Some keys serve a different purpose or have a different data type depending on the primary tag of the element. In other cases, a homonymous key may have different semantics when tagged on a node versus a way. These conflicts often arise when "iterative refinement" tagging schemes use words that have homonyms in the English language.
List of homonymous keys
|This article is a stub. You can help OpenStreetMap by expanding it.|
Homonyms in English
- subject=*, subject:wikidata=*
Refining the feature versus something tangential to it
Containment versus refinement
- when used as a primary feature tag – the kind of public safety feature
- when used with highway=* – whether emergency vehicles are allowed
- when used as a primary feature tag – whether two or more ways form a junction at the node
- when used with highway=* – the kind of junction
- when used as a primary feature tag – the kind of kerb
- when used with crossing=* – whether there is a kerb at either end of the crossing
- when used with highway=mini_roundabout – the direction of rotation
- when used with highway=stop;traffic_signals, traffic_sign=* (as a node on a way) – the direction of traffic along the way to which the feature applies
- when used with route=road – the signposted cardinal direction of travel along the subrelation
- when used with manoeuvre relations – a relative turning direction
- when used with other primary tags – an absolute direction
- when used with amenity=atm, amenity=bicycle_rental – the name of an organization that coordinates operation in various locations
- when used with route=road;bus;train etc. – an identifier for a coherent system of routes, typically based on the containing region's region code
- when used with route=bicycle;hiking;mtb etc. – the route's scope
- when used with amenity=fuel;parking;taxi – the number of vehicles the facility can accommodate at a time
- when used with amenity=kindergarten;school – the number of students the facility can enroll at a time
- when used with leisure=stadium, amenity=shelter, room=* – the maximum (standing or seating) occupancy
- when used with tourism=camp_site, but not tourism=hotel – the number of visitors the facility can accommodate at a time
- when used on a relation – the technical type of relation
- when used with various primary feature tags – the type of aerodrome, reservoir, tree, etc.
An editor's developers may find it difficult to implement a field for a key that has a homonym associated with a different preset, especially if the homonymous keys have different data types or acceptable values. iD's fields suggest likely values based on taginfo lists of most common values by key. Since taginfo does not segment these lists by primary feature tag, irrelevant suggestions may appear.
If an element is tagged with multiple feature tags and each feature tag can potentially be used with a different homonym, a renderer or other data consumer may produce inconsistent, nondeterministic, or nonsensical results. For example, if a feature is simultaneously tagged building=yes and attraction=carousel, min_height=* may indicate either the height of the space beneath the carousel (if it sits on an elevated structure) or the minimum height required to ride the carousel. Indeed, every renderer that conforms to the Simple 3D buildings specification inaccurately depicts floating above the ground. A renderer may need to ignore the tag when set to a typical child height, which may be neither desirable nor feasible.
As an extreme example, various uses of type=* had to be deprecated in favor of other keys because it was impossible to indicate the type of a reservoir etc. that is mapped as a multipolygon, which requires type=multipolygon.
Some tagging schemes have made use of namespaces, subkeys, or more descriptive keys to avoid key conflicts. For example, construction=* is now used as a namespace to quality most feature tags; its use as a key only continues with certain feature keys that are unlikely to be tagged on the same feature. aerodrome=* replaced type=* on aeroway=aerodrome features, making it possible to map an airport as a multipolygon relation. man_made=flagpole features are tagged flag:type=* and potentially tower:type=*.
Confusion may still arise despite namespacing. For example, building:condition=* indicates the building's state of (dis)repair, while parking:condition=* indicates the condition that must be satisfied to park.
Some mappers avoid tagging multiple primary feature tags on a single feature, instead mapping multiple features to represent the same physical object. However, this approach can run counter to the "One feature, one OSM element" principle.