Proposal talk:Highway crossing cleanup

Zebras

First of all, I wholeheartedly support the deprecation of crossing=zebra. This will finally enable us to tag zebra crossings.

Zebra crossing

 – Minh Nguyễn ^💬 20:01, 7 November 2022 (UTC)

I don't support the deprecation. No problem with crossing=zebra around here. Why should we need 3 tags to express the same thing that we can do now with just one tag? Mapper's time is precious and tags that express the thing with 1 word are usually safer than combinations, which tend to only get partially modified when something changes. The more tags there are, the less they will be checked by follow mappers, and it becomes easier to not spot mistakes, so this is not just about "laziness". --Dieterdreist (talk) 12:59, 28 November 2022 (UTC)

When you say "Why should we need 3 tags to express the same thing that we can do now with just one tag?", that's the very problem of the current approach. One tag cannot encompass a multitude of properties, as evidenced by the problems with the current values of crossing=*. In certain countries crossing=zebra might work fine, but this is a global project where the tagging should be simple enough to be understood, but complex enough to describe various situations with reducing everything to a single tag. In the case of crossing=zebra there is also crossing_ref=zebra which can be used. Regarding multiple tags being more prone to errors than a single tag, that's not really true. Multiple tags make it easier to add details where having just one tag would result in changing the only value indicataing a certain feature to something erroneous. A proper editor will help the mapper in ensuring the tags are up to date. --Riiga (talk) 13:52, 28 November 2022 (UTC)

If crossing=zebra is not sufficient, you can add more tags or use a different scheme, I do not say it must be sufficient for everybody, I said just because we now have these marvelous possibilities to distinguish individual aspects of pedestrian crossings, does not mean we have to use it when it is not required. No need to deprecate one tag because you now have confirmation for 3 others. Regarding "A proper editor will help the mapper in ensuring the tags are up to date" I hope you did not intend this to be a menace, the "update tags" "feature" that the iD-Editor has implemented is a contested by quite some mappers.--Dieterdreist (talk) 13:58, 28 November 2022 (UTC)

Indeed, I dislike that "feature" of iD and much prefer JOSM where the validator will give you a notice about deprecated tagging and a suitable replacement, and only on objects you've touched. --Riiga (talk) 19:18, 28 November 2022 (UTC)

@Riiga: Not sure what you mean. By default, iD only tells you about deprecated tagging after you select a feature and only counts it as an ignored warning if you click "Ignore warning" or touch a feature without addressing the deprecation. There used to be a feature that would let you automatically fix deprecations en masse, but it was removed due to controversy. To the extent that mappers still contest this feature, it's usually because of a particular deprecation they disagree with, like waterway=riverbank to natural=water water=river. – Minh Nguyễn ^💬 22:30, 28 November 2022 (UTC)

@Dieterdreist: This argument about the inconvenience of multiple tags could be levied at a number of features we take for granted, such as level crossings (which in many countries are uniformly signposted and signalized). Mappers’ time is so precious that every self-respecting editor has some kind of support for presets. Hopefully most mappers are in the habit of using presets already. If not, maybe we should explore abbreviating more keys along the lines of ele=*, to minimize keystrokes. – Minh Nguyễn ^💬 16:21, 28 November 2022 (UTC)

to me it seems a new highway=bus_stop case is created: why use one tag on a node if you can roughly give the same information also with a platform area plus a stop position on the road to put into the relation plus additional tags so the feature isn’t confused with a tram stop or train station.—Dieterdreist (talk) 23:34, 28 November 2022 (UTC)

@Dieterdreist: I didn't think this proposal was cleaning up crossing tagging by requiring crossing ways and crossing areas, but maybe I misread it? – Minh Nguyễn ^💬 11:30, 29 November 2022 (UTC)

It proposes a complicated and incomplete scheme, also for basic situations, to replace simple and concise tagging, and in the end you don’t even know who has the right of way. —-Dieterdreist (talk) 21:02, 29 November 2022 (UTC)

@Dieterdreist: I disagree that the proposed tagging erases information about right of way versus crossing=zebra. You've helped demonstrate in this mailing list thread that a data consumer can't reliably infer anything more than markedness from the tag on a global scale, leaving it tantamount to crossing=marked. Sure, a data consumer could apply country-specific heuristics to infer more characteristics like right of way from crossing=zebra, but they could just as well do that from crossing_ref=zebra, crossing:signals=yes, etc. So the argument here really boils down to concision. I simply come to a different conclusion about trading off convenience in one country for the possibility to fully describe crosswalks in another country. – Minh Nguyễn ^💬 09:34, 30 November 2022 (UTC)

Around here, crossing=zebra means it is a crossing controlled by a zebra crossing, and crossing_ref=zebra according to whom I asked said it was about the presence of zebra markings. The latter may be interesting to some, but for many people, the kind of crossing is far more relevant, as zebra markings can be present also on crossing=traffic_signals. The zebra marking alone doesn't make a crossing a zebra crossing, it also has to have zebra crossing traffic signs or be in proximity to an intersection (all referring to local law, not globally valid, obviously). --Dieterdreist (talk) 13:40, 30 November 2022 (UTC)

> Why should we need 3 tags to express the same thing that we can do now with just one tag?
For the same reason why we don't use e.g. `highway=paved_lit_oneway_4_m_private_50_mph_residential`: orthogonality. Different properties that are independent of each other should not be lumped into the same tag. If these properties can occur in any combination, we'd need a tag value representing each of these combinations in order to have a complete tagging schema. Each of these combination values would have to be specifically supported by data consumers. Now suppose we want to add a new property. If everything was lumped into one tag, we'd have to invent new values for every possible combination of the values for the old properties and the new property. All data consumers (and editors) would have to add support for these new values if they want to keep working properly, even if they are only interested in one of the old existing properties.
If the properties were tagged using different orthogonal keys, this would be a non-issue. Data consumers/editors would keep working properly as the use of the new key doesn't influence interpretation of existing properties. When the new property becomes accepted and used, support can be gradually implemented when required. Orthogonal tagging schemes are extensible and allow for easier changes. Not to mention that interpretation of orthogonal tagging schemes is also a lot easier compared to when everything is lumped together.
Now all of this assumes that the combined and lumped-together tagging scheme is complete and non-ambiguous, which is unlikely in the best of cases. If it isn't, good luck with the resulting mess...
> tags that express the thing with 1 word are usually safer than combinations,
I highly doubt that. If that 'word' has a clear and specific meaning everywhere and there is no ambiguity then maybe yes that would be true. This is clearly not the case here. `crossing=zebra` is very poorly defined and ambiguous. (e.g. does crossing=zebra imply that there are traffic signals?) Why should data consumers choose to support this one specific ill defined exception if it could easily be expressed by the general tagging scheme? As it is, `crossing=zebra` doesn't actually mean more than "there are zebra markings". Mappers can just as easily add that information using `crossing:markings=zebra` in the same amount of time. The time that mappers spend is useless if they don't actually add anything of value in that time. Woazboat (talk) 20:03, 6 January 2023 (UTC)

"Uncontrolled" and comparison

This term is proven ambiguous even in technical text. In my view, it should not be synonymous with "unsignalized". Somehow the newer junction=uncontrolled doesn't have the problem of crossing=uncontrolled in referring to the lack of any traffic control from priority control by give-way and stop.

My solution in Proposed_features/Crosswalk_clean-up#Traffic_control is crossing:priority=uncontrolled, further allowing the crossing:priority=*way emerged in https://lists.openstreetmap.org/pipermail/talk-gb/2022-August/029307.html for a simple tagging on which side has the priority (without needing highway=give_way / highway=stop or Proposed features/Relation:type=stop etc). This attempts to improve upon Proposed features/crossing=priority, where crossing=prioirty didn't get enough traction. Similarly crossing=traffic_signals is clarified in crossing:traffic_signals=* (crossing:signals=* not adopted at the moment due to existing unclear usage, although may change depending on how applicable traffic_signals=* val-s are), enabling pedestrian or vehicle only signals to be shown. crossing=* will then be reserved for other attributes, including the consideration of how to show the absence vs legality of crossing currently mixed up in crossing=no. Another issue in sight is "informal" de facto crosswalks without any facilities formed at any street corner, needed to be distinguished from the crossing=uncontrolled or crossing=unmarked now.

--- Kovposch (talk) 20:51, 7 November 2022 (UTC)

@Kovposch: As far as I'm aware, the term "uncontrolled" isn't necessarily ambiguous in the real world, but it is orthogonal to crossing=uncontrolled, creating a lot of confusion and inconsistency over the years. To make matters worse, the British English definition is completely unrelated to the American English definition. Please correct me if I'm wrong, but my understanding is that British English uses "uncontrolled" to mean that pedestrians do not have priority over vehicular traffic. From an engineering standpoint, it is only distinguished as a crossing because of a refuge island. [1][2][3] Meanwhile, in American English, "uncontrolled" means there's no traffic control device, such as a stop sign or traffic light, to keep vehicular traffic from running over pedestrians. However, pedestrians by definition have a legal right of way at uncontrolled crossings. [4]

Regardless of what was going through the minds of crossing=uncontrolled's proposer, the fact is that people have been using this tag based on their dialect's definition of "uncontrolled" for years. The tag's actual usage is already too polluted for data consumers to reliably impart much meaning from it. Conflating crossing=marked and crossing=unmarked with it would only make matters worse. We would have a similar struggle with service=driveway in the U.S., except that lay Americans are well aware of the stricter definition of "driveway" that happens to be present in British English and OSM English.

 – Minh Nguyễn ^💬 07:36, 8 November 2022 (UTC)

Resolved: Scope of proposal has changed

Lossy deprecation

This proposal would deprecate both crossing=marked and crossing=unmarked in favor of crossing=uncontrolled, but it contradicts this change by endorsing crossing=traffic_signals. An unknown but significant number of crossing=marked and crossing=unmarked represent signalized crossings, partly because of a historical lack of crossing=traffic_signals presets in some editors and partly because of the orthogonal nature of these tags: in lay terms, a crossing remains "marked" or "unmarked" even if it is signalized. Unconditionally migrating these tags to crossing=uncontrolled would affirm that these crossings are not signalized when we don't know that for a fact. There is a potential for dataloss on a large scale, affecting any router that considers signalization for timing or safety. Yet choosing between crossing=uncontrolled and crossing=traffic_signals would require street-level imagery in many parts of the world where 3-inch (76 mm) aerial imagery is not yet available or where the signals are obscured by tree cover or building shadows. If this proposal must deprecate crossing=marked and crossing=unmarked, then it would be prudent to deprecate them in favor of crossing:markings=* with no crossing=* at all. – Minh Nguyễn ^💬 06:58, 8 November 2022 (UTC)

That's the other option I'm considering, getting rid of crossing=* altogether (except for crossing=no maybe?) --Riiga (talk) 07:15, 8 November 2022 (UTC)

@Riiga: Getting rid of crossing=* altogether, in every case, would require crossing:signals=* or something along these lines to account for crossing=traffic_signals. I had been planning to formally repropose crossing:signals=*, not only to supplant crossing=traffic_signals but also to distinguish between crossings where pedestrians obey the main vehicular signal (perhaps crossing:signals=shared) versus those where they obey a dedicated pedestrian signal face (separate). [5]

crossing=no has always been an oddball since crossing=yes has never been an option. Theoretically, it could be expressed as not:highway=crossing, but I don't know if that's super important. If we were to make such a change, it would be nice to take care of it in the same pass as other crossing refactoring.

 – Minh Nguyễn ^💬 07:50, 8 November 2022 (UTC)

@Riiga: I drafted User:Minh Nguyen/Crossing signalization with an expanded scheme for crossing:signals=*, both to give the proposal a stronger rationale and to scratch an itch of mine around signal heads. Do you think it would be better to propose this key on its own or as part of your proposal? – Minh Nguyễn ^💬 05:54, 16 November 2022 (UTC)

I support your proposal, but would like to also deprecate crossing=* as it is no longer necessary. Some internationalisation could be good in your proposal, I'll see if I can help out. Maybe also move it to the proposed features space? --Riiga (talk) 16:32, 17 November 2022 (UTC)

@Riiga: Sure thing, I moved it to Proposed features/Crossing signalization. For now, I left crossing=* deprecation out of my proposal in case you wanted to handle that in your proposal, but I'm open to expanding the scope to include deprecation. It'll probably be a higher hurdle to clear, because crossing=uncontrolled and even crossing=zebra have strong adherents. I'd welcome your help in internationalizing this proposal, since I'm coming from a strong MUTCD bias; all I know about Vienna Convention countries is what I've learned from OSM so far. It does seem like the shared situation is more official in MUTCD-influenced countries, but let's discuss further on the proposal's talk page. – Minh Nguyễn ^💬 18:19, 17 November 2022 (UTC)

I changed the scope of the proposal to approve crossing:signals=* as is and also deprecate crossing=*. --Riiga (talk) 11:44, 28 November 2022 (UTC)

Approving crossing:signals=yes doesn't offer a substantial improvment over crossing=traffic_signals. It needs to be accompanied by the signalization as raised in the other proposals to work. --- Kovposch (talk) 12:15, 28 November 2022 (UTC)

Resolved: Scope of proposal has changed

The migration table still ignores the fact that most occurrences of crossing=marked and crossing=unmarked were tagged without any consideration for whether they were signalized. Some editors did not tie the two concepts together for years, and neither did the wiki for a time. Therefore, we cannot infer crossing:signals=no. In some countries, we can infer crossing:signals=no from crossing=unmarked, but that’s the extent of it. – Minh Nguyễn ^💬 16:02, 28 November 2022 (UTC)

Thanks, I will change it. --Riiga (talk) 19:19, 28 November 2022 (UTC)

crossing=marked should indeed be deprecated, it encourages mappers to use tags with clearer meaning.—Dieterdreist (talk) 20:08, 28 November 2022 (UTC)

Resolved

Return to complete older scheme

I don't know why we need a new scheme for crossing, with the same paramaters. Crossing and crossing:ref was one of the most complete and easiest schemes for highway items in OSM. Then people from iD invented crossing=marked and the logic and the completeness of scheme went to hell. Now we have a new scheme. Ok, but What about when other software will tag in a wrong way using the new scheme? Please

1. return to the old complete scheme (nor the iD modifications)
2. complete the existing crossings with review tags to assure the crossing is complete.
3. if we need a new scheme tell me new information you will be able to afford with the new scheme that you can't afford with the old.
4. signals? what signals? Traffic signs? Traffic lights? Street lamps?
5. marks? what marks?

--Yopaseopor (talk) 16:18, 4 December 2022 (UTC)

The old scheme was neither complete nor easy. It conflated different concepts, and was misused constantly because people misunderstood what things meant and because some terms mean different things in different countries. `crossing_ref=*` might be useful and have specific meaning in the UK where it was invented, but it's mostly useless in other countries.
> signals? what signals? Traffic signs? Traffic lights? Street lamps?
> marks? what marks?
Have you actually read the documentation for the proposed new tags? From your comment I'd have to assume no.
https://wiki.openstreetmap.org/wiki/Key:crossing:markings
https://wiki.openstreetmap.org/wiki/Key:crossing:signals Woazboat (talk) 19:09, 6 January 2023 (UTC)

Resolved: Returning to the old scheme was my first propsal before I changed the scope. That's not going to happen now in this proposal.

Looks good, no comments

Makes sense to put **potentially** separate data into separate tags. Makes even more sense to clean up the mess created by having two to three non-deprecated tag values (marked, uncontrolled, zebra) to mean probably? the same? thing. --Westnordost (talk) 21:05, 10 December 2022 (UTC)

Looks good, but it might be clearer.

@Riiga: I usually support more general and more fine-grained tagging, and this proposal has potential, as it tries to separate different features into separate tags. But I do have some remarks.

1. It would be better if it was explicitly specified that crossing:markings is the correct place to tag the way crossing is marked (e.g. crossing:markings=zebra), not only in examples
2. I think it should be specified that access is tagged by general access tags like bicycle=yes (just as it was specified in earlier proposals). As it is now, it can only be deducted from examples.
3. I suggest to clearly note that crossing_ref is only used in some countries. With a link to Key:crossing_ref.

Rmikke (talk) 23:39, 2 January 2023 (UTC)

Resolved: Updated with changes

Solution appreciated

In 2008 I dreamed of a cleaner alternative to crossing_ref=zebra, never getting a firm grip on pelican, twocan & Co. I see discussion are already going for long, just no final solution. Given an appealing and winning proposal doesn't change the (OSM) world data instantly, I hope to see progress. We must have it before more common and people getting too familiar to change away from this known ambiguous and rather inflexible tagging schemes. --Hasienda (talk) 19:34, 10 April 2024 (UTC)