Archivo de la etiqueta: rpc

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

Deja un comentario

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:

Carga nativa de orientaciones satelitales de archivos de proyecto de Inpho

Deja un comentario

Acabamos de añadir a Digi3D.NET la carga nativa de archivos de proyecto de Inpho (*.prj) con polinomios RPC para imágenes satelitales.

De esta manera, Digi3D.NET puede trabajar con aerotriangulaciones calculadas con Inpho de forma completamente transparente para el usuario.

Este importador de orientaciones se une a los ya existentes en Digi3D.NET, de modo que ya se pueden cargar sin necesidad de tener que utilizar ningún importador orientaciones de los siguientes programas:

Extensión del archivo Software/Satélite
 *_rpc.txt Iconos/GeoEye
*.xml QuickBird/WorldView I/WorldView II
RPC* Alos
*.blk Leica Photogrammetric Suite (LPS)
*.sup Socet Set
*.smtxml Summit Evolution
*.prj Inpho

Carga de proyectos satelitales de Summit Evolution

Deja un comentario

Acabamos de añadir a Digi3D.NET la carga nativa de proyectos satelitales en archivo .SMTXML de Summit Evolution.

Gracias a esta nueva funcionalidad, podemos cargar:

  • Modelos estereoscópicos mediante el cuadro de diálogo Nuevo Proyecto.
  • Proyectos completos que nos permitirán cambiar de modelo mediante el panel de Proyectos.

Puedes ver en acción esta nueva funcionalidad en el siguiente vídeo:

Cambios en la orden FIJAZ para permitir bloquear la Z en sensores con Z elipsoidal

Deja un comentario

Los sensores ADS 40/80, VM Quasi-panoramic (cámara A3) y satelitales trabajan en el sistema de coordenadas de referencia WGS 84 3D (código EPSG:4979). La coordenada Z para estos sensores es siempre elipsoidal, de modo que si no utilizamos una orientación absoluta que tenga asignado un sistema de coordenadas de referencia con un sistema vertical ortométrico, al bloquear la coordenada Z estaremos bloqueando ésta en el sistema elipsoidal.

Cuando el operador bloquea la coordenada Z, habitualmente quiere que se bloquee en una coordenada Z ortométrica. Como estos sensores en particular trabajan con coordenada Z elipsoidal, en realidad la coordenada Z sí que se debe mover, ya que se debe transformar de esa coordenada Z ortométrica bloqueada por el usuario en su correspondiente coordenada Z elipsoidal, así que el comportamiento esperado al bloquear la coordenada Z al cargar un modelo de los sensores indicados anteriormente es que ésta se mueva en función del modelo de geoide seleccionado para la transformación.

¿Cómo podemos hacer para que la coordenada Z de estos sensores sea ortométrica y no elipsoidal?

Una opción es realizar una orientación absoluta cuyos puntos de apoyo estén en un sistema de coordenadas virtual ortométrico, como por ejemplo: ETRS89 / UTM Zone 30N + REDNAP Península.

Si no tenemos puntos de apoyo la cosa no es tan sencilla, pues no tenemos puntos que medir.

Hemos realizado una modificación a la orden de FIJA_Z. Hasta ahora esta orden bloqueaba la coordenada Z en la coordenada que tuviera la ventana fotogramétrica cuando se activaba. Ahora no es así, ahora ésta se va a bloquear en la coordenada Z que tenga la ventana de dibujo. Si la ventana de dibujo tiene asociado un sistema de coordenadas vertical ortométrico (digamos por ejemplo que la ventana de dibujo está en el sistema ETRS89 / UTM Zone 30N + REDNAP Península), al activar el bloqueo de Z, Digi3D.NET realizará el siguiente algoritmo:

  1. La ventana fotogramétrica recibe un movimiento por parte del usuario. Digamos Latitud,Longitud,h
  2. Como está activado el bloqueo de Z, se transforma esa coordenada al sistema de coordenadas de la ventana de dibujo, dando como resultado X,Y,Z.
  3. Se sustituye la coordenada Z por la de la Z bloqueada dando como resultado X,Y,Zbloqueo.
  4. Se vuelve a transformar al sistema de coordenadas de la ventana fotogramétrica, dando como resultado Latitud,Longitud,Zelipsoidal para la Z de bloqueo.
  5. Se muestran las imágenes de esas coordenadas en la ventana fotogramétrica.

De esta manera el sistema de coordenadas vertical en el que se bloquea la ventana fotogramétrica está definido por la ventana de dibujo y no por la ventana fotogramétrica. Si en la ventana de dibujo estamos trabajando en coordenadas geográficas 3D (con Z elipsoidal) significa que queremos hacer curvas de nivel con coordenadas Z elipsoidales, por lo tanto el punto transformado final no variará la coordenada Z. Si por el contrario en la ventana de dibujo indicamos un sistema de coordenadas vertical ortométrico, el bloqueo se realizará en coordenadas ortométricas.

[youtube:http://youtu.be/1wEuFCUCKDs%5D