Proposal talk:Parking lane conditionals/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Scope

The "Proposal" section is reasonably clear as to the proposal's scope, but it might need to be emphasized that this proposal isn't seeking to affirm the exact meanings of values like perpendicular; those details only appear in the proposal to make the restructuring clearer. Otherwise, there's a risk that some voters may have concerns about those details that aren't in scope, or that people could later point to a successful proposal here as evidence that all the details are correct. In fact, I've demonstrated in Talk:Key:parking:lane/Archive 1#Parking, stopping, and standing that the no_stopping and no_parking values are currently documented inaccurately, but I wouldn't want to derail this common-sense proposal, unless you're interested in also tackling those problems at the same time. – Minh Nguyễn 💬 19:13, 25 August 2021 (UTC)

I was hoping to clarify and correct some details that I found to be inaccurate in the current tagging along with adding conditional tagging. The changes not related to conditionals are minor and half of them could be done by just editing the current tag page. I plan on adding some formatting to highlight them. We'll see how much comments those get during the RFC. --Riiga (talk) 20:05, 25 August 2021 (UTC)
I don't want to push to over-extend either , but in Discord I realized Conditional_restrictions at least requires the access:*=* modal suffix according to Proposed_features/Conditional_restrictions (https://wiki.openstreetmap.org/w/index.php?oldid=821276), so parking:lane:*:condition:vehicles=* may need to be deprecated. (it doesn't make sense to have parking:lane:*:condition:vehicles:conditional=*) ---- Kovposch (talk) 17:24, 26 August 2021 (UTC)
After thinking about it a bit I realise this is correct. I will try and modify the proposal accordingly. --Riiga (talk) 11:51, 27 August 2021 (UTC)
Sorry for my wording, meant the sub-keys should be used. parking:condition:both:access=motorcar is not valid. It should be parking:lane:both:*=* or parking:condition:both:*=*, eg parking:lane:both:motorcar=diagonal / parking:condition:both:motorcar=free, and parking:lane:both:hgv:conditional=parallel @ (08:00-18:00) / parking:condition:both:hgv:conditional=free @ (08:00-18:00).
Which is why I won't want to keep parking:condition=* (although the numbered multi-condition suffix has its own arguments in uniformity and length). I doubt if this and *:conditional=* goes well with it. You can see there are 2 possibilities with this syntax.
---- Kovposch (talk) 17:52, 27 August 2021 (UTC)
So for the last example, at least:
Or depending on how you interpret it, it may be parking:lane:right:bus:conditional=parallel @ (Mo-Fr 07:00-09:00, 15:00-18:00) instead.
---- Kovposch (talk) 18:09, 27 August 2021 (UTC)
Agreed, it would be necessary to put the vehicle types in the key rather than the value, since for instance there could be a sign saying "no motorcycle parking" at certain times. On the other hand, the original syntax made it convenient to tag things like "except bus". Now there may be situations where mappers have to consult this sprawling tree to figure out how to effectively exclude buses while allowing everything else, or override the condition for buses using free. But I think that's a larger problem affecting access restriction tagging overall. – Minh Nguyễn 💬 19:49, 27 August 2021 (UTC)
I've made an edit to reflect this. --Riiga (talk) 11:33, 30 August 2021 (UTC)
I was thinking, maybe it would make sense to not remove no_stopping and no_parking from parking:condition=* and keep them for conditional parking restrictions on vehicles. For example a parking lane where trucks are prohibited would be either:
or
Which one makes more sense to you? Or are both equally acceptable? --Riiga (talk) 11:42, 30 August 2021 (UTC)
@Riiga: Yes, I think the latter makes more sense. parking:lane=* should really only describe the physical infrastructure, not how it's used. That way there won't be as much need for parking:lane:condition=*. Maybe it would help head off some confusion about the purpose of the two keys. – Minh Nguyễn 💬 18:40, 26 November 2021 (UTC)
@Minh Nguyen: I've reworked the proposal to reflect this. Overall I think it resulted in an improvement. Riiga (talk) 22:03, 27 November 2021 (UTC)
Resolved

No standing is missing

no_standing is missing from the current page and from this proposal. See https://en.wikipedia.org/wiki/Road_signs_in_the_United_States#No_Standing According to my research, it seems that the United States and the Phillippines are the only countries in which a sign like this exists. --Westnordost (talk) 13:21, 26 November 2021 (UTC)

See examples of these signs from around the world (also Australia and Canada) in Commons:Category:Diagrams of no standing signs, and a table of the differences between these prohibitions in Talk:Key:parking:lane/Archive 1#Parking, stopping, and standing. – Minh Nguyễn 💬 18:12, 26 November 2021 (UTC)
@Westnordost: I've added no_standing. Riiga (talk) 22:03, 27 November 2021 (UTC)
Resolved

How to tag other "no" parking?

With no_parking removed from parking:lane=*, no means not only "no" for "unspecified / other reasons".

So then, how to tag parking:condition=* if it is "no" for other reasons? Other reasons could be "not wide enough", "not possible for other reasons", "it's right in front of an intersection", "I don't know, there is simply not one car here", "there is a dedicated side-road just for parking" or whatever. You know, that is not a common consideration that is made in tag design in OSM. But it is a requirement to contribute with StreetComplete - the observation that there is no explicit sign or marking for no parking (etc.) but there is still no parking lane must be tagged somehow.

By the way, so far I imagined the quest to work like this:

  1. ask about physical parking lane: "Yes" prompts to specify if it is diagonal, parallel, perpendicular. "No (unconditionally)" prompts to specify it is no parking, no stopping or no for other reasons.
  2. only for lanes which are diagonal, parallel, perpendicular, ask about any signed parking restrictions (maxstay, hours, fees, maybe any special signs): if there are none, parking:condition:*=free is tagged

--Westnordost (talk) 15:46, 29 November 2021 (UTC)

@Westnordost: The first quest seems like it shouldn't be trying to clarify anything beyond "No": if there's no parking lane, then stopping isn't allowed anyways, unless you want to handle situations where cars can park on the street despite blocking traffic. (I guess I've seen that informally at an airport before, but maybe it's a thing in Europe.) The no parking/no stopping distinction seems more germane to the second quest, since it's so often conditional on the time of day and other factors. That's what motivated my suggestion to move no_parking to parking:condition=*. This nonexhaustive table is sort of how I was picturing this proposal fitting in with StreetComplete; does it make sense?

User sees Space to park? Allowed to park? parking:lane=* parking:condition=*
R32
R24
 yes yes parking:lane=parallel parking:condition=free
R32B
 yes Depends parking:lane=parallel parking:condition:conditional=no_parking @ …; free @ …
R28C
 yes no parking:lane=parallel parking:condition=no_stopping
R26F
 no no parking:lane=no parking:condition=no_stopping

 – Minh Nguyễn 💬 02:44, 30 November 2021 (UTC)

@Westnordost: Normally I wouldn't split a road and tag that for every junction as it is a basic rule of the road (in Sweden at least) that you can't park or stop within 10 meters of a junction/intersection. If you need to explicitly tag that you can't park in an intersection, you can use parking:condition:reason=*. Those 10 meters near the intersection in all directions would then have:

--Riiga (talk) 08:08, 30 November 2021 (UTC)

I wouldn't either but that doesn't mean that other people would do it. Also, sometimes, especially at intersections etc., the road may already be split up. So if a user is asked for a tiny section of road at an intersection about the parking situation, he'll of course want to answer it correctly. Regarding parking:condition:both:reason=junction - that you are not allowed to park because it is a junction was just an example. There can be many reasons why one cannot prk here. My point is that 1. parking:condition:both:reason=* would need to be exhaustive to be able to tag something in that case, which is virtually impossible due to the many different reasons why it may not be allowed to park (both signed, e.g. "clearway" etc, and not). And 2. that the user may not know if a particular situation leads to "no stopping" or "no parking", so the user needs the ability to just say "no" without being more specific. --Westnordost (talk) 11:17, 30 November 2021 (UTC)

Too long discussion in here, I'll mark this as resolved and state in short clear terms what the issue is in a new topic. --Westnordost (talk) 20:59, 11 December 2021 (UTC)

Resolved


Unclear what is changed

I went through the proposal and I am not really sure what, if anything, is changed for simpler cases. If there is no baroque set of rules - is tagging also changed? Mateusz Konieczny (talk) 11:49, 13 December 2021 (UTC)

@Mateusz Konieczny: Even a simple "No Parking Any Time" sign will change from parking:lane:right=no_parking to parking:lane:right=* parking:condition:right=no_parking. Special:Diff/2230145 adds a minimal example (with no parking lane in that case). Key:parking:lane had incorrectly described "No Parking" as meaning no_stopping in the U.S., but Westnordost copied the fix from this proposal to the main page. – Minh Nguyễn 💬 00:46, 14 December 2021 (UTC)
@Minh Nguyen: If this is intended then list next to "For other types, the condition tag makes little sense." should be modified and start including "no" Mateusz Konieczny (talk) 06:37, 14 December 2021 (UTC)
Resolved: I listed also "no" based on feedback - see https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Parking_lane_conditionals&diff=next&oldid=2230192 Mateusz Konieczny (talk) 09:17, 14 December 2021 (UTC)

Maybe give standard way to tag "there are conditional rules, I give up on listing them"

There are many cases where there are complex rules with exemptions but mapper is willing only to record main rule ("in general paid"). It would be nice to have some tag like parking:condition:side:conditional=not_recorded or fixme:parking:condition=yes to allow stating this. It would allow distinguishing between "this is too complex to tag, mapper tagged simplified version only" and "this parking has simple rules" Mateusz Konieczny (talk) 11:52, 13 December 2021 (UTC)

If you do not think that it is a really good idea feel free to ignore it (I can make own proposal after all) Mateusz Konieczny (talk) 12:08, 13 December 2021 (UTC)
Is fixme=* not enough for you give up? Following payment=*, it may be viable to use *:others=yes for incompleteness, *:others=no for completeness. ---- Kovposch (talk) 12:12, 13 December 2021 (UTC)
@Mateusz Konieczny: The conditional restriction tagging scheme offers quite a bit of flexibility. Even [1] can be tagged, as parking:condition:right=no_parking @ "day of Packers game", without having to integrate the editor with an NFL team schedule. If it's some unreadable symbol sign and you're totally stumped, fixme=* or a note is probably a safer bet anyways. – Minh Nguyễn 💬 01:08, 14 December 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 06:38, 14 December 2021 (UTC)

Is RFC planned?

Are you planning an RFC? Mateusz Konieczny (talk) 19:26, 12 December 2021 (UTC)

I am asking partially because I am right now working on implementing support for parking:condition in one of editors Mateusz Konieczny (talk) 19:29, 12 December 2021 (UTC)
I hope the counterproposal hasn't scared away Riiga after they've put in so much work iterating on this proposal to where it is now. In my opinion, it already addresses the worst flaws of the existing tagging scheme and is ready for an RFC, even if there are some remaining issues on the margins. None of the iterative changes in this proposal would preclude a subsequent overhaul of the tagging scheme, if there's sufficient need for it. – Minh Nguyễn 💬 22:02, 12 December 2021 (UTC)
I've been considering reworking the proposal again to partly match the counter-proposal, but as it stands I will probably go ahead with an RFC this week on the current proposal. --Riiga (talk) 22:30, 12 December 2021 (UTC)
Thank you for your time. I reformatted the table to compare the different schemas side-by-side. You can use it in this ver too. Just delete my new column.
Working on more examples for my part. It's broken up into 3 levels, so you can choose which part to adopt. I will wait to see how your proposal is received.
----- Kovposch (talk) 11:32, 13 December 2021 (UTC)
@Riiga: I made some edits that attempted to improve clarity without changing proposal, feel free to revert my edits if I broke something or you disagree with me (it is your proposal) Mateusz Konieczny (talk) 11:44, 13 December 2021 (UTC)
Sorry for producing so many questions - but this topic is an endless hole of complexity Mateusz Konieczny (talk) 06:56, 14 December 2021 (UTC)

How to record no stopping?

How one would record "no stopping allowed here" with the new schema? parking:lane:both=no_stopping would have no equivalent. Mateusz Konieczny (talk) 11:24, 13 December 2021 (UTC)

https://wiki.openstreetmap.org/wiki/Proposed_features/Parking_lane_conditionals#Parking_conditions still lists "no stopping" but has claim that it should be used only with "parallel, diagonal, perpendicular" values of parking:lane:side tags Mateusz Konieczny (talk) 11:27, 13 December 2021 (UTC)
@Mateusz Konieczny: parking:lane:both=no_stopping is ambiguous because it doesn't say anything about the physical presence of a lane. Stopping could be prohibited on one side of the street because of the absence of a lane and on the other side because a lane is present but restricted (either conditionally or unconditionally). As such, there can be no automatic migration path to the new tagging scheme, but it could be the subject of a MapRoulette challenge or StreetComplete quest. – Minh Nguyễn 💬 00:12, 14 December 2021 (UTC)
@Minh Nguyen: I was rather complaining that the current proposal makes impossible to tag "there is no dedicated parking lane and stopping is not allowed at all" Mateusz Konieczny (talk) 06:35, 14 December 2021 (UTC)
@Mateusz Konieczny: It would be just parking:condition:both=no_stopping. If you know the physical layout, that goes in the parking:lane=* tag. As Westnordost requested, I will split the example section in two, with simple examples in the first one where cases like this is explained. --Riiga (talk) 07:53, 14 December 2021 (UTC)
@Riiga: Then I made https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Parking_lane_conditionals&diff=2230199&oldid=2230192 Mateusz Konieczny (talk) 09:16, 14 December 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 12:56, 14 December 2021 (UTC)

How to handle parking lane where stopping is forbidden

Yes, it is extreme edge case but new schema appears to be regressing here compared to the current one where parking:lane:both=no_stopping could be used Mateusz Konieczny (talk) 11:25, 13 December 2021 (UTC)

@Mateusz Konieczny: This is one of the major features of the new proposal: before, there was no way to express this case unambiguously, but now you can say parking:lane:both=parallel parking:condition:both=no_stopping. – Minh Nguyễn 💬 00:13, 14 December 2021 (UTC)
Like Minh Nguyen said, you use parking:lane=* to specify physical layout and parking:condition=* to specify if parking is allowed or not and under which circumstances. You don't need to tag both, if you don't know what a road looks like but you know parking is forbidden, just add parking:condition:both=no_parking. --Riiga (talk) 07:56, 14 December 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 09:17, 14 December 2021 (UTC)

Distinguishing diagonal, perpendicular and parallel parking without dedicated parking lane

In Poland it is possible to have diagonal, perpendicular and parallel parking without dedicated parking lane (parking on sidewalk). How this proposal would distinguish them? In all cases parking:lane:*=no would apply due to lack of dedicated parking lane or dedicated parking space Mateusz Konieczny (talk) 06:54, 14 December 2021 (UTC)

It's possible to tag that. The "Parking position" part of the current proposal is not being changed and therefore not included in my proposal. I will add a note about that to make it clearer. A diagonal parking lane on the kerb would (for example) be parking:lane:both=diagonal + parking:lane:both:diagonal=on_kerb. This syntax is unchanged from the current one. --Riiga (talk) 08:04, 14 December 2021 (UTC)
Then "There is no physical parking lane." should be rephrased Mateusz Konieczny (talk) 09:18, 14 December 2021 (UTC)
How is it wrong? See the middle example here which I'm guessing is exactly what you're after. The tagging for this is the same in the old and new tagging. --Riiga (talk) 10:00, 14 December 2021 (UTC)
Because "There is no physical parking lane." description excludes cases where paring space along road is not a parking lane, especially when it is on sidewalk. What mismatches some of examples and intended tagging Mateusz Konieczny (talk) 12:56, 14 December 2021 (UTC)
I reworded it slightly to "There is (no) parking space". --Riiga (talk) 13:21, 14 December 2021 (UTC)
I guess "parking lane" is being defined loosely to include any space for parking, even if it's a sidewalk instead of a lane. That is confusing, but the proposal could define exactly what's meant by "parking lane" in this context. I don't see a better way around it unless we depart more drastically from the existing tagging scheme. – Minh Nguyễn 💬 10:37, 14 December 2021 (UTC)
https://commons.wikimedia.org/wiki/File:Gontyna_street,_Salwator,_Krak%C3%B3w,_Poland.jpg has no parking lane - it has parking space on sidewalk. Even https://commons.wikimedia.org/wiki/File:Ferdinand_Foch_Avenue_(Cracovia_SC_Stadium),_Krakow,_Poland.jpg I would not describe as parking lane (though it can be tagged with parking:lane:* tag family). https://commons.wikimedia.org/wiki/File:T%C5%99ebo%C5%88,_Svobody,_cyklopruh_a_parkovac%C3%AD_pruh_u_h%C5%99bitova.jpg is a parking lane Mateusz Konieczny (talk) 12:54, 14 December 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 08:07, 15 December 2021 (UTC)

Tow-away

Resolved: Kovposch (talk) 19:16, 14 December 2021 (UTC)

I see you added parking:condition:*:reason=tow_away, However it's not a reason of restriction, only a punishment. I actually thought about asking this, if not for being off-topic:

Enforcement

In Proposed features/Parking_lane_conditionals#Examples, "tow-away" is not handled yet. Since *:reason=* (and maybe *:related_law=*) is being added now, would it be in-scope to cover it here? Other synonyms include "impounding" zone. For comparison, some are using fine=* as fine:parking:lane:side.

Revived

Would be more accurate to use eg parking:*:side:violation:* (the word "penalty" is avoided for confusion with soccer)

In any case, I find this to be out of scope. -- Kovposch (talk) 13:30, 14 December 2021 (UTC)

I'll remove tow-away for now --Riiga (talk) 14:08, 14 December 2021 (UTC)

parking:lane:right:conditional vs parking:condition:right:conditional = ???

I have issues wrapping my head around the difference between the two. And then also the thing with :1, :2, ....? I am honestly not sure if there is a massive tagging scheme definition problem here or if I simply don't understand it.

Suggestion: Integrate the :conditional with 1 or 2 examples into the tables. E.g. add a row to both parking:condition:<side> and parking:lane:<side> tables that showcases the conditionals. Same with maxstay, same with numbered conditionals. Note that conditionals can usually be concatenated with a semicolon. Why deviating from this standard here? --Westnordost (talk) 13:32, 26 November 2021 (UTC)

@Westnordost: Hm, there does seem to be a problem. In the existing scheme, parking:lane=* mostly describes the physical characteristics of the parking lane, while parking:condition=* describes its allowed or disallowed uses. But that causes it to reuse values like no_parking for two different purposes. On the one hand, parking:lane=no_parking could mean there isn't even a parking "lane" at all, not even the space to park. On the other hand, parking:lane=parallel parking:condition=no_parking means there is a parking lane but you can't park there (under the conditions specified by additional subkeys). This proposal consolidates no_parking and no_stopping into parking:lane=*, which unfortunately blurs the distinction. Now a data consumer would be unable to reliably incorporate parking:lane=* into an estimation of the width of a street, for example. An editor would also be unable to support tagging the presence of a parking lane (something that can often be spotted in aerial imagery) without also adding much more complex support for parking regulations. What if we move no_parking etc. back to parking:condition=*? parking:lane=no would be the only way to indicate that there's no physical parking lane, and it would be very unlikely to require conditional tagging. – Minh Nguyễn 💬 18:37, 26 November 2021 (UTC)
Both the existing and proposed schemes use numbered conditions because each condition has a large number of possible attributes associated with it. Some of these attributes can be incorporated into the conditional restriction syntax, such as parking:condition:time_interval=* and parking:condition:vehicles=*. But other attributes don't affect whether a condition is currently in effect, such as parking:condition:maxstay=* and the undocumented but heavily used parking:condition:reason=*. Unfortunately, OSM's flat key-value table data model doesn't natively support arrays of key-value tables, so the numbered conditions are used by both this scheme and a couple of more obscure tagging schemes. The alternative would be to maintain parallel lists in each conditional subkey, like parking:condition:conditional=conditionA @ timeA; conditionB @ timeB; conditionC @ timeC parking:condition:maxstay=maxstayA @ timeA; maxstayB @ timeB; maxstayC @ timeC. (In a sense, enforcement relations could be an alternative, considering the one-to-many relationship between a feature and a key-value table, but there would be no way for one restriction to take precedence over another.) – Minh Nguyễn 💬 18:37, 26 November 2021 (UTC)
@Westnordost: @Minh Nguyen: After reading through this, I've tried to refine the tagging so that only physical properties are in the :lane tag and conditions only in the :condition tag. This should make it much clearer, with the caveat that multiple values need to specified in the same tag for multiple conditions, but after all it's not that different from opening hours tagging which works just fine. I hope you both will read through the proposal again and see if you find it easier to understand. The addition of yes and no as physical properties to the :lane tag should also allow for apps like StreetComplete to specify this part through a quest as well as allow estimating the width of a road from this property. Riiga (talk) 22:03, 27 November 2021 (UTC)
@Riiga: Thanks, at a glance, it does look like a major improvement. If I weren't already familiar with the existing tagging scheme, I would find this distinction between parking:lane=* and parking:condition=* to be much more intuitive. The subkey "condition" can be easily confused with "conditional", but I'd understand if we want to keep it for backwards compatibility and avoid unnecessary churn. How about describing it as a "parking lane use" as opposed to a "parking lane condition", to mitigate that confusion? – Minh Nguyễn 💬 22:22, 27 November 2021 (UTC)
No stopping or no parking isn't really a use of the parking lane, but rather a condition imposed, so I think I want to keep that description. I will add some clarification though. Riiga (talk) 00:41, 28 November 2021 (UTC)
Resolved

Fire lanes

Fire lanes ringing parking aisles

To follow up on some of the above discussion, should the proposal attempt to incorporate the undocumented but common tagging of parking:condition:reason=* somehow? I don't see a reason why bus_stop would be treated as an attribute of parking lane use, while fire_lane would be treated as a physical characteristic of the roadway. In my experience, fire lanes can occur anywhere regardless of infrastructure, and loading zones are similarly diverse. Do any places have a distinct concept of a fire lane that doesn't look like a parking lane or the absence of one? Over in OSMUS Slack, there's a similar discussion about "clearways" in the United Kingdom and Australia, which are a well-defined concept that can be expressed in terms of other restrictions like no_stopping.

 – Minh Nguyễn 💬 22:22, 27 November 2021 (UTC)

@Minh Nguyen: I'm unfamiliar with fire lanes as they don't exist here, but I agree some kind of tagging for the reason would be useful. Loading zones here are just a specialised category of the no stopping condition. The signs for them can also have other text instead of "Loading zone", such as "Taxi zone" or "School dropoff" and it would be nice to be able to specify that. There still needs to be a value for this as a physical feature though. Is there a good generic term in English that could be used to describe it? --Riiga (talk)
Curbs of a driveway marked as fire lanes; no extra lateral space provided for parking
@Riiga: In my experience, "fire lane" most commonly describes a situation where there isn't even dedicated space for parking. Sometimes there's space that's reserved for emergency use, but I wouldn't call that a parking lane. It's the kind of space that would be set off by crosshatching or completely unmarked. (In the U.S., parking lanes are almost always marked by something on the pavement.) Loading zones are usually situated along parallel parking lanes, but sometimes it's diagonal, perpendicular, half-on-curb, or intrudes on the traffic lanes. I don't know how that lines up with other places that have fire lanes and loading zones, though. – Minh Nguyễn 💬 02:00, 28 November 2021 (UTC)
@Minh Nguyen: I've reworked the proposal again to include parking:condition:reason=* which also makes it possible to specify the physical property of a lane in full. You can now have a diagonal parking lane where no parking is allowed at certain times because it is a fire lane at those times. Let me know what you think and which/if more reasons should be added. --Riiga (talk) 15:34, 28 November 2021 (UTC)
@Riiga: Great, thanks! I'm sure people will come across more things to put in that key over time as they become aware of it. This is a good set for starters. A minor issue would be the value crosswalk, which is an Americanism; crossing would be consistent with highway=crossing. – Minh Nguyễn 💬 22:28, 28 November 2021 (UTC)
Resolved

Explain by example

I've read through the updated proposal, looks much clearer now!

I'd propose to refrain from long prosa text but just add a table with a few easy examples that each showase maxstay, conditional maxstay, no parking at certain time, no parking for HGV. I.e. explain by example. Could be photos or (IMO) better SVGs. Further down (in the new article) are then the new more complex examples. --Westnordost (talk) 13:12, 29 November 2021 (UTC)

I've now added an example section with this. --Riiga (talk) 12:12, 14 December 2021 (UTC)
Looks very nice! It would be helpful to show how each situation would be tagged in the current scheme, but this is not what I asked in this topic, so I'll mark this as resolved. --Westnordost (talk) 13:38, 15 December 2021 (UTC)
Resolved

no_standing/no_stopping

Which one applies to https://wiki.openstreetmap.org/wiki/File:MUTCD-CA_R38A.svg ?

Right now example where it is used is quite confusing Mateusz Konieczny (talk) 11:43, 13 December 2021 (UTC)

@Mateusz Konieczny: The example suggests tagging the "Passenger Loading Only" part of the sign as parking:condition:right=no_standing, and the "No Stopping" part of the sign as parking:condition:right:conditional=no_stopping @ (07:00-09:00), because it overrides the "Passenger Loading Only" part during a specific time interval. – Minh Nguyễn 💬 00:22, 14 December 2021 (UTC)
@Mateusz Konieczny: TBH the 5min limit is pretty generous, IIRC the time limit for a "no parking" restriction in Germany is 3 minutes. Though, "no parking" includes the right to load/unload goods while "no standing" typically only includes the right to load/drop off passengers (i.e. don't leave the car). I'm marking this as resolved --Westnordost (talk) 13:52, 15 December 2021 (UTC)
Resolved

Missing unspecific "no"

Resolved: added Mateusz Konieczny (talk) 17:14, 16 December 2021 (UTC)

In some cases it is impossible to distinguish between no_stopping, no_parking and no_standing but it is clear that parking is illegal.

That includes cases where there is definitely no parking, but "no stopping" depends on season, weather and interpretation of law.

Basically proposal drops https://wiki.openstreetmap.org/w/index.php?title=Key:parking:lane&diff=2025099&oldid=2015053 case

Mateusz Konieczny (talk) 11:20, 15 December 2021 (UTC)

Do you have any IRL examples of where that tagging would be used? --Riiga (talk) 13:10, 15 December 2021 (UTC)
Nvm, I added this. --Riiga (talk) 14:01, 15 December 2021 (UTC)
I would reject a parking:condition:*=no. Not enough meaning to show it's not "no condition", ie conflicting with parking:condition:*=free. ---- Kovposch (talk) 14:06, 15 December 2021 (UTC)
I see it as an unspecific value that should be replaced when possible, but it still makes sense to tag this if you know one of the values apply. Tagging it as "no_parking" when it reality it is "no_stopping" would be incorrect data. Just "no" is incomplete but not incorrect data. --Riiga (talk) 14:11, 15 December 2021 (UTC)
No, this meaning is incorrect. parking:condition:*=no would mean there is no condition, almost exactly conditionless parking:condition:*=free. You should use parking:condition:*=yes to show there is some condition that should exist. ----- Kovposch (talk) 14:16, 15 December 2021 (UTC)
That would be value of parking:lane:*, not parking:condition:* Mateusz Konieczny (talk) 14:50, 15 December 2021 (UTC)
I don't understand your comparison. None of the parking:condition:*=* values uses simple wording. Introduction of "no" points to the existence of a "yes". In this context, the negation is unclear on whether it is negating the "condition" or parking. ---- Kovposch (talk) 17:46, 18 December 2021 (UTC)
Ok how about parking:condition:*=restricted and parking:condition:*=allowed for the negative and positive implication? Yes-no is confusing here. ---- Kovposch (talk) 14:46, 15 December 2021 (UTC)
Your "clear that parking is illegal" and "definitely no parking" is already parking:condition:*=no_parking to start with?
(Another reason why I want to deprecate it. Semantically my idea allow you to specify on top a parking:lane:*:no_parking=yes base case, if it's the single parking:condition:*=* value bothering you.)
---- Kovposch (talk) 14:06, 15 December 2021 (UTC)
"is already parking:condition:*=no_parking to start with?" - no, as just "no_parking" means that stopping is legal. And in some cases it is clear that parking is illegal and legality of stopping is unclear Mateusz Konieczny (talk) 14:45, 15 December 2021 (UTC)

Road section within the junction

I added explicit image for that based on comments on talk page, please edit it (if I interpreted something incorrectly) or revert (if for some reason such example is not supposed to appear) Mateusz Konieczny (talk) 18:44, 18 December 2021 (UTC)

OK --Riiga (talk)
Resolved

Value length limit

A tag value is limited to 255 characters, which has posed a problem for some other forms of conditional tagging in the past. (I've had to get creative about conditional maxweight=* tagging due to the complicated nature of weight restrictions in the U.S.) Would any existing features be impacted by this length limit? This extreme example comes in at only 188 characters for its longest tag value, but we only know about that example because it has an abundance of signs, some of them redundant. There may be more extreme examples out there that have deceptively simple signs by comparison. – Minh Nguyễn 💬 19:19, 25 August 2021 (UTC)

I highly doubt there are such complicated situations where this would arise with parking, given that it's easy to split it into various separate conditions (:1, :2, etc are still supported). --Riiga (talk) 20:05, 25 August 2021 (UTC)
Ah, I didn't realize you intended to keep the :2 syntax. That would be worth calling out in the proposal, in case people incorrectly assume (as I did) that eliminating *:time_interval=* eliminates the need for that syntax. – Minh Nguyễn 💬 00:55, 26 August 2021 (UTC)
I find it useful for the resident parking conditions as they (often) are separate to normal parking conditions, so in my mind it makes sense to use :1 or :2 for them. I will try to add a section about them. --Riiga (talk) 09:49, 26 August 2021 (UTC)
I see "The use of additional namespaces (:1, :2, etc.) is deprecated." what mismatches what is stated here Mateusz Konieczny (talk) 11:06, 13 December 2021 (UTC)
I changed my mind after some revision. The statement in the proposal is correct. --Riiga (talk) 07:34, 14 December 2021 (UTC)
Resolved

Global examples

Currently, all the examples are from a particular country (presumably Sweden?). It would be beneficial to include some examples from other countries, particularly those that don't follow the Vienna Convention, to demonstrate that the proposal is flexible enough to apply globally. Towards this end, I've been researching parking signs in the U.S., where there are a great variety of signs that haven't previously been considered on this wiki. So far, I've only researched the national standard and a couple state standards:

There are also many local variations, since cities are usually responsible for enforcing parking regulations, but I haven't gotten around to researching them yet. Mappers have also put together traffic sign listings for several other countries.

I don't think all these signs are within scope for this proposal, but some may be. I can provide more details if the meaning of a particular sign is unclear.

 – Minh Nguyễn 💬 19:34, 25 August 2021 (UTC)

Yes, I was hoping to add more international examples. As you said, the examples are mainly from Sweden (as am I), and a few German and Finnish examples I found on this wiki also thrown in. I would be grateful for a few North American examples, or any other countries that either have situations not covered here and/or use non-Vienna Convention signage (like the MUTCD). --Riiga (talk)

@Riiga: I finally finished creating images for all the parking signs in California. I'm pretty sure California has more standard parking signs than any other state, but many of the considerations for California apply in other states too. Let me know if the tagging suggestions in MUTCD/California/R and MUTCD/California/SR are unclear as to how they'd translate to the conditional tagging proposal. – Minh Nguyễn 💬 09:28, 17 November 2021 (UTC)

Thank you! I'll try and integrate a few of them as exemples. Riiga (talk) 13:35, 17 November 2021 (UTC)

@Minh Nguyen: Do you think that additional examples are needed? It seems to be no longer Sweden only Mateusz Konieczny (talk) 11:17, 13 December 2021 (UTC)

@Mateusz Konieczny: I did end up adding a few from the U.S. for demonstration purposes. The proposal would benefit from examples from some additional jurisdictions, so that voters can see how the still-complex syntax is an improvement over the original in their own locales, but I think we're in better shape now. The current table won't scale to many more examples anyways. (Maybe we should split the examples into a subpage so the main proposal page loads faster?) – Minh Nguyễn 💬 00:09, 14 December 2021 (UTC)
@Minh Nguyen: I've hidden the complex examples by default and added some simples examples for basic tagging with both Vienna Convention and MUTCD signage. --Riiga (talk) 15:15, 15 December 2021 (UTC)
Resolved

Outreach

At some point, it would be helpful to reach out to some developers who would be especially impacted by this proposal. The good news is that the existing parking:lane=* and parking:condition=* tagging schema is not yet widely supported by data consumers, but this specialized editor for parking lanes is fairly well-known and would need to be updated, as would Vespucci and some JOSM preset packs. – Minh Nguyễn 💬 19:58, 26 August 2021 (UTC)

I added https://github.com/zlant/parking-lanes/issues/61 . I think it is better to involve data consumers/specialized editor developers early in the process rather than "when it is done". Vespucci gets its prests from JOSM, so a simple update to the JOSM presets would be in order if this is approved but I do not think JOSM developers need to be involved in the process because they have no custom UI or parsing for it. --Westnordost (talk) 22:23, 30 November 2021 (UTC)
@Westnordost: "Vespucci gets its prests from JOSM" - no, Vespucci forked its presets, and maintains them at https://github.com/simonpoole/beautified-JOSM-preset separately from JOSM presets Mateusz Konieczny (talk) 11:10, 13 December 2021 (UTC)
I opened https://github.com/simonpoole/beautified-JOSM-preset/issues/296 Mateusz Konieczny (talk) 11:14, 13 December 2021 (UTC)
Resolved

Is :both really needed

I might be 10 years too late, but do we really need :both. In my eyes, there is no difference between no suffix and :both and it simply adds five more letters to a bunch of tags. --Skyper (talk) 16:40, 26 December 2021 (UTC)

It seems more clear with it and THIS complexity is nothing to everything else. And every bit of clarity helps here Mateusz Konieczny (talk) 00:25, 27 December 2021 (UTC)
:both is already in-use tagging, so this is not really part of this proposal. Removing/deprecating :both would need to be another proposal, though I think there is a good reason for :both --Westnordost (talk) 12:31, 27 December 2021 (UTC)
As others have already commented, this proposal is a refinement of already in-use tagging, not a complete change, so :both will remain. --Riiga (talk) 17:52, 27 December 2021 (UTC)
Resolved: out of scope
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Parking_lane_conditionals/Archive_1&oldid=2516303"