Proposal:Parking
| parking (redux) | |
|---|---|
| Proposal status: | Voting (under way) |
| Proposed by: | flaimo |
| Tagging: | amenity=parking_space/parking_entrance, type=site, site=parking=* |
| Applies to: |  ,  , 
|
| Definition: | This proposal is for detailed mapping of parking areas. |
| Statistics: |
|
| Rendered as: | Parking, more detaled, but less cluttered |
| Draft started: | 2011-03-13 |
| RFC start: | 2011-03-18 |
| Vote start: | 2011-04-17 |
| Vote end: | 2011-05-01 |
Why this proposal?
Over the last months more and more high resolution satellite images were made available to mappers. A lot of them are are good enough to identify single parking spaces, especially with special symbols on them, like disabled parking, which again would allow much more detailed mapping of such areas. The current mapping scheme with just the tag amenity=parking isn't sufficient enough to represent this high density of information. Therefore I wrote this proposal as an addition, not as an replacement, to the current mapping scheme for parking spaces.
Tag overview
amenity=parking_space
Defines an area with 1 to n parking spaces.
amenity=parking_entrance
Entrances to underground or multi-storey parking facilities, in case their physical presence can’t be fully mapped.
type=site, site=parking
The parking-relation groups individual parking spaces and entrances together. Relations of this type can be nested.
Advantages
- Navigation systems can use the information to route a disabled person directly to a suitable parking space. With the current scheme ("capacity:disabled" mapped to an big amenity=parking area) this information cannot be provided. Also car rental services would have the possibility to direct customers directly to the correct parking space.
- Renderers could use the information in the relations to choose a suitable name for the different zoom levels in their maps. It should also help reduce the clutter of to many "P" symbols on the map.
- Individual parking spaces could be connected with third party applications to provide visual aid for displaying taken or free parking spaces.
- More complex parking lots can be mapped where the usage of a single amenity=parking area isn't working out.
What about the current amenity=parking?
This new tagging scheme is not meant to replace amenity=parking. You can stick to the current scheme if you like to keep it simple. Other reasons when amenity=parking might still be better:
- In areas where there is no or low res satellite images available the current mapping scheme should still be used.
- It's easier for new mappers to use the simple parking tag without a relation. This proposal offers experienced mappers in areas where high resolution satellite images are available a way to do more detailed mapping.
- Though is can be used for underground- and multi-storey parking, it’s mainly targeted at surface parking.
What about those other parking proposals?
http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces
That was the first parking proposal I found. Seems to be inactive. The special interest groups noted in that proposal are integrated in this proposal in chapter “general tags”. That's the reason why this proposal has redux in its name.
http://wiki.openstreetmap.org/wiki/Proposed_features/Carpool
Integrated under “special interest groups” in chapter “general tags”.
http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane
Is meant for parking alongside highways. this proposal here is for dedicated parking areas, therefore the proposals don’t interfere.
Tag descriptions
Parking space
| Key | Value | Comment | |
|---|---|---|---|
| required | amenity | parking_space | Mandatory tag for defining an area that contains 1 to n parking spaces. |
| optional | ref | String | If the parking space is managed in another third party application the internal ID of this space can be noted here to offer the possibility of an connection from the space in OSM to the third party system. If more than one application needs to note it’s ID, the notation changes to ref:<vendor> (for example ref:hertz, ref:airport_JFK) |
| optional | name | String | If the parking space has a number, license plate or other written information printed on its surface or on a plate in front of the space, it should be put in the name tag. Examples: 1, 2, 3, L6F-33S, Big Boss parking space |
| optional | capacity | Unsigned Integer | Optional, but should be mapped whenever possible, even if the number is just an estimation (for example at big bicycle parking areas).
Note that the separation into different capacity:* tags for special interest groups is not supported for these kinds of parking areas. In such a case, individual parking spaces should be mapped, or you should stick with the current mapping scheme. The default value for "capacity" is "1" if not mapped otherwise. |
| optional | general tags | * | See chapter General tags for tags that can be applied to spaces, areas, entrances and relations |
- Parking spaces always have to be grouped together in a relation. In rare situations where there’s really only one single parking space that is not somehow connected to any other spaces nearby, "amenity=parking" should be applied.
- A parking space should preferably be mapped as an area, but it is also possible to use a node.
- Each single space should be mapped as a separate area. Exceptions for using one area to represent more than one space:
- A lot of similar parking spaces side by side without any differing attributes and you don't want to put that much afford into it.
- Spaces are just too small to map (for example for bicycle parking)
- Satellite images aren't good enough and don’t allow the mapping of single parking spaces, but you can still make out separate groups of spaces.
- It should not be used as a representation of one big single parking area. Highways should not cross this areas.
Parking entrance
While underground or multi-storey parking facilities could be mapped using amenity=parking_space in combination with a layer tag, it’s often sufficient enough to just map the entrances and exists as nodes.
| Key | Value | Comment | |
|---|---|---|---|
| required | amenity | parking_entrance | Mandatory tag for defining a parking entrance. |
| optional | ref | String | same rules as for parking space |
| optional | name | String | Name of the entrance. Examples: Main entrance Big Underground Parking, Side Exit 3rd Avenue |
| optional | general tags | * | See chapter General tags for tags that can be applied to spaces, entrances and relations |
- A parking entrance always has to be mapped as a node.
- The differentiation between different kind of entrances is defined by setting the correct access tags.
- If appropriate, the tag can be combined with building=entrance.
- Parking entrances should always be connected to a highway and never be mapped isolated.
- The distinction between entrances which function as exits, entrances or both is defined by the oneway tag of the highway=* connected to the parking_entrance node.
- Parking entrances are only used for underground or multi storey parking, not for surface parking.
- Inside a site relation parking entrances optionally can have the role entrance (see site proposal for details)
Site relation
The relation is used to combine the individual elements stated above 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.
| Key | Value | Comment | |
|---|---|---|---|
| required | type | site | |
| required | site | 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 sapces 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 for tags that can be applied to spaces, entrances and relations |
- The required tags are based in most parts on the proposal for site. A parking relation can be added as a sub relation to a more general site relation (for example an relation for an airport).
- 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 to 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
General tags
General tags can be applied to parking space areas, parking entrances and relations. The general rule is: The tag on a specific element weights more then the same tag on a more general element. For example if you map a surface=paved to the relation grouping some parking spaces, but one of the spaces has a tag surface=gravel, the value paved is applied to all parking spaces accept the one with the tag surface=gravel. Example 2: A relation contains some sub relations which again then contain parking spaces. The relation has operator=Big Mall mapped to it, but one of the sub relations contains an operator=IKEA. operator=Big Mall would therefore be applied to all sub relations and therefore all their parking spaces, except for the sub relation with operator=IKEA. The parking spaces under this sub location would also inherit the value operator=IKEA (as long as not stated otherwise on a specific parking space).
| Key | Value | Defaut value | Comment | |
|---|---|---|---|---|
| optional | access | <access value> | public | Access restrictions can be applied as stated on the wiki page for access. Note that the access definitions should only be used to define the type of vehicle/transportation which is allowed on the element. special interest groups (like disabled, woman, parents…) are handled separately since those two are not exclusionary (see below).
You are encouraged to map more specific access restrictions besides the general access tag: example 1 - a parking space for a truck on a privately owned rest stop along a highway: vehicle=no, hgv=permissive example 2 - public bicycle parking: vehicle=no, bicycle=designated |
| optional | access:<special interest group> | <access value> | – | To add further restrictions besides, the generic access tag, on who can access the element, this tag can be used. examples:
These tags can also be combined: access=private + access:woman=yes + access:disabled=yes would mean, that this place is only for disabled women when given permission by the owner. This separate tags compensate for a flaw in the design of the current access structure. The kind of transportation normally is exclusive. You can't drive two different kinds of vehicles at the same time. On the other hand roles aren't. You can be disabled, a woman and a customer at the same time. If the flaw gets fixed for access tags in general, this tag could be eliminated later on for a generic solution. I wrote down my suggestions for a fix of the access system here: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 The attributes stated above are examples and are not a fixed list. Additional special interest groups can be added if needed. Subgroups should be separated by a semicolon (for example access:customer:firstclassguests). |
| optional | surface | String | paved | Standard values for surface. see surface page for further details. |
| optional | operator | String | – | The operator of the parking space/entrance/area. |
| optional | fee | yes/no/interval | no | Whether you have to pay a parking fee or not. If the fee must be paid only on certain hours, the same syntax can be used as for opening hours. |
| optional | payment:<payment method> | yes/no/interval | no | Whether you can use a certain payment method or not. If a payment method only work at certain hours, the same syntax can be used as for opening hours. |
| optional | avg_fph | (<Currency><Space>)Float | no | Pricing for parking is to complex to be represented in a single tag, therefore only the average fee per hour for one parking space should be noted, to give the user some sort of orientation of what price to expect.
The value itself is a float with two decimal places. The dot is used as a separator. If no currency format is given, the official currency of the country, where the parking space is located, is used. So by default there shouldn't be the need to map the currency. If it differs from the official currency, note it in front of the value using the ISO 4217 format (Three letter format), separated by a space. |
| optional | covered | yes/no | no | covered should be set to yes if a parking space has a roof to protect from rain, hail or foliage, but not necessary side walls. Real garages made of metal or bricks should be tagged as a building with building=garage and maybe combined with amenity=parking_space + capacity=*, since mapping of individual spaces inside a garage building isn’t possible. |
| optional | parking | underground, surface, rooftop, multi-storey | surface | Same as for amenity=parking. can be extended with other values, that describe the physical presence, if needed. |
| optional | maxstay | Integer | 0 | Time limit in minutes for parking. 0 means unlimited. Note that in this proposal the value is measured in minutes, not hours like currently noted on the wiki page for amenity=parking. |
| optional | supervised | yes/no/interval | no | Whether the vehicles are guarded to prevent theft and vandalism. If a guard is only present on certain hours, the same syntax can be used as for opening hours. |
| optional | lit | yes/no/interval | no | Whether the element is lit or not. If lit only at certain hours, the same syntax can be used as for opening hours. |
| optional | opening_hours | interval | 24/7 | General syntax for opening hours can be used.
In case special interest groups or kinds of transportation have differing access times, the key can be appended to the access or access:<special interest group> tag. Example: access:disabled:opening_hours, hgv:opening_hours. |
- This is not a fixed list of tags. If needed additional tags can be added.
Examples
Shopping mall area
Underground parking
Car rental service
Suggestions for renderers
Some suggestions on how renderers could display the data:
- The basic appearance shouldn't differ from current rendering styles. For example in mapnik, parking spaces should be colored yellow.
- At lower zoom levels the name mapped on the site relations could be displayed under one "P" symbol. At even lower zoom levels the name of the parent site relation could be used. Only one “P” has to be rendered. That would reduce the clutter of Ps on the map, since renderers currently try to display a symbol for every area mapped with amenity=parking.
- Individual parking spaces could be rendered with a slightly darker border at very high zoom levels.
- At the highest zoom level the name of individual parking spaces could be displayed inside the area (like a house number for building). Also symbols for special parking places (disabled parking, parents parking,…) could be displayed.
Suggestions for editors
- Editors could provide a function to users to split up an area into single parking spaces. JOSM, for example, has a plugin for terracing buildings and add house numbers to them. A modified version for parking spaces (where the user can define the number of rows AND columns) could be implemented.
Changes based on comments from the RFC phase
- changed parking_*_id to generic ref tag (Pobice)
- allowed parking spaces to also be nodes (Tordanik)
- changed to parking=amenity + parking_type=* concept to stay compatible with current renderers. (Dieterdreist)
- merged parking_type=space and parking_type=area to one element (Dieterdreist)
- reverted parking=amenity + parking_type=* back to amenity=parking_space/parking_entrance to avoid processing errors of current amenity=parking elements. (Tordanik / user on mailing list)
Voting
Voting is open until 2011-05-01. Please vote with {{vote|yes}} or {{vote|no}} and sign with ~~~~
I approve this proposal. --Flaimo 16:04, 17 April 2011 (BST)- I approve this proposal. --Dri60 17:39, 17 April 2011 (BST)
- I approve this proposal. --Tordanik 22:44, 17 April 2011 (BST)
- I approve this proposal. --Pobice 00:53, 18 April 2011 (BST)
- I approve this proposal. --Joshdoe 12:57, 18 April 2011 (BST)
- I approve this proposal. --Sanderd17 18:52, 18 April 2011 (BST)
- I approve this proposal. --Sev 21:38, 18 April 2011 (BST)
- I approve this proposal. --Xapitoun 21:46, 18 April 2011 (BST) complicated but I like it
- I approve this proposal. --a_henderson 18:09, 19 April 2011 (BST)
- I approve this proposal. --Marko Knöbl 09:49, 20 April 2011 (BST)
- I approve this proposal. --Kennioje 17:18, 20 April 2011 (BST)
- I approve this proposal. --JasonWoof 22:16, 22 April 2011 (BST)
- I approve this proposal. --DINENISO 08:24, 27 April 2011 (BST)
I oppose this proposal. --Stefan Bethke 16:19, 27 April 2011 (BST) I find this way too complicated, and I feel all relevant information can be provided through amenity=parking- I approve this proposal. --Don-vip 00:45, 29 April 2011 (BST)
- I approve this proposal. --Julienfastre 09:17, 29 April 2011 (BST) except that I think we should not use the tag avg_fph: this information could be deprecated too regulary and need a lot of work to be kept up to date.
- I approve this proposal. --Polyglot 09:50, 29 April 2011 (BST)
