<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 11, 2015 at 12:35 PM, moltonel 3x Combo <span dir="ltr"><<a href="mailto:moltonel@gmail.com" target="_blank">moltonel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/03/2015, Mike N <<a href="mailto:niceman@att.net">niceman@att.net</a>> wrote:<br>
> On 3/10/2015 12:56 PM, Volker Schmidt wrote:<br>
>> If I understand correctly that you want routing to cross a park as long<br>
>> as the way in and the way out are connected to the perimeter of the<br>
>> park. This is only correct in parks where you are free to walk anywhere.<br>
>> Most parks in continental Europe do not work this way. Typically, but<br>
>> not always, you have to stay on the paths.<br>
>><br>
>> To solve this, one needs possibly a new (?) tag for parks like<br>
>> stay_on_path=yes|no<br>
><br>
> I agree - there needs to be areas of general walk permission established<br>
> before a router can include that area.<br></span></blockquote><div> </div><div>Or the router could have an affinity for the path but not so aggressively avoid it if there's not a barrier way more substantial than bollard in the way...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Another common usecase is surface car parks. You've got lots of<br>
pedestrian paths that lead to it, but nothing explicit inside it, and<br>
even following the service=parking_aisle ways would be too<br>
restrictive.</blockquote><div><br></div><div>These could be mapped as highway=surface, area=yes anyway (not sure how well routing engines actually handle this, but navigable areas are hardly unique to carparks). </div></div></div></div>