Digi3D.NET crea cadenas WKT compatibles con el estándar OpenGis Coordinate Transformation Service, y ese estándar dicta que si un sistema es tridimensional (que es como trabaja Digi3D.NET) debe crear sistemas de referencia o puramente 3D como los Geográficos 3D o compuestos en los que hay dos partes: una horizontal y otra vertical.
En el caso de sistemas compuestos es legal que tanto la componente horizontal como la vertical pueden ser locales (desconocido), de manera que si en Digi3D.NET creas un sistema de referencia de coordenadas en el que conoces la parte horizontal (por ejemplo WGS84 / UTM Zona 30N) y desconoces la vertical, el programa va a crear un sistema compuesto del tipo WGS84 / UTM Zona 30N + vertical local.
Esto está muy bien para los programas que siguen el estándar, pero vuelve locos a los programas que no lo siguen o que no son 3D, de manera que para mejorar la compatibilidad con esos programas, hemos añadido una opción en Digi3D.NET que nos va a permitir configurarlo para que en el caso de que el usuario cree un sistema 3D en el que el sistema vertical sea desconocido, al crear archivos .PRJ con cadenas WKT, estas se creen como sistemas 2D puros. Si por el contrario el sistema vertical no es local o desconocido, aunque tengas esta opción activada, el programa va a crear una cadena 3D.
Puedes activar esta funcionalidad en la opción del menú Herramientas/Configuración/Sistemas de referencia de coordenadas/Trabajar con sistemas 2D (horizontales) si el vertical es desconocido.
Acabamos de añadir una nueva sección en el cuadro de diálogo de Configuración denominada Sistemas de Referencia de Coordenadas que por ahora tiene una única opción: Solicitar sistema vertical para sensores.
Si activamos esta opción y cargamos un modelo fotogramétrico cuya orientación proporciona un sistema de referencia de coordenadas horizontal pero no uno vertical, el programa asumirá que el vertical es Desconocido y no nos va a preguntar más.
Si desactivamos esta opción, el programa se comportará como hasta ahora, es decir, preguntará al usuario por el sistema vertical.
Digi3D.NET es puramente 3D, y desde el momento en el que empezó a solicitar al usuario Sistemas de Referencia de Coordenadas, siempre ha solicitado sistemas 3D. Lo tienes todo muy bien explicado en la página de Sistemas de Referencia de Coordenadas de la ayuda online.
Además Digi3D.NET carga de forma nativa proyectos creados por otros programas como Inpho o PhotoScan. Personalmente me encantan ambos formatos (quizás más el de PhotoScan), entre otras cosas porque indican el Sistema de Referencia de Coordenadas de las orientaciones que contienen (punto número 1) y además, lo hacen de una manera estándar, utilizando cadenas Well Known Text, que es como se tiene que hacer (punto número dos), pero ambas adolecen de lo mismo:
Se olvidan de la coordenada Z
No se yo qué les habrá hecho la pobre coordenada Z, pero siempre se olvidan de ella…
Primero sucedió con el sensor Digi3D.RPC, que es el que se encarga de trabajar con sensores satelitales. Una empresa nos solicitó la posibilidad de cargar aerotriangulaciones realizadas con Inpho en UTM (la verdad es que no me imaginaba que se pudieran realizar orientaciones RPC en UTM, pero si, olé por los desarrolladores de Inpho, porque eso funciona y bien), pero en los archivos del proyecto, no existía la componente vertical. Lo solucionamos solicitando al usuario el SRC vertical en caso de que al cargar proyectos satelitales de Inpho no apareciera en la cadena WKT la componente vertical.
En realidad en este caso no era tan importante, porque a las fórmulas de RPC le dan igual las coordenadas Z; da igual si están en elipsoidales o en ortométricas, no hay ninguna exigencia, sin embargo decidimos solicitar eso al usuario por si realizaba alguna transformación a otro sistema, para saber dónde están las cosas de verdad.
En el caso de PhotoScan además es peor, porque para poder trabajar con ese formato, hay que transformar sí o sí a coordenadas geocéntricas, y para transformar a coordenadas geocéntricas hay que utilizar siempre coordenadas Z elipsoidales, de modo que si las coordenadas de las orientaciones son ortométricas, digo yo que habrá que saber el sistema de referencia de coordenadas vertical en el que están ¿no?
Podrían estar perfectamente en EGM2008, o en EGM96 o REDNAP08 o Nivel medio del mar en Alicante, o lo que sea. Además, quizás las coordenadas Z estén medidas en millas o en pies o en micras, o en milímetros… ¿Quién sabe?
Digi3D.NET no hace jamás ninguna suposición, no tiene ninguna caja negra que tome una decisión por el usuario, así que hemos añadido también en el sensor Digi3D.ConicSensor, que es el encargado de cámaras cónicas la misma solución que en el caso del sensor satelital: Ahora el programa solicita el SRC vertical en caso de que el archivo de aerotriangulación que estés cargando proporcione uno pero que sea en 2D.
Ayer mismo publicamos una entrada en la que se anunciaba la posibilidad de cargar archivos .PRJ de Inpho con parámetros RPC de satélites, pero el vídeo tenía un truco para evitar que Digi3D.NET solicite el Sistema de Referencia de Coordenadas (SRC a partir de ahora) vertical.
El sensor satelital de Digi3D.NET es un sensor 3D, de modo que requiere que le proporcionemos tres coordenadas: X, Y, Z o Longitud, Latitud, Altitud. Además, Digi3D.NET necesita saber el SRC de estas coordenadas.
Si los parámetros RPC se han obtenido de cualquiera de los formatos que soportaba la extensión hasta ayer (antes de añadir la posibilidad de obtenerlos de archivos .PRJ de Inpho), se suponía que el SRC era el EPSG:4979, que el SRC geográfico 3D (lo que significa que la coordenada Z es elipsoidal) con nombre WGS 84. No lo confundas son el mucho más famoso EPSG:4326 con el que comparte nombre: este otro es 2D, y únicamente puede formar parte de un SRC compuesto, y en los SRC compuestos no podemos especificar una coordenada Z elipsoidal, tiene que ser ortométrica si o si.
Cuando ayer implementamos la posibilidad de cargar archivos .PRJ hicimos que el SRC asociado al sensor satelital ya no sea siempre el EPSG:4979, sino que sea el que viene indicado en el archivo .PRJ. El problema es que los SRC que aparecen en los archivos .PRJ son 2D y no 3D.
A continuación tienes un recorte de un archivo .PRJ con las orientaciones en geográficas:
$PROJECT 7.0.0
# generated using Version 7.0.1.49528 (64bit), build #36 of 2015-10-13 09:38
$PROJECT_NAME : new_project
$USER_ID : Jose Manuel
$STARTING_DATE : mar ene 12 12:44:00 2016
$LAST_CHANGE : Tue Jan 12 13:22:21 2016
$IMAGE_TYPE : Satellite
$REFRACT_CORR_DEFAULT : off
$CURV_CORR_DEFAULT : off
$COORDINATE_SYSTEM :
GEOGCS["WGS 84",
DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG",
"7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
$LINEAR_UNITS_OF_OBJECT : m
$LINEAR_UNITS_OF_IMAGE : pixel
$ANGULAR_UNITS : deg
$REPORT_LOGFILE : C:\Users\Jose Manuel\new_report.log
$END
Como puedes ver, el SRC proporcionado es el EPSG:4326. A simple vista se ve que es 2D, porque los SRC que se definen como GEOGCS son 2D, así de sencillo.
Lo mismo ocurre con un archivo .PRJ con las coordenadas en UTM como puedes ver a continuación:
$PROJECT 7.0.0
# generated using Version 7.0.1.49528 (64bit), build #36 of 2015-10-13 09:43
$PROJECT_NAME : new_project
$USER_ID : Jose Manuel
$STARTING_DATE : mié nov 18 14:03:18 2015
$LAST_CHANGE : Tue Dec 15 14:09:15 2015
$IMAGE_TYPE : Satellite
$STD_DEV_OBJECT_POINTS : 0.200000
$STD_DEV_OBJECT_Z_POINTS : 0.400000
$STD_DEV_IMAGE_POINTS : 0.500000
$STD_DEV_IMAGE_GC_POINTS : 0.500000
$SDS_OBJ_GROUP_XY : -1.000000 -1.000000 -1.000000 -1.000000
$SDS_OBJ_GROUP_Z : -1.000000 -1.000000 -1.000000 -1.000000
$REFRACT_CORR_DEFAULT : off
$CURV_CORR_DEFAULT : off
$COORDINATE_SYSTEM :
PROJCS["WGS 84 / UTM zone 18S",
GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
UNIT["metre",1,AUTHORITY["EPSG","9001"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-75],18S
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",10000000],
AUTHORITY["EPSG","32718"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]
$LINEAR_UNITS_OF_OBJECT : m
$LINEAR_UNITS_OF_IMAGE : pixel
$ANGULAR_UNITS : deg
$REPORT_LOGFILE : C:\Users\Jose Manuel\new_report.log
$END
Este sistema también es 2D, porque los proyectados son siempre 2D.
Si intentamos cargar un archivo de estos, Digi3D.NET va a preguntarnos por el SRC de la componente vertical mostrando el siguiente cuadro de diálogo:
y esto lo va a hacer cada vez que carguemos el modelo.
Si queremos evitar que suceda esto, podemos modificar las cadenas WKT que aparecen en los archivos .PRJ y poner una que proporcione información del SRC vertical.
Para ello seguiremos los siguientes pasos:
Seleccionamos la opción del menú Herramientas/Sistema de referencia de coordenadas…
Seleccionamos el SRC que nos interese.
Pulsamos el botón Copiar para que se copie la cadena WKT al portapapeles.
Abrimos el archivo .PRJ con nuestro editor de textos favorito y modificamos la cadena WKT que aparece ahí por la que tenemos en el portapapeles.
Con esto habremos conseguido que Digi3D.NET no nos pregunte cada vez por el SRC vertical del modelo.
Además esto es fundamental si queremos trabajar con coordenadas Z elipsoidales, en cuyo caso tendremos que seleccionar como el SRC Geográfico 3D WGS 84, porque como he indicado antes, no podemos asignar un SRC elipsoidal a un SRC compuesto.
Puedes ver un vídeo en el que explico todo esto a continuación:
Hemos realizado dos mejoras en el cuadro de diálogo de selección de Sistema de Referencia de Coordenadas en Digi3D.NET:
A partir de ahora, podemos seleccionar el orden de los ejes en los sistemas de coordenadas horizontales que forman parte de los sistema de referencia de coordenadas compuestos Proyectado + Vertical.
Ahora podemos almacenar los sistemas de referencia de coordenadas en el portapapeles de Windows.
Hasta ahora únicamente podíamos seleccionar el orden de los ejes en los sistemas Geográfico 3D y en Geográfico + Vertical. Ahora podemos también seleccionar el orden de los ejes en Proyectado + Vertical.
Podemos seleccionar una de las siguientes opciones:
Estándar (se obtendrá el orden de los ejes de la base de datos EPSG).
Este, Norte (se forzará a que el primer eje sea el que apunte a Este y el segundo el que apunta a Norte).
Norte, Este (se forzará a que el primer eje sea el que apunta a Norte y el segundo el que apunta a Este).
Para hacer que se copie la cadena WKT al portapapeles, tan solo tenemos que pulsar el botón Copiar que aparece en las distintas páginas del cuadro de diálogo.
En ocasiones Digi3D.NET localiza más de una transformación de coordenadas cuando está buscando transformaciones entre dos sistemas de referencia de coordenadas.
Si sucede esto, Digi3D.NET mostrará un cuadro de diálogo invitándonos a seleccionar la operación que queremos utilizar de entre la lista de operaciones localizadas.
Esta operación se repetirá cada vez que se intente localizar la transformación entre esos dos sistemas de referencia de coordenadas.
Si no queremos que Digi3D.NET nos pregunte constantemente la operación a realizar, podemos indicarle a éste que memorice la opción que hemos seleccionado. Para ello tendremos que activar la casilla «Memorizar esta transformación» que aparece al final del cuadro de diálogo.
En el siguiente vídeo puedes ver en acción esta funcionalidad.
Blog de Digi21 