|definition = Introducing conditionals for parking lanes and deprecating the use of certain older tags.<!-- A short, clear definition of the feature or property which the new tag represents -->
|definition = Introducing conditionals for parking lanes and deprecating the use of certain older tags.<!-- A short, clear definition of the feature or property which the new tag represents -->
|taginfo = no
|appearance = <!-- A possible rendering, if relevant - optional -->
|appearance = <!-- A possible rendering, if relevant - optional -->
<!-- A short statement of what you propose, including a list of what tag(s) are being proposed to be added, changed, or deprecated -->
<!-- A short statement of what you propose, including a list of what tag(s) are being proposed to be added, changed, or deprecated -->
<!-- Which Database Elements (nodes, ways, areas, relations) each of the tags can be used on could be included here or under the Tagging heading, or both. -->
<!-- Which Database Elements (nodes, ways, areas, relations) each of the tags can be used on could be included here or under the Tagging heading, or both. -->
====In a nutshell====
==== In a nutshell ====
# Use the [[Conditional_restrictions|conditional restrictions]] scheme for conditional parking restrictions.
# Use the [[Conditional_restrictions|conditional restrictions]] scheme for conditional parking restrictions.
# Cleanly separate tagging of physical alignment ({{tag|parking:lane}}) and condition to park ({{tag|parking:condition}}).
# Cleanly separate tagging of physical alignment ({{tag|parking:lane}}) and condition to park ({{tag|parking:condition}}).
Line 27:
Line 28:
# Parking positions remain unchanged. [[Key:parking:lane#Parking_position|See the current wiki page for this]].
# Parking positions remain unchanged. [[Key:parking:lane#Parking_position|See the current wiki page for this]].
====Affected tags====
==== Affected tags ====
* Introduce {{tag|parking:condition:*:conditional}} following the [[Conditional_restrictions|conditional restrictions]] scheme.
* Introduce {{tag|parking:condition:*:conditional}} following the [[Conditional_restrictions|conditional restrictions]] scheme.
* Adopt the current {{tag|maxstay}} syntax for {{tag|parking:condition:*:maxstay}}, including conditional restrictions.
* Adopt the current {{tag|maxstay}} syntax for {{tag|parking:condition:*:maxstay}}, including conditional restrictions.
Line 37:
Line 37:
* Document {{tag|parking:lane||yes}} and refine {{tag|parking:lane||no}}.
* Document {{tag|parking:lane||yes}} and refine {{tag|parking:lane||no}}.
==Rationale==
== Rationale ==
<!-- Explanation of why the proposal is needed, and why you chose the specific key and value of the tag. Compare with similar tags or previous proposals, if relevant. Consider significance and potential uses of the data.-->
<!-- Explanation of why the proposal is needed, and why you chose the specific key and value of the tag. Compare with similar tags or previous proposals, if relevant. Consider significance and potential uses of the data.-->
<!-- Keep the tag short while still being logical and descriptive enough to need little explanation. Avoid tag names which might cause confusion with a different tag. British English terms are preferred, when possible -->
<!-- Keep the tag short while still being logical and descriptive enough to need little explanation. Avoid tag names which might cause confusion with a different tag. British English terms are preferred, when possible -->
Line 43:
Line 43:
This proposal aims to introduce support for conditional restrictions to alleviate this.
This proposal aims to introduce support for conditional restrictions to alleviate this.
The {{TagKey/exists|parking:lane}} tag is used to describe the physical properties of the road. This means space properties.
The {{TagKey/exists|parking:lane}} tag is used to describe the physical properties of the road. This means space properties.
Line 155:
Line 154:
=== Parking conditions ===
=== Parking conditions ===
The {{TagKey/exists|parking:condition}} tag describes the legal properties of the parking space.<br/><br/><br/><br/>
The {{TagKey/exists|parking:condition}} tag describes the legal properties of the parking space.<br/><br/><br/><br/>
Line 258:
Line 256:
Use {{k|parking:condition:{{tvar|side}}:maxstay}} to specify maximum stay limits; especially applicable for {{value|disc}} parking. It should take values precisely as per {{TagKey/exists|maxstay}}.
Use {{k|parking:condition:{{tvar|side}}:maxstay}} to specify maximum stay limits; especially applicable for {{value|disc}} parking. It should take values precisely as per {{TagKey/exists|maxstay}}.
The {{TagKey/exists|parking:condition}} tag describes the legal properties of the parking space. This tag is also the default value when used in combination with conditonals.
The {{TagKey/exists|parking:condition}} tag describes the legal properties of the parking space. This tag is also the default value when used in combination with conditonals.
Line 326:
Line 324:
<br />
<br />
=== Time dependence (conditional) ===
=== Time dependence (conditional) ===
On many occasions, parking conditions are time limited, especially for {{value|disc}} and {{value|residents}} parking. This can be specified by using the conditional tag: {{k|parking:condition:{{tvar|side}}:conditional}}. It uses the same syntax for values as [[Conditional restrictions| conditonal restrictions]].
On many occasions, parking conditions are time limited, especially for {{value|disc}} and {{value|residents}} parking. This can be specified by using the conditional tag: {{k|parking:condition:{{tvar|side}}:conditional}}. It uses the same syntax for values as [[Conditional restrictions| conditonal restrictions]].
<!-- Examples of what elements should be tagged: real-world images, openstreetmap.org screenshots, links to OpenStreetMap elements that use the proposed tagging. -->
<!-- Examples of what elements should be tagged: real-world images, openstreetmap.org screenshots, links to OpenStreetMap elements that use the proposed tagging. -->
All examples below assume a parking lane on the right side of the road.
All examples below assume a parking lane on the right side of the road.
Line 501:
Line 499:
|}
|}
===Complex signage===
=== Complex signage ===
(note "expand" toward the right side)
(note "expand" toward the right side)
<div class="mw-collapsible mw-collapsed">
<div class="mw-collapsible mw-collapsed">
Line 691:
Line 689:
<div style="clear:both"></div>
<div style="clear:both"></div>
===Other signage===
=== Other signage ===
(note "expand" toward the right side)
(note "expand" toward the right side)
<div class="mw-collapsible mw-collapsed">
<div class="mw-collapsible mw-collapsed">
Line 747:
Line 745:
<div style="clear:both"></div>
<div style="clear:both"></div>
==Features/Pages affected==
== Features/Pages affected ==
<!-- List of wiki pages that would be edited if the proposal is approved -->
<!-- List of wiki pages that would be edited if the proposal is approved -->
* [[Key:parking:lane]]
* [[Key:parking:lane]]
Line 759:
Line 757:
<!-- Links to mailing lists, other forums where this proposal has been discussed... -->
<!-- Links to mailing lists, other forums where this proposal has been discussed... -->
==Comments==
== Comments ==
<!-- There must be at least 2 weeks set aside for comment on the proposal. Do not go to a vote without addressing the comments and fixing any problems with the proposal. The wiki talk page is used for comments, it is linked from the proposal page for those unfamiliar with wikis. -->
<!-- There must be at least 2 weeks set aside for comment on the proposal. Do not go to a vote without addressing the comments and fixing any problems with the proposal. The wiki talk page is used for comments, it is linked from the proposal page for those unfamiliar with wikis. -->
Revision as of 17:58, 15 March 2022
The Feature Page for the approved proposal Parking lane conditionals is located at Key:parking:lane
The current proposal from 2012 uses non-standard tags like time_interval to specify a time range and is not very flexible with handling parking lanes that have different conditions throughout the day. This means that many parking restriction signs cannot currently be mapped in OpenStreetMap.
This proposal aims to introduce support for conditional restrictions to alleviate this.
Tagging
Current practice
Proposal
Parking spaces
The parking:lane tag is used to describe the "physical" properties of the road. This means space properties.
Please note that the latter three are considered "physical" tags, this means: parking is not possible, so no parking:condition tag (see below) is required in those cases.
Key
Value
Description
parking:lane:side
parallel
Parking parallel to the road.
diagonal
Diagonal parking. Also known as angle parking or echelon parking.
perpendicular
Perpendicular parking, i.e. at a 90° angle to the road so that the the front or back of the vehicle points straight towards the road center line.
marked
Only some parking spaces are available, these are individually marked.
Note that there is an obvious overlap with parking:lane:side:type=painted_area_only (see below). As opposed to this tag, the latter allows to also specify the orientation.
no_parking
No regular road user is allowed to park on the road. They may stop, though, to for example pick up/drop off a passenger, unload cargo or for other reasons as laid out in the local legislation.
no_stopping
No regular road user is allowed to stop their vehicle, except when traffic conditions require them to do so. In addition this also implies that neither standing nor parking is allowed.
no_standing
No regular road user is allowed to park on the road. They may stop, as long as they remain in the vehicle, to for example pick up/drop off a passenger or for other reasons as laid out in the local legislation. This restriction is known and explicitly signed most notably in the United States but unknown in most other legislations.
fire_lane
In countries where such exist, an extra sign indicating a lane that must be kept clear for possible fire engines, or other emergency vehicles: in a sense equal to, but stricter than a no_stopping.
no
It is not distinguishing between no_stopping , no_parking and no_standing, it may make sense to use in some cases.
separate
Parking facilities are mapped explicitly (usually with parking=street_side).
Parking spaces
The parking:lane tag is used to describe the physical properties of the road. This means space properties.
Please note that this tag only describes the space properties, not the actual condition. A parking:condition tag is required in those cases. See below.
Key
Value
Description
parking:lane:side
parallel
There is parking space. Vehicles must park parallel to the road.
diagonal
There is parking space. Vehicles must park diagonally. Also known as angle parking or echelon parking.
perpendicular
There is parking space. Vehicles must park at a 90° angle so that the front or back of the vehicle is pointing straight towards the road center line.
marked
There is parking space, with only some parking spaces available that are individually marked.
no_parking
No regular road user is allowed to park on the road. They may stop, though, to for example pick up/drop off a passenger, unload cargo or for other reasons as laid out in the local legislation.
no_stopping
No regular road user is allowed to stop their vehicle, except when traffic conditions require them to do so. In addition this also implies parking is not allowed.
fire_lane
In countries where such exist, a sign indicating a lane that must be kept clear for possible fire engines, or other emergency vehicles.
no
There is no parking space.
yes
There is some type of parking space. If possible, be more specific.
separate
Parking facilities are mapped explicitly as another object (usually with parking=street_side).
Current practice
Proposal
Parking conditions
The parking:condition tag describes the legal properties of the parking space.
Key
Value
Description
parking:lane:side
parallel, diagonal, perpendicular.
For other types, the condition tag makes little sense. For separate, the conditions should be tagged on the separately mapped amenity=parking instead.
parking:condition:side
free
No additional information is required.
ticket
To be discussed. Maybe add a parking:condition:side:fee_per_hour=1 € tag.
disc
Add a parking:condition:side:maxstay=2 h tag. This means you may park here for up to 2 hours.
residents
Add a parking:condition:side:residents=A tag. This means "parking only for residents with permission A" (With A being the identification of the permission). A parking permit on a car windshield.
customers
No additional information is required. This means you are only allowed to park here if you are a customer of the shop that owns this parking space (or a visitor of a site, or a guest of a hotel, or similar).
private
No additional information is required. This means you are only allowed to park here if you rented the parking space (or have a permission of the owner).
disabled
Usually, this parking space is not about free or paid. It requires being related to disabled persons or to have such permission.
no_parking
In combination with time dependences (see examples below), no_parking may also be used as a condition.
no_stopping
In combination with time dependences (see examples below), no_stopping may also be used as a condition.
Type of vehicles
If the condition is valid only for some vehicles, use
Area based residential permits often carry some sort of letter or code identifying the area wherein they are valid; this can be recorded using the key: parking:condition:side:residents.
When parking is requires a ticket or a residential permit, the following combination is often used:
In many occasions, parking conditions are time limited, especially for disc and residents parking. This can be specified by using the following tag: parking:condition:side:time_interval. Values specify both days and times, plus it can be multiplied. It uses the same syntax for values as opening_hours.
Key
Value
Description
parking:condition:side:time_interval
<opening_hours>
A date and time specification as per opening_hours, such as Mo-Fr 12:00-14:00
The format is complicated to define technically, but easy to understand by examples:
12:00-14:00 means: "every day from 12:00 until 14:00".
Mo-Fr 00:00-24:00 means: "every weekday (except Saturday and Sunday)".
Su 20:00-06:00 means: "Sunday night from 20:00 until (Monday) 06:00".
Intervals may be joined by semicolons with optional whitespace:
Mo-Fr 09:00-20:00; Sa-Su 09:00-14:00 means: "Weekdays 9 to 20, and weekends 9 to 14".
With multiple differing conditions
In the simplest case you have free parking at night, and ticket parking at day on workdays; for example,
In this example, we couldn't use plain parking:lane:right=no_stopping, as parking is allowed at some times of the day.
Maximum stay
Use parking:condition:side:maxstay to specify maximum stay limits; especially applicable for disc parking. It should take values precisely as per maxstay.
Parking conditions
The parking:condition tag describes the legal properties of the parking space. This tag is also the default value when used in combination with conditonals.
Note: Do not confuse condition with conditional. The former is part of the parking:condition tag while the latter is for conditional restrictions and only added at the end of a key.
Key
Value
Description
parking:condition:side
free
The parking is free to use. If there is a time limit, add a parking:condition:side:maxstay=* tag
ticket
A ticket is required. This can be a physical ticket, electronic ticket via SMS or through an app, etc. If possible add the location of the ticket machine(s) nearby using the amenity=vending_machine + vending=parking_tickets tags.
disc
A parking disc is required. Add a parking:condition:side:maxstay=2 hours tag to describe the time limit, for example 2 hours.
residents
Add a parking:condition:side:residents=A tag. This means "parking only for residents with permission A" (With A being the identification of the permission). A parking permit on a car windshield.
customers
This means you are only allowed to park here if you are a customer of the shop that owns this parking space (or a visitor of a site, or a guest of a hotel, or similar). If additional restrictions apply, such as a time limit, add those.
private
No additional information is required. This means you are only allowed to park here if you rented the parking space (or have a permission of the owner).
disabled
Usually, this parking space is not about free or paid. It requires being related to disabled persons or to have such permission.
no_parking
No regular road user is allowed to park on the road. They may stop, though, to for example pick up/drop off a passenger, unload cargo or for other reasons as laid out in the local legislation.
no_standing
No regular road user is allowed to park on the road. They may stop, as long as they remain in the vehicle, to for example pick up/drop off a passenger or for other reasons as laid out in the local legislation.
no_stopping
No regular road user is allowed to stop their vehicle, except when traffic conditions require them to do so. In addition this also implies that neither standing nor parking is allowed.
no
There is no explicit signage that prohibits parking, standing or stopping, but some of these are not allowed, and it is not possible to distinguish the exact conditions.
Type of vehicles
If the condition is valid only for some vehicles, use
Area based residential permits often carry some sort of letter or code identifying the area wherein they are valid; this can be recorded using the key: parking:condition:side:residents.
When parking requires either a ticket or a residential permit (named "A" in this example), specify both conditions in the main value and further describe the residential permit in another tag that is specific to that condition
On many occasions, parking conditions are time limited, especially for disc and residents parking. This can be specified by using the conditional tag: parking:condition:side:conditional. It uses the same syntax for values as conditonal restrictions.
In the simplest case you have free parking at night, and ticket parking at day on workdays; for example,
Note: The use of additional namespaces (:1, :2, etc.) is deprecated.
Maximum stay
Use parking:condition:side:maxstay to specify maximum stay limits; especially applicable for disc parking. It should take values precisely as per maxstay.
If this applies only part of the day, use parking:condition:side:maxstay:conditional.
Reasons for the condition (optional)
It is often useful to indicate why certain conditions apply. This allows telling a fire lane from a loading zone or an implicit condition (e.g. no parking near a crossing) from an explicit condition (no stopping sign on a busy throughfare). Use the parking:condition:side:reason tag to describe the reason for prohibitions in the condition when needed.
Note: Tagging this is optional. The list of reasons below is not a complete list, just a collection of the most common ones.
Key
Value
Description
parking:condition:side:reason
bus_stop
This is a bus stop, where according to local legislation, certain rules apply.
crossing
This is near a crossing, where according to local legislation, certain rules apply.
fire_lane
This is a fire lane that must be kept clear for possible fire engines, or other emergency vehicles.
junction
This is part of a junction and according to local legislation, certain rules apply.
loading_zone
This is a zone for loading and unloading of goods and/or passengers.
passenger_loading_zone
This is a zone for loading and unloading of passengers only, not goods.
priority_road
This is a priority road. According to local legislation certain rules apply.
street_cleaning
This is a street cleaning zone where vehicles intermittently may not be allowed to park, stand or stop. This includes snow removal.
turnaround
This is a zone for turning a vehicle around, typically at a cul-de-sac.
turn_lane
This is part of a turn lane and according to local legislation, certain rules apply.
Examples
Simple signage
All examples below assume a parking lane on the right side of the road.
parking:condition:right=free (When the conditional restriction is not in place, this is a free parking.) parking:condition:right:conditional=no_stopping @ (Mo-Fr 08:00-17:00, Sa 08:00-14:00, Su 08:00-13:00) (However, stopping is prohibited on weekdays 8-17, Saturdays 8-14 and Sundays 8-13.)
parking:lane=no (It's not a parking lane.) parking:condition:hgv:conditional=no_parking @ (Sa-Su 00:00-24:00, Mo-Fr 00:00-08:00, Mo-Fr 18:00-24:00) (HGVs can only park during daytime on workdays.) parking:condition:bus:conditional=no_parking @ (Sa-Su 00:00-24:00, Mo-Fr 00:00-08:00, Mo-Fr 18:00-24:00) (The same applies to buses.)
In first half of month: No parking on side with even housenumbers. In second half of month: No parking on side with odd housenumbers.
For places where the left side is the side with even housenumbers and the right side is the side with odd housenumbers:
parking:condition:left:conditional=no_parking @ (Jan 1-15, Feb 1-15, Mar 1-15, Apr 1-15, May 1-15, Jun 1-15, Jul 1-15, Aug 1-15, Sep 1-15, Oct 1-15, Nov 1-15, Dec 1-15) parking:condition:right:conditional=no_parking @ (Jan 16-31, Feb 16-29, Mar 16-31, Apr 16-30, May 16-31, Jun 16-30, Jul 16-31, Aug 16-31, Sep 16-30, Oct 16-31, Nov 16-30, Dec 16-31) Note: The opening hours syntax does not support something like:parking:condition:left:conditional=no_parking @ (Jan-Dec 1-15)
No parking on odd days of the month.
parking:condition:*:conditional=no_parking @ (Jan 1-31/2, Feb 1-29/2, Mar 1-31/2, Apr 1-30/2, May 1-31/2, Jun 1-30/2, Jul 1-31/2, Aug 1-31/2, Sep 1-30/2, Oct 1-31/2, Nov 1-30/2, Dec 1-31/2) Note: The opening hours syntax does not support something like:parking:condition:*:conditional=no_parking @ (Jan-Dec 1-31/2)
No parking on even days of the month.
parking:condition:*:conditional=no_parking @ (Jan 2-30/2, Feb 2-28/2, Mar 2-30/2, Apr 2-30/2, May 2-30/2, Jun 2-30/2, Jul 2-30/2, Aug 2-30/2, Sep 2-30/2, Oct 2-30/2, Nov 2-30/2, Dec 2-30/2)
Note: The opening hours syntax does not support something like:parking:condition:*:conditional=no_parking @ (Jan-Dec 2-30/2)
On odd days of the month: No parking on side with odd housenumbers. On even days of the month: No parking on side with even housenumbers.
For places where the left side is the side with even housenumbers and the right side is the side with odd housenumbers:
parking:condition:left:conditional=no_parking @ (Jan 2-30/2, Feb 2-28/2, Mar 2-30/2, Apr 2-30/2, May 2-30/2, Jun 2-30/2, Jul 2-30/2, Aug 2-30/2, Sep 2-30/2, Oct 2-30/2, Nov 2-30/2, Dec 2-30/2) parking:condition:right:conditional=no_parking @ (Jan 1-31/2, Feb 1-29/2, Mar 1-31/2, Apr 1-30/2, May 1-31/2, Jun 1-30/2, Jul 1-31/2, Aug 1-31/2, Sep 1-30/2, Oct 1-31/2, Nov 1-30/2, Dec 1-31/2)
No parking in first half of month.
parking:condition:*:conditional=no_parking @ (Jan 1-15, Feb 1-15, Mar 1-15, Apr 1-15, May 1-15, Jun 1-15, Jul 1-15, Aug 1-15, Sep 1-15, Oct 1-15, Nov 1-15, Dec 1-15)
No parking in second half of month.
parking:condition:*:conditional=no_parking @ (Jan 16-31, Feb 16-29, Mar 16-31, Apr 16-30, May 16-31, Jun 16-30, Jul 16-31, Aug 16-31, Sep 16-30, Oct 16-31, Nov 16-30, Dec 16-31)
It was approved with 29 votes for, 0 votes against and 1 abstention.
I approve this proposal. Great work, and thank you for persistence on refining this Proposal for each and every edge case I and others were throwing at you on the discussion page. Also thank you for all the examples with pictures, when incorporated in the main page, it will be very helpful --Westnordost (talk) 14:38, 7 January 2022 (UTC)
I approve this proposal. --Riiga (talk) 14:41, 7 January 2022 (UTC)
I approve this proposal. Thanks for patience in dealing with all related and sort of related things on the talk page. Overall it appears a noticeable improvement and I see no problems with changes being made. It is nice to be able to support more exotic tagging and gain a bit of consistency in tagging Mateusz Konieczny (talk) 14:47, 7 January 2022 (UTC)
I approve this proposal. --AntMadeira (talk) 15:36, 7 January 2022 (UTC)
I approve this proposal. --Nmombo12 (talk) 16:32, 7 January 2022 (UTC)
I approve this proposal. This would make tagging a bit more consistent and I'd be more than happy to re-tag parking restrictions I've previously mapped to this scheme. I wish I'd seen it when it was first proposed. --Rskedgell (talk) 18:34, 7 January 2022 (UTC)
I approve this proposal. Well written proposal, especially with the comparison between the old and new situation --Cartographer10 (talk) 20:24, 7 January 2022 (UTC)
I approve this proposal. --Emilius123 (talk) 20:29, 7 January 2022 (UTC)
I approve this proposal. Thank you for your patience as we went down this epic rabbit hole fixing so much technical debt in the parking lane tagging scheme. I likewise plan to update my existing parking lane tagging in the U.S. and look forward to mapping parking lanes more often, now with a more expressive scheme. – Minh Nguyễn💬 20:35, 7 January 2022 (UTC)
I approve this proposal. --Mashin (talk) 22:33, 7 January 2022 (UTC)
I have comments but abstain from voting on this proposal. I support this, but don't like keeping some of the syntax. ---- Kovposch (talk) 06:35, 8 January 2022 (UTC)
I approve this proposal. --Nw520 (talk) 15:56, 8 January 2022 (UTC)
I approve this proposal. Incredibly detailed, but also confusing! Definitely going to need a cheat-sheet to use it! :-)--Fizzie41 (talk) 05:45, 9 January 2022 (UTC)
I approve this proposal. --mnalis (talk) 13:50, 9 January 2022 (UTC)
I approve this proposal. --Srdjan02131 (talk) 19:38, 11 January 2022 (UTC)
I approve this proposal. --Chris2map (talk) 20:00, 11 January 2022 (UTC)
I approve this proposal. --K4pl4n (talk) 23:56, 12 January 2022 (UTC)
I approve this proposal. And hope that in the follow-up we can perhaps also aim to "reform" of the parking lane scheme itself (see talk page). Thank you already for your good work. --Supaplex030 (talk) 17:19, 13 January 2022 (UTC)
I approve this proposal. Good work! I particularly like the `loading_zone` and `passenger_loading_zone` addition --Tjuro (talk) 10:01, 14 January 2022 (UTC)
I approve this proposal. --EneaSuper (talk) 11:52, 16 January 2022 (UTC)
I approve this proposal. --Shogun-18 (talk) 14:28, 16 January 2022 (UTC)
I approve this proposal. --Mweper (talk) 14:47, 16 January 2022 (UTC)
I approve this proposal. --Cafeconleche (talk) 14:51, 16 January 2022 (UTC)
I approve this proposal. --HirschKauz (talk) 16:29, 16 January 2022 (UTC)
I approve this proposal. --TheBlackMan (talk) 20:30, 16 January 2022 (UTC)
I approve this proposal. --Adiatmad (talk) 03:19, 17 January 2022 (UTC)
I approve this proposal. --Reino Baptista (talk) 09:46, 18 January 2022 (UTC)
I approve this proposal. This proposal does not resolve all discrepancies between subtags for parking lanes and parking areas, but a good chunk of them, so it's a big and well-executed step in the right direction. --Tordanik 15:51, 18 January 2022 (UTC)
I approve this proposal. --Rmikke (talk) 19:39, 20 January 2022 (UTC)
I approve this proposal. --快乐的老鼠宝宝 (talk) 06:12, 21 January 2022 (UTC)
_at_Cherry_Lane_in_Dayton,_Rockingham_County,_Virginia.jpg)
Road section within the junction
_01.jpg)
_with_additional_signs_for_residential_parking_(1020-32)_and_time_intervalls_(1042-33).jpg)
I approve this proposal. Great work, and thank you for persistence on refining this Proposal for each and every edge case I and others were throwing at you on the discussion page. Also thank you for all the examples with pictures, when incorporated in the main page, it will be very helpful --Westnordost (talk) 14:38, 7 January 2022 (UTC)
I have comments but abstain from voting on this proposal. I support this, but don't like keeping some of the syntax. ---- Kovposch (talk) 06:35, 8 January 2022 (UTC)
