Talk:Tag:parking=street side

From OpenStreetMap Wiki
Jump to navigation Jump to search

Grouping of adjacent street-side parking bays

During the discussions on this proposal/value, there was the question whether it makes sense to group adjacent street-side parking bays with a relation (if there are several parking bays lined up along the same street). There was no real solution on this discussion, so a soft wording ("consider...") has found its way into the proposal and this page. Personally, I don't see any benefit in this, just extra work. At a local mapper meeting we also just discussed this, but we couldn't identify a real advantage. I have the feeling that the desire for a grouping aims to prevent P-symbol spam in the rendering, but that is not a task of a relation. I would like to remove the mention of grouping. What do you think? --Supaplex030 (talk) 21:30, 13 December 2020 (UTC)

That's OK with me. The grouping makes some sense, but I get the impression that the parking site relation is a bit exotic in practical use still. JeroenHoek (talk) 21:33, 13 December 2020 (UTC)
I have deleted it for now. See also this and that (last one) thread on the initial proposal page.--Supaplex030 (talk) 18:08, 17 December 2020 (UTC)

Putting condition, capacity etc. on the way

Hello, I just found out about this tag and it's an excellent idea! I just have one suggestion: there should be a way to keep the parking intricacies data on the way containing parking:lane=* and to mark this on the parking=street_side area. I presume my city is not alone in that a lot of data has been already mapped via the parking:lane=* tags, and moving it all on the parking=street_side areas would be a large task. It would also make it harder/impossible to generate maps like these and add the task of matching street_side areas to parking:lane ways for machines trying to determine whether parking is free, paid, forbidden, disabled-only etc. Rostaman (talk) 12:05, 17 December 2020 (UTC)

You don't have to migrate from one to the other. Mapping street-side parking as separate areas is optional, and mapping them with parking:lane=* is not deprecated. Also, they only overlap when parking:lane=* is used with the `street_side` value; other values such as `on_kerb`, etc.are not mapped separately.
When someone maps amenity=parking plus parking=street_side, the documentation recommends tagging the street these areas belong to with parking:lane:(side)=separate, so if your dataset only has streets, the presence of that tag will tell you that there are parking areas nearby that may need to be inspected. – JeroenHoek (talk) 12:44, 17 December 2020 (UTC)
I see, so if I have a way with parking:condition=* with parking:lane:blah=separate and no conditions on the parking=street_side, data users will not presume the street_side parking is free or w/ no conditions? Rostaman (talk) 13:25, 17 December 2020 (UTC)
I think that parking:lane:(side)=separate implies that all data relevant to that parking amenity are mapped on that amenity. So yes, a amenity=parking plus parking=street_side without any additional tags is presumed to be free.
I don't know if tagging the conditions on the street as well when separate is declared is merely redundant or discouraged. — JeroenHoek (talk) 13:33, 17 December 2020 (UTC)
Well, that's the problem I want to solve: create some kind of tag=value that tells the user to look for parking=street_side's conditions on the street. Otherwise I'll have to add/update the same conditions twice. Or delete them from the way, which creates the problems I mentioned above. Rostaman (talk) 13:52, 17 December 2020 (UTC)
That is not really possible without resorting to relations, and the parking site relation is not that well supported. But it shouldn't be a problem: anyone who maps those parking=street_side areas should tag conditions there, but your existing tagging can stay as it is. Only when someone starts explicitly mapping parking=street_side will those change. You don't have to update anything unless you start mapping street-side parking areas explicitly. — JeroenHoek (talk) 14:27, 17 December 2020 (UTC)

OK, keep the conditions doubled then. Related question: how do I preserve half_kerb, on_street and similar information? It would normally go under parking:lane:side=*, and I don't see where I would place this in parking=street_side area's tags. Rostaman (talk) 15:51, 17 December 2020 (UTC)

Hey, if you are mapping separate parking areas and indicate them with parking:lane:*=separate at the highway, then the conditions should also be mapped at the separate area. parking:lane:*=separate on a highway indicates that you have to search on the separate geometry for every information. There should be no other parking:*-Tag on the highway in this case. Unfortunately this might be inconvenient if you make data analyses, but collecting data twice is discouraged in OSM, as it can quickly lead to contradictions and the data quality decreases.
Are you sure that a separate geometry is usefull in your case? Or wouldn't it be better to stick to the parking:lane scheme? Are you aware that "street_side" should actually only be used for "parking pockets" and therefore usually conflicts with values like "on_street" or "half_on_kerb"? See also the graphic in this section. --Supaplex030 (talk) 17:59, 17 December 2020 (UTC)
To explain: I added parking:lane info a good while ago to most of the inner city in my town. Some time afterwards another user drew amenity=parking for street parking in some of these and some streets I didn't map parking in. Some of these parking areas are pretty detailed, especially the lay_by'es - I didn't know parking=street_side was only intended for those, nor that "lay_by" is obsolete, thanks for pointing that out. I'm wondering if I can make use of this geometry, since I would prefer to not delete another user's work. But leaving it as simply amenity=parking and not adding appropriate conditions is obviously giving wrong/conflicting info. Rostaman (talk) 13:03, 18 December 2020 (UTC)
In that case the solution is to tag the conditions only on the amenity=parking, and set parking:lane:*=separate (without conditions) on the street (for the relevant side). Any data consumer that wants to do something with the parking data should look at both streets and amenity=parking, but this was already the case before the introduction of parking=street_side; parking=surface is always mapped as separate from the street, and some mappers may have used parking=lane as well. — JeroenHoek (talk) 13:12, 18 December 2020 (UTC)
Yes, but that would lose half_on_kerb, etc. type information. I'm in Zagreb FWIW, you can look up the situation for yourself, e.g. [1][2][3]. The parking=lane tags are all by me, mostly trying to make use of the incorrectly tagged amenity=parking geometry Rostaman (talk) 13:41, 18 December 2020 (UTC)
Ah, ok, I'm understandig the problem. In the past, in some special situations I have very rarely used parking:position=* to indicate the position relative to the kerb. But I think here we have a case for which there is no tagging solution yet – especially for "on_kerb" parking there is no equivalent that could be used on separate areas. amenity=parking + parking=on_kerb could be a variant (or amenity=parking + parking=street_side + parking:position=on_kerb, but this does not actually correspond to the definition of street_side), but you would be the first (with one exception) who would use that... But why not?
In case of "on_street" and "half_on_kerb" parking I would use amenity=parking + parking=lane + parking:position=on_street/parking:position=half_on_kerb (because the parking takes place at least partially on the carriageway). In any case you could add area:highway=parking_space – or I would prefer area:highway=parking to don't mix it up with the different meaning of amenity=parking_space, but thats rarely in use...
As you can see, there are actually a few fundamental questions that need to be clarified here :) --Supaplex030 (talk) 22:10, 20 December 2020 (UTC)

How could I map this?

What about parking conditions like no_stopping and no_parking associated with a street-side parking?

street-side parking together with a no_parking condition – how could this be mapped?

An example (from Germany): I would like to map the street-side parking shown on the first photo, and I would prefer to map it as an amenity=parking area, because it's more precise and would fit to other details already mapped in the surrounding area, which is near to a pedestrian zone. (Sorry for the bad photo made in the evening ...)

First there could be 2 interpretations of the signs:

  • Interpretation 1: Default is no_parking. Parking for residents with permit B2 is allowed Mo-Fr 08:00-20:00; Sa 08:00-16:00.
  • Interpretation 2: Default is free parking. The condition no_parking is valid Mo-Fr 08:00-20:00; Sa 08:00-16:00. And residents with permit B2 are allowed to park there at every time.

But I tend to the first interpretation because of the top-down order of the signs. Otherwise the order should be like the sign on the second photo, I think.

example of another sign (no parking with exceptions – this would fit to interpretation 2, I think)

[Subsequent comment from December 19, 2021 – also see summary below –: this assumption was WRONG! The 2nd interpretation is correct ... only the order if the signs is confusing. But both the first and 2nd additional sign limit the meaning of the main traffic sign and the additional sign for residents even overrides it. A good explanation can be found on the german Wikipedia Page Haltverbot#Gültigkeitsbereich_der_Zeichen_283_und_286. The german road traffic regulations (StVO 2013 of 2021-07-12) says to the additional sign for residents in „Anlage 2 Lfd.Nr. 63.4“: „Das Zusatzzeichen zu Zeichen 286 nimmt Bewohner mit besonderem Parkausweis vom Haltverbot aus.“]


To be clear: the following thoughts are based on interpretation 1 and the first photo ... (But the problems would be similar with interpretation 2 and the 2nd photo, I think).


It's already not easy to tag it in a proper way with the parking:lane=* tags IMO. I see these possibilities (this parking is only on the right side of the street):

Version A (only with parking:lane tags on the street):

parking:lane:right=parallel
parking:lane:right:parallel=street_side
parking:condition:right=residents
parking:condition:right:residents=B2
parking:condition:right:time_interval=Mo-Fr 08:00-20:00; Sa 08:00-16:00
parking:condition:right:default=no_parking
parking:lane:right:capacity=4

But here, "parking:condition:right:default=no_parking" could be a problem, because "no_parking" is not an "allowed" (common) value for "condition", only for the type. So perhaps version B would be better:

Version B (only with parking:lane tags on the street):

parking:lane:right=no_parking
parking:lane:right:no_parking=street_side
parking:lane:right:capacity=4


parking:lane:right:2=parallel
parking:lane:right:2:parallel=street_side
parking:condition:right:2=residents
parking:condition:right:2:residents=B2
parking:condition:right:2:time_interval=Mo-Fr 08:00-20:00; Sa 08:00-16:00

But here, the notation "parking:lane:right:2=parallel" is not described on the wiki page of parking:lane=*. I'm not sure if it's OK like this ...

But how would Version C with an amenity=parking area look like?

Is it possible at all? Or one of these cases of fundamental questions that need to be clarified? My idea would be:

amenity=parking
parking=surface
access:conditional=private @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00) [considering resident parking as a form of private parking, because you need an individual permit with a fee per year or month here]
fee=Mo-Fr 08:00-20:00; Sa 08:00-16:00 [because residents have to pay a fee here ...]
parking:condition=residents [parking:condition=* on amenity=parking is OK due to the wiki page]
parking:condition:residents=B2
parking:condition:time_interval=Mo-Fr 08:00-20:00; Sa 08:00-16:00
capacity=4
surface=paving_stones
lit=yes
...

I hope, no one has a problem with the "parking:condition" tagging on an amenity=parking area (without the subkeys both/right/left). The wiki page of parking:condition=* says, it's OK. But what about the "no_parking" condition?

Tagging with "parking:condition:default=no_parking" has the same problem as mentioned in version A. Perhaps an additional "access=no"? But it's not the same as "no_parking" ... Or "maxstay:conditional=3 minutes @ Mo-Fr 20:00-08:00; Sa 16:00-24:00; Su 00:00-24:00" (because you can park a car for 3 minutes in a no-parking zone in Germany)? Also not the best solution, I think .... Or adding these tags to the street (like in version B):

parking:lane:right=no_parking
parking:lane:right:no_parking=street_side

But without an access=no condition or something like that on the amenity=parking area, the default would be free parking out of the resident parking times, I think – if you (or some data consumer) only look to the amenity=parking.

Any suggestions/ideas? --Goodidea (talk) 02:42, 22 December 2020 (UTC)

This is really a strange order of the additional signs! Actually, you're right: your interpretation 1 would probably be the one that results from the order of the signs. But I'm pretty sure that interpretation 2 is meant, because residents are supposed to be able to park their vehicles there at night, while the parking spaces are supposed to be available during the day, e.g. for delivery traffic... (Maybe you can ask the city or the traffic authority what is meant :)
Depending on the interpretation, I would tag it according to the parking:lane scheme as follows (Note: I use conditional notation, which is unfortunately not yet documented in the wiki, but is already in use):
parking:lane:right=parallel
parking:lane:right:parallel=street_side
+ Interpretation 1:
parking:condition:right=residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
parking:condition:right:residents=B2
parking:condition:right:default=no_parking
+ Interpretation 2:
parking:condition:right=residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
parking:condition:right:residents=B2
parking:condition:right:default=free
As for tagging for separate areas, I would agree with you: This is a question of principle that needs further clarification. Here's how I would do it (and how I've already done in my area):
amenity=parking
parking=street_side (!)
parking:orientation=parallel
+ Interpretation 1:
access=yes
access:conditional=residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
maxstay:conditional=load-unload (in my opinion a good variant for describing "no_parking" according to german law)
maxstay:conditional=no @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
+ Interpretation 2:
access=yes
access:conditional=residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
(or, in the strict sense, maybee access:conditional=residents;load-unload @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00), but this is yet another new uncertainty...)
A way of tagging the parking permit number would still have to be developed in this case, at least I don't know any. Maybe "access:conditional:residents=B2"?
For both the parking:lanes scheme and separate spaces, condition tagging is not really well developed and previous approaches are poorly documented. So the more such discussions we have, the better :) --Supaplex030 (talk) 10:50, 22 December 2020 (UTC)


Thanks a lot for the detailled answer! (And for adding my signature, I think, I forgot it ...) Yes – I think, we are moving quite far away out of the (poorly) documented concepts ... and many questions arise there for me. And my tendency goes more and more NOT to tag such situations at all as long as the community couldn't strike an agreement. (Or you would create a lot of taggings which perhaps has to be changed again ... and that could be quite complicated in these cases. The result could be a lot a different variants.)
And yes, I am really not far away from writing to the city/traffic authority and ask how these signs are meant ... would be easier to talk about ONE interpretation. But on the other hand, it's a good example of "real word situations" ... Who said that mapping would be easy? :)
And yes: I agree, that interpretation 2 makes more sense. It's also logical, because the word "frei" (free) on the 2nd sign for the residents normally "overwrites" the main sign. (Like with "bicyle free" sub signs under a dedicated footway sign – sign DE:239 + DE:1022-10). Following THAT logic, the 3rd sign with the time conditions can only belong to the main sign (no parking). The result is: residents are allowed to park there at every time (here specially also during the "no parking time interval"), and default is free, and during the time conditions it's "no parking" for public traffic (everyone who doesn't has a resident parking permit B2). So perhaps, we should only talk about interpretation 2 ...
To your tagging proposals (I limit myself to the 2nd interpretation):
First, the conditional tagging is surely smarter and I also would support to use it. It's only very bad that the wiki page about conditional restrictions still claims: "Does not apply to: Parking lane restrictions as the parking lane scheme has defined its own way of dealing with conditions." :( Too bad ... I know, there is a discussion since a longer time (but don't know exactly the current state).


For the parking:lane scheme: your proposed tagging is missing the "no parking" time interval. Perhaps you have to use the subkeys ":1" and ":2" to complete it, but the problem is, that you will end in two conditions for the SAME time interval, and it's not clear which one has a higher priority (I think this is also the fundamental problem to intuively understand this combination of signs at all). And I will keep the conditional notation here, it's clearer:
Lane tagging version 1:
parking:lane:right=parallel
parking:lane:right:parallel=street_side
parking:condition:right:default=free
parking:condition:right:1=no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00) (two conditions with the same time intervall!)
parking:condition:right:2=residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00) (two conditions with the same time intervall!)
parking:condition:right:2:residents=B2
I thinks, this is not OK (?). Then I was thinking about NOT the set the default to "free", but to "residents", would also be logical, because only THEY are allowed to park there at EVERY time. The tags could be:
Lane tagging version 2:
parking:lane:right=parallel
parking:lane:right:parallel=street_side
parking:condition:right:default=residents
parking:condition:right:default:residents=B2 (not really documented in the wiki ...)
parking:condition:right:1=no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
parking:condition:right:2=free @ (Mo-Fr 20:00-08:00; Sa 16:00-24:00; Su 00:00-24:00)
But that would mean, that the ":1" no_parking condition also affects the residents in the given time interval, because the conditional expression outweights the default. Not OK ... So perhaps the only solution would be to set the default to "no_parking", but then you end to be out of the documented lane scheme, because "no_parking" is not documented as a value for parking:condition:
Lane tagging version 3:
parking:lane:right=parallel
parking:lane:right:parallel=street_side
parking:condition:right:default=no_parking (undocumented use of "no_parking" as a value for parking:condition!) [Subsequent comment from December 19, 2021: now it is documented!]
parking:condition:right:1=residents @ (24/7)
parking:condition:right:1:residents=B2
parking:condition:right:2=free @ (Mo-Fr 20:00-08:00; Sa 16:00-24:00; Su 00:00-24:00)
The result of these 3 versions is that nothing fits 100% to the documented lane tagging scheme at this time (if I am not missing something). Version 3 perhaps would be the one with the smallest deviation from the documentation, but it's still a deviation.


And for tagging as a separate area (amenity=parking): Your examples clearly shown that a new access value for "no_parking" is needed ... "load-unload" is not bad for Germany, but I'm not sure if it correponds to all "no_parking" restriction rules worldwide (also in Germany it's not only load/unload, but can also be a maximum of 3 minutes of parking, but you are not allowed to leave the car ... complicated). A value which simpy corresponds to the sign and lets open every legal rules behind it would perhaps be better. So it has to be the wording "no_parking" I think ... And strictly said, "no_parking" is not an access category (and I'm sure it wouldn't be accepted by the community as a new access value), it's a special parking condition ... So perhaps, here it's really necessary the parking:condition scheme, and that would be the smallest change, I think .... it could be like that:
amenity=parking
parking=street_side
access=yes
access:conditional=residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00)
parking:condition=no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00); free @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00 AND residents) (2nd conditions overweights the first, see Conditional_restrictions!)
So, according to the wiki page about conditional restrictions, we need a <restriction-type> – that would be parking:condition=* (already exists and documented) and a <restriction-value> – here "no_parking" and "no_stopping" would have to be added – and we could use "residents" as a "User group" (which is not really well documented, but could be easy to be added here; easer than an access value – see below).
But – IMO a big "but" – and I'm not sure if you are aware of that: the value "residents" is not a common access value at all! JOSM for example produces a validation error with this value if used for access:conditional ("is not a restriction value"). It's not in the List_of_possible_values of Key:access, and taginfo for access counts only 2065 uses (compared to 9729323 for "private") – that's nothing ... And I think it will be hard to find acceptance for a new value here. That's why we would have to drop the line access:conditional=residents @ ... (it's also not really necessary) and simply write:
amenity=parking
parking=street_side
access=yes
parking:condition=no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00); free @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00 AND residents)
parking:condition:residents=B2 (corresponds to the lane tagging scheme)
For the notation of the parking:condition line see Conditional_restrictions#Combined_conditions:_AND and Conditional_restrictions#Evaluation_of_conflicting_restrictions.
So the only really new thing which is left over, as far as I see it: adding "no_parking" as a value for parking:condition=* and allowing the conditional notation for parking:condition=* – because parking:condition:conditional would be weird. Then you could use the lane tagging scheme (see "Lane tagging version 3") OR the scheme for amenity=parking (see the lines above).
So maybe starting a vote for adding "no_parking"/"no_stopping" to parking:condition=* values? Or how could that be accomplished? I am not very familiar with that ... What do you mean? Am I missing something? --Goodidea (talk) 02:12, 24 December 2020 (UTC)


You don't need to explicitly tag the "no_parking" time interval, because residents already implies that other vehicles are not allowed to park there during this time. (We aren't tagging the signs here, but their meaning – you could use traffic_sign=* to map the signs itself, in this case something like traffic_sign=DE:286;1020-32[B2];1042[Mo-Fr 08:00-20:00; Sa 08:00-16:00];1053-34 could fit on the parking object).
Also, the parking:lane:*:default value does not have to correspond to the one that applies "always" or "most of the time", but it simply corresponds to the value out of the times of the time interval (see also the examples in the wiki!). Just keep it simple ;)
About the access values: In a case like this, where the aim is to develop new solutions, I don't think it makes sense to stick too closely to documented values (or their number at TagInfo), because since it's new, the suitable values can't even exist yet! Many proposals arise from de facto tags that are already "wildly" used, tested in practice, perhaps later discarded, improved or accepted in use. Your idea with "parking:condition" is interesting, though, and should be put up for discussion, but I think you can also get it right with just using access=*.
I think the first step to find an accepted solution for this would be a discussion on the Tagging Mailing List. If no one else starts it, I will do that one day, but at the moment I have too many other things on my to-do list (and sometimes I think it's not bad to wait and see what solutions emerge "in the wild" – there might be some confusion and inconsistency at the beginning, but the solution might be all the better in the end – my opinion!) --Supaplex030 (talk) 09:53, 24 December 2020 (UTC)


Thanks a lot for your useful comments ... I mainly agree and understand. I only think that your first sentence (that it's not necessary to tag the "no_parking" time interval) is wrong. Becauce the second condition free @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00 AND residents) ONLY fits to residents (because of the AND) does not say that other people are allowed to stop there for some minutes or loading/unloading in the same time interval (that's the tricky thing with this situation – at the same time where residents may park there, others may stop there for a short "no_parking" time – and out of the time interval it's free for everyone. At least I am quite sure now that this is the meaning of the signs = interpretation 2, see above).
So the "no_parking" intervall has to be in the condition, too (important: in this first place to be the "main" condition in this time interval). I'm quite sure at least ... It has nothing to do with tagging signs without any sense or necessity – I think, I this case it's the only way (I found) to correctly tag the complete meaning of the signs, which is quite complicating at a frst or even second sight.
And for a discussion of new values or new tagging scheme: I understand what you mean, I was only searching for a way with the least neccessary changes to documented methods which could reduce discussions and make it easier to reach agreements. And I would propose to take one (or more) really tricky situations (like this perhaps) for a discussion and find the best (and easiest) solution for all of these (you could say "worst case") cases ... And I know it could be tricky to follow the sentence of Bruno Munari "Progress means simplifying, not complicating." (AND to consider all cases.) In this case I would be happy, if an easier way of tagging (and readability of the tags) would be possible, but I'm not sure if a really easy way IS possible here (even with new values for access, which is perhaps not a good idea, I think – it has too many implications, long discussions, low acceptance and so on) ... --Goodidea (talk) 14:00, 6 January 2021 (UTC)

A Summary

It has been almost a year since I wrote this post, and because it has become such a long text, I wanted to add a (hopefully clear) summary ...

First – this combination of traffic signs is to be interpreted in the following way. (To confirm, I spoke to a policewoman on site and it is also quite well documented on the (German) Wikipedia page of “Haltverbot”.)

 Traffic sign combination  German traffic sign numbers  Meaning / Interpretation
German traffic sign 286 (no parking) with additional signs for residential parking (1020-32) and time intervalls (1042-33).jpg
  1. 286-11 („Eingeschränktes Haltverbot“ / “no parking”)
  2. 1020-32 („Bewohner mit Parkausweis Nr. ... frei“ / “Residents with parking permit no. ... free”)
  3. 1042-33 or 1042-34 („Zeitliche Beschränkung“ / “Time limit”)
  4. 1053-34 („Auf dem Seitenstreifen“ / “On the parking lane”)
  • The condition “no_parking” is valid Mo-Fr 08:00-20:00; Sa 08:00-16:00 – otherwise parking is free (so default is free parking!)
  • Residents with permit “I1” are allowed to park there at every time. *
  • Parking position – not important here – is something like "painted_area_only" (but this combination of signs is also used in the case of a parking bay, then "street_side" would fit better)


* Note: The german road traffic regulations (StVO 2013 of 2021-07-12) says to the additional sign for residents in „Anlage 2 Lfd.Nr. 63.4“: „Das Zusatzzeichen zu Zeichen 286 nimmt Bewohner mit besonderem Parkausweis vom Haltverbot aus.“ / “The additional sign to sign 286 exempts residents with a special parking permit from the no-parking permit.”)


And I would tag it in this way(s):

Traffic sign combination My proposed tagging
(“traditional” parking:lane scheme) 		My proposed tagging
(using a new – proposed – parking lane conditionals scheme)
German traffic sign 286 (no parking) with additional signs for residential parking (1020-32) and time intervalls (1042-33).jpg Case 1: Tagging for amenity=parking with parking=street_side (if the parking lot was drawn as an extra area). 

amenity=parking
parking=street_side
access=yes

parking:condition=no_parking;residents
parking:condition:time_interval=Mo-Fr 08:00-20:00; Sa 08:00-16:00

parking:condition:residents=I1
parking:condition:default=free


amenity=parking
parking=street_side
access=yes

parking:condition=free
parking:condition:conditional=no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00); free @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00 AND residents)

parking:condition:residents=I1

Some (less important) notes on Case 1 – a little off-topic, but it's also part of it (for the sake of completeness):

  • I would add access=yes, because it's generally a public parking, accessibly for everyone – with free parking for everyone out of the given time interval and short time parking during the time interval. The parking permit for residents with further rights does not change anything in this regard.
  • I would not add something like access:conditional=private @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00) to express that only residents (= some kind of a private group of people) are allowed to use the parking during that time, because it ignores the short-term parking option for everyone during the time interval.
  • I would not add any fee=* tag, because it's too hard to express and too unclear/not well documented how it should be applied here (residents have to pay a monthly or annual fee for their parking permit, which they can use to park there at any time. Perhaps you would have to write something like: fee:conditional=yes @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00 AND residents)? But this also ignores the short-term parking option for everyone during the time interval – so it wouldn't be correct IMO. And fee=no wouldn't be correct neither – except out of the time range! So you could perhaps write a conditional fee tag for that. Or to cover everything: a conditional expression with 3 value@condition pairs to cover all cases (1. during the time_interval/no_parking; 2. during the time_interval/residents; 3. out of the time interval). But I didn't want to overload this example any further. But if someone wants to do it ... you are welcome ...
Case 2: Parking:lane tagging for a highway=* way (if the parking lot was NOT drawn as an extra area).
... assuming that the parking lane is on the right side, parking position is parallel and it's a marked – painted – parking lane 

parking:lane:right=parallel 
parking:lane:right:parallel=painted_area_only

parking:condition:right=no_parking;residents
parking:condition:right:time_interval=Mo-Fr 08:00-20:00; Sa 08:00-16:00

parking:condition:right:residents=I1
parking:condition:right:default=free


parking:lane:right=parallel
parking:lane:right:parallel=painted_area_only

parking:condition:right=free
parking:condition:right:conditional=no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00); free @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00 AND residents)

parking:condition:right:residents=I1

Some important notes/thoughts to both cases (and the two tagging variants)
  • The special case of this traffic sign combination is, that there are two different conditions which are valid at the same time (during the given time interval): no_parking and residents parking (parking without restrictions for residents).
  • Due to the old scheme this can be solved by the double value no_parking;residents – and exactly this is not possible in such a simpel way with a new conditional scheme, because only single values followed by a condition is allowed (and several such value@condition pairs can appear one after the other with a ";" separated).
  • Here the old scheme has an advantage of simplicity IMO.
  • And to mention it: the value "no_parking" can be a value for parking:lane=* as well as for parking:condition=*, which is important for this case (see Wiki). And the value "residents" is a documented value for parking:condition=* as well.
  • And out of the time range it's a no brainer, because then parking is allowed for everyone. This is expressed by the default condition parking:condition:default=free / parking:condition:right:default=free.
  • At the time I wrote this summary, the proposal for a new conditional scheme had not yet been finalized (and there is even a counter-proposal) and the exact syntax had not yet been determined. I've used the most likely form, and anyway it's more about the conditional expression than the syntax of the keys.
  • Although the form of the condition seems to be over complicated, I think it's the only way to express the complete meaning of the sign, specially in the indicated tiime range – because in this range, there are the two two conditions at the same time: no_parking (which means in Germany: you are allowed to stop for some minutes or loading/unloading) and residents are allowed to park without any restrictions.
  • The tricky thing is the fact, that the two conditions have the same time range, and in this case the second condition normally overweights/beats the first condition. So you cannot simply write: no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00); residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00), because the 2nd pair would overwrite the first pair and it would be residents parking only at the given time interval ... (See Conditional_restrictions#Combined_conditions:_AND and Conditional_restrictions#Evaluation_of_conflicting_restrictions). This conflict can only be solved by the addition of AND residents. At least I see no other way.
  • And out of the time range it's a no brainer, because then parking is allowed for everyone. This is expressed by the default condition parking:condition=free / parking:condition:right=free.

That was a lot for a traffic sign that was simple at first, I know ... but I hope to have presented and explained reasonably clearly why I do not consider it a simple case or see great possibilities for a simplification. At least not with the currently documented (or proposed) tagging schemes. If someone sees possibilities for simplification or a mistake in reasoning, then I ask for contributions ... --Goodidea (talk) 02:46, 19 December 2021 (UTC)

German traffic sign 286 (no parking) with additional signs for residential parking (1020-32) and time intervalls (1042-33).jpg
After some discussions, I am currently working on adding a paragraph regarding the tagging of parking restrictions in order to provide some standardisation here. Along with this, I came across this case again and would tag it like this:
for separately mapped areas:
(using standard access/fee/maxstay tagging)
    • amenity=parking
    • parking=street_side
    • access=yes
    • maxstay:conditional=load-unload @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00), no @ residents
      • or maxstay:conditional=3 minutes @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00), no @ residents (3 minutes only according to german law)
      • or access:conditional=private @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00) (simpler, but ignores the possibility of short standing)
    • parking:residents=I1 (to be proposed)
    • fee=no (because you don't have to pay a fee on site - even residents have already paid in advance. That's my interpretation - there is no documented interpretation so far.)
for parking lanes mapped on the highway line:
(with new conditional-Tagging)
--Supaplex030 (talk) 08:44, 10 October 2022 (UTC)

surface or street_side?

I've recently mapped 1000 street_side parking lots and have some questions/doubts:

1) parking1.jpg: street_side or surface or should I redraw it for 3x street_side?

Both approaches are possible, but in this case it looks like surface is correct. For me the difference lies in what the street does: here it looks like it is used exclusively for the parking area. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)
As with many of the following cases, I would use "surface" here - see comment below! --Supaplex030 (talk) 00:13, 12 January 2021 (UTC)

2) parking2.jpg: How about this?

Can be either. Again depends on how that street is used. From what I can see surface looks good, mainly because the street end there. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

3) parking3.jpg: I tagged it as surface but not sure. It looks like a wild, not marked parking lot.

I would go with surface. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

4) parking4.jpg: This is an interesting case. I can either do as it is now and mark it as parking=surface, because there is a parking_aisle inside it or reduce the size of the polygon so it doesn't inlcude the road and mark it as street_side - which is more appropriate?

Is that parking aisle exclusively used for parking cars? JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

5a) parking5a.jpg: One parking=surface or 2x street_side? There is a kerb between them.

Either would work. I would let it depend on how it fits in the broader picture of that area, and, again, the usage of those streets. Are they used for residential access, through-traffic, or only for parking cars? JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

5b) parking5b.jpg: Similar to 5a but there is no kerb :)
5c) parking5c.png: I would tag all of them as street side. And you?

Could be one area of parking=surface as well. Those ways look like parking aisles, with a residential road passing on the right. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

6) parking6.jpg: Is it street_side?

This looks more like a candidate for parking:lane=*. It looks like half_on_kerb parking, which is hard to map nicely explicitly. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)
I go with Jeroen: This case looks like a parking:lane=* (if parking (even only partly) takes place on the carriageway, parking:lane is the better choice (or parking=lane, if you realy want to map it separately, but I think, it's not recommended here, because there is no clear parking area).--Supaplex030 (talk) 00:13, 12 January 2021 (UTC)

7) parking7.jpg: 3x street_side or 1x street_side or 1x surface? How would you tag it?

Depends on the use of the street again. Is it one area dedicated to parking cars, or is it a street that has parking on its left and right side? Hard to tell from the zoomed in photograph. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

8) parking8.jpg: How would you tag it?

Is there through-traffic from the roundabout to the upper-left corner of the photograph? JeroenHoek (talk) 10:18, 11 January 2021 (UTC)

9) parking9.jpg: Would it be ok to tag it as 1x street side? Grass is just a detail.

Looks like street_side parking. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)
I think it might be ok zu map it as one area with parking=street_side (even if I would draw different areas with capacity=3 for myself :) But you could consider to use parking:lane:*=perpendicular + parking:lane:*:perpendicular=street_side on the highway line instead, if you aren't interested in the details.--Supaplex030 (talk) 00:13, 12 January 2021 (UTC)

10) parking10.jpg: I found such an interesting case. It's like street_side on lane...

Looks like street_side parking. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)
Funny. I think I would prefer "lane", but "street_side" could also be ok. In my mapping practice, I always think about how to define the width:carriageway=* (road width). In this case, there is only a small chicane (formed by the parking lot), but the street in general (as an physical object from kerb to kerb) isn't changing it's width. That's why I would prefer "lane".--Supaplex030 (talk) 00:13, 12 January 2021 (UTC)

11) parking11.jpg: How would you tag it - street_side or lane? The parking space is actually on a lane but not exactly... maro21 19:08, 10 January 2021 (UTC)

Are those red areas raised kerbs? If the outline is hard to draw here, you could use parking:lane=* instead.
Depends on the exact structural situation. If there is, for example, a (even lowered or flushed) kerb between the lane and the parking area, I would prefer "street_side", if there is only a different surface or color, it's "lane". On the picture, it very looks like lane parking, because there are only some kerb extensions at the end. My definition for street_side parking in combination with kerb extensions is, that I use "lane", if the kerb extensions are only at the end or beginning (often to protect crossings, not to build parking spaces – "width:carriageway" isn't reduced in general) and I use "street_side", if there are multiple kerb extensions that are building/structuring "parking pockets" ("width:carriageway" is reduced in general).--Supaplex030 (talk) 00:13, 12 January 2021 (UTC)
All in all, there is some overlap between parking=surface and parking=street_side in these cases you show. I have encountered such examples myself as well, like this one. I mapped that as two street_side parking areas, but one large parking=surface wouldn't be wrong either. The criterium I use is what the function of the 'street' there is. Is it just a parking aisle, or is it used for more? In this case, residents use that street to gain access to their houses by foot and bicycle as well, so street-side parking seemed a better fit. On the other side of that tertiary road there is a parking=surface for the shopping mall there. There the ways on it are much more clearly intended as service ways for the parking lot, and the parking lot is something you might want to navigate to as well (which is not a common use case for parking areas in front of houses). There is some ambiguity here, but that is OK; some overlap in unavoidable. JeroenHoek (talk) 10:18, 11 January 2021 (UTC)
I would define most of the cases as parking=surface, namely when the parking spaces are on an access or service road (classification "service") without significance for through traffic. "street_side" is rather meant for "real" through-roads. I have left separate comments on some cases where this is not the case. Your questions and examples encourage me to write a text to better define the distinction between street_side and other forms of parking. Unfortunately, I won't have the time to do that soon :( --Supaplex030 (talk) 00:13, 12 January 2021 (UTC)

amenity=motorcycle_parking?

What about amenity=motorcycle_parking? Should it not be added as a combination for parking=street_side (here and on the wiki page of amenity=motorcycle_parking)? In my city, I saw at least one motorcycle parking which perfectly fulfills the "street side" parking criteria. --Goodidea (talk) 03:20, 23 March 2021 (UTC)

It probably can, judging from the amenity=motorcycle_parking documentation. That tag already uses parking=*, so I can't see why not — I did it myself here. I think you can safely go ahead and edit the documentation to reflect that. --JeroenHoek (talk) 07:22, 23 March 2021 (UTC)
Thank you for the confirmation. I also can't see why not. Because there were no negative replies, I added it now here and on the wiki page of amenity=motorcycle_parking. I hope it's ok like I did it. --Goodidea (talk) 03:59, 27 March 2021 (UTC)

Relating to street

@Supaplex030: I noticed you add *:of=* and *:of:name=* in https://wiki.openstreetmap.org/w/index.php?title=Tag:parking=street_side&oldid=2364362 -- Can you separate your community's use from general advice? Putting aside my doubts on is_sidepath:*=*, what you need is a general attribute, not another suffix. There is already object:street=*, fire_hydrant:street=*, water_tank:street=*, water_tower:street=*, etc. Not to mention naptan:Street=* for import.
If only is_in:*=* will have its complaint about being deprecated stopped (it's not where there is no boundary=administrative), I would suggest simply is_in:street=* or similar. (Off-topic: I don't like contact:street=* and post:street=* much)
--- --- Kovposch (talk) 19:03, 16 October 2022 (UTC)

If we follow the new street parking revision proposal, then we indeed need a better solution. Otherwise we would also have to introduce *on_kerb:of:name=* etc., and I don't think that makes sense. object:street=* might be an easy solution (even though I personally think it useful to align this to the sidepath scheme, but do not see an easy adaptation here).
Since it is an experimental tagging, I have deleted the section on the page for now. --Supaplex030 (talk) 13:43, 17 October 2022 (UTC)

Rendering in OSM Carto

Regarding Special:Diff/2621249 @JeroenHoek: OK, but I can't see the icon on the map. In what cases is the symbol displayed? I've checked at way 1148765507 and way 33798584. --Chris2map (talk) 09:40, 25 November 2023 (UTC)

I took another closer look and I think now got it: If parking=street_side is attached to amenity=parking then the smaller "P" is displayed instead of the default "P". --Chris2map (talk) 09:47, 25 November 2023 (UTC)
parking=street_side requires amenity=parking (or a similar parking area tag like amenity=motorcycle_parking, but mostly amenity=parking). Using it with amenity=parking_space is not within the scope of this tag. --JeroenHoek (talk) 10:23, 25 November 2023 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:parking%3Dstreet_side&oldid=2621544"