François Lacombe a écrit : > Bnhynoteam c'est quoi/qui ?
> il y a la dépréciation de type=pond sur laquelle j'aurais voulu éviter > qu'on vote vu que cela conforte la séparation entre hydrant et suction. > Ok, en effet > Par contre si il n'est pas déprécié, il faudra quand même le passer dans > water_source plutôt que de le laisser dans le type d'hydrant 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. > 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é. Je trouve que le nom d'un tag doit vraiment être très parlant. les preset pour les clefs ayant une liste de valeur courante. le wiki étant là pour la qualité des détails ou des explications. > Cela dit, on a pas indiqué de clé où donner le nombre de connexions > possibles et la confusion peut en effet régner. > Là, un namespace peut etre utile et vu qu'il y a déjà des sous-clés de > capacity, que penses-tu de > capacity:flow et capacity:pipes ? 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 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é. > 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 > le défaut est en mètres, on peut préciser des valeurs en km en > l'ajoutant à la fin de la valeur. Si je devais coder un éditeur, je ferrai une différence entre ce que l'utilisateur encode et ce qui est mis en base. une largeur encodée comme 100cm serrait transformé par 1 en base. J'avais fais la réflexion lorsqu'il a mis l/min devant m3/h. Mais à nouveau je pense que c'est un tout autre sujet, qui ne doit pas bloquer la validation de la proposition actuelle. _______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
