[Tagging] barrier=kerb + kerb=lowered

[Mateusz Konieczny]

Jun 7, 2021, 16:50 by f at zz.de:

> On Sun, Jun 06, 2021 at 10:50:54PM -0400, Jmapb wrote:
>
>> What do folks here think of the barrier=kerb + kerb=lowered combo? I've
>> started seeing it a lot with mappers micromapping crosswalks.
>>
>> Offhand, it seems like textbook troll tagging to me, negating a tag with
>> its own subtag. If the kerb has been lowered so that the footway is
>> level with roadway, then not only is there no kerb but there's no
>> barrier at all. Exactly the opposite.
>>
>> Currently the wiki doesn't indicate that kerb=lowered and other kerb=*
>> values are intended to be subtags of barrier=kerb. But it doesn't say
>> they shouldn't be, either.
>>
>> https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkerb
>> https://wiki.openstreetmap.org/wiki/Key:kerb
>>
>
> I am bit annoyed by barrier=kerb. kerb=lowered is perfect for me.
>
> The point is that a lot of software assumes barrier=* to be impassable
> as long as there are not other positive modality tags on it like
> bicycle/foot etc.
>
Such software will be confused by barrier=bollard and barrier=height_restrictor.
And some other values.

And for pedestrians by barrier=stile, barrier=kissing_gate, barrier=turnstile.
And some other values.

>  Which IMHO would be a perfect abstraction. A software
> which only want navigation only needs to check for barrier=something
> and then check modality. But instead we already overloaded
> barrier=bollard etc with implicit modality tags, and with barrier=kerb 
> we overloaded it again with kerb=* tags.
>
> So for barrier=kerb. Its a barrier for a lot of Software.
>
> For example OSRM treats it as a barrier, or better it did. For OSRM the
> barrier=kerb+kerb=lowered has been fixed for the car profile in March,
> but not so for bicycle and foot profile. So today we had a strange
> bicycle routing because of this on the regional mailinglist which
> was caused by a barrier=kerb + kerb lowered. All except one barrier=kerb 
> had been removed already so it was a hard find.
>
Adapting software will be likely easier than deprecating all barrier=* values
that are not completely blocking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210607/d2d723f7/attachment-0001.htm>