Re: R: [mkgmap-dev] (almost) duplicated node issue
I know about IMG resolution, Mark. That is the reason I think there is a bug. If the Garmin cannot handle such short arcs, mkgmap shall compile the case in a way that does not violate the garmin specs. But I'm not really sure that the problem is exactly this. It might be that mkgmap has a bug in the routing data base compiling. Well I'm not expert, but I guess something goes wrong when the 2 so close nodes collapses in a single node when the garmin encoding is applied. Then 2 nodes in OSM, 1 node in Garmin... and the routing DB gets corrupted. Something like that (but I'm really speculating). Someone should check the code to track the situation. The osm file I've attached (that reproduce the error) is small enough to be tested carefully. Ciao. --- Dom 24/5/09, Mark Burton <markb@ordern.com> ha scritto:
Da: Mark Burton <markb@ordern.com> Oggetto: Re: R: [mkgmap-dev] (almost) duplicated node issue A: mkgmap-dev@lists.mkgmap.org.uk Data: Domenica 24 maggio 2009, 19:04
Hi Marco,
I believe that the distance between nodes must not be less than some minimum value (can't remember what it is off the top of my head). So I guess what you have found is an arc whose length is too short to handled by the garmin software.
Cheers,
Mark
Well, maybe I've found something strange.
I've attached to this mail a .zip file containing a small .osm DB (downloaded today) and a screenshot (.png)
If I try to compile the attached .osm file, I get a map with broken routing data that crashes MapSource (for example try to get a route from one side to the other of "Piazza Caprera" in the centre of the map, or try routes in the lower left corner). This problem is independent by mkgmap style and mkgmap version (if you download the Italian map from http://www.team-oid.de/cgi-bin/maps_download/showdir.cgi compiled about one month ago, you'll get the same routing problems in this area)
I've discovered an issue that maybe is the cause of the problem. If you open the attached picture you'll see a very short segment (less than 1 meter) that you can identify with the coordinates. It is at the cross between Via Zara and Corso Trieste (you must zoom a lot).
Well, if you delete this short piece of road, the routing Data Base is built correctly by mkgmap. Maybe somthing related to rounding makes this too short segment a problem during map compiling (the two ends collapses in one point...).
I don't think I'll be able to go further: I hope that what I found can help some mkgmap developers to individuate the issue and a possible solution.
I've not corrected the OSM DB, so you can still download this area by yourself.
Ciao, Marco.
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marco,
I know about IMG resolution, Mark. That is the reason I think there is a bug. If the Garmin cannot handle such short arcs, mkgmap shall compile the case in a way that does not violate the garmin specs.
It would be nice if mkgmap could work around the problem of short arcs so I am looking into what it needs to do to achieve that. Unfortunately, it's not an easy problem to solve so it will take a little thought.
But I'm not really sure that the problem is exactly this. It might be that mkgmap has a bug in the routing data base compiling. Well I'm not expert, but I guess something goes wrong when the 2 so close nodes collapses in a single node when the garmin encoding is applied. Then 2 nodes in OSM, 1 node in Garmin... and the routing DB gets corrupted. Something like that (but I'm really speculating).
The nodes are separate, just too close together.
Someone should check the code to track the situation. The osm file I've attached (that reproduce the error) is small enough to be tested carefully.
Thanks for the sample. Cheers, Mark
I know about IMG resolution, Mark. That is the reason I think there is a bug. If the Garmin cannot handle such short arcs, mkgmap shall compile the case in a way that does not violate the garmin specs.
It would be nice if mkgmap could work around the problem of short arcs so I am looking into what it needs to do to achieve that. Unfortunately, it's not an easy problem to solve so it will take a little thought.
Would it be an idea to enter a slightly longer distance for the arc in the routing db? I really dont like such things, as they are only are just workarounds, but it seems the easiest solution until the correct encoding is known.
Hi Johann,
Would it be an idea to enter a slightly longer distance for the arc in the routing db?
I tried that, it didn't help.
I really dont like such things, as they are only are just workarounds, but it seems the easiest solution until the correct encoding is known.
I don't think the issue is the correctness of the encoding, it's more to do with the fact that the OSM map can contain nodes that are closer together than the Garmin can accept. The thorny issue is how to munge the data so that the GPS (or mapsource) doesn't barf but the map is still usable (connections not broken, etc.) One trivial fix is to delete any way that would otherwise cause a problem. That should stop the garminware from barfing but would not be ideal from the user's point of view because it would break the routing. Cheers, Mark
Hi - I'm new on this mailing list an try to understand what's going on... :-) One observation regarding bicycle routing: The tag combination oneway=yes cycleway=opposite_lane seems not to work correctly. I.e., routing suggests a detour because it does not consider that you could use the one-way street in opposite direction. This applies to the tags "cycleway=opposite_track" and "cycleway=opposite" as well. Is there a solution for this problem? Is, in this case, Garmin routing software able to distinguish between car routing and bicycle routing at all? Hope you can help... because there's a great number of one-way streets in my city, which may be used by bike in opposite direction. Regards, Markus
Hi Markus,
Hi - I'm new on this mailing list an try to understand what's going on... :-)
One observation regarding bicycle routing: The tag combination
oneway=yes cycleway=opposite_lane
seems not to work correctly. I.e., routing suggests a detour because it does not consider that you could use the one-way street in opposite direction.
This applies to the tags "cycleway=opposite_track" and "cycleway=opposite" as well.
Is there a solution for this problem? Is, in this case, Garmin routing software able to distinguish between car routing and bicycle routing at all?
Hope you can help... because there's a great number of one-way streets in my city, which may be used by bike in opposite direction.
At this time, I believe the only way you can achieve what you want is to create a map specifically for bicycle navigation that ignores the oneway=yes if the cycleway=opposite* tag(s) are set. This would involve writing some rules for the style file. I am sure that the style file gurus on the mailing list will suggest something appropriate. Of course, such a map would not be useful for routing vehicles. Cheers, Mark
On Mon, May 25, 2009 at 05:27:52PM +0100, Mark Burton wrote:
Hope you can help... because there's a great number of one-way streets in my city, which may be used by bike in opposite direction.
At this time, I believe the only way you can achieve what you want is to create a map specifically for bicycle navigation that ignores the oneway=yes if the cycleway=opposite* tag(s) are set. This would involve writing some rules for the style file. I am sure that the style file gurus on the mailing list will suggest something appropriate.
What would it take to duplicate the way in mkgmap, as highway=cycleway, oneway=-1? This could of course be done relatively easily by preprocessing the OSM data before feeding it to mkgmap, but I would consider it an ugly workaround.
Of course, such a map would not be useful for routing vehicles.
Nitpicking: I thought that bicycles are human powered vehicles. :-) BTW, are there any non-OSM Garmin maps that feature routeable cycleways? Such a map could be useful for reverse engineering. (I have only used OSM on my Edge 705, and I read that a commercial map of Finland lacks routing data for cycleways, even though some ways are visible on the screen.) Marko
Hi Marko,
What would it take to duplicate the way in mkgmap, as highway=cycleway, oneway=-1? This could of course be done relatively easily by preprocessing the OSM data before feeding it to mkgmap, but I would consider it an ugly workaround.
This has been discussed before but I don't think anyone implemented anything. I would be happy to give it a go.
Of course, such a map would not be useful for routing vehicles.
Nitpicking: I thought that bicycles are human powered vehicles. :-)
Agreed, but you know what I was trying to say! Cheers, Mark
Thanks to you all for the ideas! Now I see that a lot can be achieved by editing the style file. A lot good things, and a lot nonsense as well. ;-) The default style adds a "foot=yes" for cycleways, which should not be assumed as a default permission, imho. But I'm not sure about this. Bicycle routing against one-ways -------------------------------- As far as I understand the style rules, I could add this one: bicycle=opposite { set oneway=no } Some other rules should be established too: bicycle=opposite_lane { set oneway=no } bicycle=opposite_track { set oneway=no } Having generated a map with this rules, it will be of no use for motor vehicles, of course. But as my only goal is to optimize a map for bicycles, that would be no problem so far. In the long run, this feature should be adapted so that the user can select at the GPS device whether bicycle routing or motorcar routing is to be used. Road preferences ---------------- There is a key "road_speed" in the style file. I assume that this is meant to be a means for road preferences. What speed values are associated with this speed classes? E.g., is road_speed=4 twice as fast as road_speed=2? I ask this because I want to give cycleways a slight preference against other roads, and this preference should really be "slight". Markus -------- Original-Nachricht --------
Datum: Mon, 25 May 2009 19:54:05 +0100 Von: Mark Burton <markb@ordern.com> An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
Hi Marko,
What would it take to duplicate the way in mkgmap, as highway=cycleway, oneway=-1? This could of course be done relatively easily by preprocessing the OSM data before feeding it to mkgmap, but I would consider it an ugly workaround.
This has been discussed before but I don't think anyone implemented anything. I would be happy to give it a go.
Of course, such a map would not be useful for routing vehicles.
Nitpicking: I thought that bicycles are human powered vehicles. :-)
Agreed, but you know what I was trying to say!
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
gypakk＠gmx.eu -
Johann Gail -
Marco Certelli -
Mark Burton -
Marko Mäkelä