Proposal talk:Parking conditions on separately mapped parking areas

The difficult parts

I tried to write up User:Kovposch/Proposed features/Parking lane conditionals before to show what replacing parking:condition=* may look like, (surprised to see it mentioned) and expand on the functionalities, eg untangling stopping and parking while separating no and other restrictions (that you haven't added yet?), standing as waiting, and parking by apps. Several issues I encountered are found here.

1. Using an exact definition by duration maxstay=3 minutes to replace parking:condition=no_parking is not possible in most if not vast majority of places, I assume. Laws usually don't define this by numbers.
   1. I haven't updated my examples, but the reason I changed to *:waiting=* *:stopping=* instead of *:no_standing=* and *:no_stopping=* is to simplify the syntax, align with parking:access=*, and allow better tagging. Eg parking:access=private + parking:waiting:taxi=yes + parking:stopping=no overriding each other similar to different access=* + motor_vehicle=* + foot=* modes - vs - Something totally difficult to express with parking:condition=no_*. (The parking:*=* prefix is only a placeholder. Fundamentally parking:waiting=* and parking:stopping=* looks somewhat silly.)
2. The requirement of having a parking:condition=disc (although it might be a national default law, norm, or expectation) haven't been added.
   1. I had thought to make authentication:*=* and access:for=* optional additions to fee=* and access=*. Unfortunately, parking disc is very much a necessity, compared to carrying the paper receipt or license to prove your payment or identity. Therefore there is a greater need in authentication:disc=* or equivalent, to preserve the information.
3. While parking:residents=60 is at least better than the parking:condition=* mess (eg Talk:Key:parking:condition#Multiple_conditional_parking_conditions), it looks too much like capacity:residents=60 or something else.
   1. I brought up zone:parking=* before that can be used for all sorts of zones, including those in schools; not only residents or city. However, others may have suggested they can be different in some cases.
   2. I wondered whether parking:zone=* or zone:parking=* is more appropriate, since zone:*=* is implemented by zone:traffic=* and zone:maxspeed=*. Unfortunately the latter has a very specific country code prefixed format.
   3. Another potential use for eg residents=* and customers=* is to show who from where are allowed to park when there are no zones/permits, only specific building/estate/shop. This resembles permit=* in access=permit from Proposed_features/access=permit#Permit_contact_information:_the_permit:*_keys, to supplement access=customers and access=private + access:for=resident.

I should also explain the my motivation behind moving parking:lane:*=separate and parking:lane:*:*=street_side to parking:side is to handle "double parking" situations, aside from making parking:lane=* consistent with parking=lane. Eg parking on the carriageway outside a parking=street_side is allowed at certain times; or parking in a parking=street_side is allowed on a parking:condition:*=no_stopping + parking:condition:*:reason=fire_lane. This can be solved with separating into eg parking:*=street_side + parking:lane:*:access=*.

I'm not sure car sharing or rental spots (eg Times car renting in Japan) needs to be dealt with here.

Something, perhaps extra, I support here is making parking=lane a standard. I assume there are more than a few parking=surface out there that are actually parking=street_side or parking=lane.

--- Kovposch (talk) 20:45, 2 September 2022 (UTC)

Sorry for the late answer. I wanted to keep the discussion on the tagging list for now, as this page was only intended to illustrate the different variants and not to elaborate on them in detail. So let's rather talk about the details elsewhere once one of the variants is taken further.

To be honest, I am no longer convinced that the benefit of a complete revision of the parking:lane scheme is appropriate to the impact that this step would have. Unfortunately, the scheme is not ideal, but its weaknesses can be handled pragmatically and can be solved by specific solutions. --Supaplex030 (talk) 07:57, 5 September 2022 (UTC)

I don't like emails. Just leaving this here to explain the context and gaps. --- Kovposch (talk) 03:16, 6 September 2022 (UTC)

Parking lanes as ways

I'm not sure if this completely fits into the discussion here, but would tagging parking lanes as linear way cause any problems? Parking lanes on streets are inherently linear, and tagging them separately avoids the mess of needing to split the street every time the condition changes. --Popball (talk) 08:36, 8 September 2022 (UTC)

You mean: A way with parking:lane=*-Tags, but without highway=*? I don't think this will work because the interpretation of this key is usually linked to a road segment. (You would have to propose a "new" scheme for that and it would be a different way of working). But there is nothing wrong in splitting a road segment imho - we do that for all kinds of other things. --Supaplex030 (talk) 22:08, 8 September 2022 (UTC)

error in the assertion "access=* tagging cannot distinguish between no_stopping and no_parking without establishing a new tag"

no_parking (= only stopping) : maxstay=load-unload
no_stopping : access=* but how can we have a separately mapped parking areas that doesn't allow to stop ? that isn't a parkinng anymore
Marc marc (talk) 11:22, 12 October 2022 (UTC)

no_stopping can also be a temporary condition, therefore it might be relevant anyway. access=no and/or maxstay=load-unload could be fine, but as we have our new discussion here for "regular" parking lanes/restrictions, I have thought of a notation like access=no + access:stopping=yes. This notation could also used for statements like access=private + access:residents=yes. User:Kovposch similar proposed parking:lane:*:stopping=*. --Supaplex030 (talk) 12:38, 12 October 2022 (UTC)