Talk:Key:parking:lane

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.

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.

Resolved: Resolved, I think Mateusz Konieczny (talk) 19:18, 12 December 2021 (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.

Lulu-Ann

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)

See amenity=parking_space and area:highway=* Mateusz Konieczny (talk) 11:18, 14 July 2020 (UTC)

Resolved: Resolved, I think Mateusz Konieczny (talk) 19:18, 12 December 2021 (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.

• parking:lane:right=parallel
• parking:condition:right=ticket
• parking:condition:right:time_interval=Mo-Fr 09:00-19:00
• parking:right:parallel=on_street
• then parking:condition:right:residents=E, but that it overrides the fee is not obvious or at least not documented.

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?

• parking:condition:right=ticket
• parking:condition:right:ticket:time_interval=Mo-Fr 09-19, Sa 09-16
• parking:condition:right:residents=A. Alv 16:52, 19 May 2010 (UTC)

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:

Sign	Tags
	parking:lane:right=parallel parking:condition:right:ticket:time_interval=Mo-Fr 09:00-19:00 parking:condition:right:ticket:maxstay=4h (for example) parking:condition:right:free:time_interval=Mo-Fr 00:00-09:00,19:00-24:00; Sa-Su parking:condition:right:residents:time_interval=24/7 parking:condition:right:residents=E
	parking:lane:right=parallel parking:condition:right:ticket:time_interval=Mo-Fr 09:00-19:00,Sa 09:00-16:00, PH off parking:condition:right:free:time_interval=Mo-Fr 00:00-09:00,19:00-24:00,Sa 00:00-09:00,16:00-24:00, PH off parking:condition:right:residents:time_interval=24/7 parking:condition:right:residents=A
	parking:lane:right=parallel parking:condition:right:no_stopping:time_interval=07:00-09:00 parking:condition:right:disc:time_interval=09:00-18:00 parking:condition:right:disc:maxstay=30 minutes parking:condition:right:free:time_interval=00:00-07:00,18:00-24:00
	parking:lane:right=parallel parking:condition:right:no_stopping:time_interval=Mo-Sa 15:00-18:00; PH off parking:condition:right:no_parking:time_interval=Mo-Fr 07:00-15:00; Sa 07:00-09:00; PH off parking:condition:right:ticket:time_interval=Sa 09:00-15:00 parking:condition:right:ticket:maxstay=60 minutes parking:condition:right:free:time_interval=Mo-Sa 00:00-07:00,18:00-24:00;Su;PH

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

Disc parking (maxstay) or free for residents

Sign	Tags
	Proposal parking:condition=residents parking:condition:disc:maxstay=2h see http://www.openstreetmap.org/?lat=48.64233&lon=8.90618&zoom=17&layers=B000FTF source: http://www.gaertringen.de/p/d1.asp?artikel_id=1486 --User:Fx99 You have at least to specify the side: parking:condition:both=residents parking:condition:both:disc:maxstay=2h --User:kay_D meant both --Fx99 16:18, 25 May 2010 (UTC)

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:

parking:lane:left=parallel (this must be used because parking ''is'' allowed at nighttime)
parking:condition:1:left=no_stopping
parking:condition:1:left:time_interval=Mo-Fr 07-09; Mo-Fr 15-18; Sa 09-15
parking:condition:2:left=no_parking
parking:condition:2:left:time_interval=Mo-Fr 09-15
parking:condition:3:left=free
parking:condition:3:left:time_interval=Mo-Fr 18-07; Sa 00-09; Sa 15-24; Su 00-24

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:

parking:lane:right=parallel
parking:condition:right=no_stopping
parking:condition:right:time_interval=Mo-Fr 07-09
parking:condition:2:right=disc
parking:condition:2:right:maxstay=30 min
parking:condition:2:right:time_interval=Mo-Fr 09-18
parking:condition:default=free

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.

parking:condition:both:default = free
parking:condition:right = no_stopping
parking:condition:right:time_interval = Mo-Fr 15:00-18:00
parking:condition:right:2 = no_parking
parking:condition:right:2:time_interval = Mo-Fr 07:00-15:00
parking:condition:right:3 = ticket
parking:condition:right:3:maxstay = 60 min
parking:condition:right:3:time_interval = Sa 09:00-15:00

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.

lanes=2
parking:lane:right = parallel
parking:lane:right:parallel = on_street
parking:condition:right:default = free
parking:condition:right = no_stopping
parking:condition:right:time_interval = Mo-Su 09:00-15:00; 
parking:condition:right:2 = no_parking
parking:condition:right:2:time_interval = Mo-Fr 07:00-09:00; Mo-Fr 15:00-18:00
parking:condition:right:2:except = bus
parking:condition:right:3 = disc
parking:condition:right:3:maxstay = 30 min
parking:condition:right:3:vehicles = bus
parking:condition:right:3:time_interval = Mo-Fr 07:00-09:00; Mo-Fr 15:00-18:00

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)

Other

Motorcycles

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)

Loading/Unloading

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:

Tag	Description
parking:lane:side=type	side is always left, right or both. type is parallel, diagonal, perpendicular, no_parking_space.
parking:condition:side=cond	cond is no_parking, no_stopping, fire_lane, free, ticket, disc, residents, customers or private. A condition is only specified if a sign is present. I.e. when a road is too small, then parking:lane:side=no_parking_space, and with a "fire lane" sign in addition: parking:condition:side=fire_lane
parking:lane:side:parallel=itype	itype is on_street, painted_area_only, half_on_kerb, on_kerb or lay_by. This is only specified if the inline parallel value is present. (lay_by = Parkbucht)

"However, the latter two may be evident by road layout, there may be no signs around to tell so." - and? It is still possible to tag this Mateusz Konieczny (talk) 19:19, 12 December 2021 (UTC)

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

• parking:condition:side:vehicles=bus

(2) Limitation to certain vehicles is a separate property

• parking:vehicles:side=bus

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

1. No stopping, except diplomatic; alternatives:

   1. parking:lane:*=parallel

      parking:condition:*=no_stopping

      parking:condition:*:except=diplomat ?

   2. parking:lane:*=parallel

      parking:*:vehicles=diplomat ? Doesn't really convey the "no stopping for others".

   3. parking:lane:*=parallel

      parking:condition:*=private

      parking:*:private=diplomat ? Doesn't really convey the "no stopping for others".

2. No parking (daytime), except "City Hall vehicles" ("Kaupungintalon virka-autot")

   parking:lane:*=parallel

   parking:condition:*=private

   parking:condition:*:private=Kaupungintalo

   parking:condition:*:time_interval=Mo-Fr 07-18

   parking:condition:default=free

3. Parking only for "tourist traffic" buses with a disc 4 hours, and military vehicles two hours with a parking disc; no other parking. This one gets quite ugly:

   parking:condition:right=disc

   parking:condition:right:maxstay=4h

   parking:condition:right:vehicles=bus

   parking:condition:right:2=disc

   parking:condition:right:2:maxstay=2h

   parking:condition:right:2:vehicles=military

   parking:condition:right:default=no_parking Alv 15:05, 7 September 2010 (BST)

Default rules

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

Examples:

Image	Example	Inside time interval	Outside time interval
	[Annastraße]	residents only	free parking
	[Ludwigstraße]	free parking	no parking

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.

Resolved: Nowadays we have Conditional restrictions Mateusz Konieczny (talk) 19:20, 12 December 2021 (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

• :time_interval vs. :times
• half_on_kerb vs. half
• on_kerb vs. outside
• customers vs. destination
• painted_area_only vs. dedicated - does it matter if there's painted lines, or that the space is otherwise dedicated for parking only?

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)

Lane?

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)

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:

• using polygons to specify the area is unsuitable at times, because polygons are only two-dimensional. They cannot cope with bridges or similar complicated topology.
• renderers cannot easily find out currently about roads within polygons
• using relations is not the intended use of relations.

--Kay D 13:06, 5 May 2010 (UTC)

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):

parking:right=inline
no_parking=both
no_parking:times=Mo-Fr 09-15
no_stopping=both
no_stopping:times=Mo-Fr 07-09, 15-18; Sa 09-15

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:

• really means "Parking allowed for residents". Would you use the no_parking-Tag?
• marks private property. Is it no_parking or no_stopping?
• - cars may park here...
• means only parking for public transport buses

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)

Resolved: This deprecation proposal is stuck and apparently noone was interested in it for over decade. Marking as resolved, with plans to archive it Mateusz Konieczny (talk) 19:22, 12 December 2021 (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)

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)

The issue is that if there is no sign, it is up to the state legislation to decide which situation leads to no-stopping, no-parking or modified no-parking rules (no stopping but loading passengers is ok for example). In this case, I find it is more future-proof to just use parking:lane:*=no and optionally give the reason than declaring that it is no stopping or no parking. Because state legislation may change. Signs only change when they physically do. --Westnordost (talk) 14:41, 7 December 2021 (UTC)

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

parking:condition:side:residents=A
parking:condition:side:maxstay=2 h
parking:condition:side:no_stopping:time_interval=Tu[2,4] 09:00-11:00 

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)

 parking:condition:side=disc
 parking:condition:side:residents=Z
 parking:condition:side:maxstay=2 h
 parking:condition:side:time_interval=Mo-Fr 09:00-12:00;Mo-Fr 14:00-18:00
 parking:condition:side:2=no_stopping
 parking:condition:side:2:time_interval=Mo-Fr 12:00-14:00
 parking:condition:side:2:reason=street_cleaning
 parking:condition:side:default=free

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

 parking:condition:side:except:residents=Z

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)

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)

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)

back-in parking

Various cities have been converting existing parking spaces to diagonal/angle back-in parking. Boulder, Colorado example (implemented Aug. 2013): aerial view of University Ave. from Broadway east (downhill) to 17th St. - Bing Streetside view DougGrinbergs (talk) 22:11, 5 October 2018 (UTC)

Existing tagging supports this: search for diagonal ("Diagonal parking. Also known as angle parking or echelon parking.") Mateusz Konieczny (talk) 19:24, 12 December 2021 (UTC)

@Mateusz Konieczny: This discussion is about back-in angle parking, also known as reverse eschelon parking. Physically, the spaces are rotated 90 degrees from the usual orientation, as if the street has a different driving_side=* (but it doesn't). There are also signs about this relatively unusual layout, such as in California. This detail can be useful for renderers, as well as perhaps for traffic simulators. There's no established tagging for back-in angle parking, but MUTCD/California/R supposes a parking:lane:right=reverse_diagonal along with parking:orientation=reverse_diagonal on any separately mapped spaces. – Minh Nguyễn ^💬 22:19, 12 December 2021 (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:

• parking:condition:alternate-side=half-monthly:left-right: First half of the month: park left, second half of the month: park right
• parking:condition:alternate-side=half-monthly:right-left: Reverse of the previous
• parking:condition:alternate-side=no: Regular parking on both sides simultaniously. Can be used to warn mappers that the situation has changed (similar to oneway=no). This value is the default
• parking:condition:alternate-side=half-monthly: Parking happens on alternating sides, but the sides are unknown (f.e. it's unknown where the even and the odd housenumbers are). This tag should be replaced by one of the above when possible.

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)

Late to the party. Here is a current proposal to make conditional parking restrictions on lanes https://wiki.openstreetmap.org/wiki/Proposed_features/Parking_lane_conditionals#Examples

In a nutshell parking:lane:*:conditional=no_parking @ (Jan-Dec 1-15) for the "you may not park in first half of month" etc. --Westnordost (talk) 22:12, 26 November 2021 (UTC)

How to tag "on road" bicycle parking

In this example, there where 16 amenity=bicycle_parking placed on 2 car parking spaces. I mapped the bicycle_parking as an parking area to make it explicit. How would you change the parking lane tags on the road? Split the road twice and map parking:condition:right:vehicles=bicycle? Or only split the road once and leave the tags meet the crossing? Or leave it as is 'cause its to many changes for the small bicycle_parking? --Tordans (talk) 06:45, 3 November 2018 (UTC)

I always mapped such places explicitly with a node/area. Mateusz Konieczny (talk) 08:54, 14 July 2020 (UTC)

For documentation: bicycle_parking:position=lane or =street_side is in use for that.--Supaplex030 (talk) 10:35, 25 June 2022 (UTC)

Resolved: answered Mateusz Konieczny (talk) 19:24, 12 December 2021 (UTC)

Migrate to conditional restrictions

MUTCD R7-203

Should we deprecate the current parking:condition=* schema in favor of conditional restrictions? As far as I can tell, the former predates the latter. That would explain why such an appropriate use case for conditional tagging would have its own, less flexible syntax for conditions.

Parking lanes can have so many intricacies beyond time restrictions. Recently, in 65141087 , I needed to tag 19013015 19013015 to reflect the "No Parking When Snowfall Exceeds 2 Inches" sign seen at the far left of this Mapillary photo. It's a variant of a standard U.S. road sign, intended for clearing the streets for snow plows to get through during a snow emergency. I ended up having to invent a new tag, parking:condition:left:maxsnow=2". But it's such a one-off that I'm certain no data consumer will ever make use of it. Having used conditional tagging for various other purposes in the past, I would've found parking:lane:conditional=no_parking @ (snow > 2") much more intuitive.

If we move towards a tag like parking:lane:conditional=*, editors and data consumers that are already using parking:condition=* might be able to make use of the (presumably more numerous) tools that recognize conditional tagging.

 – Minh Nguyễn ^💬 18:41, 4 December 2018 (UTC)

I have the same impression and sooner or later it will happen. Not sure what kind of support there is for either syntax? RicoZ (talk) 18:46, 14 January 2019 (UTC)

I would support the use of conditional restrictions. Very good proposal in my opinion ... The old schema is really too hard to read and to understand in complex situations (and is not ready for these situations I think). There are too many exceptions and special cases which the old schema doesn't seem to cover (as shown n this talk page), and all the (often quite good) proposals in this talk page (of 2009 and later) didn't lead to any improvements as far as I can see. So conditional restrictions could help a lot to make the tagging clearer, and it would follow the (for me well known) tagging of access conditions. But what's the way to come to such a decision? I still don't understand enough the system of decisions and agreements on OpenStreetMap, although I contribute as a mapper since more than 6 years ... --Goodidea (talk) 04:00, 9 April 2019 (UTC)

The parking conditions have some overlap with conditional restrictions, but the two concepts aren't exactly the same. So a first step would be for someone to think this through and write down a "translation" from the existing tagging onto a new one that's based on conditional restrictions. For example, time-based restrictions are a perfect candidate for conditional restrictions and should indeed be replaced by them, whereas parking:condition:left:maxstay should probably not be mapped onto a conditional restriction. (After all, maxstay=* exists for normal parking and is mostly unrelated to conditions in that sense.) I would also suggest that we try to make things consistent: Many tags should probably be the same as those used on amenity=parking, just with a parking:lane:<side>: attached in front.

Once someone has done that work, creating a proposal might be a good approach to document it and spread awareness. --Tordanik 14:13, 9 April 2019 (UTC)

Maxstay tags answer a different question than the other parking condition tags: "when must I leave?" versus "can I park in the first place?" So it makes a lot of sense for maxstay to end up in a separate tag. – Minh Nguyễn ^💬 22:28, 8 August 2019 (UTC)

Proposed features/Parking lane conditionals exists but appears to be inactive Mateusz Konieczny (talk) 19:31, 12 December 2021 (UTC)

@Mateusz Konieczny: Proposed features/Parking lane conditionals grew out of discussions such as this one and is actively being worked on. Please see the talk page for that proposal for current activity. – Minh Nguyễn ^💬 21:55, 12 December 2021 (UTC)

116483305 updates the example above to conform to the newly approved Proposed features/Parking lane conditionals. – Minh Nguyễn ^💬 01:33, 23 January 2022 (UTC)

Parking lane for electric cars, charging

Elektrofahrzeuge während des Ladevorgangs

How to tag the case shown on the photo? Sign says: Free for electric cars while charging, max stay 2 hours (with disc) between 8 a.m. and 6 p.m. How about that:?

parking:condition:right=disk;charging
parking:condition:right:maxstay=4 hours
parking:condition:right:time_interval=Mo-Su 08:00-18:00
parking:condition:right:default=charging

--Supaplex030 (talk) 14:05, 17 March 2020 (UTC)

It would be better to consider Talk:Key:parking:lane#Migrate_to_conditional_restrictions. parking:condition:right:default=charging would not be supported well for both the key and value. Most importantly, charging is a condition, not a conditioned value. -- Kovposch (talk) 07:57, 19 March 2020 (UTC)

Could you write down how to tag this case with conditional restrictions scheme? --Supaplex030 (talk) 12:06, 19 March 2020 (UTC)

I think I got it. Maybe this is a good and simple solution?

parking:condition:right=charging

parking:condition:right:maxstay=4 h @ (08:00-18:00)

--Supaplex030 (talk) 17:02, 21 March 2020 (UTC)

An abundance of tags

The article says:

Sometimes specifying one default condition is not enough. In these cases we end up with an abundance of tags

No kidding. The right side of this street, which is making the rounds on social media, currently holds the record for the most parking conditions applied to one side of a street: ten. Hopefully any data consumer brave enough to process the parking:lane=* tagging scheme can handle more than a single digit of conditional subkeys.

 – Minh Nguyễn ^💬 18:00, 26 July 2021 (UTC)

I see this is from https://osmus.slack.com/archives/C029HV951/p1627315996440400. Great exemplification of the limitations of parking:lane:condition=*. Let me try to formulate an alternative that could be applied on 871456129 871456129 as an exercise:

1. parking:lane:left=parallel
2. parking:lane:right=no_parking
3. parking:lane:both:parallel=on_street
4. parking:lane:both:conditional=no_stopping @ (Mo-Fr 06:00-16:00; SH off); parallel @ (resident AND zone=4; permit=CCUSD)
5. parking:lane:left:conditional=no_parking @ (Mo-Fr;SH off); parallel @ (maxstay=PT1H AND no_return=P1D AND zone=4 AND (Mo-Fr 16:00-18:00;SH off))
6. parking:lane:right:conditional=no_parking @ (Mo-Fr 04:00-06:00 open "street cleaning"); no_stopping @ (Fr 18:00-24:00;Sa,Su); parallel @ (maxstay=PT1H AND no_return=P1D AND zone=4 AND (Mo-Th 16:00-18:00,Fr 00:00-18:00))
7. parking:lane:both:related_law=CCMC 7.03.300
8. parking:lane:right:related_law=CVC 22551(M)
9. parking:lane:both:related_law:conditional=CCMC 7.03.300,CVC 23421(M) @ (Mo-Fr;SH off); CCMC 7.03.300,CCMC 7.03.215(D) @ (Mo-Fr 06:00-16:00;SH off)
10. parking:lane:left:related_law:conditional=CCMC 7.03.010,CCMC 7.03.305 @ (Mo-Fr 16:00-18:00;SH off)
11. parking:lane:right:related_law:conditional=CCMC 7.03.010,CCMC 7.03.305 @ (Mo-Th 16:00-18:00,Fr 00:00-18:00)

Is parking:condition:6=* and parking:condition:10=* duplicated? Do you really to need separate parking:condition:both=* into parking:condition:left=* and parking:condition:left=*?

As can be seen, the format necessitates splitting of info, and risks hitting the length limit. Might be easier if there's a *:conditional=* @ (NOT *) syntax.

---- Kovposch (talk) 14:16, 27 July 2021 (UTC)

@Kovposch: You're right, there's probably more we could do to condense the tagging on the roadway using the existing tagging scheme. I simply concatenated everything that appeared on the separately mapped traffic signs in the same changeset, some of which were apparently redundant. From Bing Streetside imagery, the signpost to the left of the building entrance has an identical set of signs, except that one sign has its ↔ covered up on one end by a sticker, turning it into a → right-side-only restriction. I can't tell if that's an intentional change by the city or minor vandalism, but it has the potential to affect the roadway's tags quite a bit. I kept the two sides separate in case anyone needs to account for that covered-up arrow. – Minh Nguyễn ^💬 20:29, 27 July 2021 (UTC)

By way of an update, I belatedly remembered that arrows on an MUTCD parking sign refer to before and after the sign, not the left and right sides of the street. The other side of the street has another set of signposts with completely different regulations (thankfully simpler ones). – Minh Nguyễn ^💬 17:10, 4 August 2021 (UTC)

Actually, would be more beneficial to directly introduce no_return=* (or expand maxstay=* to limit per-day usage), and zone:parking=* (as in zone:traffic=* and zone=maxspeed). The latter already has 1064 instances. 112 *no_return=* instances from https://taginfo.openstreetmap.org/search?q=no_return.

zone:parking=*

More details at taginfo

More details at taginfo

4. parking:lane:both:conditional=no_stopping @ (Mo-Fr 06:00-16:00; SH off); parallel @ (resident; permit=CCUSD) [since "resident" can be localized]

5. parking:lane:left:conditional=no_parking @ (Mo-Fr;SH off); parallel @ (Mo-Fr 16:00-18:00;SH off))

5.1 parking:lane:left:maxstay:conditional=PT1H @ (Mo-Fr 16:00-18:00;SH off)

5.2 ?(parking:lane:left:no_return:conditional=P1D @ (Mo-Fr 16:00-18:00;SH off))

6. parking:lane:right:conditional=no_parking @ (Mo-Fr 04:00-06:00 open "street cleaning"); no_stopping @ (Fr 18:00-24:00;Sa,Su); parallel @ (Mo-Th 16:00-18:00,Fr 00:00-18:00))

6.1 parking:lane:right:maxstay:conditional=PT1H @ (Mo-Th 16:00-18:00,Fr 00:00-18:00)

6.2 ?(parking:lane:right:no_return:conditional=P1D @ (Mo-Th 16:00-18:00,Fr 00:00-18:00))

12. zone:parking=4

Side note: charge=* tries to use a rate, but that's not a limit.

---- Kovposch (talk) 08:22, 7 August 2021 (UTC)

A separate zone:parking=* key seems elegant to me, but sometimes parking zones can overlap. For example, on a college campus where some zones are for dormitory residents and others are for visitors or staff, the visitor or staff zones may only apply for a more limited time while the resident zones always apply, or there may be other conditions on when certain zones apply. I suppose zone:parking:conditional=* could work. – Minh Nguyễn ^💬 07:49, 8 August 2021 (UTC)

This proposal from SharedStreets to ditch parking:lane=* in favor of mapping the signs would've reduced the amount of work for me as a mapper, because I wouldn't've had to consolidate the various traffic_sign=* nodes' parking tags onto the affected roadway. However, I got lucky in terms of being able to just barely discern all the signposts in Bing Streetside imagery. I think the SharedStreets proposal has some advantages – less road splitting and a much easier story for imports – but I'm not sure how well it generalizes to situations where parking restrictions are defined using something other than a standard signpost at either end of a restriction. For example, there's a standard sign in California that is posted at city limits to indicate a default time-dependent street parking restriction on every street in the city. [1] – Minh Nguyễn ^💬 17:10, 4 August 2021 (UTC)

This requires much processing to be usable. You could try zone-based restriction or area defaults for that instead. (discussed somewhere)

---- Kovposch (talk) 08:22, 7 August 2021 (UTC)

I think this parking:lane:conditional=* approach is promising. I just added an example of it to MUTCD/California/SR#SR49: Tow-Away No Parking When Snow Removal Conditions Exist, which is about a standard sign in California that can't be expressed in a sensible way using the current tagging scheme. (parking:condition:condition=snow would've been the only alternative, but it wouldn't have accommodated snow depth restrictions.) – Minh Nguyễn ^💬 18:05, 8 August 2021 (UTC)

116485609 updates the infamous Culver City Parking Trap to conform to the newly approved Proposed features/Parking lane conditionals – or at least I tried. – Minh Nguyễn ^💬 01:31, 23 January 2022 (UTC)

An attempt at conditional restrictions

I've started a proposal to move towards conditional restrictions. I will be working on it in the following days. --Riiga (talk) 11:24, 24 August 2021 (UTC)

Unclear sentence

"Usually, this parking space is not about free or paid." - what it is supposed to mean? Mateusz Konieczny (talk) 11:21, 13 December 2021 (UTC)

This is related to the value "disabled" of parking:conditions and for me, it's quite clear what it should mean. I think it should express that on parking spaces with a parking sign for disabled persons you generally don't have to pay a fee (and there are also no time restrictions for parking) – if you have a document proofing your disability which has to be placed in the car. And no one else is allowed to park there of course. At least that is the applicable law in Germany (I only know the situation here – perhaps it's different in other countries???), so the categories "free" or "ticket"/"disc" or something else don't fit here – "usually". But the quality of the wording is another question (and whether different international regulations have been considered and if it's really "usually" like this) ... perhaps it could be improved ... --Goodidea (talk) 03:43, 19 December 2021 (UTC)

How to tag informal "when there is space" parking

Oftentimes in residential streets without marked lanes, there are simply no signs at all and cars park (legally) on the side of the street. BUT the street is not wide enough for that cars can park (legally) on both sides on the street. So what happens is that some cars park on the left side, then some further down the road, some on the right etc., leading to the through-traffic cars having to drive a bit in a slalom. The pattern, when people park their car on the left and on the right can change daily. So, how can this be tagged? Something with "if_space", or "informal"? Ideas?

This issue was actually brought up by several confused StreetComplete users that tried out the new "street parking overlay" (https://github.com/streetcomplete/StreetComplete/releases/tag/v47.0-beta1). It is not something theoretical, but a very common situation that is kind of not represented with the current tagging scheme. --Westnordost (talk) 12:41, 23 September 2022 (UTC)

For this "alternating" parking on both sides of the street (on streets that are too narrow for parking on both sides), there is the suggested tag parking:condition:either_side_only=yes. I think it originally appeared here a lot of years ago. Currently, this tagging is used 159 times on different places in the world. In the context of our Berlin parking project, we have discussed (in German) the possibility of taking this tagging into account. --Supaplex030 (talk) 13:29, 23 September 2022 (UTC)