Proj.4 / GDAL / QGIS Transformación entre CRS que se definen igual

8

Estoy ayudando a garantizar que el software de código abierto pueda manejar el nuevo dato de Australia de manera adecuada, consulte el sitio web de ICSM para obtener detalles sobre el proyecto GDA2020.

Ahora, QGIS ya tiene las definiciones de GDA2020 incluidas, a través de GDAL, entiendo.

Un ejemplo del sistema de referencia de coordenadas GDA2020 es este:

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

Y si nos fijamos en un CRS GDA94, se define así:

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

Como puede ver, estos son muy similares.

Ahora, los dos CRS se definen exactamente igual, pero hay un cambio en las coordenadas en GDA94 a GDA2020 de aproximadamente 1,5 m hacia el noreste. (Hay un archivo de cambio de cuadrícula en formato NTv2 que pronto estará listo que permitirá transformaciones precisas, pero de eso no se trata esta pregunta).

Pero, si convierte entre GDA94 y GDA2020 ahora , usando QGIS, no hay cambio en las coordenadas. Esencialmente solo lo etiqueta de manera diferente.

¿Debería haber una transformación simple de 7 parámetros implementada en Proj.4 u otras herramientas de código abierto que sea la transformación predeterminada (aunque imperfecta) entre GDA94 y GDA2020?

¿O es simplemente el caso de que las herramientas siempre no cambiarán?

¿Cómo debería ser manejado?

(Y solo quiero señalar nuevamente que la transformación utilizando una cuadrícula es ideal, y eso se maneja de varias maneras, incluido este complemento QGIS ).

qgis coordinate-system gdal proj gda2020 Alex Leith
fuente
1
¿Crees que sería mejor esperar hasta que la transformación NTv2 esté disponible, como la transformación de AGD66 a GDA94 (pero más pequeña), si vas a hacer algo, hazlo bien o no lo hagas? De lo contrario, terminarás arriba con coordenadas redefinidas en el lugar equivocado, no por mucho pero aún así equivocado Teniendo en cuenta que GDA2020 no es un dato estático, seguramente debería haber una fecha definida en el CRS en cuanto a cuándo se aplicó la transformación de coordenadas.
Michael Stimson el
¿Han proporcionado las autoridades australianas esos parámetros? Si tienen un proyecto Proj4, pueden incluirlos como parámetros + towgs84, pero los parámetros deben tener un estado oficial. Los usuarios pueden usar naturalmente + towgs84 como lo deseen.
user30184
Hola amigos, en primer lugar, los parámetros + towgs84 deberían ser 0,0,0,0,0,0,0, según tengo entendido, porque la diferencia entre los dos datos es prácticamente nula. Y las transformaciones NTv2 están casi disponibles, y no es lo que estoy preguntando. Quizás tengas razón, @MichaelStimson, en que NO hacer una transformación es mejor que hacer una imperfecta.
Alex Leith

Respuestas:

4

Si busca en la base de datos EPSG para GDA94CoordinateTransformation, obtiene:

  • Código de transformación EPSG:1150GDA94 a WGS84 (1) que tiene valores todos cero
  • Código de transformación EPSG:8048GDA94 a GDA2020 (1) con los 7 valores dados por @ user30184

Por lo tanto, es seguro llevarlos para GDA2020 a WGS84 (¡cuidando los letreros y las unidades!) Hasta que se publique el nuevo cambio de cuadrícula. Eso obtendrá un nuevo número de código de transformación.

Actualmente hay un código de transformación EPSG:8049ITRF2014 a GDA2020 (1) que establece que ambos son iguales por ahora, con valores de aumento anual. Por lo tanto, también podría aprovechar los plazos de ITRF.

AndreJ
fuente
Ajá, gracias @AndreJ, esa es la primera parte de mi pregunta. Y ahora, ¿qué se necesitaría para que esta transformación se use como predeterminada en, por ejemplo, QGIS?
Alex Leith
Debe colocar un CRS personalizado para cada CRS basec GDA2020. Tenga en cuenta que los valores de desplazamiento están en mm, mientras que PROJ.4 espera metros. También puede editar el srs.db de QGIS, sin ninguna garantía.
AndreJ
ITRF2014 y GDA2020 serán solamente momentáneamente iguales el 1 de enero de 2020. Al igual que GDA94 fue alineado brevemente con ITRF92 en 1994. Si desea transformar un preciso para cualquier momento, pero la época 2020.0, entonces usted necesita para hacer una transformación de 4D que tenga en cuenta los parámetros de deriva dependientes del tiempo. La transformación definida en EPSG: 8049 depende del tiempo, y las versiones recientes de pro.4 pueden tener en cuenta la diferencia entre la época de alineación de datos y cuándo se capturaron sus datos.
Rob
2

Tu preguntaste:

¿Debería haber una transformación simple de 7 parámetros implementada en Proj.4 u otras herramientas de código abierto que sea la transformación predeterminada (aunque imperfecta) entre GDA94 y GDA2020? ¿O es simplemente el caso de que las herramientas siempre no cambiarán? ¿Cómo debería ser manejado?

Las preguntas frecuentes en http://www.icsm.gov.au/gda2020/faq.html informan:

Los siguientes productos estarán disponibles:

  • Transformación 2D y archivos de cuadrícula de distorsión en el ampliamente utilizado formato de Transformaciones Nacionales Canadienses versión 2 (NTv2)
  • Transformación de similitud de 7 parámetros (casco)
  • Un archivo de cuadrícula de transformación 3D: formato aún por determinar.

También se publicarán valores que respalden la transformación de conjuntos de datos entre GDA2020 e ITRF2014 utilizando un modelo de movimiento de placa o una transformación de similitud de 14 parámetros.

Esta información se proporcionará directamente al Registro de parámetros geodésicos de EPSG al que hacen referencia los proveedores de software y hardware espacial de todo el mundo antes de incorporar parámetros de transformación en software y firmware.

Una vez que ICSM haya publicado los 7 parámetros de transformación de similitud de parámetros, puede comenzar a usarlos como

+ proj = utm + zone = 55 + south + ellps = GRS80 + towgs84 = [nuevos parámetros] + unidades = m + no_defs

Parece que ya están publicados en http://www.icsm.gov.au/gda2020/InterimReleaseNoteV1.0.pdf .

61.55, -10.87, -40.19, -9.994, -39.4924, -32.7221, -32.8979

Puede probar con estos parámetros + towgs84, pero recuerdo que el Proj.4 puede querer algunos de los parámetros con signo invertido.

Hacer un ticket del Proj.4 cuando los parámetros están oficialmente disponibles puede acelerar el proceso con el Proj.4, pero cuando la base de datos EPSG se actualiza y el Proj.4 comienza a usar esa nueva base de datos, el cambio puede ocurrir automáticamente. Depende un poco de cómo se implementará GDA2020 en la base de datos EPSG y si se necesita un nuevo algoritmo o si solo se trata de agregar los parámetros de towgs84.

usuario30184
fuente
Puede que tenga que esperar un tiempo hasta que un cambio en la base de datos EPSG llegue a GDAL y PROJ.4. GDAL está actualmente (2.2.2) basado en la base de datos EPSG v9.0 de diciembre de 2016 trac.osgeo.org/gdal/ticket/6772 y no se actualizará hasta la v2.3.0. PROJ.4 es aún más antiguo: github.com/OSGeo/proj.4/issues/477 estará en la próxima versión.
AndreJ
Hola @ user30184, no creo que el parámetro toWGS84 se use para este propósito. El sitio web del Proj.4 dice que estos son parámetros para transformar coordinadores en un dato en el dato WGS84, y con el caso GDA94 y GDA2020, los datos son los mismos que para WGS84 (para todos los propósitos y propósitos), ver: proj.maptools .org / gen_parms.html . Lo que se necesita es una forma de transformar entre dos CRS geodésicos que se definen con el mismo elipsoide de referencia, creo. Y noto que las definiciones de GDA2020 están en el registro EPSG y en herramientas como QGIS ya, así que no hay necesidad de esperar.
Alex Leith
El Proj.4 está utilizando WGS84 como dato provisional. Si tiene parámetros + wgS84 en un lado pero no en el otro, obtendrá un cambio de referencia. Pruebe con + towgs84 e informe sus resultados.
user30184
Oye, supongo que lo que espero lograr de esto es asegurarme de que estos parámetros de transformación (que, como ha señalado @AndreJ son parte de la base de datos EPSG) se usen por defecto en las herramientas de código abierto.
Alex Leith
1

TLDR: No son lo mismo. La igualdad informada es el resultado de aproximaciones y solo es cierta en circunstancias limitadas. Las coordenadas GDA94 / 2020 se definen en diferentes datos y marcos de referencia. La transformación apropiada entre ellos depende del nivel de precisión deseado.

El problema aquí es la suposición en la pregunta de que el proyecto 4 informa correctamente que los dos CRS (sistema de referencia de coordenadas) son iguales. Ellos no están. Las cadenas del proyecto 4 citadas no son las definiciones de CRS. Se generan a partir de la definición de CRS, y las cadenas del proyecto 4 no son la imagen completa. Las definiciones de registro EPSG nos brindan la información adicional que necesitamos para comprender lo que realmente está sucediendo.

Esto se deriva de una visión del mundo de que WGS-84 es 'el' dato global e históricamente el proyecto 4 lo ha utilizado como intermediario al convertir entre datums. La cuestión es que WGS-84 se redefine cada pocos años ( ahora estamos en G1762, alineado con ITRF-08 ), ya que se vuelve a alinear con los cambios en el marco de referencia de ITRF, del que también se deriva GDA.

Esto ha llevado a que estos atajos y suposiciones formen parte del comportamiento del proyecto, aunque en versiones recientes esto está comenzando a cambiar.

El seguimiento de las implicaciones de los cambios en los marcos de referencia, y cuando cambiaron no fue un gran problema, mientras que el GPS del consumidor tenía una precisión> 5m, pero los tiempos están cambiando y la precisión del submedidor requiere herramientas que los justifiquen adecuadamente.

Entonces, para responder a la pregunta, necesitamos rastrear en qué datum y marcos de referencia se basan GDA94 y GDA2020 CRS y luego ver qué transformaciones disponibles hay.

  • EPSG:7844 GDA2020 2D Geographic CRS (Lat / Lon), desde
  • EPSG:7843 GDA2020 3D Geographic CRS (L / L / H), desde
  • EPSG:7842 GDA2020 3D Geocéntrico (ECEF X / Y / Z), todos los cuales usan
  • EPSG: 1168 (dato) - dato geocéntrico de Australia, 2020

EPSG: 1168 define su marco de referencia de anclaje:

  • Definición de anclaje: ITRF2014 en la época 2020.0
  • Época de realización: 01-01-2020

Si hace lo mismo para GDA94, verá que el marco de referencia es ITRF92, alineado el 01/01/1994.

Si se transforma entre datos ITRF02 / 14 y GDA94 / GDA2020, los datos se alinean y la transformación entre ellos null solo se realiza en la fecha de alineación de época. Eso es esencialmente lo que dicen esas cadenas de proyectos. Por conveniencia, generalmente no nos gusta tener que cambiar constantemente las coordenadas que almacenamos, por lo que es más sencillo cambiar la deriva entre ellas cada pocos años y aceptar un nivel de error.

Para la mayoría de las aplicaciones que requieren una precisión> 1m, eso es lo suficientemente bueno.

Pero la realidad no cambia paso a paso cada pocos años y si queremos una transformación más precisa, debemos considerar la deriva de la distancia dependiente del tiempo de los datos antes / después de su alineación. Es una transformación 4D en lugar de 3D.

Las transformaciones entre GDA2020 y WGS-84 o ITRF2014 se describen en:

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

Si se transforma entre GDA94 y GDA2020, las cosas son más simples ya que solo necesitamos saber la diferencia entre los marcos de referencia. Algo así como. Hay más de uno, y el correcto para usar depende de cuándo, cómo y dónde se referenciaron los datos a GDA94. Es un intento de eliminar errores debido a métodos menos refinados que se utilizaron en los años 90.

Estos son:

  • Conformal - Rotación de trama de coordenadas (1) - EPSG: 8048
  • Distorsión localizada (2) - EPSG: 8447
  • Conformal - Transformación de cuadrícula NTv2 (3) - EPSG: 8446

Para comprender en qué circunstancias se deben usar, lea el manual técnico GDA2020

Robar
fuente
0

Sobre la base de respuestas anteriores, la definición de proj4 se ve así:

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

Luego puede usar esto en cualquiera de las zonas de cuadrícula proyectadas estándar simplemente agregando el parámetro towgs84. p.ej

+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

Para obtener los números correctos de la sección 3.1 de la especificación, primero invierta el signo de los parámetros de rotación (como se discutió en la sección 2.2.1), pero luego invierta todo porque los parámetros en la especificación son la transformación de WGS / GDA94 y queremos la transformación a WGS para la definición proj4. Entonces, básicamente, todo excepto las rotaciones en la especificación tienen su signo invertido.

La única otra cosa a tener en cuenta es que para proj4 la escala es el último parámetro.

Los puristas sugerirán usar el enfoque de cambio de cuadrícula NtV2, pero estos archivos son muy grandes y he descubierto que lo anterior proporciona una precisión superior a 5 cm utilizando datos de muestra para Victoria. También quería una solución que funcionara con proj4js.

JohnGom
fuente