Proposal talk:Street parking revision

Restriction format

First of all, I should point out "standing" is American English. Use "waiting" for British English. There were complaints before. https://discord.com/channels/413070382636072960/428214296695144458/1027917730071978046

I drafted User:Kovposch/Proposed features/Parking lane conditionals as parking:*:access=*, parking:*:waiting=*, and parking:*:stopping=* with 2 reasons:

Modes will be chaotic. Should it be parking:*:access:parking:*=*, or parking:*:access:*:parking=*? Adding usage into access:*=* has more impact in general.
Avoid over-namespacing, as exemplified by parking:*:access:parking=*.

So parking:*:access=* is the exemption to re-use access=* directly.

Aside from the greater effect they will bring, access:residents=* and access:employees=* don't entirely make sense for all the main access=* val. While access:residents=private might have merit in expressing it is the individual resident, access:employees=private has limited purpose. It is sufficient to use access=private + access:for=resident or access:for=employee in most cases to combine legal restriction and user group.

Furthermore, what's needed more is to distinguish the exact user group. Ironically parking:condition:*:residents=* did this. It is more useful to use eg access:for:residents=* and access:for:customers=* for the name of residence and business they cover. This helps with complicated cases where there is a mix or overlapping features. permit=* was proposed in (Proposed_features/access=permit#Permit_contact_information:_the_permit:*_keys). I feel it is better to not cover this here.

-- Kovposch (talk) 10:46, 14 October 2022 (UTC)

Good point that standing should actually be waiting. I didn't know that this distinction also exists outside the USA (it would be ok if it's an US concept only, but it seems it isn't). So I would also prefer a change to waiting.

I haven't thought through the whole access:stopping/access:residents issue very deeply yet. I know your suggestion with parking:*:stopping, but thought it would be consistent to "push" it into the access namespace. But maybe you are right with the "overnamespacing" and parking:<side>:stopping=yes/no and ...access:for=residents/employees/... are the better choice. I will adjust it. --Supaplex030 (talk) 16:09, 16 October 2022 (UTC)

Perhaps it's possible to not cover this, and leave the issue as a general one for access=* or others to solve. It is not highly necessary here, with parking:*:access=private, plus parking:*:zone=* for residents, already implying similar meaning. --- Kovposch (talk) 18:46, 16 October 2022 (UTC)

That's true, we should leave it out here for now, or perhaps move it to a separate proposal. But we have to include parking:*:stopping etc., of course.--Supaplex030 (talk) 07:33, 17 October 2022 (UTC)

Ok I see you have parking:right:hgv=designated. This format is ambiguous as to whether it should instead be a special form of parking for them. Eg can I have parking:right:motorcycle=on_kerb? That's why parking:right:access:hgv=designated is preferable. --- Kovposch (talk) 10:53, 14 October 2022 (UTC)

I think parking:right:hgv=designated is the "correct" choice, as we would, for example, specify the access=* to a separately mapped parking space like this:

Sign	Tagging on a `amenity=parking` (separate area)	Tagging as attribute of the street (`parking:<side>=*`)
	`access=no` `hgv=designated`	`parking:right:access=no` `parking:right:hgv=designated`

On a parking lane, it should be effectively the same, only with the parking:<side> prefix. --Supaplex030 (talk) 16:09, 16 October 2022 (UTC)

Because parking:right:access=* is used to refer to parking, it is more structured to use parking:right:access:hgv=*. This makes it tidy alongside parking:right:waiting:hgv=* and parking:right:stopping:hgv=*.
For comparison, there is no other special meaning in shoulder:right:*=* with shoulder:right:access=*. Then shoulder:right:bicycle=* can be used directly.
--- Kovposch (talk) 18:28, 16 October 2022 (UTC)

I consider parking:right:access:hgv=* variant absolutely unfavourable and inconsistent, because then we start again with the same "disharmonies" between area and line tagging that we already had before. Thats not how we use access tags and namespacing in OSM imho. You are of course right about the parking:right:stopping:hgv=* issue, but with my initial variant parking:right:access:stopping=* this problem would not arise (even if the tag then becomes very long).--Supaplex030 (talk) 07:33, 17 October 2022 (UTC)

Ok now I realized there is no replacement for the unspecified negative parking:condition:right=no. Maybe you do need to use parking:right:parking=no for no parking allowed, and reserve parking:right:access=no for unspecified not-allowed. In this case, parking:right:parking:hgv=designated is required. I don't know what other words exist for "parking". --- Kovposch (talk) 18:30, 16 October 2022 (UTC)

Resolved: Restriction tagging was restructured by proposing restriction. User group and vehicle type restrictions seems to work and in the same logic as in other usages. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

no parking/no standing/no stopping Just introduce stopping:<side>!

I am currently working on the no_stopping/no_parking differentiation and just had a new idea:

First of all: no_standing is almost not in use after all the years the schema is in existence - absolutely ignorable at the moment. Moreover, a suitable definition to distinguish no_standing from no_parking is difficult, because local legislations are very broad and the local differences between both are sometimes hardly understandable.

This leads me to consider whether the simplest solution is to simply introduce stopping:<side> to record whether stopping is possible or not: stopping:right=no means that you are not allowed to stop. parking:right=no + stopping:right=yes means that parking is not allowed, but stopping is possible. stopping would be a replacement for the previous no_stopping/no_standing/no_parking.

This would simplify the tagging of parking restrictions significantly and de facto no meaningful information would be lost. If you really need to differentiate between standing and parking, you can still do this with a similar standing or by using traffic_sign=*, for example. But, in my opinion, this differentiation is not necessary at all for the parking schema in general.

Some examples how this could work and look like:

Sign	Tagging
	`parking:right=no` `stopping:right=yes`
	`parking:right=*` `parking:right:access=yes` `parking:right:access:conditional=no @ (Mo-Fr 16:00-18:00)` `stopping:right:conditional=yes @ (Mo-Fr 16:00-18:00)`
	`parking:right=no` (actually implied by `stopping:right=no`) `stopping:right=no`
	`parking:right=*` `parking:right:access=yes` `parking:right:access:conditional=no @ (Mo-Fr 16:00-18:00)` `stopping:right:conditional=no @ (Mo-Fr 16:00-18:00)`
	`parking:right=*` `parking:right:access=yes` `parking:right:access:conditional=no @ (Tu-Fr 09:00-18:00; Sa-Su 10:00-18:00)` `parking:right:bus:conditional=designated @ (Tu-Fr 09:00-18:00; Sa-Su 10:00-18:00)` `stopping:right:conditional=yes @ (Tu-Fr 09:00-18:00; Sa-Su 10:00-18:00)`
	`parking:right=no` `stopping:right=no`
	`parking:right=no` `stopping:right=yes`
	`parking:right=no` `stopping:right=yes` Feel free to add `parking:right:traffic:sign=*` or propose `standing:right=yes`, if really needed.

--Supaplex030 (talk) 12:20, 25 October 2022 (UTC)

Unfortunately I don't think this would work. To my knowledge no_standing is a legal distinction in America when it comes to traffic rules, unlike where the Vienna Convention is in effect and there's only no stopping/no parking. Also, parking:right=no is to be used for the physical presence of a parking lane (since parking:right=lane is a value. Mixing the physical and legal properties was a problem with the old tagging and one my proposal solved. I would prefer to not introduce it again. Another solution would be to move the lane tagging to another tag and keep parking:right=no for "no parking" --Riiga (talk) 14:54, 25 October 2022 (UTC)

Yes, this distinction exists, but my thought was that it is so fuzzy that we cannot meaningfully "define" it in OSM. For example, in a recent discussion in the German community, we realised that according to the current OSM definition we would have to use "no_standing/no_waiting" instead of "no_parking" in certain situations in Germany to reflect the German legal situation. That would be nonsense, of course, but consistent in terms of the definition. So if we keep this distinction, it must be clear that the terms must be used according to their local meaning. Therefore, I am not yet sure how we should deal with the waiting/standing problem (British English, see above).

Take care to not mixing physical and legal attributes is a good hint. But move the lane tagging to another tag and keep parking:right=no for "no parking" legal restriction is not a good idea in my opinion, because that would somewhat contradict the goals of the proposal (simplicity, conventions).

I posted a new tagging table below, staying with the parking:right:standing syntax. So all the legal information should be part of the "access" and "standing/stopping" namespace. How does this look like? --Supaplex030 (talk) 21:13, 26 October 2022 (UTC)

@Supaplex030: I like the idea that keywords like "parking" and "standing" should reflect local distinctions. Even within the U.S., the specific activities affected by a "No Standing" prohibition vary from state to state. Since most non–Vienna Convention countries are influenced by the MUTCD, an English-language standard, this approach probably won't lead to a proliferation of untranslatable values. Data consumers will have to vary their handling of these tags from region to region anyways, whether they use these tags to render signs or simulate traffic. – Minh Nguyễn ^💬 06:44, 28 October 2022 (UTC)

@Supaplex030: no_standing is so rare because it was coined less than a year ago as part of a cleanup of Key:parking:lane. Until then, the page misrepresented American parking rules. – Minh Nguyễn ^💬 06:05, 28 October 2022 (UTC)

Ah thanks, I hadn't noticed this addition! This explains the small numbers. --Supaplex030 (talk) 07:40, 28 October 2022 (UTC)

Resolved

The UK also has a distinct no loading restriction that I think we lack a tag for.--InsertUser (talk) 22:24, 13 November 2022 (UTC)

See below: Talk section "no loading". --Supaplex030 (talk) 08:24, 14 November 2022 (UTC)

How should we map no parking/no standing[waiting]/no stopping?

Here is a new suggestion that is based on the proposal of @Kovposch: parking:right:access=* specifies the general accessibility of the parking area as usual. If there is no parking, parking:right:stopping=* and parking:right:waiting=* can specify whether one is allowed to stop or wait anyway. parking:right=no means a physical absence of parking/parked vehicles, parking:right:access=* as well as parking:right:stopping=*/parking:right:waiting=* represent legal restrictions.

Sign	Tagging
	`parking:right=no` (as a "physical" attribute) `parking:right:access=no` (to make clear that it is not just a physical absence, but a signposted legal rule) `parking:right:stopping=yes` (to record that stopping is allowed anyway. In countries where a "standing/waiting" distinction does exist, use `parking:right:waiting=yes` instead (see below).)
	`parking:right=no` `parking:right:stopping=no` (implies `parking:right:access=no`, which therefore does not need to be tagged)
	`parking:right=*` `parking:right:access=yes` `parking:right:access:conditional=no @ (Mo-Fr 16:00-18:00)` `parking:right:stopping:conditional=yes @ (Mo-Fr 16:00-18:00)`
	`parking:right=no` `parking:right:access=no` `parking:right:waiting=yes` (In countries where a "standing/waiting" distinction does exist. Implies `parking:right:stopping=yes`)
	`parking:right=no` `parking:right:waiting=no` (implies `parking:right:access=no`, which therefore does not need to be tagged) `parking:right:stopping=yes`
	`parking:right=no` `parking:right:stopping=no`(implies `parking:right:access=no` and `parking:right:waiting=no`)

I don't know if there is a need for a tagging like parking:right:stopping=no + parking:right:stopping:hgv=yes, but it would certainly be possible.

--Supaplex030 (talk) 21:13, 26 October 2022 (UTC)

This seems like a better idea than the previous one, but by making parking:right:access=no mean "no parking" and in addition requiring parking:right:stopping=no to indicate "no stopping", conditional values are unnecessarily duplicated as in the example with no parking (but stopping allowed) on Monday-Friday 16-18. I haven't thought about a better way to solve it yet though. --Riiga (talk) 06:44, 27 October 2022 (UTC)

Yes, that is unfortunately the (perhaps only) disadvantage of the change to the access scheme: the no_parking/no_stopping/... distinction can no longer be mapped as easily as before. The only alternative I have thought so far would be something like parking:right:access=no_stopping, but that would again break with the standard access scheme.--Supaplex030 (talk) 07:34, 28 October 2022 (UTC)

Perhaps not parking:right:stopping:hgv=*, but the U.S. does have standard signs restricting stopping or parking to certain vehicle classes, such as

for tour buses and

for alternative-fuel cars. There's also a

for trucks. – Minh Nguyễn ^💬 06:28, 28 October 2022 (UTC)

Resolved: Reasonable syntax in proposal

parking:side:markings=*

I think this is somewhat overshooting it, as it is only tagging for the visual appearance.

The visual appearance of marked parking spaces are usually simply defined in the legislation... and vary even more widely than you defined so far. E.g. different colors may be used to also mean different things (that certain restrictions apply). So for some regions, it may be quite spammy to even record the appearance, because it is always the same.

--Westnordost (talk) 13:53, 25 October 2022 (UTC)

That's true, and additional properties like colour might be needed, but like all information in OSM, you can tag as little or as much as you want when it comes to details. Mapping markings is not intended to be the most commonly added tag for parking. --Riiga (talk) 14:56, 25 October 2022 (UTC)

I have adjusted the proposal a bit to make clear that the existence of markings (parking:side:markings=yes) is a relevant information that is the focus of this key. But I also think it can't hurt to "think ahead" to more specific values, because otherwise sooner or later there will be uncontrolled growth in this name space. --Supaplex030 (talk) 19:51, 26 October 2022 (UTC)

Resolved: Markings only yes/no, appearence in separate proposal

Back-in angle parking

Standard sign in California

The "Orientation" table has a diagonal value, but for completeness, it should also have a reverse_diagonal value or somesuch to indicate back-in angle parking (reverse eschelon parking). The driver is expected to enter the diagonal parking space in reverse, so the markings are rotated by 90 degrees compared to diagonal. – Minh Nguyễn ^💬 06:13, 28 October 2022 (UTC)

Thanks for the hint. Isn't it better to indicate this case with a subtag like parking:right:orientation:reversed=yes or similar? Because there are further "special situations" (like "parking only forward" or "parking only backward") that could be tagged in a similar way without, in my opinion, having to adjust the "core values".

Furthermore, I think it is better not to express this situation in the "primary" tag, because it probably cannot be identified by any casual mapper without background knowledge and then you can't trust the data. And there are situations like one-way streets where the parking direction is also reversed (at least here in Germany) and then it becomes increasingly difficult to distinguish these forms.

At first glance, I would propose parking:right:orientation:reversed=yes for this and parking:right:orientation:forward_parking=designated/parking:right:orientation:backward_parking=designated (with a "_parking" suffix to not confuse it with forward/backward) for places where there is a sign or a rule that says you should only park forward or only park backward. --Supaplex030 (talk) 07:25, 28 October 2022 (UTC)

@Supaplex030: Back-in angle parking is easily visible from aerial imagery, even when all the spaces are vacant: the markings are rotated by 90 degrees relative to what they would be for ordinary angle parking. A one-way street would have other clues visible in aerial imagery, such as one-way arrows, because on the ground it's also necessary to keep drivers from mistaking the road direction based on the angle of the parking spaces.

Can you elaborate on what it means for the parking direction to be reversed on a one-way street? I'm not strongly opposed to a separate key, but parking:right:orientation=parallel parking:right:orientation:reversed=yes sounds like "back-in parallel parking", which seems impractical to me (requiring making a U-turn and facing oncoming traffic in order to park along the street).

– Minh Nguyễn ^💬 08:35, 29 October 2022 (UTC)

Yes, if you have some knowledge about parking, you may identify that, but I'm assuming a casual mapper (e.g. mapping with StreetComplete - and a European one - most Europeans in cities don't have a car/driving licence and don't know anything about parking ;).

So an additional tag has the advantage that it would be more likely to be used by mappers who are sure of what they are doing and who really want to record this specific situation. The orientation key remains simple and contains only information that can be clearly identified by everyone and by any mapping method (remote or on the ground). And other parking concepts like signposted backward/forward parking can be mapped in a similar way.

Regarding one-way streets, I mean that parking there is in the same (driving) direction on both sides (vehicles on the left are facing in the same direction as vehicles on the right). However, you are right, that is something different and does not need to be explicitly tagged (because it's implied by the oneway attribute). parking:right:orientation=parallel + parking:right:orientation:reversed=yes certainly does not exist or would probably be a mapping mistake. The reversed attribute would therefore only/mainly occur in combination with diagonal parking, I think. --Supaplex030 (talk) 09:20, 29 October 2022 (UTC)

One-way road markings

@Supaplex030: Yes, I was assuming a certain level of familiarity with how roads are typically laid out in a given region, or alternatively the kind of visual aids that StreetComplete is good at providing. Personally, I identified back-in angle parking in aerial imagery long before I ever saw it in person, but by then I was already used to navigation mapping. (Back-in angle parking is common in some parts of the U.S., but rare where I live.) I'll defer to your judgment about adding a separate reversed subkey, but it'll require some effort to raise awareness of this subkey among developers.

By the way, I was referring earlier to the one-way or wrong-way arrows painted on the pavement. They're by no means universal, but I think they're more likely to be present when there's any potential for confusion.

– Minh Nguyễn ^💬 06:35, 30 October 2022 (UTC)

Resolved: parking:side:direction now uses only two easily distinguishable values. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

Redundancy

Why is both *=reverse and *=back_in needed? Can't park in wrong direction.--- Kovposch (talk) 03:02, 2 November 2022 (UTC)

Head-in diagonal

@Kovposch: It does sound redundant. It seems like an attempt to distinguish the reasons for mandating a particular direction: collision avoidance versus air quality. But wouldn't marking diagonal back-in parking inherently accomplish both goals at the same time? By the way, in practice, if a parking space is marked diagonally as in the illustration for default, I think that would all but require going head-in – backing in would be possible but require at least a six-point turn if the adjacent spaces are occupied. – Minh Nguyễn ^💬 16:42, 2 November 2022 (UTC)

@Kovposch: You are right: The way back_in and head_in are defined right now, they are only meant for perpendicular parking. Because - as @Minh Nguyen: pointed out - for diagonal parking, reverse already implies back_in and the default actually implies head_in.

So we could simplify the tagging and only use back_in and head_in. back_in in combination with diagonal oriented parking would (literally!) indicate back-in diagonal parking, whereas in combination with perpendicular orientation it would indicate a signposted rule like "You have to park back in here" (for whatever reason such signs are posted - but they exist).

So I will reduce the list to the two values back_in and head_in (head_in should actually only appear in combination with perpendicular parking, because for ordinary diagonal parking you don't have to tag it explicitly and I never saw those rules for parallel parking).

Or do you think we should outsource this topic from the proposal in general? We (the authors of the proposal) have already considered this. But I'm not sure because this might not be a controversial issue... --Supaplex030 (talk) 20:06, 2 November 2022 (UTC)

Sounds reasonable to me. I've occasionally seen signs requiring or prohibited backing into a perpendicular space, just nothing standard that I was able to point to. I agree that parallel parking is pretty straightforward in this regard. At least where I'm from, it's illegal to park parallel on the wrong side of a two-way street, for safety reasons. I've seen people do it, but a requirement for wrong-side parallel parking just sounds chaotic. – Minh Nguyễn ^💬 21:03, 2 November 2022 (UTC)

Resolved

Example parking lot

All Cars Head In Parking Only

For future documentation purposes, here's a sign in English for head-in parking only. In this case, it applies to both perpendicular and diagonal spaces. This photo happens to have a bunch of interesting restrictions to tag. – Minh Nguyễn ^💬 05:14, 11 November 2022 (UTC)

Great! What a restriction party... Took me a while, but for me it looks like:

amenity=parking (It seems to be a car park with an access driveway (apparently this one in OSM), not classic street parking. But you could use the same following tags on a parking lane by adding parking:side as a prefix.)
parking=surface (Parking with access driveway - see above.)
orientation=perpendicular and orientation=diagonal (On separate amenity=parking_space areas, if one wants to micromap them - some of them where sill mapped in OSM, I added some missing ones. One could use orientation=separate or orientation=mixed on the entire parking area?)
direction=head_in ("All cars head in parking only")
access=yes (Public parking.)
access:conditional=no @ (We[-1] 02:00-07:00); permit @ (Mo-Fr,Su 19:00-07:00) ("No Parking 2am - 7am For Field Cleaning Last Wednesday Each Month" and "Overnight Parking License Required 7pm - 7am Su - Fr" - for permit the Overnight Parking License should be "routinely granted to everyone requesting it".)
access:reason:conditional=street_cleaning @ (We[-1] 02:00-07:00) ("No Parking 2am - 7am For Field Cleaning Last Wednesday Each Month"
goods=no + hgv=no ("Commercial vehicles not allowed" - ?)
fee=no (There seem to be no fee.)
maxstay:conditional=4 hours @ (Mo-Fr 08:00-02:00); no @ commuter ("4hr Parking 8am - 2am Mo - Fr Without Commuter License" - how to handle commuter? Can't find any "commuter" values in TagInfo...)
dog=leashed ;)

This appears to be a perfect example for the advanced examples collection to show an example on a separately mapped parking area. Any objections? --Supaplex030 (talk) 11:31, 11 November 2022 (UTC)

@Supaplex030: Sure, it could be an instructive example. I agree with most of your suggested tags and appreciate your mapping of the individual spaces. At first, I was unsure what "field cleaning" meant, but apparently the local dialect calls a surface parking lot a "parking field". This parking lot serves the LIRR commuter railroad station. The village requires a commuter permit to park at the lot. Apparently only village residents are eligible for this specific permit. [1] The railroad simply marks this lot as being residents-only. [2] I think parking:zone=* would be accurate in this case. The village says five spaces are available to non-residents, but I don't see any signs about that. [3]

U.S. mappers have generally tagged "commercial vehicles" as goods=* hgv=* (along with tourist_bus=* coach=*) in some cases. There isn't a very good fit to OSM's European vehicle restriction tags; I've long wanted to . I've seen some mappers using commercial=*, which is elegant in a way, but it's a homonymous key. Anyways, we can solve that problem separately; it's a fine suggestion for now.

– Minh Nguyễn ^💬 18:24, 13 November 2022 (UTC)

@Minh Nguyen: The picture is already 5 years old - maybe some regulations have changed since then, which could explain some differences between signposting and information on the website? But anyway: If it is clear in the local context that this permit is only granted to residents, then "private" should be used instead of "permit". (By the way: I think I will propose a tagging in the near future to specify "private" with a secondary tag like access:residents=yes, e.g. also for employees or commuters in this case...)

But according to the signs on the photo, all other tags are ok for now? I already added the example in the proposal yesterday. --Supaplex030 (talk) 20:04, 13 November 2022 (UTC)

@Supaplex030: Bing Streetside has imagery of these signs from about a year ago and actually went through the parking lot. It doesn't look like the signs changed. It's a good reminder that signs don't always tell the full story when it comes to parking restrictions, but we do the best we can. [4] Refining "private" is a good idea. I recently created a page for private=*, which has been in use for some time. But I think it would be reasonable to treat it as a residential permit zone in this case, since it's a specific permit you have to apply for. The other tags look fine to me. – Minh Nguyễn ^💬 08:32, 14 November 2022 (UTC)

@Minh Nguyen: The (residential) zone=* tagging on parking lanes usually carries letters or codes – but what's the zone=* value in this case in your opition? yes? commuter?

P.S. Thanks for creating the private=* page - I have been undecided for some time about which variant to use and will likely support this one now. --Supaplex030 (talk) 09:05, 14 November 2022 (UTC)

@Supaplex030: I've been supposing that zone=* would contain freeform, human-readable text, and the examples just happened to be concise by coincidence. If that's true, then commuter or even Lynbrook Commuter would be reasonable. Most parking zones in the U.S. are lettered or numbered, so this would usually be a moot point here. But anyways, since this is just an example, it would be better to keep the recommendations simple and straightforward based on what the reader can infer from the photo. The extra context is mostly interesting for mapping the actual parking lot. – Minh Nguyễn ^💬 21:37, 14 November 2022 (UTC)

Agree - a local mapper could map it like this, but it can't be seen on the signs, so it shouldn't be part of the example. --Supaplex030 (talk) 08:24, 15 November 2022 (UTC)

Resolved: Added example with aligned tagging. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

More parking space markings

In the U.S., the national MUTCD offers three standard options for marking parallel parking spaces: what you're calling lines:single, a plus pattern, and an I-bar pattern. [5] In practice, what you're calling lines, hooks, and lines:hooked are also very common. – Minh Nguyễn ^💬 09:00, 29 October 2022 (UTC)

In some cities, the parking lane is demarcated by nothing more than a standard dashed lane divider (not solid or dotted like your examples, and only one on side, not three). [6][7] Does this count as marked or unmarked? – Minh Nguyễn ^💬 09:00, 29 October 2022 (UTC)

Interesting - what is the gap for in the example on the right? Is that something like an access_aisle?

In my opinion, we could already use lines:single for the left and hooks for the middle exampe. But there is no fitting value for the example on the right (something like a "hooked lane"). The naming of some of the values might not be perfect yet... And of cause there is such a variety of markings in the world that new ones could be added over time if they have something "unique".

I know the case with ordinary road markings/standard dashed lane divider too. I would see it as unmarked (at least in the examples I know and the ones you have shown), because these markings are not meant to mark the parking space, but to mark a lane that is there at the times when parking is not allowed.--Supaplex030 (talk) 09:40, 29 October 2022 (UTC)

@Supaplex030: The 8-foot-wide (2.4 m) gap could be to facilitate pedestrian access to the sidewalk and provide refuge from passing traffic. However, this is not the same as access aisles for disabled spaces, which usually have a hatching pattern (but can sometimes look like lines:single). Another reason for a gap would be that it's illegal to park near a fire hydrant. The prohibited distance varies widely, from 5 feet (1.5 m) in Salt Lake City [8] to 10 feet (3.0 m) in Ohio [9] to 15 feet (4.6 m) in states that follow the Uniform Vehicle Code. [10] California has its own MUTCD that specifies a gap 4 feet (1.2 m) wide instead of 8 feet wide. It also officially allows the hooks pattern. [11] – Minh Nguyễn ^💬 08:02, 30 October 2022 (UTC)

In terms of naming, the MUTCD describes the three patterns as "vertical rectangles", "cross markings", and "vertical line", but these terms don't leave a lot of room for expansion. The crossing:markings=* scheme uses lines for longitudinal lines (perpendicular to the roadway), skewed for diagonal, and zebra for lateral (parallel to the roadway). bars would've been more straightforward for the last tag, but zebra was a concession to those familiar with the term "zebra crossing". I wonder if we should instead strive instead for consistency with parking:orientation=* with values like lines:perpendicular and lines:parallel. – Minh Nguyễn ^💬 08:02, 30 October 2022 (UTC)

We will outsource this topic, as it is too complex, and only propose the values yes, no, single (for individual marked spaces - better term?) and lane (for not individual marked spaces - better term?), as these are the basic "types"/clear classes of markings. Let's think about the exact specification of the style elsewhere (we will create a new page for this). --Supaplex030 (talk) 09:21, 30 October 2022 (UTC)

Yes, I think that's a sensible approach. – Minh Nguyễn ^💬 20:24, 30 October 2022 (UTC)

Resolved: Handled in separate proposal

Disc parking

How do we intend to indicate that you require a disc when parking? It was obvious before, but now it seems be tagged the same was as regular time-limited parking. --Riiga (talk) 12:23, 2 November 2022 (UTC)

I thought that it can be treated as a national default for regulating time-based parking, Still, I suggested authentication:disc=*. Problem is this needs to get authentication:*=* approved, meaning more work. --- Kovposch (talk) 16:11, 2 November 2022 (UTC)

@Riiga: Is there a difference between disc parking and "time limited parking" in e.g. Sweden? How would a driver without a disc prove that he/she has not exceeded the parking limit? (Are there digital possibilities for this?)

I'm from Germany and here there is no other way than to use a disc when a time limit applies. I haven't thought about whether this is the case everywhere - but you're right: of course it can be regulated differently elsewhere (Germany is a stone-age country in many aspects :)

But @Kovposch: is also right: isn't this regulated uniformly at national level? That's why I don't think a authentication tag is necessary...--Supaplex030 (talk) 20:17, 2 November 2022 (UTC)

Just a time limit is enforced by parking officers, no need for a disc. This is the default. When a disc is required, signs will indicate that. In my city disc parking is very uncommon or non-existent, but in a smaller neighbouring town they use disc parking almost everywhere. --Riiga (talk) 09:31, 3 November 2022 (UTC)

Ok, interesting. Sounds like the authentication idea is useful, but I think that would be a separate follow-up issue again. Or what do you think? We could at least mention it as an idea.--Supaplex030 (talk) 09:40, 3 November 2022 (UTC)

I wouldn't want to retag any disc parking until there is some way to map it as changing to the new schema (without disc support) would remove that information and make it hard to add afterwards.--Riiga (talk) 10:17, 3 November 2022 (UTC)

You could just use ~~parking:side:authentication=disc~~ parking:side:authentication:disc=yes, even if it is not approved yet. I think the chances that you will have to re-tag this again one day are rather unlikely - and even if that may happen, at least the information has been preserved. We could mention this tagging (and maybe drafting a side proposal for this) to make a suggestion for other mappers too. --Supaplex030 (talk) 10:42, 3 November 2022 (UTC)

We don't have disc parking at all in the U.S., but it reminds me of pay and display, which is very common for both street parking and parking lots. It varies from lot to lot, so I'm always having to double- and triple-check whether I'm supposed to keep the ticket with me or leave it on the dash. – Minh Nguyễn ^💬 21:07, 2 November 2022 (UTC)

Related is differentiating between parking meters (as is common in the US) and parking validation tickets (as is more common in Europe and in private lots as Mihn mentioned). In either case, this proposal is an improvement over the old scheme as it doesn't force American mappers to mistag metered parking with parking:condition=ticket to indicate it is payed parking or use some undocumented value such as parking:condition=meter

Resolved: Mentioned parking:side:authentication:disc=yes in the proposal, but since this interfers with another proposal, it's not an "official" part of this parking proposal. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

"either-side"

"Either" is ambiguous in parking:either_side_only=*, requiring "only" to emphasize the implied meaning. USA has some "no parking" on "either side" text signs. In one perspective, car can't be parked at both sides simultaneously. It can only choose one from the two sides.
I suggest parking:staggered=*. The term "staggered parking" seems less uncommon and unclear than "either side" parking.
Some uses:

"Staggered parking only" sign (apparently in Melbourne, non-standard in Australia?):

That being said, more commonly (including technical and planning) "staggered parking" is used for pre-arranged blocks of parking spots, as this is more formal. (eg https://nacto.org/publication/urban-street-design-guide/streets/residential-shared-street/ )
The problem with parking:either_side_only=* is I can't find any uses matching "either side" and "either side only" parking.
--- Kovposch (talk) 03:19, 3 November 2022 (UTC)

I like that. Thank you for the references to the use of the term. I honestly just used "either side only" because it has been (rarely) used before, but the term sounds rather odd and clumsy to me as well.

I would like to propose to use parking:both:staggered=yes in those situations + position and orientation values as usual. Of cause, "both" is implied, but it fits much better into the general syntax of the schema (parking:side:...) and could theoretically be used without this prefix on separately mapped parking spaces without breaking the general logic (although I personally don't think it makes sense to use it there). --Supaplex030 (talk) 08:20, 3 November 2022 (UTC)

The left arrow is pointing to the stop sign at the corner on the right side of the street.

@Kovposch: Regarding the U.S., I wonder if you're referring to signs like

that have a double-sided arrow. This means the restriction applies before and after the sign on the same side of the street as the sign. The sign is supposed to be angled diagonally to face away from the curb and toward the street, at least enough to avoid pointing to the opposite side of the street. A standard parking sign will never refer to a restriction on the opposite side of the street. – Minh Nguyễn ^💬 23:40, 3 November 2022 (UTC)

Oh, I should've actually searched for this text to see what you meant. Signs like these are nonstandard, but I suppose we should find a way to accommodate them. I don't think this is the sign that would be used for staggered parking though; it would definitely be interpreted as prohibiting parking on the side of the street, period. – Minh Nguyễn ^💬 23:44, 3 November 2022 (UTC)

Resolved

"reason" missing?

Are we still able to use parking:condition:side:reason or rather parking:side:condition:reason or a variant thereof to explain why parking is forbidden? In your example of

parking:left=no
parking:right=street_side
parking:right:orientation=perpendicular

it is totally unclear to me, why parking on the left would be forbidden. I found it very helpful to get things like parking:left:condition:reason=narrow or parking:left:condition:reason=fire_lane, because not everyone is always aware of the legal implications of these. Are there any plans to adopt this schema as well? --Nadjita (talk) 14:30, 7 November 2022 (UTC)

Yes, it is possible. See the Reasons_for_parking_restrictions chapter. The list of reasons will remain the same as currently approved. --Riiga (talk) 14:43, 7 November 2022 (UTC)

But the narrow road example is a good one, which we have also just discussed locally: We should give another specific tagging example for this case, because it is not quite clear yet how reason would be used in this case.

Basically, reason can be used as a suffix on different keys now in order to be able to specify a particular reason for exactly this rule (parking:side:access:reason or parking:side:maxstay:reason, but also parking:side:stopping:reason etc.).

In the case of a narrow road without an explicit prohibition, i.e. a physical reason, however, the suffix should also be used with the physical keys. So in the picture shown, concretely: parking:left=no + parking:left:reason=narrow. Is that a good idea? In this case, there is no access tag but the reason tag would still make it clear why there is no parking. --Supaplex030 (talk) 20:10, 7 November 2022 (UTC)

Resolved: There is now an explanation and a corresponding example. --Supaplex030 (talk) 22:22, 22 November 2022 (UTC)

Maxstay exception for residents?

What would be the best conditional restriction for a traffic sign like this?

(2 hour disc parking, residents "O" exempt)

parking:maxstay:conditional=no @ residents? --Popball (talk) 07:15, 13 November 2022 (UTC)

In my opinion: Yes, exactly like that (Attention: You have no side infix in your example, like parking:right:maxstay:conditional=no @ residents on your photo).

A similar exception for residents often exists with ticket parking - but I'm not sure if it makes sense to use fee:conditional=no @ residents in this context, as residents usually still have to pay for their parking permit. However, they do not have to pay a fee "on the ground".

Are there any opinions on this? Should we use fee:conditional=no @ residents if residents are exempted from paying a parking ticket, but only because they have a resident's permit for which they have to pay a fee maybe once a year? --Supaplex030 (talk) 08:54, 13 November 2022 (UTC)

I think that it makes sense to use fee:conditional=no @ residents if residents are exempted from paying a parking ticket (theoretically a city could issue the parking permits to residents for free anyway). Another condition may be fee:conditional=no @ disabled if a disabled parking permit entitles one to free parking. In any case, fee=* means free at the time of service. --Popball (talk) 18:05, 14 November 2022 (UTC)

I think that a parking zone tagging implies fee:conditional=no @ residents almost everywhere, doesn't it? Therefore, I would avoid repetitive conditional tagging, but I can understand that it would be acceptable. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

Resolved: There is an example for parking:*:maxstay:conditional=no @ residents and a passage that clarifies the fee:conditional issue. --Supaplex030 (talk) 22:22, 22 November 2022 (UTC)

No loading

In the UK there is a distinction between no waiting, no loading and no stopping with road markings.

Red routes are the most restricted with double red lines forbidding stopping and thus by extension loading and waiting at any time. Single red lines are the same except only within particular time limits.

Then we have double and single yellow lines. These are no waiting with double yellow and single yellow lines having the same time implications as double and single red lines.

However double and single yellow lines along the road do **not** restrict loading in the UK. There are completely separate road markings to specify that no loading is allowed. They are little known in the UK amongst drivers but they are very much in use: the main shopping street in the town where I live has them along most of its most busy part for example.

Those markings restricting loading are single and double yellow marks across the kerb perpendicular to the centreline of the road. As with red and yellow lines double marks indicate no loading at any time and single marks indicate no loading within a particular time restriction.

So to tag things properly in the UK we need to be able to mark that waiting is restricted by yellow lines only and that both waiting and loading are restricted by both yellow lines and yellow dashes.

The UK also has spaces specifically marked and signed as loading bays only. So we definitely need the ability to distinguish loading from stopping and from waiting in tagging.

There are further things that may be worth having tagging examples of as well. There are bus clearways at some bus stops, in other words clearways for everything but local buses using the stop. There are yellow zig-zag lines outside schools which sometimes have advisory effect and can actually have legal force as well if signed. These relate to not stopping to keep school entrances clear. Similar markings can occur outside fire stations and police stations for the same reason. Then there are the white zig zags around zebra, pelican, puffin, pegasus, parallel and toucan crossings. These forbid waiting, loading, stopping and even overtaking the last vehicle before the point where the crossing is.

Trouble is that there are instances where such crossing zig-zag lines are along the edge of the main carriageway and there is parking signed along the edge of the road. So there are road markings forbidding waiting, loading and stopping along the same section of road as signed and marked parking bays .... Some highways authority people don't seem to have two brain cells to rub together.

Davidpnewton (talk) 11:51, 13 November 2022 (UTC)

Those road authorities can make life (and thus OSM tagging) really difficult ;)

But we still have maxstay=load-unload as an documented concept for loading zones (that are a common phenomenon, I think, see example in this section). From the point of view of the applicable regulations, there doesn't seem to be any difference between a loading bay and the kerb markings you describe, does there? Both tell you that you are not allowed to park and that stopping/waiting is only allowed for the purpose of loading. parking:right:access=yes + parking:right:maxstay=load-unload may look strange at first glance, but exactly expresses this when interpreted correctly.

And since there is an extremely wide range of very specific rules worldwide, you probably have to use additional tags like parking:right:traffic_sign=* if you want to map the exact local situation in each case. (Do the red and yellow markings have traffic sign codes in the UK? In Germany, these codes also exist for ground markings).

Regarding the no stopping/ground/zig-zag-markings: If these markings are only valid on a short road section, it is unnecessary to map their implication to the parking lanes if one would have to split the road centerline for this. For applications and evaluations, it is sufficient to map such markings separately (e.g. area:highway=prohibited - however, we need more documentation and a consensus in the community about the exact tagging). In Berlin, we are working on an evaluation tool for parking lane data, where we include many such external features (such as bus stops, driveways, ground markings...) and it works well.

However, if there is a bus clearway/a bus lane, parking:right=no + parking:right:stopping=no + parking:right:stopping:reason=clearway/bus_lane or similar can be used. The former reason concept does not list anything about this, but there are some uses in the OSM database. You are right: We should add an example for a case like this (and maybe the reason tagging needs more documentation, but thats out of scope of this proposal, because this concept already exists). --Supaplex030 (talk) 13:03, 13 November 2022 (UTC)

Yes there are traffic sign identifier codes for road markings in exactly the same way as there are for upright traffic signs. 1023B is the isosceles triangle that's part of the road markings for a give way for example.

I've used them in OSM by extending the traffic sign tagging syntax. So instead of traffic_sign=GB:501 for an upright sign it would be road_marking=GB:1023B on a node at the appropriate point in the highway way. Davidpnewton (talk) 14:19, 13 November 2022 (UTC)

Should there be a dedicated subkey for regional road markings distinct from parking:traffic_sign=* and parking:markings=*? Not every jurisdiction assigns codes to road markings. (Most MUTCD-influenced jurisdictions don't.) There's also road_marking=*, though that tagging scheme hasn't received a lot of scrutiny so far. – Minh Nguyễn ^💬 18:29, 13 November 2022 (UTC)

I'm not sure if this should be part of the parking namespace, because these markings aren't exclusively related to parking in every case. But the topic of road markings definitely needs more scrutiny, documentation and possibly proposals. Therefore, we shouldn't deal with this in this proposal without keeping the "big picture" in mind. However, using something like parking:right:road_marking=* on a individual basis sounds good to me. --Supaplex030 (talk) 20:21, 13 November 2022 (UTC)

Resolved: Road markings tagging out of scope of this proposal. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

Seprarate/distinct tag for loading?

Should there be a separate key for loading? Perhaps parking:right:loading=yes/no/designated or loading:right=yes/no/designated? Might be out of scope however--Popball (talk) 18:33, 14 November 2022 (UTC)

I thought long about this today, based on the previous discussions, whether it makes sense. I am still not sure, but I think we can map this situation sufficiently well in OSM with tagging that is already in use (using maxstay=load-unload).

The problem is, in my opinion: no parking, no stopping and no waiting are clear graduations of differently "strict" regulations of "no parking". For pragmatic reasons, we have now introduced separate access-like keys for each of them in order to be able to clearly and easy distinguish them from each other. Loading zones are a bit out of line because they are defined differently, e.g. they are defined "positively" (you are allowed to load - in contrast to e.g. no stopping: you are not allowed to stop), which makes it difficult to integrate them into the no parking levels in an intuitive way.

The current variant (access=yes +) maxstay=load-unload may not be ideal from a semantic point of view, but can be clearly evaluated and I find it even a bit more logical than access=no + loading=yes or similar. Their only disadvantage is that there are sometimes time limits on the maximum loading time, which are difficult to map (but maybe not impossible if using conditional restrictions...).

Or what do you and other readers think? --Supaplex030 (talk) 20:10, 14 November 2022 (UTC)

@Supaplex030:

CA MUTCD R25A

Loading zone restrictions in California always come with time limits. Otherwise it would be too easy to claim one is loading very slowly. Outside of business hours, there often are no restrictions whatsoever, but this fine print is relatively unknown among drivers, lucky for those that know about it. In other states, the time limit may not be posted on the signs, but the act of "loading" may be legally time-bound. For example, in Ohio, loading is limited to 3 minutes statewide. [12] I don't have a strong opinion on which key should indicate a loading zone as long as "load" appears somewhere in the tags, even if only parking:maxstay:reason=*, because some jurisdictions consider it to be a distinct kind of parking regulation. – Minh Nguyễn ^💬 22:10, 14 November 2022 (UTC)

access=loading?

What about proposing loading as a new access=* value, used mainly for parking? parking:right:access=loading is a very easy way to tag loading zones and fits well in the access schema since it cleary describes an access restriction on a parking facility. maxstay=* becomes available again for the specification of maximum loading times. --Supaplex030 (talk) 08:35, 15 November 2022 (UTC)

The issue with *:*:access=loading is that it suggests that you aren't allowed access otherwise. The same applies for using the similar delivery tag. --InsertUser (talk) 08:57, 15 November 2022 (UTC)

Which is actually quite correct for explicitly-signed loading bays. You are not allowed to use them unless you're loading or unloading, at least in the UK. Davidpnewton (talk) 14:01, 20 November 2022 (UTC)

But isn't that correct in this case? In a loading zone or during loading times, I am only allowed to stop for loading. Otherwise, I have no legal access. --Supaplex030 (talk) 09:17, 15 November 2022 (UTC)

Looking at it from a Swedish perspective, the are no designated loading zones in that sense, but only a generic "ändamålsplats" = "place designated for a specific purpose". The way these are signed is shown in the "Reasons for parking restrictions" section. The base restriction is no stopping, with the specific purpose that overrides this written on the sign. The way I've mapped these currently are no_stopping + reason=*, where loading_zone is just one of a number of possible reasons. --Riiga (talk) 09:14, 15 November 2022 (UTC)

loading_only

Today I reworked the proposal and added a new parking:right:restriction=* key as a result of this long external discussion. It allows to distinguish no parking/no stopping etc. in an easy way, but also other "action-based" restrictions like loading. Your "Lastplats" (see traffic sign on the right) is well covered with parking:right:restriction=loading_only, isn't it? Because this implies reason=loading_zone in my opinion (or even makes this value obsolete), I deleted this from the examples. Moreover loading_only implies, that parking is not allowed, but stopping only for the purpose of loading/unloading. --Supaplex030 (talk) 20:06, 19 November 2022 (UTC)

Resolved: We have restriction now. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

JOSM Plug-in

Great work here. I’d support the proposal. I’d really support it if you could rework the JOSM Plug-in to match! I did the parking in my city some years ago and found the plug-in essential. Any plans on implementing? ID/JOSM presets? ElliottPlack (talk) 01:44, 14 November 2022 (UTC)

I did update the plug-in the last time the tagging changed, but unfortunately never completed the validation of tags part. With this change I'm sure we'll update the plug-in again. --Riiga (talk) 07:12, 14 November 2022 (UTC)

I just started to update the style today - new tagging and some more attributes are supported now and deprecated tagging is clearly visible. Feel free to contribute - it's still work in progress.

Stress test

Are you interested in more complex examples of parking restriction signs for this proposal, as a stress test, or are you satisfied that the current examples illustrate the intended tagging well enough? If only I could convince an Angeleno to get a better shot of these infamous parking restriction totems outside the schools in Culver City, California, but alas, that would require parking there first. [13][14][15] One interesting aspect of these signs is that they limit you to parking in one space per zone per day. [16] – Minh Nguyễn ^💬 21:51, 14 November 2022 (UTC)

I have seen great pictures of such signs and thought I had one under a free licence. But unfortunately I can't find it anywhere. Even in Wikimedia Commons I can't find any particularly "extreme" cases. I don't think we need to make a big effort to photograph one, but if one appears somewhere under a free licence, it can't hurt to include it in the list of examples. But since these are examples to help understand the tagging, it should also not be overly extreme, i.e. readable and consistent ;) --Supaplex030 (talk) 08:44, 15 November 2022 (UTC)

Resolved: Had a look on some of this totems to check whether the restriction tagging is working. Didn't faced new issues, but of course there are still open questions of detail (as was the case before - not uncommon in a field of this complexity and variety), e.g. a distinction between passenger and goods loading zones or how to tag "once per day per district" or just "tow away". But considering the current size of the proposal, these should be discussed and documented individually later. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

When to use marking

I think the proposal should more clearly define when marking should be used. Is this only for painted areas or is a different surface a marking? What about paint on curb, is that a marking? Discostu36 (talk) 07:04, 15 November 2022 (UTC)

It is for any kind of marking or different surface that shows where you should park or that certain rules apply. This will be clearer in the marking proposal itself, but I'll clarify that in this proposal too. --Riiga (talk) 07:42, 15 November 2022 (UTC)

Resolved: Section/usage clearified. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

street_side vs lane

I think the definition about lane and street_side is a bit unclear. On the one hand you say that street_side means parking bays. On the other hand you define parking lanes as being easily convertible into traffic lanes. But what about parallel parking that uses a different surface but no parking bays? You could only convert it into a traffic lane by paving it (not easy = street_side) but it is not a bay (=lane). Discostu36 (talk) 07:14, 15 November 2022 (UTC)

The difference is that a lane, regardless of any markings, can easily be driven on if there are no cars. The type of markings (including a different surface) will be handled in a separate marking proposal which we felt was not really in scope for this proposal, so we opted to just include the basic yes/no for markings at this time. --Riiga (talk) 07:49, 15 November 2022 (UTC)

I just started to address this distinction in a new section for the street_side/lane wiki pages but I haven't yet integrated them into the article and put them up for discussion there.

Maybe this helps: Distinction between street side and lane parking --Supaplex030 (talk) 08:53, 15 November 2022 (UTC)

Well, your draft manages to be detailed but to still have no definite answer for edge cases. I'd prefer a more clear-cut definition, even if it was extreme. Something like "Use lane only if the parking area has the same surface as the traffic lanes and there are no obstacles that would need to be removed to convert it into a traffic lane". Discostu36 (talk) 09:25, 15 November 2022 (UTC)

I fear that such a "clear" definition for edge cases is hardly possible or can at most be made at the local level, taking into account the typical structural phenomena there. A different surface, for example, is a very weak criterion: in many places it is common to have sett surface on the sides of an asphalt carriageway (where vehicles are usually parked) but this surface is still part of the carriageway (and parking therefore on the lane). Even "obstacles" on the lane are nothing extraordinary (like for traffic calming purposes).

A rough definition is already given in the article linked above: In general, a street-side parking area is a structural extension at the edge of the carriageway, whereas lane parking is on the carriageway itself. I think better than any "literal" definition would be a collection of photos of such edge cases and a common categorisation, which we make available as an image gallery on the wiki and which helps each mapper to classify them. (Can we further discuss/collect this on the sub-page linked above, as that is not the subject of this proposal?)

However, in case of doubt, it's less important which criterion you choose - more important is that the width specifications of the lane fit the categorisation: The carriageway width (tagged as width=* on the highway line) includes lane parking areas, but never includes street-side parking areas. --Supaplex030 (talk) 09:52, 15 November 2022 (UTC)

Resolved: No direct connection to this proposal - but we should discuss this further elsewhere. --Supaplex030 (talk) 23:56, 19 November 2022 (UTC)

General comments

I am baffled how complete and well researched this PR is. Wow, thank you to all contributors for this! This may be the best proposal I have read, ever. And in the end, even though it is very big, it is not really complex to tag (complex situations). You thought of staggered parking, all those properties of parking that were before thrown into one key only have now their own keys, you thought of the parking / standing / stopping, loading zones, parking zones etc.

Now, the sheer size of the PR is going to draw some comments. I read through it all and here are mine:

parking:side:stopping and parking:side:waiting are proposed to distinguish parking, stopping and waiting (standing) restrictions.

Why did you choose this over parking:side:no=waiting or something like that (as it was before)? After all, there can not really be a no parking and no stopping sign at the same place, or can there? Well, maybe there can, for time-limited restrictions (e.g. no stopping during workweek, no parking during weekend) but even that should be projectable if it is just one key? Anyway, if you have a good reason, it should go into that document, not into the reply to this comment.

parking:side:surface for the surface=* of the parking space,

For some situations, this does not make sense. E.g. if it is half-on-kerb parking. So, either it should be noted that this does not make sense in that case or it should be made clear that the surface applies to the not-on-street section only if ambiguous (or something?)

parking:side:capacity for the capacity=* of the parking space (note that capacity should not be mapped in general, as it is prone to errors if another mapper changes the road geometry, e.g. splits it, without adjusting this value. Furthermore, the capacity can usually be derived precisely from the length of the road segment and the orientation of the vehicles).

If it is problematic (for the noted reason), the capacity can always be derived with reasonable precision from length/size, why have it in the proposal at all then? (Or, why not have it only as "deprecated" value?) If it makes sense in edge cases, maybe you should supply one.

An additional tag like parking:right:access:residents=yes could be used to specify, that access=private means access for residents only in this case, but this is out of scope of this proposal.

It's a bit weird to read a proposal for a tagging in a proposal with the attached note that it is out of scope of the same proposal. Then why mention it at all?

Finally, further down, you compare how things were mapped before and how they are mapped now. It would be nice to have a few examples which could simply not be mapped with the old scheme. So that it shows that the old scheme is also simply not sufficient.

If this discussion page becomes too big, consider marking resolved topics as resolved (and move them to the talk archive)

--Westnordost (talk) 12:54, 15 November 2022 (UTC)

Hey, thanks a lot for your detailed feedback! You have addressed some issues that we are also dealing with... Therefore a short reaction to your points:

parking:side:stopping and parking:side:waiting: Indeed, this is a pragmatic, not an elegant solution that's probably not final yet. At this point, the old proposal had an advantage. I just started a separate discussion on this in the Community Forum in order to get more opinions on this. In particular on the idea of simply introducing no_parking, no_waiting, no_stopping and loading as special access=* values for parking spaces.
parking:side:surface and half-on-kerb parking: Unfortunately, we have the same problem here as with ways/path/roads with more than one surface. We do not yet have a good solution for this in OSM in general. parking:side:surface:lane + parking:side:surface:kerb could be a workaround for the case described. I was already confronted with such cases and could - since I wanted to know exactly - only help myself with the area:highway=* schema.
parking:side:capacity: I have reworked this section. It now explains why these tags should only be used with caution. It also explains when it can still be helpful to use them. It's a tag that is used often and that also seems intuitive to use. Therefore, I think it is important to mention it.
parking:right:access:residents=yes suggestion: I removed this and replaced it with a private=* reference that is in use for this use case and was documented just some days ago. --Supaplex030 (talk) 23:36, 15 November 2022 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 1. I have tried this before. Doesn't work, even for me being very patient when only playing with a draft.
2. parking:*:surface:*=* is not an ordered syntax. First of all, kerb itself doesn't have a surface. Any attributes belongs to sidewalk:*:surface=*. I have suggested parking:*:lane:*=* etc before to allow double parking restrictions. This is extensible to parking:*:lane:surface=*.
3. I don't like private=*, Aside from being vague on its own, it's yet another level before reaching the perhaps eventually needed customers=*, permit=*, and residents=*.
--- Kovposch (talk) 05:01, 16 November 2022 (UTC)

@Kovposch: private=* has been in use for a while; I just belatedly discovered it and felt it necessary to raise awareness by creating a page. It happens to address an unrelated longstanding complaint of mine, that access=private on a swimming pool does nothing to distinguish a private backyard swimming pool from a community swimming pool open only to residents. It isn't intended to supplant other access values like access=customers, which are already mutually exclusive of access=private. – Minh Nguyễn ^💬 06:24, 16 November 2022 (UTC)

1. You can compare with my initial attempt to separate out to parking:*:no_*=* in User:Kovposch/Proposed_features/Parking_lane_conditionals/original#Examples. They are still very long.

    parking:right:no_parking=yes
    parking:right:no_parking:conditional=no @ (Mo-Fr 00:00-09:00,18:00-24:00; Sa-Su)
    parking:right:no_stopping:conditional=yes @ (Mo-Fr 07:00-09:00)

As you see, the separated negative form requires double negation. Complicated logic and semantics. The alternative is a very long parking:*:access=no_parking + parking:*:access:conditional=yes @ (Mo-Fr 00:00-09:00,18:00-24:00; Sa-Su); no _stopping @ (Mo-Fr 07:00-09:00)
Using the positive form directly means you have to think of a suitable base val to start from. How should this example start? parking:*:access=stopping or parking:*:access=parking? Assuming the former, you already end up with a long parking:*:access:conditional=parking @ (Mo-Fr 00:00-09:00,18:00-24:00; Sa-Su); no @ (Mo-Fr 07:00-09:00). "No" here is ambiguous what it means.
This is only time-based. I'm not going write out what happens when you mix modes in.
Separating allows eg parking:*:*:reason=* to be specified individually, rather than a very unreadable parking:*:access:reason:conditional=* for each of them together. You have to think about and repeat this for all other attributes as needed.
--- Kovposch (talk) 05:17, 16 November 2022 (UTC)

Resolved: New restriction tagging solves the main issue - the others are out of scope of this proposal and should be discussed further on other/their respective channels. --Supaplex030 (talk) 22:22, 22 November 2022 (UTC)

Map what happens or what is signed

The proposal includes tagging for half footway and full footway parking. The question I have, predominant form of parking of parking in a road segment is one thing (e.g. parking:side=half_on_kerb) but the markings/signs are another (e.g. parking:side=lane), what should we map? What we find on the ground by observing the vehicles or what we find on the ground by observing the signs? Alex Sims (talk) 11:50, 20 November 2022 (UTC)

This is a very good question, which we have discussed intensively in our local community (Berlin, Germany) and roughly answered like this: "We map what is intended by traffic regulations or what is permanently tolerated (in case it is not intended)".

In practice, this e.g. means in our case: There are living streets where parking is only allowed in marked areas. If there are no marked areas, many people still park on the side if the road is wide enough. However, this is occasionally, sometimes regularly, penalised by the authorities and is therefore not a "permanent situation" - and not an intended parking lane anyway. We therefore do not map it. One can argue that this status is clearly indicated "on the ground" by traffic signs and street design.

In other cases, however, people have been parking on the edge of grass strips for years, although this is actually not allowed by law. The authorities absolutely ignore this, so it is tolerated. Ground surface is changing over time (earth instead of grass, compacted ground), so there is something like a parking-characterised area (although not an structural parking lane). I just started mapping such cases with informal=yes to make them identifiable.

I could imagine, however, that your question would be answered differently elsewhere, since it depends, for example, on the importance of parking rules in everyday life and how strongly they are enforced. Therefore, I think the wiki should not provide an answer to this without first having discussed this question broadly and separately. Or at best just give some arguments for and against. --Supaplex030 (talk) 21:22, 20 November 2022 (UTC)

Homonymous keys

Something I completely overlooked in #Example parking lot is that direction=* and orientation=* are being overloaded even more by values like head_in and diagonal. The only obvious conflict is parallel, which works out nicely. However, I am a little concerned about the potential that editors or data consumers might misinterpret these keys when applied to point features that are tangential to the parking lot. For example, one of the common approaches to mapping traffic signs relies on secondary keys, for example maxspeed=* on a speed limit sign. If a sign at the entrance to a parking lot indicates, among other things, that head-in parking is required, direction=head_in just barely avoids a conflict because traffic signs use traffic_sign:direction=* instead of direction=*. But I wonder if there are other feature types we haven't considered. Where there is a conflict, perhaps we could make an exception and use parking:direction=* and parking:orientation=* instead, but this would undermine an otherwise elegant tagging scheme. I think this would only be at most an edge case, so it doesn't affect my vote, but it may be worth a followup at some point, maybe a footnote on one of these pages. – Minh Nguyễn ^💬 19:05, 24 November 2022 (UTC)

I have to admit I don’t understand your (hypothetical?) problem of the traffic sign at the parking lot. Discostu36 (talk) 19:42, 24 November 2022 (UTC)

This parking lot's rules include head-in parking. The rules are all on one sign.

@Discostu36: It is somewhat hypothetical. In the example at right, there are a number of signs detailing the rules of the parking lot. Some parking lots consolidate it into a single sign. If someone wanted to detail the sign itself, they would map a traffic_sign=* node with direction=head_in, among other tags. But to indicate the direction the sign faces, they would need to use traffic_sign:direction=* instead of direction=*. This is actually to be expected in this case, so crisis averted. But I was hypothesizing that there might be some other tagging scheme out there relying on direction=* on the same kind of feature that would get parking-related tags too. As I mentioned, this is quite an edge case already, so it's mostly just a curiosity. – Minh Nguyễn ^💬 21:32, 24 November 2022 (UTC)

I have never noticed it to be a common practice to tag the information signed by the traffic sign as a tag to the traffic sign node. It's not like I should park head in into the traffic sign, is it? Discostu36 (talk) 22:04, 24 November 2022 (UTC)

@Discostu36: I understand your reasoning, but for better or worse, it is a common practice to indicate the sign's contents using the same (non-feature) tags as one would use on the feature that the sign refers to. For example, over 200,000 traffic_sign=* nodes are tagged with maxspeed=*. This is not the maximum speed at which you can run over the sign. ;^) This is probably not the best example, since there's an alternative traffic_sign=maxspeed[123] syntax, but that syntax doesn't work for signs that include multiple pieces of information, as is common in some regions. Maybe we can ride this momentum of tag refactoring to propose a new namespace for these details. – Minh Nguyễn ^💬 01:10, 25 November 2022 (UTC)

I'm aware of this but haven't met any conflicts. (Well, you created one with your traffic sign example, but I don't think this is how the tags should be used or expected to be used by applications.) I also checked whether there are already relevant shared uses (parking + direction/orientation), but this doesn't seem to be the case. I think the rather low/hypothetical risk of misinterpretation is not worth to abstain from the added value that this easy form of tagging offers. Moreover, direction=* is one of the keys with the most homonymous uses, in particular when used with traffic features, so I think all data consumers are aware of how this tag is meant/need to be interpreted depending on its primary key. Of cause, we should document this homonymous uses on all related pages.

An interesting thing is, by the way, that both (direction=* and orientation=*) fits the vanilla definition very closely, so one could say, the proposal just provides more meaningful values for the context of parking. --Supaplex030 (talk) 20:13, 24 November 2022 (UTC)

@Supaplex030: Yes, I think we could manage to justify any conflict in this case. Hopefully it doesn't give future proposal authors too much license to overload these keys further though. – Minh Nguyễn ^💬 21:32, 24 November 2022 (UTC)

Proposal talk:Street parking revision

Contents

Restriction format

no parking/no standing/no stopping Just introduce stopping:<side>!

How should we map no parking/no standing[waiting]/no stopping?

parking:side:markings=*