[Tagging] Feature Proposal - RFC - crossing:markings

[Alexander Kane]

I tweaked the values for the "compound" keys:
crossing:markings=paired_zebra is now crossing:markings=zebra:paired for
example (I took inspiration from surface=concrete:lanes) Simple values like
crossing:markings=zebra are unaffected.

Although namspacing in values is somewhat uncommon, this should streamline
the creation of new values as well as making the interpretation of these
values trivial via regex.

Alex

Alexander Kane <1998alexkane at gmail.com> schrieb am So., 24. Juli 2022,
12:12:

> I'll remove the deprecation part of the proposal.
>
> Regardless, I think that if we provide an unambiguous way to tag the
> markings, people will use it rather than crossing_ref in this sense anyway,
> but perhaps that is overly optimistic :D
>
> Alex
>
> Am So., 24. Juli 2022 um 10:37 Uhr schrieb Mateusz Konieczny via Tagging <
> tagging at openstreetmap.org>:
>
>>
>>
>>
>> Jul 23, 2022, 12:45 by 1998alexkane at gmail.com:
>>
>> I updated the proposal saying that using crossing_ref to describe
>> pavement markings should be depricated.
>>
>> Is it really fundamentally needed?
>>
>> Note that as you bundle A, B, C, D in one proposals then someone opposing
>> any of that will vote against.
>>
>> So bundling multiple changes increases opposition.
>>
>> The biggest effect of this is that crossing_ref=zebra should be reverted
>> to its original definition.
>>
>> Maybe it is useful, but can it be done separately?
>>
>> Crossing_ref certainly needs an overhaul imo (maybe something like
>> crossing:designation=GB:zebra or the like) but this would probably be best
>> as a separate proposal.
>>
>> +1
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220726/185f5b05/attachment.htm>