Street parking

Street parking is a very common phenomenon, especially in cities, and is a dominant feature of the urban landscape in many places.

This page describes the mapping of street parking; i.e. parking lanes and spaces along streets. In contrast to car parks, street parking is usually recorded as a property of the street line mapped with highway=*. In certain cases, however, street parking can also be mapped as a separate feature (amenity=parking). The tagging of parking properties is similar in all variants. Street parking is characterised by more diverse rules and restrictions as well as physical attributes (such as the position and orientation of the vehicles) that are interesting to capture in OSM.

Quick guide

Quick example for physical tagging:
parking:left=lane
parking:left:orientation=parallel
parking:right=no

Quick example for legal tagging:
parking:right:maxstay=30 minutes
parking:right:fee=no
parking:right:access=yes (optional, as it is implied on public streets)

To map street parking properties on a way tagged with highway=*, use parking:side, where side is left, right or both and refers to the side of the street on which the parking is located (seen in the direction of the street (way) in OSM).
To record the physical properties of parking, use
- parking:side: Where are the vehicles located on the street? (lane, street_side, on_kerb, half_on_kerb, shoulder, separate or no, if there is no parking.)
- parking:side:orientation=*: How are the parked vehicles orientated compared to the street? (parallel, diagonal or perpendicular.)
To record the legal properties of parking, use
- parking:side:fee=*: Do you have to pay a fee to park here? (yes or no.)
- parking:side:maxstay=*: In the case there is a maximum period of time you are allowed to park here (e.g. 30 minutes, 1 hour or 2 hours).
- parking:side:access=*: Who can/can not use the parking space? Is it public and/or for special user groups/vehicles? (For examples see chapter on access restrictions.)
- parking:side:restriction=*: Is there a no_parking or no_stopping restriction or an other action-based restriction (loading_only or charging_only)?
Use conditional restrictions to map temporary parking restrictions, e.g. parking:right:maxstay:conditional=1 hour @ (Mo-Fr 09:00-18:00) for a maximum parking time of one hour on weekdays during the day.
In case you want to map street parking separately with its own geometry (e.g. a street-side parking bay), draw an area of the size of the parking facility and add amenity=parking + parking=* (e.g. parking=street_side). All other mentioned properties can also be added by simply dropping the parking:side prefix (e.g. orientation=parallel or fee=no). Add parking:side=separate on the street centre line to express, that the parking and all it's properties are mapped separately for the given side.
Former parking:lane=* and parking:condition=* tagging was deprecated and should no longer be used. If you know of places where these tags still exist, please update them if possible. There are tools that can help with finding and updating them.

Tagging

Street parking data are usually mapped as attributes of ways tagged with highway=*, but can also be mapped as separate parking features tagged with amenity=parking. In general, it is not necessary to map street parking as a separate feature, if the parking information can be mapped sufficiently accurate at the street centre line, because this can be evaluated more easily. However, in some situations it can be preferable to record this information separately instead of omitting relevant information or fragmenting the street centre line (see the chapter on separately mapped parking areas and spaces below).

Street parking tagging includes two basic levels of information:

Physical properties express the allowed position (e.g. on the carriageway or on the pavement) and orientation (e.g. parallel or diagonal) of parked vehicles as well as other properties like the surface of a parking lane.
Legal properties describe parking restrictions like who can park somewhere (residents, customers, specific vehicles etc.), when and how long they can park (time limits), whether they have to pay a fee, no parking or no stopping restrictions, loading zones and more.

Both, physical and legal properties, can be used independently of each other, they do not necessarily require the other. However, it's recommended to map them together if possible.

The roadway needs to be split up where any of the properties changes, for example, when parallel parking is available only alongside the first half of a way between two intersections, split the road and tag parallel parking on the first part and no parking at the other one. For very short changes or single parking spaces with other conditions, consider mapping them separately to avoid over-fragmenting the street line. Especially in places where the parking situation is very diverse, this can actually be easier to do and easier to maintain than to split the roadway into many small segments just to accommodate for the different parameters that change down the road. Note that some parking restrictions are implicit and don't have to be mapped explicitly (see “Using OSM parking data” below).

Physical properties

There are two main attributes that describe 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.

Parking position

Add parking:side to a way tagged with highway=* and one of the following values to record parking along a street. side can be left, right or both and should always be specified explicitly. It refers to the side of the street where parking is located (based on the direction of the street centre line in OSM). If there is no parking, this should be mapped, too.

Key	Value	Description
`parking:side`	`no`	There is no place for parking.
	`yes`	There is a place for parking, but nothing more specific. Reserve this value for when no other could be used.
	`lane`	On the carriageway, which could otherwise be traversed by vehicles.
	`street_side`	In parking bays adjacent to the carriageway, which could not otherwise be traversed by vehicles.
	`on_kerb`	Parking on the pavement.
	`half_on_kerb`	Parking spanning across the carriageway and pavement.
	`shoulder`	Parking on the shoulder, i.e. hard, paved or unpaved sections beside the road not normally meant to be driven on.
	`separate`	Parking is mapped with separate OSM objects, tagged with `amenity=parking` + `parking=*`.

Distinction between `street_side` and `lane` parking

Main: Tag:parking=street_side § Distinction between street side and lane parking

In general, a street_side parking area is a structural extension at the edge of the carriageway, whereas lane parking is on the carriageway itself. But in some cases, a distinction between street_side and lane parking can be difficult and depend on the subjective perception of the mapper. For example, in many places, it is common to extend the kerb at intersections and crossings to make it safer to cross for pedestrians. Those kerb extensions doesn't make a lane parking of an entire street into a street_side parking. But if there are many kerb extensions in one street, it may become a little hard to distinguish between these two situations in reality.

When mapping the carriageway width (width=* on the highway line), be aware that the carriageway width includes lane parking areas, but never includes street-side parking areas.

Parking orientation

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

Key	Value	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 centre line.

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, specifying the maximum capacity for a given stretch of parking may be useful in cases where the number of parking spaces differs significantly from the expectation based on the length of the road segment (e.g. because there are only some dedicated marked parking spaces) and where geometry changes are less 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.
`parking:side:markings=*`	`no`		There are no markings.

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. There are some suggestions on how to do that if needed.

Special rules on parking direction

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 on Wikipedia (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.

Germany ("Parking head in only")
United States
California

Use parking:side:direction and one of the following values to map these rules:

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 on Wikipedia (parking space direction is inverted in this case).
`parking:side:direction`	`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 (unless there is a sign which states that). 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 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 are parked in a staggered manner — sometimes on one side, sometimes on the other. As the adjacent picture shows, this also has an influence on the driving line of the flowing traffic.

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

Legal properties

Physical and legal properties of parking are different kinds of information, and therefore they should also be recorded separately. E.g., if there is no parking present on the right side, use parking:right=no (as a physical description) and add tags that describe why there is no parking.

There is a set of keys that describe different legal parking restrictions:

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?
parking:side:restriction=*: Is there a prohibition of parking (no parking or no stopping) or other rather action-based restrictions (load and unload, charging electric vehicles)?

All of them can be used with conditional restrictions to map temporary parking conditions (e.g. parking:side:maxstay:conditional=*). See the following examples for more details.

No parking, no stopping, and 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, Philippines), 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.

It should be noted that parking restrictions can be lifted inside marked areas only. Aside from adding markings=yes to the parking, the exact tagging procedure wasn't clarified. Multiple solutions have been found:^[1]^[2]

Omit parking:side:* (note that data consumers can't know whether a parking restriction is restriction=no_parking, restriction=no_standing or restriction=no_stopping which is relevant)
Map the individual parking spaces separate and add parking:side:parking=separate and parking:side:restriction (this omits parking:side:markings=yes from the road since that's handled by the amenity=parking)
Map the individual parking spaces separate and add parking:side:parking=no and parking:side:restriction (this omits parking:side:markings=yes from the road since that's handled by the amenity=parking)
Use a conditional restriction like parking:side:restriction:conditional=restriction @ unmarked
Don't treat parking:side=yes and parking:side:restriction=* mutually exclusive and use both at the same time
Treat parking:side=yes and parking:side:restriction=* mutually exclusive and split the street where parking spaces exist and where they don't.

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 are also mapped by using the restriction tagging.

Tagging	Sign examples
`parking:side:restriction=loading_only` Implies, that parking is not allowed, but stopping is allowed as long as loading/unloading 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 explicitly.

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

Alternate side parking

Sign	Tagging
	`parking:right:restriction:conditional=no_parking @ ("First half of each month")`
	`parking:right:restriction:conditional=no_parking @ ("Second half of each month")`
	`parking:right:restriction:conditional=no_parking @ ("Odd days of each month")`
	`parking:right:restriction:conditional=no_parking @ ("Even days of each month")`

Note: With the current revision of the opening hours schema, it is not properly possible to express these days, see Talk:Street parking#How to map alternate side parking?, which is why we are using prose here, which is allowed in the opening hours schema.

Access restrictions for specific user groups or vehicle types

access=* is used 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 on public streets and therefore does not have to be specified explicitly.

Rules that only apply to certain vehicle types are used 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:motorcar=designated for a parking lane that is for motorcars only.

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.

In many places, parking discs are used for controlling the parking limit. parking:side:authentication:disc=yes is suggested to record that explicitly and can also be adapted for other authentication=* systems.

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=* (e.g. A, 20 or blue, depending on the local zone code concept).

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

It can be useful to indicate why certain parking restrictions apply. This allows e.g. telling an implicit restriction (like a narrow road, no stopping in a turnaround or on the left of a dual carriageway street) from an explicit one (like no stopping signs on a busy thoroughfare) as well as mapping signposted reasons (like street cleaning). Use reason=* as a suffix to parking restriction keys (mainly parking:side:restriction:reason) or just parking:side:reason in case of “physical” reasons (see examples below the following table).

This is optional. The list of reasons below is not a complete list, just a collection of the most common ones. Some of the values refer to “geometric” implicit restrictions (like driveway or junction) – usually it's not necessary to split a street line in order to map such implicit restrictions (see § Using OSM parking data below).

Key	Value	Description
`parking:side:reason` / `parking:side:restriction:reason`	`bus_lane`	There is a bus lane, where according to local legislation, certain rules apply.
	`rails`	There are rails on the lane. According to local legislation, certain rules apply.
	`bus_stop`	This is a bus stop, where according to local legislation, certain rules apply.
	`crossing`	This is near a crossing, where according to local legislation, certain rules apply.
	`cycleway`	There is a cycleway, where according to local legislation, certain rules apply.
	`driveway`	This is near a driveway, where according to local legislation, certain rules apply.
	`dual_carriage`	This way is part of a dual carriageway, where according to local legislation, certain rules apply.
	`fire_lane`	This is a fire lane that must be kept clear for possible fire engines, or other emergency vehicles.
	`junction`	This is part of a junction and according to local legislation, certain rules apply.
	`loading_zone`	This is a zone for loading and unloading of goods and/or passengers.
	`markings`	There are markings on the ground. According to local legislation certain rules apply.
	`narrow`	This is a narrow street, influencing the ability to park here.
	`passenger_loading_zone`	This is a zone for loading and unloading of passengers only, not goods.
	`priority_road`	This is a priority road. According to local legislation certain rules apply.
	`street_cleaning`	This is a street cleaning zone where vehicles intermittently may not be allowed to park, stand or stop. This includes snow removal.
	`turnaround`	This is a zone for turning a vehicle around, typically at a cul-de-sac.
	`turn_lane`	This is part of a turn lane and according to local legislation, certain rules apply.

Examples:

	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`

Separately mapped parking areas and spaces

Instead of mapping street parking with parking:side as a side-dependent property of the highway=* centre line, 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 centre line, 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 centre line.

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 identical to the tagging on the centre line, 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 (which is the most common category of separately mapped street parking) for more details.

Add parking:side=separate to the street centre line for all sides (left, right or both) where 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 and as part of a amenity=parking area, use amenity=parking_space as documented. The use of amenity=parking_space always requires that there is a “parent” area with amenity=parking that includes this single parking space. All properties of the enclosing parking area also apply to individual mapped parking spaces unless otherwise tagged there. The tags should therefore not be repeated for each individual parking space if they are the same. On the other hand, for example, an individual disabled parking space can be mapped within the parking area by “overwriting” the restrictions for this space – e.g. access=no + disabled=designated (or parking_space=disabled, that should be interpreted the same way in this case).

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

Examples

The following examples illustrates how street parking tagging is used (assuming that the parking is mapped as properties of the highway centre line, with a direction pointing “into” the picture).

They show typical situations. For more complex situations, take a look at the advanced examples page.