Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!

--- Mer 8/7/09, Mark Burton <markb@ordern.com> ha scritto:
Da: Mark Burton <markb@ordern.com> Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards! A: mkgmap-dev@lists.mkgmap.org.uk Data: Mercoledì 8 luglio 2009, 11:15
Hi Marco,
Why either side? shoudn't be enough one side only for restrict the access to the whole way?
Hey, thanks for that question, it reminded me that I needed to make the POI a routing node to stop routing across the POI when the start point is within the restricted region.
The only case it doesn't work for now is when both the start and end points are within the restricted region (one each side of the POI).
Mark, this is how I "solved" the issue so far: a short piece (say 10m) of footway on one side of the bollard http://www.openstreetmap.org/?lat=41.895031&lon=12.414956&zoom=18&layers=B00... I still do not see the reason to make 2 unaccessible arcs on both sides instead of one. Ciao.

Marco,
I still do not see the reason to make 2 unaccessible arcs on both sides instead of one.
Imagine that you have only one restricted arc that is on one side of the bollard. Now if you are within that region and try to route to a point that is on the other side of the bollard, it will route straight through the bollard because you are leaving the restricted area and not entering it. If you have two restricted areas, one each side of the bollard and your starting point is within one of the areas, it will now not route through the bollard if the destination is outside of the restricted area on the other side of the bollard. As previously mentioned, the case where both start and destination are within the restricted area does not work right and, currently, I don't have a plan for fixing this. I can't see how that can be achieved. Cheers, Mark

2009/7/8 Mark Burton <markb@ordern.com>:
As previously mentioned, the case where both start and destination are within the restricted area does not work right and, currently, I don't have a plan for fixing this. I can't see how that can be achieved.
Wouldn't Marco's approach of surrounding the bollard with a tiny piece of footpath do the trick? Dermot -- -------------------------------------- Iren sind menschlich

2009/7/8 Mark Burton <markb@ordern.com>:
Marco,
I still do not see the reason to make 2 unaccessible arcs on both sides instead of one.
Imagine that you have only one restricted arc that is on one side of the bollard. Now if you are within that region and try to route to a point that is on the other side of the bollard, it will route straight through the bollard because you are leaving the restricted area and not entering it. If you have two restricted areas, one each side of the bollard and your starting point is within one of the areas, it will now not route through the bollard if the destination is outside of the restricted area on the other side of the bollard.
As previously mentioned, the case where both start and destination are within the restricted area does not work right and, currently, I don't have a plan for fixing this. I can't see how that can be achieved.
Hi Mark! Is there any chance for this patch to get committed in the near future? I think it would be very helpful for routing (also with barrier=cycle_barrier/gate/lift_gate etc) and the case of target and/or destination being too close to the barrier is not that common. Thank you for any info! -Martin

Hi Martin,
Is there any chance for this patch to get committed in the near future? I think it would be very helpful for routing (also with barrier=cycle_barrier/gate/lift_gate etc) and the case of target and/or destination being too close to the barrier is not that common.
Thank you for any info!
It's there - but it the option to use doesn't have an obvious name? --link-pois-to-ways If this option is enabled, POIs that are situated at a point in a way will be associated with that way and may modify the way's properties. Currently supported are POIs that restrict access (e.g. bollards). Their access restrictions are applied to a small region of the way near the POI. Cheers, Mark

2009/9/1 Mark Burton <markb@ordern.com>:
Hi Martin,
Is there any chance for this patch to get committed in the near future? I think it would be very helpful for routing (also with barrier=cycle_barrier/gate/lift_gate etc) and the case of target and/or destination being too close to the barrier is not that common.
Thank you for any info!
It's there - but it the option to use doesn't have an obvious name?
--link-pois-to-ways If this option is enabled, POIs that are situated at a point in a way will be associated with that way and may modify the way's properties. Currently supported are POIs that restrict access (e.g. bollards). Their access restrictions are applied to a small region of the way near the POI.
Thanks! It's working fine! :-) To be honest, the option's name makes me think of linking POI address information to ways or something similar, not of creating restricted way snippets next to barrier nodes. Maybe something like "create-restricted-ways-for-barriers" (shorter? ;) ) would be more obvious. Anyways, thanks for this cool feature! -Martin
participants (4)
-
Dermot McNally
-
Marco Certelli
-
Mark Burton
-
Martin Simon