Proposal:Parking=street side
| The Feature Page for the approved proposal parking=street_side is located at Tag:parking=street_side |
| parking=street_side | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | JeroenHoek, Supaplex030 |
| Tagging: | parking=street_side |
| Applies to: |  ,  , 
|
| Definition: | Area suitable or designated for parking, which is directly adjacent to the carriageway of a road and can be reached directly from the roadway without having to use an access way. |
| Statistics: |
|
| Rendered as: | The rendering especially of the parking symbol for individual areas of this type should be different from other (surface) parking areas to avoid appearing too dominant in the rendering. |
| Draft started: | 2020-09-30 |
| RFC start: | 2020-10-24 |
| Vote start: | 2020-11-14 |
| Vote end: | 2020-11-28 |
Proposal
We propose to introduce street_side as a new value for parking=* and parking:lane=*. It is intended for parking areas located directly at roadways — either single parking areas (often only for a few vehicles) or chains of "bays" or "pockets" alongside the roadway which, in contrast to parking lanes, are structurally designed and therefore regularly interrupted by structural elements like curb extensions or islands for street furniture. In contrast to parking=surface, these parking spaces are accessed directly from the street without having to use an access/service road or driveway.
These street-side parking facilities can either be mapped as separate areas (amenity=parking + parking=street_side) or the new value can be used with the parking:lane=* scheme (see below).
Rationale
Street-side parking areas are a common feature of the urban cityscape of many countries. In contrast to other types of parking spaces commonly used in OSM, especially parking=surface, they represent a different class of parking spaces, both in terms of their structure and terminology. In some languages there are unique terms for this type of parking, in the German language e.g. it's called Parkbucht, Parktasche or Parkhafen. In the English language there seems to be no clear unambiguous term for this type of parking, so we decided upon street_side.
The introduction of a separate sub-tag for this form of parking also makes it possible to recognize these areas as part of the road system. Furthermore, this type of parking may have different rendering and navigation needs compared to other types of parking (see below).
Street-side spaces designated for the parking of cars often take up non-trivial amounts of space, and together with streets, buildings, and vegetation (grass, shrubs, trees, etc.) make up the bulk of the recognizable features of any particular location in a built-up area. For users orienting themselves with a map, such features, taken as a whole (in addition to specific points-of-interest) enable them to pinpoint their location on the map. As an amenity too, mapped parking spaces can be useful in determining a suitable place to park nearby when navigating to a specific place.
Tagging
Street-side parking areas can either be drawn as separate areas or used with the parking:lane=* scheme:
- As a separate area: Draw the parking areas alongside the street as separate areas with amenity=parking + parking=street_side. If several parking bays are lined up along the same street, consider grouping them together in a site relation tagged with type=site + site=parking.
- With the parking:lane=* scheme: According to this scheme add
parking:lane:<side>(usually either parallel, diagonal or perpendicular) andparking:lane:<side>:<type>=street_sideto the highway. In this case the value lay_by should no longer be used and should be replaced by street_side (see below).
The separate variant is particularly suitable in areas where the road space is already mapped in great detail or if there is only a single (small) street side parking area. The parking:lane variant is a simple alternative if no micromapping of these areas is desired.
In case of separately drawn parking areas:
parking:lane:<side>=separateshould be added to the highway to indicate that the parking information is mapped separately.- The key
parking:street_side=*parking:orientation=* with the typical valuesparallel,diagonalorperpendicularcan be used additionally on the separately drawn parking areas to indicate the orientation of the parked vehicles in relation to the street.[1] - It is useful to provide other common information (if these are identifiable) such as capacity=*, capacity:disabled=*, fee=*, surface=*, or access restrictions.
- Same as with parking=surface, separate parking places can be drawn in and tagged with amenity=parking_space, but this is optional (Note: Do not use parking=street_side on these parking spaces if they are already part of a larger area with this tag).
Relation to other parking=* values
Because the base-tag of amenity=parking can be applied, and is rendered, without any sub-tags, the type of street-side parking documented in this proposal is already tagged in abundance. In addition to the base-tag, a variety of parking=* values have been used. Some of these have been considered to co-opt for this proposal, but all seem unsuitable based on their original meanings — as far as these can be determined.
| Value | Example | Intent |
|---|---|---|
| Misunderstandings and contradictions when using layby or lay_by | ||
| parking=layby | Originally intended for roadside (typically rural) short-stop rest-areas along through-traffic roads intended for breaks during a car-trip or for stops in case of emergency. It was introduced on parking=* as “Commonly used in the UK to describe parking directly alongside a road”, and is widely used in this sense.
In the parking:lane=* scheme, this value is also common, here however written with an underscore (lay_by). The wiki defines it as above via a link to Wikipedia. Unfortunately, it is used largely for street-side parking in the sense of this proposal. It seems that the meaning has been misinterpreted. Nevertheless lay_by is the second most common value when used with the parking:lane=* scheme.[2] All in all this could be a candidate for the proposed type of parking, but the two uses clash in their intended purpose and desired prominence on maps. On a motorists map, for example, road-side resting areas would likely be rendered quite explicitly, whereas street-side parking should not show up on lower zoom-levels. Not using this tag-value has the benefit of providing an alternative for street-side parking, and gradually restoring layby/lay-by to its original intent. | |
| Relation to surface and lane | ||
| parking=surface | Intended for the classical parking-lot; a self-contained area dedicated to the parking of vehicles. Can be of any size, but usually has its own access roads.
Because this value is one of those in the JOSM-preset, and the only one remotely suitable for street-side parking, it is (mis)used for this purpose as well. As with parking=layby, the rendering and navigation goals of parking-lots (in particular large capacity, public use ones) differ from those of street-side parking. The example shows two street-side parking areas as well for comparison. | |
| parking=lane | Seemingly intended to be the explicitly mapped equivalent of the areas implied by parking:lane=*.
Documentation is unclear, but name and usage point to the mapping of parking areas on the carriageway, rather than separate areas off the carriageway (the topic of this proposal), although the latter occurs as well. Co-opting this tag-value might add to the confusion. | |
Other values
parking=street was used by one of the mappers behind this proposal as a first attempt at figuring out a useful tag-value. These will be re-tagged when the tag-value proposed here is deemed suitable.
Relation to area:highway=*
When the parking areas are explicitly mapped using amenity=parking plus parking=street_side, then there is some overlap with the subject of the area:highway=* proposal. This proposal neither encourages nor discourages the mapping of highway areas, but should complement area:highway=* where used.
The relevant proposal shows street-side parking areas mapped as separate areas, which would be a good fit for parking=street_side. Some mappers use area:highway=parking_space to map the area of street_side parking spaces. amenity=parking + parking=street_side should be added as main tag.
| area:highway=parking_space |
Examples
| Single street side parking area
On a separate area: | |
| Several street side parking areas (on the left – and lane parking on the right)
Variant 1: Implicitly mapped by only adding tags to the highway:
Variant 2: When the street side parking areas on the left are explicitly mapped as separate areas:
|
Rendering
Initially, rendering will in most cartographic styles likely follow that of other amenity=parking types such as parking=surface.
To reduce the density of the map renderers could consider de-emphasizing the rendering of street-side parking (e.g., by dropping or down-sizing the P or by not rendering it until zoomed in further). See some example renderings in the gallery below.
over-emphasized rendering (carto default)
de-emphasized (like limited parking - might be confusing)
no rendering of parking symbol
small parking symbol
small light parking symbol
Features/Pages affected
- parking=street_side must be added and defined on page parking=* (when used on separate areas) and on page parking:lane=* (when used on ways).
- On page parking:lane=*, the distinction between lay_by and street_side must be pointed out to bring lay_by back to its original intention in the future.
- On page area:highway=* it should be pointed out in context with area:highway=parking_space, that amenity=parking + parking=street_side should be added as main tag.
None of the tags mentioned in the chapters above need to be deprecated. However, due to the better differentiation, some of them ("layby", "lane", "parking_space") return to their original intention.
External discussions
This proposal is the result of an exchange between the two mappers who are proposing it and who have been using different mapping approaches so far.
Comments
Please comment on the discussion page.
Notes
- ↑ Key was renamed after the proposal was closed after local community discussions: It is now more intuitive and can also be used in connection with other parking values. As this is only a side aspect of the proposal which is not yet in further use, the renaming should not conflict with the proposal process.
- ↑ According to the scheme
parking:lane:<side>:<type>with the values "both", "left" and "right" for <side> and the most frequent values "parallel", "perpendicular" and "diagonal" for <type>, there are a total of 12,625 uses for "on_street" and 4,710 uses for "lay_by". Further values follow at a certain distance: Thus, "on_kerb" with 2,040 uses (as at 2020-10-10 19:00 UTC).
Voting
Voting on this proposal has been closed.
It was approved with 23 votes for, 2 votes against and 0 abstentions.
I approve this proposal. The page Tag:amenity=parking also need to be changed as it states under heading How to Map:
- "Parking along the side of streets is tagged with parking:lane=*."
- --Lectrician1 (talk) 17:02, 14 November 2020 (UTC)
I oppose this proposal. Does not reproduce the actual topology of the driveable network in a visual representation (cars must be lifted by crane or helicopter from the road to the parking space, or the cars must have pogo sticks). Complicates issues for routers having to scan nearby parking lots to see if they might be connected by a magic tag. I oppose any suggestion that vital parking spaces be de-emphasized because somebody thinks it makes the map look cluttered. If you need to park you want to find possible spaces. --Brian de Ford (talk) 17:05, 14 November 2020 (UTC)
- I agree with with you that this doesn't provide any routing advantage. I disagree that this might clutter the map and that the topology isn't defined when clearly, the layer that the road is in is going to be the layer the highway adjacent to the parking is in. However there's no direct link between these two elements so software isn't going to easily be able to recognize this relationship. This debacle is just another reason why Proposed_features/Relation:street needs to be implemented. If type=street was to be implemented, the layer=* could be stored in the Relation, and then the topographical and streetside relationship between the street and the parking would be known.
- As for this proposal right now, because no relationship exists between the street and parking elements to begin with, I think this could be helpful to future mappers who are putting these street side parking elements into a Street Relation. Also, the note that renderers should shrink the size of streetside parking elements is helpful. --Lectrician1 (talk) 17:47, 14 November 2020 (UTC)
- Your criticism seems to be aimed against questions of practical implementation, but not against tagging itself, do I understand that correctly? You could, for example, use the parking:lane scheme. On the Tagging Mailing List the "helicopter problem" and possible solutions were also mentioned. However, I think this argument is fundamentally wrong, because I'm a cyclist and I have never needed a helicopter to route from the street to the adjacent bicycle stand (I don't know of any bicycle stand in OSM with a street connection).--Supaplex030 (talk) 20:07, 14 November 2020 (UTC)
- Having a way to associate road-side elements with a road does sound useful (it extends to separately mapped sidewalks/cycleways as well). I think it is beyond the scope of this proposal though. The argument that entities not connected to the road network are undesirable and hard to route to does not, in my experience, match reality. You wouldn't be able to navigate to any address at all, and most POI's are not connected to the road network (and never will). Also, street-side parking areas sit rather low on the scale of things people plot navigation to. JeroenHoek (talk) 09:48, 15 November 2020 (UTC)
- I approve this proposal. I've always mapped these areas as amenity=parking, but this should be a handy alternative. --Fizzie41 (talk) 21:44, 14 November 2020 (UTC)
- It is amenity=parking! parking=street_side is a complement to specify the type of parking (like parking=surface, parking=multi-storey or parking=underground). This will be clear from the future description pages if approved. --Supaplex030 (talk) 22:13, 14 November 2020 (UTC)
- I oppose this proposal. I believe the term "street side" is confusing and will be used for car parking along roads (and on the carriageway, what you call "lane") in both configurations, parallel and perpendicular. --Dieterdreist (talk) 22:05, 14 November 2020 (UTC)
- "will be used for car parking along roads (and on the carriageway, what you call "lane") in both configurations, parallel and perpendicular" - why it would be a problem? Maybe I missed something but, I though that it is the intention of that proposal Mateusz Konieczny (talk) 18:43, 15 November 2020 (UTC)
- You are correct, I had misread a paragraph in the proposal, it is actually consistent. While I am not mapping these street side parkings with amenity=parking, I can understand that you would want to mark them somehow when you did. I am supporting the possibility to do it. --Dieterdreist (talk) 22:25, 15 November 2020 (UTC)
- I approve this proposal. --Dieterdreist (talk) 22:25, 15 November 2020 (UTC)
- I approve this proposal. I agree with providing additional tagging to better describe amenity=parking areas that are alongside roads. Thanks for all the hard work you put into this proposal! --ZeLonewolf (talk) 22:29, 14 November 2020 (UTC)
- I approve this proposal. --Rassilon (talk) 02:11, 15 November 2020 (UTC)
- I approve this proposal. --Vakonof (talk) 10:39, 15 November 2020 (UTC)
- I approve this proposal. --Sanchi (talk) 12:08, 15 November 2020 (UTC)
- I approve this proposal. This is a good improvement for tagging parking areas/spaces which are not on the road but next to it. I do agree with Brian de Ford that it would be better to make the parking amenity topologically connected to the road to reflect reality where street_side parking is connected to the actual road. --Hiddewie (talk) 12:23, 15 November 2020 (UTC)
- I approve this proposal. Nice! Thanks. --Peter Elderson (talk) 12:43, 15 November 2020 (UTC)
- I approve this proposal. Thanks for your hard work. --Dr Centerline (talk) 17:00, 15 November 2020 (UTC)
- I approve this proposal. --Rskedgell (talk) 09:44, 16 November 2020 (UTC)
- I approve this proposal. --Roef (talk) 12:34, 16 November 2020 (UTC)
- I approve this proposal. I find it useful to make the distinction between on- and off road parking. The rendering for zoom levels 17, 18 and 19 should be changed to avoid a forest of P's within populated areas. --E de Wit (talk) 14:17, 16 November 2020 (UTC)
- I approve this proposal. --Adamfranco (talk) 18:46, 16 November 2020 (UTC) I've been mapping these areas already and find that the rendering that works well for dedicated parking lots is too visually intense for street-side parking. Hopefully this new tagging will allow a way forward to disambiguate these two usages.
- I approve this proposal. --TimurRin (talk) 14:07, 18 November 2020 (UTC)
- I approve this proposal. --Westnordost (talk) 23:28, 19 November 2020 (UTC)
- I approve this proposal. --Janko (talk) 17:16, 22 November 2020 (UTC)
- I oppose this proposal. -- A place for parking are not parking bays. Then the symbol for a parking space P is displayed too often. example geozeisig (talk) 18:11, 23 November 2020 (UTC)
- Avoiding the tagging of places you can actually, evidently, and legally park because you don't like how it renders is tagging for the renderer, and is frowned upon by the OSM community. However, you'll be pleased to note that we address the rendering concern in the proposal. When enough of these places are tagged as proposed, rendering engines such as Carto may leverage the new tagging value to adjust the rendering of street-side parking to a more suitable verbosity. In fact, if you dislike all those blue P, supporting this proposal offers a good chance to eventually fix that problem, because with or without this proposal, people will map street-side parking (and in fact already do so). JeroenHoek (talk) 18:20, 23 November 2020 (UTC)
- I approve this proposal. --OSMRogerWilco (talk) 13:48, 24 November 2020 (UTC)
- I approve this proposal. --maro21 21:29, 24 November 2020 (UTC)
- I approve this proposal. --Ravlop (talk) 11:47, 27 November 2020 (UTC)
- I approve this proposal. -- Juan Carlos G F (talk) 15:06, 27 November 2020 (UTC)
- I approve this proposal. --Jemily1 (talk) 22:34, 28 November 2020 (UTC)
- I approve this proposal. --!bm (talk) 23:58, 28 November 2020 (UTC)