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 point 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=* or railway=* ways.

Examples of bad situations

• An area object with a point 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 as amenity=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 relations for the barrier=hedge and for the amenity=school, make the closed way a member of both relations and transfer the tags from the way to the relevant relation .
• Mapping hotel and restaurant within hotel as one object, with tourism=hotel and amenity=restaurant on one node or area. It is causing problems as soon as any more detailed tags such as opening_hours=* would be added
• Pub and ATM nearby as one node, with amenity=pub;atm, name=Lone Buffalo;Credit Bank and opening_hours=24/7.
• Shop in a building mapped as a single object with building=* and shop=* and name=* (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.

Situations where multiple elements may be needed

Top Dog Hot Dog and Furniture Outlet Top Dog Hot Dog and Furniture Outlet, a particularly unusual example of this situation.

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 as amenity=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.
• Villages are commonly mapped with place=village on a node at the village centre, with tags such as name=*. Areas with residential landuse within the village should be treated as separate objects and are separately mapped with landuse=residential, just like other landuse=*.
  • The same with place=town, place=city, etc.
• 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 an area (area:highway=*), which for example can show what the surface is on a crossing between two roads with different surfaces. Another examples are bridges. Using bridge=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 with man_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 more waterway=river on routable linear ways that follow the main flow of the river, with tags such as name=* on the waterway=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 a highway=* line. This also applies to other features such as waterway=river. Rivers need to be split in parts where for example main local name=* 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