Le 21 août 2017 à 19:27, marc marc <[email protected]> a écrit :
> > Bnhynoteam > c'est quoi/qui ? > La Base des Hydrants nationale ouverte ;) Un idée d'Eric Pommereau, Yann Kacenelen, Donat Robaux et d'autres On peut en trouver trace sur Twitter, et j'ai mis un n en trop. C'est Bhynoteam le bon nom > j'ai répondu en ce sens ce midi sur la ml mondiale avec une phrase de > remplacement qui ne ferme pas la porte à une fusion des 2 tag emergency. > A voir ce qu'il en pense. > Et je partage complètement Il faut juste indiquer water_source=pond pour le moment et c'est très bien. > > > Par contre pour ta proposition de réduire flow_capacity en capacity, > > je ne suis pas favorable. capacity est trop générique. > > sans lire le wiki, cela pourrait tout aussi bien représenter le > nombre > > de tuyaux qu'on peux connecter simultanément. > > Sans lire la notice, on a généralement des problèmes > tu ne peux pas espérer que ceux qui utilisent id ou un éditeur mobile > commencent par lire le wiki pour chaque tag utilisé. > Non en effet, mais les presets en tiennent compte et donc les éditeurs donnent des conseils voire des avertissements en cas de contributions identifiée comme maladroite. > Je trouve que le nom d'un tag doit vraiment être très parlant. > Nous sommes d'accord. Néanmoins c'est une approche subjective. Ce qui est parlant pour l'un ne l'est pas pour l'autre. Regardes comment certains s’accommodent des clés fire_hydrant:xx les preset pour les clefs ayant une liste de valeur courante. > le wiki étant là pour la qualité des détails ou des explications. > Non c'est la seule référence, c'est pour ça que la rédaction des pages doit être la plus complète possible en recensant tous les cas si possible. flow_capacity existe déjà. 6000+ occurrences. > Lui faire perdre son préfixe pour le rendre commun aux suction_point > serait déjà une avancé. > Depuis le temps que + de 80% de la proposition est accepté unanimement, > je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte > à ouvrir un nouveau chantier pour le reste. > C'est un piège. On a eu le cas sur l'énergie et il y a des choses qui ne se feront jamais (sur les supports poteaux et pylônes, qu'on aurait pu rapprocher de man_made=tower) En effet le périmètre de la proposition doit rester raisonnable, mais d'expérience je ne suis pas d'accord pour faire la moitié du chemin maintenant le reste après. Si on laise flow_capacity, le coup d'après il sera à 80k utilisations et indéboulonnable (parce qu'indiqué comme Approved dans le wiki entre autres) Je ne dis pas que c'est une mauvaise chose, mais il faut choisir en ayant ça à l'esprit. capacity est déjà un concept largement utilisé, que l'on peut compléter en lui ajoutant des suffixes pour gérer le cas des unités. C'est ce que je trouve intéressant, mais conçoit que ça ne séduise pas tout le monde. En le choisissant, on se range du côté de l'existant et ce sera ainsi plus facile à faire adopter. > c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count > c'est obscur, y compris la description du wiki. > mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point > supplémentaire de discussion afin que le reste soie validé. > count, c'est comme type, le fourre-tout qu'on peut rendre plus explicite dans 80% des cas. Au contraire, il faut en parler. Ne pas discuter des points pour accélérer ne m'attire pas trop. > De plus je pense qu'il est utile, pour les éditeurs, d'avoir un seul > > type d'unité par clé afin de pouvoir l'afficher lors de la saisie. > > sinon les éditeurs doivent avoir une liste hard-codée des unités en > > fonction de l'objet, c'est contre-productif à l'effet souhaité d'une > > harmonisation des clefs. > > Problématique intéressante que je n'ai pas rencontré jusque là. > > JOSM par exemple, n'affiche pas d'unité dans les presets il me semble ? > Je n'en ai jamais vu mais ce serrait utile. Rien ne bloque techniquement > > > Est-ce que tu étend cela aux multiples ? Parce que pour height, même si > Mais à nouveau je pense que c'est un tout autre sujet, qui ne doit pas > bloquer la validation de la proposition actuelle. > Ok, je partage. On va trouver une clé adéquate pour indiquer un débit et ce sera réglé. Accordons-nous sur ces points, et nous verrons ce qu'il est utile de lancer dans le Talk de la propal ensuite François
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
