Monitorización en tiempo real de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección

Proyecto final de carrera Monitorización en tiempo real de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección Alumno: Miguel Ángel Querol Carratalá Correo: [email protected] Tutor: Javier Lluch Crespo Proyecto final de carrera. 2 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Índice de contenido 1 INTRODUCCIÓN...............................................................................................................5 1.1 Gestión de recursos hídricos en la Confederación Hidrográfica del Guadalquivir.....6 1.2 Objetivos.....................................................................................................................8 1.3 Estructura del documento.........................................................................................10 2 ESTADO DEL ARTE.........................................................................................................11 2.1 Sistemas de información geográfica.........................................................................11 2.1.1 Funcionamiento de los SIG................................................................................17 2.1.2 Modelo de datos de los SIG...............................................................................19 2.1.3 Aplicaciones de los SIG.....................................................................................26 2.1.4 Algunos SIG en el mercado...............................................................................29 2.1.5 GvSIG.................................................................................................................30 2.2 Gdal..........................................................................................................................40 2.2.1 Acceso a datos raster con gdal en gvSIG..........................................................41 2.2.2 Herramientas proporcionadas por gdal.............................................................42 2.3 Proyecciones cartográficas.......................................................................................43 2.3.1 Reproyección de capas.....................................................................................46 2.4 Sensores MODIS......................................................................................................48 2.4.1 Hierarchical Data Format (HDF)........................................................................52 2.5 Teledetección............................................................................................................53 2.5.1 Proceso de teledetección..................................................................................55 2.5.2 Índices de vegetación........................................................................................59 3 PLANIFICACIÓN DEL PROYECTO.................................................................................63 3.1 Ciclo de vida en cascada..........................................................................................63 3.2 Especificación de requisitos y estimación temporal.................................................66 4 ANÁLISIS.........................................................................................................................74 4.1 Definición del sistema y componentes......................................................................74 4.2 Descripción de funcionalidades................................................................................78 4.2.1 Soporte para imágenes MODIS........................................................................79 4.2.2 Reproyección de capas raster...........................................................................82 4.2.3 Cálculo de índices de vegetación a partir de series temporales......................84 4.2.4 Generación de datos vectoriales a partir de datos raster.................................88 4.2.5 Análisis estadístico............................................................................................89 5 DISEÑO E IMPLEMENTACIÓN.......................................................................................94 5.1 Entorno de trabajo.....................................................................................................95 5.1.1 Eclipse................................................................................................................95 5.1.2 Java Native Interface (JNI).................................................................................97 5.1.3 Entorno de programación de código nativo.......................................................98 5.1.4 IzPack.................................................................................................................98 5.2 Diseño de funcionalidades.......................................................................................99 5.2.1 Soporte MODIS y reproyección.......................................................................100 5.2.2 Añadir capas MODIS.......................................................................................105 5.2.3 Herramienta de reproyección raster................................................................107 3 Proyecto final de carrera. 5.2.4 Cálculo de índices de vegetación....................................................................109 5.2.5 Herramienta de generación de datos vectoriales............................................112 5.2.6 Herramienta de análisis estadístico.................................................................114 5.2.7 Herramienta de cálculo raster..........................................................................119 5.3 Generación de instaladores....................................................................................119 6 FASE DE TEST..............................................................................................................122 7 CONCLUSIONES Y TRABAJO FUTURO.....................................................................125 7.1 Conclusiones...........................................................................................................125 7.2 Trabajo futuro...........................................................................................................126 8 BIBLIOGRAFÍA..............................................................................................................127 ANEXO A: Manual de usuario............................................................................................129 4 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 1 INTRODUCCIÓN Durante las últimas décadas el tratamiento de la información ha ido adaptándose a las nuevas tecnologías hasta el punto en que, actualmente, la práctica totalidad de la información se puede encontrar en formato digital. De esta forma, los sistemas de información tradicionales se encuentran totalmente integrados con los sistemas informáticos. Cualquier información susceptible a ser representada en formato digital, como pueden ser datos numéricos, imágenes o sonidos, puede pasar a formar parte de un sistema de información informático. De esta forma, los datos geográficos no han sido una excepción y se han conformado los Sistemas de Información Geográfica (SIG). Los SIG se definen como sistemas de información capaces de representar y analizar características y acontecimientos geográficos. Se diseñan para capturar, almacenar, manipular, analizar y desplegar en todas sus formas la información geográficamente referenciada con el fin de resolver problemas complejos de planificación y gestión. Dada la naturaleza de la información con la que trabajan, los SIG, se están utilizando cada vez más dentro del ámbito de la administración pública con diferentes propósitos, como planeamientos urbanísticos, gestión de comercios o mantenimiento y gestión de carreteras. Este auge en la popularidad de los SIG supone el surgimiento de nuevos desarrollos dentro del ámbito de esta tecnología. Estrechamente relacionada con los SIG se define la teledetección como la ciencia y arte de obtener información acerca de la superficie de la Tierra sin entrar en contacto con ella. Esto se realiza detectando y grabando la energía reflejada por cada elemento de la superficie terrestre y procesando, analizando y aplicando esta información. Se basa en que cada objeto, área o fenómeno emite un espectro electromagnético específico, en función de su propia naturaleza y de las radiaciones que recibe. La reflectancia de ese espectro electromagnético se denomina firma espectral, la cual hace distinguible a ese objeto, superficie o fenómeno de los demás. Por lo general los datos son recogidos a través de sensores instalados en plataformas aerotransportadas o en satélites artificiales, los cuales captan la radiancia 5 Proyecto final de carrera. emitida o reflejada, obteniéndose una imagen, habitualmente en falso color con una banda para cada una de estas regiones del espectro. Una imagen de satélite, o una fotografía aérea, no es más que una capa raster sin georreferenciar, por tanto las vamos a poder almacenar, manejar, analizar, etc. en un entorno SIG. Dentro de este contexto se desarrolla el presente trabajo, en el que utilizan tecnologías SIG y técnicas de teledetección para afrontar un proyecto contratado por la Confederación Hidrográfica del Guadalquivir a la empresa Iver. El alumno trabaja desde hace varios años en la empresa Iver como Jefe de Proyecto y Programador, colaborando en el desarrollo del SIG en software libre impulsado por la Conselleria de Infraestructura y Transporte, gvSIG. Del mismo modo, realiza proyectos de consultoría SIG, como el que se desarrolla en esta memoria, para diferentes clientes dentro de la administración pública a nivel nacional. Este proyecto se asignó íntegramente al alumno por lo que es susceptible a presentarse como Proyecto Fin de Carrera del mismo. Se realizó durante los meses de marzo, abril, mayo y junio del año 2007. El proyecto pretende desarrollar un sistema, integrado en la herramienta gvSIG, capaz de monitorizar los recursos hídricos de la Cuenca del Guadalquivir con una frecuencia temporal cercana al tiempo real. 1.1 Gestión de recursos hídricos en la Confederación Hidrográfica del Guadalquivir La Confederación Hidrográfica del Guadalquivir (CHG) tiene la competencia de gestionar los recursos hídricos de la cuenta de la que toma su nombre. La actividad y el desarrollo económico de este territorio son muy sensibles a las fluctuaciones de estos recursos, al tener en su actividad económica una fuerte presencia la agricultura de regadío. Durante la época estival las temperaturas y la evotranspiración son muy elevadas, y las lluvias escasas, justo cuando las necesidades de agua son mayores al incrementarse también la demanda para uso humano. Esta descompensación se ve aún más acentuada en épocas de sequía como la que nos ocupa, en las que el organismo de cuenca se ha visto obligado a reducir las dotaciones de agua destinadas a riego. La 6 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. existencia de una demanda creciente de un recurso limitado obliga a un control más estricto de su consumo durante las épocas de escasez. La CHG, al igual que el resto de organismos de cuenca, obligados por la legislación vigente, ya dispone de varias redes de observación, que se encargan de recoger series históricas sobre las medidas realizadas de distintos parámetros, que permiten cuantificar tanto la cantidad como la calidad de las aguas: nivel de agua embalsada, aforos, temperaturas, precipitaciones, piezometría, etc. No obstante, los datos cosechados por estas redes, si bien esenciales pues proporcionan mediciones hechas con un alto grado de precisión, presentan dos importantes problemas: Falta de una adecuada densificación espacial, dado que las estaciones de medida de la CHG están situadas en un número concreto de puntos y no cubren la totalidad del territorio de la cuenca. Desfase entre la fecha de recogida del dato y la fecha en que éste es cargado en el sistema, al predominar todavía la instrumentación analógica. Por tanto no es posible la monitorización de los recursos de la cuenta en dentro de unos márgenes temporales adecuados. Con todo lo expuesto anteriormente, el objetivo último de este proyecto, es disponer de una herramienta que cubra todas las fases del tratamiento de la información: soporte para las imágenes capturadas por el satélite, su tratamiento para reproyectarlas al sistema de coordenadas del resto de la cartografía utilizada, tratamientos previos, obtención de magnitudes e índices con significado físico (NDVI, VCI, evapotranspiración, etc.), generación de imágenes estadísticas a partir de las series históricas (NDVI medio para un año, NDVI medio por mes, anomalía del NDVI del último mes respecto al NDVI medio de idéntico mes para el total de la serie histórica, etc.), operaciones de álgebra de mapas en las que intervengan tanto modelos como imágenes procedentes de teledetección, etc. Una vez generadas las diferentes “coberturas” (entendiendo el término según el significado que da la OGC) se generan valores estadísticos mediante el cruce de los datos raster con capas vectoriales. De este modo podemos calcular el NDVI promedio de un 7 Proyecto final de carrera. municipio de la cuenca para un día determinado y almacenar su serie histórica en la base de datos relacional corporativo, junto con el resto de las series, de forma que pueda ser consultada desde el resto de sistemas corporativos. Las imágenes empleadas en este trabajo son las recogidas por el sensor MODIS, debido a su excelente resolución temporal (una escena diaria) y a su aceptable resolución espacial (hasta 250 metros por píxel, lo que permite monitorizar el riego en parcelas de 6.25 hectáreas). Se han utilizado tanto las imágenes facilitadas por el servicio MODIS Rapid Response System (debido a su excelente disponibilidad, el mismo día en que la escena es captada), como las imágenes MODIS de NDVI proporcionadas de forma quincenal [CHG]. La herramienta que ha servido para realizar todos estos procesos ha sido gvSIG, al que se le han añadido una serie de extensiones que permiten automatizar el proceso al máximo, de forma que el operador se limite a cargar las imágenes NDVI proporcionadas por MODIS de forma periódica, realizando el proceso de carga, reproyección, generación de nuevos índices de vegetación a partir de series temporales, generación de estadísticas y actualización de los sistemas corporativos con éstas. De este modo se ha conseguido disponer de una nueva visión del estado de la cuenca, que aporta un mayor grado de agilidad a los periodos de captura – tratamiento – análisis de información anteriores. Como efecto secundario nada despreciable, se obtiene la posibilidad de dar información rigurosa al público, diariamente, del estado de la cuenca, mediante su publicación con un servidor de mapas Mapserver de libre acceso. 1.2 Objetivos Con todo lo expuesto anteriormente, el objetivo de este proyecto es generar un conjunto de herramientas que se integren como un sistema capaz de, tomando como entradas los datos proporcionados por el servicio MODIS referentes al índice de vegetación NDVI, proporcionar información cuantificable e interpretable con una 8 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. resolución temporal óptima, a fin de posibilitar la monitorización de la cuenca del Guadalquivir de una forma continua. A continuación se detallan las principales herramientas desarrolladas en el proyecto y su función dentro del proceso de monitorización. Soporte para imágenes proporcionadas por MODIS: El servicio “MODIS Rapid Response System” proporciona imágenes en formato HDF (Hierarchical Data Format). La versión de gvSIG utilizada para el desarrollo del proyecto no tiene soporte para este formato, por lo tanto es necesario habilitarlo, así como dotar a gvSIG de los mecanismos necesarios para tener en cuenta las particularidades del formato. Reproyección de capas raster: Dado que la proyección de las diferentes capas raster que pueden formar parte de los estudios hidrográficos pueden estar en sistemas de coordenadas diferentes, es necesario desarrollar una herramienta para poder cambiar la proyección de una imagen. Cabe destacar que la herramienta de reproyección incluida en la versión 1.9 de gvSIG se ha basado en la desarrollada en este proyecto. Obtención de nuevos índices de vegetación a partir de series temporales de NDVI. Se desarrollan las herramientas necesarias para obtener los índices ΣNDVI, VCI y Coeficiente de variación, a partir de series temporales de imágenes NDVI. Herramienta para generar, a partir de una o varias imágenes NDVI, datos estadísticos numéricos que serán añadidos a la tabla de una capa vectorial que actúa como máscara de las regiones que conforman la población de dichas estadísticas. Generación de estudios estadísticos completos, tanto numéricos como gráficos a partir de una o varias imágenes que representen índices de vegetación. Calculadora de capas raster: Adaptación de la calculadora de capas raster presente en la versión 1.9 de gvSIG a la versión 1.1.2. 9 Proyecto final de carrera. intereses corporativos, en detrimento de la iniciativa privada, que pasa a ocupar en este momento un segundo plano. En este periodo se desarrolla el segundo tipo de sistemas. La estructuración de la información espacial basada en cuadrículas o pixels se complementará con la estructuración de la información vectorial, dando paso a los “sistemas vectoriales”. En este caso, los datos geográficos se sitúan en el espacio a partir de la definición de sus coordenadas. Los nuevos sistemas vectoriales, en sus inicios, se asemejaban más a programas de diseño asistido por ordenador que a SIG. Era necesario estructurar topológicamente los datos, esto es, establecer las relaciones espaciales entre las entidades geográficas, para así dotar al sistema con funciones de análisis espacial. En esta nueva línea de trabajo, y bajo este nuevo formato, se crea el sistema POLYVRT, también diseñado por la universidad de Harvard, que además de estar considerado como un programa para la producción cartográfica fue también un modelo de datos, al incluir y mejorar los ficheros Dual Independent Map Encoding (DIME). 4. 1980 – 1990: Fase de comercialización. Se produce la expansión de los SIG. El interés demostrado por industrias relacionadas o no con los SIG provoca su divulgación y comercialización masiva. La bajada de los precios provocada por el desarrollo comercial, junto con la cada vez mayor capacidad de tratar gran cantidad de información, hace que desde las universidades de EEUU empiece a concebirse la posibilidad de unir bases de datos gráficos con alfanuméricos. El mercado no tardará en ofrecer programas denominados de Información Geográfica que aprovechan el desarrollo tecnológico para unir las funciones de producción cartográfica con funciones de análisis. La empresa Enviroment Systems Research Institute (ESRI) es un hito a destacar dentro de este pequeño recorrido histórico que en torno a los SIG se está exponiendo. Y ello, fundamentalmente, porque no solo se ha mantenido en el mercado desde su aparición en 1969, sino porque también ha convertido sus 16 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. productos en un estándar en la tecnología SIG. 5. Actualmente: Fase de usuario. La nueva herramienta ya está lo suficientemente consolidada como para que pueda ser utilizada en un número cada vez mayor de aplicaciones. Esta última fase se caracteriza por: Competencia en el mercado, lo que arrastra una estandarización en los SIG. Incremento de sus usuarios, diversificando sus usos en el campo de las aplicaciones. 2.1.1 Funcionamiento de los SIG El componente más importante para un SIG es la información. Se requieren de buenos datos de soporte para que el SIG pueda resolver los problemas y contestar a preguntas de la forma mas acertada posible. El mapa tradicional es una representación analógica (continua) de la realidad, por lo tanto, no está adaptado para ser procesado por un ordenador que utiliza datos en formato digital (discreto). Por ello el primer paso que es necesario realizar para introducir los datos a un SIG es convertirlos al formato digital. Lo más problemático de este proceso es la representación en esta forma de la componente espacial de los datos geográficos. La consecución de buenos datos generalmente absorbe entre un 60 y 80 % del presupuesto de implementación del SIG, y la recolección de los datos es un proceso largo que frecuentemente demora el desarrollo de productos que son de utilidad. La información producida solo tiene el valor de los datos introducidos previamente. Una información incorrecta o insuficiente introducida en el SIG produciría respuestas incorrectas o insuficientes, por muy perfeccionada o adaptada al usuario que pueda ser la tecnología. Los datos geográficos y alfanuméricos pueden obtenerse por recursos propios u obtenerse a través de proveedores de datos. Mantener organizar y manejar los datos debe ser política de la organización. La información espacial contiene una referencia geográfica explicita como latitud y longitud o una referencia implícita como domicilio o código postal. Las referencias 17 Proyecto final de carrera. implícitas pueden ser derivadas de referencias explícitas mediante geocodificación. Los SIG funcionan con dos tipos diferentes de información geográfica: el modelo vectorial y el modelo raster. El modelo raster ha evolucionado para modelar tales características continuas. Una imagen raster comprende una colección de celdas (píxel) de una rejilla más como un mapa o una figura escaneada. Ambos modelos para almacenar datos geográficos tienen ventajas y desventajas únicas y los SIG modernos pueden manejar varios tipos. En el modelo vector, la información sobre puntos, líneas y polígonos se almacena como una colección de coordenadas x, y. La ubicación de una característica puntual, pueden describirse con un sólo punto x, y. Las características lineales, pueden almacenarse como un conjunto de puntos de coordenadas x, y. Las características poligonales, pueden almacenarse como un circuito cerrado de coordenadas. El modelo vector es extremadamente útil para describir características discretas, pero menos útil para describir características de variación continua. El SIG funciona como una base de datos con información geográfica (datos alfanuméricos) que se encuentra asociada por un identificador común a los objetos gráficos de un mapa digital. De esta forma, señalando un objeto se conocen sus atributos e, inversamente, preguntando por un registro de la base de datos se puede saber su localización en la cartografía. 18 Figura 2: Capas de un SIG Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. La razón fundamental para utilizar un SIG es la gestión de información espacial. El sistema permite separar la información en diferentes capas temáticas y las almacena independientemente, permitiendo trabajar con ellas de manera rápida y sencilla, y facilitando al profesional la posibilidad de relacionar la información existente a través de la topología de los objetos, con el fin de generar otra nueva que no podríamos obtener de otra forma [SIG]. 2.1.2 Modelo de datos de los SIG Los datos SIG representan los objetos del mundo real (carreteras, el uso del suelo, altitudes). Los objetos del mundo real se pueden dividir en dos abstracciones: objetos discretos (una casa) y continuos (cantidad de lluvia caída, una elevación). Existen dos formas de almacenar los datos en un SIG: raster y vectorial. Datos vectoriales El modelo vectorial es una estructura de datos utilizada para almacenar datos geográficos. Los datos vectoriales constan de líneas o arcos, definidos por sus puntos de inicio y fin, y puntos donde se cruzan varios arcos, los nodos. La localización de los nodos y la estructura topológica se almacena de forma explícita. Las entidades quedan definidas por sus límites solamente y los segmentos curvos se representan como una serie de arcos conectados. El almacenamiento de los vectores implica el almacenamiento explícito de la topología, sin embargo solo almacena aquellos puntos que definen las entidades y todo el espacio fuera de éstas no está considerado [IGAC]. Un SIG vectorial se define por la representación vectorial de sus datos geográficos. De acuerdo a las peculiaridades de este modelo de datos, los objetos geográficos se representan explícitamente y, junto a sus características espaciales, se asocian sus valores temáticos. Hay dos formas de organizar esta base de datos doble (espacial y temática). Normalmente, los sistemas vectoriales tienen dos componentes: uno que almacena los datos espaciales y otro los datos temáticos. A éste se le denomina sistema de 19 Proyecto final de carrera. organización híbrido, por unir una base de datos relacional, para los aspectos temáticos, con una base de datos topológica, para los geográficos. Un elemento clave en este tipo de sistemas es el identificador de cada objeto. Éste es único y diferente para cada objeto y permite la conexión entre ambas bases de datos. En el modelo de datos vectorial (figura 3), los datos geográficos se representan en forma de coordenadas. Las unidades básicas de información geográfica en los datos vectoriales son puntos, líneas (arcos) y polígonos. Cada una de éstas se compone de uno o más pares de coordenadas, por ejemplo, una línea es una colección de puntos interconectados, y un polígono es un conjunto de líneas interconectadas. Coordenada: Pares de números que expresan las distancias horizontales a lo largo de ejes ortogonales, o tríos de números que miden distancias horizontales y verticales, o n-números a lo largo de n-ejes que expresan una localización concreta en el espacio n-dimensional. Las coordenadas generalmente representan localizaciones de la superficie terrestre relativas a otras localizaciones. Punto: Abstracción de un objeto de cero dimensiones representado por un par de coordenadas X,Y. Normalmente un punto representa una entidad geográfica demasiado pequeña para ser representada como una línea o 20 Figura 3: Representación vectorial Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. como una superficie; por ejemplo, la localización de un edificio en una escala de mapa pequeña, o la localización de un área a la que una instalación da servicio en una escala de mapa media. Línea: Conjunto de pares de coordenadas ordenados que representan la forma de entidades geográficas demasiado finas para ser visualizadas como superficies a la escala dada (curvas de nivel, ejes de calles, o ríos), o entidades lineales sin área (límites administrativos). Una línea es sinónimo de arco. Arco: Término específico de ARC/INFO que se utiliza como sinónimo de línea. Polígono: Entidad utilizada para representar superficies. Un polígono se define por las líneas que forman su contorno y por un punto interno que lo identifica. Los polígonos tienen atributos que describen al elemento geográfico que representan. Datos raster El modelo de datos raster, [UAH] es el modelo de datos complementario al modelo vectorial presentado anteriormente. Tiene como principal característica el llevar a cabo una representación “discreta” del mundo real, empleando una malla de rejillas regulares que denominaremos celdillas o píxeles. Para cada celdilla se almacena un valor numérico que representa el valor de un determinado aspecto del mundo real en el interior de dicha celdilla. 21 Proyecto final de carrera. Generalmente, cada capa raster almacena en sus celdillas valores de un único aspecto del mundo real: usos del suelo, temperatura, pendiente, precio del suelo, carreteras, red hidrográfica… de tal forma que cada aspecto o variable de la realidad sería representado por una capa raster. Para el caso de las variables cualitativas como por ejemplo los usos del suelo, se almacenaría en cada celdilla un código numérico que representaría el tipo de uso existente en dicha celdilla. 22 Figura 5: Equivalencia entre códigos numéricos y tipos de uso del suelo Figura 4: Malla raster. En cada pixel se almacenan valores numéricos Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Para el caso de las variables cuantitativas, como por ejemplo el caso de las pendientes, el número que se almacenaría se correspondería con el valor de la variable en esa celda. Otra de las principales característica del modelo “raster”, es que registra el interior de los objetos en lugar de codificar sus fronteras, de tal forma que los límites quedan implícitamente representados por los límites de las celdillas que presentan un mismo valor. Siguiendo con el ejemplo de los usos del suelo, se puede observar en la figura 6 izquierda, que tras superponer la malla raster y codificar los elementos existentes en el interior de cada píxel, se obtiene la imagen de la figura 6 derecha, en la que los límites de los usos del suelo quedan delimitados de forma implícita por los bordes de las celdillas, y de ahí su aspecto, que comúnmente denominamos “pixelado”. Esta característica del modelo raster permite representar mejor las variables continuas (elevaciones, precipitación, precio del suelo…), que varían de forma gradual en el espacio (figura 7 izquierda) y en las que no existen unos límites bien diferenciados de las diferentes entidades espaciales. Para poder representar variables de este tipo en el modelo vectorial sería necesario agrupar los rangos de valores en intervalos (figura 7 derecha). 23 Figura 6: Usos del suelo y su codificación raster Proyecto final de carrera. Se han presentado las celdillas o píxeles como los elementos fundamentales del modelo, de las misma forma que en el modelo vectorial lo eran los puntos, las líneas y los polígonos. A continuación se muestran algunas de las principales características de las celdillas consideradas más importantes para un mejor conocimiento de este modelo de datos: Regulares: Las celdillas son regulares, es decir todas son iguales, estableciendo una codificación discreta de las coordenadas. La celdilla es la unidad mínima en un archivo raster, y por ello el tamaño de celda lo da la precisión con que se pueden definir los elementos geográficos. Localizables por su número de fila y columna. Cada celda puede ser identificada por su posición en la matriz del archivo raster, a partir de su número de fila y columna. Contienen un valor numérico que puede ser el identificador de la celda o el valor temático de la misma (elevaciones, temperatura, etc), de tal forma que la geometría y la componente temática se almacenan a la vez. Como se puede observar en las figuras 6 y 7, la codificación raster de la información supone una pérdida de la misma con respecto a la realidad, debido a que este modelo supone una simplificación del mundo real. Dentro de esta representación de la realidad “raster” que hemos tratado de relatar 24 Figura 7: Representación de las elevaciones y agrupación en intervalos para su representación vectorial Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. brevemente, existen varias estructuras de datos, que representan la forma en la que se almacenan en el ordenador los valores registrados en cada una de las celdillas. Generalmente los SIG raster almacenan la información de cada capa en mínimo dos ficheros: el fichero de valores y el fichero de documentación, este último en el que se señala la resolución del raster, número de filas y columnas, etc. Una característica muy importante de los SIG raster es el compartir el modelo de datos con las imágenes procedentes de los sensores satelitales. Dicho de otra forma, los datos aportados por los satélites, son datos raster. De hecho, los SIG y la teledetección, son técnicas que se han desarrollado de forma paralela. De esta forma, las imágenes tomadas por los diferentes sensores remotos a bordo de satélites pueden ser perfectamente integradas en un SIG raster, como por ejemplo IDRISI, GRASS o MODIS. En este trabajo se ha desarrollado el soporte para imágenes procedentes del sensor MODIS dentro del GIS gvSIG. Generalmente se suelen incorporar al SIG los resultados de haber llevado a cabo un proceso de clasificación o de extracción de información temática de la imagen mediante técnicas de tratamiento propias de la teledetección. Así podríamos incorporar a nuestro SIG capas de información temática como cubiertas del suelo, índices de productividad vegetal, zonas afectadas por incendios, superficies cubiertas de agua,… que pueden generarse a través del tratamiento de estas imágenes de satélite. El potencial de la teledetección como fuente de información para los SIG es enorme como aquí se esboza, por lo que esta facilidad de integración entre la teledetección y los SIG raster debe ser tenida en cuenta como una posibilidad de obtención, tratamiento e integración de información territorial muy importante para la gestión del territorio, que sólo de una forma más dificultosa podríamos realizar empleando SIG vectoriales. Este proyecto aplica técnicas de teledetección sobre imágenes raster para controlar los recursos hídricos de la cuenca del Guadalquivir, ejemplo claro del uso de los SIG raster, que contribuyen a facilitar la gestión de estos recursos. Se han presentado los dos modelos de datos que permiten representar en un SIG las entidades del mundo real, ya sea gracias a la codificación de sus límites (modelo 25 Proyecto final de carrera. aplicación fácilmente, así como desarrollar aplicaciones totalmente nuevas a partir de las librerías utilizadas en gvSIG (siempre y cuando cumplan la licencia GPL). Las características principales de gvSIG se pueden resumir en: Modularidad: El programa está construido con un conjunto de funciones básicas, comunes a todos los programas de ventanas, y es capaz de leer y escribir datos de diversas fuentes (programas de CAD o SIG , servidores de mapas de tipo WMS y WFS). Algunas de ellas forman parte del núcleo del programa pero la mayor parte están programadas como extensiones (plugins). El modelo de objetos final (núcleo + extensiones) es perfectamente accesible por nuevas extensiones que se desarrollen. Las nuevas extensiones se integrarán de manera transparente como si formaran parte de el programa desde el principio. Cada usuario podrá tener en su ordenador solo aquellas partes que necesite, de manera que el uso y el mantenimiento del programa será tan sencillo o más que los que actualmente se emplean. Interoperatividad: Una vez finalizado, nos vamos a encontrar con la aparición de nuevos formatos. Se requerirá el desarrollo de nuevas extensiones para ser usadas con el programa. Una vez finalizado este nuevo desarrollo esas extensiones se incorporarán a las instalaciones que ya se hayan efectuado de manera que cualquier usuario acceda a esos datos con nuevos formatos. Código abierto: En todo momento los programadores tendrán acceso al código fuente original del programa, lo que hará mucho más rápido el desarrollo de nuevas funcionalidades, así como la sustitución de algunas que se haya decidido mejorar. Sujeto a estándares: Cada nueva fuente de datos o usuario que se incorpore lo hará con facilidad si sigue estos estándares, puesto que está previsto desde el principio en la concepción del programa. Economía: Al contar con un desarrollo inicial de amplio horizonte, la adecuación para nuevos usos requerirá solo de pequeñas adaptaciones en 32 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. forma de extensión. Esto reducirá mucho el coste de desarrollo de esos nuevos usos. Así mismo, al estar libre de licencias el coste por PC para cada nueva instalación será muy reducido. Portabilidad: La tendencia al uso de Linux en los ordenadores de usuario final, así como la gran cantidad de versiones diferentes de Windows instaladas (que cambian a lo largo del tiempo) da al programa una gran flexibilidad, ya que un grupo de usuarios puede usar el mismo programa y datos, sin importar que las plataformas que usen no sean homogéneas. De la misma manera se pueden incorporar con facilidad nuevos usuarios independientemente de su hardware / software usado. Podría darse el caso de que alguna plataforma no soportada inicialmente (Apple, UNIX, BSD) necesitase de modificaciones. Al ser un desarrollo en Java el coste económico y técnico de estas migraciones será realmente asequible. A continuación, se pasa a explicar a grandes rasgos la arquitectura con la que se ha desarrollado gvSIG en su versión 1.1, para que el lector pueda hacerse una idea de la interfaz que se proporciona y el funcionamiento de su núcleo. El proyecto gvSIG se presenta como un framework sobre el que se pueden ir añadiendo plugins que le doten de nuevas funcionalidades. La plataforma que proporciona gvSIG se sustenta en una arquitectura abierta en la que cada equipo que está desarrollando un plugin se puede centrar en su área de experiencia. Puede haber equipos especializados en librerías base, mientras que otros equipos se centran en desarrollar interfaces de usuario para que las herramientas de base estén accesibles para los usuarios finales. GvSIG usa un modelo que consiste en presentar un conjunto de herramientas de forma homogénea desde el punto de vista del usuario. Las herramientas que se desarrollan se integran dentro del marco de gvSIG usando unos mecanismos ya definidos llamados plugins. La plataforma gvSIG en sí misma esta construida a modo de capas, cada una de las cuales define sus propios puntos de extensión. A su vez, cada plugin puede definir sus 33 Proyecto final de carrera. propios puntos de extensión. Este modelo de plugins, permite a los desarrolladores añadir gran variedad de funcionalidades a la plataforma base de gvSIG, de forma que los artefactos de cada herramienta, como pueden ser los distintos tipos de capas, o botones, se presentan al usuario desde la plataforma común. Los desarrolladores de plugins también se benefician de esta arquitectura. El framework base de gvSIG les proporciona una serie de servicios de los cuales ellos no tienen que preocuparse, pudiéndose centrar en las tareas especificas de su extensión. GvSIG está estructurada en una serie de subsistemas los cuales están implementados como librerías y como plugins en si mismos. La plataforma de gvSIG esta conformada en su núcleo por tres subsistemas [DEV]: gvSIG. Representa los datos geográficos manejados por Fmap. En este subsistema encontraremos las clases que implementan la mayor parte de cuadros de diálogo que utiliza la aplicación final, así como las clases de soporte a esos cuadros de diálogo. Por ejemplo, aquí se encuentran los formularios para asignar leyendas, crear mapas y vistas, definir escalas, etc. FMap. Es el corazón SIG de la plataforma. Incluye todas las clases necesarias para manejar objetos SIG, así como drivers y adaptadores para manejar los formatos más usados para el almacenamiento de los datos cartográficos. Dentro de esta librería encontramos clases para leer y escribir los formatos soportados, dibujar los mapas a las escalas adecuadas, asignar leyendas, definir simbologías, realizar búsquedas, consultas, análisis, etc. Subdriver. En este subsistema encontramos todas las clases que permiten el acceso y la gestión de los datos. 34 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Subsistema gvSIG Representa la parte visual de la aplicación. Es la representación gráfica de los datos geográficos. Gestiona el interfaz de usuario. Se compone de un gestor gráfico llamado Andami y de los distintos documentos que pueden formar un proyecto [DEV]. 35 Figura 9: Diagrama de subsistemas de gvSIG Proyecto final de carrera. Andami: Proporciona los métodos necesarios para que los plugins puedan comunicarse tanto con la aplicación principal como entre ellos. Soporta también los métodos necesarios para gestionar el interface gráfico. Project: Es el contenedor de la estructura de documentos que hay cargados en un momento dado. Contiene también los datos básicos del proyecto (nombre, fecha,...) Documents: Son los distintos tipos de documentos que soporta la aplicación, en la actualidad existen 3 tipos de documentos, Vistas, Tablas y Mapas. Proporciona los puntos de extensión necesarios para incluir nuevos tipos de documentos. View: Representación gráfica de la cartografía así como la leyenda en el ToC. Layout: Es la representación gráfica de una vista en un soporte apto para imprimir. Table: Es la representación gráfica de los datos alfanuméricos. Layers: Son el conjunto de capas que pueden insertarse en una vista de gvSIG. 36 Figura 10: Bloques del subsistema gvSIG Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Subsistema Fmap Se puede considerar Fmap como la capa que comunica las librerías de acceso a datos con la interfaz gráfica de gvSIG. Proporciona los mecanismos y las estructuras de datos necesarias para poder trabajar con objetos propios de los sig así como el modelo de datos de gvSIG. La clase MapContext representa este modelo de datos. De la misma forma se implementan drivers para acceder a los datos y estructuras (FLayers) para poder representar dichos datos como capas dentro del SIG. Es el controlador de la cartografía tanto para dibujarse como para acceder a los datos. Es el motor de SIG de la aplicación. A grandes rasgos puede decirse que se compone de un gestor de herramientas, capas y orígenes de datos para las capas y las geometrías que se utilizarán para representar los datos en las capas [DEV]. MapControl: Se encarga de dibujar y mantener la herramienta actual, conoce todas las herramientas que existen en la aplicación MapContext: Es el contexto de la parte gráfica. Contiene los elementos 37 Figura 11: Diagrama de bloques de FMap Proyecto final de carrera. necesarios para que el MapControl pueda realizar su labor. Behaivor: Es un comportamiento de una herramienta. También dice como se comporta la herramienta gráficamente. Controla el dibujado de la herramienta y el iniciador de los eventos de la herramienta. Listeners: Son los encargados de gestionar los eventos de las distintas herramientas, ya sea propagándolos hacia quien corresponda o ejecutando las instrucciones necesarias. Layer: Contiene las características de la capa y las herramientas necesarias para su gestión. Geometrías: Son los distintos tipos de elementos gráficos que pueden ser representados dentro de una layer. Subsistema subdrivers Es el bloque que está recuperando los datos directamente de la fuente. Sirve de puente entre la aplicación y los datos. Contiene las clases necesarias para acceder a los datos, escribir datos en una fuente, así como las propiedades de acceso a fuentes remotas [DEV]. 38 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. RemoteServices: Contiene las herramientas necesarias para unificar el acceso a datos remotos. Drivers: Gestionan los distintos tipos de datos soportados por gvSIG. DriverManager: Proporciona la carga y el acceso a los drivers disponibles en la aplicación tanto alfanuméricos como espaciales. WriterManager: Proporciona la carga y el acceso a los writers disponibles en la aplicación tanto alfanuméricos como espaciales. Writers: Permiten las operaciones de escritura sobre los distintos tipos de formatos soportados. VectorialSources: Proporciona acceso a los datos con las geometrías. DataSources: Proporciona acceso a los datos alfanuméricos. RasterSources: Proporciona acceso a los datos de tipo ráster. 39 Figura 12: Subsistema subdrivers Proyecto final de carrera. 2.2 Gdal En el apartado anterior se ha presentado el subsistema de subdrivers encargado, entre otras cosas, de acceder a los datos directamente de la fuente de estos. Dado que este trabajo está centrado en la parte raster de gvSIG aplicada a procesos de teledetección, vamos a presentar más en profundidad las librerías encargadas de acceder a los formatos de datos raster. Aunque gvSIG está programado en lenguaje Java para mejorar su portabilidad entre plataformas, el acceso a los datos raster se realiza mediante librerías nativas. Para la inmensa mayoría de formatos raster, se utiliza la librería gdal, siendo las únicas excepciones los formatos de datos ecw y jpeg2000 (que se accede mediante la librería par a el formato ecw de Ermapper) y MrSid (que se accede mediante la librería mrsid de Lizzardtech). Gdal [GDAL] (Geospatial Data Abstraction Library) es una biblioteca de software para la lectura y escritura de formatos de datos geospaciales, publicada bajo la licencia X/ MIT style Open Source por la fundación geoespacial de código abierto, Open Source Geospatial Foundation (OSGeo). Como biblioteca, presenta un único modelo abstracto de datos al uso que llama para todos los formatos soportados. También viene con una variedad de utilidades en línea de comando para la traducción y el proceso de datos geoespaciales. Como parte de gdal existe la librería OGR que tiene prestaciones similares a las de gdal para datos vectoriales, completando así el soporte para la gran mayoría de datos SIG. Originalmente gdal fue desarrollado íntegramente por Frank Warmerdam hasta la versión 1.3.2, a partir de la cual su desarrollo y mantenimiento fue oficialmente transferido al Comité de Mantenimiento del Proyecto GDAL/OGR dentro de la OSGeo. GDAL/OGR se considera uno de los proyectos de software libre mas importantes incluso dentro de la comunidad de SIG comerciales, debido a su uso tan extendido y a su amplio juego de funcionalidades. 40 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 2.2.1 Acceso a datos raster con gdal en gvSIG Tal y como se ha indicado, gdal da soporte de lectura y escritura para la inmensa mayoría de los formatos raster que soporta gvSIG debido al gran número de formatos que soporta de forma nativa. Dado que gdal trabaja con una misma estructura de datos abstracta para todos los formatos que soporta tiene la posibilidad de añadir ciertos formatos que no se soportan de base. Para esto cuanta con algunos puntos de extensión para algunos formatos en concreto como, por ejemplo, Ecw, MrSid, Hdf4 y Hdf5. Estos dos últimos formatos son los utilizados para la publicación de las imágenes proporcionadas por el sensor MODIS en el servicio Modis Rapid Response System. Mediante la recompilación de los fuentes de gdal se puede activar el soporte para dichos formatos incluyendo las librerías de cada uno de ellos e indicando a gdal su ruta para tenerlas en cuanta en la compilación. Esta estrategia es la que se ha utilizado en el presente proyecto para dotar a gvSIG de soporte para las imágenes obtenidas con el sensor MODIS, en la parte de la lectura de los datos desde su fuente por parte de las librerías nativas. La segunda parte de este desarrollo trata de dotar a gvSIG de un driver que sea capaz de comprender y gestionar las particularidades del formato. Dado que gdal está escrito en lenguaje nativo (C, C++), se ha tenido que desarrollar un recubrimiento del api proporcionado por la librería. Para esto se ha utilizado la librería de Java “Java Native Interdace” (JNI). La librería JNI se utiliza para escribir métodos en lenguaje nativo que pueden utilizar objetos de Java, de la misma forma que java es capaz de utilizar los objetos proporcionados por JNI. Dentro del apartado de desarrollo se extenderá la utilización de esta librería para comprender mejor su funcionamiento. Al compilar este recubrimiento se generan dos archivos como librerías del wrapper de gdal para su uso en Java: jgda.jar (librería con las clases Java que proporcionan el interfaz con la librería nativa) y jgdal.dll / jgdal.so (librería nativa con el recubrimiento de gdal). 41 Proyecto final de carrera. ✔Cambio de datum puro: Transformación de un sistema S1a otro S2 donde únicamente difiere el datum: Por ejemplo de UTM 31N-WGS84 a UTM 31NED50. ✔Cambio de elipsoide: Transformación de un sistema de referencia S1 a otro S2 donde únicamente difieren en el elipsoide de referencia, incluido un cambio de modelo elipsoidal a esférico o viceversa. Por ejemplo latitud/longitud ED50 con modelo elipsoidal International 1924 a latitud/longitud ED50 con modelo esférico Normal Sphere of radius 6370997. ✔Cambio de parámetros de datum: Caso singular del cambio de datum donde los datum origen y destino son coincidentes pero los parámetros que se aplican son distintos. Transformaciones combinadas: Cualquier combinación de 2 o más de los anteriores cambios elementales. Por ejemplo la transformación de UTM 31NED50 a Lambert Cónica Conforme ZonaIII-NTF correspondería a un cambio combinado de proyección (y por extensión parámetros de proyección) de UTM a Lambert Cónica Conforme y de datum (y por extensión de parámetros del datum) de ED50 a NTF y sus correspondientes elipsoides asociados, de Hayford y Clarke respectivamente. 2.4 Sensores MODIS MODIS (Moderate Resolution Imaging Spectroradiometer) es un sensor montado abordo de los satélites de la NASA “Terra (EOS AM)” y “Aqua (eso PM)”. La órbita de Terra alrededor de la tierra está programada para que recorra la tierra de norte a sur a través del ecuador durante la maña, mientras que Aqua la recorre de sur a norte a través del ecuador durante la tarde. De esta forma, los sensores MODIS equipados en Terra y Aqua recorren la superficie completa de la tierra cada 1 o 2 días, adquiriendo datos en 36 bandas espectrales o grupos de longitud de onda. Estos datos contribuyen a mejorar el conocimiento de los procesos globales que ocurren en tierra, mares y océanos y en la atmósfera baja. MODIS juega un papel vital en el desarrollo de modelos globales e 48 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. interactivos de la Tierra capaces de predecir cambios sobre la misma que ayuden a la toma de decisiones de las administraciones para la protección del medio ambiente [MOD]. Los sensores MODIS aportan alta sensibilidad radiométrica en 36 bandas espectrales en el rango de longitudes de onda de 0.4 µm hasta 14.4 µm. De los 36 canales, 2 tienen una resolución 250 metros por píxel, 5 tienen 500 metros píxel y el resto con 1 kilómetro por píxel. Los siete primeros canales, los de más resolución, están orientados al estudio del suelo, los nueve siguientes al estudio del océano y el resto a estudios atmosféricos, aunque lógicamente hay una gran interrelación entre todos ellos. Con la información obtenida de los sensores MODIS, que recorre el espectro de frecuencias, es posible confeccionar modelos digitales de diferentes temáticas así como ofrecer los datos en bruto para su posterior tratamiento. De esta forma, MODIS ofrece un gran número de productos que dan respuesta a la necesidad de información en tiempo real para la toma de decisiones en diferentes ámbitos. En el caso que nos ocupa, estamos estudiando los recursos hídricos de una zona en concreto. La cantidad y calidad de los recursos hídricos se hace patente de forma directa en la vegetación de la zona con lo que un modelo digital raster que represente algún índice de vegetación muestra claramente el estado de la zona en este aspecto. Se estudiarán con mayor detenimiento los índices de vegetación y otros conceptos en el siguiente apartado, dedicado de forma íntegra a la teledetección. MODIS ofrece imágenes con índices de vegetación ya calculados a partir de las bandas correspondientes tomadas con el sensor. Dada su resolución espacial (250 metros/píxel) y su resolución temporal (1 imagen quincenal), los modelos proporcionados por este servicio referentes a índices de vegetación (en concreto NDVI, ver apartado siguiente), lo suficientes para el proceso de monitorización que nos ocupa, siendo la fuente de datos que se va a utilizar en el presente proyecto. Todas las imágenes producidas de esta forma y el resto de imágenes generadas se ofrecen a los usuarios utilizando diferentes servicios. A continuación se listan algunos servicios importantes que ofrecen imágenes obtenidas de los sensores MODIS: 49 Proyecto final de carrera. Modis Rapid Response System: Servicio desarrollado para ofrecer diariamente imágenes de las masas continentales con una periodicidad cercana al tiempo real. Imágenes en color real y falso están disponibles algunas horas después de que hayan sido tomadas, haciendo al sistema un recurso valioso para diversas organizaciones como comunidades de monitorización de fuegos, que utilizan estas imágenes para detectar fuegos o departamentos de agricultura, que las usan para controlar las condiciones de crecimiento de los cultivos. Land Processes Distributed Active Archive Center (LP DAAC): Componente del sistema de observación de la Tierra de la NASA (Earth Observing System, EOS). Está destinado a procesar, archivar y destribuir datos terrestres y productos derivados de los sensores EOS (como por ejemplo, sensores MODIS). Maneja datos provenientes de tres instrumentos EOS abordo de dos satélites operativos: ASTER y MODIS abordo del satélite Terra y MODIS abordo del satélite Aqua. Los datos ASTER son recibidos, procesados, distribuidos y archivados mientras los productos MODIS solo se reciben, archivan y distribuyen. LP DAAC ofrece una amplia gama de productos en la cual podemos encontrar coverturas referentes a índices de vegetación en los cuales encontramos conjuntos de datasets relacionados. A partir de este servicio de distribución de imágenes, se toman los datos MODIS necesarios para este proyecto. En nuestro caso, el producto MOD13Q1 del servicio LP DAAC nos ofrece un juego de imágenes de índices de vegetación con una resolución de 250 m/píxel y una periodicidad de un archivo cada 16 días. El formato en el que se distribuyen estos juegos de datos es el Hierarchical Data Format (HDF) que permite almacenar varios juegos de datos (imágenes) dentro de un mismo archivo. De esta forma, la tabla de la siguiente figura muestra la lista de juegos de datos de un archivo correspondiente al producto MOD13Q1 en la que aparecen la descripción del dataset, las unidades, el tipo de píxel, el rango de valores y el factor de escala. Estos concepto se explicarán en la siguiente 50 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. sección dedicada íntegramente al formato HDF [LPDAAC]. Tal y como se puede observar en la tabla, hay un parámetro que corresponde con el factor de escala y que se puede consultar como metadato dentro de cada uno de los subdatasets. El soporte desarrollado por gdal reconoce y lee esta dato. Las imágenes vienen multiplicadas por un factor de escala como medida para ahorrar espacio en las imágenes. Muchos índices de vegetación tienen valores decimales, por lo que el tipo de dato de cada píxel tendría que ser decimal. Al multiplicar por un factor de escala este valor, tenemos valores enteros para cada uno de los píxeles que se pueden codificar como bytes, ocupando una menos cantidad de espacio. Este dato se tiene que tener en cuenta a la hora de desarrollar el driver encargado de abrir las imágenes en gvSIG. 51 Figura 15: Información de los datasets de MOD13Q1 Proyecto final de carrera. 2.4.1 Hierarchical Data Format (HDF) Tal y como se ha indicado en la sección anterior, lo productos derivados de los sensores MODIS que distribuye LP DAAC vienen codificados en formato HDF (Hierarchical Data Format). Realmente HDF no es un formato raster sino un formato contenedor. HDF (HDF, HDF4 o HDF5) es el nombre de un conjunto de formatos de fichero y librerías diseñadas para almacenar y organizar grandes conjuntos de datos numéricos. Fue originalmente desarrollado por el NCSA (National Center for Supercomputing Applications) y actualmente le da soporte el HDF Group, un grupo no lucrativo. El objetivo del HDF Group es asegurar la continuidad de desarrollo de tecnologías HDF5 y el acceso a los datos actualmente almacenados en HDF. El formato HDF, así como sus librerías y herramientas, están disponibles libremente para su uso general. Actualmente están en uso dos versiones distintas del formato: HDF4 y HDF5. Existe API para muchos de los lenguajes de programación más importantes como C, C++ y Java. En nuestro caso, cada uno de los productos proporcionados por el servicio LP DAAC se descarga como un fichero HDF. Gdal es capaz de leer este fichero para obtener el número de datasets que contiene así como su nombre. Cada uno de estos datasets corresponde a una imagen con una temática determinada a la cual, gdal puede acceder de forma individual. Dado el formato elegido para distribuir las imágenes MODIS, se ha hecho necesario implementar un driver que permita obtener los nombres de los subdatasets de cada uno de los archivos y acceder a cada imagen a petición del usuario. En conjunto, como entradas para el proceso de monitorización de recursos hídricos, necesitamos tomar como datos de partida modelos digitales del índice de vegetación NDVI. Para esto, el servicio LP DAAC ofrece, entre otros, el producto MOD13Q1 para cada una de las regiones terrestres de la Tierra, en el cual encontramos, como su primer dataset, el índice de vegetación NDVI para la región seleccionada. Estos datos vienen en formato HDF por lo que es necesario habilitar su soporte dentro de gvSIG para poder trabajar con estos datos. 52 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 2.5 Teledetección La teledetección o percepción remota [WIK] es una disciplina científica que integra un amplio conjunto de conocimientos y tecnologías utilizadas para la observación, el análisis y la interpretación de fenómenos terrestres y planetarios. Como su nombre indica, la teledetección es la técnica que permite obtener información sobre un objeto, superficie o fenómeno a través del análisis de los datos adquiridos por un instrumento que no está en contacto con él. Se basa en que cada objeto, área o fenómeno emite un espectro electromagnético específico, en función de su propia naturaleza y de las radiaciones que recibe. La reflectancia de ese espectro electromagnético se denomina firma espectral, la cual hace distinguible a ese objeto, superficie o fenómeno de los demás. Por lo general los datos son recogidos a través de sensores instalados en plataformas aerotransportadas o en satélites artificiales, los cuales captan la radiancia emitida o reflejada, obteniéndose una imagen, habitualmente en falso color con una banda para cada una de estas regiones del espectro. Los avances en tecnología han permitido contar con instrumentos cada vez más precisos basados en electrónica y experimentación con materiales que permiten obtener información cada vez más completa contenida en imágenes satelitales. La adquisición de información a distancia implica la existencia de un flujo de información entre el objeto observado y el captador. El portador de esta información es la radiación electromagnética, esta puede ser emitida por el objeto o proceder de otro cuerpo y haber sido reflejada por este. Todos los cuerpos (planetas, seres vivos, objetos inanimados) emiten radiación electromagnética; la cantidad y tipo de esta radiación emitida depende fundamentalmente de su temperatura. El principal emisor de radiación en el sistema solar es el propio Sol cuya radiación, reflejada por la Tierra y los objetos situados en ella, es la más comúnmente utilizada en teledetección y es la que nos permite ver los objetos situados a nuestro alrededor. Otra opción es que el sistema captador incorpore un emisor de radiación 53 Proyecto final de carrera. (Radar) cuyo reflejo en la superficie del planeta objeto de estudio lo recoge el propio captador. El objetivo fundamental de la teledetección es el de analizar las características de la radiación que abandona la superficie terrestre, y que es captada posteriormente por un sensor situado en un satélite. El análisis de estos datos, permite determinar qué elementos y factores ambientales las han producido. Historia de la teledetección La historia de la teledetección se remonta a las primeras plataformas de observación aérea: los globos aerostáticos y a la invención de la fotografía en el siglo XIX. La teledetección moderna, nace con la fotografía aérea en el siglo XX. El año que simboliza la entrada de la teledetección en la era moderna es 1957 con el lanzamiento del satélite Sputnik, primer satélite artificial puesto en órbita alrededor de la Tierra por la Unión Soviética. Los resultados obtenidos en el estudio de recursos naturales terrestres con los datos de los primeros satélites meteorológicos y las misiones espaciales tripuladas, impulsaron el desarrollo por la NASA del programa ERTS (Earth Resources Technological Satellite) conocido también como LANDSAT. A partir de los datos suministrados por los LANDSAT, son numerosos los países que han decidido disponer de medios propios de teledetección. Entre estos destacan los satélites SPOT francés, RADARSAT canadiense, el MOS de Japón, el IRS de la India y el ERS de la Agencia Espacial Europea. Actualmente, hay permanentemente en órbita decenas de satélites de observación de la Tierra que generan miles de imágenes cada día para aplicaciones de uso civil y militar. 54 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 2.5.1 Proceso de teledetección El principio de base de la teledetección es similar al de la visión. La teledetección es el resultado de la interacción entre tres elementos fundamentales: una fuente de energía, un objetivo o escena y un captador o sensor [UM]. La fuente de energía es la que "ilumina" el objetivo emitiendo una onda electromagnética (flujo de fotones). También es posible medir el calor que se desprende de la superficie del objetivo (infrarrojo térmico). En este caso el propio objetivo es la fuente de energía (aunque se trata de energía solar almacenada y reemitida). El objetivo o escena es la porción de la superficie terrestre observada por el satélite. Su dimensión varia, en función de la resolución del captador, de unos pocos km² a algunos miles de km². El captador o sensor de teledetección mide la energía solar (es decir la radiación electromagnética) reflejada por el objetivo. El captador puede encontrarse en un satélite o en un avión, sobrevolando el objetivo a una altura de pocos centenares de metros hasta distancias de 36.000 kilómetros en el caso de los satélites meteorológicos. Los captadores embarcados en los satélites miden la radiación electromagnética reflejada y posteriormente reenvían esta información a la Tierra mediante un emisor. En la Tierra una red de estaciones de recepción se encarga de recibir y almacenar estos datos. Cuando la fuente de energía es el Sol, y el captador solo mide la radiación reflejada, se conoce como teledetección pasiva. Esta modalidad de teledetección solo es operativa durante las horas diurnas. Por la noche o cuando hay nubes que se interponen no es posible realizar observaciones. La observación de las regiones tropicales no es fácil con esta modalidad de teledetección, a causa de la frecuente presencia de densas coberturas de nubes en estas zonas. Asimismo son difíciles de observar las regiones polares durante los periodos invernales, debido a la reducida iluminación solar que reciben. 55 Proyecto final de carrera. En los casos que el mismo satélite lleva una fuente emisora de energía (radar) que envía hacia el objetivo y mide el eco producido se le denomina teledetección activa. El radar atraviesa la cobertura de nubes lo que facilita la obtención de imágenes independientemente de las condiciones meteorológicas, tanto de día como de noche. Aunque las imágenes de radar son más difíciles de analizar, complementan los datos de la teledetección pasiva y ofrecen información adicional sobre otros aspectos como la topografía del terreno. La teledetección puede hacerse a distintas alturas y mediante diferentes 56 Figura 16: Esquema de teledetección pasiva Figura 17: Esquema de teledetección activa Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. plataformas como se aprecia en la figura adjunta. El área de la superficie terrestre escaneada, está en función de la altura de exploración. Cuanto más lejos esté el sistema de teledetección, mayor será la superficie cubierta, de forma inversa, cuanto más cerca estemos de la superficie menor será el área analizada. En la figura adjunta se muestran los tres niveles en que se clasifican las plataformas de teledetección: Nivel I: Agrupa los instrumentos que operan desde el nivel del suelo hasta los aviones de gran altitud. Nivel II: Incluye los dispositivos ubicados en ingenios de órbita baja (Transbordador espacial, estación orbital) hasta los satélites de observación de órbitas polares hasta 1000 km) Nivel III: Son los satélites de observación meteorológica situados en órbita geoestacionaria a casi 36.000 Km de la Tierra. 57 Figura 18: Alturas y plataformas de teledetección Proyecto final de carrera. Tal y como se ha indicado antes, este modelo supone conocer perfectamente los requisitos del sistema, ya que errores en una fase superior se arrastran hasta las inferiores. Esto ocasiona que los errores detectados durante las últimas fases del ciclo estén ocasionados por equivocaciones en las fases de definición, análisis o diseño, suponiendo un gran esfuerzo de rediseño e implementación para su subsanación. Sin embargo, el modelo cascada en algunas de sus variantes es uno de los actualmente más utilizados, por su eficacia y simplicidad, pero nunca (o muy rara vez) se lo usa en su forma pura. En lugar de ello, siempre se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida. Esto da oportunidad al desarrollo de productos software en los cuales hay ciertas incertezas, cambios o evoluciones durante el ciclo de vida. Así por ejemplo, una vez capturados y especificados los requisitos (primera etapa) se puede pasar al diseño del sistema, pero durante esta última fase lo más probable es que se deban realizar ajustes en los requisitos (aunque sean mínimos), ya sea por fallos detectados, ambigüedades o bien por que los propios requisitos han cambiado o evolucionado; con lo cual se debe retornar a la primera o previa etapa, hacer los pertinentes reajustes y luego continuar nuevamente con el diseño; esto último se conoce como realimentación. Lo normal en el modelo cascada será entonces la aplicación del mismo con sus etapas realimentadas de alguna forma, permitiendo retroceder de una a la anterior (e incluso poder saltar a varias anteriores) si es requerido. 64 Figura 22: Modelo en cascada con realimentación Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. A continuación se describe brevemente cada una de las fases del ciclo de vida en cascada utilizado para el desarrollo del proyecto: Definición de requisitos: Es la fase dedicada a consensuar con el cliente los requisitos exactos de la funcionalidad mediante reuniones entre cliente y jefe de proyecto. A raíz de estas reuniones, se redacta el análisis funcional en el que se describen, sin entrar en detalles técnicos, las diferentes partes del sistema y su funcionamiento desde el punto de vista del usuario. De la misma forma, a partir de esta fase se va a planificar el proceso de desarrollo de la aplicación y se va a presupuestar la misma realizando una planificación temporal de su desarrollo. Es muy importante aclarar todos los requisitos de la aplicación y su funcionamiento exacto ya que, nuevos requisitos en fases avanzadas de desarrollo pueden suponer mayor coste y pueden peligrar la rentabilidad del proyecto al no estar contemplados en la planificación temporal del desarrollo. Fase de análisis: Esta fase consiste en redactar documentación que describa el funcionamiento preciso de la aplicación. También se encarga de identificar los diferentes subsistemas de la aplicación y la relación entre ellos sin entrar en excesivo detalle. A partir de la documentación del análisis funcional se aborda la fase de diseño, definiendo la arquitectura interna de cada uno de los subsistemas definidos. Fase de diseño: Se genera toda la arquitectura de la aplicación. Se toma cada uno de los subsistemas definidos en la fase de análisis como un único sistema que ofrece un API, toma unas entradas y devuelve unas salida. A partir de la definición de estos componentes, se diseña la arquitectura interna en detalle con la que se pasará a desarrollar la aplicación. Fase de desarrollo: Fase correspondiente a la implementación del todo el código de la aplicación así como los test unitarios que tendrá que superar. Fase de test: Una vez desarrollado toda la aplicación y superados todos los test unitarios diseñados, comienza la fase de test por usuarios reales. En el caso de Iver, se cuenta con varios cartógrafos especializados en testing de herramientas 65 Proyecto final de carrera. SIG, especialmente de gvSIG, ya que forman parte del su equipo de desarrollo y han testeado cada una de las versiones que han ido apareciendo hasta la fecha. En esta fase se realiza un trabajo tester – programador, para conseguir estabilidad y funcionalidad de la herramienta. Operación y mantenimiento: Momento en el que la herramienta desarrollada pasa a producción. Dado que el uso habitual de las aplicaciones puede conllevar situaciones no contempladas durante el proceso de testing, es posible que aparezcan nuevos problemas por lo que se presta un periodo de mantenimiento de la aplicación durante el cual existe el compromiso de hacerse cargo de los posibles problemas que se puedan presentar. 3.2 Especificación de requisitos y estimación temporal Una vez adjudicado el proyecto, comienza un periodo durante el cual se mantuvieron varias reuniones con el cliente para establecer los requisitos precisos de la aplicación. Dado que el personal de la CHG se encuentra situado en la ciudad de Sevilla, estas conversaciones se mantuvieron por medio telefónico y por documentos escritos vía correo electrónico. La herramienta, tal y como se ha indicado en diferentes puntos de esta memoria, persigue la posibilidad de monitorizar, en tiempo real, los recursos hídricos de la cuenca del Guadalquivir. Con este fin, la CHG ya cuenta con una serie de procesos de medición y análisis de los datos, pero no cuenta con un sistema integrado con el que realizar todo el proceso. Aprovechando el carácter libre de gvSIG, se diseña un sistema que cubre todas las fases de ducho proceso. La idea central de la herramienta la de poder generar índices de vegetación que tengan en cuenta el tiempo como un parámetro más. A partir de series temporales de NDVI, se generan nuevos modelos digitales correspondientes a nuevos índices de vegetación. Es necesario poder operar libremente con cada una de las capas que se han añadido al sistema para poder conseguir nuevos datos. Por último, es necesario analizar los datos obtenidos a partir del cálculo con las series temporales cargadas en el sistema. 66 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Con este fin, se diseñan procesos de análisis estadístico de los resultados para poder redactar informes que ayuden a la toma de decisiones. Un ejemplo claro del uso de esta herramienta se podría explicar como sigue. La CHG obtiene, mediante las estaciones de medición diseminadas por todo el territorio que rige, modelos digitales de las precipitaciones ocurridas para un periodo temporal concreto. Por otro lado, con la herramienta a diseñar, será posible obtener un modelo digital del gradiente de NDVI para el mismo territorio y el mismo periodo temporal. Mediante la comparación de ambas capas es posible controlar el riego en cada una de las parcelas. Está claro que si durante un periodo no se han producido precipitaciones en una zona y el índice de vegetación para dicha zona a aumentado, se ha producido riego. Analizando las diferencias entre estos parámetros se puede monitorizar el uso de los recursos de la cuenca del Guadalquivir para la agricultura y detectar posibles usos indebidos. A continuación se describen cada uno de los requisitos de la aplicación de forma breve: Soporte para imágenes MODIS: Tal y como se ha indicado antes, LP DAAC ofrece, con una periodicidad temporal de 16 días, imágenes NDVI para toda la cobertura de la superficie terrestre, con una resolución de 250 metros por píxel. Estos datos se obtienen a partir de los recogidos por los sensores MODIS abordo de los satélites Terra y Aqua. Esta información se distribuye en formato HDF que actualmente no es soportado por gvSIG, es necesario implementar el soporte para este formato y además, dar la posibilidad al usuario de seleccionar los subdatasets necesarios dentro de cada fichero hdf. Reproyección de capas raster: Dado que los raster distribuidos por LP DAAC no están en la proyección ED50, uso 30, que es la utilizada en los proyectos de la CHG, sino que están en una proyección sinusoidal, es necesario implementar una herramienta de reproyección para capas raster. GvSIG no disponía, en el momento del desarrollo de este proyecto (la versión estable era la 1.1.2) de reproyección raster, por lo que se tuvo que desarrollar a propósito de este proyecto. La herramienta de reproyección generada ha servido como base para 67 Proyecto final de carrera. la que se ha desarrollado para la versión estable de gvSIG 1.9. Herramienta para el cálculo de índices de vegetación: A partir de series temporales de índices NDVI, se pide generar imágenes correspondientes a los índices ΣNDVI, VCI y coeficiente de variación. Se tiene que poder generar para toda la imagen o para un área determinada. El resultado de este cálculo es una nueva imagen con el valor de píxel correspondiente al índice calculado. Generación de datos vectoriales a partir de los datos raster: A partir de una o varias imágenes raster y una capa vectorial, esta herramienta debe cruzarlas y añadir a la tabla alfanumérica de la capa vectorial una serie de columnas que tengan información estadística generada a partir de las capas raster. De forma similar a las herramientas anteriores los cálculos se deben realizar para todos los elementos vectoriales de la capa o sólo para los seleccionados y además, en caso de utilizar una capa de polígonos el usuario debe poder especificar el umbral de solape entre el píxel y el polígono para la realización de los cálculos. Los estadísticos a calcular se podrán especificar en una ventana y deben incluir cuenta, media, mediana, moda, suma, desviación estándar, varianza, rango, mínimo, máximo, índice de Skewness y Kurtosis. Generación de análisis estadístico: Esta herramienta debe permitir la creación de estadísticos a partir de una o varias imágenes satélite especificadas por el usuario. Los estadísticos se podrán realizar para toda la imagen (con o sin máscara) o bien para los elementos de una capa vectorial que determine el usuario. Dicha capa vectorial podrá ser de puntos, líneas o polígonos y en este último caso también se podrá especificar el umbral de solape. Además, si se utiliza la capa vectorial debe poder especificarse un campo categórico de su tabla de atributos para poder realizar los cálculos por grupos. Los resultados numéricos podrán aparecer en una ventana de texto plano que pueda ser exportada a txt o copiada y pegada. Los gráficos deberían ser 68 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. interactivos y estar linkados entre sí y con los datos. Calculadora raster: Tomando como datos varias capas raster y/o valores numéricos, se tiene que desarrollar una calculadora para realizar álgebra entre los diferentes datos, generando en todo caso una nueva capa raster con las operaciones indicadas. Cabe indicar que esta herramienta ya existía en gvSIG en el momento de la realización del proyecto por lo que no ha sido desarrollada por el alumno sino que éste se ha limitado a adaptar la herramienta a la versión 1.1.2 ya que estaba desarrollada para la versión 1.9. Dado que entre las dos versiones hay importantes diferencias en cuanto a la arquitectura de las librerías raster, ha sido necesario un proceso de adaptación. A partir de los requisitos identificados para el proyecto, se han identificado una serie de tareas a realizar en cada uno de ellos. Además, contemplando el tiempo utilizado para las reuniones y para la generación de la documentación de análisis, se ha confeccionado el conjunto de tareas a realizar para la consecución del proyecto. Con esta lista de tareas, se genera una estimación temporal para el desarrollo de la aplicación y, finalmente, en base a esta estimación temporal, se fija el coste económico del proyecto. Lista de tareas identificadas en el proyecto: Planificación ✔Reuniones con el cliente ✔Especificación de requisitos ✔Redacción de planificación temporal Análisis ✔Estudio de alternativas para soporte de MODIS ✔Estudio de alternativas para reproyección raster ✔Identificación de subsistemas ✔Redacción del análisis funcional 69 Proyecto final de carrera. Diseño ✔Arquitectura soporte MODIS ✔Arquitectura reproyección raster ✔Arquitectura cálculo de índices de vegetación ✔Arquitectura generación de valores vectoriales ✔Arquitectura análisis estadístico Implementación ✔Desarrollo de wrappers para soporte de MODIS ✔Desarrollo del driver de MODIS ✔Desarrollo de wrappers para soporte de reproyección ✔Desarrollo de herramienta de reproyección ✔Desarrollo de cálculo de índices de vegetación ✔Desarrollo de calculo de valores vectoriales ✔Desarrollo de análisis estadístico ✔Adaptación de calculadora raster ✔Generación de instalable ✔Generación de documentación A partir de esta lista de tareas se realiza una planificación temporal utilizando un diagrama de Gantt. Un diagrama de Gantt es una herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. Para realizar este diagrama se ha utilizado la herramienta de software libre “Gantt Project”. A continuación se muestra la lista de tareas listadas anteriormente con sus fechas de inicio y finalización aproximadas. 70 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. En la siguiente figura se muestra el diagrama de Gantt que representa el coste temporal para su realización así como las dependencias entre las diferentes tareas a realizar. 71 Figura 23: Lista de tareas con sus fechas aproximadas Proyecto final de carrera. En base a esta estimación temporal, el departamento comercial de la empresa ajustó el precio por hora de trabajo y fijó el coste de desarrollo de la aplicación tal y como se muestra en la figura. Llegados a este punto, han quedado definidos los requisitos que definen a la aplicación a desarrollar mediante sucesivas reuniones con la CHG. Una vez definidas las tareas, estimados los costes temporales para cada una de ellas y traducidos los costes 72 Figura 24: Diagrama de Gantt del proyecto Figura 25: Estimación económica del proyecto Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. temporales en costes económicos, el proyecto queda convenientemente planificado para comenzar a abordarlo. Hay que remarcar la importancia de esta primera fase en el ciclo de desarrollo del proyecto, ya que en gran medida, determina la rentabilidad y viabilidad del mismo además de ser la base a partir de la cual surgen el resto de fases. 73 Proyecto final de carrera. compilaciones con soporte para estos dos formatos, realizar un recubrimiento de cada una de las dos librerías se considera innecesario. Utilizando gdal para abrir los ficheros HDF se consigue utilizar una misma librería para las dos versiones del formato (HDF4 y HDF5). Otra ventaja es poder utilizar el mismo modelo de datos que utiliza gdal para el resto de formatos. De esta forma, los wrappers y los subdrivers en gvSIG son los mismos que ya existen en la actualidad. Como se verá en la fase de implementación, es necesario retocar los drivers introduciendo los métodos necesarios para obtener información relativa a los subdatasets existentes dentro del fichero HDF. Por todo esto, se decide acceder a los datos de los ficheros HDF utilizando la librería gdal con el soporte para HDF activo. Planteando la mejor manera de abrir ficheros HDF dentro de gvSIG, nos encontramos con el problema de que la herramienta de “Añadir capa” de gvSIG ha sido diseñada con la idea de añadir una capa por cada fichero seleccionado. El inconveniente viene cuando un fichero HDF contiene varias imágenes. Al pasarle a gdal la ruta del fichero HDF para que lo abra como si de una imagen se tratase, se incurre en un error ya que el fichero HDF no es una imagen sino un contenedor. Es por esto que no se puede utilizar la pestaña “Archivo” del diálogo “Añadir capa” de gvSIG para utilizar archivos HDF. Es necesario crear otro punto en el diálogo “Añadir capa” que soporte las particularidades del formato. El diseño de dicho diálogo permite que sea extensible para 80 Figura 28: Se observa como se pretende añadir una capa por cada fichero seleccionado Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. añadir nuevas pestañas. Esta particularidad se a aprovechado para crear una nueva pestaña exclusiva para ficheros HDF correspondientes a imágenes MODIS. En el panel se permite al usuario, utilizando los botones correspondientes de añadir y eliminar, añadir tantos archivos HDF como desee, mostrándose éstos en una ventana con una estructura en forma de árbol (1). Dentro de esta estructura, aparece el nombre del fichero HDF como una carpeta (recordemos que los HDF pueden ser simples contenedores) que contiene como hijos una serie de datasets (que son las verdaderas imágenes). También puede ser que el fichero HDF no contenga varios subdatasets y sea directamente la imágen. En este caso aparecería, en el primer nivel de profundidad, el nombre del fichero como un nodo hoja, sin subdatasets colgando de él. Una vez añadidos los archivos deseados, el usuario tiene que seleccionar, haciendo doble click sobre ellos, los subdatasets que desea añadir a la vista. Estos subdatasets se añadirán a una lista en la parte inferior del diálogo (2). De igual manera, se pueden quitar de dicha lista haciendo doble click sobre su nombre dentro de la lista. Finalmente, cuando se confirma la operación, se añaden a la vista la totalidad de los subdatasets seleccionados por el usuario, generándose una capa en la vista de gvSIG por subdataset. 81 Figura 29: Panel para añadir imágenes en formato HDF. Proyecto final de carrera. Cabe indicar que, en algunos casos, las imágenes vienen multiplicadas por algún factor de escala. Esto se hacer para hacer pasar números decimales por enteros y así poder codificar las imágenes en formato byte y así ahorrar memoria. En el momento en que se cargan estas imágenes, se lee de sus metadatos si vienen multiplicadas por algún factor de escala y, si es el caso, se divide para que los píxeles tomen su valor real. Esto ocurre de forma transparente para el usuario. 4.2.2 Reproyección de capas raster De nuevo, a la hora de abordar la manera de realizar reproyecciones en capas raster, surgen dos alternativas que cabe estudiar. La primera posibilidad es realizar la conversión de coordenadas usando la librería proj4 (que ofrece tal servicio). En este caso, la parte del warp (transformaciones a realizar en la imagen para que tenga la forma apropiada en su nueva localización) se tendría que programar directamente en la parte de Java. Utilizar la herramienta facilitada por la librería gdal para realizar reproyecciones a archivos raster, gdalwarp. Dada una imagen georeferenciada con una proyección conocida por gdal, gdalwarp reproyecta y transforma la imagen al nuevo sistema de coordenadas. Nuevamente, por razones de sencillez, se decide utilizar la herramienta brindada por gdal para realizar las reproyecciones de capas raster. En la sección de implementación, se mostrará como se ha realizado el recubrimiento de esta herramienta. Dentro de gvSIG, se ha ideado una herramienta lo más sencilla posible para poder trabajar con imágenes de distinta procedencia usando la misma proyección en cada una de ellas. Cuando se crea una vista nueva en gvSIG, se elige una proyección para ésta que es la misma proyección en que deberían estar todas las capas que se van a utilizar en dicha vista. La actual herramienta de reproyección de capas raster solo va a permitir 82 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. reproyectar capas raster, georeferenciadas y con proyección soportada por gdal, a la proyección en que se encuentra la vista. Como se puede observar, no se está generando una herramienta avanzada de reproyección con numerosas opciones. Simplemente, se da la posibilidad de cambiar la proyección de una manera rápida y sencilla. El punto de extensión de la funcionalidad de reproyección se sitúa dentro del menú contextual del TOC de la vista de gvSIG, aprovechando el punto de extensión del mismo. De esta forma, al pulsar el botón derecho del ratón en una capa raster susceptible a ser reproyectada, aparece activa la opción de reproyectar. Una vez seleccionada la opción de reproyección, se abrirá un diálogo en el que se pide al usuario que seleccione la ruta del archivo que se creará con la reporyección. También se le informa del tipo de transformación que se va a realizar. 83 Figura 30: Opción de reproyección en el menú contextual Figura 31: Diálogo de reproyección raster Proyecto final de carrera. Una vez aceptada y realizada la operación se habrá creado una fichero en formato tiff en la ruta especificada. De igual forma, se añadirá a la vista una nueva capa con el nombre indicado correspondiente a la reproyección de la capa seleccionada. En caso de que la reproyección no sea posible o no sea necesaria por coincidir la proyección de la capa con la de la vista, la herramienta lo indica, no realizando la operación. 4.2.3 Cálculo de índices de vegetación a partir de series temporales La herramienta de cálculo de índices de vegetación a partir de series temporales de imágenes NDVI se divide en 3 partes de idéntico funcionamiento. Es por esto que se va a proponer un funcionamiento que se extenderá a los 3 índices de vegetación que se necesita calcular. Se pretende calcular, para una serie de imágenes, los índices de vegetación ΣNDVI, VCI y coeficiente de variación. El cálculo de estos índices ya se ha explicado con anterioridad en este mismo documento. La mecánica de la funcionalidad va a ser la misma independientemente del cálculo que se valla a realizar que depende del índice seleccionado. Con una serie temporal de imágenes NDVI cargada en la vista activa de gvSIG, se 84 Figura 32: La aplicación informa de que no se realizará la operación Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. selecciona la herramienta de cálculo de índices de vegetación correspondiente al índice deseado. Los accesos a estas herramientas se encuentran en la barra de herramientas de gvSIG. La herramienta le da la posibilidad al usuario de elegir un conjunto de bandas que pueden pertenecer a cualquiera de las capas raster que están cargadas en la vista. Una vez seleccionadas, la aplicación pasa a calcular el índice deseado. Se recorre el raster celda a celda. Para cada coordenada píxel x,y, se realiza el cálculo correspondiente tomando como datos los píxeles de todas las bandas seleccionadas en esas coordenadas x,y. De esta forma, para calcular ΣNDVI, para cada x,y de la imagen, el resultado es la suma de los píxeles en esa coordenada para todas las imágenes seleccionadas para el proceso. Así se genera una nueva capa raster que se guarda en una carpeta temporal, correspondiente al índice seleccionado. En esta primera parte de la herramienta, solo se genera una capa raster a partir de un conjunto de capas raster NDVI. A continuación se indica el cálculo que se realiza tomando como datos los valores de NDVI para la coordenada dada, en cada uno de los índices que se pueden calcular. ΣNDVI: Se suma el valor de los píxeles de todas las imágenes seleccionadas para la coordenada dada: cteyxxyNDVINDVIxy t==∑∑ ∀, VCI: Se aplica la siguiente fórmula: cteyx inNDVaxNDV inNDVNDVI VCI xyxy xyxy xy = − − =, )ImIm( )Im( *100 Los valores máximos y mínimos se toman del conjunto de píxeles de la serie de imágenes para la coordenada dada. El valor NDVI(x,y) corresponde al valor del píxel en las coordenadas dadas, de una imagen seleccionada como pivote. Coeficiente de variación: Supone el cociente de la desviación típica entre la media aritmética. Estos valores, como en los casos anteriores, se calculan a partir del conjunto de píxeles con coordenadas x,y de cada una de las imágenes. 85 Proyecto final de carrera. Para poder seleccionar una capa pivote en el cálculo del índice VCI, en el panel de selección de capas correspondiente a este índice, se añade un menú desplegable (ComboBox) en el cual se puede elegir cuál será la capa pivote. Para los otros dos índices no se incluye es este menú. La siguiente figura corresponde con el panel de selección de capas para el índice VCI. Nótese que el menú de la parte inferior no aparecerá en los paneles homólogos para los otros índices. Otro requisito de esta herramienta es poder enmascarar, utilizando geometrías, la capa raster resultante, obteniendo un valor medio para todas las zonas enmascaradas. Es posible utilizar como máscara las geometrías de una capa vectorial previamente cargada en la vista o digitalizar con herramientas de edición (CAD) las áreas de interés. En ambos casos se calcula, a partir de la capa obtenida (es decir una capa ΣNDVI, VCI o coeficiente de variación) la media aritmética de todos los píxeles que estén dentro de las zonas delimitadas por las geometrías seleccionadas. La diferencia viene dada por la manera de almacenar este valor. Se dan dos supuestos: 86 Figura 33: Selección de bandas para el cálculo de VCI Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Se enmascara el cálculo con una capa vectorial: Se puede seleccionar si la máscara la conformarán todas las geometrías de la capa o solo las que están seleccionadas. En ambos casos, se calcula la media para cada una de las geometrías y se añade una columna a la tabla de la capa vectorial con el valor calculado. Para consultar este valor, vasta con ver la tabla de la capa vectorial. Se habrá creado un campo con la media (por ejemplo “Media VCI”) con el valor calculado. Se digitalizan geometrías usando herramientas de edición: Se realiza un cálculo de la media de los píxeles de la imagen obtenida en las zonas indicadas por todas las geometrías digitalizadas. Al final del cálculo, se muestra por pantalla esta valor. Se puede copiar y pegar en otro documento. En el caso de que la máscara esté formada por geometrías de tipo polígono, se tiene que considerar un porcentaje umbral de solape. Con este porcentaje (que puede introducir el usuario) se indica la cantidad de píxel que tiene que estar dentro del polígono (en los píxeles que coincidan con el borde del polígono) para que pase a formar parte del cálculo. Figura 34: Solape de un píxel con el extremo de un polígono Este nivel de precisión es necesario ya que hay parcelas de riego pequeñas que pueden ocupar muy pocos píxeles y que uno en concreto entre a formar parte del cálculo o no, es importante. 87 Proyecto final de carrera. 4.2.4 Generación de datos vectoriales a partir de datos raster El objetivo de esta herramienta es añadir datos numéricos a la tabla de una capa vectorial seleccionada previamente. De la misma forma que en la herramienta anterior, partimos de un conjunto de capas raster y una capa vectorial. Las geometrías de esta capa vectorial van a funcionar como máscara para el cálculo de estadísticas con los píxeles de las capas raster. De esta forma, se selecciona un conjunto de las capas raster cargadas en la vista. También se selecciona (en el ComboBox que lo indica) una capa vectorial de las que están cargadas en la vista. Para cada una de las geometrías de la capa vectorial, se calculan datos estadísticos con los píxeles de todas las capas seleccionadas para el cálculo, que estén dentro de dicha geometría. Una vez calculados estos valores, en caso de que no existan, se crean los campos en la tabla de la capa vectorial correspondientes a cada uno de los estadísticos calculados. Para cada geometría, se ponen los valores estadísticos calculados en el lugar correspondiente de la tabla. Al igual que con las herramientas de cálculo de índices de vegetación, para el caso de que la capa vectorial sea de polígonos, se puede introducir un porcentaje a partir del cual el píxel coincidente con el límite del polígono, pasa a formar parte del cálculo. Con esta herramienta es posible crear capas vectoriales con estadísticas de temáticas determinadas para cada una de las zonas delimitadas por sus geometrías. 88 Figura 35: Estadísticos disponibles en la herramienta Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. En la figura se muestran los diferentes estadísticos disponibles. El usuario puede seleccionar los necesarios y estos serán lo que se añadan a la capa vectorial seleccionada. 4.2.5 Análisis estadístico Esta herramienta está ideada para disponer de datos finales que muestren de forma cualitativa y cuantitativa el estado de los recursos de la cuenca del Guadalquivir. Los resultados que se buscan son una serie de estadísticos gráficos y numéricos que apoyen a la realización de informes sobre la cuenca y ayuden a la toma de decisiones. A partir de una o varias capas raster especificadas por el usuario de entre las cargadas en el sistema, se tiene que poder calcular una serie de estadísticas, de las cuales el usuario puede seleccionar un subconjunto. Las estadísticas que se tienen que calcular son las siguientes: Estadísticos descriptivos univariantes: Media, mediana, moda, suma, cuartiles, percentiles (especificados por el usuario), desviación típica, varianza, rango, mínimo, máximo, Índice de Skewness e Índice de Kurtosis. Gráficos descriptivos univariantes: Histograma de valores, gráfico BoxWishker y gráfico de barras de errores. Los estadísticos se podrán realizar tomando como población todos los píxeles de la serie de imágenes, o bien enmascarando con una capa vectorial, de igual forma que en las herramientas anteriores. Se podrá especificar si se quieren realizar para todas las geometrías de la capa vectorial o solo para las seleccionadas. También en este apartado se da la posibilidad de establecer un porcentaje umbral de solape a partir del cual el píxel pasa a formar parte del cálculo. En caso de enmascarar con una capa vectorial, se tiene que poder especificar una serie de condiciones con los campos de la tabla de dicha capa vectorial. Las geometrías que cumplan cada una de esas condiciones, pasarán a forma parte de una población. De esta forma se definen diferentes poblaciones que se van a poder comparar 89 Proyecto final de carrera. realizan bajo el mismo entorno. Eclipse [ECL] en un entorno de desarrollo integrado de código abierto para realizar aplicaciones de escritorio en lenguaje Java. Aunque la mayor parte del entorno esté programada en lenguaje Java y su uso más popular sea el de IDE para programación en Java, se puede utilizar para programar en otros lenguajes como C++ o Python mediante un sistema de plugins. Una de las características más importantes de Eclipse es su extensibilidad ya que brinda una serie de puntos de extensión para incorporar nuevos plugins que le doten de nueva funcionalidad. Tanto es así, que la herramienta final es, en realidad, un conjunto formado por un núcleo y un conjunto de extensiones. Eclipse permite organizar los diferentes bloques de una aplicación en diferentes proyectos, cada uno de ellos con sus paquetes de código y sus propiedades. GvSIG tiene divididas en diferentes proyectos las fuentes de cada una de sus librerías y extensiones, siendo posible realizar compilaciones de gvSIG con solo una porción de funcionalidad. 96 Figura 39: Apariencia del entorno de trabajo Eclipse Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 5.1.2 Java Native Interface (JNI) Dado que para manejar los datos raster se van a utilizar librerías escritas en código nativo, es necesario disponer de algún sistema con el cual se pueda acceder a estas librerías desde Java. JNI es un interfaz de programación estándar para escribir métodos nativos en Java y para incluir una máquina virtual de Java dentro de aplicaciones nativas [WIK]. El principal objetivo de JNI es lograr una compatibilidad binaria de las librerías nativas con la máquina virtual en un sistema dado. De esta forma, JNI posibilita la integración de código escrito en Java con código nativo en C o C++ y permite a los programadores aprovechar las ventajas de Java sin tener que desechar librerías nativas previamente desarrolladas. El framework JNI permite a un método nativo utilizar los objetos Java de la misma forma en que el propio código de Java lo hace. Un método nativo puede crear objetos Java; y examinarlos y utilizarlos para que lleven a cabo su función. Un método nativo puede asimismo examinar y utilizar objetos que han sido creados por código de aplicación escrito en Java. JNI no es en absoluto trivial, y aprenderlo requiere de un esfuerzo considerable. En cualquier caso, la posibilidad de comunicar Java con C, C++ o ensamblador, desestima toda limitación en lo que los programas Java pueden hacer. Una de las mayores desventajas de JNI, además de su dificultad, reside en que 97 Figura 40: Equema de la comunicación con JNI Proyecto final de carrera. pequeños errores dentro del código nativo pueden desestabilizar gravemente la aplicación y tumbar la máquina virtual de Java. Por esto es necesario realizar un exhaustivo proceso de captura de errores y predecir todas las situaciones de riesgo. Un pequeño fallo que conlleve sobreescribir posiciones de memoria utilizadas por librerías nativas puede llegar, con cierta frecuencia, a hacer que la máquina virtual se cierre y, por tanto, la aplicación que se está ejecutando en ella. Esto conlleva una perdida de datos no salvados con la aplicación Java. Por último, JNI hace que se pierda una de las características más atractivas de Java: la portabilidad. Dado que el código JNI es código programado en C o C++, es necesario compilarlo para generar las librerías necesarias. Por tanto, el sistema resultante no es completamente independiente del sistema operativa ya que se tendrán que generar ficheros binarios para cada uno. 5.1.3 Entorno de programación de código nativo Los fragmentos de código nativo que se han tenido que programar (algunas funciones para la reproyección raster y código JNI) se han desarrollado utilizando el plugin de Eclipse para C y C++. Como la versión de gdal que se ha utilizado en esta aplicación no es una compilación estándar sino que incorpora las librerías para acceso a ficheros HDF, se ha tenido que compilar a partir de sus fuentes. Para esto se han utilizado los compiladores proporcionados por Linux, gcc y g++. 5.1.4 IzPack IzPack es una solución en software libre para empaquetar, distribuir e instalar aplicaciones. Empaqueta los instalables en archivos .jar por lo que un mismo instalador puede servir para cualquier sistema operativo que tenga una máquina virtual de Java. Las distribuciones de gvSIG se realizan utilizando IzPack. Existe la posibilidad de crear instaladores de la aplicación completa o de crear instaladores parciales para ampliar 98 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. una versión de la herramienta ya instalada. El instalador de este proyecto se generó como una ampliación para una instalación de la versión 1.1.2 de gvSIG. 5.2 Diseño de funcionalidades A fin de contribuir al modelo de desarrollo modular propuesto por gvSIG, se han desarrollado varios proyectos de Eclipse que coinciden con los bloques funcionales más importantes de la aplicación. Aunque existen algunas dependencias entre ellos con el fin de evitar el código duplicado, cada uno de los bloques tiene es, en buena parte, independiente del resto. A continuación se describe brevemente el contenido de cada uno de los proyectos de Eclipse que se ha desarrollado. A continuación, se entrará a presentar en detalla la arquitectura de cada uno de los proyectos. extCHGRaster: Es el proyecto principal de la aplicación en el que se centralizan las modificaciones de las estructuras del núcleo de gvSIG que han sido necesarias a fin de dar soporte a las particularidades del soporte MODIS y la reproyección raster. Además de estas modificaciones contiene los paquetes correspondientes a la 99 Figura 41: Organización de los componentes en proyectos de Eclipse Proyecto final de carrera. capa de acceso a datos y negocio para las herramientas de acceso a imágenes MODIS, reproyección raster y cálculo de índices de vegetación Dado que la herramienta de cálculo de índices de vegetación realiza, seleccionando las opciones correspondientes, la actualización de la tabla de una capa vectorial con valores estadísticos a partir de las capas raster, se utiliza el algoritmo programado con este fin en la extensión extVectorialCut. Es por esto que existe una dependencia con esta extensión. extVectorialCut: Extensión para la herramienta de generación de datos estadísticos a partir de imágenes raster. No depende de ningun proyecto más. extRasterCalculator: Extensión donde ubica la calculadora raster de gvSIG adaptada a la versión 1.1.2. Dado que es una herramienta completamente independiente, no tiene dependencia alguna con el resto de proyectos de la aplicación. extRasterStatistics: En esta extensión se ha desarrollado la herramienta para realizar análisis estadísticos a partir de imágenes raster. Debido a que también tiene en cuenta capas vectoriales para dividir los píxeles en diferentes poblaciones, utiliza algunas clases alojadas dentro de la extensión extVectorialCut. 5.2.1 Soporte MODIS y reproyección Tal y como se ha indicado antes, en este proyecto se van a utilizar nuevas funcionalidades de la librería gdal con el fin de poder dar soporte a las imágenes MODIS y poder utilizar su herramienta de reproyección “gdalWarp” Para esto se han tenido que recubrir nuevas partes de la librería gdal y se han ampliado los subdrivers de gvSIG que acceden directamente a gdal. Primero vamos a mostrar, para cada uno de los dos casos, las nuevas partes de gdal que se están utilizando y que se recubren utilizando JNI. Finalmente se verán los subdrivers de gdal de gvSIG (ya en la parte de Java) y los nuevos métodos que introducen 100 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. en su interfaz para poder trabajar con estas nuevas funcionalidades. Gdal y MODIS Para que la librería gdal tenga soporte para el formato HDF (formato en que se distribuyen las imágenes MODIS, con sus dos versiones: HDF4 y HDF5) es necesario realizar una compilación a partir de su código fuente activando este soporte. La versión estándar de gdal no soporta el formato HDF pero sí que se da la posibilidad de, añadiendo las librerías de HDF correspondientes, activar esta característica. Para esto es necesario realizar una compilación nueva de la librería gdal, indicándole dónde están los binarios de las librerías HDF. En Linux, gdal se compila por linea de comandos utilizando scripts configure para generar los Makefiles necesario. A configure se le pasan parámetros con las características con las que se quiere compilar la librería. En nuestro caso, hay que pasarle el path en el que se encuentran las librerías HDF4 y HDF5. Al ejecutar este script se comprueba que el sistema tenga disponibles todas las herramientas y librerías que son necesarias para el proceso de compilación de gdal. De la misma forma, crea los Makefile necesario y deja apunto el código para su compilación. El siguiente paso es compilar utilizando el Makefile generado de la manera acostumbrada: $> make. Cuando la compilación termina, vemos que se han generado las librerías correspondientes con el soporte para los formatos que utiliza MODIS habilitados. Gdal presenta ciertas funciones para poder acceder a información relativa a los subdatasets que pueda tener un fichero. Esto es indispensable para poder gestionar los ficheros HDF y dado que el recubrimiento para Java que utiliza gvSIG (jgdal) no recubre estos métodos, ha sido necesario implementarlos para este proyecto. El código fuente de los wrappers de gdal desarrollados para gvSIG se encuentra en el SVN del proyecto bajo el nombre de libjni-gdal. Para este proyecto, se creó un 101 Proyecto final de carrera. branch de esta librería a fin de no interferir en las librerías jgdal de la versión estable de gvSIG, con el nombre de libjni-gdal-CHG. La información relativa al nombre y la descripción de los subdatasets de un fichero está contenida en sus metadatos. Gdal divide los metadatos de un fichero en diferentes dominios. De esta forma existe un dominio propio para los subdatasets al que se puede acceder pasándole a la función de gdal “GDALGetMetadata” un string con el nombre del dominio. El problema es que, hasta el momento, gvSIG invocaba a GDALGetMetadata (por medio de JNI) sin pasarle parámetros por lo que se devolvían los metadatos estándar (tamaño, proyección, etc.). Se completó el recubrimiento de esta función para poder pasar dicho parámetro. De esta forma, la librería jgdal ahora dispone de un método para pedir dominios concretos dentro de los metadatos de un fichero. Una vez realizados estos cambios, se compila la librería jdal utilizando el Makefile ya existente en el código e indicando en el mismo la dirección de la librería gdal que tiene que utilizar (la que hemos compilado con soporte para HDF). Esto da como resultado los ficheros jgdal-0.6.2b.jar y libjgdal.so.0.6.2b. Al final de la sección se mostrará como quedan las clases GdalNative y GdalFile (interfaz de gdal con los drivers de gvSIG) con los núevos métodos añadidos para el soporte MODIS y la reproyección. Gdal y reproyección raster Gdal ofrece una serie de herramientas para realizar operaciones sobre ficheros raster entre los que se encuentra la funcionalidad gdalwarp, que reproyecta un fichero raster de su proyección original a una proyección dada. Gdalwarp es una herramienta por linea de comandos y, entre el código de gdal no existe ninguna función para su invocación por código, sino que se compila un fichero .c con un main para generar el ejecutable 102 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. gdalwarp. Para poder utilizar esta funcionalidad desde gvSIG, es necesario incluirla en la librería jgdal y para ello necesitamos una función a la que llamar. Como en el código de gdal, gdalwarp está dentro de un main(), se tuvo que sacar una función a la que poder llamar. El código de esta función se encuentra en el archivo warpfunc.cpp y se invoca desde el recubrimiento con JNI, concretamente desde la función warpDataset dentro del fichero gdalwarp_interfaz.cpp. Finalmente, se modifican las reglas del Makefile dentro del proyecto libjni-gdal-CHG para que se tengan en cuenta estos ficheros y se compila. La cabecera del recubrimiento de la función de reproyección queda como se muestra en la figura. Con esto se preparan las clases necesarias que se incluirán en la librería jgdal-0.6.2b.jar para que se puedan utilizar desde gvSIG. Finalmente es necesario modificar las clases GdalNative y GdalFile de gvSIG con el fin de ampliar el API de estas clases con los nuevos métodos relacionados con gdal. Para comprender mejor el acceso a la librería gdal por parte de gvSIG se presenta el siguiente diagrama de clases. 103 Figura 42: Acceso a datos raster a través de gdal en gvSIG Proyecto final de carrera. La clase CmsRasterDriver es el driver de gvSIG encargado de acceder a los datos raster. Este driver utiliza el modelo de fichero raster en gvSIG que es el GeoRasterFile y éste, a su vez, se divide en un tipo de fichero para cada una de las librerías nativas de acceso a raster que se utilizan en gvSIG. Cada una de estas clases (GdalFile, EcwFile y MrSidFile, utilizan directamente el recubrimiento de las librerías nativas y su interfaz para acceder a los datos. Para el actual proyecto, con el fin de no desestabilizar la versión estable de gvSIG 1.1.2 modificando partes tan internas de su arquitectura, se implementaron dos clases que heredan de GdalNative y GdalFile para poder incluir los nuevos métodos implementados. Utilizando los puntos de extensión de gvSIG, se utilizaron las nuevas clases (GdalNativeReproject y GdalFileReproject) para hacerse cargo de abrir los diferentes tipos de archivo. En la siguiente figura se listan los nuevos métodos que se incluyeron en la clase GdalNativeReproj. 104 Figura 43: Registro de los formatos raster con las nuevas clases Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. Con esto se consigue obtener el nombre y la descripción de los subdatasets de un fichero HDF. En la clase GdalFileReproj se han implementado algunos métodos más a propósito de la reproyección raster. Los métodos getFileProjection() y hasProjection() se utilizan para poder leer la proyección en la que está la imagen desde los metadatos del fichero, en el caso de que se contenga esa información. Esta información es útil para saber cual es la proyección real de la imagen y, por tanto, saber si es necesario reproyectarla. Los métodos relacionados con subdatasets son para obtener información sobre los subdatasets presentes en un fichero. Por último, se implementa un método openHdfFile() que es capaz de abrir un fichero HDF solo para consultar sus subdatasets, dado que el método utilizado por GeoRasterFile para abrir un fichero, directamente intenta cargarlo con gdal como si fuera una imagen y, en los casos en que un HDF contiene varios subdatasets, aparece un error en la librería. 5.2.2 Añadir capas MODIS Hemos visto que el formato HDF tiene ciertas particularidades por las que no se puede cargar de el mismo modo que el resto de formatos raster. Dado que el fichero HDF puede contener varios subdatasets, a gdal no le vasta con la ruta del archivo para interpretarlo, necesita que se le indique el dataset en concreto al que se quiere acceder. 105 Proyecto final de carrera. La variable divisions indica el número de divisiones en las que se va a separar un píxel, tanto en x como en y, para determinar una serie de puntos dentro del píxel. Este conjunto de punto es el que se va a utilizar para determinar el porcentaje del píxel que está dentro de un polígono, comprobando para cada punto si está dentro o no del polígono. Después de optimizar el algoritmo lo mejor posible, se ha comprobado que el coste temporal se eleva exponencialmente cuando el número de divisiones se aumenta, por lo que se ha decidido utilizar solo 2 divisiones por dimensión, lo que da un total de 16 comprobaciones por píxel. Se pierde algo de precisión en el cálculo en pos de tener un coste temporal razonable. El método encargado de realizar esta comprobación es included(), dentro de la clase VectorialDataGen de la extensión extVectorialCut. Esta misma clase también se utiliza en la extensión encargada de realizar el análisis estadístico de capas raster extRasterStatistics. Es por esto que hay una dependencia de esta extensión con extVectorialCut, como se indica en el diagrama de componentes del sistema. 5.2.5 Herramienta de generación de datos vectoriales Esta herramienta cuenta con un mecanismo sencillo que se basa en ir recorriendo una lista de geometrías y, para la extensión de cada una de ellas, hacer cálculos estadísticos con los píxeles de las capas vectoriales que coincidan. Los algoritmos más importantes, se centralizan en dos clases: StatisticCalc: Dada una lista de datos numéricos, calcula y devuelve las estadísticas necesarias para la aplicación. VectorialDataGen: Se encarga de realizar el recorrido de las geometrías correspondientes así como de las imágenes incluidas en el cálculo. Contiene también el método encargado de comprobar si un píxel está dentro de una geometría dependiendo del porcentaje de solape umbral. Puede usarse con tres modos distintos de funcionamiento. Puede recorrer todas las geometrías de una capa y para cada una, añade en la tabla de la capa 112 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. vectorial los valores de los estadísticos que indicados. También se le puede indicar que solo realice el cálculo para las geometrías de la capa vectorial que estén seleccionadas. Por último, existe un modo con el cual se calculan las estadísticas (únicamente la media aritmética) para todas las geometrías de la capa a la vez. Este modo no actualiza la tabla de la capa vectorial sino que muestra por pantalla el valor de la media calculada. Este último uso responde al requisito de calcular la media para una extensión de terreno que digitaliza el usuario de forma manual usando las herramientas de CAD de gvSIG. Cuando el proceso finaliza se invoca al método addAllValues() dentro de la clase VectorialDataGen, que se encarga de introducir los datos calculados en las lineas que corresponda en la tabla de la capa vectorial. 113 Figura 49: Diseño de la herramienta Figura 50: Cabecera de addAllValues Proyecto final de carrera. 5.2.6 Herramienta de análisis estadístico El análisis estadístico de imágenes tampoco es una herramienta complicada en su funcionamiento. De manera similar a la herramienta anterior, existe una clase (StatisticsAlgorithm) que ejecuta el algoritmo con el cual se recorren los píxeles de las imágenes implicadas en el cálculo. Utiliza la clase StatisticsCalc, que hemos comentado en el apartado anterior, para conseguir las estadísticas numéricas y, a partir de estas, se obtienen los datos necesarios para generar las estadísticas gráficas. Es posible realizar los cálculos sobre una población determinada por un conjunto de geometrías de una capa vectorial cuyos atributos en su tabla cumplan una condición determinada por el usuario. Mediante el panel GroupSelectionPanel y su listener GroupSelectionListener, se crean conjuntos de geometrías que cumplen condiciones indicadas por el usuario que se añaden en las correspondientes consultas SQL a la tabla de la capa vectorial. Si estos conjuntos de geometrías (FBitSet) se le indican al algoritmo que recorre los datos en StatisticsAlgorithm, los tienen en cuenta y genera un juego de datos estadísticos para cada población. Con esto se demuestra la sencillez del proceso de realización de los cálculos y obtención de los datos estadísticos, ya que no comprende ningún proceso fuera de lo común. A grandes rasgos, se determina la población a estudiar mediante un conjunto de geometrías de una capa vectorial, se recorren los píxeles que correspondan a dichas geometrías (utilizando o no el umbral de solape) y se calculan los datos numéricos. El paso final es la representación de los datos. En el caso de las estadísticas numéricas, la cuestión es trivial, se escriben en un panel susceptible a seleccionar y copiar el texto para que pueda ser utilizado en otros documentos. En cambio, el caso de las estadísticas gráficas es diferente. Para dibujar los diferentes gráficas estadísticas que se piden, se contempló utilizar la librería jFreeChart. JFreeChart es una librería escrita en Java con licencia libre que tiene como propósito ofrecer un gran conjunto de representaciones gráficas de datos. Recordemos que uno de los requisitos de esta herramienta es que los gráficos 114 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. estuviesen enlazados, es decir, que en el caso de seleccionar una población en un gráfico, se seleccione automáticamente en el resto de gráficos y se seleccionen las geometrías de la capa vectorial que corresponden a dicha población. En este sentido, JFreeChart no ofrece posibilidad de modificar el dibujado de los gráficos a bajo nivel, por lo que determinar una forma concreta para los objetos del gráfico o cambiar el color de uno de sus componentes al quedar seleccionado, no pareció una tarea asequible. Es por esto que se decidió desarrollar componentes en Java que representasen las gráficas. Heredando de JComponent se desarrolla la clase GraphicsBase que representa el panel base sobre el cual se dibujan las diferentes gráficas estadísticas. Ofrece métodos para determinar los valores máximo y mínimo de cada uno de los ejes, las divisiones por ejes, la existencia de rejillas o el color de fondo. En esta clase se implementa el dibujado de todos los detalles de la base de la gráfica, sin pintar los componentes correspondientes a cada tipo de estadística. Cada una de los tipos de gráfica que se quieran representar, tendrán que heredar de GraphicsBase e implementar el método draw() invocando siempre primero el paint() del padre (super.paint()). Con esto se está dibujando primero el gráfico base y, sobre él, el 115 Figura 51: Componente base sobre el que pintar las gráficas Proyecto final de carrera. resto de elementos correspondientes a cada gráfico. El pintado de todos los componentes desarrollados se realiza utilizando doble buffer para evitar parpadeo. Esto quiere decir que cada vez que se redibuja el componente, lo hace sobre un buffer temporal y solo cuando acaba el dibujado se pasa el valor de este buffer al que se está visualizando por pantalla. El diagrama de clases de la imagen, representa la arquitectura con la que se ha diseñado el componente que dibuja los gráficos. Cada nuevo componente, hereda de GraphicsBase dibujando sus propias formas. Como se puede observar, todos los componentes implementan la interfaz Ilinkable, que ofrece los métodos necesarios para obtener y determinar la población que está seleccionada. También permite ordenar el redibujado del componente así como 116 Figura 52: Diagrama de clases del diseño de los gráficos Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. exportar el gráfico a un fichero de imagen. Es uso de esta interfaz se explicará más adelante. Las clases HistogramObject, BoxWishkerObject y ErrorBarObject representan las figuras que se van a dibujar en cada uno de los gráficos, teniendo datos de posiciones de cada una de las coordenadas del dibujo. Estas clases contienen el modelo de datos de cada estadístico, es decir, estrictamente sus datos numéricos, sin entrar en su representación. En el caso del BoxWishker y del Histograma, se han desarrollado clases específicas para representar este modelo debido a su complejidad. En el caso de las barras de errores, los valores numéricos se pasan directamente a la representación gráfica del objeto dada su simplicidad. En el siguiente diagrama de clases se muestra el sistema por el cual se relacionan los gráficos con el algoritmo que calcula los datos así como la forma en que los gráficos están enlazados. 117 Figura 53: Diseño del enlace de los gráficos Proyecto final de carrera. Tal y como se ha comentado anteriormente, la clase StatisticsAlgorithm se encarga de seleccionar y recorrer los píxeles que forman parte del estudio estadístico para cada una de las poblaciones definidas apoyándose en StatisticsCalc (clase de extVectorialCut que calcula datos estadísticos). Una vez calculados los datos, los representa en la capa de interfaz gráfica. En el caso de los estadísticos numéricos, le pas el texto directamente a NumericStatPanel, que los muestra y permite su copiado. La representación de las estadísticas gráficas se realiza mediante el uso de una serie de clases gráficas que implementan la interfaz IGraphicPanel. Esta interfaz permite el acceso al gráfico ILinkable que contiene dicho panel. Está diseñado para los paneles dedicados a visualizar gráficos susceptibles a estar enlazados entre ellos para permitir, precisamente, el acceso a estos gráficos para conocer o modificar la selección actual. De la misma forma, crea una instancia de GraphicLinker, clase encargada de enlazar la selección en cada una de las gráficas que se le añaden. Esta clase implementa MouseListener y pasa a ser un listener de eventos de ratón de los componentes que se le añaden. Captura los eventos de ratón relacionados con la selección de una población en un gráfico ILinkable (en concreto el doble click). Al recibir un evento de este tipo, identifica la fuente, consulta la población seleccionada y recorre el resto de gráficas registradas seleccionando la misma población en todas. Finalmente, obtiene la definición de dicha población y selecciona las geometrías de la capa vectorial utilizada que coincidan con la población. Vemos que las clases ResultPanel, son simples contenedores de un componente de tipo GraphicsBase que, a su vez, implementa ILinkable. Dado que el GraphicLinker necesita acceder a cada uno de los ILinkable contenidos en los ResultPanel, éstos tienen que implementar la interfaz IGraphicPanel, que ofrece acceso a los gráficos. Con todo esto, también queda explicada la dependencia de la extensión en la que se desarrolla el análisis estadístico (extRasterStatistics) con extVectorialCut, que calcula los datos estadísticos necesarios. 118 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 5.2.7 Herramienta de cálculo raster La calculadora de capas raster, tal y como se ha indicado en otras partes de la memoria, no se desarrolló en este proyecto sino que el trabajo contratado en el mismo, se basaba en la adaptación de dicha herramienta a la versión con la que se iba a trabajar. De esta forma, el único trabajo de desarrollo relacionado con la calculadora raster fue su extracción en un proyecto de Eclipse propio desde extRemoteSensing y su adaptación a la versión 1.1.2 de gvSIG. Con este fin, solo fue necesario adaptar las estructuras de datos con las que se representan los raster en gvSIG, que difieren de una a otra versión y, por tanto, es un trabajo de poca importancia. 5.3 Generación de instaladores Una vez desarrollada toda la funcionalidad del proyecto, hay que entregarla al cliente y permitir su distribución y correcta instalación para su uso. Para esto se generan ficheros instalables que, dada una versión de gvSIG 1.1, amplían su funcionalidad con las nuevas herramientas. El instalador del proyecto, necesita de una versión de gvSIG previamente instalada en el sistema y, durante el proceso de instalación, se tendrá que especificar la ruta en que se encuentra. Para realizar el instalador, se ha utilizado la misma herramienta que se usa en gvSIG para generar las distribuciones, IzPack. La configuración principal de una instalación con IzPack, se indica en el fichero install.xml, donde se añade cada uno de los bloques que se quieren instalar utilizando el target pack. Cada una de las extensiones que hay en gvSIG se corresponde con un pack diferente dentro del install.xml que ya hay desarrollado para las versiones de gvSIG. En el trunk del SVN de gvSIG, ya existe una carpeta install que contiene la estructura necesaria para realizar una distribución de gvSIG. Mediante el uso de esta carpeta y la modificación de sus archivos de configuración, se consiguen instalaciones 119 Proyecto final de carrera. parciales para un conjunto de herramientas dado. De esta forma, dentro del proyecto extCHGRaster, existe una carpeta install. La estructura es similar a la carpeta install de gvSIG, por lo tanto tiene un archivo de compilación ant (buildExt.xml) que realiza el proceso de generación de los instalables binarios. En la siguiente imagen se muestran las modificaciones más importantes del fichero de configuración de IzPack para la generación de los instalables. Los tres primeros packs, corresponden a las herramientas que no modifican clases dentro de gvSIG ni librerías nativas. Corresponden con los proyectos de Eclipse extRasterCalculator, extRasterStatistics y extVectorialCut. El último pack inscluye las herramientas desarrolladas dentro del proyecto extCHGRaster y la actualización de las clases de gvSIG que se han modificado para dar soporte al presente proyecto. Por razones de espacio no se incluyen todas las lineas de este último pack, pero se puede encontrar el código completo en el fichero install.xml dentro de la carpeta install del proyecto extCHGRaster. 120 Figura 54: Grupo de packs para el instalable con IzPack Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. También se realizaron instaladores de cada una de las herramientas por separado con la idea de que si el cliente decidía liberar la extensión para su uso público, poder distribuir parcialmente el proyecto. Cada uno de los proyectos de eclipse relacionados con la aplicación contiene una carpeta install que permite generar un fichero binario para la instalación de sólo esa herramienta. Indicar que, durante el desarrollo de la aplicación, se puso especial interés en utilizar al máximo los puntos de extensión de gvSIG para no tener que modificar el núcleo, ya que en el momento del desarrollo del proyecto, gvSIG se encontraba en proceso de estabilización y, modificar el núcleo en ese momento podría peligrar tal proceso. 121 Proyecto final de carrera. de la Universidad de Valencia. [ECL] Eclipse.org home. http://www.eclipse.org . 128 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. ANEXO A: Manual de usuario 129 Proyecto final de carrera. 130 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 131 Proyecto final de carrera. 132 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 133 Proyecto final de carrera. 134 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 135 Proyecto final de carrera. 136 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 137 Proyecto final de carrera. 144 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 145 Proyecto final de carrera. 146 Monitorización de los recursos hídricos de la cuenca del Guadalquivir mediante tecnologías SIG y teledetección. 147 Proyecto final de carrera. 148