On 06/09/2019 05:42, osm.sanspourr...@spamgourmet.com wrote:
Le 06/09/2019 à 12:04, Stéphane Péneau - stephane.pen...@wanadoo.fr a
écrit :
Le 06/09/2019 à 11:14, Eric SIBERT via Talk-fr a écrit :
Pour le fond du problème, mon avis est que OSM est un projet mondial
et qu'il faut rester avec une référence globale, à savoir WGS84 mais
en précisant bien que c'est dans sa réalisation actuelle. Les
données dans des références locales doivent alors être converties en
WGS84(réalisation actuelle). Quand il y a un changement de
réalisation de WGS84, il faut convertir les coordonnées dans la base
OSM de l'ancienne à la nouvelle réalisation de WGS84 (ou au moins le
faire dans les zones où la dérive des plaques est plus grande que
l'incertitude sur les données sources du coin).
Les nouvelles réalisations du WGS84 n'ont pas de rapport avec le
déplacement des plaques.
Si entre 2 réalisations, ma plaque s'est déplacée de 10 mètres (c'est
un exemple irréaliste), transformer les coordonnées de l'ancienne à
la nouvelle réalisation ne corrigera pas le décalage de 10 mètres.
Stf
Je suppose qu'Eric veut dire que les "anciennes" données étaient de
facto mettons en GDA94 et qu'elles doivent être reprojetées en GDA2020.
Ce qui revient à dire qu'on travaille en coordonnées locales...
Jean-Yvon
Merci pour vos réponses!
Petit complément, pour y voir plus clair :p (ça me fait des nœuds dans
la tête depuis quelques temps)
Imaginons que je transforme les données dans la dernière réalisation du
WGS84 (G1762). Cette réalisation date de 2013 et est basée sur
l'ITRF2008, qui se lock à l'époque 2005. Sachant que la plaque
polynésienne a bougé de 2m depuis le début du système RGPF (en 93 à peu
près) , ça nous fait un décalage déjà d'un peu plus d'1m depuis 2005
(ça rejoint les 7cm/an de wikipédia). Donc une simple reprojection dans
la dernière réalisation du WGS84 me parait pas suffisante. Il faudrait
ajouter les translations de plaques / associer à l'époque courante. Et
la...imaginons que je le fasse (et que je trouve les vrais bons
paramètres.. :o) , qui dans les collectivités locales et utilisateurs de
la donnée qui en ont besoin en référentiel local, va faire la bonne
transformation inverse? Notamment car la transfo de base WGS84 qu'on
trouve dans QGis et autres outils SIG (4326) est décalé du RGPF de 30 à
50cm uniquement. Ca voudrait dire -toujours pour moi, je peux me
tromper- que si les gens font la transfo inverse avec cette définition
du WGS84 il seront dans les 1.5m à côté (de la plaque!!).
Donc si on va plus loin et qu'on veut les données issues de plusieurs
contributeurs à différentes époques... Qui va vraiment reprojeter en
récupérant les époques des dates de contribution? J'ai des grosgros
doutes la dessus. Après yen a qui diront qu'on n'a pas besoin de ce
niveau de précision, mais pour moi c'est un sujet et surtout l'intérêt
de garder la précision des données de base. Ce serait dommage de perdre
du décimètre de précision pour des questions de projection.
Mon autre problème pour simplifier les choses, ici en Polynésie
française le système local (RGPF) est basé sur l'ITRF92 mais il ya des
différences en local en fonction des iles (toutes les iles ne sont pas
directement associées à l'itrf 92)
Après je suis daccord avec toi Eric, que ce serait mieux de rester dans
un système global commun, mais la c'est comme si on en a tout pleins
avec toutes les époques du WGS84. Donc c'est pas bon pour moi non plus.
Donc pourquoi pas rester en local? On pourrait avoir une base de données
de systèmes locaux utilisée dans OSM, ça me paraîtrait plus juste, et
moins source d'erreurs. Les applis n'auraient "/qu/"'à récupérer les
données et les reprojeter en fonction de la zone ou l'on se trouve,
l'époque... \o/
Ensuite il y a quelque chose que je ne comprends pas, c'est la relation
entre le systeme wgs84 dispo sous qgis et la dernière révision du
wgs84... je vois pas le lien, je comprends pas de quelle révision on
parle dans qgis... :/
@+
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
--
Violaine_Do
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
