Donc, si je comprends bien, pour le moment,
- au vue de :
[out:json][timeout:600];
{{geocodeArea:France Métropolitaine}}->.searchArea;
nwr["camp_site"][camp_site!=basic][camp_site!=standard][camp_site!=serviced][camp_site!=deluxe](area.searchArea);
out meta;>;out meta qt;
2 cas principaux et des suggestions de remplacement pour camp_site=pitch
qui décrit soit :
- un camp/emplacement basique -> tourism=camp_site + camp_site=basic
- un terrain dans un site + large -> tourism=camp_pitch
- sans oublier camp_site=reception -> amenity=reception_desk
--
deuzeffe, je comprends vite mais faut m'expliquer longtemps
On 21/05/2019 13:20, marc marc wrote:
Bonjour,
Comme plusieurs contributeurs l'ont remarqué, sur tagging et le wiki
une discussion a lieu à propos de la clef camp_site
le problème principal est l'ajout massif de partie de camping
au même niveau que la clef servant à décrire le type de camping
tel que approuvé par
https://wiki.openstreetmap.org/wiki/Proposed_features/Camp_Site
le gros soucis c'est que cela casse la logique des chaînes de tags
exemple
amenity=parking peux être raffiné par parking=surface qui donne
des infos supplémentaire sur les caractéristiques du parking
on ne me fait pas parking=place/distributeur/barrière/entrée
landuse=industrial industrial=oil donne des info sur le type
d'activité à cet endroit
on ne fait pas industrial=silo/reception/usine/...
dans cette logique tourism=camp_site
camp_site=basic/standard/serviced/deluxe donnes des infos sur le camp en
lui-même et un autre tag doit être trouvé pour décrire les parties du
camp, de la même manière qu'on
a d'autre tag pour décrire les parties d'une parking (parking_space
vending_machine) ou les parties d'un site industriel (silo, building, )
l'ampleur est tel que cela semble difficile de résoudre le problème
en une fois, c'est pourquoi se discute en ce moment la possibilité
de faire cela en 2 fois en se concentrant d'abord à éliminer
les valeurs les plus problématique en les basculant sur des valeurs
moins problématiques mais déjà existante même si imparfaite
bref, 2 petits pas au lieu de se prendre le mur :
camp_site=camp_pitch et camp_site=pitch -> tourism=camp_pitch
camp_site=reception -> amenity=reception_desk
dans cette optique, les valeurs choisie sont volontairement
des valeurs existantes afin d'éviter d'augmenter la fragmentation
elles sont pas parfaite, je sais, le but du premier pas est de supprimer
des valeurs problématiques, pas de d'aboutir à une solution finale
en une fois.
la proposition actuellement soumise au vote un peu prématurément
propose de "valider l'incohérence". je vous invite à la lire
et à faire votre avis.
a noter que la majorité des avis pour sont "pour le fait de renseigner
les parties d'un camping", ce qui n'était pas l'objet du vote
https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
cela aiderait à trouver une meilleur solution si des contributeurs
supplémentaires donnait leur avis que le bricolage actuel n'est pas bon :)
Cordialement,
Marc
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
