Proposal:Parking=street side

From OpenStreetMap Wiki
Revision as of 21:59, 29 November 2020 by Supaplex030 (talk | contribs) (documented renaming "parking:street_side" to "parking:orientation" - see reference/foot note #1.)
Jump to navigation Jump to search
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: node, way, area
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

Illustrative example of parking=street_side
Typical street-side parking areas (highlighted).

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

Rendering in OpenStreetMap-Carto.

Street-side parking areas can either be drawn as separate areas or used with the parking:lane=* scheme:

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:

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
Lay-by.png
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
Surface.png
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
Parking-lane on carriageway.png
Example of parking on the carriageway.
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=*

amenity=parking plus parking=street_side, combined with area:highway=*. Other tags such as capacity=* and parking:orientation=* are omitted for brevity.

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

20200925-parking-lined-perpendicular.jpg
Single street side parking area

On a separate area:

Street side parking 05.jpg
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:

  • On the parking areas:
Consider grouping the parking areas together in a site relation tagged with type=site + site=parking.
  • On the highway:

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.

Features/Pages affected

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

  1. 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.
  2. 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 closed

Voting on this proposal has been closed.

It was approved with 23 votes for, 2 votes against and 0 abstentions.

  • I approve this proposal 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 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 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 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 I approve this proposal. --Dieterdreist (talk) 22:25, 15 November 2020 (UTC)
  • I approve this proposal 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 I approve this proposal. --Rassilon (talk) 02:11, 15 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Vakonof (talk) 10:39, 15 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Sanchi (talk) 12:08, 15 November 2020 (UTC)
  • I approve this proposal 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 I approve this proposal. Nice! Thanks. --Peter Elderson (talk) 12:43, 15 November 2020 (UTC)
  • I approve this proposal I approve this proposal. Thanks for your hard work. --Dr Centerline (talk) 17:00, 15 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Rskedgell (talk) 09:44, 16 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Roef (talk) 12:34, 16 November 2020 (UTC)
  • I approve this proposal 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 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 I approve this proposal. --TimurRin (talk) 14:07, 18 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Westnordost (talk) 23:28, 19 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Janko (talk) 17:16, 22 November 2020 (UTC)
  • I oppose this proposal 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 I approve this proposal. --OSMRogerWilco (talk) 13:48, 24 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --maro21 21:29, 24 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Ravlop (talk) 11:47, 27 November 2020 (UTC)
  • I approve this proposal I approve this proposal. -- Juan Carlos G F (talk) 15:06, 27 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --Jemily1 (talk) 22:34, 28 November 2020 (UTC)
  • I approve this proposal I approve this proposal. --!bm (talk) 23:58, 28 November 2020 (UTC)