Transportation: add filter to reject unsigned routes

[Blijbol]

This is my suggested fix for issue #1613. It discards transportation routes tagged with unsigned=yes.

The code is inspired by the already-existing filtering of water polygons with covered=yes in the water layer.

Disclaimer: I have no experience with this code repository and have not tested this.

[ZeLonewolf]

In principle, this change is fine, but ref + unsigned=yes is an obscure combination that, according to taginfo, only occurs in 189 (now 188) cases. The more typical method of signing unsigned routes is to use unsigned_ref, which has over 258,000 usages.

Source:
https://taginfo.openstreetmap.org/keys/unsigned#combinations
https://taginfo.openstreetmap.org/keys/unsigned_ref#overview

The case that you found in Michigan, I would regard as a tagging error and I've corrected it to use unsigned_ref, as is the norm in the United States. I would suggest changing the tagging on the 188 instances of ref + unsigned=yes would be a better course of action rather than encouraging a duplicate tagging system to arise via schema usage.

[1ec5]

For context, a route can be signposted independently of its number (ref). For example, this route is conspicuously signposted with signs that indicate the route’s name but not its number. Its number exists only for internal inventory purposes, but that number is tagged as unsigned_ref so that someone won’t come along, think it’s missing, and add it as ref. Conversely, there are routes marked by signs that only mention their numbers rather than their names.

unsigned=no is documented as applying to the feature’s name, not its number. If you encounter a relation that uses this tag to indicate that only the number is unsigned, unsigned_ref or ref:signed=no would be better alternatives, depending on how certain you are that the route has no signs anywhere.

[reventlov123]

I've edited https://wiki.openstreetmap.org/wiki/Key:unsigned to attempt to make the situation more clear. "unsigned" would imply that a feature has no on-the-ground signage at all. "unsigned_ref" implies that the feature does actually have on-the-ground signage, but that the signs don't display the particular legal designation.

[1ec5]

Even so, the fact that this key originally only pertained to the name (in the context of bus stops) means that data consumers need to be careful interpreting it to mean anything other than an unsigned name, depending on how lenient or strict the use case needs to be. OpenMapTiles may get away with hiding these features out of an abundance of caution, but redefining the key (even in a very sensible manner) probably deserves at least a brief discussion in the OSM community beyond this relatively obscure PR.

[Blijbol]

In principle, this change is fine, but ref + unsigned=yes is an obscure combination that, according to taginfo, only occurs in 189 (now 188) cases. The more typical method of signing unsigned routes is to use unsigned_ref, which has over 258,000 usages.

Many of those tag uses are ways instead of relations. For the actual usage on route relations, the current counts are 36 versus 2560.

Anyway, the point is not to abandon all existing uses of unsigned_ref, but to allow a more nuanced tagging where appropriate.

For example, replacing ref=* with unsigned_ref=* on the route relation is problematic if the ref=* is actually important for identifying the unsigned route (e.g. unsigned E-roads). It e.g. breaks the labelling of the relation based on ref=* on the OpenStreetMap website and in the JOSM editor.

unsigned=no is documented as applying to the feature’s name, not its number. If you encounter a relation that uses this tag to indicate that only the number is unsigned, unsigned_ref or ref:signed=no would be better alternatives, depending on how certain you are that the route has no signs anywhere.

"unsigned" would imply that a feature has no on-the-ground signage at all. "unsigned_ref" implies that the feature does actually have on-the-ground signage, but that the signs don't display the particular legal designation.

This is more or less my idea. I'd say unsigned=yes indicates the route relation is entirely unsigned, unsigned=name or name:signed=no indicates the name is unsigned, unsigned=ref or ref:signed=no indicates the reference is unsigned.

One could consider a follow-up PR to ignore the ref=* in case unsigned=ref or ref:signed=no is present (similar to how unsigned_ref=* is currently ignored), but this probably requires a somewhat more advanced code change.

[ZeLonewolf]

For example, replacing ref=* with unsigned_ref=* on the route relation is problematic if the ref=* is actually important for identifying the unsigned route (e.g. unsigned E-roads). It e.g. breaks the labelling of the relation based on ref=* on the OpenStreetMap website and in the JOSM editor.

This does not seem to be a problem in practice. In the UK, where E-roads are unsigned, unsigned_ref doesn't seem to break things:

https://www.openstreetmap.org/relation/6246893

[1ec5]

It e.g. breaks the labelling of the relation based on ref=* on the OpenStreetMap website and in the JOSM editor.

I hadn’t thought of that. We should probably make sure that all the editors and the website fall back to unsigned_ref for the purpose of relation labels in non-map UI elements, regardless of what OMT does about unsigned.

The E15 example “works” because of a name that is kind of questionable.

[pnorman]

Quoting from trolltag,

It is not OK to use one tag and add second tag that negates or massively change its meaning. Additional tags should clarify meaning of main tags rather than negate it.

In general, any tag that must be processed to avoid serious misinterpretation of the feature is a trolltag.

This is an excellent example of such a tag. unsigned=yes goes against the common understanding of ref, and we already have a standard tag for unsigned refs. Quoting from the ref page,

unsigned_ref=* - reference number or code that is generally not signed on the route