oneway:bicycle=yes seems not to be digested

Bug #1606968 reported by zarl on 2016-07-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

From what I saw in the code I assume that oneway:bicycle=yes seems not to be digested yet.

This affects my Garmin Oregon using

Some time ago a contributor mass edited combined foot/cycleways in Munich by exchanging all oneway=* with bicycle:oneway=* (assuming that oneway=* also affects routing for pedestrians...). That broke routing in that area for me and I discovered the mistankenly used bicycle:oneway=* instead of oneway:bicycle=*.

After those tags were fixed routing still broke on formerly working routes:

- when calculating a ~12 km long route from e.g. 48.1182,11.4444 to 48.1631,11.5688 my Garmin now reports a route calculation error, in both directions.

- I also observed strange micro-routing while on a way which was calculated properly before that mass edit, e.g. my Garmin asked me to take the cycleway on the left side of the road which I knew had an information tagged to route 'oneway'.

I tested this latter region by adding oneway=yes to the existing oneway:bicycle=yes and discovered that now routing worked again properly in that area. I can provide links to some example changesets if necessary.


luckyguess (luckyguess) wrote :

Thanks for the hint, a small patch is already committed and I will create a new set of map files in the next hours.

Changed in radkarte:
importance: Undecided → High
assignee: nobody → luckyguess (luckyguess)
status: New → Fix Released
zarl (carl-einem) wrote :

revision 440 looks great, thanks!

zarl (carl-einem) wrote :

My second use case (routing via the wrong side of the street) is now solved, thanks again!

Only the calculation error still turns up for a certain reference route. For some reason POIs several hundred meters away (to the left or right) from my test destination will not always cause this routing calculation error. I still have to test this behaviour in the opposite direction.

So I suspect there is an area between my tour start and the destination that has too much details or other elements that overburden my several years old Garmin Oregon 400, I just don't have an idea yet how to isolate such an area since I have no idea how Garmins' internal route calculation works.

luckyguess (luckyguess) wrote :

Can you show me examples (especially in BaseCamp), so I can try to debug that issue?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers