One feature, one OSM element
From OpenStreetMap Wiki
Other languages — Help us translating this wiki
• Afrikaans • አማርኛ • العربية • অসমীয়া • Asturianu • Azərbaycanca • Български • বাংলা • Brezhoneg • Bosanski • Català • Corsu • Česky • Dansk • Deutsch • ދިވެހިބަސް • Ελληνικά • Esperanto • Español • Eesti • Euskara • فارسی • Suomi • Français • Frysk • Gaeilge • Kréyòl gwadloupéyen • Gàidhlig • Galego • Alemannisch • ગુજરાતી • هَوُسَ • עברית • हिन्दी • Hrvatski • Kreyòl ayisyen • Magyar • Հայերեն • Interlingua • Bahasa Indonesia • Igbo • Íslenska • Italiano • Basa Jawa • ქართული • Қазақша • ភាសាខ្មែរ • ಕನ್ನಡ • 한국어 • Kurdî • Lëtzebuergesch • ລາວ • Lietuvių • Latviešu • Malagasy • Македонски • മലയാളം • मराठी • Bahasa Melayu • Malti • မြန်မာဘာသာ • नेपाली • Nederlands • Norsk (nynorsk) • Norsk (bokmål) • Occitan • Oromoo • ଓଡ଼ିଆ • ਪੰਜਾਬੀ • Polski • پښتو • Português • Português do Brasil • Română • Română (Moldova) • سنڌي • සිංහල • Slovenčina • Slovenščina • Soomaaliga • Shqip • Српски / Srpski • Svenska • தமிழ் • తెలుగు • Тоҷикӣ • ไทย • Türkçe • Українська • اردو • O'zbek • Tiếng Việt • Wolof • isiXhosa • Yorùbá • 中文(简体) • 中文(繁體) • isiZulu
One feature, one OSM element is a good practice principle whose meaning is self-explanatory. One on-the-ground real world feature should be mapped as one OSM element.
Map objects
A 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. x=y + y=z).
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.
