[Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
marc_marc_irc at hotmail.com
Sun Apr 14 20:39:45 UTC 2019
Le 14.04.19 à 21:35, Martin Koppenhoefer a écrit :
>> On 14. Apr 2019, at 18:36, marc marc <marc_marc_irc at hotmail.com> wrote:
>> one of the problems is that each key has its own logic
>> a part of a amenity=building is building:part=*
>> a part of the amenity=parking is amenity=parking_space
>> a part of a leisure=sports_centre is leisure=pitch unless it is water
>> then it is leisure=swimming_pool
>> new keys deserve to have some consistency.
>> e.g. :part if the part does not have a name in itself
> I don’t follow this, a part of a park is a park:part (bench, tree etc)? A part of a city?
> This would be ridiculous or ambiguous or arbitrary most of the time, but for buildings it works well, also if the part has its own name.
I was obviously talking about the case where the parts have the same
characteristics as the whole. an amenity=parking capacity=1 have the
same characteristic as a parking_space capacity=1.
I wasn't talking about dividing a park into lots of :part
for every tree, every bench, every blade of grass.
a bench is not part of a park, it is an equipment found in some of them.
if you cut a leisure=park in 2 to say that one part has a different tag
from the other (for example, a part closed at night), it would be a bit
silly to invent a new term to say "part of a park" or to have to claim
that there are 2 parks.
there was the same kind of discussion also with the relationships
grouping several natural=wood and whose relationship is used to put
the tag name
I find also strange it's perfect to have parking_space camping_pitch
and that it would be arbitrary to call it X:part or any other sufixe
instead of inventing a new one for each value
More information about the Tagging