Transformation du système de coordonnées Geobide, ED50 et ETRS89

Profiter pour suivre la capacités de la suite Geobide, nous verrons les options pour transformer Systèmes de référence. Intéressant pour ceux qui doivent se transformer entre différents Datum, dans ce cas, nous verrons comment le faire avec les systèmes ED50 et ETRS89 qui est presque le même cas en Amérique latine entre NAD27 et WGS84.

Les données sont-elles déplacées?

Ce n'est pas le cas de Google Earth, où plus de transformations sont faites, les nombreuses images sont déplacées, quelque chose qui peut être vérifié dans des chevauchements entre différentes prises; Cependant, dans de nombreux pays, états ou communautés autonomes, les institutions publiques ont fourni à GoogleEarth leurs images avec une géoréférence précise, avec l'inconvénient que GoogleEarth utilise WGS84 comme Datum générique, donc l'utilisation de données dans un autre système nécessite une transformation. La transformation dépend tout d'abord de sa propre définition mais aussi du domaine dans lequel on se trouve. C'est pourquoi les systèmes génériques ne fournissent pas les paramètres spéciaux de chaque zone.

Prenons comme exemple la transformation ED50-30N (EPSG: 23030) en ETRS89-30N (EPSG: 25830) pour la Navarre et pour l'Espagne. La définition générique de la transformation a un degré de précision différent selon la zone dans laquelle elle est appliquée. Pour cette raison, il existe des paramètres supplémentaires, qui ne rentrent pas dans la définition générique et qui en Navarre par exemple en sont certains, mais dans les Asturies, ils peuvent avoir d'autres valeurs différentes.

Si nous regardons l'image ci-dessus capturée à partir de Geomap, nous voyons une carte avec deux couches (orthophoto et parcelle) déplacées l'une par rapport à l'autre. C'est le résultat de la projection à la volée du Cadastre de Navarre en ED-50N sur une couche de GoogleMaps dans WGS84 et le décalage résultant est lié au problème décrit dans le paragraphe précédent.

Un récent tutoriel Geobide, à partir duquel nous faisons cet article, publie maintenant au moins 4 méthodes pour y remédier. Avec Geobide, il est désormais possible d'indiquer la conversion de datum pour une transformation entre systèmes de coordonnées de quatre manières différentes:

1. Transformation générique:

Cette option utilise une transformation générique sans paramètres spatiaux et est la moins précise. Pour Navarra par exemple, passer d'ED50 à ETRS89 a une erreur de ~ 100-200m dans x et y. (En se rappelant que cela N'Affiche PAS les systèmes de coordonnées avec des données égales).

Tout à fait similaire est le cas de NAD27 avec WGS84 marche et 202 mètres au nord et 6 mètres à l'est dans les changements de la zone centrale que vous changez la latitude, mais il est significatif que dans la latitude de l'Equateur vient tout la longueur vient du faux-est.  

2. Transformation à l'aide d'une grille NTv2:

Cette option utilise une grille avec des valeurs pour corriger la conversion par interpolation linéaire. Cette option est plus précise que la première méthode et a été adoptée par l'IGN. Précis, bien sûr, si nous avons une grille pour notre zone de travail.

Les applications de Geobide Ils proposent désormais les deux grilles fournies par l'IGN pour l'Espagne, couvrant la péninsule et les Baléares, et qui ont été publiées en 2003 et 2009. L'utilisateur peut facilement choisir la grille à utiliser.

De nombreuses grilles peuvent être trouvées sur Internet, même dans le monde entier, mais par taille elles ne sont pas automatiquement disponibles dans les téléchargements de l'application Geobide.

3. Transformation Molodensky (méthode des paramètres 3):

3 utilise des valeurs de décalage à l'origine entre les ellipsoïdes. Un assistant préconfiguré recommandé par le IGN pour l'Espagne.

4. 
   

   Transformation Bursa-Wolf (méthode des paramètres 7)

Cette transformation utilise les valeurs 7 pour se transformer entre les ellipsoïdes. Les paramètres à saisir sont: Offset (Dx, Dy, Dz), Rotation (Rx, Ry, Rz) et Facteur de mise à l'échelle (μ)

Dans les applications Geobide Les assistants 3 sont préconfigurés par les IGN pour le nord-ouest, la zone centrale et l'est de la péninsule, respectivement.

Résultats

Comme vous pouvez le voir, les résultats ne varient pas beaucoup entre les dernières méthodes 3, mais oui avec le premier. C'est pourquoi vous devez savoir si la transformation nécessite l'une de ces options avancées.

Parmi les ED50-xxn (EPSG: 230xx) systèmes et ETRS89-xxn (EPSG: 258xx) dans la région de l'Espagne elle-même devrait être utilisé comme les Datums / ellipsoïdes ED50 et ETRS89 / WGS84 ne sont pas équivalents.

Par exemple, si Géocarte pas ces ensembles de données avancées, les données de Navarra dans ED50-30N (EPSG: 23030) reprojetées à la volée sur les données fournies par Google Maps (ellipsoïde WGS84) sera déplacé. Pour qu'ils aient l'air bien, il faut utiliser les transformations les plus précises qui ont déjà été expliquées.

Il me semble très bien que Geobide fait un effort important non seulement pour laisser les capacités à son système, mais aussi pour documenter un peu plus en détail cette question, car cela peut affecter beaucoup la qualité et la précision du travail, en plus de simplement le comprendre aussi est un autre effort.

Jusqu'à présent, tout cela a été automatiquement intégré dans le moteur, mais comme nous l'ont dit les amis de Geobide, les exigences des utilisateurs ont permis de le rendre visible dans les applications afin que l'utilisateur lui-même soit conscient et même change le ou définir un autre pour votre propre zone de travail.

Transformation des hauteurs ellipsoïdales / géoïdiennes

Dans la nouvelle version, la boîte de calcul de la différence de hauteur ellipsoïdale / géoïde a également été modifiée afin que l'utilisateur puisse maintenant sélectionner le modèle de géoïde à utiliser.

Nomenclatures des fichiers PRJ

Et enfin, un autre changement qui semble juste dans votre effort d'interopérabilité avec les normes OGC ou les pratiques de programmes vulgarisés. Les fichiers PRJ générés par Geobide sont dans la nomenclature OGC WKT, qui est une norme reconnue par de nombreux outils de CAO / SIG. Ce n'est pas le cas pour les applications ESRI, dont les PRJ, bien qu'elles contiennent la même définition mathématique que les normes, dénomment différemment les systèmes de coordonnées.

Par exemple:

Dans le contenu d'un fichier PRJ OGC, le système ETRS89-30N (EPSG: 25830) est défini par le nom de code "zone ETRS89 / UTM 30N"; les applications Esri, à la place, ils l'appellent "ETRS_1989_UTM_Zone_30N". Si dans ArcGis nous mélangeons des couches avec des PRJ dans les deux nomenclatures, ce logiciel effectuera la transformation spatiale même lorsque la définition mathématique des systèmes de coordonnées est identique.

Prêter attention à cela entêtement, Geobide a activé une nouvelle option dans le sélecteur de système de référence afin que l'utilisateur puisse indiquer s'il veut un système de coordonnées avec un PRJ en style ou style EPSG Esri.

http://www.geobide.es/