> I don't know why we need a new tag scheme. Please check out my proposal, as I've laid out several reasons. As someone who has personally mapped thousands of crossings, the current schema is absolute garbage for reliably collecting accurate data that can be reliably interpreted by data consumers that aren't solely focused on car routing. It is also virtually impossible for any new user to know what tags to use and what they mean. You can see in this thread as well as the one in my other proposal regarding signals that even veteran, expert OSM users have different ideas on what "crossing=uncontrolled" means.
> 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.) This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra). > crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled I don't understand what you mean by "so one of them implies crossing=uncontrolled"? Are you saying that all crossings with markings should be tagged, "uncontrolled"? What if they have pedestrian signal lights? That's a crossing that has both, implying a contradiction. Note that crossing=traffic_light does not imply whether there are markings on the ground. That's the whole problem: these tags cover information regarding at least 3 discrete categories of information, but do not themselves contain the full gamut of combinations nor even all 3 in every value: (1) markings on the ground, (2) the "controlled" status, and (3) the existence of a pedestrian signal. These should be separate questions a mapper can easily answer: does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)? > 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 . Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag. The two proposals I've announced are related to breaking out these non-orthogonal crossings tags, similar to crossing=island. However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes. > And then there are the crossing_ref This is outside the scope of this proposal, aside from the fact that if crossing=marked is used, it creates an opportunity to use a straightforward subtag for different marking types that are currently tagged as crossing_ref. Try explaining to virtually anyone why the crossing type is called, "crossing_ref". What's a ref? What does it mean to apply a ref to a crossing? With that said, this proposal does not hinge on this, it's just an opportunity for a different proposal down the line. > But there is no crossing=zebra or crossing=marked. I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings. > I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems. I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list. > Are you sure we need a new tagging scheme for crossings? I am absolutely positive. > Are you sure there is not other existing way to map whatever you want with the present tagging scheme? Yes, and I've tried many, many times. Best, Nick On Wed, May 8, 2019 at 10:38 AM yo paseopor <yopaseo...@gmail.com> wrote: > 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_...@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@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
