User talk:Kovposch/Proposed features/Parking lane conditionals

Could you please add one (perhaps tricky) example?

I find your counter-proposal interesting ... it's always worth looking at a different approach ... And it's good that you took the trouble to create this table - quite a bit of work, certainly!

Could you maybe add a (maybe?) tricky example? (Which might not look so tricky at first glance.) I posted it on the talk page of the main proposal. It concerns this combination of traffic signs:

And one remark to this example in your table:

IMO, the code for the "Proposed Tagging" (3rd column) is not sufficient:

parking:condition:right=free; residents
parking:condition:right:conditional=ticket @ (Mo-Fr 09:00-19:00, Sa 09:00-16:00)

The second conditional tag would mean that at the given time interval, ONLY parking with a ticket is possible (no free parking for residents). At least I would read it like that. Or am I wrong?

And your proposed counter-proposal tagging is really very complicated and hard to read and understand, e.g. parking:lane:right:fee:conditional=no @ (Mo-Sa 00:00-09:00,19:00-24:00, Sa 16:00-19:00; private) – what exactly should it mean? That out of the given time interval of the sign (side note: not optimal if you have to determine that first – another source of errors!) there is no fee OR (at any time) if "private"? So you imply that residents are "private"? I think it's difficult with the term "resident", because it's not defined in the "access value space", but only in the parking context (as far as I know). To simply equate it with "private" seems too easy to me. And too hard to understand/to read. Because it's still a public parking, the residents only have a special permit to park there at any time. (And I know some discussions about that ...) But it doesn't change the parking to a private parking. I would not mix these 2 terms. It only leads to confusion ... I would prefer to have only the term "residents" in the conditions (in accordance with the term on the traffic sign), with the definition of the old scheme (or to precise this definition if neccessary). It would make it easier to understand and to tag (I try to imagine an “average” mapper - if someone like that should even dare to approach this area – but that's another question). I fear that there will be many errors in practice if the system is too complicated to use. But that's the gold standard of a good system: to be easy AND powerful. Not sure if it can be achieved here, but it should be kept as simple as possible (above all in the application and understanding of the conditional statements).

However, I have to admit that I have not yet carefully read your full counter-proposal (e.g. the "Management" section). At first glance, it seems very complex and powerful, but perhaps too complex to be applied correctly by everyone? Only a first impression ... --Goodidea (talk) 06:42, 19 December 2021 (UTC)

1. Ok let me work on this. Excuse me as I don't know the language. I can only adapt the tags given by you.
2. Yes, I agree. That's why I already tagged the example according to your correct interpretation.
3. It is made to more elaborate. I tried to break the values down, to avoid more mess as complicated as parking:condition:right:conditional=ticket "Röd biljett" @ (Mo-Fr 08:00-20:00, Sa 08:00-15:00). Some parts are not 100% necessary at first, especially parking:lane:*:authentication:*=*
   1. parking:condition:*=disc is how drivers show they comply with the maxstay=*.
   2. parking:condition:*=ticket is mainly about fee=yes.
   3. parking:condition:*=resident is basically access=private on its own. I actually don't agree with using parking:condition:*=private to mean each resident is assigned to a specific spot. This is a finer detail about individual amenity=parking_space.
4. *:conditional=* @ (private) was mentioned in https://wiki.openstreetmap.org/w/index.php?oldid=821276#Condition. "Resident" is usually access=private for other features.

Another reason why there are more tags: I chose to use parking:lane:*:no_*=yes following authentication:*=yes to allow more flexible combinations and shorter values. ---- Kovposch (talk) 11:08, 19 December 2021 (UTC)

Did User:Kovposch/Proposed_features/Parking_lane_conditionals#Newer. You can see breaking the values up avoids specifying the condition again to not overwrite the default. ---- Kovposch (talk) 11:49, 19 December 2021 (UTC)

I marked all the secondary and tertiary tags more clearly with italics. ---- Kovposch (talk) 11:51, 19 December 2021 (UTC)