Archivo de la etiqueta: src

El mundo es en 3D, pero nadie se acuerda del sistema de referencia de coordenadas vertical (si, el de la coordenada Z)

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?

EDICIÓN EL dÍA 27/2/2019: PhotoScan sí que trabaja con sistemas de referencia verticales tal y como se explica en https://blog.digi21.net/2019/02/26/modificacion-en-el-modulo-de-carga-de-archivos-de-photoscan/

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.

En el siguiente vídeo puedes verlo en acción:

Solucionando problemas con los Sistemas de Referencia de Coordenadas colombianos

El viernes pasado comenzaron a trabajar en una entidad de Colombia con modelos del sensor ADS40 en Digi3D.NET.

El sensor ADS40, trabaja en el sistema de referencia de coordenadas EPSG:4979 tal y como se explica en esta página de la ayuda de Digi3D.NET, sin embargo la cartografía la quieren registrar en el sistema de referencia de coordenadas MAGNA-SIRGAS / Colombia West zone.

En un principio, tan solo tenemos que indicar al crear el archivo de dibujo que el sistema de referencia de coordenadas horizontal es MAGNA-SIRGAS / Colombia West zone, pero al cargar cartografía existente nos indicaron que las coordenadas X e Y estaban intercambiadas.

Con versiones modernas de Digi3D.NET la solución es muy sencilla, tan solo tenemos que indicarle a Digi3D.NET que los ejes los queremos como Este/Norte, y que haga caso omiso a lo que se indica en la base de datos EPSG, tal y como se muestra en la siguiente captura de pantalla:

ejes en src proyectados

…pero desafortunadamente el cliente tiene instalada una versión que no permite forzar la orientación de los ejes, así que los sistemas de referencia de coordenadas se crean siempre de forma estándar, y el estándar tal y como te voy a mostrar un poco más adelante indica que primero va la coordenada Y, y a continuación la coordenada .X.

Lo primero que se nos ocurrió fue comprobar los ejes del sistema MAGNA-SIRGAS / Colombia West zone en Digi3D.NET. Para ello, abrimos el panel Archivos de dibujo y pulsamos con el botón derecho del ratón en el archivo de dibujo y seleccionamos la opción Mostrar sistema de referencia de coordenadas horizontal…, lo que hizo aparecer el cuadro de diálogo Parámetros del sistema de referencia de coordenadas horizontal que te muestro a continuación:

Parámetros del SRC Magna-Sirgas

Estos parámetros salen de la base de datos EPSG que lleva incluida Digi3D.NET en su instalación, y se puede ver claramente que en Tipo de sistema de coordenadas se indica que los ejes son Norte, Este (viene en inglés), y no Este, Norte. En realidad, tal y como se puede ver en el vídeo al final de esta entrada en el blog, ese texto «Cartesian 2D CS. Axes: ….» no lo crea dinámicamente Digi3D.NET, sino que se extrae como un texto que aparece en la base de datos. Para ver bien el orden de los ejes, podemos consultar la cadena WKT que crea Digi3D.NET para ese sistema de coordenadas:

PROJCS["MAGNA-SIRGAS / Colombia West zone",
GEOGCS["MAGNA-SIRGAS",
DATUM["Marco Geocentrico Nacional de Referencia",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6686"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["grados",0.01745329251994328,AUTHORITY["EPSG","9122"]],
AXIS["Lat",North],AXIS["Long",East],AUTHORITY["EPSG","4686"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",4.596200416666666],
PARAMETER["central_meridian",-77.07750791666663],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",1000000],
PARAMETER["false_northing",1000000],
PARAMETER["semi_major",6378137],
PARAMETER["semi_minor",6356752.314140356],
UNIT["metros",1,AUTHORITY["EPSG","9001"]],
AXIS["N",North],
AXIS["E",East],
AUTHORITY["EPSG","3115"]]

El usuario allí nos asegura que en el sistema MAGNA-SIRGAS / Colombia West zone la primera coordenada es la X, y la segunda es la Y, de modo que algo debe estar haciendo mal Digi3D.NET, o no. Vamos a analizarlo…

Si creas una cuenta en http://epsg.org/ y te descargas el dataset, verás que distribuyen la base de datos como una base de datos Microsoft Access. Digi3D.NET no puede utilizar un base de datos en formato Microsoft Access porque los programas de 64 bits tienen prohibido acceder a este tipo de bases de datos, así que hace años convertimos esa base de datos en una base de datos Microsoft SQL Server Compact, que tiene la característica de que sí que se puede acceder desde programas de 64 bits (y de 32 bits obviamente). Estas bases de datos tienen extensión .sdf y existen varias versiones. La que se instala con Digi3D.NET es la última versión, la 4.0.

El instalador de Digi3D.NET almacena esta base de datos en la carpeta %ProgramData%\[versión del programa]\OpenGis y tiene como nombre: epsg_es_ES.sdf si nuestra instalación es en español o epsg_en_US.sdf si nuestra instalación es es inglés.

Podemos abrir archivos .sdf versión 4.0 con una herramienta gratuita de Microsoft denominada Microsoft WebMatrix 3.0.

Instala el programa y sigue los siguientes pasos:

  1. Ejecuta el programa Microsoft WebMatrix. Te mostrará una página inicial con tres botones:  My sites, New y Open.
  2. Pulsa el botón Open. Aparecerá un menú contextual con varias opciones.
  3. Selecciona la opción Folder en el menú contextual. Aparecerá un cuadro de diálogo para seleccionar la carpeta a abrir.
  4. Selecciona la carpeta en la que está la base de datos EPSG y pulsa aceptar. Comprobarás que aparecen en el panel lateral izquierdo los archivos disponibles en dicha carpeta, entre ellos el archivo .sdf.
  5. Haz doble clic en el archivo .sdf. Comprobarás que cambia el menú y te muestra iconos relacionados con base de datos.
  6. Pulsa el botón New Query (nueva consulta). Se creará una ventana que te va a permitir teclear consultas SQL.
  7. Copia la siguiente consulta SQL y pulsa el botón Execute:
    SELECT * FROM [Coordinate Reference System] WHERE [COORD_REF_SYS_CODE]=3115

    Comprobarás que aparecen abajo los parámetros del sistema de referencia de coordenadas MAGNA-SIRGAS / Colombia West Zone. Entre ellas el código del sistema de coordenadas asociado, que es 4500.

  8. Ahora vamos a ver los ejes del sistema de coordenadas 4500, Para ello teclea la siguiente consulta:
    SELECT * FROM [Coordinate Axis] WHERE COORD_SYS_CODE=4500

    Comprobarás que aparecen dos ejes: El eje E y el eje N. En un principio aparece en el orden en el que le interesa al usuario, es decir, primero la coordenada X (este) y luego la coordenada Y (norte), pero en bases de datos el orden en el que aparecen los registros no vincula nada, quizás esta misma consulta con otro sistema de gestos de bases de datos muestre a información en otro orden. Los señores del EPSG lo saben, por eso añadieron un campo denominado ORDER en la tabla COORD_SYS_CODE, y si te fijas, el orden está mal: En el eje Este aparece un 2 y en el eje Norte aparece un 1.

    De hecho, Digi3D.NET no utiliza la consulta SQL que te he indicado en este paso para averiguar el nombre de los ejes, sino que utiliza la siguiente:

    SELECT * FROM [Coordinate Axis] WHERE COORD_SYS_CODE=4500 ORDER BY [Order]
    

    Si la ejecutas, comprobarás que el primer eje es el Norte y el segundo el Este. Esta es la causa por la cual Digi3D.NET está creando los ejes de forma incorrecta. En la base de datos EPSG viene mal. Vamos a solucionarlo.

  9. Tenemos que cambiar el valor de ORDER de los registros 44 (el registro para el eje Norte del sistema de referencias 4500 que representa el eje Norte) y cambiar el valor a 2, y poner un valor 1 en el registro 43 que representa el eje Este para el sistema de coordenadas 4500.
    Para ello ejecutaremos las siguientes consultas SQL:

    UPDATE [Coordinate Axis] SET [ORDER]=1 WHERE COORD_AXIS_CODE=43
    UPDATE [Coordinate Axis] SET [ORDER]=2 WHERE COORD_AXIS_CODE=44
    

y asunto solucionado.

Puedes ver cómo lo hago en el siguiente vídeo:

 

 

 

 

 

 

Modificando archivos .PRJ satelitales de Inpho para que Digi3D.NET no solicite el SRC vertical

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:

Selecciona SRC vertical

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:

  1. Seleccionamos la opción del menú Herramientas/Sistema de referencia de coordenadas…
  2. Seleccionamos el SRC que nos interese.
  3. Pulsamos el botón Copiar para que se copie la cadena WKT al portapapeles.
  4. 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:

Mejoras de usabilidad al especificar el SRC asociado a un archivo de dibujo

Hasta ahora, Digi3D.NET solicitaba el sistema de referencia de coordenadas asociado a un archivo de dibujo independientemente de que el archivo ya tuviera asignado uno o no.

Digi3D.NET solicitando el SRC del archivo de dibujo independientemente de si éste tiene o no uno ya asignado

Digi3D.NET solicitando el SRC del archivo de dibujo independientemente de si éste tiene o no uno ya asignado

En la captura de pantalla anterior puedes comprobar que el programa siempre solicitaba el sistema de referencia de coordenadas del archivo. Si te fijas en la descripción que aparece abajo, se indica que este parámetro se utilizará únicamente en caso de que Digi3D.NET tenga que crear el archivo de dibujo, pues si éste ya existía, se hace caso omiso de lo que ponga el usuario aquí y prevalece el SRC asignado al archivo de dibujo ya creado.

Eso podía llevar a confusión, de modo que hemos decidido cambiar esta funcionalidad.
Ahora el programa pregunta por el SRC únicamente si el archivo no tiene ya uno asignado tal y como puedes ver en el vídeo de a continuación.

[youtube:http://youtu.be/8aMUyDMOJic%5D