One feature, one OSM element

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages

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

An OSM element should represent an on-the-ground feature once and only once:

  • 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 area, and not the buildings, unless the buildings are different (e.g. buildings on the school grounds can be assumed to be part of the school).
  • 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.

Examples of bad situations:

  • An area object representing a single-use building with a point object inside it. Move the tags to the area object and delete the point.
  • An area object representing grounds with a tagged single area object representing the only building on it. Move the tags to the outer area object and remove them from the inner one.
  • An area object representing grounds with a tagged single area object representing the only building on it, with a tagged point object inside it. Move the tags to the outermost object, remove from the inner area, delete the point.

Situations where multiple tags may be needed:

  • More than one of something on the same site e.g. two schools sharing grounds. Normally if the schools are separate they would have separate neighbouring grounds, but if the only thing defining a separation between two schools is their buildings, then the containing area should be tagged with a suitable landuse=, and the buildings tagged individually.
  • Multiple-use buildings. The building should be tagged as being a building, and should have point or area objects representing the locations of what is in them. e.g. shops within a shopping mall

Tag data

A tag should correspond to one and only one concept:

  • A concept may have many aliases, as long as these refer to identical concepts, having one as a canonical form is a good idea.
  • Tags may cover several varieties of the one concept, but they should not unify different concepts.
  • High-level tags may represent a hierarchy of concepts where there isn't something more specific (make one up, perhaps), or where a type isn't known. Folding out attributes is sometimes useful (e.g. natural=wetland + wetland=reedbed).

Things that are bad:

  • "Umbrella" tags. One may buy drinks at several locations. These locations will be different concepts - bars, cafes, shops, vending machines, water fountains, etc. Someone designing a search for drinks can use these features and devise appropriate rules to narrow down the selections.

See also

  • Relation:multipolygon way to mark complex areas (common example feature separated by road)
  • Relation:site if feature cannot be expressed as simple multipolygon (common example feature spread across the locality or some region)
  • building:part=* about how to tag complex buildings