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

M∡rtin Koppenhoefer dieterdreist at gmail.com
Fri Mar 18 14:51:10 GMT 2011

2011/3/18 Flaimo <flaimo at gmail.com>:
> 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.

sometimes, given that these segregated parkings are indeed _one_
Parking (often while all beeing parkings of the same airport, they
would be distinct parkings where routing to distinct places would also
be desirable). You don't need a site relation in these cases anyway,
you can do with type=multipolygon.

> 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?

yes, of course. That's the same for every features. Multipolygons are
for grouping outer ways as well as for subtracting enclaves. They are
an object type suited for mapping one feature which is geometrically
split up into different pieces.

> doesn't make things easier. also inheritance of properties
> would be more complicated in the long run.

I don't understand this. Inheritance of properties is implicit in
multipolygon relations.

 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.

the site relation is indeed used a lot (around 128.000 times) but IMHO
needed only for details like where is the ticket office, where is the
main entrance, which would be a suggested label position (render
hint), etc. and there is no application that I know of (in contrary to
multipoly) which takes site relations into account.

> 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.

in  highway=service + service=* all ways remain still types of
service, while in your suggestion you would shift the meaning from
parking facility (including streets and ticket machines, lift-gates,
etc.) to parking space for a vehicle.


More information about the Tagging mailing list