Drop default traffic_signals=signal for traffic_signals field

[burrscurr]

The traffic_signals field's default signal value should be dropped. The field is used in the traffic signal preset.

Reasoning

The current traffic_signals=signal default should be dropped because

• the initial rationale for setting the default seems to not apply anymore,
• the default provides almost no additional meaning over highway=traffic_signals,
• keeping the default makes traffic_signals=signal tags more difficult to interpret and
• using a subtype value as a default for a field is atypical anyway.

Initial rationale for default value does not apply anymore (?)

Originally, the field and preset for traffic signals were added in openstreetmap/iD@12409e4 in September 2015 and apparently have remained unchanged since then. This is quite a while ago, so it is tricky to find the original rationale for the default value. The earliest reference I could find is from 1.5 years later in openstreetmap/iD#3838 (comment):

I decided to set the field to default to signal because otherwise people would see that field and probably open a ticket to ask why they need to pick the signal type every time they map a traffic signal. (Really they don't strictly need to set a value, but it is difficult to explain conventions like this to OSM newcomers, and easy to just default things to fill in the 95% case for them).

As it seems, the main reason was to not confuse users by having a preset field without a default value -- maybe this was an issue back then? Today, this is quite normal and better solutions to avoid user confusion exist (e.g. adding labels to the raw values or hiding the field by default). (@bhousel feel free to comment if I'm misinterpreting something here)

In the years since then, there were some discussions (e.g. openstreetmap/iD#3838 and openstreetmap/iD#5016) about the preset and the default value in particular, however, without any changes.

traffic_signals=signal lacks distinction from highway=traffic_signals

Wiki highway=traffic_signal says:

Traffic signals [...] are signalling devices positioned at road intersections, pedestrian crossings and other locations to control competing flows of traffic

Wiki traffic_signals=signal describes a somewhat more concrete version of a traffic signal:

A standard traffic signal, typically with three steady aspects.

Moreover, it falls back to defining the tag via its use as a default in iD and recommends using other values to avoid repetition and even states that the value can be presumed in a traffic light:

This is the default value in iD for a traffic signal node. Since this kind of signal is assumed for highway=traffic_signals, please choose a more specific value for a more specialized signal.

While the signal definition is qualitatively less broad than highway=traffic_signals, there is very high overlap in tag use in practice.
98% of traffic_signals=signal have highway=traffic_signals tagged (see taginfo). In the opposite direction,
approximately 42% of highway=traffic_signalss also have a traffic_signals= tag. This lower value is expected since the traffic_signals key has been largely popularized by iD, which is also acknowledged in the wiki. To measure the impact of iD, it therefore makes sense to only look at the highway=traffic_signals with traffic_signal= (taginfo). Within this group, 83% of signals have traffic_signals=signal tagged. When Excluding traffic_signals=traffic_lights, which lacks clear definition in wiki and appears to be largely a synonym for highway=traffic_signals, this proportion raises to 93% (92.73% = 34.91% / (42.03% - 5.16%)). From these numbers it is clear that both tags are almost always used together.

Using a (common) subtype as a default undermines tag use

The traffic_signals= key is defined as a "subtype" key that describes the type and function of a traffic signal (highway=traffic_signals).

• the generic key is usually more broad, necessitating the need for a type subkey
• the type key is supposed to clearly answer which subtype is present
• if a subtype is used as default (even if it is the most common variant), this cannot be distinguished from a conscious use of the variant: in both cases, the known user input was to select the "traffic signal" preset
• data users cannot rely on traffic_signals=signal to actually describe a subtype (and not just a unintended default)
• mappers have limited interest in using a key that isn't useful to data users

In conclusion, using the subtype as default value undermines the purpose of the subtype tag, both for data consumers as well as mappers.

traffic_signals=signal is inconsistent with general use of default

I found 8 fields that currently define a default value:

field	default	uses in Presets
data/fields/building/part.json	building:part=yes	1
data/fields/building_area_yes.json	building=yes	129 (cafe, bank, office, ...)
data/fields/crossing/markings_yes.json	crossing:markings=yes	3 (uncontrolled crossing for road, pedestrian, cyclist)
data/fields/crossing/markings_yes-DE-AT-CH.json	crossing:markings=yes	1
data/fields/crossing/markings_yes-PL.json	crossing:markings=yes	1
data/fields/crossing/markings_yes-BG.json	crossing:markings=yes	1
data/fields/handrest.json	handrest=yes	1 (cycling waiting aid)
data/fields/intermittent_yes.json	intermittent=yes	1 (basin)
data/fields/traffic_signals.json	traffic_signals=signal	1 (just for Traffic Signal preset)

For instance with building=yes, this is a generic value that applies to every cafe, bank, office and so on. There is no interference with a specific subtype value like building=commercial or building=residential. Same goes for building:part=yes or crossing:markings=yes in their respective preset contexts. Using a subtype value like traffic_signals=signal is inconsistent with the other uses of default values in fields/presets.

Alternatives

Do nothing, keep default

• traffic_signals=signal remains difficult to use
• inconsistency for users of tagging schema remains: not all fields' default values do always apply (and there is no way to find out which ones do)

Clarify definition of "default" to also include "likely value"

• would technically resolve inconsistency issue, but only by broadening the definition (and thus limiting usefulness to tagging schema users)
• would require all users of tagging schema to stop applying field defaults for presets

[bhousel]

As it seems, the main reason was to not confuse users by having a preset field without a default value -- maybe this was an issue back then? Today, this is quite normal and better solutions to avoid user confusion exist (e.g. adding labels to the raw values or hiding the field by default). (@bhousel feel free to comment if I'm misinterpreting something here)

I thought it was pretty clear from all the various discussions over the years that you linked to, but I'll recap:

• We wanted to give users a field to specify what "type" the signal is.
• Most users would see a type field like that and try to fill it with a value - most users would assume that leaving it empty means "unspecified". (Does every other "type" field work this way? maybe).
• The signal value was already listed on the wiki in 2015 and in use.
• Even though the wiki has since been changed to make signal the same as "no value", having that tag causes no problems for anyone, and it saves us from having to field questions from users who think they need to set the signal type to something.

Hope that helps.

[burrscurr]

Thank you for the reply. I understand the intention to allow users to specify the signal type – I don't see a problem in that on its own. However, due to traffic_signals=signal being the default in the tagging schema, the usefulness of the key to data consumers is pretty limited and very close to what could be guessed based on highway=traffic_signals node. That's why i think that the default itself is problematic, not that iD popularized the key.

If an empty type field is confusing to users (I'm not sure whether that's actually the case), it might also be worth considering making traffic_signals a more field in the traffic signal preset.