You are right in that in regards to KISS, i was not seeing it as being more complex but easier to interact with the parking_space elements via editor (but that was personal preference for sure). I was also following the description here https://wiki.openstreetmap.org/wiki/Proposed_features/parking where you can see schema (in the example category) with grouping of the parking relation like a "tree" (i found it easier to understand by human editor than just keeping it via geographic relation only). After all, site relation is not meant to be rendered, but only to be used as *an administrative tool . *
But i recognize that i have probably over-extended the definition with its use for the "simple" parking. Do you think i should remove the relation for the 'simple' parking that are "only on the surface" and all contained into the amenity=parking polygon ? For multi-site parking (like for mall or large venue place where parking can be separated by highways, buildings, ...), i still see it as a good use as it avoid the duplication of most tags (opening_hours...) and indicate that they are all the parking for that particular place (without relying on the name or something like that).
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
