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

Tobias Knerr osm at tobias-knerr.de
Fri Mar 18 13:37:00 GMT 2011


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



More information about the Tagging mailing list