Proposal:Street parking revision

The Feature Page for the approved proposal Street parking revision is located at Street parking

Street parking revision
Proposal status:	Approved (active)
Proposed by:	Supaplex030, Riiga, partly based on proposed tags by Kovposch
Tagging:	parking:side, parking:side:orientation/access/fee/maxstay/restriction/zone/markings/direction=*, parking:both:staggered=yes, parking=on_kerb/half_on_kerb/shoulder, orientation=*
Applies to:
Definition:	Revision of the parking:lane=* and parking:condition=* schema that follows established OSM conventions more closely and harmonises tagging of separately mapped parking spaces with parking spaces mapped on the centerline.
Draft started:	2022-10-13
RFC start:	2022-11-07
Vote start:	2022-11-24
Vote end:	2022-12-08

The content of this proposal has been archived to avoid confusion with the current version of the documentation.

See on Template:Archived proposal how one may mark older proposal version to provide easy link for viewing archived content. (quick hint: {{Archived proposal|archive_id=}})

Proposal

Goals and outlines of this proposal

The goal of this proposal is to deprecate and replace the parking:lane=* and parking:condition=* schema for mapping street parking spaces. The new schema is intended to be easier and more logical to apply. The new schema follows established OSM conventions more closely. It harmonises tagging of parking spaces mapped on the centerline as an attribute of a street with parking spaces mapped as a separate feature.

Goal 1: The tagging of physical attributes (position and orientation of parked vehicles) should be similar to the tagging of other road attributes, e.g. cycleways:

parking:left=lane – The primary key parking:side (where side means the side of the street this information applies to) indicates the position of the parking in the street space. parking:left:orientation=parallel – A secondary tag indicates the orientation of the vehicles (parallel, diagonal or perpendicular). Current tagging according to the parking:lane=* schema: parking:lane:left=parallel (orientation as value of the primary key) parking:lane:left:parallel=on_street (position as value of the secondary key; which also includes the duplication of orientation as part of the key)

Goal 2: The tagging of parking restrictions should be based on the standard keys access=*, fee=* and maxstay=* (e.g. using parking:side:access). To map "action-based" restrictions such as no parking, no stopping or loading in a convenient way, we extend the new schema by adding the tag parking:side:restriction. Specific restrictions such as user group or vehicle type restrictions, residential parking zones, etc. can be tagged in this manner. For example (see more detailed at sections Tagging and Examples):

parking:right:access=yes – Who can use the parking space? Is it public and/or for special user groups/vehicle types? parking:right:fee=no – Do you have to pay to park here? parking:right:maxstay:conditional=30 minutes @ (Mo-Fr 08:00-18:00)* – Is there a maximum period of time you are allowed to park here? Current tagging according to the parking:condition=* schema: parking:condition:right=free parking:condition:right:maxstay:conditional=30 minutes @ (Mo-Fr 08:00-18:00)

^* Mo-Fr is used here because the example is a Swedish traffic sign where hours without brackets and in non-red colour refer to weekdays.

Goal 3: Harmonise tagging of separately mapped parking:

Under certain circumstances (e.g. complex geometries, frequent changes of attributes) it may be useful to map street parking separately using the common amenity=parking + parking=street_side or parking=lane. For those separately mapped parking areas, the same set of tags (already) exists, so now both can be mapped in the same style.

To put it differently: Parking mapped on the centerline uses the same keys, but prefixed with parking:side.

There are two exceptions that require changes for the mapping of separately mapped parking to fully harmonise the tagging of both variants:

• parking=on_kerb, parking=half_on_kerb and parking=shoulder are proposed as parking=* values in addition to the existing street parking values parking=street_side and parking=lane to clearly distinguish different street parking types/positions on separately mapped parking areas. Note: In general, it's not necessary to map such forms of street parking as separate geometry, but in special cases it can be useful and is still in use.
• parking:orientation=*, that was introduced by the street_side-Proposal in 2020, will be deprecated and replaced by just using orientation=*. This is in line with the current usage of the key orientation=* which is used mainly (but not exclusive) as an attribute of advertising=* features to "indicate[s] the orientation of the feature with respect to the flow of vehicles or passerby".

Summary: What is proposed, changed and deprecated?

• The street parking main key will be the new key parking:side. The current parking:lane:side will be deprecated.
• Switching position and orientation: The position of street parking (e.g. parking on the lane, on kerb, street side...) is the new value of parking:side and therefore the new "primary" attribute. The orientation (parallel/diagonal/perpendicular) is added by the new key parking:side:orientation.
• Parking conditions are mapped by using the established keys access=*, fee=* and maxstay=* (e.g. parking:side:access, parking:side:motorcar, parking:side:fee, parking:side:fee:conditional etc.). parking:condition=* will be deprecated. The former parking:lane=* and parking:condition=* schemas will be merged in a single street parking schema, where all these and other attributes (e.g. parking:side:surface) are used within the parking:side namespace - as is done in other OSM contexts.
• parking:side:restriction is proposed to distinguish no parking, no stopping and no standing restrictions as well as other action-based restrictions like loading and charging.
• on_street (as a parking position value for the former parking:lane:side:type=*) is replaced by lane (parking:side=lane) in order to harmonise this value with separately mapped areas of the same kind (tagged with parking=lane).
• The values marked and painted_area_only (used in former parking:lane:side=marked and parking:lane:side:type=painted_area_only) will be deprecated. They prevent mapping the parking position/orientation, aren't very meaningful and cannot be usefully evaluated. Instead, the new key parking:side:markings is proposed to indicate that a parking space is "marked".
• (Residential) parking zones are mapped by using the zone=* schema (parking:side:zone instead of parking:condition:side:residents=*).
• To record staggered parking on narrow roads, the tag parking:both:staggered=yes is proposed. A similar concept (parking:condition:either_side_only=*) was already proposed in the original parking:lane proposal, but never documented and will be deprecated.

Regarding separately mapped parking areas,

• parking=on_kerb, parking=half_on_kerb and parking=shoulder are proposed beside the existing parking=street_side and parking=lane to clearly distinguish different parking positions.
• parking:orientation=* will be deprecated and replaced by orientation=* (see above).

Rationale

The parking:lane=* schema was introduced during the early years of OSM. It is usable, but has some weaknesses and is unnecessarily complicated and therefore unattractive for many mappers. The existing schema makes it hard for editors to support it. Above all, in many ways it differs from today's OSM conventions. Here are some main issues:

• The primary key for mapping the "physical" attributes of parking is unnecessarily complicated and in some cases not logical, for example...
  • ...the naming of the primary key parking:lane contains the unnecessary suffix lane, which makes the key longer and more confusing and whose values partly contradict the term "lane" (e.g. on kerb or street side parking is not lane parking in general understanding and also in the sense of OSM - see parking=street_side and parking=lane).
  • ...the current notation parking:lane:side:type for mapping the parking position is unnecessarily complicated because the specific orientation (type) of the parking lane is included as part of the key. This notation offers no advantages, but it does have some disadvantages (complexity in mapping and evaluation, error-proneness).
• The tagging of parking restrictions is currently based on a unique tagging system instead of using the established keys access=*, fee=* and maxstay=*. In the former parking:condition=* schema, different categories of restrictions are mixed in just some values for one single key. The choice of former values did not always correspond to the diverse situations that can exist worldwide, so sometimes rather pragmatic solutions had to be found (like residents;ticket when access and fee are interfering or the use of disc for indicating a time limit although there are countries und parking lots where no parking disc is used for this purpose.)
• Parking spaces mapped as areas with amenity=parking are mapped in a completely different way than parking spaces mapped with the parking:lane=* schema, although both variants could be applied for one and the same on-the-ground feature.
• The schema has some weaknesses (e.g. issues with "marked" parking spaces, see above) and minor gaps for special situations (e.g. alternating parking on both sides on roads that aren't wide enough), which can be closed within this revision.

In conclusion, the current parking lane schema is unintuitive and hard to understand and therefore very unattractive for many mappers. To be able to map or maintain street parking attributes, it is currently necessary to "study" the schema intensively. Although the schema exists for 12 years, street parking spaces have rarely been mapped in the past (see section on the use of the schema). When mapping, many mistakes or misinterpretations can occur. A new schema, which is easier to use and follows common OSM conventions, would counter these problems.

The successful revision of the parking conditions one year ago has already provided some improvement to further existing problems, but during this process there has been much discussion about the general shortcomings of the schema and its need for reform. There were also concrete ideas for revisions to the schema, but these were not followed up at first due to the effort needed. During a recently proposed minor improvement of the existing parking lane schema, comments for a complete revision instead of step by step "cosmetic" improvements came up again.

Tagging

Physical tagging

There are two main attributes that describe on-street parking on a physical level:

• The position – e.g. vehicles are parked on the lane, on_kerb...,
• The orientation – vehicles can park parallel, diagonal or perpendicular to the street.

Position

Parking along a street is mapped by adding parking:side to the street line (tagged highway=*). side should always be specified explicitly and stands for the side of the street where parking is located (based on the direction of the street line; values are left, right or both). If there is no parking, this should be mapped, too. Use one of the following values:

Key	Value	Illustration	Description
parking:side	lane		Parking on the street (which could be easily converted to a travel lane). (Replaces on_street).
	street_side		Parking only in parking bays adjacent to the carriageway, which could not easily be converted into a travel lane.
	on_kerb		Parking on sidewalk.
	half_on_kerb		Parking partially on sidewalk.
	shoulder		Parking on the  shoulder, i.e. hard, paved or unpaved sections beside the road not normally meant to be driven on.
	no		There is no parking. This refers only to the physical presence of a parking lanes, not the legal condition.
	separate		The parking features are mapped as separate areas with amenity=parking + parking=*.
	yes		There is parking alongside the street, but it is not specified where exactly. Use one of the more specific values above instead, if possible.

Orientation

If there is parking, add the orientation of the vehicles if possible. Use parking:side:orientation and one of the following values for this:

Key	Value	Illustration	Description
parking:side:orientation	parallel		Vehicles have to park parallel to the road.
	diagonal		Vehicles have to park diagonally. Also known as angle parking or echelon parking.
	perpendicular		Vehicles have to park at a 90° angle so that the front or back of the vehicle is pointing straight towards the road centerline.

Other physical attributes

Other physical attributes of the parking can be added, e.g.

• parking:side:surface for the surface=* of the parking space.

Some other physical attributes also seem suitable, but should be used with caution:

• parking:side:width for the width=* of the parking space: In many places, depending on the orientation of the vehicles and the local norms, parking lanes have a default width that doesn't need to be mapped explicitly, but there may be variations from this like very narrow or very wide parking spaces.
• parking:side:capacity for the capacity=* of the parking space: The capacity should not be mapped in general, as it is prone to errors if another mapper changes the road geometry, e.g. splits it, without adjusting this value. Furthermore, the capacity can usually be derived precisely from the length of the road segment and the orientation of the vehicles. However, this number may be helpful in cases where the number of parking spaces differs significantly from the expectation based on the length and tags of the street segment and where geometry changes do not seem likely, e.g. because the streets are already recorded in a very precise and differentiated way.

Marked parking spaces

To record whether parking spaces are marked or not, use parking:side:markings and one of the following values:

Key	Value	Illustration	Description
parking:side:markings	yes		There are (some kind of) markings. This includes different surfaces, kerb-side markings, etc.
	no		There are no markings.

Deprecation:

The former parking:lane=* schema used the tag parking:lane:side=marked which resulted in a loss of data since there was no way to tag the orientation (parallel/diagonal/perpendicular). The same is true for the tag parking:lane:side:type=painted_area_only which prevented to map the position (on_street/on_kerb/etc.). Part of this proposal is to deprecate those tags and record the information about markings in a separate tag instead.

Possible follow-up proposal:

Some mappers might be interested in recording the precise design of the markings (e.g. lines, dots, hooks, surface, colour...), even if this mostly follows typical local patterns. Suggestions for this are out of scope of this proposal, but on this proposal page there are first ideas for their tagging if needed.

Special rules on parking direction

Sign from Germany stating "Parking head in only"

Back-in angle parking (sign in California)

Sometimes there are special rules that determine the direction of parking/driving into a diagonal or perpendicular parking space. These include back-in angle parking (reversed/back-in diagonal parking - a traffic engineering technique intended to improve the safety of on-street parking) and rules for head in or back in perpendicular parking (e.g. to prevent car exhausts from reaching the roadside). When such rules apply, they are usually signposted with a special sign or are indicated by markings.

This proposal extend the schema to allow recording these rules with parking:side:direction:

Key	Value	Illustration		Description
parking:side:direction	back_in			The vehicle must be parked with the rear facing the side of the road (i.e. with the front facing the middle of the road). In combination with parking:side:orientation=diagonal, this means Reversed/back-in diagonal parking (parking space direction is inverted in this case).
	head_in			The vehicle must be parked with the front facing the side of the road (i.e. with the rear facing the middle of the road). Note: Usually only exists in combination with parking:side:orientation=perpendicular, as head in parking is the standard for diagonal parking and does not need to be explicitly tagged. For back-in diagonal parking, see back_in above.

Staggered parking on narrow roads

Staggered parking:
parking:both=lane
parking:both:orientation=parallel
parking:both:staggered=yes

On some streets, parking is theoretically possible on both sides, but they are too narrow so that in practice parking is only possible on one side without obstructing traffic. In many places, one of the both sides is used for parking regularly in this case (vehicles are "traditionally" parked on one side or because it is structurally more convenient, e.g. on a side where there are no driveways), which can be well represented by parking:side (e.g. parking:left=no + parking:right=lane).

However, it can also happen that the vehicles parked staggered — sometimes on one side, sometimes on the other. The adjacent picture shows, that this also has an influence on the driving line of the flowing traffic.

This proposal introduces parking:both:staggered=yes to record such situations. All other attributes (parking:side, parking:side:orientation etc.) are tagged as if the vehicles parked on both sides.

Note: The original parking lane proposal mentioned parking:condition:either_side_only=yes for this situation, but this tagging was never documented and is rarely in use. Part of this proposal is to deprecated and replace this tagging.

Also note: For indications like this, we assume motor vehicles with more than 2 wheels/more than 1 track, especially motorcars. Parking lanes are usually designed for this purpose. Apart from that, we have other concepts in OSM for explicit motorcycle or bicycle parking.

Restriction tagging

Besides the physical properties of parking (see above), there are legal properties that we can map as follows.

Note: legal and physical properties are different informations, that should also be recorded separately. E.g., if there is no parking present on the right side, use parking:right=no and add tags that describe why there is no parking.

Switch to common access, fee and maxstay tagging

This proposal aims to align street parking condition/restriction tagging to the tagging of other (parking) features. Therefore, access=*, maxstay=* and fee=* should be used to map parking restrictions. The former parking:condition=* schema will be deprecated.

• parking:side:access=*: Who can/can not use the parking space? Is it public and/or for special user groups/vehicles?
• parking:side:maxstay=*: Is there a maximum period of time you are allowed to park here?
• parking:side:fee=*: Do you have to pay to park here?

Conditional restrictions are used to map temporary parking conditions. See examples for more details.

Adding a key for action-based restrictions

access=* (user group and vehicle type restrictions), maxstay=* (time limits) and fee=* can cover most types of parking restrictions. However, there is a class of rather "action-based" restrictions in parking, which is difficult to map with these keys. In particular this includes detailed tagging of why parking is prohibited (no parking vs. no stopping) as well as loading zones or parking spaces for charging electric vehicles.

We propose to use parking:side:restriction=* to cover this kind of restrictions (examples below). Those restriction imply that no regular parking is possible.

No parking, no stopping, no standing

No parking and no stopping are restrictions that are commonly used worldwide with similar traffic signs. Where parking is not allowed, stopping is still possible (e.g. to drop off or pick up someone or something). In contrast, with a no stopping restriction, a vehicle is not allowed to stop at all (unless due to traffic conditions or an emergency). In a few countries (USA, parts of Canada, Phillippines), there is also a no standing restriction (also called no waiting in some places, but don't mix it up with the meaning of "no waiting" in the UK, which is used synonymously with "no parking"). The exact meaning of these categories may vary from country to country and should always be used according to local regulations and signage.

• Use parking:side:restriction=no_parking, if there is no parking at any time (same for no_stopping and no_standing).
  It is recommended to add parking:side=no in this case to explicitly indicate the absence of a parking lane in the physical sense.
• Use parking:side:restriction:conditional=no_parking @ ..., if parking is not allowed at certain times/under certain conditions (same for no_stopping and no_standing).
  Following the established usage of conditional tagging, we can add multiple conditions like parking:side:restriction:conditional=no_parking @ ...; no_stopping @ ....

Tagging	Sign examples
parking:side:restriction=no_parking Parking is not allowed. However, you may stop or stand here.
parking:side:restriction=no_standing Standing is not allowed. Implies, that parking is also not allowed. However, you may stop here.
parking:side:restriction=no_stopping Stopping is not allowed. Implies, that parking and standing are also not allowed.

none can be used as a value to override restrictions if they are indicated as default but are not valid under certain conditions, e.g.

• parking:side:restriction=no_parking + parking:side:restriction:conditional=none @ (Mo-Fr 10:00-18:00), if parking is allowed during daytime in a no parking zone, or
• parking:side:restriction=no_stopping + parking:side:restriction:bus=none, if buses are excepted from a no stopping restriction.

See the example section below on how to use this in other typical situations, in combination with conditional restrictions or transport mode restrictions.

Loading zones and other action-based parking

There are parking facilities with similar action-based, mostly short-term restrictions. This includes designated loading zones or parking spaces for charging electric vehicles. They also can be mapped using the restriction tagging. In contrast to the no_parking/no_stopping values above, they define a "positive" exclusive restriction. Similar to turn restriction values and similar to the road signs used in many places, we add _only to the value to make this clear.

		parking:side:restriction=loading_only	Implies, that parking is no allowed, but stopping is allowed as long as loading is in progress (or a signposted time limit has expired).
		parking:side:restriction=charging_only	Implies, that stopping, standing or parking is allowed as long as charging is in progress (or a signposted time limit has expired). Also implies, that there is an exclusive access for electric vehicles, so you don't have to tag an additional parking:side:access=* restriction explicitely.

In case there is a time limit for this dedicated parking facilities, add parking:side:maxstay=*.

Access restrictions for specific user groups or vehicle types

access=* is used as usual to specify user group restrictions, e.g.:

• parking:side:access=private for a parking facility dedicated to a non-public user group, e.g. residents or employees (parking:side:private=* is in use as an addition to specify this more precisely, e.g. parking:side:private=residents),
• parking:side:access:conditional=customers @ (Mo-Fr 10:00-18:00) for parking that is dedicated to customers of a particular facility during the day.

parking:side:access=yes is the default and therefore can, but does not have to be specified explicitly.

Rules that only apply to certain vehicle types are used as usual with the specific access keys for transport mode restrictions, e.g.

• parking:side:hgv=no for a parking lane that is prohibited for trucks or
• parking:side:access=no + parking:side:bus=designated for a parking lane for busses.

So access=* restricts the users who are allowed to use a parking facility. Whether the excluded groups are still allowed to stop or wait on the parking facility is often not explicitly signposted, so it depends on local laws. In these cases, access=* tagging is sufficient to describe the situation. If parking or stopping restrictions are explicitly designated for a certain vehicle type, however, this can be tagged explicitly using the new restriction tagging:

• parking:side:restriction:hgv=no_stopping for a no stopping restriction that only applies to trucks.

See also examples for more cases and details.

Time limits

If you are only allowed to park for a certain time, this is indicated by using maxstay=*, e.g.:

• parking:side:maxstay=2 hours for a maximum time of two hours,
• parking:side:maxstay:conditional=30 minutes @ (Mo-Fr 10:00-18:00) for short term parking of 30 minutes during daytime,
• parking:side:maxstay:motorhome=1 day for a maximum length of parking that only applies to recreational vehicles.

The former parking:condition=* schema used the value disc to indicate this on the primary level. However, in many places, parking discs are not used for controlling the parking limit, but other, e.g. digital systems. During the proposal process, users suggested to use the authentication=* schema to explicitely map this, e.g. parking:side:authentication:disc=yes. But since this is part of an other proposal, this tagging will not be approved by this parking proposal.

Fees and charge

Use fee=* to indicate whether a parking fee has to be paid or not. E.g.

• parking:side:fee=no for a free parking without paying a fee,
• parking:side:fee=yes + parking:side:fee:conditional=no @ (Mo-Fr 20:00-24:00; Su) for paid parking which is free in the evenings and on Sundays,
• parking:side:fee=yes + parking:side:fee:conditional=no @ (stay < 30 minutes) if the fee only has to be paid after a certain time, e.g. not for short-term parking (see stay duration condition in conditional tagging).

Optional, the charge for parking can be specified, e.g.

• parking:side:charge=1.50 EUR/hour for an hourly charge, or
• parking:side:charge=4.00 USD/hour + parking:side:charge:conditional=2.00 USD/hour @ (stay > 1 hour) for a fee that is $4 for the first hour, but only $2 from the second hour.

Residential parking permits, parking zones

In residential parking zones you need a parking permit for residents or, possibly, need to pay otherwise. Such area based residential parking permits often carry some sort of letter or code identifying the area wherein they are valid. This can be recorded using the key:

• parking:side:zone=*

If residents' parking is exclusive, i.e. truly only for residents with the corresponding permission, use:

• parking:side:access=private (don't use permit, since this does not match our OSM definition: A resident parking permit is not "routinely granted to everyone requesting it". parking:side:private=residents can be added to specify the e.g. residential use.)
• parking:side:zone=*: Add the number, letter or code of the residential parking zone if possible. If multiple zones overlap, they can be recorded separated by semicolons (e.g. parking:side:zone=21;31).

If parking requires either a residential permit or a ticket and is therefore possible for all who pay a fee, use:

• parking:side:access=yes (default)
• parking:side:fee=yes
• parking:side:zone=*

Note: fee=* usually refers to charges that you have to pay "on the spot" for the purpose of parking. Residents' parking permits also cost a fee in many places, but they are not paid at the place of parking. However, it is not necessary to express this by complicated conditional tagging such as parking:side:fee:conditional=no @ residents, as this is already implied by the zone=* tagging.

Reasons for parking restrictions

The revision of the parking conditions one year ago has added parking:condition:side:reason for tagging the reason why certain restrictions like no parking, no stopping or a maximum limit of parking apply. With this new proposed schema, these can still be recorded using reason as a suffix to parking restriction keys or simply as parking:side:reason in case of "physical" reasons, e.g.:

	No parking in this area, this is a turnaround (cul-de-sac). parking:both:restriction=no_parking parking:both:restriction:reason=turnaround
	No parking on Wednesday for street sweeping/cleaning: parking:right:restriction:conditional=no_parking @ (We 10:00-12:00) parking:right:restriction:reason:conditional=street_cleaning @ (We 10:00-12:00)
	Narrow road and parking therefore not acceptable on at least one side: parking:left=no parking:left:reason=narrow

See also the approved list of reasons for parking restrictions.

Separately mapped parking spaces and areas

Instead of mapping street parking with parking:side as a side-dependent property of the highway=* centerline, it is also possible to map parking areas alongside the street as a separate feature (using amenity=parking). In general, it is not necessary to map street parking separately, if the parking information can be mapped sufficiently accurate at the street centerline, because this can be evaluated more easily. However, in the case of complex geometries (e.g. frequently separated street-side parking bays) or frequent changes in the physical or legal characteristics of the parking areas, it can be preferable to record this information separately instead of omitting relevant information or fragmenting the street centerline.

To map a parking feature separately, draw an area of the same extent as the real parking area. You can also map it as a node, if it's just a small area or individual parking space. Add amenity=parking, the matching parking=* value according to the parking position (e.g. parking=street_side or parking=half_on_kerb) and further properties like orientation=*, access=* or fee=*. The tagging of physical and legal properties is almost identical to the tagging on the centerline, except there is no prefix parking:side and the type of parking is specified directly with parking=*. See some examples below (assuming the shown parking situation is mapped separately) or parking=street_side for more details.

Add parking:side=separate to the street centerline if the parking along the street is mapped separately - unless other parking regulations still apply on the carriageway itself, e.g. if parking still take place on the carriageway between separated street-side parking bays or if the separate information only applies to individual parking spaces within the parking lane. All properties of the separately mapped parking feature (orientation=*, access=* etc.) are tagged on the separate geometry.

For mapping single parking spaces inside of the amenity=parking area, use amenity=parking_space as documented.

street_side parking	on_kerb parking	single disabled parking space
amenity=parking parking=street_side orientation=perpendicular access=yes fee=no capacity=4	amenity=parking parking=on_kerb orientation=perpendicular access=yes fee=no	amenity=parking parking=half_on_kerb orientation=parallel access=yes access:conditional=no @ (Mo-Fr 06:00-17:00; PH off) disabled:conditional=designated @ (Mo-Fr 06:00-17:00; PH off) fee=no capacity=1

Examples

The following examples illustrates the new tagging by comparing it with the old variant (assuming that the parking is mapped as properties of the highway centerline, with a direction pointing "into" the picture).

Physical properties

Example picture	New tagging	Old tagging
	parking:both=lane parking:left:orientation=parallel parking:right:orientation=perpendicular	parking:lane:left=parallel parking:lane:right=perpendicular parking:lane:left:parallel=on_street parking:lane:right:perpendicular=on_street
	parking:left=no parking:right=street_side parking:right:orientation=perpendicular	parking:lane:left=no parking:lane:right=perpendicular parking:lane:right:perpendicular=street_side
	parking:left=on_kerb parking:right=half_on_kerb parking:both:orientation=parallel	parking:lane:both=parallel parking:lane:left:parallel=on_kerb parking:lane:right:parallel=half_on_kerb
	parking:left=lane parking:left:orientation=parallel parking:right=no parking:right:reason=narrow	parking:lane:left=parallel parking:lane:left:parallel=on_street parking:lane:right=no parking:condition:right:reason=narrow

Parking restrictions: Common signs

To keep it simple, all examples assume a parking lane on the right side of the road.

Note that all tagging examples are also applicable on separately mapped parking spaces/areas (with amenity=parking) if you leave out the subkey parking:side! (E.g. amenity=parking + access=yes + fee=no for the first example.)

Sign	New tagging	Old tagging
	parking:right:access=yes (Public access - always the default.) parking:right:fee=no (This is a free parking with no other restrictions.)	parking:condition:right=free
	parking:right:maxstay:conditional=2 hours @ (Mo-Fr 08:00-17:00) (There is a time limit on weekdays from 8 to 17.) parking:right:authentication:disc:conditional=yes @ (Mo-Fr 08:00-17:00 (Suggested to explicitly record the usage of a parking disc - see also this section.)	parking:condition:right=free parking:condition:right:conditional=disc @ (Mo-Fr 08:00-17:00) parking:condition:right:maxstay:conditional=2 hours @ (Mo-Fr 08:00-17:00)
	parking:right:access=no (No one is allowed to park here...) parking:right:motorcar=designated (...except motorcars.)	parking:condition:right:motorcar=free
	parking:right:fee=yes (You have to pay a fee...) parking:right:maxstay=1 hour (...and parking is limited to a maximum of one hour.)	parking:condition:right=ticket parking:condition:right:maxstay=1 hour
	parking:right:maxstay:conditional=2 hours @ (08:30-17:30) (There is a time limit of two hours from 8:30 to 17:30.)	parking:condition:right=free parking:condition:right:maxstay:conditional=2 hours @ (08:30-17:30)
	parking:right:restriction=no_parking (By default, there is no parking.) parking:right:restriction:conditional=none @ (Mo-Fr 08:00-18:00) (However, you may park here on weekdays from 8 to 18.) parking:right:maxstay:conditional=30 minutes @ (Mo-Fr 08:00-18:00) (For a maximum of 30 minutes.)	parking:condition:right=no_parking parking:condition:right:conditional=free @ (Mo-Fr 08:00-18:00) parking:condition:right:maxstay:conditional=30 minutes @ (Mo-Fr 08:00-18:00)
	parking:right:restriction:conditional=no_stopping @ (Mo-Fr 08:00-17:00, Sa 08:00-14:00, Su 08:00-13:00) (Stopping is prohibited at certain hours.)	parking:condition:right=free parking:condition:right:conditional=no_stopping @ (Mo-Fr 08:00-17:00, Sa 08:00-14:00, Su 08:00-13:00)
	parking:right:restriction:hgv=no_parking (Parking is prohibited for lorries and trucks - explicitly means, stopping is still allowed for them.)	parking:condition:right:hgv=no_parking
	parking:right:restriction:hgv=no_stopping (Stopping is prohibited for lorries and trucks.)	parking:condition:right:hgv=no_stopping

Parking restrictions: Typical situations

This table illustrates the tagging of parking restrictions for different typical situations. To keep it simple, all examples assume a parking lane on the right side of the road.

Description	Image	New Tagging	Old tagging
Residential or ticket parking zone Residents get parking permits, parking for non-residents allowed with ticket. Example: Residential permit for zone "60" or ticket needed from 09:00-22:00, free at night and on Sundays.		parking:right:fee=yes parking:right:fee:conditional=no @ (Mo-Sa 00:00-09:00,22:00-24:00; Su) parking:right:zone=60	parking:condition:right=ticket;residents parking:condition:right:conditional=free @ (Mo-Sa 00:00-09:00,22:00-24:00; Su) parking:condition:right:residents=60
Parking only for residents Residents get parking permits, but nobody else is allowed to park here. Example: Nobody is allowed to park here except residents with permit for zone "IIIIIIIIII".		parking:right:access=private parking:right:zone=IIIIIIIIII Note: parking:right:private=residents is in use to specify access=private more precisely. Note: This permit is not "routinely granted to everyone requesting it", so don't use access=permit.	parking:condition:right=residents parking:condition:right:residents=IIIIIIIIII
Disc parking Parking is allowed for a maximum of a designated period of time. The start time is recorded with a parking disc. Example: From Monday to Friday between 09:00 to 18:00 and on Saturdays between 09:00 to 14:00 parking is allowed for a maximum of two hours.		parking:right:maxstay:conditional=2 hours @ (Mo-Fr 09:00-18:00; Sa 09:00-14:00) parking:right:authentication:disc:conditional=yes @ (Mo-Fr 09:00-18:00; Sa 09:00-14:00) (suggested to explicitly record the usage of a parking disc - see also this section.)	parking:condition:right=free parking:condition:right:conditional=disc @ (Mo-Fr 09:00-18:00; Sa 09:00-14:00) parking:condition:right:maxstay:conditional=2 hours @ (Mo-Fr 09:00-18:00; Sa 09:00-14:00)
No parking/stopping zones, clearways Parking (and standing or stopping, depending on local legal situation) is not allowed (at all or at certain times). In commonwealth countries, there are special concepts for this like clearways or red routes. Example: Vehicles are not allowed to stop between 06:00 and 10:00 from Monday to Friday.		parking:right:restriction:conditional=no_stopping @ (Mo-Fr 06:00-10:00) parking:right:restriction:reason:conditional=clearway @ (Mo-Fr 06:00-10:00)	parking:condition:right=free parking:condition:right:conditional=no_stopping @ (Mo-Fr 06:00-10:00)
Loading zone Parking is not allowed, but standing for loading or unloading is explicitly designated. Example: Designated loading zone from 07:00 to 18:00, except Sunday, with a time limit of 30 minutes.		parking:right:restriction:conditional=loading_only @ (Mo-Sa 07:00-18:00) parking:right:maxstay=30 minutes	parking:condition:right=loading parking:condition:right:maxstay=30 minutes
Charging electric vehicles Parking for charging electric vehicles. Example: Parking only allowed for vehicles during charging. Between 08:00 and 18:00, the maxstay time period is 4 hours.		parking:right:restriction=charging_only parking:right:maxstay:conditional=4 hours @ (08:00-18:00)	parking:condition:right=charging parking:condition:right:maxstay:conditional=4 hours @ (08:00-18:00)
Taxi waiting area A waiting area for taxis where other vehicles are not allowed to stop.		parking:right:access=no (No access for the general public, because...) parking:right:taxi=designated (...this area is designated for taxis.) If you want to record the signposted no stopping condition explicitely, add: parking:right:restriction=no_stopping (Stopping is explicitely not allowed here...) parking:right:restriction:taxi=none (...except taxis.)	parking:condition:right=no_stopping parking:condition:right:taxi=free
Disabled parking A public parking area reserved for people with a disability. Example: The parking area is reserved for people with disabilities on weekdays between 06:00 and 17:00.		parking:right:access=yes parking:right:access:conditional=no @ (Mo-Fr 06:00-17:00; PH off) parking:right:disabled:conditional=designated @ (Mo-Fr 06:00-17:00; PH off)	parking:condition:right=free parking:condition:right:conditional=disabled @ (Mo-Fr 06:00-17:00; PH off)

Parking restrictions: Complex signs

Sign	Tagging
	No stopping in the morning, parking with a limit of 30 minutes during day time. parking:right:restriction:conditional=no_stopping @ (Mo-Fr 07:00-09:00) parking:right:maxstay:conditional=30 minutes @ (Mo-Fr 09:00-18:00)
	Sign says: (1) no stopping from 9-15, (2) no parking from 7-9 and 15-18, except busses, that may park for a maximum of 30 minutes during this hours. parking:right:restriction:conditional=no_stopping @ (09:00-15:00); no_parking @ (Mo-Fr 07:00-09:00,15:00-18:00) parking:right:restriction:bus:conditional=none @ (Mo-Fr 07:00-09:00,15:00-18:00) parking:right:maxstay:bus:conditional=30 minutes @ (Mo-Fr 07:00-09:00,15:00-18:00)
	2 hours maximum parking during day time, except residents with parking permission "A". parking:right:orientation=perpendicular parking:right:maxstay:conditional=2 hours @ (Mo-Sa 08:00-21:00); no @ residents parking:right:zone=A
	Half on kerb parking with ticket during certain hours or residential permit. parking:right=half_on_kerb parking:right:orientation=parallel parking:right:fee:conditional=yes @ (Mo-Fr 09:00-19:00; Sa 09:00-16:00) parking:right:zone=A
	Parking only for busses at certain times, but other vehicles are explicitely allowed to stop. parking:right:restriction:conditional=no_parking @ (Tu-Fr 09:00-18:00; Sa-Su 10:00-18:00) parking:right:restriction:bus:conditional=none @ (Tu-Fr 09:00-18:00; Sa-Su 10:00-18:00) parking:right:bus:conditional=designated @ (Tu-Fr 09:00-18:00; Sa-Su 10:00-18:00) can be added to indicate, that buses are explicitely designated.
	Passenger/commercial loading zone and temporary clearway (no stopping zone at certain hours) with various loading, psv and maxstay restrictions in Australia. Applicable on a road segment left of the sign (bus and loading zone): parking:right:restriction=loading_only (Loading zone "all other times". parking:right:restriction:conditional=no_stopping @ (Mo-Fr 07:00-10:00,16:00-20:00) (Clearway 4-7pm Mo-Fr, bus zone 7-10am, 4-8pm Mo-Fr) parking:right:restriction:reason:conditional=bus_lane @ (Mo-Fr 07:00-10:00,16:00-20:00); clearway @ (Mo-Fr 16:00-19:00) Applicable on a road segment right of the sign (loading and taxi zone): parking:right:access=no parking:right:taxi=designated parking:right:access:conditional=yes @ (Mo-Fr 05:00-16:00) parking:right:restriction:conditional=loading_only @ (Mo-Fr 05:00-16:00); no_stopping @ (Mo-Fr 16:00-19:00) (Loading zone 5am-4pm Mo-Fr; clearway 4-7pm Mo-Fr) parking:right:restriction:reason:conditional=clearway @ (Mo-Fr 16:00-19:00)

Temporary bus lane, but vehicles may park otherwise. At certain hours, also loading is allowed on the bus lane. parking:right=lane parking:right:orientation=parallel parking:right:restriction:conditional=no_stopping @ (Mo-Fr 06:00-19:00); loading_only @ (Mo-Fr 09:00-15:00) (Overlapping conditional hours: the latter (loading_only) overwrites the former (no_stopping).)

Commuter parking lot with multiple restrictions. This is no street parking, so map a separate parking area with amenity=parking in this case. But note that all tags could be used in the same manner on a parking lane by adding parking:side as a prefix. Since there is no uniform orientation=* on this parking lot, orientation=perpendicular and orientation=diagonal could be added on separate amenity=parking_space areas, if one wants to micromap them. amenity=parking parking=surface access=yes goods=no + hgv=no ("Commercial vehicles not allowed". Note: This restriction is difficult to map accurately in OSM.) access:conditional=private @ (Mo-Fr,Su 19:00-07:00) ("Overnight Parking License Required 19-7 Su-Fr" - private, because it's only granted to residents.) restriction:conditional=no_parking @ (We[-1] 02:00-07:00) restriction:reason:conditional=street_cleaning @ (We[-1] 02:00-07:00) ("No Parking 2-7 For Field Cleaning Last We Each Month" fee=no maxstay:conditional=4 hours @ (Mo-Fr 08:00-02:00); no @ commuter ("4hr Parking 8-2 Mo-Fr Without Commuter License") direction=head_in ("All cars head in parking only".)

Data migration from current to the new schema

Numbers of usage of the current schema

Currently (as of the end of October 2022), about 260.000 road segments in OSM have "primary" parking lane tagging (parking:lane:both=*, parking:lane:left=* or parking:lane:right=*), and another about 20.000 segments have parking:condition=* or parking:lane=* attributes without primary tagging. This is the current usage of the most important tags:

	both	left	right
parking:lane:*=*	More details at taginfo	More details at taginfo	More details at taginfo
parking:condition:*=*	More details at taginfo	More details at taginfo	More details at taginfo

260.000 road segments sounds a lot at first, but it is quite few compared to other highway properties. For example, about 8 million road segments are tagged with lit=*. If we take a closer look at the spread of the tagging schema (we did this based on an actual OSM planet file), we can see local concentrations where individual mappers have contributed a significant amount of the total data. Here are some indicators to assess the usage of the current schema (as of the end of October 2022):

• About 37.000 kilometres of road network have parking information (a significant number of these are long highways without parking, e.g. in Colorado, US).
• About 20.000 kilometres of road network have at least one parking lane mapped (parking:lane:side=* without no/no_parking/no_stopping).
• About 6% of all parking lane usages originates from Berlin (Germany), although only about 22% of the road network of the city have parking lane information. If a single large city like Berlin were fully mapped with parking lane attributes in OSM, it would therefore currently contribute a quarter of all data available in OSM.
• Helsinki (Finland) also has a lot of data. Berlin and Helsinki together represent 13% of our global OSM parking lane data.
• Even smaller cities such as Bamberg (Germany, 80.000 inhabitants) or Salamanca (Spain, 145.000 inhabitants), where local mappers mapped a lot of data many years ago, currently each reach about 2% of the world's OSM parking lane data.
• Since the release of the StreetComplete parking overlay in late September 2022, the amount of parking lane data in OSM had already increased significantly by almost 15% within one month until the end of October and 25% until the end of November. So within a few months, more data could have been recorded with StreetComplete than in the previous 12 years altogether.

These indicators show that the schema is still not adopted on a wide scale, which could make data migration easier. The current strong increase by a single editor also shows the potential that parking data in OSM could develop in the future.

Call for participation: Updating parking lane data

Replacing an established tagging schema with a new one leads to a situation where both variants are initially in use at the same time. Mappers and editors have to decide for one variant (in the case of this proposal, there are hopefully no reasons to stay with the old schema) and applications have to decide whether they support both variants or only one of them. Ideally, it is possible to transform a lot of old data into the new schema as quickly as possible. In the short term, there is a risk that data will be "lost" to applications, but in the long term, the new schema will hopefully lead to an increase in usable data, as it will be easier to capture and maintain them.

Call for participation: To support data migration, the following actions are possible and some are already being addressed by the proposal authors. Anyway, help is urgently desired in any case!

• Automated edits are possible, but not specifically planned yet as the requirements are difficult and the data situation is complex especially for parking condition/restriction tagging. Moreover, some of the existing data is already several years old and could perhaps benefit from a closer look during the update.
• Local mappers are encouraged to check and update data in their area. Semi-automated edits with checking the individual road segments are possible and should be announced locally.
• A "translation" from old to new tags is possible and a dictionary provided below. We started developing a simple online tool that can help mappers with updating street parking data. Who can help with this?
• There is a Parking lane style for JOSM, which we have already updated for test purposes. It visualises the new tagging in the familiar way and also makes road segments with old tagging clearly visible. For comparison, however, the meaning of the old tagging is still visible.
• We are in contact with parking lane information users and developers (StreetComplete, AB Street, Zlant, Berlin Parking Project). Updating such applications to the new schema quickly can help to support and accelerate the data migration. Developers are open to this, but are grateful for any support.
• It would be useful if editors provide warnings for outdated street parking tagging in future, if the proposal is accepted.

Any further ideas and support very welcome!

Tools helping with updating parking lane data

• Overpass query showing highways with former parking:lane=* and parking:condition=* tagging.
• OSM Parking Lane Tag Updater: An easy to use tag updating tool, but still work in progress. Copy and paste old and new tagging or load data for a given OSM way ID. Check the results for plausibility and whether they are up-to-date, add missing tags and be aware of the Automated Edits code of conduct!
• Update for the JOSM-Parking-Lane-Style, that supports the new tagging, makes more attributes visible than before (parking position and some more restrictions) and also clearly highlights deprecated tagging. There is also a Preset that's just a word list for the new street parking tags helping with auto complete in JOSM.

Dictionary: old vs. new tags

To support the data migration process, we provide a "translation list" from old to new tags. It can be used by mappers and developers to update data and code more easily. It's the base for a online tool helping with updating parking lane tags.

(Semi-)Automated edits are also possible (see above), but are controversial and need their own discussion.

A more detailed list can be found here. The following overview lists the changes for the most common tags in reduced form:

old		new		notes
key	value	key	value
parking:lane:side	parallel	parking:side:orientation	parallel
parking:lane:side	diagonal	parking:side:orientation	diagonal
parking:lane:side	perpendicular	parking:side:orientation	perpendicular
parking:lane:side	marked	parking:side:markings	yes	orientation unclear - please specify if possible.
parking:lane:side	separate	parking:side	separate
parking:lane:side	no	parking:side	no
parking:lane:side	no_parking	parking:side	no	deprecated tagging already
		parking:side:restriction	no_parking
parking:lane:side	no_stopping	parking:side	no	deprecated tagging already
		parking:side:restriction	no_stopping
parking:lane:side	fire_lane	parking:side	no	deprecated tagging already
		parking:side:restriction	no_stopping
		parking:side:restriction:reason	fire_lane
parking:lane:side	yes	parking:side	yes	position and orientation unspecified - please specify if possible.
parking:lane:side:type	not specified	parking:side	yes	only if parking:lane:side is specified in old tagging - new position unspecified in this case. Please specify if possible.
parking:lane:side:type	on_street	parking:side	lane
parking:lane:side:type	half_on_kerb	parking:side	half_on_kerb
parking:lane:side:type	on_kerb	parking:side	on_kerb
parking:lane:side:type	street_side	parking:side	street_side
parking:lane:side:type	lay_by	parking:side	street_side	deprecated tagging already
parking:lane:side:type	painted_area_only	parking:side:markings	yes	position unclear - please specify if possible.
parking:lane:side:type	shoulder	parking:side	shoulder
parking:lane:side:capacity	...	parking:side:capacity	...
parking:condition:side	free	parking:side:fee	no
parking:condition:side	ticket	parking:side:fee	yes
parking:condition:side	disc	parking:side:authentication:disc	yes	note also maxstay tagging; parking:side:authentication:disc=yes is suggested to explicitly record the usage of a parking disc
parking:condition:side	residents	parking:side:access	private	note also residents/zone tagging
parking:condition:side	ticket;residents	parking:side:fee	yes	note also residents/zone tagging
parking:condition:side	residents;ticket	parking:side:fee	yes	note also residents/zone tagging
parking:condition:side	customers	parking:side:access	customers
parking:condition:side	private	parking:side:access	private
parking:condition:side	disabled	parking:side:access	no
		parking:side:disabled	designated
parking:condition:side	loading	parking:side:restriction	loading_only
parking:condition:side	no_parking	parking:side:restriction	no_parking
parking:condition:side	no_standing	parking:side:restriction	no_standing
parking:condition:side	no_stopping	parking:side:restriction	no_stopping
parking:condition:side:maxstay	...	parking:side:maxstay	...
parking:condition:side:residents	...	parking:side:zone	...

Features/Pages affected

• A new Street parking page will be created containing the (updated) informations of the former parking:lane=* and parking:condition=* pages and new contents from this proposal page. (Note: The term on-street parking should be avoided, as on street in the OSM sense was a special form/position attribute of [on-]street parking so far).
• A deprecation notice will be added to the parking:lane=* and parking:condition=* pages, that will refer to the new street parking page.
• Related pages (like example pages) need an update and relocation.
• There are some other pages that refer to street parking and may need updates or discussion about that. For example, fine=* mentions fine:parking:lane=* (in use).
• Parking and parking=* need an easily visible reference to the new street parking schema.
• orientation=* needs an update on how to use it in the parking context.
• Regional sign references (e.g., for California) need to be rewritten.

External discussions

• Talk:Proposed_features/Parking_lane_conditionals#Counter-proposal and User:Kovposch/Proposed features/Parking lane conditionals: First approach for a fundamental renewal of the parking:lane schema a year ago during the process of the revision of the parking conditions.
• Talk:Proposed features/parking:position: Discussion page of a recently created proposal for a slight "cosmetic" improvement of a single parking:lane aspect. Criticised for its lack of consequence to improve the whole parking:lane schema, it led to the writing of this proposal for a fundamental renewal.
• Proposed features/parking conditions on separately mapped parking areas and it's discussion page: Proposal that illustrated the issue of disharmony/different taggings between separately mapped and non-separately mapped parking spaces.
• Extensive discussion in the community forum about solutions to distinguish "graduations" of no parking (no standing/waiting, no stopping) as well as other "action-based" restrictions (loading, charging).
• Tickets to inform about this proposal in parking related editor repository and developer communities: StreetComplete, Zlant parking-lane Editor, A/B Street

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 51 votes for, 2 votes against and 1 abstention.

• I approve this proposal. --Nadjita (talk) 14:50, 24 November 2022 (UTC)
• I approve this proposal. --Tordanik 14:53, 24 November 2022 (UTC)
• I approve this proposal. Thank you for the hard work! --Discostu36 (talk) 15:08, 24 November 2022 (UTC)
• I approve this proposal. This is a big improvement, thank you! --Tordans (talk) 15:28, 24 November 2022 (UTC)
• I approve this proposal. --Popball (talk) 15:44, 24 November 2022 (UTC)
• I approve this proposal. --Riiga (talk) 17:15, 24 November 2022 (UTC)
• I approve this proposal. Something tells me this won't be the end of parking tagging churn, but it gets us to a much better spot, so that hopefully future improvements can be much more incremental. – Minh Nguyễn ^💬 19:06, 24 November 2022 (UTC)
• I approve this proposal. --- Kovposch (talk) 19:47, 24 November 2022 (UTC)
• I approve this proposal. --Cartographer10 (talk) 19:52, 24 November 2022 (UTC)
• I approve this proposal. Thanks for all the work on this! If the proposal passes, I'll be very happy to migrate all the parking I've mapped. --Rskedgell (talk) 19:59, 24 November 2022 (UTC)
• I approve this proposal. --Uboot (talk) 20:07, 24 November 2022 (UTC)
• I approve this proposal. Diacritic (talk) 22:11, 24 November 2022 (UTC)
• I approve this proposal. --Gislars (talk) 22:15, 24 November 2022 (UTC) Thanks for the hard work, I really appriciate it.
• I approve this proposal. --Westnordost (talk) 11:31, 25 November 2022 (UTC)
• I approve this proposal. Thank you for your work! This will make street parking much easier to map! --Wielandb (talk) 16:41, 25 November 2022 (UTC)
• I approve this proposal. --Tjuro (talk) 16:46, 25 November 2022 (UTC)
• I approve this proposal. Thank you for all the hard work that has obviously gone into researching and assembling this proposal! --ZeLonewolf (talk) 20:25, 25 November 2022 (UTC)
• I approve this proposal. -- Something B (talk) 21:09, 25 November 2022 (UTC)
• I have comments but abstain from voting on this proposal. I disagree with the change from parking:orientation=* to orientation=*. Every other parking tag starts with the word "parking", so I would like to keep this consistent. I agree with all the other parts of the proposal. --501ghost (talk) 21:41, 26 November 2022 (UTC)

All parking related tags that are recorded at the street centerline must start with the prefix parking:side:. parking:side:orientation is also used in this way. But at separately mapped parking features that are already identifiable as parking feature by the primary tag amenity=parking (e.g. parking=street_side features), this prefix is simply dropped. So on separately mapped parking features, there are no tags that start with parking: at all. In this case, simply orientation is used. --Supaplex030 (talk) 22:43, 26 November 2022 (UTC)

Okay, I see what you mean. But would you also use the values of the current orientation=* for parking orientation or would only the currently documented values be used? There seems to be an overlap with the meanings of orientation=medium and parking:orientation=diagonal. --501ghost (talk) 00:26, 27 November 2022 (UTC)

The values remain the same as before. See this discussion about the advantages and disadvantages of this possibly homonymous use. --Supaplex030 (talk) 14:36, 27 November 2022 (UTC)

• I approve this proposal. --Dimitar155 (talk) 20:14, 27 November 2022 (UTC)
• I approve this proposal. --Nw520 (talk) 01:34, 28 November 2022 (UTC)
• I approve this proposal. I've using street parking tagging recently and it was quite inconvenient. With the updated tagging scheme, it would make it easier to use and it adds additional functionality so I'm all for it. --Mxdanger (talk) 00:22, 29 November 2022 (UTC)
• I approve this proposal. --SherbetS (talk) 02:41, 29 November 2022 (UTC)
• I approve this proposal. --Billyonthemountain (talk) 12:57, 29 November 2022 (UTC) Thank you for your effort. This makes it much more coherent with the general tagging scheme.
• I approve this proposal. --K4pl4n (talk) 21:52, 29 November 2022 (UTC)
• I approve this proposal. This has the potential to bring a great deal of value to the world in terms of less expensive package delivery. Appreciate the hard work on building it out and gathering a consensus. And I prefer the simple orientation=* over parking:orientation=* --G Forman (talk) 23:07, 29 November 2022 (UTC)
• I approve this proposal. --Mcliquid (talk) 08:56, 30 November 2022 (UTC)
• I approve this proposal. Thanks for your time to incorporate the extensive feedback! --Herrieman (talk) 14:11, 30 November 2022 (UTC)
• I approve this proposal. Makes tagging parking lanes less of a pain. Hopefully it's going to be implemented in Vespucci as well! --Greenie11 (talk) 23:11, 30 November 2022 (UTC)
• I approve this proposal. --Woazboat (talk) 20:32, 1 December 2022 (UTC)
• I approve this proposal. Rtnf (talk) 05:29, 3 December 2022 (UTC)
• I approve this proposal. --Kjon (talk) 08:26, 3 December 2022 (UTC)
• I approve this proposal. --Lejun (talk) 16:31, 3 December 2022 (UTC)

• I have comments but abstain from voting on this proposal. Partially oppose. For Goal 1 I can't get the necessary, use left and right direction is very deceptive, and if left and right have same situation, why use a parking:lane=*, but we need to duplicated it when use new schema. --快乐的老鼠宝宝 (talk) 18:27, 3 December 2022 (UTC)

@快乐的老鼠宝宝: This proposal also proposes parking:both which avoids having to duplicate data for both parking:left and parking:right. --Nw520 (talk) 15:05, 4 December 2022 (UTC)

• I approve this proposal. --快乐的老鼠宝宝 (talk) 18:52, 3 December 2022 (UTC)
• I approve this proposal. --Cristoffs (talk) 13:55, 4 December 2022 (UTC)
• I approve this proposal. --Ptarac (talk) 14:05, 4 December 2022 (UTC)
• I approve this proposal. --Reino Baptista (talk) 14:22, 4 December 2022 (UTC)
• I approve this proposal. Thanks for the time that went into this extensive proposal! --Flo Edelmann (talk) 14:28, 4 December 2022 (UTC)
• I approve this proposal. --Fiszi37 (talk) 14:49, 4 December 2022 (UTC)
• I approve this proposal. For all the people involved in this proposal, thank you! --AntMadeira (talk) 15:01, 4 December 2022 (UTC)
• I approve this proposal. --TheBlackMan (talk) 15:20, 4 December 2022 (UTC)
• I approve this proposal. --clay_c (talk) 16:00, 4 December 2022 (UTC)
• I oppose this proposal. I don't see big improvements to deprecate the old scheme. I don't see new kind of info added with the new scheme and some tags that were be able with the old scheme are missing (residential, etc.) --Yopaseopor (talk) 16:35, 4 December 2022 (UTC)
• I approve this proposal. --Jemily1 (talk) 17:42, 4 December 2022 (UTC)
• I approve this proposal. --JB (talk) 17:49, 4 December 2022 (UTC)
• I approve this proposal. --Rmikke (talk) 17:58, 4 December 2022 (UTC)
• I approve this proposal. --Robybully (talk) 21:04, 4 December 2022 (UTC) I have no problem with the old version but prefer the supposed version.
• I approve this proposal. --Olr (talk) 00:04, 5 December 2022 (UTC)
• I approve this proposal. --Marek-M (talk) 08:58, 5 December 2022 (UTC)
• I approve this proposal. --Zorae (talk) 09:28, 5 December 2022 (UTC)
• I approve this proposal. --Hanif Al Husaini (talk) 06:27, 6 December 2022 (UTC)
• I approve this proposal. --Heilbron (talk) 09:09, 6 December 2022 (UTC)
• I oppose this proposal. Generally I'm fine with renew streetparking scheme. Only, the areas of parkingspaces should tagged as amenity=parking_spaces and definitly not as amenity=parking. --Bergaufsee (talk) 18:09, 6 December 2022 (UTC)
• I approve this proposal. --Cyton (talk) 18:48, 6 December 2022 (UTC)