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
