Homonymous keys
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.
Causes
These conflicts have multiple causes, depending on the nature of the incompatibility. See the list below for details.
Disadvantages
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 161214224 161214224 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
.
Mitigation
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.
List of homonymous keys
Due to the ever-changing nature of OSM (see any tags you like), this list will always be incomplete; however, please help document these namespace collisions whenever you encounter them.
Homonyms in English
These conflicts arise when "iterative refinement" tagging schemes use words that have homonyms in the English language:
branch=*
- when used with
amenity=bank;restaurant;fuel
,shop=*
– the name of the store branch - when used with
community=hutterite
– the branch of Hutterites that occupies the place - when used with
railway=*
– the name of the branch line
- when used with
department=*
- when used as a primary feature tag – to identify the feature as a section of a
shop=department_store
; see OpenLevelUp/Use cases/Shopping mall - when used with
building=university;college
– the name of the university department that occupies the building; seeamenity=university
- when used as a primary feature tag – to identify the feature as a section of a
line=*
- when used with
power=line
– the type of assembly that connects power lines - when used with
railway=*
– the name of the railway line
- when used with
service=*
Refining the feature versus something tangential to it
admin_level=*
- when used with
boundary=*
– the administrative level of the boundary itself - when used with
government=*
– the administrative level of the government unit that operates the feature
- when used with
brewery=*
– whether the establishment is or has a brewery, or the name of the brewery that supplies beer to the establishment
distance=*
- when used with
highway=milestone
– the distance along the road denoted on the milestone - when used with
route
relations – the length of the route
- when used with
highway=*
maxspeed=*
(foot=*
,bicycle=*
,oneway=*
,zone:maxspeed=*
, etc.)- when used with
highway=*
– speed limit when traveling along the roadway - when used with
traffic_sign=*
– speed limit denoted on the sign
- when used with
min_height=*
- when used with
attraction=*
– minimum height required to ride the attraction (some mappers are usingminimum_height_requirement=*
to specify this information) - when used with
building=*
– height above ground level at which the building begins
- when used with
model=*
- when used with
shop=model
– the variety of hobby models or kits sold (discussed but not documented) - when used with various primary feature tags (such as
man made=street cabinet
) – the model name or number of the feature itself
- when used with
school=*
Containment versus refinement
These conflicts often arise when a crude tagging scheme is established before a more granular micromapping technique is introduced later on:
bench=*
cemetery=*
cycleway=*
footway=*
junction=*
- when used as a primary feature tag – whether two or more ways form a junction at the node
- when used with
highway=*
– the type of junction
kerb=*
- when used as a primary feature tag – the type of kerb
- when used with
crossing=*
– whether there is a kerb at either end of the crossing (and optionally also what type of kerb it is)
shop=*
swimming pool=*
- when used with
leisure=fitness_centre
,tourism=hotel
– whether a swimming pool is available on-site (yes
/no
) - when used with
leisure=swimming pool
– the type of swimming pool
- when used with
Incompatible formats
These conflicts arise due to "iterative refinement" tagging schemes:
construction=*
- when used with
building=construction
,highway=construction
,landuse=construction
,railway=construction
– the value is what will be moved to the primary key once construction is complete - when used with other primary tags as a lifecycle prefix – the entire primary tag is namespaced, e.g.
construction:amenity=*
- when used with
direction=*
- when used with
highway=mini_roundabout
– the direction of rotation - when used with e.g.
highway=traffic_signals
,highway=stop
,highway=give_way
,traffic_sign=*
(as a node on a way) orcycleway=asl
– the direction of traffic along the way to which the feature applies (forward
/backward
orboth
forhighway=traffic_signals
) - 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
tourism=viewpoint
– one or more arcs visible from the viewpoint (0-360 is the most common value) - when used with other primary tags – an absolute direction as a numeric value in degrees (or a cardinal value like N/E/S/W), usually the direction in which the object or its front is pointing, e.g.
amenity=bench
ortraffic_sign=*
(as a separate node not connected with a way)
- when used with
name=*
- when used with
route=train;subway;monorail
route=tram;bus;trolleybus
route=ferry
– a strict format including the network, route number, origin, destination, and some ASCII art- This is causing major problems as some of this routes have actual names
- when used with other primary tags – what the feature is called, not how it is described
- when used with
network=*
- 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 and mode of transportation - when used with
type=network
– the route's scope and/or mode of transportation
- when used with
symbol=*
Other nuances
bus=*
capacity=*
- 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 nottourism=hotel
– the number of visitors the facility can accommodate at a time - when used with e.g.
man made=storage_tank
orman made=grit_bin
(and some others) – volume measurement
- when used with
destination=*
- when used with
highway=motorway_link;trunk_link;primary_link
etc. – the signposted names of the places to which the road leads - when used with
waterway=*
– the name of the body of water into which the waterway flows, not necessarily signposted
- when used with
maxweight=*
- when used with
highway=motorway;residential;cycleway
etc. – legal access restriction by vehicle weight - when used with
highway=elevator
,aerialway=zip_line
,attraction=roller_coaster
– access restriction by passenger weight
- when used with
type=*
- when used on a relation – the technical type of relation
- when used with various primary feature tags – the type of aerodrome, reservoir, tree, etc.
Homonymous roles
Some relation types also document roles inconsistently, with similar consequences for editors and data consumers:
via
- when used with
type=restriction;connectivity;turnlanes:turns
,type=destinationsign
– the intersection node or internal intersection way at the decision point - when used with
type=destination_sign
– the internal intersection way at the decision point, but not the intersection node
- when used with