I have checked out your proposal...and I don't know what is the difference with a crossing=marked (yours) and a crossing=uncontrolled (in OSM) I don't agree with you. I think you are forgotten all the other items to tag and the others tagging schemes in OSM. Kerbs are not for cars, cycleways are not for cars. And there are other traffic lights rather than car traffic lights.
> It is also virtually impossible for any new user to know what tags to use and what they mean It is not true. There is a wiki and also a iD which can help to undesrtand the tagging scheme and making easier to tag that crossing. > This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra) What is the proposal: translate crossing=uncontrolled to crossing=marked? > Are you saying that all crossings with markings should be tagged, "uncontrolled"? If there is not any control of the crossing...yes otherwise should be crossing=traffic_signals or supervised=yes as you can read in the wiki. > Note that crossing=traffic_light does not imply whether there are markings on the ground Well, in my country it is, when there is a traffic signals with pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is crossing=no because there is no crossing at all. >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)? Change the questions: -Is there any traffic signal in the crossing? -Is there any supervision in the crossing? -Is there any mark in the crossing? A crossing=marked would not inform if it is supervised, and also if is there a pedestrian traffic signal controlled crossing. > However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes No , for a pedestrian way which passes inside an island I have footway=crossing because there si a footway inside a island. I don't need a tag which says things I can see in the situation for the map. It is the same reason I don't need crossing=marked if I have crossing=uncontrolled. Mark is not a control. > 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. Well, we have it and it is called crossing_ref. > I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list. I was talking about crossing=zebra issue. > Yes, and I've tried many, many times. Tell me one situation you cannot map in detail with present tagging scheme. This is my point of view. Health and maps (Salut i mapes) yopaseopor On Thu, May 9, 2019 at 5:50 PM Nick Bolten <nbol...@gmail.com> wrote: > > 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
