I've had a play with routing over the weekend - it's generally great, though I'm looking forward to routing across map boundaries! I've occasionally seen the roundabout-exit counting problem - though more commonly, data-source problems with entries/exits not marked one-way when they should be. Other than that (and the discussion suggests that's now fixed), it seems to be working really well - thanks, team!
I'll second that. I've been away for the weekend and so took the opportunity to use my routable maps for some 100+ mile journeys. Routing seemed to work well with the best route being chosen in most cases and other than the roundabout exit counting problem (data errors) I could find no fault. Cheers Paul Toby Speight wrote:
I've had a play with routing over the weekend - it's generally great, though I'm looking forward to routing across map boundaries!
I've occasionally seen the roundabout-exit counting problem - though more commonly, data-source problems with entries/exits not marked one-way when they should be.
Other than that (and the discussion suggests that's now fixed), it seems to be working really well - thanks, team! _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I would also like to add my compliments to the remarkable progress mkgmap has shown in the last week. I have been testing in southern Germany, with recent SVN versions of the NOD branch: routing has been quite reliable. With the latest roundabout patches, even the correct exit is displayed by my unit (tested on a eTrex Vista HCx). Since my area is very densely mapped, I'm desperately looking forward to the across-tile routing. :-) Cheers
Hi Clinton,
I would also like to add my compliments to the remarkable progress mkgmap has shown in the last week. I have been testing in southern Germany, with recent SVN versions of the NOD branch: routing has been quite reliable. With the latest roundabout patches, even the correct exit is displayed by my unit (tested on a eTrex Vista HCx).
Thanks, please report any bad routing or other oddities. My next goal is to implement turn restrictions as they really need to be in place for routing to be trustworthy.
Since my area is very densely mapped, I'm desperately looking forward to the across-tile routing. :-)
A trial patch has been posted but no-one has yet reported back on how it performs. Cheers, Mark
On Tue, Feb 17, 2009 at 1:33 PM, Mark Burton <markb@ordern.com> wrote:
Since my area is very densely mapped, I'm desperately looking forward to the across-tile routing. :-)
A trial patch has been posted but no-one has yet reported back on how it performs.
Thanks: I've applied the -v2 patch to the trunk, and am compiling a map of Germany. I'll report on its success/failure when I have a chance to test. Cheers
Since my area is very densely mapped, I'm desperately looking forward to the across-tile routing. :-)
A trial patch has been posted but no-one has yet reported back on how it performs.
Sorry to tell you, at the moment it works not for me. If I set the start of the routing near a boundary, my etrex hangs up. But I've some other problems with the bounding box, maybe this is the real reason.
Hi Johann,
Sorry to tell you, at the moment it works not for me. If I set the start of the routing near a boundary, my etrex hangs up. But I've some other problems with the bounding box, maybe this is the real reason.
You're definitely in uncharted territory there! What's the problem with the bounding box? Cheers, Mark
Mark Burton schrieb:
Hi Johann,
Sorry to tell you, at the moment it works not for me. If I set the start of the routing near a boundary, my etrex hangs up. But I've some other problems with the bounding box, maybe this is the real reason.
You're definitely in uncharted territory there!
No, the area should be well charted :-)
What's the problem with the bounding box?
If I prepare a osm file with splitter, the bounds are calculated with some overlap, which should get cut by mkgmap. As far as I can see, this overlap is not cut away from the map. The bounding boxes of the resulting combined gmapsupp.img are overlapped. I will explain more precise tomorrow, today I'm in a hurry.
If I prepare a osm file with splitter, the bounds are calculated with some overlap, which should get cut by mkgmap. As far as I can see, this overlap is not cut away from the map. The bounding boxes of the resulting combined gmapsupp.img are overlapped. I will explain more precise tomorrow, today I'm in a hurry.
OK - thanks. Mark
Hi Toby,
I've had a play with routing over the weekend - it's generally great, though I'm looking forward to routing across map boundaries!
I've occasionally seen the roundabout-exit counting problem - though more commonly, data-source problems with entries/exits not marked one-way when they should be.
Other than that (and the discussion suggests that's now fixed), it seems to be working really well - thanks, team!
Glad to hear it's working well for you. The roundabout exit problem can be fixed by using the --frig-roundabouts option. It's rather a hack and may actually make some roundabouts suffer from the problem when, before, they didn't but, at this time, it's all we have. I believe the problem is that the gps doesn't appear to recognise a roundabout exit if the exit road is too close to being lined up with one of the segments in the roundabout it is attached to. If we can come up with a better fix, it would be good. Cheers, Mark
0> In article <20090217122810.774eb3aa@crow>, 0> Mark Burton <URL:mailto:markb@ordern.com> ("Mark") wrote: Mark> The roundabout exit problem can be fixed by using Mark> the --frig-roundabouts option. It's rather a hack and may Mark> actually make some roundabouts suffer from the problem when, Mark> before, they didn't but, at this time, it's all we have. I understand that; thanks for reiterating, though. As I said, bad source data is more of an issue - I'm cleaning up quite a bit as I go. One thing that caught me by surprise was approaching a roundabout and just being told to keep left - it wasn't until I reached the splitter island that I got given the roundabout exit to take. I guess this is the opposite of the missing-exits problem, in that the island was large enough to count as a separate road for the eTrex's purposes. One thing I do have a concern about is mixing speed rules into the lines file - I've patched my style as instructed, but now all roundabouts are drawn the same, because there's a rule for roundabouts for speed purposes. (I'm too lazy to introduce roundabout rules for each highway class). I think that this probably needs a re-think, because it would be nice to combine information to give a better resultant speed guess (including features such as traffic signals, number of lanes, etc - and for roads in "place=*" as described[1] on the OSM wiki). [1] <URL: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed >
Hi Toby,
As I said, bad source data is more of an issue - I'm cleaning up quite a bit as I go.
Good!
One thing that caught me by surprise was approaching a roundabout and just being told to keep left - it wasn't until I reached the splitter island that I got given the roundabout exit to take. I guess this is the opposite of the missing-exits problem, in that the island was large enough to count as a separate road for the eTrex's purposes.
Did it think that the splitter was, itself, a left turn?
One thing I do have a concern about is mixing speed rules into the lines file - I've patched my style as instructed, but now all roundabouts are drawn the same, because there's a rule for roundabouts for speed purposes.
Not sure I understand that. The default rules now look like this: junction=roundabout & highway=trunk [0x0c road_class=3 road_speed=5 resolution 16] junction=roundabout & highway=primary [0x0c road_class=3 road_speed=4 resolution 19] junction=roundabout & highway=secondary [0x0c road_class=2 road_speed=3 resolution 20] junction=roundabout & highway=tertiary [0x0c road_class=1 road_speed=3 resolution 20] junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=2 resolution 21] junction=roundabout [0x0c road_class=0 road_speed=1 resolution 21]
(I'm too lazy to introduce roundabout rules for each highway class). I think that this probably needs a re-think, because it would be nice to combine information to give a better resultant speed guess (including features such as traffic signals, number of lanes, etc - and for roads in "place=*" as described[1] on the OSM wiki).
[1] <URL: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed >
The maxspeed tag should be effective as support for that was recently added by Bernhard. Cheers, Mark
0> In article <20090217140024.4c823ae4@crow>, 0> Mark Burton <URL:mailto:markb@ordern.com> ("Mark") wrote: Mark> Did it think that the splitter was, itself, a left turn? No, the instruction was something like "keep left, 200m". It's just that not having had routable maps before (unless you count the basemap), I was just slightly surprised (I'd seen the sign for the roundabout, and was expecting a roundabout instruction). I'm over it now.
One thing I do have a concern about is mixing speed rules into the lines file - I've patched my style as instructed, but now all roundabouts are drawn the same, because there's a rule for roundabouts for speed purposes.
Mark> Not sure I understand that. The default rules now look like this: Mark> Mark> junction=roundabout & highway=trunk [0x0c road_class=3 road_speed=5 resolution 16] Mark> junction=roundabout & highway=primary [0x0c road_class=3 road_speed=4 resolution 19] Mark> junction=roundabout & highway=secondary [0x0c road_class=2 road_speed=3 resolution 20] Mark> junction=roundabout & highway=tertiary [0x0c road_class=1 road_speed=3 resolution 20] Mark> junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=2 resolution 21] Mark> junction=roundabout [0x0c road_class=0 road_speed=1 resolution 21] You're right - my niggle was that they all map to 0x0c, and thus appear in different colour to the roads they are part of. Can I just change them to match the highway=* rules? [/me looks at garmin_feature_list.csv] I guess not - presumably this is what the device uses to know it's a roundabout rather than a random one-way road that just happens to be circular. Never mind.
I think that this probably needs a re-think, because it would be nice to combine information to give a better resultant speed guess (including features such as traffic signals, number of lanes, etc - and for roads in "place=*" as described[1] on the OSM wiki).
[1] <URL: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed >
Mark> The maxspeed tag should be effective as support for that was Mark> recently added by Bernhard. Trouble is that maxspeed refers to the legal maximum; near here there's a 30mph-limit road with about 10 sets of lights in half a mile and the effective speed is about 10mph (slightly faster on a bike). Maybe it's time to resurrect a proposal for a more realistic speed tag on ways...
Toby Speight escribió:
0> In article <20090217140024.4c823ae4@crow>, 0> Mark Burton <URL:mailto:markb@ordern.com> ("Mark") wrote:
Mark> Did it think that the splitter was, itself, a left turn?
No, the instruction was something like "keep left, 200m". It's just that not having had routable maps before (unless you count the basemap), I was just slightly surprised (I'd seen the sign for the roundabout, and was expecting a roundabout instruction). I'm over it now.
From my experience with a nuvi I think when the angle between an exit and the road you are in is small (don't know the exact figure) message is "keep left/right" instead of "exit left/right", but it means you must abandon your road and take the one to your left/right, so in the case above, I think the splitter is being considered as a left turn. Otherwise you wouldn't receive any message before the roundabout.
One thing I do have a concern about is mixing speed rules into the lines file - I've patched my style as instructed, but now all roundabouts are drawn the same, because there's a rule for roundabouts for speed purposes.
Mark> Not sure I understand that. The default rules now look like this: Mark> Mark> junction=roundabout & highway=trunk [0x0c road_class=3 road_speed=5 resolution 16] Mark> junction=roundabout & highway=primary [0x0c road_class=3 road_speed=4 resolution 19] Mark> junction=roundabout & highway=secondary [0x0c road_class=2 road_speed=3 resolution 20] Mark> junction=roundabout & highway=tertiary [0x0c road_class=1 road_speed=3 resolution 20] Mark> junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=2 resolution 21] Mark> junction=roundabout [0x0c road_class=0 road_speed=1 resolution 21]
You're right - my niggle was that they all map to 0x0c, and thus appear in different colour to the roads they are part of. Can I just change them to match the highway=* rules?
[/me looks at garmin_feature_list.csv] I guess not - presumably this is what the device uses to know it's a roundabout rather than a random one-way road that just happens to be circular. Never mind.
I think that this probably needs a re-think, because it would be nice to combine information to give a better resultant speed guess (including features such as traffic signals, number of lanes, etc - and for roads in "place=*" as described[1] on the OSM wiki).
[1] <URL: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed >
Mark> The maxspeed tag should be effective as support for that was Mark> recently added by Bernhard.
Trouble is that maxspeed refers to the legal maximum; near here there's a 30mph-limit road with about 10 sets of lights in half a mile and the effective speed is about 10mph (slightly faster on a bike). Maybe it's time to resurrect a proposal for a more realistic speed tag on ways... _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. OpenOffice es gratis. El uso de OpenOffice es totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
One oddity that comes to mind - I got told to turn right ("Right on Victoria Avenue") where two roads meet end-to-end. Two cycle routes also meet here, but I'd told the Garmin to use car routing, so from that point of view, it shouldn't be a turn. If it matters, I was heading north at node_20094647: 52.212823,0.12573928.
participants (6)
-
Carlos Dávila -
Clinton Gladstone -
Johann Gail -
Mark Burton -
Paul -
Toby Speight