Proj.4 / GDAL / QGIS Transformation entre CRS définis de la même manière

8

J'aide à faire en sorte que les logiciels open source puissent gérer correctement les nouvelles données de l'Australie, consultez le site Web de l'ICSM pour plus de détails sur le projet GDA2020.

Maintenant, QGIS a déjà inclus les définitions de GDA2020, via GDAL, je comprends.

Un exemple de système de référence de coordonnées GDA2020 est le suivant:

+proj=utm +zone=55 +south +ellps=GRS80 +units=m +no_defs

Et si vous regardez un CRS GDA94, il est défini comme ceci:

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Comme vous pouvez le voir, ceux-ci sont très similaires.

Maintenant, les deux CRS sont définis exactement de la même manière, mais il y a un changement de coordonnées dans GDA94 à GDA2020 d'environ 1,5 m au nord-est. (Il existe un fichier de décalage de grille au format NTv2 qui sera bientôt prêt et qui permettra des transformations précises, mais ce n'est pas de cela qu'il s'agit.)

Mais, si vous convertissez entre GDA94 et GDA2020 maintenant , en utilisant QGIS, il n'y a pas de changement de coordonnées. Il l'étiquette essentiellement différemment.

Devrait-il y avoir une transformation simple à 7 paramètres implémentée dans Proj.4 ou d'autres outils open source qui est la transformation par défaut (quoique imparfaite) entre GDA94 et GDA2020?

Ou est-ce simplement le cas que les outils ne changeront toujours pas?

Comment cela devrait-il être géré?

(Et je veux juste noter à nouveau que la transformation à l'aide d'une grille est idéale, et cela est géré de plusieurs manières, y compris ce plugin QGIS .)

qgis coordinate-system gdal proj gda2020 Alex Leith
la source
1
Pensez-vous qu'il serait préférable de ne pas attendre que la transformation NTv2 soit disponible, comme la transformation d'AGD66 en GDA94 (mais plus petite), si vous voulez faire quelque chose, faites-le bien ou pas du tout ... sinon vous finirez avec des coordonnées redéfinies au mauvais endroit, pas beaucoup mais toujours mal. Étant donné que GDA2020 n'est pas une donnée statique, il devrait sûrement y avoir une date définie dans le CRS quant au moment où la transformation des coordonnées a été appliquée.
Michael Stimson
Les autorités australiennes ont-elles fourni ces paramètres? S'ils ont un projet Proj4, vous pouvez les inclure en tant que paramètres + towgs84 mais les paramètres doivent avoir un statut officiel. Les utilisateurs peuvent naturellement utiliser + towgs84 comme ils le souhaitent.
user30184
Hé les amis, premièrement, les paramètres de + towgs84 devraient être 0,0,0,0,0,0,0,0, d'après ce que je comprends, car la différence entre les deux datums n'est pratiquement rien. Et les transformations NTv2 sont presque disponibles, et pas ce que je demande. Peut-être avez-vous raison, @MichaelStimson, en ce sens qu'il est préférable de NE PAS transformer une transformation imparfaite.
Alex Leith

Réponses:

4

Si vous effectuez une recherche dans GDA94CoordinateTransformation dans la base de données EPSG , vous obtenez:

  • Code de transformation EPSG:1150GDA94 en WGS84 (1) qui a des valeurs entièrement nulles
  • Code de transformation EPSG:8048GDA94 en GDA2020 (1) avec les 7 valeurs données par @ user30184

Il n'est donc pas nécessaire de prendre ceux pour GDA2020 à WGS84 (en prenant soin des panneaux et des unités!) Jusqu'à ce que le nouveau décalage de grille soit publié. Cela obtiendra un nouveau numéro de code de transformation.

Il existe actuellement un code de transformation EPSG:8049ITRF2014 à GDA2020 (1) indiquant que les deux sont égaux pour l'instant, avec des valeurs d'augmentation annuelles. Vous pouvez donc également respecter les délais de l'ITRF.

AndreJ
la source
Aha, merci @AndreJ, c'est la première partie de ma question. Et maintenant, que faudrait-il pour que cette transformation soit utilisée par défaut dans, disons, QGIS?
Alex Leith
Vous devez mettre en place un CRS personnalisé pour chaque CRS de base GDA2020. Notez que les valeurs de décalage sont en mm, alors que PROJ.4 attend des mètres. Vous pouvez également modifier le srs.db de QGIS, sans aucune garantie.
AndreJ
ITRF2014 et GDA2020 sera seulement égale momentanément le 1er janvier 2020. Comme GDA94 a été brièvement aligné avec ITRF92 en 1994. Si vous voulez une transformation précise pour tout le temps , mais l'époque 2020,0 alors vous devez faire une 4D transformation qui prend en compte les paramètres de dérive en fonction du temps. La transformation définie dans EPSG: 8049 dépend du temps et les versions récentes de pro.4 peuvent prendre en compte la différence entre l'époque d'alignement des données et le moment où vos données ont été capturées.
Rob
2

Tu as demandé:

Devrait-il y avoir une transformation simple à 7 paramètres implémentée dans Proj.4 ou d'autres outils open source qui est la transformation par défaut (quoique imparfaite) entre GDA94 et GDA2020? Ou est-ce simplement le cas que les outils ne changeront toujours pas? Comment cela devrait-il être géré?

La FAQ sur http://www.icsm.gov.au/gda2020/faq.html informe:

Les produits suivants seront disponibles:

  • Fichiers de grille de transformation et de distorsion 2D au format largement utilisé Canadian National Transformations version 2 (NTv2)
  • Transformation de 7 paramètres de similitude (casque)
  • Un fichier de grille de transformation 3D - format à déterminer.

Les valeurs prenant en charge la transformation des ensembles de données entre GDA2020 et ITRF2014 en utilisant soit un modèle de mouvement de plaque ou une transformation de similarité à 14 paramètres seront également publiées.

Ces informations seront fournies directement au Registre des paramètres géodésiques EPSG auquel les fournisseurs de logiciels et de matériel spatiaux du monde entier font référence avant d'incorporer les paramètres de transformation dans les logiciels et les micrologiciels.

Une fois que l'ICSM a publié les 7 paramètres de transformation de similarité des paramètres, vous pouvez commencer à les utiliser comme

+ proj = utm + zone = 55 + sud + ellps = GRS80 + towgs84 = [nouveaux paramètres] + unités = m + no_defs

Il semble qu'ils soient déjà publiés sur http://www.icsm.gov.au/gda2020/InterimReleaseNoteV1.0.pdf .

61,55, -10,87, -40,19, -9,994, -39,4924, -32,7221, -32,8979

Vous pouvez essayer avec ces paramètres + towgs84 mais je me souviens que Proj.4 peut vouloir certains paramètres avec signe inversé.

La création d'un ticket Proj.4 lorsque les paramètres sont officiellement disponibles peut accélérer le processus avec Proj.4 mais lorsque la base de données EPSG est mise à jour et que Proj.4 commence à utiliser cette nouvelle base de données, le changement peut se produire automatiquement. Cela dépend un peu de la façon dont GDA2020 sera implémenté dans la base de données EPSG et si un nouvel algorithme est nécessaire ou s'il s'agit simplement d'ajouter les paramètres towgs84.

user30184
la source
Vous devrez peut-être attendre un moment jusqu'à ce qu'une modification de la base de données EPSG trouve son chemin dans GDAL et PROJ.4. GDAL est actuellement (2.2.2) basé sur la base de données EPSG v9.0 de décembre 2016 trac.osgeo.org/gdal/ticket/6772 et ne sera pas mis à jour avant la v2.3.0. PROJ.4 est encore plus ancien: github.com/OSGeo/proj.4/issues/477 sera dans la prochaine version.
AndreJ
Hé @ user30184, je ne pense pas que le paramètre toWGS84 soit utilisé à cet effet. Le site Web Proj.4 indique que ce sont des paramètres pour transformer les coordonnées d'une donnée en référence WGS84, et avec les cas GDA94 et GDA2020, les références sont les mêmes que pour WGS84 (à toutes fins utiles), voir: proj.maptools .org / gen_parms.html . Ce qu'il faut, c'est un moyen de transformer entre deux CRS géodésiques qui sont définis avec le même ellipsoïde de référence, je pense. Et je note que les définitions de GDA2020 sont déjà dans le registre EPSG et dans des outils comme QGIS, donc il n'y a pas besoin d'attendre.
Alex Leith
Proj.4 utilise WGS84 comme référence provisoire. Si vous avez les paramètres + wgS84 d'un côté mais pas de l'autre, vous obtiendrez un décalage de référence. Essayez avec + towgs84 et communiquez vos résultats.
user30184
Hé, je suppose que ce que j'espère obtenir de cela est de s'assurer que ces paramètres de transformation (qui, comme @AndreJ l'a souligné font partie de la base de données EPSG) sont utilisés par défaut dans les outils open source. Je ferai un peu de lecture ...
Alex Leith
1

TLDR: Ce ne sont pas les mêmes. L'égalité déclarée est le résultat d'approximations et n'est vraie que dans des circonstances limitées. Les coordonnées GDA94 / 2020 sont définies sur différents référentiels et référentiels. La transformation appropriée entre eux dépend du niveau de précision souhaité.

Le problème ici est l'hypothèse de la question que proj.4 rapporte correctement les deux CRS (système de référence de coordonnées) comme étant les mêmes. Ils ne sont pas. Les chaînes proj.4 citées ne sont pas les définitions CRS. Ils sont générés à partir de la définition CRS, et les chaînes proj.4 ne sont pas l'image complète. Les définitions du registre EPSG nous fournissent les informations supplémentaires dont nous avons besoin pour comprendre ce qui se passe réellement.

Cela découle d'une vision du monde selon laquelle le WGS-84 est «la» donnée globale et historiquement proj.4 l'a utilisé comme intermédiaire lors de la conversion entre les références. Le fait est que le WGS-84 est redéfini toutes les quelques années ( nous sommes maintenant au G1762, aligné sur ITRF-08 ) car il est réaligné avec les changements dans le cadre de référence ITRF, dont GDA est également dérivé.

Cela a conduit à ces raccourcis et hypothèses dans le comportement de proj, bien que dans les versions récentes, cela commence à changer.

Le suivi des implications des modifications apportées aux cadres de référence, et quand ils ont changé n'était pas un gros problème alors que le GPS grand public était> 5 m de précision, mais les temps changent et la précision du sous-mètre nécessite des outils pour les prendre en compte correctement.

Donc, pour répondre à la question, nous devons tracer les bases de données et les référentiels sur lesquels sont basés les CRS GDA94 et GDA2020, puis voir quelles sont les transformations disponibles.

  • EPSG:7844 GDA2020 2D Geographic CRS (Lat / Lon), de
  • EPSG:7843 GDA2020 3D Geographic CRS (L / L / H), de
  • EPSG:7842 GDA2020 3D géocentrique (ECEF X / Y / Z), qui utilisent tous
  • EPSG: 1168 (datum) - Datum géocentrique de l'Australie, 2020

EPSG: 1168 définit son cadre de référence d'ancrage:

  • Définition de l'ancre: ITRF2014 à l'époque 2020.0
  • Époque de réalisation: 2020-01-01

Si vous faites de même pour GDA94, vous verrez que le cadre de référence est ITRF92, aligné le 01/01/1994.

En cas de transformation entre les données ITRF02 / 14 et GDA94 / GDA2020, les références sont alignées et la transformation entre elles se fait null uniquement à la date d'alignement de l'époque. C'est essentiellement ce que disent ces chaînes de projet. Pour plus de commodité, nous n'aimons généralement pas avoir à changer constamment les coordonnées que nous stockons, il est donc plus simple de modifier progressivement la dérive entre elles toutes les quelques années et d'accepter un niveau d'erreur.

Pour la plupart des applications nécessitant une précision> 1 m, cela suffit.

Mais la réalité ne change pas toutes les quelques années et si nous voulons une transformation plus précise, nous devons tenir compte de la dérive de la distance en fonction du temps des références avant / après leur alignement. C'est une transformation 4D plutôt que 3D.

Les transformations entre GDA2020 et WGS-84 ou ITRF2014 sont décrites dans:

  1. GDA2020 à WGS 84 (G1762) (1) - EPSG: 8448
  2. ITRF2014 à GDA2020 (1) - EPSG: 8049

En cas de transformation entre GDA94 et GDA2020, les choses sont plus simples car il suffit de connaître la différence entre les référentiels. Sorte de. Il y en a plusieurs, et la bonne à utiliser dépend du moment, de la manière et de l'endroit où les données ont été référencées à GDA94. C'est une tentative pour éliminer les erreurs dues à des méthodes moins raffinées utilisées dans les années 90.

Ceux-ci sont:

  • Conformal - Rotation coordonnée du cadre (1) - EPSG: 8048
  • Distorsion localisée (2) - EPSG: 8447
  • Conformal - Transformation de grille NTv2 (3) - EPSG: 8446

Pour comprendre dans quelles circonstances celles-ci doivent être utilisées, lisez le manuel technique GDA2020

Rob
la source
0

En s'appuyant sur les réponses précédentes, la définition de proj4 ressemble à ceci:

+proj=longlat +ellps=GRS80 +towgs84=-0.06155,0.01087,0.04019,-0.0394924,-0.0327221,-0.03289790,0.009994 +no_defs

Vous pouvez ensuite l'utiliser sur n'importe quelle zone de grille projetée standard en ajoutant simplement le paramètre towgs84. par exemple

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=-0.06155,0.01087,0.04019,-0.0394924,-0.0327221,-0.03289790,0.009994 +units=m +no_defs

Pour obtenir les bons nombres de la section 3.1 de la spécification, vous inversez d'abord le signe des paramètres de rotation (comme discuté dans la section 2.2.1), puis inversez tout parce que les paramètres de la spécification sont la transformation de WGS / GDA94 et nous voulons la transformation en WGS pour la définition de proj4. Donc, fondamentalement, tout sauf les rotations dans la spécification a son signe inversé.

La seule autre chose à surveiller est que pour proj4, l'échelle est le dernier paramètre.

Les puristes suggéreront d'utiliser l'approche de décalage de grille NtV2 mais ces fichiers sont très gros et j'ai trouvé que ce qui précède donne une précision meilleure que 5 cm en utilisant des données d'échantillonnage pour Victoria. Je voulais également une solution qui fonctionnerait avec proj4js.

JohnGom
la source