Proposal:More parking
| More tags parking [spaces] | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Mwoehlke |
| Tagging: | parking_space=* |
| Applies to: |  amenity=parking_space
|
| Definition: | Additional identifiers for specific types of parking spaces |
| Statistics: |
|
| Rendered as: | POI icon |
| Draft started: | 2020-07-25 |
| RFC start: | 2020-08-07 |
Proposal
This proposal has multiple (closely related) parts:
- Make the already-in-use parking_space=disabled official. (More specifically, create that page and give it status=approved to clarify the status of the tag.)
- Add parking_space=motorcycle, parking_space=compact, parking_space=takeaway and parking_space=charging. (Possibly others, if recommended by feedback?)
- Add the related capacity:motorcycle=*, capacity:compact=* and capacity:takeaway=*.
Naturally, the wiki pages to be created will include details of how to use these tags. (As for the proposal, such details are mainly the assorted Rationale sections.)
Rationale
Some parts of the proposal are simply to codify existing practice, or introduce "obvious" extensions (e.g. parking_space=charging).
Rationale for takeaway
The justification for parking_space=takeaway (and capacity:takeaway=*) is, mainly, that these things exist, but there is currently no specified way to map them. In particular, there are many parking lots in the proposal author's area which have "carry-out only" parking spaces. (Note that, although in the author's area, "carry-out" is frequently used and "takeaway" is virtually unheard-of, takeaway is proposed for consistency with takeaway=*. The terms "takeaway" and "carry-out" are effectively synonymous and may be used interchangeably within the text of this proposal.)
There was some debate on the mailing list previously as to what constitutes a "parking space", and whether carry-out parking qualifies. For the purpose of this proposal, "parking" means leaving the vehicle stopped and unattended. Carry-out spaces clearly meet this definition because the intent is for the occupant(s) to exit the vehicle in order to enter the associated store (typically, but not necessarily, a restaurant). Note also that such spaces typically do not have a defined time limit, so trying to shoehorn them into time-limited parking is not really appropriate. See this Google Street View example. Moreover, not including them as part of a lot's capacity is also not entirely satisfactory, as this means we have no way of indicating their presence at all.
(Of course, this begs the question whether we should also add parking_space=pick_up or some other mechanism for indicating standing spaces?)
Rationale for compact
Like parking_space=takeaway, the main justification is "these exist" and such spaces are not usable by all vehicles.
To clarify, "compact" here refers to "small" automobiles, especially two-seat "city" cars. These spaces are shorter than average and are thus not suitable to longer vehicles (e.g. pickup trucks, SUVs, full-sized sedans). Examples [can be found easily]. Because the definition of "compact" can vary regionally, the intent is that this should be used for spaces which are explicitly signed "compact vehicles only" (or equivalent). (For discussion: if signage cannot be verified, e.g. mapping from aerial imagery, should spaces where it is very clear that they are non-trivially smaller than typical parking spaces (usually in the same lot) also be tagged "compact"? See 835852110
835852110 for an example.)
Rationale for motorcycle
Currently, the suggested practice is to map motorcycle parking as a separate lot. However, when mapping lots according to "contiguous" lot surfaces (bounded by road intersections), this does not always work nicely. For example, consider here or here (links open iD editor; use of MapBox imagery is recommended). Most humans that are not experienced with OSM mapping would likely consider both the automobile and motorcycle parking spaces part of one "lot".
Moreover, delineation of parking spaces for specific purposes is hardly new. We already have capacity:disabled=* and capacity:charging=*, both of which "carve out" otherwise normal parking spaces (which are included in capacity=*) for use by only specific vehicles. This is not unreasonable, since a PEV or disabled vehicle can park in a "regular" spot... as can a motorcycle. This will also make it easier for novice mappers to properly map mixed-use lots.
To be clear, this is not a proposal to deprecate amenity=motorcycle_parking. Although this would make it possible to convert all such parking, having a tag to designate a lot which is exclusively for use by motorcycles is not necessarily bad.
Examples
- 830096097 830096097
More examples of "use in anger" may be added in the future. Additionally, the taginfo is interesting, showing a number of uses of most of the proposed values already. Ignoring obvious typos and the superfluous values normal and yes, we have (at time of writing):
| delivery | 349 |
| bus | 229 |
| motorcycle | 222 |
| charging | 140 |
| parent | 127 |
| hgv | 89 |
| parent_and_child | 85 |
| family | 60 |
| private | 45 |
| electric_vehicle | 38 |
| charging_station | 30 |
| staff | 27 |
| minute | 27 |
| customers | 25 |
| trailer | 23 |
| carpool | 18 |
Some of these (e.g. charging and charging_station) would appear to be redundant; a good argument for producing a standard. Others (private, customers) should possibly be handled instead using access=*. Indeed, most extant instances of {{{1}}} appear to be using parking_space=* in an undocumented manner that is inconsistent with what documentation does exist.
Tagging
How to tag should be self-evident.
Applies to
Areas tagged amenity=parking or amenity=parking_space.
Rendering
It would be nice if renderers would use some mechanism to identify non-standard parking spaces. Some allegedly will do so for disabled parking. Doing so for charging spaces and motorcycle parking also would be useful.
Features/Pages affected
amenity=parking and amenity=parking_space will need to be updated.
External discussions
This proposal is at least partly inspired by several previously existing threads on the tagging mailing list:
Comments
Please comment on the discussion page.