Las aplicaciones de Geobide cuentan con nuevas opciones para transformar entre Sistemas de Referencia. Sin duda, estas novedades resultarán especialmente interesantes para quienes deban transformar entre los sistemas ED50 y ETRS89 y, en general, entre sistemas con distinto datum.
¿Por qué tengo los datos movidos?
Sin entrar en mucho detalle (ya que Internet ofrece una extensa bibliografía sobre este tema, como este Tutorial), para convertir de forma precisa entre dos sistemas de referencia distintos debemos especificar una transformación espacial entre ellos. Esta 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. Geobide publica ahora varios métodos para solucionarlo.
Métodos de Transformación entre Sistemas de Referencia
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. (Recordad que esto NO afecta a sistemas de coordenadas con igual datum).
2.- 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 encontraréis muchas rejillas, incluso de ámbito mundial, pero por tamaño no están disponibles automáticamente en las descargas de las aplicaciones de Geobide.
3.- 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 preconfigurado recomendado por el IGN para España.
4.- 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 preconfigurados recomendados por el IGN para el Noroeste, Zona central y Este de la Península, respectivamente.
Como podréis ver los resultados no varían mucho entre los 3 últimos métodos, pero sí con el primero. Es por ello que deberíais saber si vuestra 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 configuráis 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 hemos explicado.
Hemos considerado conveniente explicar con un poco más de detalle esta cuestión puesto que puede afectar mucho a la calidad y precisión de nuestro trabajo.
Hasta ahora, todo esto estaba integrado de forma automática en el motor, pero las demandas de los usuarios nos 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
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. 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.
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 (Derroche de proceso en el tratamiento de los datos).
Prestando atención a este aspecto, 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.
