[PATCH v4] - beware of the bollards!
v4 forgot to make the POI a routing node - it is now - this stops routing across the POI when the start and end points are within the restricted area. ------------- v3 now adds extra points either side of the POI to reduce length of way that has restricted access. Currently points are 25m away from the POI. It would be nice if they were really close (like 5m) but if you try that, the map looks crap due to the limited coordinate resolution. So, 25m is a compromise between visual appearance and minimising the extent of the restricted zone. ------------ v2 - quick update based on instantaneous feedback from ML! Now works for any POI that sets "access=no" (could use the more general test of any of the access tags being set but let's see how this works for now). Default access rights now set in style file. Any suggestions for a better code for cycle_barrier? ------------ Fed up of being routed in your car down city streets only to find the way is blocked by a bollard? Well, if so, this is the patch for you. If a way has a bollard on a point, the segments of the way that connect to the bollard have access restrictions placed on them. By default, a bollard implies: access=no, foot=yes, bicycle=yes. Testing using mapsource shows that it generally works as expected although if the destination cannot be reached by any other route, it routes straight through the bollard rather than failing! If the destination can be reached by some other route, even if the route is really long, it will avoid the bollard. I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex it appears as a small dot in the way. As usual, all feedback is welcome. Cheers, Mark
v4
forgot to make the POI a routing node - it is now - this stops routing across the POI when the start and end points are within the restricted area.
Sorry, my comment is incorrect. It only stops routing across the POI when the start point is in the restricted area not when both the start and destination points are within the area - that case is still not handled right.
Howdy folks, Shall I commit this stuff or does it need more work? To recap, it stops routing across a bollard (or other POI that has access restrictions). It works OK except in the case where the start and end positions are close to the bollard. As previously discussed, that is probably not fixable given our current knowledge. So, if no one has any issues, I shall commit this in a day or two. Cheers, Mark
On Fri, Jul 17, 2009 at 10:32 PM, Mark Burton<markb@ordern.com> wrote:
Shall I commit this stuff or does it need more work?
I have not yet had time to test this, but would it be an idea to optionally enable or disable this behaviour? I know that mkgmap is slowly growing an unmanageable number of command line options, but this still might help if we discover unwanted side effects. In particular, I wonder how this would affect special cycling maps which use (or abuse) automobile routing for bicycles. Cheers.
Hi Clinton,
I have not yet had time to test this, but would it be an idea to optionally enable or disable this behaviour? I know that mkgmap is slowly growing an unmanageable number of command line options, but this still might help if we discover unwanted side effects.
I can do that. My preference would be to enable this feature by default and have an option to disable the association of POIs with ways with something like: --no-pois-on-ways. Cheers, Mark
Clinton Gladstone schrieb:
In particular, I wonder how this would affect special cycling maps which use (or abuse) automobile routing for bicycles.
This shouldn't be a problem, since the bollard implementation is based on the access values. And such a map has to deal with the access tags in general, if it wants to use the motorcar routing for other vehicles. Gruss Torsten
2009/7/20 Torsten Leistikow <de_muur@gmx.de>
Clinton Gladstone schrieb:
In particular, I wonder how this would affect special cycling maps which use (or abuse) automobile routing for bicycles.
This shouldn't be a problem, since the bollard implementation is based on the access values. And such a map has to deal with the access tags in general, if it wants to use the motorcar routing for other vehicles.
Well but one allways has to remap these values to motorcar=yes for special purpose maps, as only car/motorcycle provides proper routing. I have not really read through the patch as it does not interest me, but you have to make sure that it runs before the style-file for the access values, otherwise routing with a bicycle on car/motorcycle mode will not work anymore. I'm a bit skeptical if this will really not pose any problems for speciality maps. With a switch it would be cleaner (and not cost any additional calculation time for other maps).
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann schrieb:
Well but one allways has to remap these values to motorcar=yes for special purpose maps, as only car/motorcycle provides proper routing.
Yes, but you have to do such a change for all highway types anyway (bicycle=* -> motorcar=*, motorcar=* -> bicycle=*). So there is nothing special about the bollards. Gruss Torsten
Hi Felix,
Well but one allways has to remap these values to motorcar=yes for special purpose maps, as only car/motorcycle provides proper routing.
Never understood that need to route as a car, but I am happy to cater for such a foible.
I have not really read through the patch as it does not interest me, but you have to make sure that it runs before the style-file for the access values, otherwise routing with a bicycle on car/motorcycle mode will not work anymore.
Well, it runs after the style file stuff so to avoid making you unhappy, I shall make it disabled by default and the switch will enable it.
I'm a bit skeptical if this will really not pose any problems for speciality maps. With a switch it would be cleaner (and not cost any additional calculation time for other maps).
Your scepticism is well placed. Cheers, Mark
2009/7/20 Mark Burton <markb@ordern.com>
Hi Felix,
Well but one allways has to remap these values to motorcar=yes for special purpose maps, as only car/motorcycle provides proper routing.
Never understood that need to route as a car, but I am happy to cater for such a foible.
bicycle does rely only on routeclass, not on speedclass. So you can only have 0-4 as differentiation in bicycle mode, no different speed (o.k. you have 0 and 1 (2-7 get degraded to 1), basically bicycle mode equals motorcar shorter distance, so you miss the faster / shorter time routing option (though choosable) when going for bicycle modus. With only 5 different classes of roads it is more or less impossible to prefer i.e. a mtbroute over a cycleroute over a ......., you get too many roads/ways classified equally and too few possibilites to heavily downgrade something. One could of course use taxi, emergency, .... also as they route as good as car/motorcycle - but bicycle and pedestrian do not produce any reasonable routes (basically only good for shortest route while avoiding some road types, but not enough to prefer specific road types). The problem is that while every garmin unit (except edge) supports car/motorcycle not all support emergency or taxi. I don't think maps where you expect cyclists to choose emergency mode because car/motorcycle is really kept for cars but they can only choose car/motorcycle will work well for them. That's why I prefer to use car/motorcycle, it is the best to provide consistent results.
I have not really read through the patch as it does not interest me, but you have to make sure that it runs before the style-file for the access values, otherwise routing with a bicycle on car/motorcycle mode will not work anymore.
Well, it runs after the style file stuff so to avoid making you unhappy, I shall make it disabled by default and the switch will enable it.
if it is enabled by default, but you can disable it, it would be fine with me too. I just think we should have a possibility for speciality maps not to need to calculate things that are not needed.
I'm a bit skeptical if this will really not pose any problems for speciality maps. With a switch it would be cleaner (and not cost any additional calculation time for other maps).
Your scepticism is well placed.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Clinton Gladstone -
Felix Hartmann -
Mark Burton -
Torsten Leistikow