[RFC] Feature Proposal - Deprecate crossing=zebra in favor of crossing:markings

In Nederland, an official zebra crossing includes a traffic sign L2, and the stripes can have prescribed size limits and colours. Colours? Yes, e.g. the zebra pattern can be brownish/reddish and whitish/greyish paving stones. But the pedestrian priority does not require the L2 sign, and if the sizes and colours do not fully meet the requirements exactly it’s still a pedestrian crossing with pedestrian priority.

So, crossing:markings is the tag to set; crossing_ref=zebra only adds that it meets the official requirements posed to the operator.

Sidebar:
Personally, I do not intend to check colours, size and signs for all crossings. We have a Dutch JOSM preset that sets the tag though, so I am sure that many mappers do set crossing_ref=zebra without checking. We will probably do a cleanup some time in the future, setting crossing_ref=zebra only when there is an L2 sign and removing it for all other zebra marked crossings. (We have an official source for the signage).

In the meantime, I have started to add crossing:markings=zebra to all zebra crossings, using a data source which used aerial imagery to detect zebra patterns. Lots of false positives and false negatives; still, I estimate that over 95% is actually a zebra-patterned crossing, and most of the false positives are recently removed or shifted zebra crossings, which can be verified by more recent imagery.

I am not yet removing crossing=zebra set by other mappers.

Looks like there is also at least one person that would oppose that, lmao:


Tripeling the amount in one day is impressive.

2 Likes

What you’re seeing might be the result of @Peter_Elderson’s edits across the Netherlands in a large number of local changesets over the span of some weeks or months. He doesn’t view it as shifting the tagging style, though the chart you pulled up might make it look that way:

True. I added many unmapped zebra’s, and initially took the simplest existing style. The idea was to map as many as I can first, and worry about the best tagging later. For already mapped zebra’s, the main concern was to add the zebra information as easy as possible, without losing other information. E.g. zebra’s tagged crossing=marked, I changed to crossing=zebra, which adds the word zebra as a more specific value for the marking. If I encountered crossing:markings=yes, I changed it to crossing:markings=zebra. When I encountered e.g. a series of zebras around a roundabout, typically mapped in different styles by different mappers, I selected all and added crossing_ref=zebra.
Now, I have changed my method a little, anticipating a systematic cleanup when we’re done adding the new zebras. I am no longer adding any crossing=zebra tags, so the quick rise has stopped.

4 Likes

after criticizing the iD maintainer for unilaterally introducing crossing=zebra many years ago, I subsequently have adopted this tag (because there were many of these by the time, and it actually worked for the situation here, “uncontrolled” always seemed ugly for markings controlled crossings), just in time that the said developer introduced a new tag again, “marked”, which I found to be too unspecific.

Can you explain why you are refraining now from adding crossing=zebra tags, although you described it as the simplest existing style that works to add the zebra information?

Another, mostly unrelated question: is there a way to map whether there are traffic signs at the crossing node?

I see crossing=zebra as the starting level mapping. For detailed mapping, markings, traffic control, islands and other details are tagged in secondary keys, making crossing=zebra redundant.
While adding zebras, I started to correct wrong mappings of crossings: bicycle crossings mapped as pedestrian crossings; crossings just mapped as highway=crossing which is totally useless; crossing=marked+crossing:markings=yes; that kind of nonsens…/ I mean, non-specific information. Crossing_ref=zebra was often not applicable. And, many existing zebras have been altered to pedestrian crossings with different markings.
So I have changed my method from simple tagging (adding crossing=zebra) to detailed tagging (adding crossing:markings=zebra|dots|dashes, crossing:signals=yes|no, crossing:island=yes)

Traffic signs: I tag crossing:signals=yes.

1 Like

There really should be. I’m surprised we haven’t established crossing:signed=yes/no alongside the several other *:signed=yes/no keys that are used in the thousands or tens of thousands. Maybe it’s because of an overreliance on an assumption that any signalized or marked crossing is signposted, but that isn’t necessarily the case everywhere. Or maybe some countries are content to imply signedness based on certain crossing_ref=* values, but this isn’t very transparent to data consumers. A few potential StreetComplete quests would be unwieldy and not as reliable because we aren’t tagging signedness. It’s possible to map the physical sign as a traffic_sign=* node, of course, but you can’t map the absence of one as a node.

1 Like

I see it the other way round, for a zebra crossing, crossing:markings=zebra is redundant. After all, “crossing” is supposed to be the main tag (after highway=crossing) to determine the type of crossing. Traffic islands are another, unrelated question and we have tags for it.

For traffic signal controlled crossings, crossing:markings=zebra / other could be seen as relevant (e.g. if you want to render detailed views, e.g. in 3D, it is interesting), although I don’t think it is very important compared to the fact there are traffic lights. Zebra markings on signal controlled crossings may occur in some places, in others they don’t exist, and I have seen not so rarely people adding zebra crossings where there actually were traffic signals, something we should raise awareness about.

I agree crossing:signed would be the expected tag. For the question of a sign requirement, in Italy signs are required only for pedestrian crossings that are distant from road crossings.

2 Likes

This is why I’ve been advocating for crossing:signals=* to go alongside crossing:markings=* (for signals, not signs). The specific configuration of an unmarked but signalized crossing is an important one that shouldn’t be conflated with other configurations just because it’s unheard of in Europe. In some countries, the markings are merely a matter of engineering judgment; motorists don’t notice pedestrians at an unmarked crossing like at a marked crossing. Elsewhere, this key still gives mappers the ability to distinguish unknown signalization, which prevents them from diluting information about configurations with known signalization.

I‘ve also drafted a proposal for more detail in countries where a Boolean value is inadequate, again because signalization is so important. If there aren’t dedicated pedestrian signals, then a motorist is even less likely to notice a crossing pedestrian as they make an unprotected turn.

Indeed, there are six reasons why longitudinal bar (“zebra”) markings may appear at a crosswalk in the U.S., and five of them are relevant to a signalized crosswalk. Some cities like New York install zebra markings exclusively, because their crosswalks are so busy and so wide that normal transverse lines would lose their visual meaning. Other cities only install zebra markings at signals when a younger, less traditional traffic engineer happens to be involved in the project.

These are all reasons to keep the tagging for markings, signs, and signals as distinct from each other as possible.

2 Likes

I agree, many agree, but there is no consensus nor dominant usage about what characteristic constitutes a main type. I think markings and control method are both secondary characteristics of crossings, and all combinations of markings and control are present IRL.

3 Likes