
Hi, I have been getting strange roundabout errors. I do not see anything wrong in the data. Today's run was with mkgmap r2001, because the locator branch merge in r2008 broke the address search on the Edge 705 when not using --index and MapSource. I have seen these with a newer mkgmap as well: 2011/08/18 11:15:12 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 125418517 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.20986&mlon=25.07535&zoom=17) Last time I checked, all roundabout segments were counter-clockwise, which corresponds to drive-on-right. 2011/08/18 11:15:56 WARNING (RouteNode): 63240002.osm.pbf: Incoming roundabout flare road (Hietasaarenkuja, http://www.openstreetmap.org/browse/way/22821480) points in wrong direction? http://www.openstreetmap.org/?mlat=60.15502&mlon=24.92128&zoom=17 This is an outgoing flare road. Only the roundabout that is connected to the road has been tagged as junction=roundabout. (Sometimes I have seen flare roads or other non-roundabout roads incorrectly tagged as roundabouts.) Best regards, Marko

On Thu, Aug 18, 2011 at 01:22:38PM +0300, Marko Mäkelä wrote:
Hi,
I have been getting strange roundabout errors. I do not see anything wrong in the data. Today's run was with mkgmap r2001, because the locator branch merge in r2008 broke the address search on the Edge 705 when not using --index and MapSource. I have seen these with a newer mkgmap as well:
I still keep getting these.
2011/08/18 11:15:12 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 125418517 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.20986&mlon=25.07535&zoom=17)
Last time I checked, all roundabout segments were counter-clockwise, which corresponds to drive-on-right.
Could this be caused by too high resolution? I tried removing half the roundabout nodes.
2011/08/18 11:15:56 WARNING (RouteNode): 63240002.osm.pbf: Incoming roundabout flare road (Hietasaarenkuja, http://www.openstreetmap.org/browse/way/22821480) points in wrong direction? http://www.openstreetmap.org/?mlat=60.15502&mlon=24.92128&zoom=17
This is an outgoing flare road. Only the roundabout that is connected to the road has been tagged as junction=roundabout. (Sometimes I have seen flare roads or other non-roundabout roads incorrectly tagged as roundabouts.)
I might add that there is a oneway incoming highway=service between the two oneway flares that are called Hietasaarenkuja. Could that confuse the mkgmap diagnostics? Marko

On Thu, Sep 08, 2011 at 01:40:28PM +0300, Marko Mäkelä wrote:
On Thu, Aug 18, 2011 at 01:22:38PM +0300, Marko Mäkelä wrote:
Hi,
I have been getting strange roundabout errors. I do not see anything wrong in the data. Today's run was with mkgmap r2001, because the locator branch merge in r2008 broke the address search on the Edge 705 when not using --index and MapSource. I have seen these with a newer mkgmap as well:
I still keep getting these.
2011/08/18 11:15:12 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 125418517 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.20986&mlon=25.07535&zoom=17)
Last time I checked, all roundabout segments were counter-clockwise, which corresponds to drive-on-right.
Could this be caused by too high resolution? I tried removing half the roundabout nodes.
Removing 1/2 or 2/3 of the nodes had two effects: the "owner" of the roundabout came after me (asking why roundabouts should not look round), and mkgmap shut up. The segment consisted of 4 nodes, and its total length was less than 10 meters. Is there a bug in the mkgmap node-merging algorithm or in the diagnostics? Yesterday, the generated map of the roundabout (without the nodes removed) looked OK. I did not try routing, though. Marko
participants (1)
-
Marko Mäkelä