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 (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.
parking:condition=*
may look like,
- Using an exact definition by duration
maxstay=3 minutes
to replaceparking:condition=no_parking
is not possible in most if not vast majority of places, I assume. Laws usually don't define this by numbers.- 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 withparking:access=*
, and allow better tagging. Egparking:access=private
+parking:waiting:taxi=yes
+parking:stopping=no
overriding each other similar to differentaccess=*
+motor_vehicle=*
+foot=*
modes - vs - Something totally difficult to express withparking:condition=no_*
. (Theparking:*=*
prefix is only a placeholder. Fundamentallyparking:waiting=*
andparking:stopping=*
looks somewhat silly.)
- I haven't updated my examples, but the reason I changed to
- The requirement of having a
parking:condition=disc
(although it might be a national default law, norm, or expectation) haven't been added.- I had thought to make
authentication:*=*
andaccess:for=*
optional additions tofee=*
andaccess=*
. 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 inauthentication:disc=*
or equivalent, to preserve the information.
- I had thought to make
- While
parking:residents=60
is at least better than theparking:condition=*
mess (eg Talk:Key:parking:condition#Multiple_conditional_parking_conditions), it looks too much likecapacity:residents=60
or something else.- 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. - I wondered whether
parking:zone=*
orzone:parking=*
is more appropriate, sincezone:*=*
is implemented byzone:traffic=*
andzone:maxspeed=*
. Unfortunately the latter has a very specific country code prefixedformat.
- Another potential use for eg
residents=*
andcustomers=*
is to show who from where are allowed to park when there are no zones/permits, only specific building/estate/shop. This resemblespermit=*
inaccess=permit
from Proposed_features/access=permit#Permit_contact_information:_the_permit:*_keys, to supplementaccess=customers
andaccess=private
+access:for=resident
.
- I brought up
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)
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 withouthighway=*
? 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/ormaxstay=load-unload
could be fine, but as we have our new discussion here for "regular" parking lanes/restrictions, I have thought of a notation likeaccess=no
+access:stopping=yes
. This notation could also used for statements likeaccess=private
+access:residents=yes
. User:Kovposch similar proposedparking:lane:*:stopping=*
. --Supaplex030 (talk) 12:38, 12 October 2022 (UTC)