crossing:markings isn't automatically set when a crossing is created

[reschultzed]

URL

No response

How to reproduce the issue?

1. Draw a way across a road and tag it as crossing=unmarked or crossing=marked
2. As expected, an issue will pop up saying that the two ways should intersect or be layer-separated
3. Select "Connect the features"
4. The crossing node that is created will have a new issue, saying that the feature has incomplete tags and should be upgraded with crossing:markings=no or crossing:markings=yes. If this tag is needed, it should be automatically added to the node upon creation. As it currently stands, the issue needs to be resolved individually and repeatedly by the user

Screenshot(s) or anything else?

No response

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.25.1

Which browsers are you seeing this problem on?

Firefox

[LucasBrandt]

If a way with crossing=marked already has a value for crossing:markings like crossing:markings=zebra, should the new crossing node use that value when created with "Connect the features", rather than using crossing:markings=yes?

Extending that question beyond the specific purpose of this issue, I wonder if any problems would arise from also inferring crossing:island and/or tactile_paving from the way as well. This would avoid editors having to set those values twice - for the way and the node (as long as an editor sets those tags before connecting the ways). This would be similar to the change made in https://github.com/openstreetmap/iD/pull/9181 to infer the crossing value from the way, and would save me personally a good amount of time. I'd be happy to open a separate issue for this question if that would be better.

[1ec5]

If a way with crossing=marked already has a value for crossing:markings like crossing:markings=zebra, should the new crossing node use that value when created with "Connect the features", rather than using crossing:markings=yes?

Yes, that would make a lot of sense. There would be no point for crossing:markings to differ between the way and node representations of the same crossing.

tactile_paving could be trickier, specifically in the case where there’s tactile paving on one end of the crosswalk but not the other. Not sure whether yes or no would be entirely correct in that situation, which is unfortunately pretty commonplace where I map.

[LucasBrandt]

tactile_paving could be trickier, specifically in the case where there’s tactile paving on one end of the crosswalk but not the other. Not sure whether yes or no would be entirely correct in that situation, which is unfortunately pretty commonplace where I map.

Thanks. I've reviewed the documentation for tactile_paving and now realize that it has a different meaning for crossing ways (user can follow along the way) vs crossing nodes (user can detect the feature). So I agree tactile_paving should not be inferred from the way when connecting, and I now also realize I have unfortunately mapped a lot of crossing ways as having tactile paving when I shouldn't have due to misinterpreting the in-editor instructions (😭)

Reviewing the documentation for crossing:island, I do think that tag could be inferred correctly from the way when creating a crossing node, and doing so would be a nice convenience.

[TheAdventurer64]

I'm having the same issue with crossing tags. If you add a bunch of tags to a crossing way and connect them to a street via nodes, the tags won't convert over.

[NebSgird]

I'm still having this issue. #9573 didn't seem to resolve.

[jdhoek]

#9922 was closed as a duplicate of this issue, but is it really a duplicate?

In the past months I've seen mappers 'fix' hundreds of crossing=unmarked crossings by automatically adding crossing:markings=no because ID raises a warning, but doesn't crossing=unmarked already imply crossing:markings=no? Adding crossing:markings=no isn't wrong, but neither does it seem necessary or an improvement.

[1ec5]

Yes, #9922 is a duplicate of this issue, but I think you’re commenting on something slightly different. openstreetmap/id-tagging-schema#590 added crossing:markings to the existing crossing presets, and there has been some discussion to the effect of eventually someday deemphasizing the overloaded crossing=* key in favor of crossing:*=* and crossing_ref=* depending on the situation. There’s also a cluster of recent forum discussions about the future of other values of crossing=*.

[jdhoek]

@1ec5

someday […] some discussion […] eventually […]

I'm not seeing a proposal to deprecate crossing=* on the wiki now (is there?), and on the tagging-ML there is talk of deprecating crossing=zebra in favour of crossing=uncontrolled. So crossing=* isn't going anywhere is it?

crossing=unmarked implies crossing:markings=no. It's fine that ID adds the latter via its preset, but the warning that a crossing=unmarked without crossing:markings=no has incomplete tags is not correct:

It's a bit pushy to be honest, and it is leading to armchair mappers happily amending hundreds of crossing=unmarked for no tangible benefit other than to boost crossing:markings. This warning has merit if crossing=* is being phased out, but that's not now I think, and still a big if.

[1ec5]

I'm not seeing a proposal to deprecate crossing=* on the wiki now (is there?), and on the tagging-ML there is talk of deprecating crossing=zebra in favour of crossing=uncontrolled. So crossing=* isn't going anywhere is it?

I linked to the iD community call that took place some months back. (I wasn’t able to attend due to a conflict; I’m just going off notes.) To my knowledge, there’s no active proposal to deprecate all of crossing=*. This 2022 proposal to deprecate crossing=* has been on hold because it was premature: crossing:signals=* hadn’t become de facto yet, and some folks wanted to chip away at the problem piecemeal instead, starting with crossing=zebra. That proposal is using crossing=uncontrolled as a stopgap, but the intent there is clearly to prioritize crossing:markings=*.

[tordans]

@jdhoek I reworked the crossing presets in https://github.com/openstreetmap/id-tagging-schema/pull/1201#issuecomment-2075548508 which is in review to be merged – hopefully soon. Would be great if you could have a look if that setup resolves the issues you mentioned.

[jdhoek]

@tordans In the linked preview I still see these raised for existing crossing=unmarked lacking crossing:markings:

I can get behind a warning for cases where crossing=unmarked has a crossing:markings-field with any value but no, but a simple node like this:

highway=crossing
crossing=unmarked

…implies crossing:markings=no. It is fine for a preset to add both tags to a new crossing (although I wouldn't), but the warning if crossing:markings=no is not there invites warning-solving edits without much value (someone just added crossing:markings=no to dozens of crossing=unmarked in my town.

[Dimitar5555]

We got rid of the crossing=marked presets (https://github.com/openstreetmap/id-tagging-schema/pull/590). Maybe it's time to change the "Unmarked crossing" presets to use crossing=uncontrolled + crossing:markings=no instead of crossing=unmarked.

[bhousel]

Be careful what you wish for.

A “controlled” crossing is one where pedestrians have priority and vehicles must yield to them.
An “uncontrolled” crossing is one where pedestrians don’t have priority and must wait for vehicles.

If the OSM crossing tags are defined somehow that conflicts with what I wrote above, data consumers working on pedestrian accessibility will not be able to use OSM. (This is why the unambiguous marked and unmarked values are preferred).

[Dimitar5555]

On the other side of the big lake "controlled" is crossing=traffic_signals and "uncontrolled" is everything without traffic signals. Pedestrians have priority over non-rail vehicles on both types of crossings (which doesn't make them immortal of course).

The markings aspect is already tracked in crossing:markings so it seems to me that we can safely drop unmarked and let crossing=* define whether there are traffic lights or not. That way we can also "save" on yet another tag - crossing:signals.

It should be trivial for data consumers to change a few rules and remove a dozen other rules in X time (when the values have been cleaned). Even more trivial step would be to preprocess the data using whatever tags they like.

Since the PR I mentioned, crossing=marked has been mostly stagnant with a few slight drops, while crossing=uncontrolled has been growing since 2008 without any stagnation. It seems like the second option is the proffered one.

[1ec5]

On the other side of the big lake "controlled" is crossing=traffic_signals and "uncontrolled" is everything without traffic signals.

I guess you’re referring to British English, but actually this is a point of agreement between American and British English: markings are a form of traffic control at a controlled pedestrian crossing. The definition of “uncontrolled” you’re using is an OSMism from the 2008 crossing_ref=* proposal – or at least what’s left of it after the 2011 sidewalk proposal split off crossing=unmarked.

Your suggestion would effectively roll back that part of the approved proposal, even though it won stronger support than the proposal that originally formalized crossing=uncontrolled. I’m not sure that would be any cleaner than it would be to migrate to a combination of crossing_ref=*, crossing:markings=*, and crossing:signals=*. In any case, the forum would be a better place to get the community on board with something like that.

By the way, the expansive 2008 definition of crossing=uncontrolled also influenced how railway level crossings without barriers and signals were originally tagged as level_crossing=uncontrolled. (Markings are mostly irrelevant at level crossings.) Nowadays that’s deprecated in favor of crossing:barrier=no and crossing:light=no.