X

Geobide, Transformación de Sistema de Coordenadas ED50 y ETRS89

Aprovechando para dar seguimiento a las potencialidades de la Suite Geobide, veremos las opciones para transformar entre Sistemas de Referencia. Interesantes para quienes deban transformar entre distintos Datum, en este caso veremos como hacerlo con los sistemas ED50 y ETRS89 que es casi el mismo caso en América Latina entre NAD27 y WGS84.

¿Están los datos movidos?

Este no es el caso de Google Earth, donde por más transformaciones que se hagan, las muchas imágenes están desplazadas, cosa que se puede comprobar en los traslapes entre diferentes tomas; sin embargo en muchos países, estados o comunidades autónomas las instituciones públicas han proporcionado a GoogleEarth sus imágenes con georeferencia precisa, con la desventaja que GoogleEarth usa WGS84 como Datum genérico, por lo que usar datos en otro sistema requiere una transformación.   La transformación depende en primer lugar de su propia definición pero también de la zona en la que nos encontremos. Es por ello que los sistemas genéricos no proveen de los parámetros especiales de cada zona.

Pongamos como ejemplo la transformación ED50-30N (EPSG:23030) a ETRS89-30N (EPSG:25830) para Navarra, y para España. La definición genérica de la transformación tiene distinto grado de precisión en función de la zona en la que se aplique.  Por ello existen unos parámetros extra, que no van en la definición genérica y que en Navarra por ejemplo son unos pero en Asturias puede tener otros valores distintos.

Si nos fijamos en la imagen de arriba capturada de Geomap, vemos un mapa con dos capas (ortofoto y parcelario) movidas entre sí.  Es el resultado de proyectar al vuelo el Catastro de Navarra en ED-50N sobre una capa de GoogleMaps en WGS84 y el desplazamiento resultante está relacionado con el problema descrito en el párrafo anterior.

Un reciente tutorial de Geobide, a partir del cual estamos haciendo este artículo publica ahora al menos 4 métodos para solucionarlo, .   Con Geobide, ahora es posible indicar la conversión de datum para una transformación entre Sistemas de Coordenadas de cuatro formas distintas:

  1. Transformación genérica:

Esta opción usa la transformación genérica sin parámetros espaciales, y es la menos precisa. Para Navarra por ejemplo pasar de ED50 a ETRS89 tiene un error de ~100-200m en x e y. (Recordando que esto NO afecta a sistemas de coordenadas con igual datum).

Bastante similar es el caso de NAD27 con WGS84 que anda como en 202 metros al Norte y 6 metros al este en la zona centroamericana, cambia a medida que cambia la latitud, aunque solo es significativo en la latitud pues viene desde el ecuador mientras que en la longitud apenas proviene del falso este.  

  1. Transformación usando una rejilla NTv2:

Esta opción usa una rejilla con valores para corregir la conversión por interpolación lineal. Esta opción es más precisa que el primer método y ha sido adoptada por el IGN. Precisa, claro, si disponemos de una rejilla para nuestra zona de trabajo.

Las aplicaciones de Geobide ofrecen ahora las dos rejillas proporcionadas por el IGN para el ámbito de España, que abarcan la Península y Baleares, y que se publicaron en 2003 y 2009.  El usuario puede elegir fácilmente la rejilla a utilizar.

En Internet  se pueden encontrar muchas rejillas, incluso de ámbito mundial, pero por tamaño no están disponibles automáticamente en las descargas de las aplicaciones de Geobide.

  1. Transformación de Molodensky (método de los 3-parámetros):

Usa 3 valores de desplazamiento en el origen entre elipsoides. En las aplicaciones se ofrece un asistente pre configurado recomendado por el IGN para España.


  1. Transformación de Bursa-Wolf (método de los 7-parámetros)

Esta transformación utiliza 7 valores para transformar entre elipsoides. Los parámetros a introducir son: Desplazamiento (Dx, Dy, Dz), Rotación (Rx, Ry, Rz) y Factor de escala (µ)

En las aplicaciones Geobide se ofrecen 3 asistentes pre configurados recomendados por el IGN para el Noroeste, Zona central y Este de la Península, respectivamente.

Resultados

Como se puede ver los resultados no varían mucho entre los 3 últimos métodos, pero sí con el primero. Es por ello que se debe saber si la transformación necesita de alguna de estas opciones avanzadas.

Entre los sistemas ED50-xxN (EPSG:230xx) y ETRS89-xxN (EPSG:258xx) de la zona de España sí se deberían emplear pues los Datums/Elipsoides ED50 y el ETRS89/WGS84 no son equivalentes.

Por ejemplo, si en Geomap no se configuran estos datos avanzados, los datos de Navarra en ED50-30N (EPSG:23030) reproyectados al vuelo sobre los datos ofrecidos por Google Maps (Elipsoide WGS84) saldrán movidos. Para que queden bien, es preciso utilizar las transformaciones más precisas que ya se han explicado.

Me parece muy bien que Geobide haga un esfuerzo significativo no solo en dejar las capacidades a su sistema, sino también en documentar con un poco más de detalle esta cuestión puesto que puede afectar mucho a la calidad y precisión del trabajo, aparte que solo entenderlo también es otro esfuerzo.

Hasta ahora, todo esto estaba integrado de forma automática en el motor, pero según nos comentaban los amigos de Geobide, las demandas de los usuarios los han llevado a dejarlo visible en las aplicaciones para que el propio usuario sea consciente de ello e incluso cambie la configuración por defecto, o ponga otra para su propia zona de trabajo.

Transformación alturas elipsoidal/geoidal

En la nueva versión se ha cambiado también el cuadro de cálculo de diferencias de altura elipsoidal/geoidal para que el usuario pueda seleccionar ahora el modelo de geoide a utilizar.


Nomenclaturas de archivos PRJ

Y finalmente, otro cambio que me parece bien en su esfuerzo por la interoperabilidad con los estándares OGC o prácticas de los programas popularizados. Los archivos PRJ que genera Geobide están en nomenclatura WKT del OGC, que es un estándar reconocido por muchas herramientas CAD/GIS. No así para las aplicaciones de ESRI, cuyos PRJ, aunque contienen igual definición matemática que los estándar, denominan de manera distinta los Sistemas de Coordenadas.

Por ejemplo:

En el contenido de un archivo PRJ del OGC, el sistema ETRS89-30N (EPSG:25830) se define con el nombre clave “ETRS89 / UTM zone 30N”; las aplicaciones ESRI, en cambio, lo denominan “ETRS_1989_UTM_Zone_30N”. Si en ArcGis mezclamos capas con PRJs en las dos nomenclaturas este software realizará la transformación espacial aún cuando la definición matemática de los Sistemas de Coordenadas sea idéntica.

Prestando atención a esta tozudez, Geobide ha habilitado una nueva opción en el selector de sistemas de referencia para que el usuario pueda indicar si quiere un Sistema de Coordenadas con un PRJ en estilo EPSG o estilo ESRI.

 

http://www.geobide.es/

geofumadas: Editor de Geofumadas
Related Post