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