[Tagging] StreetComplete 10 / foot=yes on residential

[Markus]

On Fri, 15 Feb 2019, 13:22 Tobias Wrede <list at tobias-wrede.de wrote:

> Unfortunately, the legal situation is not always as clear as we wish to.
> There are a lot of grey zones and we need to apply common sense when
> tagging the access rules.
>
> Here are a few situations where I would not hesitate to put a foot=no on
> the road even if there is no corresponding traffic sign.
>
> [...]
>
> By German law you are required to use footpaths if they exists on the
> road. In these examples there are no footpaths on the roads so you
> should be able to use the carriageways. But is that what the planners
> intended and would it make sense at all?
>

Afaik this law also applies to these examples: a road can be composed of
several carriageways, consequently a parallel carriageway – even if it runs
through a tunnel or over a bridge – belongs to the same road. If there are
sidewalks or parallel footways – even if they run through a tunnel or over
a bridge – a pedestrian is obliged to use them and consequently isn't
allowed to use any other parallel carriageway like for example that tunnel.

Regarding the tagging: while the meaning of foot=no isn't wrong, it's in
conflict with our 'Don't map your local legislation, if not bound to
objects in reality' rule (which imo makes sense as not every mapper –
especially non-locals – might know the law).

If the sidewalks are mapped as separate ways, i'd add sidewalk=separate to
all parallel carriageways. Thus, routers have the information that there
are separate footways that – depending on the jurisdiction – pedestrians
must use.

For parallel pedestrian bridges or underpasses sidewalk=separate seems a
bit unsuitable. Maybe footway=separate [undocumented, but in use] were
better?

If the sidewalks aren't separately mapped, but tagged with
sidewalk=left/right on lateral carriageways, it seems we need something
like sidewalk=parallel_carriageway for the medial carriageways as
information for routers.

Regards

Markus

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190216/30a61b88/attachment.html>