Salut Marc,
Je vois bien que tous les pays n'ont pas accès à une ortho de la qualité
de celle de l'Ign, mais est-ce que ça veut dire que je suis tombé sur
les 2 seuls cas (France + Sud-Est de l'Australie) où le problème est
clairement visible ?
Pour le savoir, la meilleure solution est de compléter le tableau de
cette page wiki. Il faut plus de repères dans plus de pays :
https://wiki.openstreetmap.org/wiki/Survey_points_on_aerial_imagery
Mais bon, admettons que pour le moment ce soient effectivement les 2
seules zones où on constate une erreur de système de référence. Faut-il
pour autant l'ignorer ?
Je ne pense pas car... sinon je n'aurais pas écrit cet article :-)
Plus sérieusement, le cas de l'Australie va réellement poser problème
dans les mois à venir. Presque 2 mètres d'écart, ce n'est pas
négligeable. Et laisser les contributeurs de ces zones déplacer
manuellement l'ensemble des noeuds lorsque les images calées en GDA2020
vont arriver, ça me parait être une monstrueuse perte d'énergie. Il y a
bien mieux à faire...comme recaler correctement ce qui ne l'est pas
aujourd'hui.
N'oublions pas qu'il y a moins de 10 ans, on traçait sur une imagerie
Yahoo avec souvent des difficultés pour repérer les petites routes.
Aujourd'hui on pourrait dessiner individuellement les pointillés des
lignes centrales. Les progrès sont très très rapides.
Ensuite, il y a le problème de la cohérence entre ce qui affiché
(Osm=WGS84), et la réalité des données.
Pour répondre à ta question, à première vue, je pense qu'accepter
officiellement les systèmes de référence locaux est bien plus simple,
s'ils ne sont pas trop nombreux.
A ce sujet, dans les commentaires, Cameron Shorter parle de son travail
sur sa tentative de création d'un nouveau "datum global" qui serait un
ensemble des datum locaux :
https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0
Ce pourrait être une bonne solution.
Si on part sur une BDD à 100% en WGS84, ça implique pas mal de travail
pour les éditeurs comme Josm qui vont devoir au strict minimum déplacer
de manière permanente les imageries aériennes pour qu'elles se calent
sur la réalité. Et ce minimum, c'est si un robot se charge de déplacer
progressivement les données dans la BDD, avec les problèmes que ça
implique, comme la gestion de l'historique, la comparaison des données
entre plusieurs années, etc...
S'il n'y a pas de robot, et que c'est aux éditeurs de prendre en compte
le timestamp d'origine de chaque node pour le recaler où il faut à la
date du jour en fonction de la modélisation du déplacement de la
plaque..... Au secours !!
Stf
Le 18/07/2019 à 23:27, marc marc a écrit :
Bonjour Stephane,
article bien intéressant.
mais je crains que le niveau moyen d'alignement soie à des km de là :
- utilisation de Bing et autre ortho mal corrigé
- non alignement de l'imagerie avec les objets existant, y compris les
offset permanent de plusieurs d'entre elles
- non alignement du cadastre et/ou difficulté de renseigné une anomalie
cadastre pour que le contributeur suivant (éventuellement débutant) ne
sache au lieu de "corriger" un positionnement correct avec un cadastre
erroné.
- non disponibilité (licence ou import non fait) des repères géodésiques
dans de nombreux pays, rendant un réalignement précis difficile.
quand je vois une route qui traverse un batiment à cause d'une des
raisons ci-dessus, c'est malheureusement là que le + gros reste à faire
mais sinon,quel solution te semble réaliste ?
Le 18.07.19 à 18:38, Stéphane Péneau a écrit :
https://www.openstreetmap.org/user/StephaneP/diary/390290
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
