[OSM-talk-fr] Systèmes géodésiques et OSM

[Violaine_Do]

On 06/09/2019 05:42, osm.sanspourriel at spamgourmet.com wrote:
>
> Le 06/09/2019 à 12:04, Stéphane Péneau - stephane.peneau at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Violaine_Do

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20190906/cf0226f1/attachment.htm>