One feature, one OSM element
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:
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.
- 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
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.
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.
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.
- 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