On 18.03.2011 13:33, Flaimo wrote: > my original version used new tags for all three elements, but a user > in the comments suggested to explicitly use amenity=parking for > compatibility reasons and to slowly force renderers to adapt this > mapping scheme.
I disagree with that user's idea of forcing renderers to implement a new feature by breaking existing rendering rules. If it is possible to introduce tagging for individual parking spaces without changing the usage of existing tags such as amenity=parking (and it is easily possible by using separate tags), then it should be done. Renderers will adapt their rendering rules if they want to show individual spaces, and don't need to change them if they are not interested in showing individual spaces. And that's exactly how it should work. As explained by Martin, amenity=parking traditionally marks an entire parking facility, including not only parking spaces, but also infrastructure within the facility. Thus it provides a higher level of abstraction which is still useful even when you map individual spaces. Additionally, the availabilty of an enclosing amenity=parking area could make the use of a relation optional in many cases, enabling a visually more intuitive editing style. As mentioned on the site proposal page, it is not necessary to use a site relation "if all the elements contained within an area (the perimeter) belong to the site, and no elements of the site exist outside the area". >> I also suggest to allow nodes for parking spaces. [...] > good argument. i changed the proposal accordingly. Nice, thanks. Tobias Knerr _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
