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
