Informe Final Tutoria de Investigación Trento - Italia Enero Junio 2013 Lic. Zader Pablo

Transcripción

1 Informe Final Tutoria de Investigación Trento - Italia Enero Junio 2013 Lic. Zader Pablo Tutor en Italia: Dr. Markus Neteler Tutor en Argentina: Mgtr. Estefania De Elia 1

2 Índice de contenido Primera parte: Desarrollo de un módulo para el Sistema de Vigilancia de Salud Dirección de Enfermedades Transmisibles por Vectores, DETVs...4 Segunda parte: Incorporación de una solución para Orto-rectificación de imágenes...15 Tercera parte: WebGIS - Geoprocesamiento en la web Cloud Computing

3 Primera parte: Desarrollo de un módulo para el Sistema de Vigilancia de Salud Dirección de Enfermedades Transmisibles por Vectores, DETVs Table of Contents Introducción...3 Meeting GRASS...4 Desarrollo de un modulo para el Sistema de Vigilancia de Salud Dirección de Enfermedades Transmisibles por Vectores, DETVs...5 Módulo : Gestión de datos...5 Requerimientos...5 Tecnología utilizada...5 Architectura...6 Implementación...6 Conclusión...11 Anexos

4 Introducción El siguiente informe describe las actividades realizadas durante la Tutoria de Investigacion en la provincia de Trento Italia en el periodo comprendido entre el 10 de Enero de 2013 y 15 de Marzo de Desarrollo realizado para CONAE para el proyecto de Chagas del Ministerio de Salud de la Nación. El sistema de Vigilancia de Salud esta siendo desarrollado poe CONAE y a grandes rasgos presentamos las distintas capacidades con las que constará el mismo: Una plataforma cliente-servidor donde el acceso al mismo se da a traves de la web mediante una interfaz instuitiva que permitira al usuario gestionar la informacion integrada al mismo y proveniente de distintas fuentes a distintos niveles como ser por localidad, por departamento y por provincia. La informacion ingresa a traves de planillas excel que son previamente pobladas con datos de campo obtenidas por responsables designados a tal fin. Efectuara el procesamiento de la misma de acuerdo a una serie de requerimientos especificos y generara salidas en diferentes formatos como datos tabulares, gráficos, tablas y mapas vectores y raster ya que los datos ingresados estaran identificados en el espacio mediante coordenadas geográficas. Módulo : Gestión de datos Cuando el usuario ingresa las planillas excel al sistema, estas son procesadas y almacenadas en una base de datos objeto-relacional. Luego, estos datos deben ser extraidos y visualizados correctamente para permitirle al usuario del sistema la visualizacion y manipulacion de los mismos. El modulo de Gestion de datos que implementa esta solucion fue diseñado e implementado en este trabajo de acuerdo a los requerimientos descriptos a continuación. Nota: existen dos tipos de usuarios: Nacionales y Provinciales, ambos con distintos privilegios de acceso a la información. Requerimientos 1. Realizar búsquedas/consultas (SQL) a la base de datos predeterminadas. 2. Permitir editar los datos cargados previamente (esta funcionalidad solo está disponible para algunos niveles de usuarios). Tiempo de edición de la base de datos: Pasado los 30 días de la carga de la planilla, los datos NO pueden ser modificados. 3. Permitir eliminar los datos cargados previamente (esta funcionalidad solo está disponible para algunos niveles de usuarios). Las modificaciones solo pueden realizarse por quien ingresa los datos. 4. Permitir la descarga de los resultados de las búsquedas SQL.. 5. La descarga de la base de datos y los resultados de las búsquedas deberán ser guardadas en archivos con formato compatible con sistemas de administración de bases de datos (como CSV). Tecnología utilizada 4

5 El cliente se programó utilizando la libreria EXTJS 4.1 El servidor, el lenguaje PHP 5.3 El motor de base de datos PostgreSQL 8.4 Architectura Organización de los componentes Las clases que componen el modulo se organizan bajo un patron MVC (Modelo-Vista- Controllador) y tiene la siguiente estructura: Figura 1. Estructura MVC Breve descripcion de cada archivo (ver ANEXO I) Implementación Para acceder al modulo de gestion de datos, el usuario debe loguearse en el sistema. De esta manera se registra una sesion, luego los datos asociados a la misma estan disponibles a todo el sistema y particularmente a este modulo que se vale de tal informacion para extraer: el nombre del usuario; el 5

6 tipo de usuario que esta autenticado,nacional o Provincial, y si es Provincial el nombre de la provincia a la cual pertenece. Esta informacion es necesaria es indispensable para implementar las distintas funcionalidades que el sistema requiere. Realizar búsquedas/consultas (SQL) a la base de datos predeterminadas La búsqueda SQL consiste en listar toda la información disponible en la base de datos para un tipo de usuario y provincia a la que pertenece. El resultado de tal consulta es listado en forma tabular en una grilla definida estaticamente y que representa la planilla excel que el usuario ingresó al sistema. 1. El usuario solicita visualizar los datos: el codigo cliente invoca mediante una solicitud ajax los datos al servidor Ext.define('chagas.store.Planillajoin', { extend: 'Ext.data.Store',... api: {... read : 'php/chagas.php?action=fetchall', } } 2. El servidor mediate la funcion fetchall() llama a la db solictando los datos dependiendo del tipo de usuario: Si el usuario es de tipo Provincial: SELECT * FROM tabla_general WHERE nombre_provincia = provincia_user donde provincia_user es el nombre de la provincia a la que pertenece el usuario logueado. Este dato es obtenido previamente. Si el usuario es de tipo Nacional: SELECT * FROM tabla_general Nota: tabla_general se define como un VIEW en la base de datos a partir de todas las tablas que la componen que contienen los campos necesarios para ser visualizados. 3. El resultado de la consulta en enviado en formato JSON al cliente y luedo de ser decodificado por éste, es renderizado en una grilla o tabla como se muestra en la figura 2. 6

7 Figura 2. Grilla de salida con los datos obtenidos de la dase de datos Permitir editar los datos cargados previamente (esta funcionalidad solo está disponible para algunos niveles de usuarios). Tiempo de edición de la base de datos: Pasado los 30 días de la carga de la planilla, los datos NO pueden ser modificados. 1. Dependiendo del usuario logueado, el sistema detectará el tipo de usuario y proveera la funcionalidad de Editar para usuarios Provinciales pero no para usuarios Nacionales. Cuando el usuario solicita el listado de datos, el sistema controla el tipo del mismo mediante una llamada ajax al servidor al metodo checkuser() y define las funcionalidades para su tipo. Ext.application({ name: 'chagas', } Ext.Ajax.request({ url: 'php/chagas.php?action=checkuser',... if (text.data == 'Provincial'){ }else{ { xtype:'button',text:'editar', iconcls: 'edit', action: 'edit',disabled: false }, 2. Si el usuario tiene privilegios para modificar los datos, al llevar a cabo la accion, el sistema verifica mediante una llamada ajax al metodo comparedate(), tomando el campo Fecha de 7

8 carga, si han trasncurrido mas de 30 dias. Si la respuesta es SI, el sistema muestra un alerta evitando que se ejecute tal acciòn (Figura 3); en otro caso se despliega el formulari que permite modificar el registro seleccionado (Figura 4). Figura 3. Alerta: El registro no es editable Figura 4. Formulario de edición. 8

9 Ext.define('chagas.controller.Planillajoin', { extend: 'Ext.app.Controller', edit: function(btn){ Ext.Ajax.request({ url: 'php/chagas.php?action=comparedate', params: { fechacarga: fcarga }, if (text.data=="noeditable"){ Ext.Msg.alert('Aviso','No se puede editar este dato, supero los 30 dias de la carga. Fecha de carga ' + fcarga); }else{ view.settitle('editando datos '); } Una vez modificados los datos en el formulario, al presionar el boton Guardar se efectua la validación de los datos ingresados antes de ser enviados al servidor. Si todo es correcto, los datos son actualizados, sino se le da aviso al usuario marcando los campos erroneos o incompletos. Ext.define('chagas.store.Planillajoin', { extend: 'Ext.data.Store',... api: {... update : 'php/chagas.php?action=update', } Permitir eliminar los datos cargados previamente (esta funcionalidad solo está disponible para algunos niveles de usuarios). Las modificaciones solo pueden realizarse por quien ingresa los datos. Como en el edit, el mismo procesamiento es incorporado para detectar el nivel de usuario y de esta manera darle o no acceso a la funcion borrar. Si el usuario tiene la capacidad de borrar un registro, el sistema mostrará un aviso para confirmar tal acción o bien cancelarla. El procedimiento de la la eliminación es por registro (es decir, por vivienda) y se efectua realizando una llamda ajax al servidor. Permitir la descarga de los resultados de las búsquedas SQL 9

10 La función descarga de los resultados permite bajar la grilla de datos que el usuario esta visualizando en formato CSV. Para implementar esta funciòn, se tuvo en cuenta si el usuario logueado es Nacional o Provincial. Si es Nacional descarga los datos de todas las provincias. Si es Provincial, descarga solo los de su provincia. Cuando el usuario presiona el boton Descargar CSV presente en al barra de herramientas de la grilla, el sistema toma la información de sesión y decide cuales datos traer. Ext.define('chagas.controller.Planillajoin', { extend: 'Ext.app.Controller', 'planillajoingrid button[action=download]': { click: this.download } download: function(){ Ext.Ajax.request({ url: 'php/chagas.php?action=getcsv', } } Mediante una llamda ajax al servidor a la funcion getcsv() se genera el archivo y se le presenta inmediatamente al usuario para elegir el directorio en el cual desea descargarlo como puede verse en la figura 5. Figura 5. Descarga en formato CVS 10

11 Nota: el nombre del archivo descargado tiene el formato año-mes-dia-hora-minuto.csv La descarga de la base de datos y los resultados de las búsquedas deberán ser guardadas en archivos con formato compatible con sistemas de administración de bases de datos (como CSV). Este requerimiento es parte del anterior. Los archivos descargados pueden luego ser abiertos por editores de texto, excel, openoffice, etc. Conclusión 1. El uso de la librería EXTJS del lado del cliente posibilita por un lado estructurar la aplicación siguiendo el patron MVC, siendo coherentes con las buenas prácticas de la Ingenieria del Software; por otro lado, es una librería que tiene mucha documentación y muchos programadores activamente utilizandola en el mundo, lo cual genera permanente ayuda en la resolución de problemas mediante foros y también en la contribución de ejemplos desarrollados por la comunidad de software libre. Extjs existe en dos modalidades: open source y licenciada. En este proyecto se utiliza la version open source. Otra de las bondades que podemos mencionar es que brinda componentes para desarrollar a nivel visual interfaces bien acabadas y muy atractivas al usuario final. Como desventaja se puede mencionar que el tiempo de aprendizaje es algo lento debido a que presenta definiciones de funciones y objetos poco intituitivas en relacion a los conceptos de la WEB. 2. El lenguaje del lado del servidor puede ser reemplazado por otro lenguaje de programación sin afectar en lo mas mínimo el desarrollo del lado del cliente. Esto se debe a que EXTSJ implementa de forma muy limpia la utilizacion de AJAX 1 por lo que solo cambiando una linea de codigo en el cliente se puede lograr llamar a una funcion que estaba implementada por ejemplo en php, ahora en java o python. 1 Técnica que permite ejecutar codigo en background, residente en el servidor, sin recargar la página que se esta visualizando. 11

12 Anexos Anexo I Breve descripcion de los archivos que componen el modulo. Para tener la descripcion total, remitirse al codigo fuente. app.js : define el punto de arranque del sistema. Aca se define el espacio de nombres chagas y el directorio del MVC app. Ademas, se crea un contenedor Viewport donde se cargara luego el grid. App/controller/Planilla.js: define las acciones edit, delete, save y download ejecutadas por el cliente. App/model/Planilla.js: define el modelo para la planillajoin (VIEW en la DB). App/store/Planilla.js: define la API para el ABM de la DB usando ajax para llamar a las funciones php definias en el servidor. (fetchall para leer la planillajoin completa; update para edit de un registro; delete para borrar un registro) App/view/chagas/Form.js: define el formulario que sirve para la edicion de los datos. App/view/chagas/Grid.js: define el grid donde se cargaran los datos de la db. App/view/chagas/Window.js: define una ventana donde se cargara el formulario del edit. Esta, presenta dos botones: Guardar y Cancelar. Si el usuario clickea en Guardar se realiza la validacion de los datos ingresados antes de enviarlos. Si algo falla se le avisa al usuario con un mensaje de alerta. Ademas, cada vez que un campo del formulario pierde el foco, si este campo era obligatorio y no fue llenado, se marca en rojo y si el usuario mueve el puntero del mouse sobre él, aparece un mensaje de ayuda sobre como llenar el campo. La configuracion valida de los campos esta especificada en el listado de items definidos en el Form.js. Por otro lado, si el cliente cancelo la accion, la ventana se cierra. Php/Db/connection.php: crea una clase con una metodo que construye el string para la conexión a postgressql. Php/Db/Base.php Define la clase con metodos relacionados a la base de datos: Provee de metodos get y set para diversas tareas. El metodo fetchall es uno de los principales y es el encargado de traer todos los datos de la base (planillajoin) teniendo en cuenta el usuario que esta logueado y el tipo de usuario, y con estos datos devuelve los resultados ya sea para un usuario de tipo provincial o bien devuelve toda la base para el usuario de tipo nacional. Aqui se satisface uno de los requerimientos. El metodo getcsv se encarga de buscar los datos de la base teniendo en cuenta el nombre de usuario y tipo de usuario para generar con ese resultado el archivo CSV que el cliente podra descargar haciendo una llamada en el boton Descargar CSV en la interfaz del usuario. Este metodo ademas tiene en cuenta el path absoluto (document_root en apache) de donde se esta ejecutando la aplicación y el path relativo, que es un directorio dentro de nuestra aplicación (en nuestro caso la carpeta file) y que se usa para almacenar los archivo CSV que se generan cada vez que un usuario hace una peticion de estas. Una vez que el usuario descargo el archivo a su pc, este archivo en la carpeta file ya no es necesario. En el futuro se debera proveer un script que se ejecute como tarea del cron para vaciar esta carpeta y evitar que cresca. Es importante destacar que a esta carpeta debe poder acceder el usuario propietario del servidor que ejecuta la aplicación. Este metodo, utiliza el metodo array_to_scv(...) para crear el string separado por comas a partir del array devuelto en la consulta a la base de datos y esta definido en la carpeta php/libs/aux.php php/chagas.php: crea una clase que es la extension de la clase Base definida en Base.php e implementa los metodos update(...) y delete(...) que se usan para actualizar y borrar un registro de la base (planillajoin). Tambien implementa metodo comparedate() que se utiliza en el edit para 12

13 determinar si la fila es editable o no, y ckechuser() para determinar, dado un nombre de usuario logueado, de que tipo es. 13

14 Segunda parte: Incorporación de una solución para Ortorectificación de imágenes satelitales en el software GIS GRASS versión 7.0. Índice de contenido Primera parte: Desarrollo de un módulo para el Sistema de Vigilancia de Salud Dirección de Enfermedades Transmisibles por Vectores, DETVs...3 Desarrollo de un módulo para el Sistema de Vigilancia de Salud Dirección de Enfermedades Transmisibles por Vectores, DETVs...3 Introducción...3 El siguiente informe describe las actividades realizadas durante la Tutoria de Investigacion en la provincia de Trento Italia en el periodo comprendido entre el 10 de Enero de 2013 y 15 de Marzo de Desarrollo realizado para CONAE para el proyecto de Chagas del Ministerio de Salud de la Nación...3 Módulo : Gestión de datos...3 Requerimientos...3 Tecnología utilizada...4 Architectura...4 Implementación...4 Conclusión...10 Anexos...11 Segunda parte: Incorporación de una solución para Orto-rectificación de imágenes...13 satelitales en el software GIS GRASS versión Resumen...15 Objetivo...15 Parte Ortorectificación...16 Introducción...16 Métodos y procedimiento...17 GRASS...18 Características...18 Funcionalidad de orto-rectificación...18 OSSIM: Herramienta open source para ortorectificar...19 Características...19 Como funciona la ortorectificación...20 Solución propuesta...23 Implementar un wrapper en C entre OSSIM y GRASSS...23 Parte Requerimiento a desarrollar en la ultima etapa de la tutoria...24 Objetivo...24 Referencias

15 Resumen El siguiente informe describe las actividades realizadas durante la Tutoría de Investigación en la provincia de Trento Italia en el periodo comprendido entre el 15 de Marzo de 2013 y 5 de Mayo de Objetivo El objetivo de este trabajo es la incorporación de una solución para Orto-rectificación de imágenes satelitales en el software GIS GRASS versión 7.0. Ademas, se introduce el requerimiento a desarrollar en la próxima etapa. En la parte 1 se describe el trabajo realizado con la Orto-rectificación y en la parte 2 introduzco el requerimiento para la próxima y ultima etapa de mi estadía en Italia. 15

16 Parte 1 Ortorectificación Introducción La adquisición de imágenes de percepción remota vienen principalmente de dos fuentes: fotografía aérea y satélites. Estas imágenes son incorrectas respecto a la realidad que se esta sensando debido a varios aspectos: orientación de la cámara o sensor desplazamiento debido al relieve errores sistemáticos asociados a la imagen Cada sistema de adquisición (figura 1) produce distorsiones en la imagen cruda. Es decir, que es necesario corregir las deformaciones que se han producido en la imagen para lograr tener una representación lo mas cercana a la realidad. A este tipo de corrección, se la denomina corrección geométrica. Figura 1. Geometría de observación de un scanner de satélite en órbita alrededor de la tierra.[1] En el contexto de la teledetección, entendemos por corrección geométrica a un proceso de cambio de espacio de referencia: la imagen original tomada por el sensor está definida en un sistema local donde la localización de cada píxel queda determinada por su situación en filas y columnas: es el espacio imagen. La corrección geométrica ajusta esta imagen a un nuevo espacio de referencia donde cada píxel tiene asignado el valor XY que le corresponda en un sistema de proyección geográfica determinado: es el espacio de proyección[1]. 16

17 Cuando hablamos de corrección geométrica nos referimos a dos procedimientos: rectificación y ortorrectificación. Ambos métodos utilizan puntos de control (GCP's). El primero consiste en la corrección de la imagen en 2 dimensiones donde solo tiene en cuenta las dimensiones X e Y. Este método usa polinomios 2D para mapear coordenadas de un espacio en el otro. El segundo método incorpora una dimensión mas, la dimensión Z, representando la altura y utiliza polinomios 3D. Ambos métodos se basan en modelos físicos (donde los parámetros tienen significado físicos y la información es obtenida de los metadatos de las imágenes) y modelos empíricos (cuando no se dispone del metadatos de la imagen, es decir, no se conoce nada sobre el sensor). Todas las distorsiones geométricas requieren modelos y funciones matemáticas para realizar correcciones geométricas de las imágenes a través de modelos empíricos (tales como polinomios 2D/3D, funciones racionales 3D, RF's) o modelos físicos rigurosos con los cuales se refleja la realidad de la geometría de observación (plataforma, sensor, proyecciones de mapa, etc.)[2]. Métodos y procedimiento En la siguiente figura[2] se muestran los procesos y entradas y salidas en la Ortorrectificacion. En la figura anterior se representan tanto el proceso de rectificación como de ortorrectificacion. Las elipses denotan entradas y salidas y las cajas, procesos. Si se realiza una rectificación entonces se ignora la entrada DEM/DSM. Caso contrario, se incorpora dicha entrada al proceso y si los metadatos están disponibles también se lo ingresa, pero en el caso que lo metadatos no esten disponibles la orto-rectificación se realizada utilizando un modelo analítico o empírico. Explicado de otra manera[2]: 17

18 1. Adquisición de la imagen(s) y pre procesamiento del metadata 2. Adquisición de los puntos de control (GCP's) con coordendas de imagen y coordenadas de mapa X, Y, (Z) 3. Computación de lo parámetros desconocidos de las funciones matemáticas usadas por el modelo de corrección geométrico para una o mas imagenes. 4. Imagen(s) rectificadas con o sin DEM(Modelo de Elevación Digital) GRASS Es un software GIS (Geographic Information System) libre usado para análisis y manejo de datos espaciales, procesamiento de imágenes, producción de mapas y gráficos, modelado espacial y visualización. Actualmente es usado en el ámbito académico y comercial por muchas agencias gubernamentales y compañías de consultoria ambientales. Ademas es un proyecto oficial de la OSGeo(Open Source Geospacial Fundation)[3]. Características GRASS GIS contiene cerca de 350 módulos para renderizar mapas e imagenes sobre monitor y paper; manipula archivos raster y vectoriales incluyendo redes vectoriales; procesa imágenes multiespectrales; y crea, maneja y almacena datos espaciales. Ofrece dos interfaces de trabajo: un interfaz gráfica intuitiva y la linea de comandos para realizar las operaciones. GRASS GIS puede hacer de interfaz con impresoras, plotters y bases de datos para crear nuevos datos como asi para manejar datos existentes[3]. Esta desarrollado en el lenguaje C lo cual lo hace muy veloz a la hora de procesar la información, cuenta con una API en C [4]. Ademas, cuenta con una API en python, pygrass, que permite tener acceso a la API de C sin necesidad de conocer el lenguaje de programación C. Esta capacidad lo hace sumamente utilizable para programadores en lenguajes de alto nivel. Ademas, teniendo en cuenta que python es un lenguaje sumamente intuitivo, GRASS llega a usuarios no programadores que se atreven a escribir sus propios códigos sin tener demasiados conocimientos en el área de las ciencias de la computación. Funcionalidad de orto-rectificación GRASS cuenta con un módulo para ortho rectificación de fotografía aérea. En la versión 6.4 la herramienta para tal fin se llamaba i.photo.rectify y en la versión 7 i.ortho.rectify Un ejemplo completo y desarrollado para GRASS 6.4 puede encontrarse en [5] junto con el dataset en [6]. Esta guía muestra paso a paso como ortho rectificar una fotografía aérea utilizando la linea de comandos, es decís, escribiendo cada comando necesario para llevar a cabo el proceso. 18

19 OSSIM: Herramienta open source para ortorectificar OSSIM (Open Source Software Image Map) es un software muy potente para teledetección para procesamiento, análisis, sistemas de información geográfica y fotogrametría 2. Diseñado como una serie de librerías de alta performance, esta escrito en C++ y emplea las últimas técnicas de diseño orientado a objetos. Con el paquete OSSIM viene una gran variedad de utilidades de linea de comandos, aplicaciones con interfaz gráfica y otros sistemas que han sido integrado[7]. Características 1. Capacidad de procesamiento en paralelo con la librería MPI (Message Passing Interface). 2. Modelos de sensores rigurosos. 3. Modelos de sensores universales. 4. Amplio rango de proyecciones de mapas y Datums soportados. 5. Non-destructive, parameter based image chains. 6. Acceso a archivos nativos. 7. Corrección de terreno precisa y Ortorectificación. 8. Soporte de elevaciones... y muchas funciones mas. OSSIM implementa una gran variedad de modelos de sensor para la ortorectificación. En la siguiente tabla 1 se puede ver un resumen de los mismos. Tabla 1. Modelos de sensores soportados por OSSIM para la ortorectificación. 2 Es una técnica para determinar las propiedades geométricas de los objetos y las situaciones espaciales a partir de imágenes fotográficas. Puede ser de corto o largo alcance 19

20 Ademas forma parte del software OTB 3, principalmente para la ortorectificación que este realiza con gran calidad. Como funciona la ortorectificación Dentro de las utilidades de linea de comando que OSSIM trae en su paquete, se encuentra la llamada ossim-orthoigen. Dicha utilidad es instalada automáticamente cuando se instala OSSIM en nuestro sistema. La utilidad recibe distintos parámetros de entrada, cuyas opciones pueden visualizarse ejecutado ossim-orthoigen sin parámetros. Para lograr ortorectificar una imagen, este comando necesita al menos de 2 parámetros de entrada: la imagen a ortorectificar y un nombre de archivo de salida. Por ejemplo: ossim-orthoigen input.tif output.tif Ademas, y muy importante, es necesario proveer de un DEM (Digital Elevation Model) y el archivo del geoide a utilizar ya que para el calculo de la elevación se utiliza esta información. La forma de proveer de estos datos al programa es a través de un archivo de configuración donde se establecen al menos estos dos datos, especificando el path a los archivos. Tal archivo, en una instalacion de OSSIM en un sistema Linux Ubuntu, se encuentre en : /usr/share/ossim/templates/ossim_preferences_template En la figura 2 un ejemplo de configuración. Podemos observar distintos bloques de configuración especificando la rura al archivo DEM, algunos otros parametros especificos opcionales y la ruta al archivo del geoide utilizado. En este caso el GEO96. El archivo debe estar en formato grd. Con estos pocos datos, ossim es capaz de ortorectificar en un solo paso una imagen. 3ORFEO ToolBox es una librería para el procesamiento de imágenes de alto rendimiento. Es utilizado principalmente para el procesamiento de imágenes de sensores remotos como los capturados por radares, satélites o plataformas aéreas. 20

21 Figura 2. Ejemplo de configuración de archivo para ossim-orthoigen Antes de ejecutar el proceso, se puede hacer un chequeo para determinar si realmente para el archivo de entrada, existe un modelo de sensor implementado. Esto se puede lograr con el comando: ossim-info input_file el cual dara como resultado un listado con diversa información de la imagen, dentro de la cual, se debe chequear que el parametro image0.projection.type especifique un valor que sera algunos de los siguientes dependiendo del tipo de sensor que se uso para obtener la imagen de entrada: ossimapplanixecefmodel ossimapplanixutmmodel ossimcoarsegridmodel ossimrpcmodel ossimikonosrpcmodel ossimquickbirdrpcmodel ossimnitfrpcmodel ossimlandsatmodel ossimnitfmapmodel ossimfcsimodel ossimspot5model ossimsarmodel ossimbuckeyesensor ossimsonomasensor 21

22 ossimradarsatmodel ossimradarsat2model ossimterrasarmodel ossimenvisatasarmodel ossimerssarmodel ossimalospalsarmodel Con la infomación antes descripta es suficiente para lograr la ortorectificación de una imagen con OSSIM. Para otras variaciones y usos de otros parámetros puede consultarse la ayuda del comando. 22

23 Solución propuesta Debido a la falta de tiempo dentro de los dos meses que asigne a este trabajo dentro de la tutoria, no me fue posible implementar una solución. Por lo tanto, dejo planteada un propuesta de solución que podrían implementarse a futuro. Implementar un wrapper en C entre OSSIM y GRASSS Un Wrapper es un programa que controla el acceso a un segundo programa. El wrapper consiste en encapsular el comando ossim-orthoigen con funciones del lenguaje C con llamadas al sistema como execv[9], excecl, etc. Luego, se crea un comando que se ejecutara dentro de GRASS por linea de comandos. El programa debe tener las siguiente características: Entrada Imagen a ortorectificar Imagen de salida Archivo de configuración: en este archivo se debe configurar como minimo la ruta al DEM y al geoide. El archivo geoide debe ser estar en formato grd. Precondición Debe estar instalado OSSIM y GRASS. Se debe conocer la ruta del binario ossim-orthoigen. Debe estar creado el archivo de configuración para ossim-orthoigen con al menos definidas las rutas al DEM y al geoide. Procesamiento El programa tomara el archivo de configuración para obtener el path al DEM y al geoid, y hará una llamada al sistema al comando ossim-orthoigen. Previo a esto, se hará un chequeo para determinar si el modelo de sensor para la imagen de entrada, esta disponible. Sino, informara la imposibilidad de efectuar la operación. Esta información se obtiene leyendo la salida del comando ossim-info, en particular, la linea de salida: image0.projection.type. Salida En caso de éxito, genera una imagen orto-rectificada. Otra idea Una posible opción y tal vez mas viable, es pensar en una solución basada en la utilización de pygrass y pyossim. Esta solución se basa en crear un script python utilizando las API de pygrass y pyossim, aunque sin posibilidad de investigar mas al respecto solo queda planteanda la idea de usar estas herramientas. 23

24 Referencias Tutoría de Investigación Lic. Zader Pablo 1. Cuartero, A., Felicísimo, A. M. (2003): "Rectificación y ortorrectificación de imágenes de satélite: análisis comparativo y discusión", GeoFocus (Artículos), nº 3, 2003, p ISSN: Review article: Geometric processing of remote sensing images: models, algorithms and methods. T. TOUTIN Web site oficial: 4. Web site oficial: 5. Open Source GIS: A GRASS Aproach. Second edition. Chapter 10 PROCESSING OF AERIAL PHOTOS Web site oficial: 8. Web site oficial: Robust rectification of aerial photographs in an open source environment Duccio Rocchini a,n Markus Neteler 11. GEOMETRIA DE LA FOTOGRAFÍA AÉREA. Luis Jauregui 12. Ortho-rectification of QuickBird imagery with OSSIM. Stefan Sylla 13. Satellite Orientation and Position for Geometric Correction of Scanner Imagery. Paul H. Salamonowicz* 14. The Orfeo ToolBox Cookbook, a guide for non-developers Updated for OTB OSSIM Sensor Modeling. Oscar Kramer, Kramer Analytic, LLC. 16. GENERACIÓN DE DATOS GEORREFERENCIADOS DE MUY ALTA RESOLUCIÓN A PARTIR DE IMÁGENES DE GeoEye C++: Cookbook D. Ryan Stephens, Christopher Diggins, Jonathan Turkanis, Jeff Cogswell 24