From OpenStreetMap Wiki
Jump to navigation Jump to search
Public-images-osm logo.svg site = parking
P3030027ParkingLot wb.jpg
Group entrance for complex/underground parking. Edit this description in the wiki page. Edit this description in the data item.
Group: parking
Used on these elements
should not be used on nodesshould not be used on waysshould not be used on areasmay be used on relations
See also
Status: approvedPage for proposal

The relation is used to combine entrance and parking space into one group. For example all parking spaces in front of a mall can be grouped together under a relation with the name Big Mall Parking.

It has been approved in 2011, but since then there has been very little support for it from cartographers (and probably not from data consumers either) – see for example this analysis for OSM Carto (from 2015). In 2015, site=parking was used less than 3000 times worldwide. In 2023, the number of uses rose to over 20,000 (see this OSM tag history as a curve chart). But amenity=parking is of course still used much more often (over 4 million in 2023).

Example: relation Parkhaus Liederhalle/Bosch-Areal.

Key Value Comment
required type site
required site parking Please note, that at the time of voting, the proposal for site relations didn't have a clear definition on how to use the site key. To be on the safe side, please add both tags: site=parking and amenity=parking
optional ref String ID of the parking facility or sub section. Same as for parking space.
optional name String The name of the parking facility or sub section
optional capacity Unsigned integer In case the exact number of spaces of a parking facility can't be calculated by adding up the capacity tags of parking spaces, you can define the capacity for all parking elements under the relation. This is necessary if you want to map an underground parking facility, but only the entrances can be mapped. A value defined in the relation overrides a calculated value from the parking spaces.
optional general tags * See chapter General tags
  • Only elements close to each other should be grouped. It is not meant for logical collections (for example all parking areas from IKEA in whole of Sweden).
  • General tags (see below) defined in the relation are inherited by the elements inside the collection as long as not mapped otherwise.
  • Relations of this type can be nested up to three times, which should be sufficient to map even big areas with different sub areas.
  • A relation can contain other relations of the same type or 1 to n entries of the types parking space, parking entrance or other relevant elements. A mixture of sub relations and parking elements, with the exception of an optional label node, is not allowed.
  • The use of relations compensates for the flawed amenity=parking convention, which demands that all related elements have to be inside the area. This just won't work out for underground parking facilities or parking lots separated by roads that have nothing to do with parking.
  • If a building exclusively represents a multi-storey, it can be added to the relation.
  • Other elements, that somehow belong to the parking lot, can also be added to the relation. Examples:
    • Service roads tagged as parking_aisle
    • Ticket vending machines
    • Emergency phones