Proposed features/more parking

From OpenStreetMap Wiki
Jump to navigation Jump to search
More tags parking [spaces]
Status: Proposals with undefined or invalid status (inactive)
Proposed by: Mwoehlke
Tagging: parking_space=*
Applies to: area amenity=parking_space
Definition: Additional identifiers for specific types of parking spaces
Rendered as: POI icon
Drafted on: 2020-07-25
RFC start: 2020-08-07

Proposal

This proposal has multiple (closely related) parts:

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 way 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

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

area 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.