Tag:site=parking

From OpenStreetMap Wiki
Jump to navigation Jump to search
Public-images-osm logo.svg site = parking
P3030027ParkingLot wb.jpg
Description
Group entrance for complex/underground parkink Edit or translate this description.
Used on these elements
should not be used on nodesshould not be used on waysshould not be used on areasmay be used on relations
Requires

type=site

See also

amenity=parking_entrance amenity=parking_space amenity=parking

Wikidata
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, but currently there is almost no support for this among either mappers or data consumers (analysis) - amenity=parking is far more widely used.

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