Talk:Street parking

Residential parking permits are not permits....really?!

The section on residential parking permits refers to parking zones (where you, in the UK at least, must obtain a permit from the local authority for a fee after proving that you are resident in that zone, and possibly joining a waiting list as places are limited). The section then states that this is access=private and not access=permit. Obviously you've discussed this and will shoot me down but, huh?! IMHO it is the very definition of a permit. The heading even includes the word 'permit'. Access=permit. Jnicho02 (talk) 12:16, 10 December 2022 (UTC)

The reason for not using "permit" as a value is explained in the article itself, referring to the description of access=permit in the wiki. If you can't follow this explanation, it would be helpful if you stated what exactly you can't follow so the documentation can be improved to be clearer. The issue with the "permit" value in the old street parking scheme was also touched upon in the discussion for the proposal here Talk:Proposed_features/street_parking_revision --Westnordost (talk) 18:14, 10 December 2022 (UTC)

Exactly. The access value permit is often misused in OSM because it's definition doesn't match the literal meaning of this term - see access=permit: permit "is routinely granted to everyone requesting it. In cases where access to permit is obstructed it would be more appropriate to tag these areas access=private or access=no. So access=permit does not apply where permit is rarely granted, or only granted in exceptional circumstances, or if obtaining it is complex or there is a long waitlist.".

But such residential parking permits aren't granted to everyone requesting it, because you need to be a local resident at least. If I'm not living there, I can't go to an office to request and get a permission (like it's the case e.g. in some wildlife / back country activities or so, where this access value is useful). --Supaplex030 (talk) 20:41, 10 December 2022 (UTC)

In many places in the UK, on street resident parking zones (RPZ) really do seem closer to access=permit than access=private. Annual permits are granted to residents who demonstrate the residence criteria for the zone and pay the appropriate fee. There are often no capacity limits or waiting lists, however the charge per permit may increase for each additional vehicle. In addition to this, any resident may obtain visitor parking permits for visitors or tradesmen (limited to 20 per month where I live). A permit in these RPZs is granted on request routinely, easily and without a waiting list, which hardly fits access=private. Resident parking on newer housing developments on the other hand, is usually marked street_side bays, privately managed, and definitely access=private.

A typical resident parking scheme in London only applies during normal weekday working hours, with no waiting restrictions outside those hours. Some zones near me have an even shorter restricted period, Mo-Fr 10:00-12:00. This is because one of the main aims of the schemes is to deter commuters from driving further into London before parking and using public transport into the centre. I am inclined to tag my local restrictions, for marked residential parking lanes on both sides of the street, like:

parking:both=lane + parking:both:markings=yes + parking:both:access=yes + parking:both:access:conditional=permit @ (Mo-Fr 08:00-18:30) + parking:both:permit=residents + parking:both:zone=***

--Rskedgell (talk) 10:55, 27 December 2022 (UTC)

Issue raised in OSM Community Forum https://community.openstreetmap.org/t/resident-parking-access-permit-gb/106069 --16:00, 16 November 2023 (UTC)

The sign just says parking by permit only

• https://goo.gl/maps/u8R7BWwU89ZFgZJk6

I would have used parking:side:access=permit but the wiki page says I can't. No, we cannot just assume we know who can apply for a permit... that would be guessing, and we want to map the Ground truth right now with what we see. And no, it doesn't say "zone" on it. Jidanni (talk) 15:12, 21 August 2023 (UTC)

Why don't just use parking:side:access=private? That's probably the most correct value without guessing. --Supaplex030 (talk) 20:10, 22 August 2023 (UTC)

parking:side:direction=head_in

Need add diagonal picture Corsa5 (talk) 15:39, 19 December 2022 (UTC)

Added the image, but this is a very rare case, because this is the standard direction and therefore there is no need to explicitely signpost (or tag) this direction. --Supaplex030 (talk) 20:29, 19 December 2022 (UTC)

Are there tram_lanes?

According to local legislation, it's forbidden to stop on lanes shared with rail vehicles. I don't see this reason, only parking:side:restriction:reason=bus_lane. Should we explicitly add tram_lane or rails? Or would a generic legislation be more helpful to specify that there are legal reasons, without going into details?

I think reason=rails sounds like a good value. The reason list is just a list of "suggestions" for different situations, so it can never be "complete". You could either just use a value like this or feel free to add it in the list (my opinion). --Supaplex030 (talk) 20:33, 19 December 2022 (UTC)

Resolved

Suggestion to remove parking:side=shoulder

I would like to suggest to remove shoulder and amend the documentation for

• on_kerb with ", or otherwise adjacent to the street"
• half_on_kerb with ", or otherwise partially off the street"

or similar.

In a nutshell, broaden the definition of on_kerb and half_on_kerb to effectively "off/partially off the street surface" because this is the information that matters and whether there is a kerb or not or whether there is a shoulder or not can be ascertained via their respective own tags.

I know that shoulder value is part of the approved proposal, but actually it was just inherited from the old tagging schema without a second look and its usage has been minuscule (factor 10 less or so from the next more used value). More details below.

Reasons in detail

1. shoulder makes no actual statement about the parking position

shoulder was included because it has been present in the parking:lane=* schema which defined the value referring to the shoulder=* tag. A shoulder=*, however, is defined really broadly. It could be a hard shoulder (i.e. on asphalted surface, separated by line), it could be a soft shoulder (e.g. a gravel surface adjacent to the street) or it could be a bit of both, including a shoulder that is in total not broad enough to accommodate a car completely off the traffic lanes. In summary, the cars could actually be parking on the street, half off the street or adjacent to the street. Hence, as a data consumer or someone who wants to visualize the parking (in an OSM editor such as StreetComplete), one is not any wiser as for the location of the cars. The information that there is a shoulder (and what are its properties) is already defined in shoulder=*.

2. shoulder was unilaterally added later, minuscule usage to this day

For the new parking schema, the values of the now deprecated parking:lane=* schema were inherited. The parking positions in the parking:lane=* schema were added 2012 to the documentation. However, shoulder was added 2018 without any prior discussion by a single user (and was immediately misunderstood a few months later as synonymous to lay_by) Additionally, actual usage of the tag is very very minuscule, it ranges at about 0.2% which is in the range of other invalid/undocmented tags such as by_lay, one_lane, parallel etc.

3. shoulder can be easily misunderstood in translation

Touching on point 1, the understanding of what constitutes a shoulder differs somewhat regionally. A prominent example is Germany, where shoulder translates to "Seitenstreifen". However, signs that indicate "Parken auf dem Seitenstreifen" should actually be tagged not with shoulder but with on_kerb or street_side (ex-lay_by) (example photo)

In fact, the very addition of this tag value might as well have been a misunderstanding in the first place. (We'll never know).

4. shoulder has a difficult differentiation to other values

a) For parking on hard shoulders, it is difficult or impossible to differentiate between "shoulders (= breakdown lanes) on which cars park" (shoulder) and "parking lanes" (lane) i.e. street parking separated from traffic lanes with a continuous line: If no car parks in a marked parking lane, it sure looks like a shoulder. If many cars park in a shoulder, it sure looks like a marked parking lane. (See for example the left side here)

Indeed, no information is lost if all parking on hard shoulders is tagged with lane because the information about the existence of a shoulder=* is tagged separately and if a shoulder is present, it is a matter of course that cars park on it. (I.e. to have a breakdown lane behind the parking lane as seen from the center of the street does not make sense because then it would not be a breakdown lane anymore).

b) For parking on (shoulders) adjacent to the street, it is in turn fuzzy to differentiate between on_kerb or even street_side.

First of all, what if there is parking half on the shoulder (i.e. half off the street)? There is no value for that, there is only half_on_kerb. (Subsequently, that tag is used for this situation which is a de-facto broadening of its originally intended meaning). Also, what if there is parking off the street but it is not a shoulder as per definition of shoulder=* but e.g. just a verge or just dirt, some area? There is also no value for that.

on_kerb is to be used if the parking is up on the curb. According to the documentation, (also) if it is on the area that would otherwise be part of the sidewalk. Now, not all sidewalks have curbs towards the road. E.g. if there are sidewalks in living streets, they usually do not have a curb. Also, in villages with less paved infrastructure, sidewalks are often unpaved and basically just a compacted area left and right of the street (like a shoulder). Especially in the latter case, if becomes somewhat difficult to differentiate between these values.

In summary, shoulder does not cover all cases of "there is some space beside the road to park but it is not up on a curb" and at the same time, on_kerbs (and half_on_kerbs) documentation can already be interpreted so widely that it overlaps with that of shoulder.

I asked in slack US about how they would denote this situation (which should be tagged on_kerb). I got the following replies:

• "The word for this space is extremely balkanized in American English [...] people called it a berm and others called it a tree lawn, and still others called it a verge"
• "parking off the street"
• "off the pavement"
• "up on the curb"

5. shoulder was never supported by StreetComplete parking overlay

This is of course not a good reason per se, but it is a matter of fact that a significant percentage of current parking tagging was created with and hence formed by how the values were presented by StreetComplete as it has been the only editor to actually support the parking lanes schema. The app has been showing on_kerb simply as "adjacent to the street" (etc.) for a subset of the reasons as given above.

Note that the parking overlay was implemented based on the old parking:lane=* schema which never was approved and contained a plethora of other either "in use" tags (but that were not documented) and other documented but not in-use tags as well. Since shoulder was not actually in use and has the above issues, I chose not to support it. It is only now an issue that the new parking schema has been approved and with it the shoulder value has sneakily achieved some sort of official blessing.

--Westnordost (talk) 15:18, 27 January 2023 (UTC)

I'll try to give another definition to illustrate why I think the distinction between both values is useful and significant.

on kerb parking is intended for parking on sections beside the road separated by a kerb that are usually dedicated for pedestrian traffic, or in some cases would be dedicated for pedestrians if there would be no cars parking there, or that technicaly belong to areas that are dedicated for pedestrian traffic (the sidewalk edge where street furniture or trees are placed). Probably in a lot of places in the world it's only allowed if signposted (not sure about that), because a kerb borders the street area intended for motorized traffic.

shoulder, in contrast, imho is intended for parking on a section beside the road that isn't dedicated for traffic, neither motorized nor pedestrians. This might be undefined spaces where parking is just taking place on a rather informal base (depending on local legislation), soft shoulders or a somehow managed parking stripe beside the street (e.g. a section with grass paver surface to preserve the ground). Of cause, pedestrians could walk there if no cars would park there, but more likely it would be just a compacted shoulder stripe or a gras verge, depending on the surface, its compactness and management (I just showed three examples in an other context (123) and pedestrians are walking on the carriageway there (picture 1) or on separated areas beside the "shoulder" (picture 2 and 3)).

So the difference between the values on kerb and shoulder is a significant one from a technical/planning point of view, but maybe a dispensable one from a rather simplified perspective of a street complete user. Yes, in a lot of cases it's difficult to distinguish and both are defined rather broadly - but I don't see an advantage to merge both categories to get an even more broad, more or less undefined category in general. Unsharp categories is something common in OSM because reality is more complex than shortened categorization systems ;) Just think about distinguishing between on street and street side parking...

I think in context of parking we are not talking about hard shoulders in most cases, because this phenomenon rarely exist in urban spaces (but street parking is primarily something of interest in urban spaces). So - as you have already elaborated - parking on something that looks like a hard shoulder in a city is actually the same as regular "on street" parking with the difference that parking density is low (maybe just in the moment of the photograph).

So I think one core of the problem we are talking about is that the value shoulder in context of street parking (primarily urban) might be intended for something different than most mappers mean when using the key shoulder=* as a highway attribute (primarily non-urban). Imho that doesn't have to be a problem, especially since there is no better term for it/the term is used for such sections beside the street.

All in all, if you don't want to support the value in SC it might be a solution to interprete/render it like on kerb parking but leaving it untouched if somebody confirms it. --Supaplex030 (talk) 09:55, 28 January 2023 (UTC)

Well, if you define "shoulder" to mean never "hard shoulder" and always verge / soft shoulder / some area next to the street, then you solve point 1 and 4a) but the rest still stands. And that at the price of using a different definition for "shoulder" than for the shoulder tag which is just bound to be be misunderstood. It is also not actually mentioned in the documentation. As I wrote, the old parking:lane=* documentation was very clear about that shoulder necessitates shoulder=* to be set, too.

I understand what distinction you would like to establish: Parking adjacent to the road up on the curb vs parking adjacent to the road but there is no curb. This is difficult to read from the current documentation, as a sidewalk does not necessarily imply a curb, the OSM definition of a shoulder is different (see above) and in any case, then also a value like half_on_shoulder would be missing. If the distinction is worth to record, maybe something like parking:side:kerb (with values from kerb=*) would be a better fit. After all, that's also what has been done for other orthogonal properties of parking like markings, staggered parking and conditional parking - put it into own tags.

(But anyway, I will implement it the way you mentioned) --Westnordost (talk) 13:25, 28 January 2023 (UTC)

The, I guess, general problem with trying to project "construction categories" from the real world into tags (i.e. in this case "street_side parking", "parking adjacent to the street with no further infrastructure", "parking on/next to the sidewalk up on the curb", ...) rather than pure physical or locational properties is that the real world can be wonky at times (or reality may be different in different countries) and such construction categories do make some assumptions that may not always be true everywhere: Not all sidewalks (i.e. footpaths adjacent to streets) do have curbs, not all verges are shoulders, maybe there is even street_side parking with curbs? If I had been wiser during the approval process of this page, I would probably have suggested to replace half_on_kerb, on_kerb, lane with half_on_street, off_street, on_street. But alas, that's just the name of the tag value, hence why I suggested to just amend the documentation by half a sentence. --Westnordost (talk) 14:58, 29 January 2023 (UTC)

Regarding streets where the parking orientation varies on a single side.

Needing clarification for parking lots and street_side/lane parking orientations which have a mix, where in one local street there's markings for all three modes. In these cases the parking:side:orientation=marking has been used. Of course an alternate could be to use semicolon separators leading to for instance =parallel;perpendicular;diagonal but has not seen any use or could be simplified with =mixed. In 2 cases there was parking:right:orientation=parallel|diagonal|perpendicular such as on way 540508622.

Regarding segmentation, I think this is prohibitive. A single street, the sample I mentioned is only 200-250 meter long, starts with markings for parallel, switches to markings for perpendicular, then ends with a section of diagonal. More over not back to back, there's sections in between where no parking is marked. Too much fragmentation in my view. --SekeRob (talk) 10:55, 31 March 2023 (UTC)

If the segments/changes in parking attributes are very short and the street center line shouldn't be cut, separately mapped parking areas seems perfect. Just add parking:side=separate to the street line and map different areas with amenity=parking + parking=lane/parking=street_side/... + orientation=* etc. In any case, this is easier and more precise to interpret than semicolon separated values. --Supaplex030 (talk) 13:06, 31 March 2023 (UTC)

P.S. You can find an extremish example in this area: https://www.openstreetmap.org/way/1146425799 | https://www.mapillary.com/app/?pKey=488891042660539. --Supaplex030 (talk) 13:09, 31 March 2023 (UTC)

parking_space=disabled as a part of parking lane

This case is not well documented. parking_space=disabled is recommended for use inside amenity=parking. There is a case with a parking space dedicated for disabled people along a street, street is already tagged with parking:right=lane. --Plamen (talk) 08:18, 17 April 2023 (UTC)

You can map such "special" parking spaces as a separate area (or node, if you don't know the exact geometry) with amenity=parking (in this case + access=no + disabled=designated). An example can be found at the end of the section about separately mapped parking areas (the third image is a disabled parking space). --Supaplex030 (talk) 09:06, 17 April 2023 (UTC)

I was thinking of parking:right:disabled:capacity=2. Otherwise, I have to tag all other physical properties again. On the other hand 'fee' is excluded and not relevant, so parking:right:disabled:fee=no. But it is going more complicated.--Plamen (talk) 05:53, 18 April 2023 (UTC)

@Plamen: The issue with tagging such "single" parking spaces on the highway line is, that you have to split the line for lots of small segments (at least if you use this method consistently - there might be many such "special parking spaces" in the area if you have a closer look). You can do that, but it makes handling the data also a bit more complicated. A separate geometry, on the other hand, is quite easy to handle, even if you have to tag a few attributes more than once.

But of cause it's up to you which method you like to prefer. Both are ok. --Supaplex030 (talk) 08:54, 20 April 2023 (UTC)

P.S. After reading a second time, I got it: You don't want to split the highway line at all, but just add parking:right:capacity:disabled=2 to indicate that there are 2 disabled parking spaces somewhere along the line. That's also possible, but the least precise variant, as it is not clear where exactly the places are. However, it's easy to map and doesn't make handling the data complicated. --Supaplex030 (talk) 08:58, 20 April 2023 (UTC)

48-hour rule

Some US jurisdictions have rules that required parked cars to be moved every 48 hours. These rules are almost never signposted but are enforced by parking agents. The laws are intended to prevent abandoned vehicles from lingering in the public roadway. Should these restrictions be added to the maxstay tag, i.e., parking:side:maxstay=48 hours? --ElliottPlack (talk) 12:52, 10 July 2023 (UTC)

If this is the low, maxstay is relevant tag even not signposted. Plamen (talk) 11:08, 11 July 2023 (UTC)

"if this is the low" --> If by this you mean there isn't another posted limit, e.g. 2 hour parking only, than this is the default, then yes. I would only use it when there is no other posted max time. --ElliottPlack (talk) 17:43, 12 July 2023 (UTC)

no_parking on lane scheme problem

There is no explanation/replacement in the Streetparking for the deprecated parking:lane, we used parking:lane:both=no_parking, in the key there must be, the carriageway, lane, this should be possible: parking:lane:both:restriction=no_parking, now with extra :restriction, 1 string to do the job. How to tag this in the new method? By EU law the sign NL:E1 [[1]] gives a prohibition only on the lane, carriageway, no_parking, beside the lane there could be al kinds of rules in force for parking on parking:shoulder= parking:streetside=. this lane must be expressed in the key and in the right order. So I think parking:lane could not be deprecated.--AllroadsNL (talk) 12:12, 10 August 2023 (UTC) Additional example: At the same way there could be: a onesided E1 lane prohibition over the whole way: parking:right=lane + parking:right:restriction=no_parking and also on parts of the way parking:right=streetside + parking:right:orientation=parallel, we can only use once, parking:right=[position]. Also parking:right:orientation=parallel refers to the carriageway, lane, this is not right. That is the problem, so there must be :[position]: in the key. In the old, parking:lane and parking:streetside where active, with new scheme, there should be parking:side:position:=*, parking:side:position:orientation=* if you only want to keep parking:side.--AllroadsNL (talk) 18:33, 11 August 2023 (UTC) Discussion on openstreetmapforum--AllroadsNL (talk) 13:14, 1 September 2023 (UTC)

How to map alternate side parking?

In many countries (click for map), the concept of alternate street parking exists. It does neither exist in Germany, Britain nor in the Americas (except New York city, apparently), so maybe it was overlooked during the proposal process of this new street parking schema?

This is how the alternate parking signs look like: Diagrams of alternate-side parking road signs on Wikimedia

The following types of alternate parking exist. Parking prohibited ...

• 

  on each odd day of a month

• 

  on each even day of a month

• 

  from the 1-15th of each month

• 

  from the 16-31th of each month

Now, I couldn't find any place on this wiki page where it is explained how to map this. Has this been overlooked --Westnordost (talk) 15:48, 31 October 2023 (UTC)

Good point. We should explicitly document that. (There was no solution for this in the old scheme, if I remember correctly, that's why it wasn't part of the proposal.)
Since the new scheme allows regular conditional-restrictions, the solutions from this previous proposal should still be valid. Unfortunately, they are very bulky, as the conditional syntax does not seem to allow a "simple" solution. Should we document these or does anyone see a possibility/need for simpler tagging?

Sign	Tagging
	(No parking in first half of month.) parking:right:restriction:conditional=no_parking @ (Jan 1-15, Feb 1-15, Mar 1-15, Apr 1-15, May 1-15, Jun 1-15, Jul 1-15, Aug 1-15, Sep 1-15, Oct 1-15, Nov 1-15, Dec 1-15) Note: The opening hours syntax does not support a "simple" solution like: parking:right:restriction:conditional=no_parking @ (Jan-Dec 1-15)
	(No parking in second half of month.) parking:right:restriction:conditional=no_parking @ (Jan 16-31, Feb 16-29, Mar 16-31, Apr 16-30, May 16-31, Jun 16-30, Jul 16-31, Aug 16-31, Sep 16-30, Oct 16-31, Nov 16-30, Dec 16-31)
	(No parking on odd days of the month.) parking:right:restriction:conditional=no_parking @ (Jan 1-31/2, Feb 1-29/2, Mar 1-31/2, Apr 1-30/2, May 1-31/2, Jun 1-30/2, Jul 1-31/2, Aug 1-31/2, Sep 1-30/2, Oct 1-31/2, Nov 1-30/2, Dec 1-31/2) Note: The opening hours syntax does not support a "simple" solution like: parking:right:restriction:conditional=no_parking @ (Jan-Dec 1-31/2)
	(No parking on even days of the month.) parking:right:restriction:conditional=no_parking @ (Jan 2-30/2, Feb 2-28/2, Mar 2-30/2, Apr 2-30/2, May 2-30/2, Jun 2-30/2, Jul 2-30/2, Aug 2-30/2, Sep 2-30/2, Oct 2-30/2, Nov 2-30/2, Dec 2-30/2)

Supaplex030 (talk) 22:01, 31 October 2023 (UTC)

Short of using  ISO_8601#Repeating_intervals whether expressed in full (similar to *_date:edtf=* ), or as a modifier , I had the idea of modifying opening_hours=* with *:interpolation=* following addr:interpolation=* , in the last proposal. The meaning is it is not recorded exactly, for different reasons (unsupported syntax vs limited info). User:Kovposch#Clearways
The limitation is matching different conditions. Empty multival has to be used, eg parking:*:restriction:conditional:interpolation=odd;;1-15 .
Bad idea to modify opening_hours=* creating fake syntax that isn't supported.
—— Kovposch (talk) 04:47, 1 November 2023 (UTC)

With "fake syntax that isn't supported", you mean Jan 1-31/2, Feb 1-29/2, Mar 1-31/2, Apr 1-30/2, May 1-31/2, Jun 1-30/2, Jul 1-31/2, Aug 1-31/2, Sep 1-30/2, Oct 1-31/2, Nov 1-30/2, Dec 1-31/2 or Jan-Dec 1-31/2? --Westnordost (talk) 12:18, 1 November 2023 (UTC)

Jan-Dec 1-31/2 . It's not pretty to advocate for manually inputting the other one either. You could generate this from your app, or suggest copy-pasting in other software. But it looks unreliable, clutter to reading, and will easily exceed the 255 length limit (this is already 143-chars).
Within the limits of the existing syntax, I will call it done at commenting "Odd days" and "First half of month" .
—— Kovposch (talk) 05:38, 2 November 2023 (UTC)

Do I understand you correctly that you prefer that these signs should not be documented at all? Or, for that matter, documented that there is no good tag for that and thus it is not possible to tag it currently?

In my opinion, any documentation is better than none, even if it it states that there is no good tagging for that (but then, maybe refer to this discussion topic here) --Westnordost (talk) 21:28, 8 November 2023 (UTC)

But it is still possible to use comments though? To compare, for the relatively more known opening_hours:drive_through=* , commenting continues to be listed in Key:opening_hours#Common_mistakes (or maybe mainly as an example for learning). You don't need to encourage the use of some technically valid but cumbersome exhaustive syntax if the usability is low.
—— Kovposch (talk) 07:15, 9 November 2023 (UTC)

Oh, right. I forgot about the "comment"-syntax in the opening hours schema. So, a table like this could go into the documentation?

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

--Westnordost (talk) 15:19, 9 November 2023 (UTC)

Yeah. I imagine people would be more willing to tag this, than to copy & paste that long condition when their editing software doesn't support a preset yet.
—— Kovposch (talk) 10:12, 10 November 2023 (UTC)

Looks good, yeah. There should really be a proposal to extend the opening hours syntax to make the above possible (in case it doesn't break the opening hours schema)...

For the note, maybe make a little clearer that such a solution can not be used unless the syntax is extended in an approved proposal. Something like Note: Do not use "Jan-Dec 1-31/2" as this syntax is currently not supported by the opening hours schema. And if/when there is a proposal for that, it could be linked from there. --Westnordost (talk) 12:18, 1 November 2023 (UTC)