[null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/9/94/Fee9-19exceptF.png", "src": "https://wiki.openstreetmap.org/w/images/9/94/Fee9-19exceptF.png", "formatted_filename": "Fee exceptF", "alt_text": "Fee9-19exceptF.png", "rendered_width": 161, "rendered_height": 206}, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/9/97/Residents_or_ticket.png", "src": "https://wiki.openstreetmap.org/w/images/9/97/Residents_or_ticket.png", "formatted_filename": "Residents or ticket", "alt_text": "Residents or ticket.png", "rendered_width": 119, "rendered_height": 260}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/1/1d/Parkinghaltingdifferenttimes.png", "src": "https://wiki.openstreetmap.org/w/images/1/1d/Parkinghaltingdifferenttimes.png", "formatted_filename": "Parkinghaltingdifferenttimes", "alt_text": "Parkinghaltingdifferenttimes.png", "rendered_width": 104, "rendered_height": 316}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/1/10/Parkinghaltingdifferenttimesmaxstay.png", "src": "https://wiki.openstreetmap.org/w/images/1/10/Parkinghaltingdifferenttimesmaxstay.png", "formatted_filename": "Parkinghaltingdifferenttimesmaxstay", "alt_text": "Parkinghaltingdifferenttimesmaxstay.png", "rendered_width": 125, "rendered_height": 350}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/a/a5/Parkinghalting3conditions.png", "src": "https://wiki.openstreetmap.org/w/images/a/a5/Parkinghalting3conditions.png", "formatted_filename": "Parkinghalting conditions", "alt_text": "Parkinghalting3conditions.png", "rendered_width": 75, "rendered_height": 188}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/0/0f/Buses30minandothers.png", "src": "https://wiki.openstreetmap.org/w/images/0/0f/Buses30minandothers.png", "formatted_filename": "Buses minandothers", "alt_text": "Buses30minandothers.png", "rendered_width": 159, "rendered_height": 377}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/c/c1/Sign_no_parking_zone_residents.jpg", "src": "https://wiki.openstreetmap.org/w/images/c/c1/Sign_no_parking_zone_residents.jpg", "formatted_filename": "Sign no parking zone residents", "alt_text": "Sign no parking zone residents.jpg", "rendered_width": 99, "rendered_height": 160}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/e/ed/No_parking_except_resi_A.png", "src": "https://wiki.openstreetmap.org/w/images/e/ed/No_parking_except_resi_A.png", "formatted_filename": "No parking except resi A", "alt_text": "No parking except resi A.png", "rendered_width": 133, "rendered_height": 180}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/c/c5/Sfscsignsmall.jpg", "src": "https://wiki.openstreetmap.org/w/images/c/c5/Sfscsignsmall.jpg", "formatted_filename": "Sfscsignsmall", "alt_text": "Sfscsignsmall.jpg", "rendered_width": 100, "rendered_height": 150}, null, {"document_url": "http://wiki.openstreetmap.org/wiki/Talk:Key:parking:lane", "unformatted_src": "/w/images/1/17/Waysplit-3.png", "src": "https://wiki.openstreetmap.org/w/images/1/17/Waysplit-3.png", "formatted_filename": "Waysplit", "alt_text": "Waysplit-3.png", "rendered_width": 400, "rendered_height": 189}, null]
From OpenStreetMap Wiki

(This page is currently a merger of the (now abandoned) Talk:Proposed_features/parking_lane and User_talk:Kay_D/parking and thus work in progress.)


Making it more or less complicated?

I am well aware that parking is horribly complicated in places. So the proposal is clearly a 80:20 approach. Making it too simple means it will be useless for most purposes, making it more complicated means little gain. So the proposal is based on the current situation (no lane parking in the database yet) and tries to cover the most widely used parking conditions and rules. Following are discussions on how to make it simpler or more sophisticated.

Simpler approach to start with?

I find this too complicated already. Why don't we hijack parking=* for highway=*s, and take it from there? I don't think the specific shape of the parking spots is particularly interesting in itself, but restrictions are more more important, like vehicle size, time of day, maximum stay, etc. parking=* could grow a couple more values, plus we could use other keys already in use for amenity=parking. In it's most simple form, parking=yes would indicate that some form of parking is explicitly allowed. --Stefan Bethke 21:08, 31 May 2009 (UTC)

I'm just playing along here with what the original proposer came up with; that's likely the better choice for the main key. Alv 21:31, 31 May 2009 (UTC)

I've since started adding these as plain parking:both=inline/diagonal parking:left=parallel, parking:left=*, parking:right=* as I have some other details to add. Extends IMO nicely to parking:left:placement=*, parking:fee:times=*, parking:right:fee:times=* etc. Alv 13:15, 3 December 2009 (UTC)

This is exactly what I have been searching for! Tags like parking:left=inline would be great to mark some parts of a street with parking possibilities without having to tag an area for this. Additionally, I would propose some tag like parking:left=bay if there's an area that goes along with the street but is separated from it in some way (e. g. little areas with trees between) and clearly designed to be a parking area. --L3u 18:44, 30 March 2010 (UTC)

I'm definitely in favor of a simpler approach like described. what do others think and how should we proceed? --Marc 13:50, 17 December 2009 (UTC)

This is relevant to the newer proposed format with parking:lane:*, too. IMO rather just parking:left=* etc. Alv 07:42, 28 April 2010 (UTC)

Is it possible to map parking signs, rather than parking lanes? The signs could indicate left/right/both sides of road, forward/back/both, and sign content? Sign content could be added progressively (as data), or as text alone? Maps could render the sign contents, for instance forward to the next sign. In some instances a sign might relate to a whole town, like a speed limit, or only a street, like park two hours. The benefit of this approach is to more simply map only signs and let logic and renderers do all the interpretation work. When we map areas, we are doing the heavy interpretation lifting with brain power, not computer power. This approach could be used for speed signs. Maps the signs, not the road that the signs apply to. For instance, the 30 signs in the parking photo examples. areff2000 04 February, 2011

Use case. (1) I am interested in using the parking data and OSM to make a 'Free Parking' app for iPhone. I could interrogate OSM based on my current position and current (or future) time and day to find parking space which have no parking restrictions (within displayed map). Alternatives would include one or two hour parking. (2) Disabled parking spaces should be priority to map and discover. areff2000 04 February, 2011

Just make sure it's flexible enough

The possibilities of left, right, and centre parking are all independent of each other, and are going to need to be specified separately. I can think of a location near me that has all three, and certainly the restrictions are different in two of them.

(Although now that I think about it, a street with centre parking is usually modelled as two separate ways...which makes it complicated to decide which of those ways owns the centre...) Stevage 15:41, 3 December 2009 (UTC)

In France some streets have alternate side of allowed parking depending on the day in the month. The first 15 days of the month you need to park on one side, the rest of the month you need to park on the opposite side. Julien Balas 15:15, 15 april 2010

What about mixed parking situations?

Especially in residential areas you'll often find a mixed situation with both parallel and perpendicular parking lanes mixed on each side of the street that cannot properly be described with the existing keys in your proposal (parking:lane:XY) unless the street is splitted into dozens of individual segments. I suggest to add an additional key parking:lane:mixed or something similar to handle these situations easily. --@themis 19:04, 9 March 2011 (UTC)

Is it an area?

In my proposal, the general assumption is: when parking space is an area, then by all means map it as {tag|amenity|parking}. The other cases are if there's no extra allocated space for parking, then it's lane parking. There's a grey area when the lane parking space is on a kerb.

parking-slots mapped as area

Where should also be an possibility to tagg parking-slots as an area, because in some areas also the streets are mapped as an area. I think amenity=parking should be tagged and parking=lane. --Aighes 14:51, 28 April 2010 (UTC)

Left and right still does not work

As already said on other pages, :left and :right don't work when the map gets better.

Blind persons (See OSM for the blind) need the exact way coordinates of the footway and the parking lane.

Parking lanes are usually bigger than 5m diameter, so they should be mapped as areas, just like buildings of the same size would be mapped.


When someone draws the sidewalks and the lanes and all the like (I'm doing the sidewalks already), it's possible to draw dedicated roadside parking lanes/slots as areas. But until then (and it's nowhere near for quite some time), the parking lane data (with :left/:both/:right is usable for other use cases. And even when parking on the edge of the road, but within the driving lane, is allowed, there isn't an area that could be drawn separately, but it's the whole lane (which, by that time, could be drawn as an area) that has parking allowed. Alv 10:12, 22 April 2010 (UTC)

This proposal is mostly for parking on the streets or on kerbs. So it "makes no sense" to map those as separate areas (that's what {tag|amenity||parking} is for). However, I agree with Lulu-Ann that it is favourable to map lane layout better than we are currently doing. Since I see this not happening soon, I can assure you that the edits done here are migratable in an automatic way to a next better tagging scheme, so the work done now is not lost. Kay D 20:07, 27 April 2010 (UTC)

More than one parking condition

Ticket with an interval, but free with a permit ← This is a very common situation, that the current proposal doesn't fully address:

Between Mo-Fr 09:00-19:00 parking is with tickets (zone 2), except if you have a residential permit with the label E.

I believe I'll find something more complex, too, but I'll have to go for a drive for that. Alv 10:51, 29 April 2010 (UTC)

See Image to the right for an analogue sign in german. I tried with parking:condition:right=residents_or_ticket (see here for the street with that sign), but that's not good in all situations: It is then not clear what the time_interval is for: is it only for the fee (as in the image), or also for the residents? I seem to remember a street where during daytime, a fee is due, but at nighttime, only residents are allowed. Then we needed two time_intervals, see example with multiple conditions below. --Kay D 23:01, 6 May 2010 (UTC)

If the condition is included in the key, when otherwise ambiguous?

To avoid confusion, I'd take your proposal one step further, and make the specification of the time_interval always required. The parking conditions to which the time_interval or maxstay duration applies should always be specified, as part of the key name. The values "no_parking" and "no_stopping" should be parking conditions, as they might be time dependent (while parallel, diagonal, perpendicular are physical features, unlikely to be time-dependent). As the tagging is complicated, I suggest that it's safer not to assume default values, that is for any given time at least one parking condition must be specified. I assume that the condition "residents" means "free for residents". Otherwise it would probably better to expand the condition values to cover all cases ("residents_free", "residents_ticket", ...). Examples:

--Kaitu 00:28, 2 April 2011 (BST)

Disc parking (maxstay) or free for residents

Different intervals for no_stopping and no_parking These are on the same pole. Two lanes, no extra space between lanes and the sidewalk. Free parking every night, every sunday and saturdays after 15:00. Tagging ideas? ["(9-15)" is just "saturdays 9:00-15:00". Red numbers would be the interval on Sundays.] Alv 17:07, 29 April 2010 (UTC)

Since that are really two or three conditions, we need a means to specify more conditions in parallel, i.e. to enumerate them. One way would be like this:

The last condition:3 specifies the default (see section "default"). It may be omitted if rules can be found to determine the defaults reliably. This is complicated! It is not illogical or over-complicated, but cumbersome to specify without the use of specialized editors. (Josm-Plugin) --Kay D 13:06, 5 May 2010 (UTC) Another one; tram line on the road in the inner lane is kept free during the morning rush hours by the no_stopping, otherwise short disc parking in the daytime - free parking at other times. Alv 09:19, 10 May 2010 (UTC)

I've tagged this one as:

I feel that the most restrictive condition is best given with the plain key, as above, and the "other times/default" time interval is easier if left to interpreters. Alv 14:44, 7 September 2010 (BST) Here we have no stopping on workdays 15:00 - 18:00, no parking on workdays 07:00-15:00, ticket parking on Saturdays 09:00-15:00 - with a maximum of 60 minutes at a time, and free parking otherwise. Here we have no stopping every day 09:00 - 15:00, no parking on workdays 07:00-09:00 and 15:00-18:00 unless you're driving a bus (30 minutes with a parking disc), and free parking otherwise.

Different approach for conditions

Please take a look at this short suggestion for a generic approach for conditional key/value pairs: Splitting conditions and values

I would prefer a unified solution for this problem. --Imagic 09:05, 23 February 2012 (UTC)



How about motorcycle parking? They're always parked perpendicularly (orthogonally) (at least in my area) occuping the same space of cars parked inline. Something like this: [ ] = car, | = motorcycle: [ ][ ][ ]||||||| I'd say it's parking:lane:side=motorcycle. What's your opinion? --Nighto 00:08, 8 May 2010 (UTC)

In Würzburg there's a larger motorcycle parking place with diagonal parking :-) If we count the limitation to specific vehicles as a restriction similar to the other ones (e.g. residents), then it's parking:lane:side=perpendicular plus parking:condition:side:vehicles=motorcycle. Please see section Specifying the vehicles allowed to park below. --Kay D 21:59, 9 May 2010 (UTC)


There are some areas with "parking permitted for loading/unloading" here in my area. Any suggestion about how to tag those? parking:condition:side=loading? Don't know if there's a better expression in english, since it's not my main language. --Nighto 00:08, 8 May 2010 (UTC)

Seems sensible, except I'd probably prefer as parking:condition:side=no_stopping + parking:condition:side:except=loading - or no_parking for the former tag, if that's the rule. Alv 14:50, 7 September 2010 (BST)

Physical space?

with parking:lane:side the physical property of the parking is described: e.g. inline parallel, diagonal, orthogonal perpendicular. But also "parking is not possible" here is doable with no_parking, no_stopping etc.

However, the latter two may be evident by road layout, there may be no signs around to tell so. Furthermore, the parking places could be described more in detail, so an alternative would be:

Specifying the vehicles allowed to park

To quote Ralf K.:
"wenn ich es nicht übersehen habe fehlt noch wer dort parken darf, also PKW, Busse, LKW, Motorräder etc. Es gibt ja durchaus spezielle Parkbereiche für Reisebusse oder Motorräder (in WÜ z.B. hinter dem Dom oder in der Eichhornstraße)."
["If I didn't overlook it, the following is still missing: who may park where, e.g. cars, buses, HGV, motorbikes, etc. There are special parking areas for tourist buses or motorbikes (in Würzburg behind the Cathedral, or in the Eichhornstraße)."]

Specifying the vehicles allowed to park should be consistent with Key:vehicle.

Two possibilities spring to mind:

(1) Add more information to the parking conditions

(2) Limitation to certain vehicles is a separate property

Writing this, I have a slight preference to (1). Example: Friesstraße (Motorcycle parking) or Husarenstraße (Bus parking).

One I've now encountered on several residential roads is the combination "no parking" "(applies to) trucks", sometimes with "and buses". So far I've used parking:lane:*=parallel parking:condition:except=hgv;bus as it would be near impossible to list all allowed classes in ...:vehicles. Alternative would be parking:condition:bus=no_parking + parking:condition:goods=no_parking. Alv 14:09, 23 June 2010 (UTC)

Less common "vehicles"

So far I've come across

Default rules

In cases where parking is restricted to a time interval, what are the default rules, i.e. outside the interval?


For legal terms in Germany, the solution is like this:

If the time interval is on the same (physical) sign (i.e. sheet of metal) as the limitation (see first row in table above), then the time interval applies to the restriction on that sign, i.e. the restriction is time-limited, outside of the interval, no restriction is given.

Otherwise (no restriction there), the parking itself is time-limited. See second row in the table above.

It may be possible that there are two (or more) restrictions with different time intervals. This proposal explicitly ignores those signs. It could be done by identifying the signs (sheets of metal), but the cost-benefit ratio is just too bad at this time.

Internationization Question:

Is this applicable for other countries, too?

Finnish roadside parking is probably never limited to residents only, but residents are often exempt from the fee that all others pay during the daytime. The rules for interpreting what the times on the sign apply to are roughly the same, a time limit sign only applies to what's directly above it. Alv 10:54, 5 April 2010 (UTC)

Extension of parking:condition to amenity=parking?

Parking places are not elegantly and consistently tagged. For example, this parking place is "only for residents with permit S7". It cannot be tagged, and furthermore is it "fee=yes" or "fee=no"? Neither. It is parking:condition:area=residents and parking:condition:area:residents=S7.

time_limit vs. maxstay

parking:condition:side:time_limit=2 h vs. maxstay=2h ? Alv 10:35, 5 April 2010 (UTC)

That's a good idea, and I adopted it onto the main proposal page. Kay D 19:55, 27 April 2010 (UTC)

Wie ist der Rest?

Was ist mit einer Zone, wo parken nur in erlaubten Flächen erlaubt ist? Die erlaubten zu taggen ist ja klar. Aber was ist mit dem Rest? So?Bzw. so?--ChristianKnorr 11:09, 15 April 2010 (UTC)

Just use parking:lane:left=no_parking or =no_stopping. Trying to put non-parking-zones into the database is quite difficult otherwise: Polygons are not the correct thing to do so (they are only 2 dimensional and fail for situations with bridges). So for the moment I just propose to tag each street with no_parking for whatever reason it is not allowed to park there. And in the end, a user (navi) of the data does not really care why he is not allowed to park... Kay D 21:39, 29 April 2010 (UTC)

Parking in the street

How can this be used for areas where there are parking in the street without any marked spots or a set system. This is common in many residential areas, for example the street where I live. In my street there is allowed to park on one side of the street except for some spots, generally infront of garages. No spots are marked, and no signs are put up mentioning the side allowed to park (the oposite side is marked with a no-parking sign. --Skippern 22:51, 24 May 2009 (UTC)

Local law sets the system, tag accordingly, or what's the question? Alv 06:25, 25 May 2009 (UTC)

My question is how to tag this, I guess parking_lane=left can do it, but I feel that all the values for type of parking (parallel, diagonal, perpendicular) are inappropriate. Maybe an additional value can be of interest, to indicate that the space is directly in the traffic lane, and not in a separate marked lane. Maybe parking_lane:left=street can indicate this? (when no cars are parked, this is part of the normal traffic flow) --Skippern 14:59, 25 May 2009 (UTC)

Ok. I'd say it's still parallel parking. I'd make up a tag for the position, say parking_lane:right:placement=lane / dedicated / half / outside. "In lane" may block a lane on the street while the others don't. "Half" and "outside" even have corresponding signs in use, that is to park with two wheels on the curb or to park with the whole car on the outside of the curb. An extra cautious sports car driver might not want to drive up the curb, although such support in software is unlikely for a long time.
A road around here, that normally has two lanes for each direction but allows parking on the right lane in the nighttime: oneway=yes + lanes=2 + parking_lane=right + parking_lane:right:placement=lane + parking_lane:right=parallel + parking_lane:right:hour_on=18 + parking_lane:right:hour_off=7. Alv 15:47, 25 May 2009 (UTC)

Thanks, that clarified it a bit better. --Skippern 15:52, 25 May 2009 (UTC)

I'm still pondering, whether the word dedicated above is good. The dedicated (as painted on the ground) parking spaces on the side don't interfere with even hgv's driving by, but for unmarked spaces it's variable. If the lane is extra wide, there's room for up to four hgv's side by side at any point (2 x parked + 2 driving), even without dedicated spaces, yet it's still a two lane road. Other times only oncoming passenger cars can pass each other and even a bus blocks the traffic while it's on that road section. A more descriptive word might be better; meaning that the space in which the cars may park is on the road side of the curb, yet not on the area normally used for travel. Alv 11:08, 26 May 2009 (UTC)

I'm not particularly happy about the left/right designation. It's yet another thing you have to watch out for when you have to reverse a way. Are there examples of left/right designations in other tags? --Stefan Bethke 21:11, 31 May 2009 (UTC)

Only other ways to do it would be relations with named roles, or extra ways (or even areas) along the sides of the road and how overkill would that be at this time? And actually, if it were the other way round, that is left:parking_lane=x JOSM already suggests to change it to right:parking_lane=x if the way is reversed. I'd be surprised to see anything use these tags in the near future and by the time they'd have any value things would have settled down and would have been likely corrected. Better have some likely correct data than no data, when it's not like it's gonna kill someone. Alv 21:31, 31 May 2009 (UTC)

Shorter keys (or without underscore) and values

The same goes for on_street, as I think the value is not on the same axis as "painted" vs. on the curb... The parking is either in the driving lane - given a wide enough road and no signs to the contrary, one can park on the edge of the driving lane, partly blocking the lane - as the other lane remains open. Where the lane is wide enough for a truck (the widest allowed vehicle allowed on roads is 2.55 meters, the extra width on the lane is effectively dedicated to parking, painted lines or not. I'll try to dig up some example photos, eventually. Alv 11:11, 29 April 2010 (UTC)
I've now added some pictures in Proposed_features/parking:lane/Examples, feel free to correct the tagging if it's not as you think it should be according to the proposal. Alv 09:31, 30 April 2010 (UTC)

Cool, I added some more, some with markings, some without. In Germany, in some areas, markings are used, but they are only a suggestion, and in some areas (explicitly stated on a sign) parking is allowed only within markings. --Kay D 22:47, 6 May 2010 (UTC)

That's then different, here parking is only allowed within marked slots, if such slots have been marked, by paint or otherwise. To the extreme case of 6 meter long cars (old US models, for example) being fined since they don't fit inside one 5 meter slot... Alv 16:43, 19 May 2010 (UTC)


I'll get over this, but I'd rather the tag be "parking" rather than "parking_lane", and I'd rather the definition be something like "used when parking is allowed on or directly next to the way". The reason for these changes is that, where I live, parking is allowed on either side but there are no lanes specific for parking (as there are no lanes at all/one big lane). I'd have no problem tagging this with parking=both, but that doesn't seem to be allowed by the definition. Anthony 00:58, 24 October 2009 (UTC)

I cannot quite follow this. "lane" does not mean "extra space is available", but often means "use the driving lane for parking". And parking:lane:both=parallel is allowed by the definition, and allows parking on both sides of the road (either on the road, or on the kerb, depending on space/laws/signs). See also Proposed_features/parking:lane/Examples for a possible clearification. --Kay D 22:47, 6 May 2010 (UTC)

Parking capacity

There are two possible situations when describing the parking capacity of a parking lane. For marked spots, an exact number can be given with capacity=*. For non marked ones, or a mark for the whole parking lane, an estimated number could be given with capacity:estimated=*. Knowing an estimated number of the street parking spots is interesting for many reasons :) --Nosolomusic 07:13, 7 September 2009 (UTC)


Thinking about this a bit, are we sure the default should be no parking? Maybe the default could be parking=both, and we could tag parking=no for highways where parking is not allowed. Anthony 01:11, 24 October 2009 (UTC)

I think yes, it should be no parking. local law is what the user should know before parking, no matter what OSM or any navigation service based on OSM is telling him. If parking is allowed he can put his car everywhere he wants. Even so there can be dedicated parking spots or at least streets that are manly used for parking by locals whereas others are not, although law would permit it (but you just don't put your car everywhere, even if you could). And thats what we should map: some sort of "common sense" used by locals / visitors of the region. By setting the default to no we encourage the community to map parking spaces that are explicitly used by residents / local population, regardless of if they are marked on the street or not. If indeed all the streets in city are used for parking, then map it like that, as long as it does make sense to do so. but most times it just doesn't. the other argument is rendering: useless if the default is yes. I would say the default is "no" in the sense of law tells you what to do. areas marked with explicit no parking signs can be tagged with no (therefore an explicit tag exists, and a renderer can interpret that by adding the corresponding style to a street), streets with parking allowed with yes/both/left/right. --Marc 14:01, 17 December 2009 (UTC)

Non-Parking Zones In Germany (probably other countries, too) there's an option to declare a whole area ("Zone") as non parking. This saves the authorities to set up "no parking" signs at each stretch of road.

Tagging should, however still be on a road-to road basis. Reasons for this are:

Stopping/halting shouldn't be part of parking-tagging

It would make complex cases (like alv pointed above) easier to handle, if no_stopping would not be part of parking-tags, but have its own tag.

Maybe same for no_parking, as sometimes there might be complex rules (time intervals, residential parking, fee, etc.), same applies to firelanes and similia consepts in other countries.

Example (from alv's post above):

no_parking overrides parking, and no_stopping overrides both etc. Daeron 03:34, 7 May 2010 (UTC)

I liked the idea when I read it, because it seemed to make things less complicated. But I found some examples where it does not help:

This leads me to the conclusion that there will be eventually about as many exceptions as with the regular :condition tag. And using only the condition scheme is a bit more clear than having the option (or necessity) to use both at the same time. --Kay D 12:37, 7 May 2010 (UTC)

I'm not saying that no_parking should always be used when there's the round sign with diagonal slash. But for at least the first and third one I'd use perhaps: no_parking=right, no_parking:right:except=residents/motorcar (or something similar). also the bus-only parking could be done like that, parking:right=inline, parking:right:only=bus (etc.). The private property sign might be more complicated, I'd maybe just tag it as access=private, and if there's some spaces for visitors, I'd tag those separately. Daeron 17:12, 7 May 2010 (UTC)

I found a similarly stupid sign today (see right, meaning "no parking, but residents with permit A are allowed") . It is identical to the blue sign that allows parking with an addition "only residents with permit A". If you would tag it with no_parking:right:except=residents (or whatever, the syntax is not so important), the problem is that you also have to specify how to park (e.g. inline), just as when the regular blue parking sign was present. So as I see it, as soon as -- for whatever reason, whatever vehicle, at whatever time -- is allowed to stay at this space, it should be considered parking. "no_parking" makes in my opinion only sense if there are no other conditions (exceptions) present, as exceptions would mean parking. And in the original proposal, too, if parking:lane:right=no_parking is specified, then no other :condition is to be supplied. --Kay D 22:58, 9 May 2010 (UTC)

At least here they normally use the version "no stopping, except ...", but when they think it's safe to designate parking spots on the straight edge of a T-intersection, they have to use the "Parking, only for ..." kind. Alv 08:36, 8 September 2010 (BST)

right / left ?

Besides the possible confusion between right ( opposite of left ) and the right ( as authorisation ) , the use of right / left makes only sense if the direction of the road is known. Except for one way streets this is not obvious and may be changed deliberately or by accident.
I therefore propose the use of absolute geographic directions like north, south, east or west. Fx99 06:52, 23 May 2010 (UTC)

Which then isn't unambigous for curved roads, depending on the angle of the turn (say, up to 180 degrees). In all editors the direction of the way element is shown to the user, and some editors even propose to change :left to :right when the way with such tags is reversed. Also, where the map is sufficiently complete that mappers have the time and energy to map these parking restrictions, the direction of any (highway) ways in the area is very unlikely to be reversed anymore - as they more often are in areas where users are just sketching in the roads on a blank canvas. Alv 08:28, 23 May 2010 (UTC)

orthogonal / inline

Have these words come out of a German/English dictionary? Perhaps US English is different (I'm British) but I would always talk about parallel parking for parking parallel to the road. Perpendicular is a much better known word than orthogonal and the latter is better known for meaning mutually independent. I had to read this a few times to be sure that by orthogonal, you don't mean that your car can point in the opposite direction to the direction of travel. The word inline to me would imply that you're talking about parking directly on the road as opposed to in a parking lane running along the edge of the road. I would also tend to the word "slanted" instead of "diagonal". --Opk 15:31, 4 August 2010 (BST)

Angle parking or echelon parking is a more common term for diagonal parking here in the UK. I have seen signs using the term echelon, for example, sign stating "End of echelon of parking". Also take a look at http://en.wikipedia.org/wiki/Parking modes of parking. --Netman55 10:45, 29 August 2011 (BST)

In some/many cases what's decribed by the parking:lane:*=* is really parking "directly on the road", for example the first picture on Proposed_features/parking:lane/Examples. While parallel is the common term, it's a bit prone to errors by non-native English speakers; in perpendicular parking the cars are parallel to each other. Personally, I'd agree that perpendicular is a more natural term, diagonal should stay, and i'm quite indifferent to inline vs. parallel. Alv 13:20, 9 September 2011 (BST)

I mostly agree with Alv, both angle and echelon are very confusing and non-selfexplanary to non-natives. For the other two cases, I'd prefer to select the ones used by natives since both alternatives are clear enough (although I perceive that the native ones have high probability for typing errors but you don't want to manually type all those parking tags anyway :-)). --Ij 17:46, 11 September 2011 (BST)

Agreed, I will change the following on the proposal page: inline→parallel and orthogonal→perpendicular. I think that "echelon" is highly idiomatic and thus not internationally easily understood, and "angle" seems a bit unspecific (what angle?), so let's stick with diagonal as it is unambiguous and intuitive. Kay D 12:20, 12 September 2011 (BST)

Alv and I changed (outside of this section) some occasions of the deprecated inline/orthogonal to the active values parallel/perpendicular. Knowing that it is impolite to alter other user's comments I decided to do so anyway as a courtesy for new readers to improve readability. Kay D (talk) 19:55, 5 March 2013 (UTC)

Migration to parallel and perpendicular

I suggest to do a one-time complete transition in the database, converting all instances from inline to parallel etc. Normally this is not a desirable solution to perform (people should decide whether to adopt a better scheme), but in this special case I suggest this handling because:

There are currently (to my knowledge) only two tools that handle these tags:

Kay D 12:20, 12 September 2011 (BST)

Implied no_*

In basic form a road is split only at intersections; that is, if a part of road allows parking between two intersections but not directly before the intersection, we don't expect users to split the road into three sections. Simple so far. But what about places where the road is already split before the intersection, for example there's an added lane for turning, or there's two oneway bits because of a divider?

Continuing the thought, should we encourage users to tag every dual carriageway road, or every short bit (from a divider) with parking:lane:left=no_stopping? Currently they're indistinguishable (in software) from proper oneway roads, which generally allow parking on the left? Only when we're tagging the right side as no_stopping, as any other parking:lane value, or every time?

These conditions go on, as there's (in some countries, at least) an implied parking prohibition where there's a solid line separating the lanes, and other conditions that don't (yet) have established tags. Alv 16:24, 13 June 2010 (UTC)

My 'prime directive' at the moment is: just tag what's useful for a person using the parking map. It is impossible to colour all places consistently for all possible situations. E.g. in narrow roads, although it's legally possible to park on both side of the road, as soon as one side is occupied, it's impossible to park at the other side :-) So I started experimenting a bit with specifying the reason for no_parking. One would be: parking:condition:right:reason=sign that a sign explicitly forbids parking. Another could be parking:condition:right:reason=narrow, or curve, or turning_lane (in Germany, when there are arrows painted on the road, e.g. "turn right", then no_stopping is implied).
However, rendering those tags seems pointless. But it helps other surveyors to know the reasons for existing tags. Much the same like as with maxspeed:source=DE:rural. AND it could help future software to decide if tagging is consistent/complete/faulty or if defaults should rather be used.
But for your actual question: Should we explicitly tag stuff that could be found out by software that's more advanced than current one? Currently renderers are pretty basic, they don't know about country-specifics, or dual carriageways. I have no idea if it's better to tag away or wait for more intelligent renderers. Returning to my first sentence, I do tag stuff where I deem it feasible, don't have a better idea currently. Kay D 20:40, 13 June 2010 (UTC)

Time limited without a disc

While it doesn't matter much, some spaces are time limited but don't require a parking disc, even all spaces in some administrative regions; somewhat misleading but shouldn't matter that much. Alv 19:10, 23 June 2010 (UTC)

Yes, I observed that during my holidays, too. There are some parking lots in Austria where you can stay up to 0.5h without payment (but need to prove with a disc), and there are other places where you can stay up to 0.5h in a "no_stopping"-zone. How do you prove your parking time in those cases? Kay D 12:38, 12 September 2011 (BST)

Kay, in the US you typically don't need a parking disc to prove your parking time, it's the parking ticket issuers (those "Interceptor" cars) who detect your parking time by either marking your tires with chalk or (lately) scanning your license plate periodically to determine how long you've been parked at the same spot. Schmike 13:21, 18 September 2011 (BST)

I see no problem with using the maxstay tag for other conditions than disc as well. For example even for many "parking ticket" areas, you can stay only up to e.g. 2h. Kay D 12:38, 12 September 2011 (BST)

no_parking only if there's a sign?

Should the no_parking-attribute used everywhere where parking isn't possible (such es small streets) or only where a sign is standing? --Quedel 19:41, 17 October 2010 (BST)

Everywhere where it is illegal to park, so it doesn't need to have a sign, if and when other rules make parking forbidden. Such as too narrow streets, hilltops and curves with limited visibility, tunnels, turning lanes etc., all depending on the country's legislation. Some have used parking:condition:reason=turning_lane/narrow/... to record that it's not a signposted restriction but result of other conditions. Alv 08:48, 18 October 2010 (BST)

Thanks, so I did it right here. 60% are done, for the next tagging I have to be wait home again. --Quedel 18:47, 20 October 2010 (BST)

This proposal should be merged into already approved one

Although i like the ideas in this proposal, there is already approved proposal which addresses very similar situation Proposed features/parking so I think it is not good idea to have different system for parking lanes and parking sites. I also think that the approved Proposed features/parking can benefit from some of the ideas raised here, so we can incorporate some ideas to that one. Let's find which are the cases in which the approved one can benefit from approach on this page. --Jakubt 23:02, 17 August 2011 (BST)

Mapping Exceptions like Street Cleaning Times in San Francisco San Francisco and many other US cities have street cleaning times, during which noone (not even residents with permits) are allowed to park. Here's an interesting case: During the street cleaning hours Tu 12-14, noone can park. Drivers with "Z" permits can park unlimited otherwise. Drivers without "Z" permits can park for 2 hours Mo-Fr 8-18, or unlimited otherwise. So would

work and prioritize the "no_stopping" during the street cleaning hours over "residents"? Should there be a special "street_cleaning" tag to make them available on a map? -- Schmike 01:14, 18 September 2011 (PST)

With the syntax proposed here, I'd tag these as (bear with me)

That the resident permit overrides the time limit and/or ticket requirement, is only a mention on this talk page higher up. This way it's always related to the "condition block" where the beginning of the key fits into - in this case the *:condition:2 is not affected by the residential permit. Nobody has to date shown a place where the residents aren't exempt from such limitations, but if such exist, these could be amended to

Makes perfect sense, thanks for clarifying.

One thing to consider: The term "disc" is misleading, it should rather be "time_limit". Because a) in the US, there's no disc (as explained above the enforcers will track your time) and b) even in Germany, if you don't have a disc, there's no legal requirement to get one in order to park. You can just as well draw one on paper or leave a note when you parked on your dashboard, it perfectly fits the legal requirements.

Another one: Software that tries to figure out if you can park at a spot during a certain window in time needs to know that residents aren't allowed to park during street cleaning times. While this might be common sense, it's still an assumption that might have to be overridden in exotic cases. Or is it safe to assume that "2" overrides the default case? Do higher numbers reflect higher priority if they apply to the same window in time? Schmike 23:36, 20 September 2011 (PST)

Not that it matters to me much, but in other countries it's not perfectly fine to leave a note. For example here in Finland the parking disc must fit some requirements set forth in a decree - of which the funniest is that on the backside there must be a specific how-to text. And some time limited but free spaces can require a disc while the next ones don't.
I included the "...:residents=Z" only within the "1" block, so to say, just for that reason; intervals of different conditions probably shouldn't ever overlap, unless there's no room for error in interpretation. If residents were allowed to park regardless of the cleaning time, I'd repeat the residents -line with just "1" replaced by "2". There hasn't been any discussion, afaik, if it would make sense to formulate any rules how to interpret overlapping time intervals. It's probably best to consider such as ambiguous data and hope that users fix/make it eventually unambigous. Alv 08:54, 21 September 2011 (BST)

Isn't splitting up ways for the sake of parking problematic for finding cross streets? This might not be exclusive to parking, but in general, isn't splitting up a way between two intersections problematic for finding ways comprising a stretch on a street between intersections later? For example, in the diagram on the right, I might want to "find all parking tags on 'On Street' between "Cross Street 1" and "Cross Street 2". Finding nodes N2 and N5 is easy, because they're at the intersections of the two cross streets, but determining that "way3" is part of that stretch becomes hard, especially if you add more different parking sections than just way2, way3, and way4 between the two cross streets on the main street.

Is this a common problem with Openstreetmap? Maybe even the reason why you can't search for a location between two cross streets with the Nominatim API? If anyone here has any pointers as to how to solve this problem, that'd be great. Thanks in advance.--Schmike 01:01, 26 September 2011 (BST)

Ways are split for various reasons, "midblock" or even several intersections apart, whenever the lane count, speed limit, surface, street lighting etc. change. It's true that there could be a need for a more sophisticated, ready-to-use preprocessing tool to mangle the data to a structure better suited for, for example, the use case you mentioned. Such tool could, for example, split each way at every intersection, if not already split, and add (in their local database) a tag to each such way indicating which cross streets cross at the ends. Then the necessary ways would be, for example, selectable with simple SQL. With some coding it doesn't then matter where and how many times the ways are split. As to searching, you'll have to ask at Talk:Nominatim. Alv 16:20, 3 October 2011 (BST)

No Waiting?

In the UK especially a restriction of no waiting is very common in urban areas, denoted by a single yellow line down the side or the road, a sign or both. It's more permissive than no_parking and no_stopping but less so than parking, specifically it allows loading/unloading, picking up/setting down passengers but not parking ie leaving the vehicle for an extended period (occupied or not) beyond for those purposes. In a way it could be considered to be a short stay parking situation as it is timed usually to a maximum of 40 minutes unless stated otherwise however there is a caveat namely that it must be obvious to the parking enforcement officer that the vehicle is in the process of loading or unloading and that the goods are too large or heavy to carry (ie it may not be simply for convenience) so just tagging it as short stay parking seems inappropriate. I don't know about other countries but this restriction is highly common in the UK, no on all roads by all means but common enough I think there should be some way to tag it.

Any ideas, could we include no_waiting into this proposal? MttJocy 23:10, 4 November 2011 (UTC)

From the discussions around these parking tags, it has become apparent that in different countries there are different views of what is considered parking; mainly, whether a vehicle standing still for any other reason than loading/unloading (or due to a traffic obstruction, naturally) is always parking, or not. As to allowed use that you describe above, at least in Nordic countries that is just the case we consider "stopping"; car is standing still for loading/unloading people or goods, at most for the time it takes to carry the stuff to the intended destination, or to the car. If you have to wait for a passenger, then you're parking - technically it might be at the very start of the wait, but in practice anything from few seconds to few minutes is legally ok depending on the location and the traffic. The enforcement officers will hang around for like five minutes anyway if the loading case seems plausible, so if you're carrying stuff somewhere you'll get back to them in time for them to cancel it right away. There's a rough guideline, that if you have to pay for the object you're loading before you carry it, it's not allowed "stopping for loading" anymore. And, on the other hand, if you're moving home, the car could be in a no_parking section for a full hour or more legally. Some places that have cars frequently waiting for passengers then feature parking places with a maxstay of 5 to 15 minutes. Alv 15:10, 5 November 2011 (UTC)

I realise this is rather 'late in the day', but to set the record straight: there is no such thing as "no waiting" (distinct from no parking) in the UK. MttJocy seems to have got confused by a number of unrelated matters.
1. Signs historically used the term 'no waiting' (rather than the diagonal barred blue circle used today) to mean 'no parking' so the legal definition is the same.
2. A single yellow line (in the gutter) means no parking but with restrictions that fall short of Mo-Su 00:00-24:00 (ie: there are some times in the week when you are allowed to park)
3. Markings on the kerb which indicate loading restrictions.
4. I have no idea where the 40-minute limit concept has come from. Loading/unloading is self-explanatory.
Should you wish, you can check the UK Highway Code to verify this - The section on road markings is the most useful.
If, as is common in most settings, there are no kerb markings and no signs saying otherwise, you can legally load/unload on a single- or double-yellow-line, even though 'parking' is not permitted. The only exception is the normal common-sense thing about not causing an obstruction, which is implicit in all these tags anyway. In some larger cities, single- and double-red-lines are common: these ban both parking and stopping. In short: The existing tags already cover this.--CunningPlan What's on your mind? 08:31, 3 August 2014 (UTC)

I'm not sure but if that's valid for all countries, but I'd draw the line in those edge cases betweend "do I leave the car unattended" or not. I.e. when I find myself being an obstacle, am I able to depart right away. Then I'd say I was only stopping. I think this is also the definition of "loading": staying next to your car so that others see that you are able to move along "real soon now". Even in German, the law says it is parking (as opposed to stopping) when you "leave the car" (and is as vague as English language leaving it open whether that means "go out of the car" or "go away from the car"). -- Kay D (talk) 04:51, 5 August 2014 (UTC)

Too "german"

currently there are only german pictures and examples in the proposal. i think you should use more international examples (USA, japan, …). this way mappers from other countries could better identify with it, which again should broaden the acceptance of the proposal --Flaimo 15:56, 14 January 2012 (UTC)

Marker on map

Is there any chance to set markers to your parking map? I want to use it on our page (http://hackerspace-bamberg.de/Anfahrt) to show our guests where we are and where to park. Thanks four your help. Spicewiesel 07:10, 18 January 2012 (UTC)

Alternating side (at least in France)

In France we have alternating parking sides. From day 1 to 15 of the month you park on odd housenumber side, and from 16 to the end of the month on the even housenumber side of the street. What about putting that in a parking:condition:both=alternate tag ? Cquest 10:39, 11 August 2012 (BST)

In other countries alternate day parking is "even/odd" numbered days, i.e. parking is allowed on one side on 1st, 3rd, 5th of each month. Alv 17:27, 12 August 2012 (BST)

Good point. However, I think that using parking:condition:both for storing the "alternate" value is wrong, because then you cannot store the legal/payment values any more, e.g. residents or ticket, that normally go into that key. I already implemented two similar things: "narrow road, you can choose either side to park, but not both" (parking:lane:both=narrow) and "parking allowed in marked spaces only (often marks are on alternating sides to throttle traffic speed)" (parking:lane:both=marked). Please see example rendering in the Konrad-Adenauer-Straße. Altogether I think that it is more a "physical" parking mode rather than legal/payment, so I put it into the parking:lane:both key. The catch is, that it is assumed (at lease for narrow) that parking is always parallel. Does this also match your observations of alternate parking sides? If so, it would be straightforward to define. Kay D 12:01, 16 August 2012 (BST)

legal, but surprising

I came across some streets, where one would expect to be a no_parking or even no_stopping restriction, but where there wasn't any. What made me question the freeness was that these are major streets with several lanes and with continuous queues in the morning rush hour. I even asked the city parking control, and they confirmed that (despite the law stating that parking shall not block or hinder traffic), anybody is in fact allowed to park their car on those sections, but that if enough people start to park there, they will erect a suitable restricting traffic sign. Since these are quite nearby, I decided to mark them as free parking, but with an extra tag for future: parking:condition:right:not_intended=yes, so that users can identify such sections, and mappers can more easily check the situation time to time. Suggestions for a better tag will be listened to. Alv 17:33, 21 November 2012 (UTC)

Sides on two way roads

I'm trying to figure out what means left on a two way residential road. I can think of endless cases where such a road allows parking only on one side. One could assume left and right should be according to house numbering. But then again, you have Japan where no such thing exists. So what's the startpoint of a residential road? This ambiguity could be partly addressed with north/east/south/west, but has been quickly dismissed above, without giving a usable alternative or explaination. I suggest documenting more explicitly how to use this key on two way roads. --Keystorm 21:06, 22 November 2012 (UTC)

Every way on OSM has a way, even a two-way street. You can check it on the arrows icon on Potlatch toolbox, for example. --Nighto 21:13, 22 November 2012 (UTC)
The answer is also given in the Wiki: Forward_&_backward,_left_&_right. Kay D 12:34, 2 January 2013 (UTC)

Parking meters

In the USA, there is often parking meters, or new digital replacements which serve the same function. What tag to best use for this? Perhaps some parking:condition*=pay tag? Abbafei (talk) 10:39, 7 August 2014 (UTC)

The best tag is parking:condition:right=ticket in order to state that a payment is required. We may discuss if "pay" would be a better value (or a synonymous value), though. Kay D (talk) 11:08, 9 August 2014 (UTC)

"Head in parking only"

Lanes with perpendicular parking in the US often have "Head in parking only" signs (in other words, only park with front of car facing the direction away from the street). How to tag these? Perhaps parking:lane*=head_in? Abbafei (talk) 10:39, 7 August 2014 (UTC)

I'd give it a try with parking:lane:right:perpendicular=head_in to be "consistent" with the "physical space" tagging like "on_kerb" above. What would be the other way round? "tail_in" or "head_out"? I remember having seen that in Houston, because it was considered safer (you drive out looking forward). Kay D (talk) 11:08, 9 August 2014 (UTC)

I think we need a new unique key for this, because it should neither replace the perpendicular/diagonal/... distinction nor the half_on_kerb/on_kerb/... distinction. Furthermore, it would be nice if we could also map "Back in parking only".
Therefore, my suggestion would be parking:orientation:l/r/b = front_in/back_in/mixed --Tordanik 11:46, 7 August 2014 (UTC)

Agreed to the first part (new key required), but I find the suggestion a bit too general, because values like "front_in" do only apply for specific parking spaces, but for example not for parallel parking. Kay D (talk) 21:45, 9 August 2014 (UTC)

I don't see the problem here. Of course it only really makes sense for perpendicular or diagonal parking, but you would just not use the tag where it doesn't make sense. After all, with your suggestion someone could also use nonsensical combinations such as parking:lane:right:parallel=head_in, same thing. As a bonus, my suggested key can be used (without the left/right/back) on parking areas or spaces, not just lanes. --Tordanik 11:46, 10 August 2014 (UTC)

parking.openstreetmap.de render server is dead

I just entered the URL http://parking.openstreetmap.de and saw that the server lists an empty folder. --Nighto (talk) 18:56, 5 November 2014 (UTC)

As the values remains inside OSM data you can use a custom map done with uMap called Parking OSM whenever the OSM data about parking conditions exists . --yopaseopor 11:17, 19 August 2016 (UTC)

How would you map "Alternate-side parking"?

In Belgium, Alternate-side parking is very popular.

It's either marked with a sign when entering the zone, or on the specific streets themselves. Time conditionals are too hard to use for this very common case. And since you may never park in the opposite direction on a street, it's somewhat important to know on which side you can park on, so you can approach the parking lane from the right direction.

I propose the following tags:

Other conditions (tickets, disks, times) can still be tagged in the same, logical way, and tools that don't know about this condition will just ignore it.

--Sanderd17 (talk) 10:36, 18 November 2014 (UTC)

Look at this proposition on opening_hours page http://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#odd.2Feven_dates & using :time_interval tag ---Yod4z (talk) 09:57, 3 November 2015 (UTC)

Retrieved from "http://wiki.openstreetmap.org/w/index.php?title=Talk:Key:parking:lane&oldid=1337376"

