Tag:site=parking
Jump to navigation
Jump to search
 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 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: Parkhaus Liederhalle/Bosch-Areal
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