Tag:site=parking
 site = parking
|
 |
| Description |
|---|
Group entrance for complex/underground parking.  
|
| Group: parking |
| Used on these elements |
    |
| Requires |
| See also |
Status: approved
|
| Tools for this tag |
|
The relation is used to combine all elements of a local area, that relate to this parking area. It is an advanced scheme and somehow more complex / time costly than other methods (Parking).
A good example is to combine entrance, vending machines and parking spaces into one group, like all parking spaces in front of a mall under a relation with the name Big Mall Parking.
See: Parkhaus Liederhalle/Bosch-Areal
Parkhaus Liederhalle/Bosch-Areal.
Status
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).
How to map
This type of relation groups elements regarding parking (see below for examples) together, so they have to be created first and then they can be added to it. The relation will be enhanced with tags (keys/values). Tags on the relation itself are valid for all elements or child relations in it unless they are overwritten by a tag on a sub-item (element / child relation).
Elements
The main element in this relation is amenity=parking_space.
Other elements, that somehow belong to the parking lot, can also be added to the relation, like:
- amenity=parking_entrance
- Service roads tagged as highway=service + service=parking_aisle
- Vending machines tagged as
amenity=vending_machine+vending=parking_tickets - Emergency phones
- (Only) If a building exclusively represents a multi-storey
Tagging
General tags (see below) defined in the relation are inherited by the elements inside the collection as long as not mapped otherwise on sub-items.
| 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 |
Nesting
Relations of this type can be nested up to three times, which should be sufficient to map even big areas with different sub areas.
But a (parent) relation can contain either
- 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.
Annotation
- 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).
- 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.