[Tagging] Formally informal sidewalks

[Nick Bolten]

On Tue, Jul 18, 2017 at 9:24 AM marc marc <marc_marc_irc at hotmail.com> wrote:

> Le 18. 07. 17 à 16:01, Nick Bolten a écrit :
> >> All crossing between a sidewalk and a driveways I have tag have the same
> >> type of kerb on each side. It's why I use kerb=lowered without any need
> >> for left/right details, it is for the whole crossing.
> > I think I'm confused again
>
> highway=residential
> sidewalk=both
> kerb=raised
>
> highway=service
> service=driveway
> sidewalk=no
>
> on shared node
> kerb=lowered
>

I've seen some routers interpret kerb=* along a way as being a potential
barrier, though hopefully that is restricted to non-road ways. This would
be doubly confusing for a combined road+sidewalk way: is this kerb feature
encountered as one walks down the sidewalk? Both kerb=raised and
kerb=lowered are used on footway=sidewalk ways to describe changes in
displacement.


>
> >> Therefore I never needed to ask myself how I tag a useless mixed layout
> >> A crossing with a raised kerb on one side and a lowered kerb on the
> >> other side is as unusable for wheelchair as if it was raised on both
> >> sides.
> > Not true! Some wheelchair users are happy to go down a raised curb
> kerb=raised is defined on the wiki as "implies wheelchair=no"
> so it is used on kerb with a high height and wheelchair routing avoid it
> Of course you can also break this...
> Do you know a tool capable of making a wheelchair routing with
> kerb=raised usable in incline=down direction ?
> Or are you talking about a theoretical usecase that currently
> does not exist ?


Then that wiki note for kerb=raised isn't accurate.

I've done such a thing using pgRouting in the past. It actually required
guessing the 'high' and 'low' side, since incline=up/down is rare. Roughly,
given the kerb node, the previous way, and the next way:

cost AS CASE
  WHEN node.kerb = 'raised'
  THEN CASE
    WHEN prevway.footway = 'sidewalk' AND nextway.isroad
    THEN 0
    ELSE Inf
  ELSE 0
END

Most routers don't yet have a notion of 'going from this way to that way'
available to their user-editable cost functions, which is more relevant to
pedestrians than street traffic (but they do hard-code similar logic for
elements of street traffic, e.g. OSRM and turn restrictions).

Also, this information is useful for demographics outside of people with
disabilities or other explicit mobility needs. A parent walking a stroller
cares about the availability of curb ramps and the direction of traversing
raised curbs. A parent with small children may want there to be curbs or
some other barrier to protect them from cars (that's their purpose, after
all). A cyclist may want to take a route that never involves riding along
the street - but also not up any raised curbs. Such a cyclist would also
often be fine with routes where one goes down a raised curb every so often.


> Keep foot routing working before thinking about exceptional cases...
> because exceptional cases 'll not work if you break many things !
>

I'm not sure how any of these points break foot routing...

But these are not exceptional cases, these are normal cases: unlike with
automotive traffic, pedestrian needs do not fit neatly into 1-3 categories,
so we must instead rely on identifying specific potential barriers / access
modifiers. Ask 20 people from the 10-20% of the population with specific
mobility requirements and you will get 20 unique (and often incompatible)
routing profiles, including their treatment of curbs. And this is before we
get into requirements beyond mobility, such as impaired vision or hearing,
or safety concerns. This is also why our maps are almost useless for a huge
portion of the population: they treat pedestrian access as a monolith that
essentially amounts to, "you can go on some streets and also these extra
footways".

Best,

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170718/9216472d/attachment.html>