The cycleway tag seems not to be used when calculating the costfactor - no reverse use of oneways when easily possible

[Rheinhesse]

Hey Arndt,
to check local OSMAND-Bike routing rearding the usage of the cycleway tag, I constructed three small testcases some time ago.
Here are the results of brouter when computed on an Android-Phone with the standard trekking.brf:

Case1: A residential oneway isn't used. It's tagged  as cycleway=opposite and is part of a longdistancecycleway

   <trkpt lon="8.115249000000006" lat="49.84429399999999"><ele>196.75</ele></trkpt>
   <trkpt lon="8.115257000000014" lat="49.844493"><ele>196.5</ele></trkpt>
   <trkpt lon="8.115229999999997" lat="49.84504200000001"><ele>195.75</ele></trkpt>
   <trkpt lon="8.115352999999999" lat="49.845218999999986"><ele>195.5</ele></trkpt>
   <trkpt lon="8.115704999999991" lat="49.84567799999999"><ele>193.75</ele></trkpt>
   <trkpt lon="8.116023000000013" lat="49.84607199999999"><ele>191.25</ele></trkpt>
   <trkpt lon="8.11557400000001" lat="49.846070999999995"><ele>192.0</ele></trkpt>
   <trkpt lon="8.115219999999994" lat="49.846045000000004"><ele>193.0</ele></trkpt>
   <trkpt lon="8.11509000000001" lat="49.84602899999999"><ele>193.5</ele></trkpt>
   <trkpt lon="8.115057000000007" lat="49.84607"><ele>193.25</ele></trkpt>
   <trkpt lon="8.114747999999992" lat="49.84600499999999"><ele>194.25</ele></trkpt>

Case2: Same thing, several cycle-routes run over it

   <trkpt lon="8.473512999999997" lat="50.03993199999999"><ele>93.0</ele></trkpt>
   <trkpt lon="8.473749999999995" lat="50.04017999999999"><ele>92.25</ele></trkpt>
   <trkpt lon="8.473745000000008" lat="50.04038700000001"><ele>92.25</ele></trkpt>
   <trkpt lon="8.473192000000012" lat="50.04065499999999"><ele>93.25</ele></trkpt>
   <trkpt lon="8.47559799999999" lat="50.042767999999995"><ele>91.5</ele></trkpt>
   <trkpt lon="8.476100000000002" lat="50.04253"><ele>90.0</ele></trkpt>

Case3: Same thing, but now the tag is cycleway=opposite_track, which is missing in lookups.dat. Here even a primary road is taken instead.

   <trkpt lon="8.326865999999995" lat="49.994934"><ele>86.5</ele></trkpt>
   <trkpt lon="8.326848000000012" lat="49.99520000000001"><ele>87.25</ele></trkpt>
   <trkpt lon="8.326870000000014" lat="49.995344999999986"><ele>87.5</ele></trkpt>
   <trkpt lon="8.326974000000007" lat="49.99561600000001"><ele>88.0</ele></trkpt>
   <trkpt lon="8.325290999999993" lat="49.99592000000001"><ele>87.25</ele></trkpt>
   <trkpt lon="8.324347999999986" lat="49.996081000000004"><ele>87.75</ele></trkpt>
   <trkpt lon="8.324220999999994" lat="49.99610200000001"><ele>87.75</ele></trkpt>
   <trkpt lon="8.323949999999996" lat="49.996149"><ele>87.75</ele></trkpt>
   <trkpt lon="8.323210999999986" lat="49.996274"><ele>87.5</ele></trkpt>
   <trkpt lon="8.323093999999998" lat="49.99602300000001"><ele>87.25</ele></trkpt>
   <trkpt lon="8.322921000000008" lat="49.995912000000004"><ele>87.25</ele></trkpt>
   <trkpt lon="8.32243299999999" lat="49.995642000000004"><ele>87.75</ele></trkpt>
   <trkpt lon="8.321211000000005" lat="49.99506400000001"><ele>86.5</ele></trkpt>
   <trkpt lon="8.320831999999996" lat="49.99510000000001"><ele>87.0</ele></trkpt>

Regards,

Rupert

[abre...@googlemail.com]

Hi Rupert,

thanks for your analysis.

yes, I was a little sloppy on the issue of oneways with cycling allowed in opposite direction.

When compiling the lookup.dat I decided to encode all tags into a 32 bit word, limiting the number of tags as well as the number of values per tag. It known the 6 most frequent values for the "cycleway" tag, because 6 values + the empty value + the "unkown" value (=everything else) encode into 3 bits out of this 32 bit word, this is why all tags are either boolean or have the most frequent 2, 6, 14 or 30 values. This is why cycleway=opposite_track is missing.

When cycling in the black-forest recently, I noticed that the "tunnel" tag is also missing.

I'm planning to extend the way-description to 64 bit, allowing much more way-tags to be included, and also to include node-tags as well. This will be part of the next beta-version, which I hope to finish before spring, when interest in bike routing is expected to grow.

But for the cycleway=opposite it should be possibile to consider that in the profile, I will try that according to your  examples the next days and update the trekking-profile accordingly.
 
 regards, Arndt

[Rheinhesse]

Hi Arndt,

thanks for your quick response, this explains a lot to me. It's my opinion too, that brouter should work with a sensibly limited set of tags and values, the resources on an Android-Device are limited as well. The cycleway=opposite_track usage is below 1% with only 2145 occurences and can be neglected.

But why is there no access=no in the lookups, there are more than 100000 occurences?

I have run another testcase for checking barrier-awareness and the usage of steps. Brouter computed a route via a way tagged with vehicle=no and both endpoints tagged with barrier=gate and bicycle=no see http://www.openstreetmap.org/?lat=50.05032&lon=8.50211&zoom=16.
But the rest of the route is very good and when switching to the nosteps-profile another bridge was used for crossing the Rhein as expected.

Start/Endpoint of the testcase are:     lon="8.24749700000001" lat="50.02228099999999"  / lon="8.262540000000001" lat="50.02916099999999"

Including some node-tags, as you already have planned, will hopefully solve cases like this one.

Regards, Rupert

[Rheinhesse]

Sorry, I forgot to click the permalink, the URL above should be: http://www.openstreetmap.org/?lat=50.020302&lon=8.253028&zoom=18&layers=M

By the way, OSMAND also ignores these tags and even routes over ways with access=private

[abre...@googlemail.com]

On Monday, January 7, 2013 11:40:05 AM UTC+1, Rheinhesse wrote:

> to check local OSMAND-Bike routing rearding
> the usage of the cycleway tag, I constructed
> three small testcases some time ago.
> Here are the results of brouter when computed
> on an Android-Phone with the standard trekking.brf:

Hi Rupert,

I added cycleway=opposite and cycleway=opposite_lane now in all one-way-sensitive bike-profiles.

I also added some (heuristic) logic around the access=no problem (using access=unknown, which includes the access=no cases)

For details see my  post in the (german) openstreetmap-group:

http://forum.openstreetmap.org/viewtopic.php?pid=305226#p305226

regards, Arndt

PS: it's only a change in profiles, not the router, so you only have to update these.

But some time ago I also fixed an integer overflow in the router itself, leading to the problem reported here:

http://rad-forum.de/topics/896289/BRouter_Top_offline_Fahrrad_Routing_fur_#Post896289

The current version writes version "0.3" in the gpx-header, you can use that for a check if your apk is up-to-date.

[Rheinhesse]

Hi Arndt,

 

in the meantime I have rerun my testcases with BRouter Version4 and the new trekking Profile.

 

I added cycleway=opposite and cycleway=opposite_lane now in all one-way-sensitive bike-profiles.

 

This now works pretty well.

I also added some (heuristic) logic around the access=no problem (using access=unknown, which includes the access=no cases)

 

This also works, but why have you left out highway=residential and highway=unclassified - there over 1000 occurencies in Germany for each?

 

Another minor Point: If I understand the logic right, the usage of steps is decided very early without considering  access=no or private - in Germany in sum about 1500.

But in my opinion it's not worthwile to implement this, one should only know about it and it can easily be avoided with the nosteps-profile.

And in reality you often can use steps which are tagged with aqccess=no or private, I've already done it myself.

 

But in sum it's great work and an interesting and promising new approach compared to the common method of defining the costs in a plain XML-File.

 

Regards Rupert

 

 

 

 

[abre...@googlemail.com]

Am Dienstag, 22. Januar 2013 18:28:30 UTC+1 schrieb Rheinhesse:

> I also added some (heuristic) logic around the access=no problem (using access=unknown, which includes the access=no cases)

 

This also works, but why have you left out highway=residential and highway=unclassified - there over 1000 occurencies in Germany for each?

I have a problem with access=dedicated, which I think is wrong tagging ( dedicated should only be used for specific acces modes? But they exist in the map ). And because both access=no and access=dediacted are missing in the lookup table, they are both mapped to access=unknown.

I do not want to change the lookup-table during beta-cycle (just don't have the framework to handle the dependencies), so I now think I have to solve that
issue in the preprocessing step (=remapping access=dedicated -> access=<empty>). Then (after next map-refresh) I will try again to implement the "nominal logic" around access=no/private and see if my testsuite accepts that change.

This testsuite has about 100 test-routes and if and only if I'm able to review all route changes after a logic change, then I can deploy that change.

 

Another minor Point: If I understand the logic right, the usage of steps is decided very early without considering  access=no or private - in Germany in sum about 1500.

Good point, and yes, you understand the logic (Documenting the syntax of the profile-scripts is still on my todo-list...)

There's another issue around that for access=private bicycle=designated, which you have if you pass the Biblis Nuclear power station along the rhine river on longdistance-cycleway "R8".

When I encounterd that my solution was to have longdistance-cycleways supress the access-check, but with my deeper understanding now I think I can make that work also without the long-distance-cycleways-info.

I will come back to that.

thanks for your really helpful reviews.

[Rheinhesse]

Hi Arndt,

while testing a little in a known region, I observed a strange phenomenon - nothing of importance. But perhaps you want to check wether  it's an expected and explainable behaviour for the Brouter-Algorithm. In the testcase, with trekking.brf a route from A to B is calculated correctly. As soon as I simply move A a little farther away, the route is calculated with a small and unnecessary detour. This happens with apk version 0.5 and online version 0.4 as well. Interestingly when taking trekking-ignore-cr.brf, the routes are ok in both cases. The two routes calculated by the apk are added.

Regards Rupert

P.S. This time I've used Locus for testing. BRouter together with the Openandromaps for biking,  which show all longdistancecycleways directly on the map is a nearly ideal combination.

[abre...@googlemail.com]

On Friday, February 1, 2013 7:39:29 PM UTC+1, Rheinhesse wrote:

But perhaps you want to check wether  it's an expected and explainable behaviour for the Brouter-Algorithm. In the testcase, with trekking.brf a route from A to B is calculated correctly. As soon as I simply move A a little farther away, the route is calculated with a small and unnecessary detour.

Hi Rupert,

well - I can explain, but have to dig a little deeper into the elevation formula.

I count eleavtion penanlty for the downhill-part, not uphill. It doesn't really matter (what goes up must go down), but this way I can prefer slow descends versus steep descends, because for slow descends you get your energy back.

Then I use a hysteris-band of 10m height: as long as elevation variation happens within this band, I don't count elevation penalty. But having such a hysteris-band implies having a hidden state variable which I call the "elevation hysteris buffer", short EHB, which is a number in the range between 0m and 10m. And having such a hidden state variable implies having a "dislocality". At Track start I set EHB=0. When you go down 10m, you have EHB=10, but not yet added any elevation penalty to the total cost. That makes the difference between your two tracks, because you prepended a 10m downhill section, so at their common starting point one has EHB=0, the other EHB=10.

But why can this difference influence a routing descion more than 1000m away? One more detail on how I prefer slow descends versus steep descends: I subtract 1,5% of the traveled distance from the EHB, thus making 1,5% descend "free" and only what's above adds to the total cost. This is also needed to prevent glitches in flat, urban regions where elevation "variations" are mostly form builings, not from hills - this 1,5% just lowers the chance that you will ever add elevation penalty in flat, urban regions.

But in your "slow-descend example" shit happens: with "your" 1,5% average descend and "my" 1,5% subtraction  you have exaclty the case where an EHB-difference can be propagated over a long distance.

And with 1,5% free descend and "eleavtion_cost=66" I am at the limit where traveled distance can become invariant, because for a detour the saving in elevation penalty can equal the cost of the addional distance (1/66 = 1,5%!). This is what happened in your example (because you are at costfactor=1, turncost=0 for the long-distance cycleroutes).

So in summary: yes, it's a glitch, but it's in the formula, it's not a bug in the processing engine.

[abre...@googlemail.com]

Hi Rupert,

I finished all my homework from this thread :-)

With the new version (0.6) I extended the data files to include more way tags plus nodes tags, so all the access- and oneway issues should be o.k. now.

[Rheinhesse]

Hi Arndt,

Congratulations, the new version of BRouter is perfect, all my test-cases and some other BRouter-planned routes in my home region are calculated without any flaw. Next step, when spring finally comes, will be the real field-test in regions I don't know so well. I'll also try to play a little with modified profiles.

In my opinion, BRouter is at least one step ahead of any other Bike-Routing-Software I know. And the concept isn't limited to bike-routing, I think it could be extended with not too much effort to hiking and motor-cycling (when not the shortest distance but a nice curvature is preferred).

Greetings from Rheinhessen

Rupert

[Rheinhesse]

Hi Arndt,

the field-test really met all expectations - congratulatiosn. BRouter was of great help in regions I don't know so well. One idea came to my mind, when following the calculated routes. Somtimes when loosing height, it could be better to choose a minor road with few traffic, where you can gain speed, instead of a track with steep descends where you have to brake several times. Perhaps this preference can be described in a special profile. I've added an example from my home region.

Regards Rupert