Le 21 août 2017 à 10:58, marc marc <[email protected]> a écrit :
> 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 > > Par contre pour ta proposition de réduire flow_capacity en capacity, > je ne suis pas favorable. capacity est trop générique. > Sa généricité est un avantage en fait > 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 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 ? > 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 ? 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. Ainsi l'éditeur ne gère pas cette partie capacity:flow réglera le problème de l'unité en tout cas si c'est ce qui est retenu. François
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
