[Tagging] Feature Proposal - crossing=marked

[marc marc]

Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be 
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are 
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about 
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the 
crossing=zebra problems were not understood, the alternative has exactly 
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground? 
crossing=uncontrolled (the work is not perfect because a marking a kind 
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between 
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it 
with crossing=marked, which disrupts the information of the presence of 
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes 
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors, 
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc