[Tagging] Feature Proposal - RFC - parking=street_side

[Paul Allen]

On Sat, 24 Oct 2020 at 14:35, Jeroen Hoek <mail at jeroenhoek.nl> wrote:

> On 24-10-2020 15:11, Paul Allen wrote:
> > As rendered it appears you need a skyhook or
> > a cargo helicopter to park.  Not good.  You're probably as unhappy with
> that
> > method of tagging as I am.
>
> True, but the same goes for lots of points-of-interests and other mapped
> parts of the urban landscape; e.g., patches of grass, shrubs, benches,
> bicycle parking areas, etc. In all these cases mapping the exact area
> results in a neat map that makes sense for orientation as well as
> finding parking spaces for motorists in the neighbourhood.
>

Car parking areas are, I feel, in a different category to benches.  You
walk to a bench and can infer that if a bench is present you can
walk to it unless there are barriers.  With car parking areas you
need actual routes.  There are off-carriageway parking areas
where the entry might be from either of two parallel streets
(or both) which is unclear if we adopt helicopter parking
tagging.  Fixing the helicopter tagging also fixes the
ambiguities that seem to be the only justification for
your proposal.



> While being able to route exactly onto a point-of-interest is valuable
> in some cases, for the use case of this proposal I would say that it is
> not as relevant.


In which case, I don't see any use case for your proposal at all.


> Besides, if someone really wants to navigate to a
> specific mapped street-side parking area, their router will tend to
> route to the nearest point it can get too, which more often than not
> will be right in front of the parking area.
>

And sometimes isn't.  Two parallel roads.  I've seen this case somewhere,
but I can't remember where.  Worse, the nearest point a router could get
to is the road that doesn't have access to the parking.

>
> This proposal provides tag-values for a common type of parking area
> already mapped in great quantities, and hard to ignore at a certain
> level of detail. It gives mappers a way to map them without bending
> existing tags (e.g., parking=surface, parking=layby),


I agree, it's not a layby.  Technically, cars do park at a layby but I
don't think of a layby as being a car parking area or vice versa.
It's certainly not parking=surface which applies (by default) to
any car park that isn't either multi-storey or underground.

What you haven't convinced me of is that it isn't amenity=parking.
By any rational definition it is.  I know of off-carriageway parking
which is controlled by a county council and has a ticket
machine.  The county council lists it as a car park, one
of three car parks in the town, and makes no distinction.

and it eventually
> gives renderers a way to de-emphasize them (the proposal has a few
> suggestions) compared with the more 'high-value' parking facilities like
> large capacity public parking=surface|multistory|underground.
>

I don't see any valid reason for wanting to de-emphasize them and
you do not attempt to provide one.  Maybe there is a valid reason
but I don't see it.  It's a place to park.  Somebody looking for
a place to park near to their objective will be just as interested
in off-carriageway parking as an ordinary car park.

If applied consistently, this proposal will increase the relevance of
> parking areas that really are parking=surface|layby|etc.
>

You wish to increase the relevance by de-emphasising.  I don't
see how that works.  Maybe we could increase the relevance
even more by not mapping them at all - the ultimate in de-emphasis
and therefore the ultimate in relevance.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201024/e8bb41f0/attachment.htm>