Bonsoir à tous,
Le 21 août 2017 à 23:21, marc marc <marc_marc_...@hotmail.com> a écrit : > si tu les connais, préviens les qu'ils ne réagissent pas ici. > C'est fait ici : https://twitter.com/InfosReseaux/status/899711313781436420 > > il est vrai que la proposition concerne aussi le tag flow_capacity > ce n'est pas la même chose que si la proposition n'en parlait pas. > Donc en effet autant voter sur quelque chose d'abouti. > Mais voilà, je ne vois pas exactement le problème avec flow_capacity > capacity:flow je trouve flow assez générique. vois-tu un autre tag avec > flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra > un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas > flow_capacity serrait tout aussi bien. > Si t'as un exemple d'autre "flow", je me rangerai à ton avis. > Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé d'autre clé qui puisse aller avec flow. N'ajoutant dans OSM que des données statiques, il ne peut s'agir que d'une capacité. Le seul argument est que capacity existe, qu'on peut l'exploiter et il était intéressant de regrouper la capacité en débit et en connexions sous la même clé Un peu comme ref=*, qui est un bon exemple : tout ce qu'il traite ne peut être que des références, pourtant on l'a bien segmenté pour des raisons évidentes de documentation et de collisions. On a pas fait de INSEE_ref, mais ref:FR:INSEE ou de erdf_ref mais ref:erdf:gdo, etc... pourquoi rajouter un nouveau tag à discuter ? la proposition ne touche > pas à ce tag, c'était mauvais, cela reste mauvais, cela reste à > améliorer. sinon au final on se trouve avec une propal pour résoudre > tous les défaut d'osm (je caricature volontairement fortement) mais qui > reste non adoptée. > Parce que c'est dans le sujet traité et que le temps manque aussi. Là on est quand même assez raisonnable je trouve :) Et même en ajoutant deux tags, on est loin de tout avoir traité. Il restera bien quelques propositions à faire avant d'avoir un modèle complet. Tout l'aspect des connexions (hormis les clés coupling) n'est pas traité et là je suis d'accord de ne pas le faire car c'est vaste. > > Ne pas discuter des points pour accélérer ne m'attire pas trop. > mon avis n'est pas dans ce sens. > je voulais dire "diviser pour aboutir", un pas après l'autre > C'est quand même ce que nous faisons, la description est pas encore complète et ne le sera pas à l'issue du vote de cette proposition Meme en ajoutant les deux clés sous capacity. Je te laisse le mot de la fin ayant donné toutes mes billes sur le sujet pour voir ce qu'on fait remonter à Viking :) François
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
