<div dir="ltr"><div><div><div><div>Merci Vincent pour ce temps passé et cette approche, on est parfaitement en phase :)<br></div><div>Je n'étais pas plus au courant que ça du problème pylone vs point géodésique.<br></div>
<div><br><br></div>Christian, sachant que le modèle est mouvant et qu'il y a plus d'une centaine de propositions ouvertes sur le wiki et si les utilisateurs veulent des données stable, ne serait-il pas prudent de travailler sur un export ?<br>
<br></div>Les changements sont notifiés, et là ça va faire l'objet d'un vote puisque ça va être intégré à ma proposition sur les réseaux électriques.<br></div>Tout le monde sera averti en temps et en heure à toutes les étapes de l'adoption.<br>
</div>Enfin c'est comme ça qu'il y aura le moins de désagréments je pense, si quelqu'un a une meilleure idée je prends.<br></div><div class="gmail_extra"><br clear="all"><div><b>François Lacombe</b><br><br>francois dot lacombe At telecom-bretagne dot eu<br>
<a href="http://www.infos-reseaux.com" target="_blank">http://www.infos-reseaux.com</a><br></div>
<br><br><div class="gmail_quote">Le 16 août 2013 23:29, Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Je n'ai pas la même interprétation du "il y en a trop, on ne peut pas".<br>
<br>
Pour moi, remplacer un tag par un autre ne pose pas de problème<br>
technique dans la base OSM, ça peut se faire avec un bot, ou avec<br>
JOSM.<br>
<br>
Le problème c'est plutôt l'impact que ça a pour les utilisateurs des<br>
tags existants. Ils ne sont pas forcément identifiés. Ils ont peut<br>
être des applis qui dépendent du tag actuel.<br>
<br>
Pour moi le "il y en a trop" est lié à ça, il y en a trop non pas "à"<br>
changer, mais "pour" changer...<br>
<br>
<br>
Le 16 août 2013 23:09, Vincent Pottier <<a href="mailto:vpottier@gmail.com">vpottier@gmail.com</a>> a écrit :<br>
<div class="HOEnZb"><div class="h5">> Bonsoir,<br>
> Chose promise : chose due.<br>
> Quelques explications...<br>
> Après une discussion en mail privés, j'ai voulu tester la faisabilité d'une<br>
> migration power=tower -> man_made=power_tower. Parce que pour moi l'argument<br>
> "il y en a trop, on ne peut pas" ne me convainc pas. Au contraire...<br>
> Donc, j'ai testé... Certes l'échelle du test est grande, mais pas tant que<br>
> ça, peut-être...<br>
> Je ne sais pas combien il y a de power=tower en France... On attend le<br>
> réveil d'osm7.<br>
><br>
> Il y a plusieurs changesets concernés, plus que trois, du fait de problème<br>
> vers l'upload sur ma &£ø@% connexion. D'où aussi les heures tardives de<br>
> changeset (envoi un par un des objets...)<br>
><br>
> Ce que je voulais tester, c'est la possibilité avec JOSM, plutôt que par un<br>
> bot, ce qui ne sera jamais accepté, donc par une équipe de motivés.,<br>
> d'opérer la migration. Ce que je voulais tester, c'est l'utilisation du fait<br>
> que les power=line sont en réseau ou presque ( au niveau des sub_stations)<br>
> et comportent de nombreux nœuds power=tower.<br>
><br>
> Le test est confirmé. Il est assez facile de suivre le réseau électrique<br>
> pour charger les lignes, et les poteaux. C'est même assez ludique. Et le<br>
> résultat, le nombre, est impressionnant. Pour moi aussi.<br>
> Ce nombre, relativement important en peu de temps démontre que le "il y en a<br>
> trop, on ne peut pas" est très relatif !<br>
> CQFD !<br>
><br>
> Cependant, j'ai fait d'autres tests pour d'autres raisons, à cause d'autres<br>
> constats.<br>
> Certains repères géodésiques ont été repris directement comme pylônes. Ils<br>
> ont été surchargés, ou pas, du tag power=tower et on été intégrés dans les<br>
> lignes.<br>
><br>
> Ceci, d'une part, me semble fautif. Le repère géodésique est un élément du<br>
> pylône dont l'altitude est indiqué. Cette altitude n'est pas celle du poteau<br>
> lui-même. Le tag ele se rapporte au repère et en aucun cas à la base du<br>
> poteau.<br>
> Cette façon de procéder me semble devoir être corrigée.<br>
><br>
> Dans mes tests, j'ai donc cherché à éliminer les power=tower ne comportant-<br>
> pas de tag man_made=geodesic_survey, afin de ne pas écraser ce tag par ma<br>
> surcharge. C'est assez facile. JOSM dispose d'excellents outils pour ça.<br>
><br>
> J'ai chercher dans les tests suivants (et oui, les idées viennent les unes<br>
> après les autres) à copier ces repères géodésiques intégrés comme pylônes à<br>
> des lignes, à les coller dans un nouveau calque pour les dissocier des<br>
> lignes hautes tensions, afin de transformer les nœuds d'origine en simples<br>
> pylônes.<br>
> Facile à première vue. D'autant que la sélection est persistante dans le<br>
> calque d'origine.<br>
> Mais nombre de ces repères géodésiques sont intégrés à des relations<br>
> "sites", le copier-coller dans un nouveau calque perd cette intégration et<br>
> c'est un simple pylône qui se trouve dans le site.<br>
> L'autre voie, garder le repère dans le calque d'origine et créer le pylône<br>
> dans un nouveau calque est encore plus problématique. Il faut extraire le<br>
> nœud du way pour le remplacer par un nouveau nœud sans changer de place ni<br>
> l'un ni l'autre.<br>
><br>
> Bref, dans la migration, ce sont ces pylônes réemployant les repères<br>
> géodésiques qui sont problématiques.<br>
> Comme quoi l'erreur augmente la complexité. Comme quoi les choses claires et<br>
> simples sont plus faciles à traiter. Comme quoi "man_made=power_tower" c'est<br>
> quand même une bonne idée parce qu'elle est simple et claire.<br>
> Un petit outil d'aide à la substitution serait le bien-venu.<br>
> Sinon, il faudra traiter 'a la mano' ces cas.<br>
><br>
> Dans les tests, il me fallait suffisamment de données pour être sur d'avoir<br>
> des "cas" (repères avec ou sans tag power=tower, repères intégrés ou non<br>
> dans des sites) dans mon échantillon. Et, vous avez vu, on attrape vite de<br>
> la donnée en suivant le réseau.<br>
><br>
> Je ne suis pas très sur du premier test (le premier changset taggé<br>
> man_made=power_tower). Je ne crois pas avoir écrasé de tag<br>
> "geodesic_survey". Mais... Peut-être devra-t-il être reverté par prudence.<br>
> Et je ne sais pas reverter un changeset.<br>
><br>
> Les changesets suivant, je suis assez sur de ne rien avoir supprimé comme<br>
> donnée. L'objectif étant de tester, dans un premier, temps la surcharge.<br>
> Si cette surcharge gêne du monde et empêche certains de dormir. je ne<br>
> m'opposerai pas au revert.<br>
><br>
> Avec mes petits bras, en un rien de temps, j'ai fait beaucoup de changements<br>
> ?<br>
> Non, je ne prétendais pas changer en force à moi tout seul les 4 ou 5<br>
> millions d’occurrences.<br>
> Mais pour moi, la preuve est faite que le nombre d’occurrences (pour ce tag<br>
> distribué sur un réseau facile à suivre) n'est pas un problème. Même pas<br>
> peur...<br>
> Donc l'argument qui consiste à dire : "il faut de sacrés arguments pour un<br>
> tag tant employé..." est relatif, et même il peut se retourner contre lui<br>
> même : l'argument de cohérence est un argument en soi, d'autant plus<br>
> précieux qu'il porte sur de nombreux objets. Un truc pas très malin taggé<br>
> sur trois objets, ce n'est pas grave. Une amélioration de cohérence quand<br>
> elle porte sur des millions d'objets : c'est un sacré progrès. Après, le<br>
> frein, ce peut être la paresse, la peur, le manque d'imagination, le manque<br>
> de moyens humains ou techniques... je ne sais pas.<br>
><br>
> Certes, ma méthode heuristique des pylônes n'est pas exhaustive. Il restera<br>
> des bouts de lignes non migrés... Mais alors des requêtes xapis ou Osmose<br>
> pourront prendre le relais.<br>
><br>
> Encore mille excuses pour la surprise, pour l'émoi, le désagrément.<br>
> Et en même temps, un peu fier... malgré ma f... connexion, d'avoir obtenu un<br>
> tel résultat.<br>
> Encore une fois, libre à vous de reverter : je ne suis pas propriétaire.<br>
> --<br>
> FrViPofm<br>
><br>
> _______________________________________________<br>
> Talk-fr mailing list<br>
> <a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Christian Quest - OpenStreetMap France<br>
Un nouveau serveur pour OSM... <a href="http://donate.osm.org/server2013/" target="_blank">http://donate.osm.org/server2013/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>