[Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 16:22, Janko Mihelić wrote:
> These two variants are mapping for the renderer, and both add false
> data. The first one extends the parking over half the road. The second
> creates a service road area over half the road. There is no service road
> area there, you are just trying to connect the parking to the road so it
> looks nice on the map. And it does look nice, but it's false data.

Agreed.

There may be a handful of cases where a router won't route you to a spot
on the road right next to an explicitly mapped parking=street_side area
mapped the way shown in our proposal, but I don't think that is a very
common use case; you normally wouldn't target a specific street-side
parking area.

If I want to visit a friend or a small shop in an area without dedicated
parking lost/garages, I would look around on the map to orient myself,
and probably set the destination to the address I am going, or somewhere
along a road from whereon I would go look for a free spot using the map
to show me streets where I can park.

With a large parking garage you definitely would select that as the
destination if you are using a router, but that is a different kind of
beast.

> Street side parking is a very different parking area from a big enclosed
> surface parking. Some people may find it hard to park there because you
> back up onto traffic, and they may want to avoid parking there. This
> information is definitely very useful.

Exactly. Our proposal should benefit other types of amenity=parking such
as parking=surface (etc.) by giving routers and renderers a way to
ignore and de-emphasize, respectively, street-side parking.

It also benefits data consumers (including routers) when asking for a
list of parking facilities nearby: street-side parking can be properly
classified and described as such, and potentially shown lower in the
list below any public parking lots/garages.