[Tagging] Feature Proposal - RFC - parking=street_side

Allroads allroadsworld at gmail.com
Sat Oct 24 20:27:49 UTC 2020


The two methods:

1. Tagging on the way line. When a road, highway=*
2. Tagging a polygon. When a road, area:highway=*

Will always be used next to each other. We have to take that into account.

New mappers, see a parking plot/space and want to draw that in, that is 
logical behaviour. It is obvious for them to draw a polygon. And want them 
to see on a map.
It is not obvious for them to tag parking:lane on a highway=*, the method 
for wayline parking.  Originated with the first development of 
Openstreetmap, then the system evolved, area:highway was developed later.
We must give them the opportunity to do so, polygon mapping. Topographical 
mapping.

Also for on the lane parking, we need the polygon to draw in, because space 
lines are painted on the road or different paving, indicating parking 
spaces, parking traffic signs refer to it.

In the mind of general people there is no difference on the carriageway or 
beside, for them it is both street side parking. street_side is also on the 
lane parking. It is more a general term. (I think, maybe more for not native 
UK people).
Do not make a difference between carriageway (painted, surfaced) and beside 
parking by choosing street_side  value as a tag for one (beside).

Polygon: Where the transportation modes can walk/ride/drive on a polygon, we 
tag area:highway=* ,  that is a base tag.

On a way, highway=* we have residential and service and 
service=parking_aisle, this is on a amenity=parking.

For a polygon on lane and beside we have area:highway=service, even when you 
draw in a amenity parking, you have area:highway, there the lane is 
area:highway=service service=parking_aisle, parking spaces are a kind of 
service.

The plot/space on a amenity=parking, 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space , there is 
no much visual difference, when there is a parking_space on a amenity and or 
on the (marked parking) carriageway or beside parking.

The value should/could also be used. There everywhere, places for disabled 
parking and electric parkin a spaces

On the lane road with no marking, there is only  the (1.) wayline tagging, 
parking:lane possible,

A carriageway, can have,
wayline tagging highway=residential with parking:lane=no_parking,
polygon highway tagging area:highway=residential, the lane to 
walk/ride/drive
polygon parking tagging area:highway=service service=parking 
parking=street_side on lane and beside parking:condition=free
In this example there is a no_parking traffic_sign on both side of the road,
EU rules, determine that such traffic_sign, no_parking  only prohibited 
parking on the lane, and not the marked parking spaces or the verge. So w 
must have the opportunity to tag it properly, this is a example both methods 
of tagging are needed (line polygon).

Use area:highway for polygon and parking!

The combination area:highway=service and service=parking, should be enough 
indication for the render to not set a P. (Carto) Even when there is a 
amenity=parking is set. (wrongly?)
parking= street_side could be used there is no conflict parking=* on amenity 
with parking 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking#Additional_Tags

The only point for me is, can also the value "parking_space" be used, with 
what key? area:highway=service service=parking parking=parking_space(?) (Do 
we need street_side?) Or is it parking:street_side=parallel
People, want to draw in a single space. We have to take that into account. 
But others draw in several spaces as a one object, parking_space, this is 
not correct.
It must be clear that there is a single spot. Somewhere the value 
"parking_space" must fit in.

parking_space=disabled, this must not be different then on a 
amenity=parking, if, that is confusing for a lot of people ( taggers), now 
with electric cars there lots op spaces where only they can park, 
traffic_sign prohibition next to the space, single space are more drawn in 
the future. Prohibited access on the space.
Netherlands Government, are going to draw in all these spaces, each space 
get a ref, for linked data, the cost of electric charging, and more.
Amenity parking and carriageway parking, space tagging must be with the same 
tags. If they look the same and the use is the same.

So, we must prepared for more detailed mapping.

This kind of tagging is almost impossible on a wayline, all these way cuts, 
visualisation and control the data. A polygon visualisation is more clear.

For me,  the value "parking_space" what key, single space problem must be 
fixed first to say something about "street_side". As it comes to a vote. 




More information about the Tagging mailing list