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.
- 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.
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).
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.
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.
|parking:side||lane||Parking on the street (which could be easily converted to a travel lane).|
|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 the area.|
|half_on_kerb||Parking partially on the street/partially on the footpath area.|
|shoulder||Parking on the, 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 and its properties is mapped separately with amenity=parking + parking=*.|
|yes||There is parking alongside the street, but it is not specified where exactly. Use this tag only when none of the more specific values apply.|
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.
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:
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:
|parking:side:markings||yes||There are (some kind of) markings. This includes different surfaces, kerb-side markings, etc.|
|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 (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.
Use parking:side:direction and one of the following values to map these rules:
|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 (unless there is a sign which states that). For back-in diagonal parking, see back_in above.|
Staggered parking on narrow roads
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.
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)?
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 @ ....
Parking is not allowed. However, you may stop or stand here.
Standing is not allowed. Implies, that parking is also not allowed. However, you may stop here.
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.
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.
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).
Implies, that stopping, standing or parking is allowed as long as charging is in progress (or a signposted time limit has expired).
In case there is a time limit for this dedicated parking facilities, add parking:side:maxstay=*.
Alternate side parking
|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: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.
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:
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).
Note: Tagging 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).
|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.|
|No parking in this area, this is a turnaround (cul-de-sac).|
|No parking on Wednesday for street sweeping/cleaning:|
|Narrow road and parking therefore not acceptable on at least one side:|
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).
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.
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.)
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:restriction=no_parking (By default, there is no parking.)
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.
|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 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 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 parking is allowed for a maximum of two hours.
parking:right:maxstay:conditional=2 hours @ (Mo-Fr 09:00-18:00) parking:right:authentication:disc:conditional=yes @ (Mo-Fr 09:00-18:00) (suggested to explicitly record the usage of a parking disc – see also this section.)
|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 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.
|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.
|Taxi waiting area
A waiting area for taxis where other vehicles are not allowed to stop.
If you want to record the signposted no stopping condition explicitly, add:
A public parking area reserved for people with a disability.
Example: The parking area is reserved for people with disabilities on workdays between 06:00 and 17:00 (if this workday is not a public holiday, because “werktags” includes Monday to Saturday, unless it is a public holiday).
Tools and rendering styles
Using with JOSM
- There is a map paint style available called Parking lanes (or possibly a translation of this in the language you use JOSM with). It can be installed via JOSM's Map Paint preferences.
- There is also a set of tagging presets available under the same name. These can be installed via JOSM's Tagging Presets preferences.
Tools helping with tagging or editing street parking data
- The StreetComplete Parking Overlay is a very simple and intuitive way to collect street parking data. For this, start the Android OSM app StreetComplete, go to the "Overlays" selection via the settings menu at the top right and choose "Street parking". Now, streets are coloured according to existing parking space data. Streets with missing parking attributes are coloured in red. To add these information, simply click on the street segment and select the appropriate data for the left and right side of the street. If the position or orientation of the parked vehicles along the selected street segment changes, the street can be split using the menu at the bottom left (three dots).
- Using the Zlant Parking Lanes Viewer/Editor, parking lane information can be viewed and edited (for the latter, click on "Editor" at the bottom right). Based on background aerial photographs, parking space can also be mapped effectively and remotely.
- ParkingStudio, a tool that generates tagging for parking restrictions based on selected traffic signs (developed for German situation/signs). Works for both: parking lanes mapped on the street centre line as well as separately mapped parking areas (you have to choose after starting the tool).
Helpers to update old deprecated parking:lane=* and parking:condition=* data
In December 2022, the parking schema in OSM was completely reworked, i.e. a new schema (this one described on this page) was accepted and the previous schema (parking:lane=* and parking:condition=*) was deprecated. To avoid losing previous data permanently, they should be reviewed and converted to the new tagging. You are welcome to help with updating old data in your environment, if there are some. There are tools that can help:
- Overpass query showing highways with deprecated tagging. You also can use this query when downloading data with JOSM to only load road segments with deprecated parking tags.
- OSM Parking Lane Tag Updater: An easy to use tag updating tool that “translates” old tagging to the new one. Still work in progress – feel free to help. 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 if needed and be aware of the Automated Edits code of conduct if you use the tool on a larger scale.
- The subpage Translating deprecated default and time interval tagging contains instructions on how to update the sometimes complicated old default, time_interval and parking:lane:*:2/3/4 tags.
- A MapRoulette Challenge will probably follow later.
Using OSM parking data
Data consumers that require precise spatial data on street parking should consider that depending on the local legislation, implicit parking restrictions may exist that are not explicitly tagged in OSM, so some spatial post-processing may be required. For example, in most legislations throughout the world, parking is prohibited on and about 5 metres around intersections and crossings. Yet, few mappers bother to split up the road the first and last 5 metres of every road to map a no-stopping prohibition. In fact, some even deprecate this practice, as such restrictions are implicit or common sense.
Because street parking to the carriageway can also be mapped as separately areas, some spatial post-processing may be required anyway. In the case above, some possible parking spaces would need to be cut out around the intersection.
An OSM parking project from Berlin has demonstrated the methodology for processing such data. Depending on the accuracy of the collected data, very precise calculations of parking numbers and geometries are possible. Some basic informations about the project and its methodology can be found in an OSM blog post and in Geomob Podcast #154.
Here is a not necessarily complete list of situations that imply a parking restriction which can be found in many legislations and may not come with explicit tagging:
- On motorways and motorroads
- In pedestrian zones, throughflow and parking is forbidden but there may be exceptions for delivery vehicles
- In living streets, parking is usually only allowed in explicitly marked areas
- In some legislations generally on bridges and in tunnels
- Often priority roads (at least rural ones) and often on roads where overtaking is forbidden; i.e., where there is a continuous centre line
- In roundabouts and circular junctions (junction=roundabout, junction=circular should appear on road line in such cases)
- Usually in turning circles and turning loops
- On sections of the roadway marked with arrows, i.e. turn lanes – though often only on side where turn lanes are present
- In front of certain important signs such as the stop sign, saltires or yield traffic because obscuring these signs is dangerous
- At taxi stands and bus stops parking is prohibited. Depending on the legislation, stopping or standing may be allowed
- On and near pedestrian crossings, railway crossings, on tram tracks, etc. stopping is prohibited for obvious reasons. Some legislations allow at least stopping around (not on) crossings.
- At narrow points, sharp bends, fire rescue paths and other places where parking would put the parking car or other traffic in danger
- At entries to driveways and other places where there is a dropped kerb
- In some legislations also in front of police stations, post offices and hospitals
Most of this is common sense, but software does not know common sense. Also, some of these implicit restrictions may in some countries actually be explicitly signed.
- Parking for more information about mapping parking lots (that are not along a street)
- Opening hours for more information about the syntax to specify temporal restrictions
- amenity=vending_machine + vending=parking_tickets for parking ticket vending machines
- amenity=parking for details mainly about mapping parking lots/car parks
- parking=street_side for specific informations about separately mapping street-side parking bays
- access=* for describing the legal accessibility of a feature
- maxstay=* for the maximum time you are allowed to stay somewhere
- fee=* to indicate if money is charged to use a facility