Bonsoir Marc, Le mer. 18 déc. 2019 à 17:40, marc marc <[email protected]> a écrit :
> > il y a une erreur de signification : building=service décrit l'apparence > "batiment dit de service", elle ne décrit pas qu'un service y a lieu, > d'autres tags décrivent si quelques choses y a lieu (power, amenity, ..) > D'accord, partons sur l'affirmation que building=* concerne l'apparence du bâtiment, cohérent avec ce que disais Jérôme plus haut. Peut-on mettre à jour le wiki avec cette définition ? A titre perso, je trouve que se rapporter à l'apparence est critiquable puisque subjectif mais ça reste un avis individuel. Sur le fait de conserver cette apparence sur building ne doit pas être partagé par tous, je me souviens être passé à côté de ce bunker reconverti en chambre d'hote : https://www.google.fr/maps/@50.0665915,-5.6734547,3a,75y,171.31h,92.9t/data=!3m6!1e1!3m4!1sauKZG6rQhRkQIkKLGoE_Cg!2e0!7i13312!8i6656 https://www.openstreetmap.org/way/512685914 C'est un building=house, depuis sa création et un exemple au milieu de tout le reste, j'en conviens. Le terme building=service pour désigner les bâtiments techniques a été de base mal choisi puisqu'il est pensé pour refléter "Les services d'utilités publiques" qui se traduit comme "public utility" en anglais "Public services" se sont les impôts ou l’hôpital public. Et évidemment, nous n'allons pas utiliser building=service sur un hôpital. Nous français nous le prenons avec son sens transparent alors que ce n'est juste pas le bon terme, ce qui rend cette discussion compliquée entre nous puisque "service" est un terme qui semble clair de prime abord, donc peu contestable. Nous devrions pour notre part parler de bâtiment technique. > Il est réellement intéressant de pouvoir construire des chaînes comme ce > > que je montrais dans le mail du dessus. > > Si le consommateur est intéressé pour trouver tout le bâti impliqué dans > > les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques > > comme power=substation et il peut en oublier. > > c'est peut-être un vrai problème mais changer de valeur building=* est > une fausse solution > > un poste de transformation peux très bien se trouver dans un bâtiment > dit de service, un bâtiment ayant l'apparence d'un garage, voir une > pièce dans un centre commercial, ou une partie d'une pièce multi-fonction) > chacun de ces cas aura un tag building/room différent. > Aurais-je dû dire "le bâti dédié aux utilités", parce que nous sommes d'accord. Des locaux techniques peuvent se trouver dans des immeubles d'habitation ou de bureaux, mais ils ne sont pas concernés ici. Pour vous donner tous les détails, les bâtiments complètement techniques sont souvent propriété de la collectivité ou de l'exploitant. Un local installé dans un immeuble ayant une autre destination fera l'objet d'une servitude, c'est différent. Est-ce que c'est le 1er critère pour définir une clé sur OSM? Non, et je ne cherche pas rentrer dans cette complexité réglementaire, mais c'est un élément qu'on peut avoir à l'esprit. > si tu veux regrouper toute les utilités sous une même clef, > la clef utility=* convient bien, sans qu'il soie nécessaire d'ouvrir > la proposition quasi impossible à faire voter de changer > building=service pour chainer les clefs/valeurs. > C'est bien pour ça que nous en discutons ici. Ca au moins le mérite de nous faire réfléchir sur les définitions et je vous remercie pour vos contributions. J'ai retenu les arguments concernant building=service suivants : - Pour * Largement établi dans la base * Transparent en français, apparemment conforme à l'apparence - Contre * Contre-sens en anglais, avec sa propre définition * On va devoir expliquer à beaucoup de monde ce qu'est un "service" au sens de building, puis basculer sur utility. En somme c'est incompréhensible, deux termes pour parler de la même chose. > si tu veux vraiement lier, building:use=utility et room=utility > Je le propose aussi pour améliorer building=*, parce que ça reviens dans certaines discussions où des contributeurs sont perdus. Ajouter une sous valeur en plus ne m'intéresse pas. François
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
