PROYECTO ANDALUSÍG, dentro del. Sistema Integrado de Información Agraria de Andalucía (SIIA)

Transcripción

1 PROYECTO ANDALUSÍG, dentro del Sistema Integrado de Información Agraria de Andalucía (SIIA) Alvaro Zabala Ordóñez1, Marco Antonio Fuentelsaz Pérez1, Antonio Muñoz Rastrero1, Sergio Baños Calvo1, Borja Mañas Alvárez1 1: Empresa Pública Desarrollo Agrario y Pesquero. El Sistema Integrado de Información Agraria de Andalucía es un programa de actuaciones que surge a raíz del Plan de Modernización de la Agricultura Andaluza, cuyo objetivo es obtener una mejora de los sistemas de información desde y hacia el sector agroalimentario, como herramienta de apoyo al proceso de toma de decisiones. En un primer momento, la aplicación GIS del SIIA fue desarrollada como un Sistema Abierto e independiente de la plataforma, frente a las tendencias predominantes dentro del mercado GIS, que apuntaban claramente hacia el software propietario. En los últimos tiempos, la tendencia en el campo de desarrollo de software se está invirtiendo, y ha emergido con gran fuerza el movimiento del Software Libre. La Junta de Andalucía ha sido, junto con la Junta de Extremadura, una de las primeras administraciones públicas en apostar por esta filosofía, al ser consciente de las importantes ventajas que aporta tanto para la sociedad como para las empresas del sector, que se pueden aprovechar de las sinergias existentes. En ese sentido, la aplicación GIS del SIIA se ha encontrado en una posición inmejorable para aprovecharse de los beneficios del movimiento del Software Libre, al estar concebida como un sistema abierto y estar desarrollada con la plataforma Java, plataforma de desarrollo independiente tanto del entorno hardware como del sistema operativo que dan soporte a las aplicaciones. Esto hace posible, por ejemplo, que el SIIA pueda funcionar sin ningún esfuerzo adicional en sistemas operativos como GuadaLinex o Linex. En un primer momento, el SIIA ha hecho uso de numerosos proyectos de carácter libre, distribuidos bajo diferentes tipos de licencia (GPL, Apache) para incorporar funcionalidades y servicios soportados por estos. No obstante, para la consecución de la implantación de los procesos de negocio a los que el SIIA debe dar soporte, se han realizado una serie de desarrollos propios, partiendo de productos libres ya desarrollados. El siguiente paso dentro de esta decidida apuesta del SIIA por el Software Libre será la distribución de estos desarrollos bajo algún tipo de licencia libre (GPL, LGPL, Apache, etc.) Palabras Clave: SIIA, Software Libre, Java, GIS

2 PROYECTO ANDALUSÍG, dentro del Sistema Integrado de Información Agraria de Andalucía (SIIA) Alvaro Zabala Ordóñez1, Marco Antonio Fuentelsaz Pérez1, Antonio Muñoz Rastrero1, Sergio Baños Calvo1, Borja Mañas Alvárez1 1: Empresa Pública Desarrollo Agrario y Pesquero. PARTE I: INTRODUCCIÓN Y MOTIVACIONES. 1) El Software Libre como elemento clave para el impulso de la Sociedad de la Información en Andalucía. La Junta de Andalucía, consciente de la importancia que las Nuevas Tecnologías están cobrando en la sociedad actual, y con el objetivo de impedir la aparición de la denominada brecha digital, que incremente las desigualdades como consecuencia de la dificultad de acceso a las tecnologías de la información, está tomando una serie de medidas encaminadas al impulso de la Sociedad de la Información. Estas medidas, materializadas en una serie de planes como el III Plan Andaluz de Investigación, o el Plan Info-AlAndalus: actuaciones estratégicas para el desarrollo de la Sociedad de la Información en Andalucía, alcanzaron su punto culminante con la publicación del DECRETO 72/2003, de 18 de marzo, de Medidas de Impulso de la Sociedad del Conocimiento en Andalucía, en el BOJA de 21 de Marzo. El principal objetivo de este decreto es poner las Nuevas Tecnologías al servicio de los ciudadanos andaluces, para obtener una mejora en la calidad de vida, en el equilibrio social y por consiguiente en la productividad. Para ello, el decreto se traduce en varias medidas que buscan alcanzar una serie de objetivos específicos, necesarios para alcanzar el mencionado objetivo principal: - Facilitar el acceso a Internet a todos los ciudadanos, y la apertura de este canal telemático a los servicios que presta la Administración (e-administración). - Adaptar servicios básicos como Educación, Sanidad, Bibliotecas y Fondos Documentales, etc a las tecnologías de la información, con los beneficios potenciales que ello conlleva. - Garantizar el acceso de todos los andaluces y andaluzas a las tecnologías de la información y las comunicaciones. Dentro de las medidas propuestas en el Decreto para la consecución de este último objetivo, como implantación de puntos de acceso a Internet para ciudadanos, buzón de correo gratuito para mayores de 14 años, etc. destaca dentro del ámbito que nos ocupa la difusión de la utilización del Software Libre. De esta forma, el artículo 31 de este decreto establece los siguientes puntos: - En las adquisiciones de equipamiento informático destinado a los centros docentes públicos para su uso en actividades educativas, se exigirá que todo el hardware sea compatible con sistemas operativos basados en software libre. Los ordenadores tendrán preinstalado todo el software libre necesario para el uso específico al que estén destinados.

3 - El equipamiento informático que la Administración de la Junta de Andalucía ponga a disposición en los centros de acceso público a Internet utilizará para su funcionamiento productos de software libre. - La Administración de la Junta de Andalucía fomentará la difusión y utilización orientadas al uso personal, doméstico y educativo de software libre debidamente garantizado. A tal fin se establecerá un servicio de asesoramiento a través de Internet para la instalación y uso de este tipo de productos. La materialización de todas estas medidas ha sido el proyecto GUADALINFO. Este proyecto ha sido impulsado por la Junta de Andalucía, con la colaboración de varias consejerías y contando con participación privada, y su objetivo básico es la creación de centros de acceso público a Internet en banda ancha para municipios de menos de veinte mil habitantes. Uno de los pilares sobre los que se está desarrollando este proyecto es el sistema operativo de carácter libre GUADALINEX. GUADALINEX es una distribución del sistema operativo GNU/Linux, basada en una de las distribuciones libres más populares de éste: Debian. Al desarrollar una distribución propia como ésta, la Junta de Andalucía obtiene la capacidad de soporte necesaria para dar servicio al ciudadano, y es capaz de dotar a ésta de la facilidad de uso e instalación de las que suelen carecer las distribuciones no comerciales normales. GUADALINEX es la principal muestra de la voluntad de la Junta de Andalucía para promocionar la utilización de Software Libre, por las consabidas ventajas para la sociedad que éste proporciona. 2) SIIA: Sistema Integrado de Información Agraria de Andalucía. El Sistema Integrado de Información Agraria de Andalucía (SIIA) surgió para dar respuesta a varios de los objetivos planteados por el Plan de Modernización de la Agricultura Andaluza, elaborado por la Consejería de Agricultura y Pesca. En concreto el SIIA entronca directamente con las siguientes estrategias de modernización del plan: - Estrategia nº 8: Infraestructura de I+D+I al servicio de los sectores productivos. - Estrategia nº 9: Información como un factor clave para mejorar la competitividad. - Estrategia nº 10: Obtención de un sector agroalimentario organizado y vertebrado. - Estrategia nº 16: Una administración agraria ágil y eficaz, al servicio del sector agrario. Como podemos ver, en este plan se da una especial importancia a la información como un factor clave en la obtención de la competitividad (en el mismo sentido del decreto 72/2003 anteriormente mencionado). El SIIA permite gestionar toda la información de interés tanto para la Administración como para los distintos agentes económicos y sociales del complejo agroalimentario, manteniéndola perfectamente actualizada. Además, posibilita la realización de estudios prospectivos y el modelado de escenarios que sirvan de apoyo para la toma de decisiones en materia de política agraria. El SIIA por el tipo especial de información con la que trabaja (datos geográficos o susceptibles de ser referenciados espacialmente) cae dentro del ámbito de estudio de los Sistemas de Información Geográfica. El SIIA ha sido concebido como una herramienta para ser utilizada no solo por la administración, sino también por todos los agentes que estén relacionados con la realidad

4 agraria: agricultores, ganaderos, asociaciones profesionales, sindicatos, etc. De esta forma, el SIIA no es solo un sistema que permite mejorar la gestión interna de la administración, sus propios procesos, sino que también permite mejorar la relación de ésta con sus administrados, centralizando los flujos de información entre ambos. El sistema consigue dar servicio a esta pluralidad de usuarios con intereses tan distintos (regadíos, ganadería, forestación, acuicultura, etc.) de una forma totalmente integrada. Es decir, los datos que se ofrecen y las herramientas proporcionadas para su tratamiento dependerán tanto del ámbito abordado (los anteriormente mencionados y otros más, como concesiones de agua, catastro, etc.) como de los privilegios que tenga asignados el usuario para ese ámbito. Estos usuarios puede acceder al sistema bien a través de la Red Corporativa de la Junta de Andalucía (usuarios de la propia administración), bien a través del portal web de la Junta (usuarios externos). 3) SIIA y Software Libre. a) SIIA apuesta por la plataforma Java y los Sistemas Abiertos. Tal y como hemos comentado con anterioridad, el SIIA es un sistema de información que cae dentro del ámbito de los Sistemas de Información Geográfica (GIS), al manipular datos geográficos o que son susceptibles de ser referenciados espacialmente. Este sector tradicionalmente se ha visto dominado por el software propietario, e incluso la tendencia dominante apuesta por desarrollos basados en una única plataforma: Microsoft Windows, manteniendo un nicho de productos residuales para el resto de plataformas. Tal es el caso de ESRI, líder mundial del mercado GIS, cuyos productos en un principio estaban basados en componentes ActiveX, y actualmente en la plataforma.net. El SIIA desde su concepción se desvió rápidamente de esta tendencia, pues su objetivo principal era dar servicio a una gran pluralidad de usuarios funcionando bajo diversos entornos y plataformas. Con tal fin, el núcleo del SIIA fue desarrollado íntegramente con la plataforma Java. Gracias al empleo de la plataforma Java, un mismo núcleo dio soporte a servicios heterogéneos que debían funcionar bajo diferentes entornos. Teniendo en cuenta la supremacía de la familia de sistemas operativos Unix en el mundo de los servidores, caracterizada por la seguridad y estabilidad, el servicio web del SIIA comenzó a funcionar en un servidor web Apache bajo un sistema operativo Unix. La lógica de las aplicaciones desarrolladas en Java era ejecutada por el motor de servlets Tomcat, también de carácter gratuito y libre. Con posterioridad el motor de Servlets Tomcat fue sustituido por un servidor de aplicaciones, capaz de ejecutar componentes EJB (Enterprise Java Beans). De hecho, el servicio web del SIIA podría funcionar dentro del entorno de ejecución de cualquier servidor de aplicaciones compatible con la especificación J2EE. Para la manipulación, tratamiento y recuperación de imágenes digitales de gran volumen, el SIIA utilizó el formato de almacenamiento de imágenes ECW. Este formato presenta una serie de ventajas que lo hacen muy adecuado para el almacenamiento de imágenes de gran resolución: - Elevado grado de compresión, al utilizar algoritmos Wavelet. - Empleo de imágenes piramidales. - Bajo porcentaje de pérdida de información (compresión no degradativa). No obstante, se trata de un formato propietario y no existen bibliotecas de programas adecuadas para la carga de este tipo de imágenes en plataformas que no sean compatibles con

5 Microsoft Windows. Por esta razón, el servicio web del SIIA se complementa con una serie de servicios distribuidos, encargados de la manipulación de imágenes y datos cartográficos, funcionando bajo diferentes plataformas. Estos servicios comparten el mismo núcleo de sistema que el servicio web, al estar desarrollados con el lenguaje multiplataforma Java. En el momento de concepción del SIIA no existían productos de carácter libre desarrollados en Java que pudiesen servir como un adecuado punto de partida para su desarrollo. En adición, la gran mayoría de productos GIS existentes en el mercado estaban orientados a trabajar con ficheros de datos o con bases de datos personales (DBase, Access), lo que resultaba inapropiado para arquitecturas cliente / servidor a tres capas, soportando varios clientes concurrentes. Por esta razón, se optó por desarrollar íntegramente el corazón del SIIA, lo que en el sector se denomina Geodatabase, a partir de las especificaciones publicadas por el consorcio OpenGIS (OGC). De esta forma, se desarrolló un modelo de clases Java (basado en las especificaciones OGC) y se creó un modelo de datos en una base de datos relacional que diese soporte persistente a las clases Java mencionadas. Gracias al estándar de acceso a Bases de Datos JDBC, el SIIA es capaz de trabajar con cualquier base de datos relacional de la que se disponga de un driver JDBC. No obstante, por razones de celeridad en la prestación de servicio la función de renderizado de mapas fue delegada en última instancia en un producto comercial: ArcIMS de la casa comercial ESRI. ArcIMS es un servidor de mapas que trata de seguir en mayor o menor medida la especificación OGC WMS (Web Mapping Service). Este servidor recibe peticiones en formato XML (según la misma filosofía de la especificación SOAP del consorcio W3C) y como respuesta genera imágenes con los mapas solicitados, devolviendo a su vez un mensaje XML del que, entre otra información, se puede extraer la ubicación de la imagen guardada. En adición, permite gestionar aspectos adicionales como la simbología de los elementos cartográficos, etiquetado, formato de los textos en los mapas, etc. Aún así, ArcIMS es simplemente un servidor de mapas, del que no se puede esperar que soporte las funciones de análisis y geomodelaje que caracterizan a los Sistemas de Información Geográfica, funciones que sí son soportadas por el núcleo Java del SIIA. b) SIIA consumidor de Software Libre. Además, durante este tiempo en el que el SIIA ha estado dando servicio, han comenzado a surgir desarrollos de productos GIS de carácter libre publicados bajo la licencia del software libre por excelencia: la licencia GPL. La existencia de un software de carácter libre, con gran parte de funcionalidad implementada, posibilitaba la extensión del SIIA sin tener que partir desde cero. En concreto, el equipo del SIIA fijó su atención en las suites JTS y JUMP. JUMP (Java Unified Mapping Platform) es un cliente al estilo del GIS de escritorio ArcView. Tiene funciones de edición y análisis espacial avanzado, como cálculo de áreas de influencia, cruce entre capas de polígonos, etc. Presenta una arquitectura basada en plugins que le hace relativamente fácil de extender. JUMP es capaz de cargar orígenes de datos en fichero (ShapeFile, GML), también es capaz de conectarse a una base de datos Postgre SQL con la extensión espacial PostGIS, e incluso puede conectarse a servidores WMS y mostrar las imágenes generadas por este tipo de servidor. Gracias a su arquitectura extensible, JUMP es capaz de cargar cualquier origen de datos cartográfico para el que se desarrolle un plugin que realice esa tarea. JTS (Java Topology Suite) es una implementación de la especificación de geometrías del consorcio OpenGIS. JTS proporciona funciones de análisis avanzado como cálculo de áreas

6 de influencia, cruce de polígonos, evaluación de predicados binarios del tipo intersecta a, toca a, etc. Ambos proyectos han sido desarrollados por la empresa canadiense Vivid Solutions Inc., y han sido distribuidos con licencia GPL. Adicionalmente, el SIIA hace uso de otros productos de carácter libre, no directamente relacionados con la lógica GIS, pero sí necesarios como subsistemas de soporte para la realización de tareas básicas en todo sistema de información. De estos productos cabe destacar Hibernate, Velocity, JFreeChart, JFreeReport, o Log4J. Hibernate. Este producto libre, distribuido bajo licencia LGPL, es un potente motor de persistencia basado en la técnica del mapeo Objeto / Relacional. Un motor de persistencia es un subsistema que nos permite hacer persistentes las instancias de nuestras clases sobre múltiples almacenes: bases de datos, ficheros, sistemas heredados, etc. Además, nos permite recuperar instancias de estos objetos según diferentes criterios. Los motores de persistencia están diseñados para realizar esta labor de forma muy eficiente y optimizada, por lo que liberan a los desarrolladores, acostumbrados a trabajar con clases, de tener que trabajar con conceptos relacionales. De forma paulatina, el corazón del SIIA se está migrando para hacer uso de Hibernate, de forma que se gestionen de forma sencilla y transparente los accesos a la base de datos. Velocity. Es un motor de plantillas desarrollado íntegramente en Java por el proyecto Jakarta de Apache. Jakarta es un proyecto que se encarga de proporcionar herramientas de carácter libre y de código abierto a la comunidad de desarrolladores Java. En vez de utilizar alguna de las licencias GNU, Apache distribuye sus productos libres con una licencia propia: la licencia de software libre de Apache. Un motor de plantillas es un subsistema que se encarga de generar las vistas de una aplicación web (código Html) a partir del contenido de una plantilla, normalmente un fichero de texto con formato. Esta definición casa perfectamente con la tecnología de páginas JSP. De esta forma, una página JSP se podría ver como una plantilla. No obstante, Velocity (y sus páginas VTL) presenta una serie de ventajas sobre las páginas JSP que nos decidieron a optar por su utilización. Entre ellas cabe destacar: Las páginas JSP mezclan la lógica de presentación con la lógica de negocio (el acceso a objetos Java), lo que se traduce en un código en espagueti difícil de mantener. Por el contrario, las páginas VTL de Velocity mantienen una clara separación entre ambas. Las páginas JSP no permiten la reutilización de componentes visuales. Velocity permite definir bibliotecas de macros de las que se puede hacer uso desde las páginas VTL. Por esta razón, las macros Velocity pueden ser consideradas como componentes reutilizables. Las páginas JSP experimentan una fase inicial de compilación (en la primera petición que reciben), lo que eleva mucho el tiempo de respuesta de los primeros usuarios que solicitan estas páginas. Por el contrario, las páginas VTL presentan un buen rendimiento en todas las peticiones al no atravesar por el ciclo interpretado-traducción a código java-generación de código binario. Log4J. Es un sistema de traza de mensajes desarrollado también como parte del proyecto Jakarta, y distribuido bajo licencia de software libre de Apache. Un sistema de traza de mensajes (habitualmente conocido por su termino inglés Logging ) permite controlar la ejecución de los sistemas desarrollados, para revisar si su funcionamiento es el debido. Facilita controlar el nivel de prioridad de los mensajes generados por el programa como ayuda a la depuración, y volcarlos según diferentes salidas: pantalla, ficheros de log, tablas de

7 base de datos, etc. La última versión del JDK de Java (la 1.4) incluye un subsistema de este tipo. No obstante, en la mayor parte de entornos de producción los servidores de aplicaciones y motores de servlets no contemplan esta versión, sino que trabajan con la versión anterior. Esta política es muy prudente, pues el JDK 1.4 lleva relativamente poco tiempo a disposición de la comunidad, y no está todavía suficientemente maduro. Por esta razón, es muy útil el empleo de este subsistema de traza de mensajes de Jakarta. JFreeChart. Se trata de una biblioteca de clases Java, distribuida bajo licencia GPL, para la generación de gráficos y diagramas. El SIIA hace uso de esta útil herramienta para la generación de gráficos de todo tipo, tanto desde entorno Internet (gracias a su facilidad de exportación a formatos de imagen como PNG, JPEG, etc) como en los nuevos desarrollos de escritorio. JFreeReport. Consiste en un subsistema de generación de informes para su impresión y visualización por pantalla. A partir de documentos XML que especifican el formato que ha de tener el informe, se puede interactuar con el API Java que proporciona para dotar de contenido a dichos informes. Esta biblioteca de clases también permite generar salidas según diferentes formatos: Html, PDF, Excel, impresión, etc. Gracias a su uso, se han facilitado mucho las tareas relacionadas con el formateo de informes impresos, como selección del formato de papel, cambio de orientación, etc. JFreeReport y JFreeChart han sido desarrollados por la empresa Object Refinery y son distribuidos bajo licencia GPL. c) SIIA productor de Software Libre. Actualmente, el equipo SIIA está desarrollando una extensión del GIS de escritorio JUMP para que se conecte a su Geodatabase núcleo de la aplicación GIS del SIIA- y sea capaz de acceder a los orígenes de datos cartográficos contenidos en ella. Esta extensión se encuentra en estado muy avanzado, y de ella ya existe disponible una versión Beta. En algunas de las figuras que acompañan al presente documento se pueden ver capturas de pantalla con el funcionamiento de la aplicación. Se trata de una arquitectura cliente / servidor a dos capas, con el cliente JUMP accediendo directamente a la Geodatabase incluida dentro de una base de datos relacional. Además, se está desarrollando un servidor de datos espaciales, y una extensión de JUMP capaz de conectarse al mismo y de trabajar con los datos servidos por éste. De esta forma, estaríamos hablando de una arquitectura cliente / servidor en 3 niveles, con un middleware intermedio (nuestro servidor espacial) que minimiza el número de conexiones consumidas de la base de datos, optimiza el tráfico de red, y además aporta lógica no existente en la base de datos gracias al empleo de las clases topológicas de JTS. De este servidor ya existe una primera versión Beta, capaz de recuperar datos de la base de datos según diferentes criterios, incluso espaciales aunque la base de datos no estuviese preparada para trabajar con este tipo de datos. Estas extensiones contemplan también la posibilidad de trabajar con imágenes digitales y orígenes de datos Raster, característica de la que en un principio carecía JUMP. Actualmente se están desarrollando extensiones que permitan la edición concurrente de cartografía por parte de múltiples usuarios, el mantenimiento de diferentes versiones de un mismo elemento cartográfico (transacciones de larga duración), la implementación de reglas topológicas y asociaciones entre diferentes capas cartográficas, y funciones de análisis avanzado en general.

8 El desarrollo de estos productos se abordó tras un análisis de las herramientas de carácter libre existente, tras llegar a la conclusión de que ninguna ofrecía la funcionalidad requerida, y de que sí sería viable el desarrollo de un servidor propio, con un protocolo abierto y pública, al que se pudiese conectar cualquier tipo de cliente. El siguiente paso, una vez alcanzado un estado de madurez suficiente, será la publicación tanto del código fuente como de los scripts y utilidades necesarios para la instalación y puesta en funcionamiento del nuevo sistema, bajo una licencia de software libre. De esta forma, se pondrá a disposición de toda la comunidad de usuarios interesados un producto GIS que cubra sus necesidades, tanto de aplicaciones de escritorio (JUMP) como de servidores departamentales (Geodatabase del SIIA), y lo mas importante, independiente del sistema operativo utilizado, al estar desarrollado con la plataforma Java. 4) Descripción de la Interfaz Web del SIIA. Antes de pasar a describir cómo se ha desarrollado el núcleo del sistema, no podemos dejar de detallar algunos casos de uso de la interfaz web del mismo, de cara a ofrecer una mejor visión de la percepción que el usuario tiene de él. a) Visualización de Cartografía, y Navegación interactiva por ésta. El SIIA permite visualizar en forma de mapas los orígenes de datos cartográficos incorporados al sistema. Así mismo, el usuario es libre de modificar la escala, centro de visualización o número de capas que se le muestran. Con tal fin, todas las aplicaciones del SIIA (según el concepto de aplicación mencionado con anterioridad) ofrecen módulos para esto. FIGURA 1: CAMBIOS DE NIVEL DE ZOOM b) Consulta de Información Alfanumérica (Catastro, etc) El SIIA permite realizar consultas alfanuméricas sobre la información territorial almacenada. Para ello, proporciona módulos como los localizadores, que son asistentes que guían al usuario en su búsqueda ofreciéndole diferentes criterios de filtro para su encadenamiento. FIGURA 2: LOCALIZADORES. c) Incorporación al Sistema de datos almacenados de forma local. El Sistema también ofrece a los usuarios la posibilidad de incorporar nuevos datos para su visualización. Para ello, los usuarios autorizados podrán subir ficheros de cartografía en alguno de los formatos de intercambio soportados (ShapeFile de ESRI, GEN de Arc/Info, etc.). Estos datos solo permanecerán en el sistema mientras dure la sesión de trabajo del usuario que los incorporó, pudiendo éste realizar diversas operaciones con ellos. FIGURA 3: CARGADOR DE FICHEROS 5) Descripción de los nuevos productos en fase de desarrollo. El principal inconveniente de los clientes GIS basados en web es el hecho de que estos clientes solo reciben imágenes (PNG, JPEG, etc) de los mapas generados de lado del servidor. Como consecuencia de esto, la carga de trabajo se centra casi exclusivamente en el servidor, desaprovechándose notablemente las posibilidades de las estaciones de trabajo

9 actuales, cada vez más poderosas con la difusión del PC. Esto resulta claramente ineficiente para la realización de operaciones de análisis complejas, para las que tradicionalmente se ha recurrido a clientes propietarios, limitándose los clientes web para las tareas de visualización. Además, como los datos cartográficos reales nunca son enviados al cliente, este no puede editarlos ni modificarlos. El equipo de desarrollo del SIIA está trabajando en un servidor de datos cartográficos capaz de atender simultáneamente múltiples conexiones de diferentes clientes, gracias a un diseño multitarea concurrente. De forma complementaria, se ha desarrollado un plugin del cliente GIS de escritorio JUMP que permita acceder, mostrar, consultar y manipular los datos cartográficos proporcionados por este servidor. Adicionalmente, y aprovechando la funcionalidad de dicho servidor, se ha desarrollado otro plugin que permita a JUMP conectarse directamente a una base de datos que tenga el esquema de Geodatabase corazón del SIIA, y extraer de ésta directamente los datos. De esta forma, y aprovechándonos del mayor grado de reutilización ofrecido por los lenguajes orientados a objetos, podemos trabajar según una arquitectura cliente / servidor tradicional en dos niveles, o podemos trabajar con una arquitectura cliente / servidor en 3 capas, según se desee. En la figura FIGURA 4 podemos ver el primer paso para conectarnos a una Geodatabase con nuestra extensión de JUMP, a través del middleware propio desarrollado. La aplicación nos muestra un dialogo en el que aparecen diferentes orígenes de datos, para seleccionar alguno de ellos. Una vez seleccionado el origen, se crea una nueva capa dentro del panel de capas, y sus elementos cartográficos son dibujados en el panel de visualización de mapas, como podemos apreciar en la figura FIGURA 5. Nuestro servidor de datos cartográficos también es capaz de proporcionar datos en formato raster, según diferentes formatos. En la figura FIGURA 6 podemos ver como el cliente JUMP muestra datos de imágenes raster servidos por nuestro servidor dedicado. Para tal fin, hemos desarrollado una extensión de JUMP que sea capaz de mostrar imágenes, tanto proporcionadas por servidores dedicados como recuperadas directamente de ficheros. PARTE II: DESCRIPCIÓN TECNOLÓGICA. 1. Modelo de Clases para Datos Vectoriales: OpenGIS Simple Features Specification. El modelo de datos vectorial del SIIA ha sido desarrollado a partir de la especificación Abstract Specification: Features formulada por el OpenGIS Consortium. El elemento central de este modelo es el Feature, definido como una entidad real o abstracta cuyos atributos describen fenómenos cuantitativos o cualitativos relacionados con dicha entidad, y que es susceptible de ser referenciada espacialmente. Toda ocurrencia de esta entidad tendrá asociada dos estructuras: una geometría cuya definición es objeto de otra especificación OGC, el modelo geométrico OGC, como veremos posteriormente- y un esquema de Feature FeatureSchema según la especificación- del que el Feature es una instancia. Cada esquema de Feature tendrá asociados una serie de atributos identificados por un nombre, que tendrán asociados a su vez un tipo de dato y un valor. El siguiente diagrama de clases recoge el mencionado diseño:

10 FIGURA 4: MODELO DE CLASES BASADO EN LA ESPECIFICACIÓN DE FEATURES DE OGC. Como parece evidente, un Feature sería el equivalente a una ocurrencia de Entidad de una base de datos relacional, un FeatureSchema sería el equivalente al Esquema de esta Entidad, y un FeatureAttr sería el equivalente a un campo. A su vez, para acotar los tipos de datos que pueden tener los valores de los atributos de un Feature se introduce la clase AttributeType. El equivalente de la Entidad-Tipo o Entidad sería una FeatureCollection colección de Features- A diferencia de las bases de datos relacionales, este modelo incluye el tipo de dato Geometry, que representa las propiedades geométricas de un fenómeno geográfico, y que será utilizado, entre otros casos, para la representación gráfica de estos fenómenos en el seno de un mapa, o como base para la realización de consultas de base espacial. Qué ventajas ofrece este modelo basado en el uso intensivo de metadatos como FeatureSchema esquema del Feature- o AttributeType esquema de un atributo, formado por nombre y tipo de dato-? Un GIS, frente a otros sistemas de información, es un sistema abierto capaz de integrar nuevas fuentes de datos, procedentes de orígenes diversos y almacenadas según diferentes formatos. Gracias a este esquema de metadatos, podremos cargar nuevas fuentes de datos en el sistema, con el único requisito de que se disponga de la suficiente información sobre su esquema, incluyendo en éste la topología (punto, línea o superficie de forma simplificada) esencial para determinar la representación gráfica de los Features almacenados. De esta forma, entidades geográficas del mundo real tan poco relacionadas como Carreteras y Ríos podrán ser gestionadas por diferentes instancias de una misma clase, FeatureCollection, siendo sus ocurrencias instancias de la clase Feature. En adición, la propiedad Geometría de su esquema tomará valores de un mismo tipo de dato: el subtipo Línea, puesto que ambas son entidades de geometría uno-dimensional. 2. Modelo geométrico del OpenGIS Consortium. Como hemos visto con anterioridad, todos los esquemas de una entidad geográfica Featuretienen un atributo Geometría, cuyo tipo de dato es Geometry. Geometry es una clase abstracta raíz de la jerarquía de clases geométricas proporcionadas por la especificación OGC. El resto de clases aparecen en el siguiente diagrama de clases. FIGURA 5: MODELO DE GEOMETRÍAS DE LA ESPECIFICACIÓN OGC. La especificación OGC también establece el comportamiento que deben proporcionar aquellas clases geométricas que implementen la especificación. Destaca la inclusión de predicados binarios (operaciones de carácter booleano que relacionan dos geometrías, un ejemplo sería el predicado contenido en ) y de operaciones de análisis espacial (operaciones que se aplican sobre una geometría para obtener otra, un ejemplo sería la operación buffer, que devuelve el área de influencia de una geometría) 3. Esquema Relacional. Como ya mencionamos con anterioridad, una de las principales características de los Sistemas de Información Geográfica, y por extensión del SIIA, es la capacidad de integrar datos geográficos procedentes de fuentes heterogéneas.

11 La necesidad de que un GIS sea capaz de integrar fuentes de datos procedentes de numerosos orígenes, almacenadas según distintos formatos, es debida al tradicional problema de la falta de estándares en el ámbito de la información geográfica digital. Los Sistemas de Información tradicionales, basados en el empleo de bases de datos relacionales, no presentan este problema. Esto es así gracias a la utilización del modelo en 3 capas de ANSI y a la estandarización de los tipos de datos empleados. El modelo en 3 capas de ANSI separa el nivel lógico de la información esquema conceptual- del nivel físico esquema físico -. De esta forma, y puesto que las aplicaciones específicas entran directamente en contacto con el nivel lógico, podemos hacer cambios en el nivel físico como por ejemplo cambiar de gestor de bases de datos relacional- de forma casi transparente. Esto sucede así al menos en teoría, pues en la práctica los Gestores de Base de Datos se suelen desviar del estándar, introduciendo sus propios tipos propietarios. En el caso de las aplicaciones GIS esto no ha sucedido así. Debido a que la representación del atributo geométrico de un dato geográfico no fue estandarizada (el estandar SQL92 no contempla la inclusión de objetos), aparecieron numerosos formatos propietarios, incompatibles entre sí. Las primeras soluciones estuvieron basadas en un modelo híbridorelacional. La componente alfanumérica del dato geográfico era almacenada en bases de datos relacionales, como Dbase, (o el gestor relacional Info, utilizado por el célebre GIS Arc/Info) mientras que la componente geométrica y/o topológica era almacenada en formatos propietarios orientados a fichero. Tal es el caso del formato que durante mucho tiempo ha sido considerado estándar de facto en el almacenamiento de información cartográfica digital: el formato ShapeFile propiedad de la casa comercial ESRI. El problema surge en que, si nos movemos en otros ámbitos cambia el formato de almacenamiento considerado como estándar. En el campo del planeamiento urbanístico el formato más utilizado es el formato DXF (Drawing exchange Format) propiedad de la casa comercial Autodesk, líder mundial en el mercado CAD. También podemos encontrarnos con cartografía almacenada en formatos propietarios de equipos de medida GPS, formato propio de catastro, formatos propietarios de intercambio de particulares, formato MIGRA normalizado por el ministerio pero que nunca llegó a cuajar, etc. El SIIA es capaz de acceder a información almacenada bajo diferentes formatos gracias al empleo de una arquitectura basada en drivers, haciendo uso intensivo de los patrones de diseño Dynamic Linkage (ligadura dinámica) y DAO ( Data Access Object, objeto de acceso a datos). FIGURA 6: DIAGRAMA DE CLASES DE ACCESO A DATOS. En adición, el SIIA sigue la especificación OGC Simples Features Specification for SQL para la inclusión del tipo de dato geográfico en bases de datos relacionales que no incluyan esta característica. La especificación establece que las colecciones de datos espaciales (FeatureCollection en nuestro modelo de clases) serán almacenadas como tablas de la/s base/s de datos (siendo ésta otra característica del SIIA, la capacidad de trabajar simultáneamente con bases de datos distintas, según una arquitectura distribuida). Cada dato geográfico (Feature) será almacenado como una fila en la tabla alfanumérica, cuyos atributos serán columnas que tengan alguno de los tipos de datos definidos en el estandar ODBC/SQL 92.

12 El atributo espacial (tipo de geometría y coordenadas de los vértices que la componen) es almacenado de acuerdo con el formato WKB (Well Known Binary Format), en una tabla asociada a la anterior, la tabla de geometrías. Ambas tablas se relacionan a través de la columna geométrica, GID, siendo ésta clave primaria de la tabla de geometrías. FIGURA 7: DIAGRAMA ERD DEL ESQUEMA RELACIONAL DESCRITO. Los gestores de bases de datos más importantes (Oracle, SQL Server, Informix, Postgre-SQL, MySQL) están adoptando la especificación OGC, incluyendo tipos geométricos en el juego de tipos de datos disponible. Esta especificación es conocida como OGC SQL 92 With Geometry Types, y es un subtipo del estándar ANSI SQL Objeto-Relacional. 4. Consultas por Rectángulo: Indexación Espacial. Como consecuencia de trabajar con un modelo extendido del modelo lógico tradicional, que incorpora el componente espacial (el atributo Geometría de un esquema de Feature) surge la necesidad de realizar consultas sobre la base de datos con una nueva semántica: consultas de base espacial. Este tipo de consulta se puede expresar de la forma: Devuélveme todos los Feature (registros) de las FeatureCollection especificadas (tablas) que cumplan una determinada condición lógica (filtro alfanumérico) y además cumplan una determinada condición espacial. Las consultas de base espacial se pueden complicar tanto como exija la naturaleza del problema planteado. Así, por ejemplo, se podría plantear una consulta del tipo selecciona todas las ciudades de población superior a 5000 habitantes que caigan dentro del área de influencia de este hospital (representado como una Feature de geometría puntual), considerando un radio de 15 km. No obstante, la consulta de base espacial más simple y más intensamente utilizada en un Sistema de Información Geográfica es la consulta a partir de rectángulo: devuélveme los Features de las capas visibles que caigan dentro del rectángulo especificado. Esta consulta se realiza cada vez que el usuario modifica el nivel de zoom del área de visualización del mapa mostrado, para acercar, alejar, desplazar, etc. Puesto que parece evidente que no sería viable recorrer todos los Features (registros) de las FeatureCollection (tablas organizadas en capas) en busca de aquellos cuya geometría esté contenida en el rectángulo, se han desarrollado algoritmos de indexación espacial tanto para 2 como para 3 o más dimensiones. Estos algoritmos son análogos, para el caso n-dimensional, a los algoritmos de indexación alfanuméricos (b-tree, índices bitmap) para el caso unidimensional. Los principales algoritmos de indexación espacial existentes son el algoritmo R-Tree y el algoritmo QuadTree. Ambos algoritmos mantienen una estructura arbórea, basada en la subdivisión del espacio que abarcan todas las Feature de una FeatureCollection. En las siguientes figuras podemos ver el principio de funcionamiento de ambos algoritmos. FIGURA 8: ESQUEMA DE FUNCIONAMIENTO DEL ALGORITMO DE INDEXACIÓN ESPACIAL QUADTREE.

13 FIGURA 9: ESQUEMA DE FUNCIONAMIENTO DEL ALGORITMO DE INDEXACIÓN ESPACIAL RTREE. Independientemente del índice espacial utilizado, el proceso de consulta espacial atraviesa por dos etapas: filtro primario y filtro secundario. El filtro primario permite una rápida selección de los registros candidatos (Features) a cumplir la condición impuesta (contenido en rectángulo). Para ello, realiza sus comparaciones a partir de aproximaciones de la geometría de los Feature puestos en juego, reduciendo de esta forma la complejidad de los cálculos. El filtro secundario toma como entrada los Feature candidatos (elementos devueltos por nuestro algoritmo de indexación espacial) y realiza un cálculo topológico exacto del tipo contenido en que relacione candidatos con el rectángulo de consulta. Existen diferentes formas de implementar estos algoritmos de indexación espacial. El API JTS (Java Topology Suite), visto en anteriores apartados del presente documento, proporciona implementaciones en memoria de los algoritmos R-Tree y QuadTree. Esto implica que, una vez cargados en memoria todos los Feature de una FeatureCollection (independientemente de cual sea su mecanismo de almacenamiento persistente) podremos recuperar directamente aquellos que solapen con un rectángulo determinado. Esta forma de trabajar tiene el inconveniente de que, para poder realizar consultas de base espacial, debemos cargar en memoria todos los registros almacenados en nuestra base de datos (lo cual resulta claramente inadecuado para, por ejemplo, trabajar con FeatureCollection de parcelas catastrales, del orden de varios millones de registros). En este punto, nos encontramos con un problema derivado de que los gestores de bases de datos relacionales tradicionales (compatibles con la especificación ANSI SQL 92, como Oracle8i) no incluyen tipos de datos geométricos en su juego de tipo de datos. Como consecuencia, los algoritmos de indexación que incorporan (en el caso de Oracle índices btree e índices bitmap) no son apropiados para trabajar con la componente espacial del dato geográfico, y por consiguiente para la realización de consultas de base espacial. Como estructura de indexación espacial persistente, que permite indexar tanto registros de bases de datos como entradas en ficheros binarios de acceso aleatorio, estamos utilizando el subsistema Spatial Index Library, distribuido bajo licencia LGPL por la Universidad de California. ( Un ejemplo de base de datos relacional que considera tipos geométricos e índices espaciales es Oracle, a partir de su versión 9i. Para tal fin, incluye el tipo de dato MDSYS.SDO_GEOMETRY, que representa la clase abstracta Geometry definida en el modelo geométrico de OGC. Con esta nueva capacidad, podemos crear una tabla que soporte los registros de una FeatureCollection de términos municipales con geometrías de polígono mediante la siguiente sentencia SQL: CREATE TABLE parcelas ( parcela_id NUMBER PRIMARY KEY, nombre VARCHAR2(32), geometria MDSYS.SDO_GEOMETRY); Y podríamos añadir registros de la siguiente forma: INSERT INTO parcelas VALUES( 3,

14 'jaén', MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(3,3, 6,3, 6,5, 4,5, 3,3) ) ); Por último, Oracle9i permite indexar espacialmente los registros que contengan campos del tipo MDSYS.SDO_GEOMETRY mediante la siguiente sentencia: CREATE INDEX parcelas_spatial_idx ON parcelas(geometria) INDEXTYPE IS MDSYS.SPATIAL_INDEX; Gracias al uso del patrón de diseño DAO (Data Access Object) está previsto la incorporación de orígenes de datos de este tipo, de forma totalmente transparente al sistema. Como ejemplos de bases de datos libres que están incorporando esta capacidad, podemos mencionar PostgreSQL (con su extensión espacial PostGIS), y MySQL, que a partir de su vesión 4.1 va a incorporar también funciones espaciales. No obstante, la forma de trabajar con estas bases de datos no diferiría mucho de la aquí mostrada para trabajar con Oracle (producto de carácter comercial). 5. Orígenes de Datos Raster. El SIIA también permite el acceso y manipulación de fuentes de datos raster. Estos datos se corresponden con imágenes digitales, procedentes de vuelos aéreos fotogramétricos o de imágenes de teledetección. Dichas imágenes se caracterizan por su gran tamaño, del orden de magnitud del Gb, ya que forman mosaicos que pueden llegar a cubrir naciones e incluso continentes. Con tal fin, se utiliza como formato preferido de almacenamiento el ECW (Enhanced Compressed Wavelet), propiedad de la casa comercial ER-Mapper ( Este formato ofrece ratios de compresión muy elevados, conservando una calidad visual más que aceptables, característica que le hace altamente recomendable frente a otros formatos como el JPEG, que es muy degradativo, o el TIFF, que no ofrece suficiente grado de compresión. En adición, los tiempos de recuperación de fragmentos de imágenes están muy optimizados, al utilizar pirámides de imágenes multiresolución. Para su uso desde todo tipo de aplicación GIS o de Teledetección, ER-Mapper ofrece para su descarga una API Java que permite extraer fragmentos de imagen en forma de instancias de la clase java.awt.bufferedimage a partir del rectángulo del puerto de visión solicitado. En el caso de datos en formato raster, que no son más que imágenes digitales de las que se conoce las coordenadas de sus esquinas, la indexación espacial es inmediata, y viene dada por la propia estructura matricial de las imágenes digitales. Conociendo las dimensiones en pixeles de la imagen, y las coordenadas reales de sus esquinas, es posible obtener las coordenadas pixel de cualquier coordenada del mundo real que se proporcione. Como extensión a la especificación de Features, OGC ha elaborado una especificación que incluye orígenes de datos no vectoriales: OGC Coverages Specification. Dentro de esta

15 especificación se incluye el modelo de clases para orígenes de datos raster, no incluido en ninguno de las APIs utilizadas (JTS, JUMP). 6. Referencias SIIA-Web: Spatial Oracle.: Open GIS: ArcIMS: JTS (Java Topology Suite): JUMP (Java Unified Mapping Platform): JfreeChart y JFreeReport: Spatial Index Library: ER-Mapper:

16 LISTADO DE FIGURAS FIGURA 1: CAMBIOS DE NIVEL DE ZOOM E INCORPORACIÓN DE NUEVOS DATOS FIGURA 2: LOCALIZADORES.

17 FIGURA 3: CARGADOR DE FICHEROS FIGURA 4: SELECCIONANDO UNA CAPA DE LA GEODATABASE CON JUMP

18 FIGURA 5: CAPA DE LA GEODATABASE CARGADA EN JUMP FIGURA 6: EXTENSIÓN DE JUMP PARA ACCEDER A ORÍGENES RASTER.

19 FIGURA 4: MODELO DE CLASES BASADO EN LA ESPECIFICACIÓN DE FEATURES DE OGC. FIGURA 5: MODELO DE GEOMETRÍAS DE LA ESPECIFICACIÓN OGC.

20 IGURA 6: DIAGRAMA DE CLASES DE ACCESO A DATOS.

21 FIGURA 7: DIAGRAMA ERD DEL ESQUEMA RELACIONAL DESCRITO.

22 FIGURA 8: ESQUEMA DE FUNCIONAMIENTO DEL ALGORITMO DE INDEXACIÓN ESPACIAL QUADTREE. FIGURA 9: ESQUEMA DE FUNCIONAMIENTO DEL ALGORITMO DE INDEXACIÓN ESPACIAL RTREE. FIGURA 10: ARQUITECTURA GENERAL DEL SIIA.