[Tagging] Feature Proposal - crossing=marked

[yo paseopor]

I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the
possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies
crossing=controlled.
crossing=controlled is with traffic signs or with police people or similar
(it does not matter the marks because of the laws. Traffic signs are more
important than road marks, and, in conflict you have to obey the traffic
sign not the road mark.)
crossing=uncontrolled but with marks. So one of them implies
crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag
traffic_calming=island (you can read in the wiki crossing=island is a  broken
tagging scheme .

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other
value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of
panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but
doing whatever you want avoiding community consensus can generate these
problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there
is not other existing way to map whatever you want with the present tagging
scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc <marc_marc_irc at hotmail.com> wrote:

> 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
> _______________________________________________
> 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/20190508/293dcde8/attachment.html>