One feature, one OSM element

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — One feature, one OSM element
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

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 an on-the-ground feature once and only once, i.e.:

  • 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 land, 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.
  • A feature that does not fit into a single area is usually best described using a relation. Again, tags should be on the relation, not on the relation's members, unless they do not apply to all members. Examples:
    • relation:waterway for a long river
    • relation:route for a hiking route, a named motorway, or a public transport line
    • relation:site for buildings in different locations belonging together, such as a university split across two campuses

Examples of bad situations

  • An area object representing a single-use building with a point object inside it. If you find this, 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. If you find this, 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. If you find this, 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.

Notable exceptions


Streets are (arguable) an exception to the above rule: A single street with a single name, which most people would consider one "feature", is commonly represented as multiple, connected ways, each of which bearing the same name=* tag (but different other tags). This could be seen as a violation of this rule; however, the pratice is firmly established and unlikely to change. There is a relation for grouping the ways of a street (Relation:street), however it is not commonly used and thus not recommended.

Note that this special case only applies to streets (i.e. ways tagged with highway=*). All other features should only be represented by a single (set of) tags, as described above.

Place tags

Not always the same tag has the same meaning on an area and on a node. place=* on an area is about the explicit extension and borders of the place, on a node it is about the centre. You should not remove place nodes when you add a place polygon, because the information about the location of the centre is not computable, nor is the border, these are 2 distinct pieces of information.

See also

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