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 <dieterdre...@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. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
