Hello, Petit point d'étape sur les récentes discussions avec Viking On avance : la plupart des clés ont perdu leur prefixe fire_hydrant: ou suction_point.
Autre sujet maintenant : https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_ Extensions#Flow_and_pipes_capacity Je trouvais les tags couplings_type et couplings_diameter un peu restrictifs pour décrire quelque chose d'aussi divers et détaillé que les connexions des bornes. Surtout que c'était avec des valeurs listes Ainsi j'ai proposé d'avoir des couplings:small, couplings:medium ou couplings:big ou ne serait-ce que couplings=x pour donner le nombre de connexions possibles. C'est pas le meilleur schéma possible, mais les listes à ; sont à bannir, avec ou sans unités. Pour l'instant la réponse est non, convaincu qu'il faut éviter à tout prix les namespaces (ce qui n'était pas tout à fait mon propos avec fire_hydrant:) Il y a normalement l'équipe d'OsmHydrant qui est prévenue et qui devrait aussi donner son avis avant le vote, pour éviter toute déconvenue Chose également étrange, il serait aussi de nouveau question de fusionner fire_hydrant et suction_point d'après le dernier mail recu sur la ML internationale. Il reste encore un peu de chemin avant d'obtenir un truc votable, sur la forme discussion vraiment intéressante et constructive, c'est encourageant *François* Le 30 août 2017 à 11:28, François Lacombe <fl.infosrese...@gmail.com> a écrit : > > Le 28 août 2017 à 11:32, marc marc <marc_marc_...@hotmail.com> a écrit : > >> Je trouve que ce n'est pas exact. >> capacity indique le maximum possible pour une infrastructure. >> le chiffre indiqué sur une borne incendie n'est pas son débit >> variable dans le temps (celui là ne dépend que du pompier) >> mais le débit maximum dont la borne est capable. >> > Je suis de cet avis, mais tout le monde n'entend pas cette logique. > Ils ont migré vers flow_rate, ce qui est déjà un progrès. > > >> On fait quoi pour la séparation pressurisé <> non pressurisé ? >> j'argumente une dernière fois avec le fait que 10% des bornes françaises >> vont se trouver dans un état indéterminée pas d'info pour les classer ? >> et surtout quid à l'avenir du gars qui rencontre une borne >> sans plaque de pression... il doit choisir l'une des 2 catégories, >> > > Pareillement, je suis de ton avis. > dans l'immédiat, avoir des clés agnostiques de fire_hydrant ou > suction_point est déjà une avancée. > On peut partir la dessus pour l'instant et dans un second temps revenir en > force avec des cas et propositions dans ce sens ? > Comme tu le disais, sinon ca risque d'échouer si on fait tout en même temps > > >> >> > attends tu l'avis Bhynoteam ? >> > >> > Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait >> > rédigé en 2015 >> > https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655 >> J'ai lu son document. >> ä un endroit il dit qu'il n'est pas pour type=pond >> ä un autre il propose l'ajout de type=dry_hydrant qui n'est >> cependant pas en jaune comme le reste des nouveauté proposé. >> je ne sais pas si l'un est un remplacement de l'autre. >> En fin de pdf, il utilise donne des exemples de bornes sans pression : >> emergency = fire_hydrant >> fire_hydrant:type = pillar >> fire_hydrant:pressure = suction >> Donc j'en déduit que selon lui, il faudrait aussi supprimer le "pond" >> mais que le critère d'uneborne n'est pas la pression >> il ne compte pas participer au débat ? >> > Non à mon avis il n'a pas le temps > Le document étant principalement en phase avec la proposition hormis les > clés avec fire_hydrant: de partout, je suis d'avis pour le soutenir en > l'état. > > Il reste peut-être un point sur couplings_type et couplings_diameter qui > sont là pour décrire les types de connexion et surtout leur nombre et > diamètre. > Peut-être suggérerais-je l'ajout de manufacturer=* et model=* qui > pourraient servir à connaitre le modele de borne (standard dans le > catalogue fournisseur) sans avoir à préciser exactement les diamètres et > types de connexion (pas forcément visibles en plus) > Alors que des fabricants il n'y en a pas des masses (bayard,...) > > Les points Resolved commencent à apparaitre dans le Talk, ce qui est bon > signe > > François >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
