One feature, one OSM element
One feature, one OSM element is a good practice principle. It means one on-the-ground real world feature should be mapped with only one OSM element.
Map objects
General rules
An OSM element should represent a single on-the-ground feature once and only once. Examples:
- A feature consisting of buildings on grounds (e.g. a school), should be mapped as an area object delineating the land with area objects marking the buildings. Tags should be on the whole area, and not the buildings, unless the buildings are different. Buildings within the school grounds can be assumed to be part of the school by database users.
- A feature consisting of a building whose shape and position are known should be an area object with appropriate tags.
- A feature whose position is known, but whose shape is either unknown or irrelevant, should appear as a node object with appropriate tags.
- A feature that consists of several smaller features is usually best described using a relation. For example, relation:route for a hiking route or a public transport line which follows several
highway=*
orrailway=*
ways.
Examples of bad situations
- An area object with a node object inside, both with the same tags representing the same real-world feature.
- An area object representing grounds with a tagged single area object representing the only building on it, both tagged with the same feature tag.
- A closed way tagged with two feature tags, one of which is usually a linear feature such as
barrier=hedge
and another which represents an area such asamenity=school
. In this case it is ambiguous if the barrier is meant to represent an area or a line, and for all properties it is unclear to which feature they belong. In such a case you may consider making a separate relationfor the
amenity=school
: make the closed wayan
member of the relation and transfer the educational tags from the wayouter
to the relevant relation
.
- Mapping hotel and restaurant within hotel as one object, with
tourism=hotel
andamenity=restaurant
on one node or area. It is causing problems as soon as any more detailed tags such asopening_hours=*
would be added[1] - Pub and ATM nearby as one node, with
amenity=pub;atm
,name=Lone Buffalo;Credit Bank
andopening_hours=24/7
. - Shop in a building mapped as a single object with
building=*
andshop=*
andname=*
(which will often apply only to POI). This one is more debatable, and it is generally not treated as obviously wrong as long as all properties are applying to all features at the same time.[2]
Situations where multiple elements may be needed


This principle is not absolute. As a matter of practicality, some features are represented more than once, because of nuanced semantic differences between node/way/relation representations of a feature, or because different kinds of data consumers have very divergent needs, or to preserve backwards compatibility with existing data consumers during a transition period. Examples include but are not limited to:
- More than one of something on the same site: e.g. two schools sharing the same grounds. If the schools have separate buildings, they can be mapped as the buildings and the ground can be tagged with
landuse=education
. If multiple schools are located in the same building, both should be mapped asamenity=school
(typically nodes). - Multiple-use buildings: The building should be tagged as
building=*
.- If the building has a clear primary feature that can be said to contain the other features, the primary feature can be tagged on the building itself, and other features mapped inside the building perimeter (e.g. a restaurant inside a hotel, shops within a shopping mall).
- If the building doesn't have one primary feature that contains the others, all features should be mapped inside the building perimeter (e.g. a building that contains multiple shops with separate entrances).
- Features mapped inside the building perimeter can be either nodes or areas. Optionally, the Simple Indoor Tagging scheme may be used to clarify the building layout.
- Multiple-purpose shops (e.g.
shop=stationery
which is alsoshop=copyshop
and/orshop=books
). See Key:shop#Multi-purpose shops. - Villages are commonly mapped with
place=village
on a node at the village centre, with tags such asname=*
. Areas with residential landuse within the village should be treated as separate objects and are separately mapped withlanduse=residential
, just like otherlanduse=*
. - Object oriented vs functional oriented mapping: The same object can be mapped twice, once for functional reasons (e.g. routing) and once for object oriented purposes (e.g. to map the actual shape and for object information). For example, features that form routable networks, such as highways and waterways are mapped using a continuous linear
representation (
highway=*
) for routing purposes (even when they are physically interrupted such as in a ford over the riverbank), while their actual shape and topology on crossings are represented in anarea (
area:highway=*
), which for example can show what the surface is on a crossing between two roads with different surfaces. Another examples are bridges. Usingbridge=yes
on highways is an example of functional mapping to tell the router there is a bridge (with optional information like the maximum vehicle weight). When mapping object oriented, the actual shape (footprint) of the bridge can be mapped withman_made=bridge
, which can be enriched with information like the name of the bridge or wikidata. The same real world feature is mapped twice with different purposes. - Rivers are usually represented with
natural=water
+water=river
for the area covered by water and one or morewaterway=river
on routable linear ways that follow the main flow of the river, with tags such asname=*
on thewaterway=river
feature. - Long linear features such as
waterway=river
and other linear tags may for practical purposes be split into multiple ways when extremely long. - Attributes on a line Changing value of tags such as
surface=*
,lanes=*
,turn:lanes=*
,maxheight=*
makes it necessary to split ahighway=*
line. This also applies to other features such aswaterway=river
. Rivers need to be split in parts where for example main localname=*
changes. - When an on-the-ground feature has been divided into multiple elements in Openstreetmap they can be grouped into a single element such as a Relation:waterway
that represents the river as a whole
- Note that such relations does not replace tagging using way and in many cases are fundamentally unable to replace it, for example where a single river has different dominating local names along its course.
- Named natural areas consisting of multiple sub-areas, like forests, wetlands and reservoirs. Some mappers prefer to repeat the
name=*
tag for all sub-areas, but this is controversial, and breaks down if a sub-area has a name of its own.
Multiple tags
The principle one feature, one OSM element concerns nodes/relations/ways, and not tags.
Some objects may have multiple tags describing the same thing. For example both waterway=riverbank
and natural=water
+ water=river
have exactly the same meaning.
Such double tagging is not going against this specific rule. Depending on situation it may be acceptable (so both tags should be kept), clearly unwanted, or something in between. E.g., contact:phone=*
+ phone=*
with the same info will keep supporters of both tagging versions happy, and there is no support to deprecate either one. But sometimes one tag is clearly standard and it will be OK to eliminate its duplicate. For example in amenity=police
+ emoji_encoded_tag=:cop:
, the second tag may be safely deleted, and indeed deleting it would improve OpenStreetMap.
Repeating properties
Note that in the case of linear features like waterway=river
, the name=*
tag should not be repeated on river areas (like natural=water
+ water=river
), it only goes on the river line.
The same applies to area:highway=*
and highway=*
– tags such as name=*
should not be repeated.
See also
- Keep the history – similar to this guideline, but pertaining to the history instead of the tags
- Relation:multipolygon – a standard way to map complex areas (for example, a school divided in 2 parts by a road, or a lake with an island)
- Way – on the differences between linear and area representation of features
- Relation:site – proposed for multi-part features which cannot be expressed as a multipolygon (an example is a wind farm, a feature which includes multiple nodes)
building:part=*
– how to tag complex buildings