Proposal talk:Parking lane conditionals

Counter-proposal

Haven't followed all the discussions yet. Leaving this first.

parking:condition:*:conditional=* looks really ugly to me. Inside, mixing parking:condition:*=ticket and parking:condition:*=disc among the other restrictions and users isn't very nice, especially when you allow semi-colon separated combination of *=ticket; residents shown in your examples. The parking:condition:*=free + parking:condition:*:maxstay=* combination is also not fully logical.

My concept for deprecating both parking:condition:side, and possibly parking:lane:side:orientation as well: User:Kovposch/Proposed features/Parking lane conditionals#Tagging Grouping of multiple conditions by number suffix/infix is abandoned in favor of doing this on signs. The restrictions should be grouped by time and other criteria directly. If this exceeds the value length limit, that's the problem with opening_hours=* and *:conditional=* in general. ---- Kovposch (talk) 11:57, 13 December 2021 (UTC)

Can work out some examples later if needed.

-- Kovposch (talk) 10:49, 30 November 2021 (UTC)

parking:condition:*=ticket "*" is not very readable or easily parsed either. ---- Kovposch (talk) 11:31, 30 November 2021 (UTC)

Some comments to (errors in) your (counter-)proposal, maybe you want to correct them:

1. you mention both parking:right=street_side and parking:lane:right=street_side - duplicate

2. the proposed tagging parking:lane:right=on_street overlaps with current usage/meaning of the tag, e.g. parking:lane:right=parallel. So what you do is redefine the meaning of this key from "gives information on physical layout of parking lane" to "gives information on details how the parking lane is oriented in relation to the street".

3. parking:lane:right:half_on_kerb:surface wouldn't make sense though. on_street already not so much, after all the surface is already given on the road.

--Westnordost (talk) 11:43, 30 November 2021 (UTC)

Ok let me check. I'm thinking I should create a separate page or something. ---- Kovposch (talk) 12:04, 30 November 2021 (UTC)

@Westnordost: Thanks for reading through this long "comment".

1. Corrected.

2. I have considered changing to parking:side:lane, in order to match my parking:side. Another problem is how to handle parking restrictions on shoulder=* and bus_bay=*, since shoulder:side:* tagging coexists with the few parking:lane:both:parallel=shoulder et al documented in Key:parking:lane#Parking_position. Anyway, this could be reserved for future.

3. It's for handling changing surface=* on the road along the cross-section. surface:side is not clear on the extent of the different pavement. surface:lanes=* is longer, and not totally certain on how lanes are counted. In the end, it's only an example to illustrate the possible use of this schema. Can be taken out.

---- Kovposch (talk) 13:15, 30 November 2021 (UTC)

User:Kovposch/Proposed features/Parking lane conditionals#Examples ---- Kovposch (talk) 11:57, 13 December 2021 (UTC)

Feeling it's easier to evaluate each attribute individually as I work through it

-- Kovposch (talk) 12:04, 30 November 2021 (UTC)

It's really really laborious to work through your suggested changes/counter-proposal and how exactly it differs from the proposal and in turn differs from the current way to tag things. I suggest the following to move forward:

Create an own wiki page (in your user space or wherever) that is a table of parking lane (situations) sorted from easy (perpendicular free parking, parking prohibited, stopping prohibited) over a little complex (requires fee, only residents, no HGV, only at certain times...) to more complex and finally most complex examples. The table has 4 columns: 1st the picture, second how it is currently tagged, third how this proposal proposes to tag it and lastly how you propose to tag it. This will hopefully give us a better overview and then we can discuss based on that.

As a side-effect, the examples you add there can be used later when the proposal is accepted to better document the whole scheme because the current wiki page a lot and the proposal page still is still kind of complex to understand with all the prosa.

--Westnordost (talk) 21:27, 30 November 2021 (UTC)

Yeah, when I work out the table I realized it's quite a hassle to clean up the existing examples' annotations, not to mention a full comparison would require diving into the current syntax. Will take some time. ---- Kovposch (talk) 09:28, 1 December 2021 (UTC)

@Kovposch: Why do you keep using :lane in your counter-proposal, although parking can explicitly filled with other values in your examples? That would lead to confusion again. There is no need for that, because the distinction between lane, street_side etc. results from the position.

Why not simply:

parking:right = parallel

parking:right:position = on_street (Ends the mess of always needing the orientation in the key for tagging the position!)

parking:right:condition = free

parking:right:condition:conditional = no_stopping @ (Mo-Fr 06:00-18:00) (not nice, but logical - maybe there is a nicer syntax)

parking:right:surface = sett

(Generally, I absolutely support a "sustainable reform" of the whole parking:lane scheme, as you suggest here, and not only a modification of the condition part!) --Supaplex030 (talk) 20:10, 2 December 2021 (UTC)

1. You will be allowed to use this. However after comments, I'm more concerned with removing parking:condition:*=*, than improving parking:lane:*=*.
2. The reason is I want to enable tagging of double parking (usually the restriction) outside a parking=street_side, bus_bay=*, and maybe shoulder=*. parking:lane:*=* would show this clearly.
3. As you may see, I was pretty stuck between keeping parking:lane:*=*, but risks redefining it (concern of User:Westnordost); or introduce something new as parking:side, without support at first.

---- Kovposch (talk) 03:42, 3 December 2021 (UTC)

Some great suggestions, but not really within the scope of the proposal. I will consider a complete overhaul after this more modest proposal, as all I wanted when I set out was to introduce conditionals. --Riiga (talk) 13:57, 7 January 2022 (UTC)

Resolved: Out of scope, but some great future ideas

Wrong syntax

Month-day conditions

Think it is invalid to specify days across months in opening_hours=* and thus *:conditional=*. See Talk:Key:opening_hours#First_half_of_month. ---- Kovposch (talk) 10:51, 30 November 2021 (UTC)

You are correct. I will add a notice about this in the proposal and not that this is a limitation of the opening_hours syntax (which is out of scope). --Riiga (talk) 12:56, 5 January 2022 (UTC)

I added valid syntax for those examples. --Riiga (talk) 14:25, 7 January 2022 (UTC)

Resolved: Valid syntax added

Time period

There is a conflict on the syntax on maxstay=*. You use "min" and "hours". Key:parking:lane uses "min" and "h". Key:maxstay uses "1 minute"/"minutes" and "1 hour"/"hours". ---- Kovposch (talk) 12:12, 30 November 2021 (UTC)

Resolved

This issue was resolved by aligning the examples to maxstay=* syntax. The existing Key:parking:lane examples were inconsistent with the definition there. If the intention is to change parking:lane=* to use maxstay=* syntax, then that correction should be called out in the summary, because mappers and software developers could've interpreted the page either way in the past. – Minh Nguyễn ^💬 03:25, 1 December 2021 (UTC)

Resolved

Implicit "no" parking

There are many situations where there is implicit "no" parking, depending on the legislation. For example this one here https://www.openstreetmap.org/way/395002921#map=19/53.59222/9.92917 , a connecting way in the middle of an intersection.

The way I understand the current version of the proposal now is that to tag the example correctly, I'd need to add:

1. parking:lane:right=no (no physical parking lane)
2. parking:condition:right=no (not a no-parking sign, but just "no")
3. parking:condition:right:reason=intersection (way is part of an intersection, so there is no parking lane)

This looks a bit overkill to me. Also, the parking:condition:right:reason=* tag often kind of duplicates other data. E.g. among other things, in most legislations, parking is forbidden on roads with a continuous center line (= no overtaking). Then, for example specifiying exactly the reason why there is an implicit no-parking restriction duplicates the in this case no_overtaking=yes. --Westnordost (talk) 21:12, 11 December 2021 (UTC)

@Westnordost: When I proposed to add parking:condition:reason=* to the proposal, I was primarily concerned with the various "reasons" that are signposted as part of restrictions, such as fire_lane, loading_zone, and street_cleaning. Riiga compiled a more extensive table presumably based on existing usage of that key. I'm not familiar enough with other countries' parking signs to know whether other values like turn_lane ever actually appear on signage. To me, the key shouldn't be a catch-all note=*-like field to justify a particular parking:condition=* tag; rather, it should help data consumers reconstruct the parking restriction as signposted. Otherwise, we start to get into mapping legislation, like splitting a road 15 feet (4.6 m) on either side of every fire hydrant to say that parking is disallowed solely due to the presence of a fire hydrant.

Your example internal intersection way obviously disallows parking, but there would be no sign or marking to that effect. Either the key should be omitted or there should be a generic value like none or implicit so that data consumers know not to display it to users.

 – Minh Nguyễn ^💬 07:49, 12 December 2021 (UTC)

@Westnordost: Implicit no parking would still be no parking (parking:lane:right=no + parking:condition:right=no_parking). Specifying a reason is optional. I will clarify that in the proposal. --Riiga (talk) 07:48, 14 December 2021 (UTC)

"parking:condition:right=no (not a no-parking sign, but just "no")" - that would be rather no_stopping, you cannot leave car there even for a short time (@Westnordost:) Mateusz Konieczny (talk) 13:10, 15 December 2021 (UTC)

Yes, for the intersection-example, it would be no-stopping. For other places, for example a turning circle, it may be a no-parking? Worse still, I read in some legislation I don't remember right now, that at a railway intersection, stopping is prohibited within 5m of it or so and parking is prohibited within 30m or so. So, when a common-sense situation leads to "no parking" or "no stopping" depends on the legislation and legislation does not only differ from region to region, it may change. So to put a parking:condition:right=no_parking or parking:condition:right=no_stopping in situations where "no" is implicit seems to be not a good idea as the interpretation of the legislation is baked into the map this way. Additionally, the mentioned values (no_parking / no_stopping) are kind of an indicator that an explicit sign or marking is present --Westnordost (talk) 13:48, 15 December 2021 (UTC)

I've added a "no" value to support this . --Riiga (talk) 14:03, 15 December 2021 (UTC)

Can you not use parking:lane:right=no + parking:condition:right:reason=intersection only to let your application decide on some default/implicit parking:condition:right=*? ---- Kovposch (talk) 14:09, 15 December 2021 (UTC)

@Kovposch: Do I understand you right that you are suggesting that depending on the value of parking:condition:right:reason=*, the application should decide automatically which parking:condition:right=* (no_parking/no_stopping) to set? This would require 1. that for every possible reason why parking is not possible, there is a defined value for parking:condition:right:reason=* (that can, no must be selected in the app and that 2. that the app must have the knowledge which reason implies which parking/standing/stopping restriction in every country. Just to collect this knowledge would be an impossible task. And in any case, I expect that parking lane information is recorded not only with the help of the app, so the addressed issue is valid regardless of the editor used. My primary concern is for the overkill of tags used to project a common implicit no-parking situation. Also, note my previous point that legislation may change - we do not want to bake legislation into the tagging but just what we see on the road. See also Key:parking:lane#Notes_on_evaluating_data for an (incomplete) list of implicit situations --Westnordost (talk) 12:43, 27 December 2021 (UTC)

My thought was based more on the presence of parking:lane:right=no, since that's what you raised at first. Certainly there may be a need for your "no" when there is a parking lane, but it will not be as common I wonder. ---- Kovposch (talk) 13:47, 27 December 2021 (UTC)

Still not sure if I understand. You mean, parking:condition:right=no could be omitted if parking:lane:right=no was tagged? --Westnordost (talk) 14:14, 27 December 2021 (UTC)

Resolved: Added 'no' value

Invert condition for better support

"free, but the parking is metered (ticket) from May to October during daytime" seems to be better stated as "paid, except following times"

This times someone parsing this only partially, without conditional expressions, will not end as "free parking" as value while it is paid for a typical visitor Mateusz Konieczny (talk) 11:48, 13 December 2021 (UTC)

It's up to the person tagging to decide which way to go. In this case, a larger part of time is free than paid, therefore it makes sense to tag like this (imho). --Riiga (talk) 21:14, 14 December 2021 (UTC)

That's how conditional restrictions work - you can specify it either way ("free unless..." or "prohibited unless..."). I think it is out of scope of this proposal to force that conditional restrictions (on parkings) may only be used one way. It's important that a surveyor can record the information as he can se it on-site. Some signs express "parking except at these hours", some signs express "no parking except at these hours". --Westnordost (talk) 12:46, 27 December 2021 (UTC)

Resolved: Either way is fine

Implicit no_stopping should be no_stopping, not no

parking:condition now has "no" with definition "There is no explicit signage that prohibits parking, standing or stopping, but some or all of these are not allowed, and it is not possible to distinguish the exact conditions."

Why implicit no_stopping should not be mapped as no_stopping? Mateusz Konieczny (talk) 17:17, 16 December 2021 (UTC)

An implicit rule that you know is correct can always be mapped as what it is, but I changed the wording slightly now. --Riiga (talk) 20:34, 16 December 2021 (UTC)

See also related topic Implicit "no" parking --Westnordost (talk) 12:50, 27 December 2021 (UTC)

Resolved: Updated wording

Affected: styles and presets

It might be useful to explore how presets and styles are affected and which will need updating. For JOSM there are the ParkingLanes preset and the ParkingLanes Map Paint Style. (I'm the last one to have changed the latter to add the separate value for 'parking:lane:*'.) If this proposal succeeds, updating these should probably be part of the after-proposal clean-up. --JeroenHoek (talk) 18:03, 18 December 2021 (UTC)

I think there would be no problem including well-established tags and its approved subtags within core presets. Major task it usually to find appropriate .svg icons. Some validator rules could be added, too, especially if values are deprecated. After the vote, just open (some) tickets requesting support. --Skyper (talk) 16:53, 26 December 2021 (UTC)

See https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Parking_lane_conditionals#Outreach Mateusz Konieczny (talk) 18:45, 18 December 2021 (UTC)

I fully agree and am willing to help out with updating them as I use those JOSM presets/styles quite frequently. --Riiga (talk) 20:58, 18 December 2021 (UTC)

Let me know if you run into any problems with the Map Paint Style or need a hand. I don't know what is needed there (I think, at least no_standing needs handling), but it shouldn't be too hard to update (I hope). --JeroenHoek (talk) 13:01, 19 December 2021 (UTC)

I've now updated the preset and paint style. I'm not well-versed in the preset syntax to support conditions for different vehicles yet though, so that was left out. --Riiga (talk) 17:18, 22 January 2022 (UTC)

Resolved: If it looks like the proposal will pass during voting, I will work on updating these Riiga (talk) 12:56, 5 January 2022 (UTC)

limited parking time, without disc

How time limited parking, without required disc, would be tagged? Some example would be nice. Mateusz Konieczny (talk) 18:46, 18 December 2021 (UTC)

Kiss and ride example with time limit: https://commons.wikimedia.org/wiki/File:Vokovice,_Evropsk%C3%A1,_N%C3%A1dra%C5%BE%C3%AD_Veleslav%C3%ADn,_K%2BR_a_tramvajov%C3%A1_zast%C3%A1vka.jpg https://commons.wikimedia.org/wiki/File:Prosek,_Proseck%C3%A1,_zast%C3%A1vka_Prosek,_Kiss_and_Ride.jpg (added. feel free to remove/edit)

longer time limit https://commons.wikimedia.org/wiki/File:Radot%C3%ADn,_n%C3%A1m%C4%9Bst%C3%AD_Osvoboditel%C5%AF,_Karlick%C3%A1_(2014).jpg

Kiss and ride without explicit time limit: https://commons.wikimedia.org/wiki/File:Kiss_%2B_Ride_sign,_Bethesdaziekenhuis_Hoogeveen_(2020)_01.jpg

With no_parking sign https://commons.wikimedia.org/wiki/File:Opatov,_Kiss_and_Ride.jpg

I have not found image for long stay (3 hours, 24 hours)

Mateusz Konieczny (talk) 18:52, 18 December 2021 (UTC)

I would map it as regular parking with a time limit unless local legislation is clear there are additional restrictions. --Riiga (talk) 22:52, 18 December 2021 (UTC)

Resolved: Examples exist in proposal

Residents

How to distinguish cases

• only residents may park (residents)
• only residents may park and there are additionally time lits/fees/etc for them (residents + ???)
• everyone may park, residents have extreme fee reduction (payment for month costs as much as 5h of parking for nonresident) (ticket + ???)

Mateusz Konieczny (talk) 21:07, 18 December 2021 (UTC)

Or is it out of scope of this proposal? Mateusz Konieczny (talk) 21:24, 18 December 2021 (UTC)

The first cases are easy:

• parking:condition:right=residents
• parking:condition:right=residents + parking:condition:right:maxstay=2 hours

The third one is also quite straight-forward, but doesn't say anything about how much the fee is or what is required for permit A that residents need. This is out of scope of this proposal and isnt't covered by the current tagging either. There are some similar examples in the complex examples section.

• parking:condition:right=ticket; residents + parking:condition:right:residents=A

--Riiga (talk) 22:48, 18 December 2021 (UTC)

Resolved: Explanation given, some out of scope

Parking paid online

How to tag case where one pays for parking, has no physical ticket and it is verified based on car plate number? I am unable to give example but this is quite obvious idea that definitely exists somewhere (or soon will be existing). Still ticket? Mateusz Konieczny (talk) 21:09, 18 December 2021 (UTC)

That's how most street parking works here these days, but it isn't any different from regular ticket parking. You still pay a fee at the machine or an app and get a "ticket". Enforcement (e.g. ticket in window vs licence plate) isn't within scope of this proposal. --Riiga (talk) 22:56, 18 December 2021 (UTC)

Maybe clarify that in the description? I.e. "ticket" parking seems to be understood generally as "fee=yes" parking, regardless of how the fee is paid? --Westnordost (talk) 12:53, 27 December 2021 (UTC)

Indeed. I've added a clarification. --Riiga (talk) 18:01, 27 December 2021 (UTC)

Resolved

Signed vs actual

There are places where there is a signed parallel parking, but actual parking used by car drivers is perpendicular or diagonal. Which one should be tagged? Mateusz Konieczny (talk) 21:23, 18 December 2021 (UTC)

That is up to the mapper to decide (preferably by following good practice about ground truth). --Riiga (talk) 23:03, 18 December 2021 (UTC)

Resolved: Out of scope, follow OSM practice

Before/after

It would be nice to have for each example infor how it is tagged also before this proposal Mateusz Konieczny (talk) 21:32, 18 December 2021 (UTC)

There is for some of the examples in the complex example section. I've focused on tagging the new way rather than try to work out the old syntax for lots of examples. If there is demand for showing both ways I'm open to adding that to some of the simple examples too. --Riiga (talk) 23:04, 18 December 2021 (UTC)

Resolved: There seems to be no demand for it as no one else has commented

Could you please add one (perhaps tricky) example?

I was fighting around since some time with the following combination of traffic signs and how it should/could be tagged. I think it's a tricky example and worth to list it. It's quite common in the city where I live (in Germany) and it is used both for parking lanes of a road and also on separated parking areas (tagged with amenity=parking, parking=surface).

• 

  Traffic sign combination
• 

  Another real world example
• 

  Or also in this order

Perhaps it's not tricky for you ... The special case of this traffic sign combination is, that there are two different conditions which are valid at the same time (during the given time interval): no_parking and residents parking (parking without restrictions for residents). In your current examples, I've only found cases where 2 time intervals don't overlap, which is much easier. And in this case, the second value@condition pair should not overweight/beat the first one, so you cannot simply write: no_parking @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00); residents @ (Mo-Fr 08:00-20:00; Sa 08:00-16:00), because the 2nd pair would overwrite the first pair and it would be residents parking only at the given time interval ... (See Conditional_restrictions#Evaluation_of_conflicting_restrictions). This conflict can only be solved by doing it in another way with the addition of an "AND residents" statement (see my proposed tagging below and Conditional_restrictions#Combined_conditions:_AND). At least I see no other way.

And maybe cases like this will make it difficult for the "average" mapper to tag it correctly ... and it's not really a simplification. And maybe it violates a basic rule of OpenStreetMap: "Have fun!" I also didn't expect that this traffic sign would be so hard to tag when I saw it the first time. I could imagine that it is easy to make mistakes here – and a really good system would help to avoid that - I miss that a bit with the current proposal, and maybe it is really difficult to achieve (great simplicity and clarity combined with powerful possibilities). I don't know how to solve this problem without changes to to whole conditional restriction systematics ... Or do you have any idea?

I wrote a longer posting one year ago on the talk page of parking=street side (perhaps not the best place, it only was my first contact with this sign – on a amenity=parking, parking=street_side). You can find a longer summary of my conclusions on the talk page: Talk:Tag:parking=street_side#A_Summary where I also explained the meaning of this traffic sign combination (with its pitfalls). In short terms this is the meaning of this combination of signs (for the first image):

• The condition “no_parking” is valid Mo-Fr 08:00-20:00; Sa 08:00-16:00 – otherwise parking is free (so default is free parking!)
• Residents with permit “I1” are allowed to park there at every time.

Perhaps not everyone would understand it at once ... I was a little confused at first sight too (mainly because of the order of the additional white traffic signs in the first and second photos - it is clearer to me in the third photo, but the order of the additional white traffic signs is really irrelevant, it must not be read "top down"!).

Here is the complete tagging I would use according to your proposal for the first image above (green = the important part; assumption: parking lane on the right side with a marked parking space):

parking:lane:right=parallel
parking:lane:right:parallel=painted_area_only (note: for the 2nd image above "street_side" would fit better)

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

parking:condition:right:residents=I1

Side note: "free" for "residents" doesn't mean they don't have to pay anything for their parking permit - in fact, they pay a monthly or yearly amount. But that should be implied by the term "residents" in the concept of parking (and perhaps has to be mentioned in the Wiki). However, this could be yet another stumbling block and lead to confusion for one or the other in order to tag it correctly.

My proposal of tagging it with the old "traditional" scheme (double values for the condition are allowed there – which makes it more simple to tag, perhaps not so simple for data consumers? – but are we tagging for data consumers?):

parking:lane:right=parallel 
parking:lane:right:parallel=painted_area_only (note: for the 2nd image above "street_side" would fit better)

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

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

I hope, I am not completely wrong. For more explanations and notes see my Summary on the talk page of parking=street_side, where I have also tried to explain reasonably clearly why I do not consider it to be a simple case and why I do not see great opportunities for a simplification in the conditional expression. And perhaps it's also an example where the old scheme has a small advantage of simplicity and readability (?) ...

And I would also consider to list other, perhaps even more complex cases or to disuss it here. Perhaps something like mentioned here: Talk:Key:parking:lane#An_abundance_of_tags. Because I think a good system shows in how the really complex cases ("worst cases") are solved. I would appreciate this a lot before a voting is started. --Goodidea (talk) 05:36, 19 December 2021 (UTC)

I see your dilemma, tagging this is not as intuitive as other parking conditions. I think your assumption is correct regarding the tagging. I added an example to the complex sign section based on this. --Riiga (talk) 09:22, 19 December 2021 (UTC)

I formatted this in table, as in User:Kovposch/Proposed_features/Parking_lane_conditionals#Newer.

Example

Sign	Existing (unaffected vs affected)	Proposed (unchanged vs changed)
	parking:lane:right=parallel parking:lane:right:parallel=painted_area_only (note: for the 2nd image above "street_side" would fit better) parking:condition:right=no_parking;residents parking:condition:right:time_interval=Mo-Fr 08:00-20:00; Sa 08:00-16:00 parking:condition:right:residents=I1 parking:condition:right:default=free	parking:lane:right=parallel parking:lane:right:parallel=painted_area_only parking:condition:right=free (Be default this is a free parking.) parking:condition:right:conditional=no_parking @ (Mo-Fr 08:00-20:00, Sa 08:00-16:00); free @ ((Mo-Fr 08:00-20:00, Sa 08:00-16:00) AND residents) (No parking at certain times, however this does not apply to residents. Complex syntax required to not override the default free parking with residents only parking.) parking:condition:right:residents=I1 (Residents need permit "I1".)

---- Kovposch (talk) 11:38, 19 December 2021 (UTC)

Resolved: Example added

taxi-only lane

What about parking lane that can be used only by taxi cars? Is it intended to be somehow taggable or is it out of scope? Mateusz Konieczny (talk) 16:40, 6 January 2022 (UTC)

It is covered by the section Type of vehicles. E.g. parking:condition:both:taxi=free (and also parking:condition:both=no_parking if you want to be explicit about other vehicles not being allowed to park).

Resolved: It is supported