[OSM-talk] routing across open spaces

[Felix Hartmann]

On 30.11.2010 17:17, Anthony wrote:
> On Tue, Nov 30, 2010 at 10:53 AM, Robert Kaiser<kairo at kairo.at>  wrote:
>> Robin Paulson schrieb:
>>> or am i missing a tag? do i need to tag parks, etc. with "area=yes"
>>> "foot=yes", "access=yes" or would that be a case of "tagging for the
>>> routing engine"
>> Note that in some park, stepping on the grass is explicitely forbidden, so
>> automatically routing across park space may pose a problem.
> What is the default, though.  For a leisure=park, area=yes is
> certainly the default.  access=yes certainly is not (you typically
> can't drive through a park).  As for foot=*, I'd say foot=permissive
> is the default (from the definition - "Typically (or pretty much
> always) open to the public, but may be fenced off, and may be closed
> e.g. at night time."). If stepping on the grass is explicitly
> forbidden, the area should be marked with foot=no or foot=private.
>
> As for the ability of routers to utilize open spaces for routing, I
> think that's more of a future feature than a current one, regardless
> of how it is tagged.  Doesn't seem like it would be all that
> difficult, as a preprocessor would just need to add implicit ways
> connecting the possible routes through the park.  But in any case,
> doesn't really matter much how it's tagged, so long as non-routable
> park areas are tagged as such.
>
> I wouldn't apply the same logic to wooded areas, of course, but those
> wouldn't be properly tagged with leisure=park.  As for long rows of
> bushes, those should be tagged - maybe barrier=hedge?
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
I don't think routing over areas will ever work well. It might work for 
2-3 areas and that is already really difficult for calculation. Just 
routing onto an open space is no problem, but calculating a route over a 
longer distance, would mean that for any place the time it needs and the 
way to take have to be calculated as a way, before using it for 
autorouting. Hence in the end the only thing that will work, is that 
there are invisible ways for routing with very low priority added to the 
map, because everything else won't be feasible for longer distances.

As long as there is no consensus or widespread use, of how map rendering 
should add such invisible ways, no area should be considered to be 
routable.....
Real polygon routing is AFAIK with the currently developed algos 
impossible (but also does not exist in reality. If you put a camera over 
a public place, and record 24hours, you'll soon notice even though 
anyone is free to walk wherever he wants to, actually there are more or 
less defined pathes that everyone takes when crossing a place - hence 
one could also argue, that such undefined but existing pathes should be 
mapped, but with a consensus that they are not visbibly rendered in 
maps, and also not shown in editors by default, except when say 
activating an editing session with the goal of working strictly on 
autorouting features -- which is in my eyes how such areas should be 
delt with ultimately (though not yet, because the editors still show 
everything and a myriad of pathes over places would make editing much 
harder))