[Tagging] Feature Proposal - RFC - parking (redux)

Flaimo flaimo at gmail.com
Fri Mar 18 13:52:39 GMT 2011


ok, i see what you mean now. use amenity=parking for the whole
facility, and the new tags for defining the elements inside. that only
works without a relation as long as you only have one logical parking
lot that's not split up in different areas. but parking lots, on
airports for example, are often separated by official roads which are
not part of the parking lot. therefore you would map two
amenity=parking areas and then you need the relation anyway. and what
about situations where parts of the area are not part of
amenity=parking? exclude them by creating a multipolygon relation for
that spot? doesn't make things easier. also inheritance of properties
would be more complicated in the long run. that's exactly why the
relation=site proposal was written (which, according to the comments,
is already used a lot) and why i based my proposal on that.

i'll mention your concern in the comments of the proposal and let's
see what the other users think.

on terms of the interpretation of amenity=parking. i don't see why the
purpose couldn't be further refined by an additional tag. it is done
this way for highway=service + service=* for example.

regards,
flaimo

On Fri, Mar 18, 2011 at 14:09, M∡rtin Koppenhoefer
<dieterdreist at gmail.com> wrote:
>
> Yes, but the streets that are exclusively used to access the parking
> space are part of the parking. The latter is what amenity=parking is
> about, (see also in combination with parking=surface, underground,
> multilevel), the first is what you want to tag.



More information about the Tagging mailing list