Contenidos - Universitat Jaume Icanut/books/libroAvancesIDE.pdf · en marcha la Infraestructura de...

Avances en las infraestructuras de datos espaciales 5

Contenidos

Prólogo 7

Introducción M. Gould, C. Granell 11

La infraestructura de datos espaciales de España (IDEE): un proyecto colectivo y globalizado A. Rodríguez Pascual, P. Abad Power, J. A. Alonso Jiménez, A. Sánchez Maganto 15

Proceso de transformación de webEIEL en un nodo de la red de IDEs (ideAC). Estado actual y actuaciones de futuro N. R. Brisaboa, P. A. González, M. Lorenzo, M. R. Luaces 31

El papel de Dublin Core en el desarrollo de las infraestructuras de datos espaciales F. J. Zarazaga-Soria, J. Nogueras-Iso, E. Méndez-Rodríguez, R. Tolosona-Calasanz, P. R. Muro-Medrano 51

Medidas para impulsar la utilización del núcleo español de metadatos (NEM) D. Ballari, A. Sánchez Maganto, J. Nogueras-Iso, A. Rodríguez Pascual, M. A. Bernabé Poveda 61

Contribuciones de una IDE a la e-Ciencia: proyecto AWARE C. Granell, L. Díaz, M. A. Esbrí, M. Gould, A. Lladós 73

Unidades administrativas, una perspectiva ontológica J. Lacasta Miguel, F. J. López Pellicer, J. Floristán Jusué, J. Nogueras-Iso, F. J. Zarazaga-Soria 85

Ingeniería ontológica: el camino hacia la mejora del acceso a la información geográfica en el entorno web L. M. Vilches Blázquez, A. F. Rodríguez Pascual, M. A. Bernabé Poveda 95

6 Avances en las infraestructuras de datos espaciales

IDEZar: procesos, herramientas y modelos urbanos aplicados a la integración de datos municipales procedentes de fuentes heterogéneas F. J. López Pellicer, P. Álvarez, P. R. Muro-Medrano 105

IDENA: novedades y líneas de futuro P. Echamendi, S. Fontano, M. Cabello, M. A. Jiménez de Cisneros 115

Integración de los municipios en la IDE regional. Primeros resultados y conclusiones J. Guimet 125

IDERioja, despliegue de servicios IDE en el ámbito de la Administración local G. López García, R. Corredor Fernández, P. Martínez Pérez 137

gvSIG: un cliente avanzado para las infraestructuras de datos espaciales A. Anguix Alfaro, L. W. Sevilla Muelas, G. Carrión Rico 147

GeoBovino: un ejemplo de geo-trazabilidad M. A. Manso Callejo, M. Núñez Jiménez 159

PostGIS en producción cartográfica: CartoCiudad M. M. Gamo, M. A. Manso Callejo 171

Análisis de los servicios WMS disponibles: hacia un conjunto de recomendaciones para su implementación P. Abad Power, A. Rodríguez Pascual, J. A. Alonso Jiménez, A. Sánchez Maganto, L. M. Blázquez Vilches 180


Prólogo

Estamos viviendo un cambio de paradigma que afecta a la información geográ-fica. Este cambio comenzó hace una década y desde entonces no ha dejado de ace-lerarse: se está pasando del paradigma del suministro de datos geográficos al de los servicios basados en la información geográfica.

Pero hasta ahora este cambio se veía frenado por los problemas y coste que su-pone la dificultad de identificar y localizar la información existente, la necesidad de asegurar que se cuenta con los datos geográficos de referencia adecuados para referir a ellos los restantes datos espaciales a manejar, los problemas para integrar en el sistema informático de la organización receptora los datos geográficos extraí-dos de la organización suministradora y la falta de seguridad en la calidad y ade-cuación de los datos geográficos disponibles. Resolver esto supone posibilitar la dinámica económica que generará el importante mercado potencial del valor añadi-do sobre los datos geográficos.

El cambio que supone el paso al paradigma de servicio lo posibilita el estable-cimiento de las Infraestructuras de Datos Espaciales, entendidas como estructuras integradas por datos georreferenciados, organizados en bases de datos, y distribui-dos en diferentes sistemas de información geográfica, accesibles vía Internet con un mínimo de protocolos y especificaciones normalizadas que, además de los datos y sus descripciones (metadatos), incluye las tecnologías de búsqueda y acceso a dichos datos, las normas para su producción, gestión y difusión, así como los acuerdos entre sus productores y entre éstos y los usuarios. La necesidad de basarse en normas y especificaciones comunes, y de llegar a acuerdos que permitan la in-teroperabilidad, aconseja tener en cuenta, y coordinarse con, otras actuaciones equivalentes a cualquier nivel.

En el caso de España, para establecer una Infraestructura Nacional de Datos Es-paciales que fuera de todos los productores, integradores y usuarios de datos espa-ciales españoles, era preciso considerar que los principales productores de informa-ción geográfica en España son órganos y organismos de las Administraciones pú-blicas, tanto de la Administración General del Estado como de las Administracio-nes autonómicas y locales, y todos esos productores de información geográfica participan en el Consejo Superior Geográfico. Por tanto, se consideró que el Conse-jo Superior Geográfico era el órgano adecuado para plantear, acordar y definir una propuesta dirigida al establecimiento de la Infraestructura Nacional de Datos Espa-ciales en España. De esta forma, la Comisión Permanente del Consejo Superior Geográfico constituyó, entre sus comisiones técnicas, una de Geomática a la que asignó el cometido de definir y desarrollar la Infraestructura Nacional de Datos


Espaciales, que constituye el foro adecuado para desarrollar los trabajos técnicos que, mediante propuestas y aprobación por el Consejo, van definiendo y poniendo en marcha la Infraestructura de Datos Espaciales de España (IDEE).

El avance de IDE en sus cuatro años de vida ha sido espectacular. Desde 2004 está operativo un sitio web de la Internet, organizado conforme a las normas y es-pecificaciones de una IDE, y mantenido por el Instituto Geográfico Nacional, como Secretaría Técnica del Consejo Superior Geográfico, para facilitar la búsqueda de la información y el acceso de los usuarios en general a los datos, distribuidos en servidores repartidos por toda España. Este sitio web constituye el geoportal nacio-nal www.idee.es, y su objetivo es poner a disposición de cualquier usuario la in-formación georreferenciada que precise y esté disponible a partir de cualquier pro-ductor oficial. Para ello la IDEE se desarrolla colectivamente, y se constituye me-diante el conjunto de Infraestructuras de Datos Espaciales con todos los datos ofi-ciales disponibles relativos al territorio nacional, especialmente de aquellas que se han desarrollado, paralelamente y perfectamente integradas en la nacional, en los ámbitos territoriales de las comunidades autónomas y de las entidades locales. Ac-tualmente 20 servidores de datos, integrados en dichas infraestructuras autonómi-cas (10), locales (3) o sectoriales (7), son accesibles a través del geoportal IDEE, y el crecimiento del número de accesos y utilización de los servicios asociados ha sido muy importante.

Otros países y regiones, europeos o de otros continentes, están desarrollando, o tienen ya completamente operativas sus infraestructuras, pero en Europa la Comi-sión Europea promovió una Infraestructura de Datos Espaciales (INSPIRE) con el objeto de conseguir fuentes armonizadas de información geográfica para dar sopor-te a la formulación, implementación y evaluación de políticas comunitarias me-dioambientales a partir de las bases de datos a nivel local, regional y nacional de los Estados miembros.

Para obligar a, y coordinar, el desarrollo colectivo de esta infraestructura de da-tos europea y, como paso clave y previo para esto, de las infraestructuras naciona-les correspondientes, la Comisión Europea ha propuesto al Consejo de la Unión Europea y al Parlamento Europeo la aprobación de la directiva europea INSPIRE. La tramitación de esta directiva se encuentra, en este momento, en el proceso de code-cisión entre el Grupo de Estudio sobre Medio Ambiente del Consejo de Europa y la Comisión de Medio Ambiente, Salud Pública y Seguridad Alimentaria del Parla-mento Europeo, y es esperable, y desde luego deseable, que el texto definitivo reci-ba la aprobación conjunta antes del año 2007. A partir de su aprobación los Estados miembros contarán con un plazo de dos años para transponer la directiva a sus legislaciones respectivas.

En consecuencia, aún cuando el avance en las infraestructuras de datos espacia-les es espectacular, tal como queda de relieve a través del contenido de la presente publicación, no debemos relajarnos en el desarrollo y perfeccionamiento de todos los aspectos de las infraestructuras de datos espaciales. Y debemos asegurar que estas se organizan, e integran, en todos los niveles. Por esta razón, una publicación como esta, que recoge los avances en las infraestructuras de datos espaciales, tiene


un valor indudable y debe constituir una referencia para todos los interesados en el desarrollo o utilización de esta tecnología.

Sebastián Mas Mayoral PRESIDENTE DE LA COMISIÓN DE GEOMÁTICA DEL CONSEJO SUPERIOR

GEOGRÁFICO


Introducción

El presente libro recoge una muestra de las comunicaciones técnicas presenta-das en las III Jornadas Técnicas de la Infraestructura de Datos Espaciales de Es-paña, JIDEE’06, celebradas en nuestra universidad entre los días 18 y 20 de octu-bre de 2006. Su objetivo es presentar algunos de los avances reales de una comuni-dad de IDE (la española) aunque esperamos que el libro también llegue a las manos de muchos lectores en América Latina, donde seguramente las experiencias espa-ñolas van a ser igual de útiles.

Queremos iniciar este libro expresando nuestra gratitud a varios colaboradores por su ayuda en hacer realidad esta publicación. La Fundació Bancaixa-Castelló ha subvencionado el coste de la edición e imprenta. Algunos miembros del comité científico de las III Jornadas han revisado los manuscritos iniciales (resúmenes), facilitando su posterior extensión y aceptación para ser incluidos en el libro. El profesor Miguel Chover Sellés, de la Universitat Jaume I, ha facilitado la publica-ción en su papel de director de la colección “Treballs d'Informàtica i Tecnología”. También queremos agradecer al Instituto Cartográfico Valenciano (ICV) por pro-porcionar la imagen que aparece en la portada de este libro. Y por supuesto, agra-decemos el esfuerzo de los autores por su atención a los detalles y por cumplir con las fechas impuestas. Gracias a todos los colaboradores.

Estado de las IDE El título del libro, que no coincide con el de las Jornadas, ha sido elegido expre-

samente para subrayar el hecho que nuestra comunidad haya avanzado sustancial-mente en los últimos años. Ya no hay tanto discurso acerca de cómo definir una IDE (aunque algunas definiciones siguen ignorando el componente clave de la cola-boración institucional), ni tampoco sobre las razones para construir una IDE, ni sobre los detalles de cómo cada región o administración está construyendo la suya. En [1] y en otros muchos repasos al estado de la cuestión, ha quedado claro que una IDE es sobre todo colaboración entre entidades de la Administración. El discur-so actual, reflejado en este libro, ha pasado por esa primera fase, para tratarse hoy en día de cómo crear aplicaciones IDE de más alto nivel, en términos de servicios de valor añadido, y no sólo del acceso básico a los geodatos. También hay un buen intercambio de opiniones y experiencias sobre como migrar antiguos sistemas –antes SIG corporativo– a las nuevas arquitecturas y métodos IDE.


El contenido de este libro se estructura en cuatro secciones. La primera sección

contiene cinco capítulos de carácter variopinto sobre las IDE. El primero describe la situación actual de la Infraestructura de Datos Espaciales en España (IDEE). En el segundo se analizan detalladamente las experiencias obtenidas durante el proceso de migración y evolución de las IDE regionales. Cuestiones sobre metadatos y del Núcleo Español de Metadatos (NEM) se plantean en los siguientes dos capítulos. Por último, el capítulo cinco sugiere oportunidades de sinergia y retos de futuros entre las IDE y la e-Ciencia.

Los problemas relativos a la semántica y ontologías se abordan en la segunda sección, con dos capítulos que analizan el uso de las ontologías para mejorar la descripción y la posterior localización y acceso a la información geográfica.

Los siguientes cuatro capítulos son un ejemplo representativo, de entre otros tanto en España, sobre las experiencias en la implantación de IDE regionales y loca-les. En cada uno de ellos se presenta el proceso de evolución, transformación, ex-periencias, opiniones, problemas encontrados, y puesta en marcha de una IDE con-creta desde diferentes perspectivas, tanto en el ámbito regional como local.

Finalmente, los últimos cuatro capítulos de este libro describen aplicaciones de más alto nivel que utilizan y aprovechan los recursos de una IDE. Se pueden encon-trar aplicaciones desde la presentación de un cliente avanzado para la IDE, varias aplicaciones basadas en servicios web que aportan servicios de valor añadido al cliente, así como recomendaciones y buenas prácticas para la puesta en marcha de servidores de mapas.

Los avances presentados en el libro han sido tan rápidos como notables. En Es-paña empezamos relativamente tarde en este proceso global (IDE nacionales) que lleva en marcha más de una década (Masser [2] habla de once IDE nacionales ya en marcha en 1996), sin embargo (¡esta vez!) no ha sido demasiado tarde. Hemos visto como algunos países europeos que empezaron bastante más pronto, quizás demasiado pronto, no han podido mantener el momentum, por lo que todavía no han mostrado mayores resultados y logros que los que muestra España con bastan-tes años menos trabajados y de experiencia. La comunidad internacional ahora reconoce a España como un caso de buena práctica a seguir en materia de las IDE. Parece ser que esta vez no hemos llegado completamente tarde sólo para mirar como nos pasa la última ola de innovación. Mas bien esta vez hemos caído justo en la cresta de la ola. Pero hay que estar atentos y no descuidar la ventaja. Muchos de los éxitos conseguidos en España durante los últimos 3 o 4 años, han sido básica-mente implementaciones de las ideas de otros: principalmente siguiendo normas OPENGIS e ISO. Pero, y cuando todas la entidades administrativas ya tengan su WMS, WFS y demás servicios, y su metodología de creación de metadatos funcio-nando… ¿Entonces qué? ¿La infraestructura es el fin, o el vehículo hacía otros fines más importantes? ¿Cuáles serán los beneficios económicos y sociales? ¿Los ciudadanos notarán alguna diferencia real?.


El futuro Es nuestro deber como académicos no estar contentos con el status quo en nin-

gún campo de la I+D, sino de analizar con ojo crítico y plantear posibles líneas de investigación con finalidad de mejorar la situación actual. Aunque en términos informáticos una década es una eternidad, en términos reales el campo de las IDE es un campo joven, de moda, y está dando algunos resultados muy interesantes en poco tiempo, como muestran los trabajos publicados en este libro. Pero el futuro estará lleno de descubrimientos y desarrollos más allá que la mera conectividad de servidores y clientes. La revista profesional International Journal of Spatial Data Infrastructure Research (IJSDIR, http://ijsdir.jrc.it) acaba de estrenarse, editada por el Centro Europeo de Investigación (JRC). En el primero número su editor [3] pinta con líneas muy gruesas, el panorama de temas de investigación de futuro en el campo de las IDE. Dos de estos temas, cooperación institucional y metadatos, han sido rematados por [4] y [5]. Otro tema prioritario a medio plazo es la resolución de numerosos problemas semánticos [6].

Ha sido un placer editar la presente publicación de avances en IDE, y estamos a la espera de muchos avances más. La creación de IDE y sus servicios de alto nivel correspondientes, solo ha empezado.

Michael Gould y Carlos Granell UNIVERSITAT JAUME I

Referencias [1] M. Gould y C. Granell, “Fundamentos tecnológicos y políticos para la

creación de Infraestructuras de Datos Espaciales”, C. Conesa (ed.) Tecnologías de la Información Geográfica: Territorio y Medio Ambiente, Universidad de Murcia, pp. 87-98, 2005.

[2] I. Masser, “All shapes and sizes: the first generation of National Spatial Data Infrastructures”, International Journal of Geographic Information Science, vol. 13, pp. 67-84, 1999.

[3] M. Craglia, “Introduction to the International Journal of Spatial Data Infrastructures Research” (editorial), International Journal of Spatial Data Infrastructures Research, vol. 1, pp. 1-13, 2006.

[4] I. Masser, 2006. “What’s special about SDI related research?” (editorial), International Journal of Spatial Data Infrastructures Research, vol. 1, pp. 14-23, 2006.


[5] M. Gould, J. Rocha, S. Nativi, M. A. Manso y J. Nogueras, “Near-term

metadata challenges”, XII Taller EC-GI & GIS, Innsbruck (Austria), 2006. http://www.ec-gis.org/Workshops/12ecgis/presentations/Seminar room/THU_ MD_CAT/ gould.pdf.

[6] W. Kuhn, “Geospatial Semantics: Why, of What, and How?”, Journal on Data Semantics, Lecture Notes on Computer Science 3534, pp. 1-24, 2005.


La infraestructura de datos espaciales de España (IDEE): un proyecto colectivo

y globalizado

A. Rodríguez Pascual†, P. Abad Power†, J. A. Alonso Jiménez†, A. Sánchez Maganto†

† Instituto Geográfico Nacional

Calle General Ibáñez de Ibero, 3, 28003, Madrid e-mail: [email protected]

Resumen

En los últimos años, el sector de la Información Geográfica (IG) ha experimen-tado un importante cambio de paradigma: desde los Sistemas de Información Geo-gráfica (SIG) se ha evolucionado a las Infraestructuras de Datos Espaciales (IDE). Este nuevo concepto incluye un conjunto de datos, servicios, metodologías, nor-mas, estándares y acuerdos, que permiten visualizar, superponer, consultar y anali-zar la IG publicada en Internet, según estándares bien definidos, por un conjunto de productores de datos y servicios geográficos. De esta manera se consigue compartir recursos fácilmente y la interoperabilidad y libre sinergia entre los diversos siste-mas implementados por los agentes implicados.

Tan interesante línea de trabajo ha atraído a grandes corporaciones privadas, que han irrumpido en escena con soluciones no estándar, funcionalidades inspira-das en la tecnología IDE y prestaciones espectaculares.

Para completar el cuadro, se espera la aprobación a finales de este año 2006 de la propuesta de directiva europea INSPIRE, para la implementación de una IDE euro-pea.

En esta comunicación se presentan diversos aspectos de la IDE de España, pro-yecto coordinado por el Consejo Superior Geográfico, insertado en el panorama descrito como iniciativa española colectiva, basada en la libre cooperación de todos los actores del sector. Se describen su filosofía, concepción y arquitectura, los componentes que la integran, el estado actual de desarrollo y las perspectivas futu-ras.

Palabras clave: infraestructuras de datos espaciales, información geográfica, Open Geospatial Consortium, servicios, interoperabilidad, globalización, cartografía, INSPIRE.


1. Introducción Decimos que las Infraestructuras de Datos Espaciales (IDE) constituyen un nue-

vo paradigma, en el sentido de Thomas S. Kuhn [1], en el campo de la Geomática, como amplio concepto que incluye todo lo que puede considerarse como gestión de Información Geográfica (IG), porque suponen un cambio sin vuelta atrás en los principios fundamentales, métodos de trabajo, resultados, e incluso en la difusión y utilización de resultados.

En realidad, denominar paradigma a las IDE es un ejercicio de sinécdoque, de llamar a la parte por el todo. Lo que sí que constituye un nuevo marco conceptual es la globalización, o más bien episteme, “conjunto de suposiciones, prejuicios y mentalidades que estructuran y limitan el pensamiento de una época y que da lugar a una forma de conocimiento y a un discurso”, concepto acuñado por Foucault [2].

La globalización como gran cambio social y cultural, llegado de la mano de los avances en las tecnologías de las comunicaciones y muy especialmente Internet, que intercomunica con tal eficacia todos los rincones de nuestro mundo, que ha transformado radicalmente todas las esferas de la actividad humana, y en particular la gestión de IG.

Tal y como expone Thomas Friedman en su texto La Tierra es plana, la caracte-rística esencial de nuestro mundo globalizado es la desaparición de todo tipo de barreras, la más significativa de las cuales fue el muro de Berlín, cuya caída en 1989 constituye el acto inaugural de la aldea global en que vivimos [3].

Volviendo a la información geoespacial, estamos pasando de los SIG, considera-dos como modelos del mundo real construidos para satisfacer unas demandas de información muy concretas y específicas, es decir, sistemas que tienden de modo natural a la especialización, sistemas concentrados; a las IDE, como sistemas basa-dos en la apertura de servicios estandarizados, accesibles a través de la red, que proporcionan una infraestructura libre y generalista, que tienden a la máxima difu-sión, aprovechable por todo tipo de usuarios para sus fines particulares.

Por decirlo de otra manera, del SIG egoísta, cuyo fin es resolver una serie de consultas que demanda una organización, de modo optimizado y eficaz, a la IDE altruista, donde un gran número de actores colaboran en implementar servicios públicos o fácilmente accesibles para la comunidad, en una dinámica de colabora-ción basada en la confianza, que permite construir una infraestructura de la que todos resulten beneficiarios.

Ya no tiene tanto sentido el atesorar datos geográficos como algo valioso, de uso restringido y también calidad poco contrastada, en un entorno de especialistas expertos en tecnologías herméticas. Lo que prima es abrir los sistemas, compartir el acceso y el uso de tales datos, permitiendo su comparación pública, en entornos abiertos, amigables y usables que permitan al usuario acceder a un conjunto cre-ciente de funcionalidades sin exigirle un alto grado de especialización.

No en vano la interoperabilidad se define como la capacidad para comunicar, ejecutar o transferir datos entre varias unidades funcionales de tal manera que el


usuario no necesite tener ningún conocimiento o muy poco sobre las características particulares de tales unidades [4].

El concepto central, alrededor del que se estructura toda la tecnología, ya no son los datos, alma y centro de los SIG que consumían la mayor parte de los recursos invertidos, sino los servicios que permiten que la sociedad en su conjunto amortice las inversiones realizadas en la generación de datos y en el establecimiento de sis-temas de información.

2. Filosofía y objetivos de la IDEE Tal y como se ha descrito ya en varios foros [5], y en completa sintonía con los

objetivos y concepción de la iniciativa INSPIRE, los objetivos a los que atiende la implementación de la IDE de España se pueden aglutinar en torno a cuatro puntos:

1) Facilitar que las Administraciones públicas compartan de manera eficaz la

IG que gestionan para evitar duplicidades de esfuerzo, amortizar las inver-siones realizadas y garantizar que todos sus estamentos utilicen un núcleo común de conjuntos de datos geográficos básicos, los llamados datos de re-ferencia.

2) Contribuir a la administración electrónica (e-government), de manera que toda gestión burocrática en la que intervenga un plano o un documento car-tográfico cualquiera pueda ser automatizado sin que la información espa-cial suponga una rémora.

3) Poner a disposición del ciudadano toda la IG gestionada por las Adminis-traciones públicas a través de servicios IDE libres, abiertos y gratuitos, por lo menos en cuanto a búsqueda en el catálogo y visualización.

4) Un último objetivo es ampliar la IDE al sector privado y al público en gene-ral, no sólo poniendo a su disposición datos y servicios geográficos, sino también brindándoles la posibilidad de publicar sus datos espaciales, y sus servicios si así lo desean, en la IDEE, distinguiendo claramente lo que son datos de referencia, cuya fiabilidad está garantizada por un organismo ofi-cial, de otros datos, cuya fiabilidad será directamente proporcional de la fiabilidad de la organización productora de los datos. Si alguien desea inte-grar información en la IDEE tendría que cumplir ciertos requisitos mínimos de normalización y armonización.

En ese sentido, además de que el proyecto IDEE sigue la filosofía y directrices

de la propuesta de directiva INSPIRE [6], y es conforme a las especificaciones OGC y a la familia de normas ISO 19100, está alineado con las iniciativas, proyectos y disposiciones legales, que abogan por promover la libre circulación de la informa-ción, y que reconocen el derecho de los ciudadanos a acceder a los datos que ges-tionan las instituciones públicas:


• Directiva Europea PSI (Public Sector Information) 2003/98/CE [7] sobre la

reutilización por parte de la sociedad de la información que gestiona el sec-tor público.

• Convención de Aarhus [8], que establece el derecho de los ciudadanos a acceder a la información gubernamental relativa al Medio Ambiente y a participar de alguna manera en la toma de decisiones que lo afecten.

• Iniciativa Open Access de Budapest [9], firmada por más de 200 Universi-dades, Bibliotecas y Centros de Investigación de todo el mundo, que pro-mueve la publicación electrónica de revistas de investigación que den la máxima publicidad posible, mediante mecanismos más rápidos y ágiles que las tradicionales revistas científicas, a los resultados y conclusiones de proyectos de investigación.

• Iniciativa Open Archives [10], dirigida a definir especificaciones estándar para hacer interoperables y fácilmente accesibles vía Internet los archivos y catálogos de metadatos relativos a documentación científica, con el ánimo de contribuir a la libre circulación de la información.

Parafraseando a Jimmy Wales, el fundador de la Wikipedia, nuestro objetivo úl-

timo es proporcionar a cada persona del planeta una suerte de “SIG simple” o ele-mental, que le permita al menos buscar, ver y consultar datos geográficos disponi-bles, utilizando sólo una conexión a Internet y un navegador (cliente ligero).

Sin excluir el que para realizar análisis complejos sea necesario, por razones de eficacia, el disponer de un cliente pesado, de un software SIG en local que haga uso de servicios OGC, o incluso en ciertas ocasiones, también por criterios de eficacia y rendimiento, proceder a la descarga de los datos geográficos para su procesamiento en local (clientes muy pesados). De esta manera se conseguiría un balanceo de la carga que supone cada proceso entre el servidor y el cliente, para obtener en cada situación el rendimiento más adecuado.

Sabemos que, al menos en apariencia, esta aproximación choca con la protec-ción de los derechos de autor y de los derechos de propiedad intelectual (PRI) a los que pueden estar sujetos los datos.

Sin embargo, varios autores han expuesto serias dudas por un lado, sobre si ta-les derechos existen al tratarse de datos cartográficos, que son una representación o un registro de hechos, y no estar los hechos sujetos a este tipo de derechos [11]; y por otro lado, sobre hasta qué punto una autoridad pública puede invocar los PRI para limitar el acceso de los ciudadanos a unos datos recogidos en el ejercicio de sus funciones, y financiados en su mayor parte con los impuestos de esos mismos ciudadanos [12].

El problema real es que hay un gran número de entidades que difunden carto-grafía y datos geográficos siguiendo un modelo de financiación basado en las ven-tas, y el proceso a seguir para modificar leyes, decretos, estatutos, normas y buro-cracia para que los gobiernos cambien esta situación es normalmente largo, com-plejo y proceloso.


Por otro lado, hay que tener en cuenta que el planteamiento del texto original de la propuesta de directiva INSPIRE [6] propone la implementación de servicios gra-tuitos de catálogo y visualización, y deja abierta la posibilidad de establecer servi-cios de descarga de datos gratuitos, de bajo coste o comerciales, lo que supone una gran flexibilidad para acomodar la situación de cada país miembro y de cada sec-tor.

3. Organización de la IDEE La Infraestructura de Datos Espaciales de España (IDEE), es un proyecto coordi-

nado por el Consejo Superior Geográfico (CSG), órgano colegiado en el que están representados los productores de datos geográficos digitales de referencia (en el sentido INSPIRE) de ámbito nacional y autonómico (Instituto Geográfico Nacional, Servicios Cartográficos del Ejército, Ministerio de Medio Ambiente, Ministerio de Agricultura, Institutos Cartográficos y Servicios de Cartografía de las Comunida-des Autónomas) cuya presidencia ejecutiva y secretaría técnica desempeña el Insti-tuto Geográfico Nacional.

El CSG definió en noviembre de 2002 un grupo de trabajo para la IDEE, como grupo abierto a todos los actores relevantes (Administraciones públicas de ámbito nacional, regional y local, universidades, empresas privadas, etc.), para el inter-cambio de ideas y experiencias y para establecer por medio del consenso las reglas y acuerdos, en forma de recomendaciones, necesarios para la implementación de una IDE en España, abierta y eficaz, de acuerdo con las directrices marcadas por INSPIRE y siguiendo las especificaciones de interoperabilidad de Open Geospatial Consortium (OGC), antes Open GIS Consortium.

Las principales recomendaciones consensuadas hasta ahora dentro del GT IDEE son:

• El Núcleo Español de Metadatos (NEM) versión 1.0 [13], como conjunto

mínimo de ítems de metadatos recomendado, definido como un perfil de ISO 19115, que comprende el núcleo dicha norma ISO 19115, más los ítems necesarios para tener en cuenta Dublín Core Metadata, los metadatos con-templados en la Directiva Marco del Agua y la descripción de la calidad.

• Una guía de usuario del NEM versión 1.0, que establezca los criterios bási-cos para rellenar los campos del NEM.

• Definición de un conjunto de servicios mínimos recomendados a imple-mentar en cualquier IDE que se pretenda integrar en la IDEE, y que incluye básicamente servicio de catálogo, servicio de publicación de mapas (Web Map Service, WMS) y servicio de nomenclátor (Gazetteer).

• Establecimiento de unas directrices sobre arquitectura que definan el papel que debe jugar cada componente en su ámbito de actuación y las corres-pondientes responsabilidades escalonadas, para asegurar que no existen zonas de sombra en el funcionamiento de la IDEE.


• Modelo de Nomenclátor de España (MNE) versión 1.0 [14], como modelo

de datos común para topónimos que se vayan a utilizar como base para im-plementar servicios de Gazetteer, con las ventajas que supone para armoni-zación, intercambio y gestión distribuida de nombres geográficos.

• Recomendación para la implementación de servicios WMS, en la que se fi-jan una serie de criterios básicos, como una nomenclatura común y están-dar para las capas en el primer nivel o un sistema de coordenadas común que se recomienda soportar.

4. Estado actual del proyecto El geoportal de la IDEE (véase figura 1), abierto en el verano del año 2004, está

basado en software desarrollado por la Universidad de Zaragoza en el marco de un convenio de colaboración con el Instituto Geográfico Nacional. Ofrece cinco servi-cios OGC: servicio de mapas en la web (WMS), servicio de catálogo (CSW), servicio de nomenclátor (WFS-MNE [13]), servicio de contexto (WMC), servicio de fenóme-nos (WFS), y servicio de coberturas (WCS).

Integra un total de más de 28 servidores que ofrecen servicios, y permite el ac-ceso a más de 560 capas de información disponible, ofrecidas por instancias guber-namentales en los tres ámbitos, estatal, regional y local, universidades, empresas privadas, etc.

Presenta una interfaz en cinco idiomas (español, inglés, vasco, catalán y galle-go), que está previsto ampliar con sendas versiones en portugués y francés para facilitar la interoperabilidad semántica con los servicios de los países vecinos.

4.1. Datos disponibles A través de los servicios WMS fácilmente integrables en la IDEE, es posible ac-

ceder a la visualización y consulta de una gran abanico de datos de distinta proce-dencia, temática y resolución (véase figura 2).

A nivel estatal, tenemos: • La información de las bases cartográficas numéricas del Instituto Geográfi-

co Nacional, a las escalas 1:1.000.000, 1:200.000 y 1:25.000, así como los Modelos Digitales de Terreno (MDT), datos complementarios (cuadrículas, división administrativa, vértices geodésicos), datos temáticos (Corine-Land Cover, mapas de geomagnetismo, sismología, gravimetría) y una buena parte del Atlas Nacional de España.


Figura 1. Página principal del Geoportal IDEE

• El catastro de prácticamente todo el territorio nacional, a las escalas

1:1.000 y 1:500 para el catastro urbano y a las escalas 1:5.000 y 1:2.000 para el caso rústico, publicado en Internet por la Dirección General de Ca-tastro para toda España, excepto Navarra y País Vasco, comunidades autó-nomas que tienen esa competencia transferida y publican por sí mismas y en sus servicios de mapas tal información.

• Información del mapa geológico de España a escala 1:1.000.000 elaborado por el Instituto Geológico y Minero de España.

• Las unidades estadísticas, por debajo del ámbito municipal (distritos censa-les y secciones censales), definidas y mantenidas por el Instituto Nacional de Estadística.

• Antes de que acabe el presente año 2006, está prevista la apertura de las In-fraestructuras de Datos Espaciales de los Ministerios de Fomento y Medio Ambiente, y además, el Fondo Europeo de Garantía Agraria (FEGA) está estudiando la puesta en funcionamiento de un servicio de mapas que publi-que las ortofotos del SIGPAC, que recubren toda España con un metro de re-solución y algunas zonas con medio metro.


Figura 2. Superposición de cartografía del IGN 1:25.000 sobre (de izquierda a derecha y de arriba abajo): cartografía 1:5.000, catastro, callejero municipal y ortofoto, servida por

IDENA (IDE de Navarra) y por la IDE de Pamplona

A nivel regional, existe un gran número de iniciativas que ya han implementado

o están trabajando para implementar en breve, en unos casos servicios interopera-bles que den visibilidad a su cartografía, y en otros casos geoportales e Infraestruc-turas de Datos Espaciales Regionales, tan interesantes como las de Cataluña, Nava-rra, País Vasco, La Rioja, Galicia, Castilla y León, Valencia, Castilla-La Mancha, Andalucía y Murcia. En cualquier caso, todas las comunidades autónomas sin ex-cepción están trabajando muy activamente en esta línea y constituye uno de los activos más importantes de la IDEE el empuje que ha supuesto la impresionante constelación de proyectos en este ámbito de la administración y su alto nivel tecno-lógico.

En el ámbito local, podemos citar como ejemplos pioneros y notables la IDE del Ayuntamiento de Zaragoza (IDEZar), la IDE de Pamplona y el proyecto IDE local de Cataluña que integra en la IDEC (IDE de Cataluña) a 50 municipios en su primera fase. También aquí hay varios proyectos en marcha que tendrán visibilidad a corto plazo y un buen número de ayuntamientos están muy interesados en abrir su geo-portal IDE.


A nivel temático, existe ya un notable conjunto de aplicaciones y geoportales que utilizan servicios interoperables y que se apoyan en los servicios WMS existen-tes o que publican datos de referencia: el Atlas Climatológico de la Península ibéri-ca desarrollado por la Universidad Autónoma de Barcelona; la IDE de Costas, inte-grada en la IDE de Cataluña; la IDE del Parque Nacional de Doñana; el geoportal de IMEDEA (Instituto Mediterráneo de Estudios Avanzados) del Gobierno de las Islas Baleares; el proyecto Anthos del Real Jardín Botánico de Madrid, con un inventa-rio de más de un millón de especies florales y su distribución espacial sobre carto-grafía de referencia; el geoportal del Jardín Botánico de Lisboa, también con un notable catálogo de especies vegetales acompañadas de su distribución geográfica; Atlas Temático de Distribución de Aves Zonas Cinegéticas de España; y un largo etcétera que incluye un gran número de proyectos que surgen día a día en todos los sectores de aplicación y que están llevando la tecnología IDE prácticamente a todos los ámbitos de la actividad humana.

4.2. Servicios básicos El geoportal IDEE ofrece los tres servicios básicos de una IDE: servicio de mapas

en la web (WMS 1.1.0), nomenclátor (WFS con el MNE [13]) y servicio de catálogo en la web (CSW 2.0), integrados en un visualizador que permite su encadenamiento de modo transparente para el usuario.

El visualizador del geoportal de la IDEE, presenta además algunas funcionalida-des interesantes:

• Imprimir la cartografía que se ve en cada momento en pantalla, utilizando

un marco estándar, cierta información marginal (leyenda, título, escala y rosa de lo vientos) y un mensaje que informa de la procedencia de los da-tos.

• Guardar la imagen que se está mostrando en el visualizador en un momen-to determinado en una variedad de formatos que incluye los más utilizados (JPG, PNG, GIF).

• Superponer interactivamente un servicio de mapas (WMS) del que conoce-mos su dirección URL o uno de los definidos por defecto en el menú habili-tado para añadir servidores.

• Modificar el sistema de referencia y la proyección en que cada servidor WMS ofrece la cartografía, eligiendo uno entre los que ofrece el servicio en cuestión.

• Funcionalidades para una correcta visualización de servicios WMS super-puestos: modificar el estilo de un servicio WMS o de una capa, escogiendo entre opaco, transparente y semitransparente; y modificar la prioridad de visualización entre los WMS activos, eligiendo cuál se ha de ver más arriba y cuál más abajo.


Por otro lado, en la IDEE se ofrece un catálogo de servicios que funciona de ma-

nera muy simple, aunque no de acuerdo a ninguna especificación Open Geospatial Consortium: sencillamente muestra en pantalla un inventario de los servicios dis-ponibles y sus principales características, efectuando llamadas en el momento a los servidores de tales servicios, con la función GetCapabilities, que informa de lo que ofrece un servicio en concreto, y mostrando las características devueltas por todos y cada uno de los servicios registrados en una lista a tal efecto (http://www. idee.es/recursos/servicios).

Por último, y aunque se trata de una solución no estándar, el geoportal de la IDEE dispone de una pasarela que permite superponer el servicio WMS básico, el mapa base, con las imágenes que ofrece la aplicación de visualización Google Earth, que ha sido desarrollada por expertos de la Dirección General del Catastro.

4.3. Servicios adicionales Más allá de los tres servicios básicos y fundamentales para una Infraestructura

de Datos Espaciales, el geoportal de la IDEE presenta la implementación de otros servicios y aplicaciones que cumplen los estándares OGC, siempre encadenados con al menos otro servicio del geoportal.

4.3.1. Web Map Context (WMC), que permite almacenar en cualquier momento un fichero en formato XML donde se recogen todos los parámetros (servicios invoca-dos, ámbito de visualización, enlaces activos, sistema de referencia utilizado, etc.) de una sesión en un momento determinado, de manera que el estado de la sesión puede reconstruirse en todos sus detalles en otro momento. Además al ser confor-me al estándar, es posible cargar el estado de la sesión en otro visualizador que tenga implementada esa funcionalidad de acuerdo a WMC.

4.3.2. Web Feature Service (WFS), en nuestro caso orientado a la descarga de da-tos, ofrece la obtención libre y abierta en formato GML (Geographic Markup Lan-guage) de:

• Los vértices geodésicos de las distintas redes geodésicas nacionales. • Una base de datos de toda España a escala 1:1.000.000, que constituye la

contribución española al proyecto europeo EGM (Euro Global Map), que integra datos de toda Europa a esa escala.

• La geometría de las unidades administrativas españolas (comunidades au-tónomas, provincias y municipios) a tres escalas, 1:1.000.000, 1:200.000 y 1:25.0000.

El objetivo es poner a libre disposición de usuarios, desarrolladores y producto-res de datos, los datos geográficos de referencia más utilizados, para que puedan ser utilizados como base de referencia común, que luego permita cruzar informa-


ción de distintos proyectos gracias a que el marco de referencia geométrico básico es el mismo.

4.3.3. Aplicación de análisis del CORINE, aplicación que permite efectuar un aná-lisis remoto en línea, ciertamente elemental, pero análisis al fin y al cabo, del Mapa de Cobertura del Suelo Corine-Land Cover, basado en un Web Feature Service (WFS). La aplicación permite visualizar los distintos niveles de detalle que incluye el Corine-Land Cover del municipio que se desee, visualizar los cambios produci-dos desde la primera versión (1990) hasta la vigente (2000), y obtener una estadís-tica del tanto por ciento de superficie municipal ocupada por un tipo o más de cu-bierta, a gusto del usuario. El interés de esta elemental aplicación de análisis super-ficial es que está basada en el estándar WFS y que realiza el análisis en tiempo real ante la petición de un usuario (véase figura 3).

4.3.4. Aplicación de análisis del Modelo Digital de Terreno, otro ejemplo senci-llo de análisis en línea realizado sobre el Modelo Digital del Terreno (MDT) 1:200.000 del IGN, basado en el estándar Web Coverage Service (WCS). La aplica-ción permite visualizar el MDT mediante una leyenda de tintas hipsométricas y cuando la escala de visualización es mayor de 1:100.000, es posible analizar los datos de MDT en el ámbito de visualización y obtener la cota más alta, la más baja y el valor medio. Como antes, el interés que pueda tener esta aplicación, es que es un ejemplo de análisis superficial en remoto.

4.3.5. Servicio temporal de mapas catastrales. Gracias a que la Dirección Gene-ral del Catastro ha implementado un servicio de mapas WMS que admite el paráme-tro TIME en la forma AAAA-MM-DD, el visualizador del geoportal es capaz de reali-zar llamadas sucesivas a ese servicio especificando dos fechas diferentes, y ofrecer el resultado de la superposición al usuario, con lo que es posible hacer un análisis visual de los cambios acaecidos en el período de tiempo transcurrido.

4.3.6. Pasarela Google Earth. La IDEE es además capaz de interoperar con el vi-sualizador Google Earth, aunque no se trate de un visualizados estándar OGC. Uti-lizando una pasarela desarrollada por un experto de la Dirección General del Catas-tro, es posible superponer un servicio WMS cualquiera que cumpla los estándares con la visualización ofrecida por Google Earth, y como ejemplo, en el geoportal IDEE hay sendos plug-in de libre descarga que permiten dicha superposición utili-zando los servicios de mapas de catastro y de la cartografía básica del IGN.


Figura 3. Visualización de los cambios 1990-2000 en el Corine-Land Cover

4.4. Últimos desarrollos

4.4.1. Visualizador libre para PDA. Aplicación freeware que estará disponible para su libre disposición en el geoportal de la IDEE, y permite acceder a los servi-cios estándares más usuales WMS y de nomenclátor desde plataformas PDA con un conjunto de funcionalidades simplificadas y adaptadas a dicho entorno de trabajo.

4.4.2. Navegador tridimensional. Plug-in que estará también disponible en las páginas web de la IDEE y que permitirá disfrutar de las funcionalidades típicas de un simulador de vuelo tridimensional, con la particularidad de que puede funcionar tomando como datos de entrada cualquier servicio WCS público, accesible y están-dar que publique un Modelo Digital del Terreno, y cualquier servicio WMS público, accesible y estándar, cuya información servirá como textura sobre la que realizar el vuelo virtual.

4.4.3. Nomenclátor de catastro. La Dirección General del Catastro, continuando con su línea de prestación de servicios públicos OGC, va a implementar un servicio


nomenclátor basado en la referencia catastral, y la aplicación cliente correspondien-te estará disponible en el geoportal de la IDEE.

4.4.4. Enlace con datos estadísticos. Consiste simplemente en enlazar la función GetFeatureInfo del servicio WMS, que permite seleccionar un punto en pantalla y obtener los atributos de ese punto que el servidor haya declarado como públicos y accesibles, para que en el caso de los servicios de mapas que publican la División Administrativa española, estructurada en comunidades autónomas, provincias, municipios, distritos y secciones censales, sea posible seleccionar cualquiera de estas unidades administrativas o estadísticas, y automáticamente se enlace con la página web del Instituto Nacional de Estadística (INE) que muestra los atributos asociados correspondientes. De esta manera se conseguirá relacionar la geometría de las unidades administrativas que gestiona el IGN con sus atributos alfanuméri-cos, gestionados por el INE.

4.5. Clientes pesados Para completar el panorama existente en España vale la pena mencionar la apa-

rición del proyecto de software libre gvSIG (www.gvsig.gva.es) [15] impulsado por la Conselleria de Infraestructuras y Transportes de la Generalitat Valenciana. Se trata de un cliente pesado SIG, capaz de acceder a un notable abanico de formatos de datos en local y utilizar al mismo tiempo servicios estándar WMS, WFS y WCS como fuente de datos para trabajar del modo habitual en un entorno SIG, con facili-dades de edición de datos, análisis vectorial y ráster, edición orientada al trazado en papel, etc.

4.6. Proyectos transfronterizos Como consecuencia del desarrollo en España de la iniciativa IDEE, entendida

como racimo de proyectos relacionados, varios de los agentes en ella implicados están participando en proyectos transfronterizos que utilizan tecnología OGC:

• El proyecto SDIGER [16], que consiste en el desarrollo de una Infraestructu-

ra de Datos Espaciales que gestione los datos geográficos relativos a la Di-rectiva Marco del Agua, en las cuencas hidrográficas del Ebro y del Adour-Garona, situadas en dos países distintos (España y Francia). Es un proyecto piloto para la implementación de INSPIRE, financiado por la Co-misión Europea a través de Eurostat, y adjudicado a un consorcio formado por IGN Francia, IGN Francia Internacional, la Universidad de Zaragoza y el Centro Nacional de Información Geográfica y en el que colaboran varios


organismos a ambos lados de la frontera, especialmente la Confederación Hidrográfica del Ebro y la Autoridad Hidrográfica del Adour-Garona.

• El proyecto OTALEX (Observatorio Territorial del Alentejo y Extremadu-ra), se encuadra bajo el paraguas del programa INTERREG III A, y tiene co-mo objetivo implementar una IDE que cubra ambas regiones, que sirva de instrumento para la protección del medio ambiente y su armonización con el también imprescindible desarrollo económico y social, dentro de la línea del ya acuñado internacionalmente desarrollo sostenible. En esta iniciativa participan la Junta de Extremadura, la Diputación de Badajoz, el Centro Nacional de Información Geográfica, el Instituto Geográfico de Portugal, la Comisión de Coordinación y Desarrollo Regional del Alentejo, las Aso-ciaciones de Municipios del Distrito de Évora y del Norte Alentejo, y una serie de organismos y entidades colaboradoras.

5. Perspectivas: difusión En el momento actual, y dado que el nivel tecnológico de la IDEE, creemos que

es bueno la siguiente etapa de desarrollo a cubrir ha de hacer énfasis en aspectos más organizativos que técnicos, y en concreto a la difusión.

Efectivamente, aunque la información accesible en el geoportal IDEE es abru-madora, y la oferta de servicios y funcionalidades es adecuada, todavía las cifras de tráfico del geoportal son relativamente moderadas; durante lo que ha transcurrido del año 2006, hemos tenido unas estadísticas mensuales de más de 20.000 visitan-tes, más de 500.000 páginas descargadas, unos 54 gigabytes de datos descargados, y un incremento mensual en estos indicadores del orden del 10%.

Aunque estas cifras pueden parecer un éxito en cuanto a difusión, lo cierto es que son francamente moderadas si se comparan con las páginas de temática carto-gráfica más visitadas en nuestro país: Google Earth; el SIG de Parcelas Agrícolas (SIGPAC) del Ministerio de Agricultura, Pesca y Alimentación, que muestra ortofo-tos de toda España de 1 metro de resolución; la Oficina Virtual del Catastro, etc.

En ese sentido, el grupo de trabajo de la IDEE, en la reunión celebrada en Valla-dolid en junio de 2006, decidió formar un subgrupo de trabajo bajo la denomina-ción de SGT “Observatorio IDE” con un triple objetivo:

• Observar, monitorizar y seguirla actividad IDE en España, con especial

atención a las implementaciones en curso. • Informar y difundir los resultados de las encuestas, entrevistas, reportajes,

etcétera que se elaboren para cumplir el primer objetivo. • Analizar las medidas a tomar para lograr la difusión y promoción en Espa-

ña de tecnología IDE en todos aquellos sectores de actividad susceptibles de ser considerados usuarios de las IDE.


Creemos que hay una ingente labor que desarrollar en relación con el tercer punto, y pensamos que existen vastísimas comunidades potenciales de usuarios que podrían beneficiarse de las tecnologías IDE: enseñanza, universidades, centros de investigación, grandes corporaciones, empresas de cartografía, etc.

6. Conclusiones La implantación y utilización de la tecnología que aportan las Infraestructuras

de Datos Espaciales, y en particular el establecimiento de una IDE nacional, como es IDEE, supone un cambio de paradigma en la gestión y utilización de la informa-ción geográfica, y deberá permitir alcanzar la "democratización" del uso de este tipo de información, permitiendo georreferenciar, casi toda la información necesa-ria para una adecuada toma de decisiones.

En efecto, trabajar con información geográfica dentro de la red que establece IDEE permite claramente simplificar los procedimientos para localizar, acceder y utilizar la información geográfica producida por los distintos actores. Asimismo, simplifica los servicios basados en esta información existentes en la actualidad y, especialmente, abre unas posibilidades ilimitadas de creación de nuevos servicios sobre los datos o aprovechando y encadenando diversos servicios existentes.

Los aspectos organizativos, una vez establecida, y operativa, la Infraestructura de Datos Espaciales, se simplifican extraordinariamente, ya que ésta se autorregula en base a las normas y protocolos establecidos. No se debe dejar de considerar que una de las principales consecuencias del establecimiento de la IDEE será la signifi-cativa disminución de los costes de gestión y utilización que implica el acceso in-teroperable a los datos y servicios a través de dicha Infraestructura.

La IDEE es un proyecto cooperativo, de autoría colectiva, en el que colaboran organismos e instituciones de los tres ámbitos de la Administración (general, re-gional y local), del entorno universitario y del sector privado.

Esta impresionante oferta de información geográfica, junto con las funcionali-dades que aportan las tecnologías de Infraestructuras de Datos Espaciales, abre un abanico de posibilidades, todavía inexploradas, de gran interés para todos los espe-cialistas, técnicos e investigadores que manejan o precisan de cartografía en su quehacer cotidiano. La utilidad de este tipo de sistemas no ha sido todavía apenas explotada, y el significado del advenimiento de la IDE permanece aún desconocido para la inmensa mayoría de sus usuarios potenciales.

Por otro lado, necesitamos mejorar de manera continua la calidad del servicio que prestamos en el geoportal de la IDEE, perfeccionando todos los aspectos impli-cados: usabilidad, accesibilidad, disponibilidad, estabilidad y rendimiento. En una IDE, el servicio es el concepto central y su calidad es un factor decisivo del que depende la imagen de cualquier proyecto y por lo tanto su éxito.

La principal lección aprendida en el proyecto IDEE es que realmente "si compar-tes, siempre ganas más" tal y como establecen Fernando Trías y Álex Rovira en su libro La buena suerte [17]. Es decir, cuando se habla de Infraestructuras de Datos


Espaciales, compartir es algo que resulta muy beneficioso para todas las partes implicadas.

Referencias

[1] T. S. Kuhn, La estructura de las revoluciones científicas, Fondo de Cultura Iberoamericana, Méjico, 1979.

[2] M. Foucault, Las palabras y las cosas. Una arqueología de las ciencias humanas, Editorial Siglo XXI, Madrid, 2ª Edición, 1999.

[3] T. Friedman, La Tierra es plana. Breve historia del mundo globalizado del siglo XXI, Mr ediciones, Madrid, 2006.

[4] ISO 2382-1:1984 “Data processing – Vocabulary”. [5] A. Rodríguez, P. Abad, E. López, y A. Sánchez, “La IDEE: una realidad

emergente”, VIII Congreso Nacional de Topografía y Cartografía, Madrid, 2004.

[6] Unión Europea (2004): Propuesta de Directiva INSPIRE http://www.ec-gis.org/inspire/proposal/ES.pdf (último acceso julio 2006).

[7] Unión Europea (2003): Directiva 2003/98/CE Public Sector Information http://europa.eu.int/information_society/policy/psi/docs/pdfs/directive/psi_dirrective_es.pdf (último acceso julio 2006).

[8] UNECE (1998): Convención de Aarhus http://europa.eu.int/comm/environment/aarhus (último acceso julio 2006).

[9] Iniciativa Open Access: http://www.soros.org/openaccess/ (último acceso julio 2006).

[10] Iniciativa Open Archives: http://www.openarchives.org/ (último acceso Julio 2006).

[11] H. J. Onsrud y X. López, European Geographic Information Infrastructures: Opportunities and Pitfalls, (I. Masser y F. Salgé eds.), Taylor and Francis, Londres, 1998.

[12] J. Janssen, “INSPIRE and intellectual property rights – a thuderstorm or a tempest in a teapot?” 12 EC-GI&GIS Workshop, Innsbruck, 2006.

[13] Consejo Superior Geográfico, Núcleo Español de Metadatos v1.0 http://www.idee.es/resources/recomendacionesCSG/NEM.pdf (último acceso julio 2006).

[14] Consejo Superior Geográfico, “Modelo de Nomenclátor de España v1.0” http://www.idee.es/resources/recomendacionesCSG/Propuesta_MNE_v1.0.pdf (último acceso julio 2006).

[15] Proyecto gvSIG: http://www.gvSIG.gva.es (último acceso julio 2006). [16] Proyecto SDIGER: http://www.sdiger.net (último acceso julio 2006). [17] F. Trías y A. Rovira, La buena suerte, Ediciones Urano, Madrid, 2004.


Proceso de transformación de webEIEL en un nodo de la red de IDEs (ideAC). Estado actual y actuaciones de futuro

N. R. Brisaboa†, P. A. González‡, M. Lorenzo§, M. R. Luaces†

† Laboratorio de Bases de Datos, Facultad de Informática Universidad de A Coruña

Campus de Elvira s/n, 15071, A Coruña e-mail: {brisaboa, luaces}@udc.es

‡ Servicio de Asistencia Técnica a Municipios

Diputación Provincial de A Coruña Av. Alférez Provisional s/n, 15006, A Coruña

e-mail: [email protected]

§ Servicio de Organización e Innovación Tecnológica Diputación Provincial de A Coruña

Av. Alférez Provisional s/n, 15006, A Coruña e-mail: [email protected]

Resumen La puesta en marcha en julio de 2004 de webEIEL, la aplicación de publicación

en web y descarga de la información cartográfica y alfanumérica contenida en la base de datos territoriales de la Encuesta sobre Infraestructura y Equipamiento Local (EIEL) de la provincia de A Coruña, ha supuesto un decisivo avance en las políticas de puesta a disposición de los usuarios y de la ciudadanía en general de la información geográfica propiedad de la Diputación Provincial de A Coruña (DPC). Sin embargo, dicho servicio web adolece de diversos problemas entre los que des-taca el hecho de no ser interoperable y, por tanto, tampoco integrable en la red de IDEs.

Para superar dichas limitaciones, se ha puesto en marcha un convenio de cola-boración entre la Diputación Provincial de A Coruña y el Laboratorio de Bases de Datos de la Universidad de A Coruña que tiene por objeto construir, a partir de la misma información distribuida a través de webEIEL, un nodo que cumpla con las especificaciones del OGC, las normas ISO 19100, y las recomendaciones emanadas de la iniciativa INSPIRE, así como las normas y recomendaciones adoptadas por el GT-IDEE (Grupo de Trabajo de la IDE de España) del Consejo Superior Geográfico.


Palabras clave: IDE, servidores de mapas, WMS, WFS, servicio de catálogo, servicio de nomenclátor, software libre.

1. Introducción El objetivo de la presente ponencia es describir el proceso de evolución que

permitirá migrar de la aplicación webEIEL al nodo ideAC (Infraestructura de Datos Espaciales de la provincia de A Coruña), de tal manera que nuestros servicios de publicación y distribución de IG puedan ser integrados en la red de IDEs.

En este capítulo se presenta, en primer lugar, una breve descripción de la apli-cación webEIEL y de los condicionantes que presenta, para a continuación estable-cer la funcionalidad requerida para el nodo ideAC, tanto en términos de servicios a implementar como de herramientas para los usuarios de la Diputación, de los mu-nicipios de la provincia y de Internet. A continuación, se muestra la arquitectura del nodo y se presentan los módulos software que son necesarios para implementar dicha arquitectura.

Para terminar, se establecen las conclusiones generales y se describen las líneas inmediatas de crecimiento del nodo y los objetivos finales a alcanzar.

2. webEIEL Tras una década de pruebas y aproximaciones diversas al mundo SIG (Sistemas

de Información Geográfica), al acometer la realización de la Fase IV de la EIEL (Encuesta sobre Infraestructuras y Equipamiento Local), la Diputación Provincial de A Coruña optó por dar el paso definitivo de integración de los datos de esta encuesta en una base de datos territorial y gestionarlos y publicarlos mediante apli-caciones SIG integradas, en la mayor medida posible, en la red. Para ello se suscri-bieron sendos convenios con la Universidad de A Coruña (UdC) mediante los cua-les se realizarían, respectivamente, las siguientes tareas:

• Captura, grabación y validación de los datos. • Desarrollo de las aplicaciones de gestión y publicación de los mismos.

El resultado final del segundo de los convenios mencionados fue la implanta-ción de dos aplicaciones: sigEIEL (posteriormente renombrada como gisEIEL) y webEIEL, independientes entre sí, pero que hacían uso del mismo conjunto de da-tos. A efectos del presente trabajo vamos a hacer especial hincapié en la segunda de dichas aplicaciones por ser la que más directamente se relaciona con el mundo IDE, aún cuando las actuaciones que se están realizando afectan a ambas.


Figura 1. Cronograma de implantación de aplicaciones de gestión de información geográ-

fica (IG) en la Diputación de A Coruña

webEIEL, por tanto, es la aplicación de publicación en web (http://www.dico-

runa.es/webeiel/) y distribución de los datos contenidos en la Base de Datos Terri-toriales de la EIEL (BDT-EIEL). Fue puesta en producción y abierta a la totalidad de la comunidad web en julio de 2004, sirviendo a partir de entonces como modelo para posteriores actuaciones de otras entidades provinciales.

Por razones económicas y de procesos de contratación, la aplicación está cons-truida sobre tecnologías GeoMedia Web Map, de Intergraph, y con los datos con-tenidos en formato GeoMedia SmartStore, a fin de mejorar los ratios de transmi-sión a la red.

Esta base tecnológica implica varias consecuencias: • Debido al acuerdo corporativo existente entre Intergraph y Microsoft, las

aplicaciones mencionadas corren exclusivamente sobre entornos Windows, lo que ha obligado a montar una máquina virtual sobre los servidores web de la DPC, que utilizan Linux. Esta solución hace que la transmisión de da-tos sea innecesariamente más lenta de lo deseable.

• Por el mismo motivo anterior, GeoMedia Web Map es sólo compatible al cien por cien con el navegador MS Internet Explorer, lo que hace que al-gunas de sus funciones no se ejecuten adecuadamente sobre otros navega-dores. Y entre éstas una muy esencial: la visualización de los mapas temá-ticos.


Figura 2. Página de acceso a webEIEL

• Dado que las aplicaciones son independientes entre sí, es necesario tener

una réplica de la base de datos principal en formato SmartStore, por lo que los datos están finalmente contenidos en dos bases de datos diferentes, con las consiguientes consecuencias de incremento de espacio en disco (1 Gb para cada una de las BBDD), complicación de los procesos de actualización y mantenimiento de datos, riesgo de aparición de faltas de coherencia entre los contenidos de ambas bases de datos, etc.

• En el momento de desarrollo de las aplicaciones, GeoMedia Web Map no cumplía aún con la especificación WMS (Web Mapping Server) del Open Geospatial Consortium (OGC), por lo que nuestro servidor de mapas no era hasta ahora integrable en la red de infraestructuras de datos espaciales (en adelante Red IDE).

Por otra parte, tras la puesta en producción de webEIEL, la Comisión de Infor-

mática de la Diputación Provincial de A Coruña (DPC) decidió ir migrando las apli-caciones corporativas a entornos de software libre o código abierto (open source).

Todo ello, junto con la evolución de las tecnologías asociadas a Internet, el pro-pio éxito obtenido por nuestro servidor de mapas, y el lanzamiento de la iniciativa INSPIRE (INfrastructure for Spatial InfoRmation in Europe) de la Comisión Euro-pea, han determinado un cambio profundo en la filosofía de base y la selección de tecnologías que han de soportar el SIG corporativo y, en consecuencia, se ha optado por la puesta en marcha de un nuevo proyecto, denominado ideAC, que pretende construir una infraestructura de datos espaciales (IDE) que permita alcanzar los objetivos determinados por INSPIRE, y en particular el primero de ellos: “Los datos deben ser capturados una sola vez y mantenidos en el nivel en que esta tarea pueda


ser realizada de manera más efectiva”. Para identificarlo y describir sus contenidos se adoptó el sistema taxonómico propuesto por Béjar y otros en [1]:

• Nodo: ideAC, la IDE de la Diputación Provincial de A Coruña. • Ámbito: Provincia de A Coruña. • Responsabilidades: Proveer a la Red IDE con datos básicos y temáticos de

la provincia de A Coruña recogidos a escalas mayores que 1:10.000, con generalizaciones a escalas menores de estos mismos datos, y con servicios interoperables relacionados con los mismos. Gestionar, coordinar y super-visar la IDE provincial y corporativa.

• Rol: Proveedor oficial de los datos georreferenciados de la EIEL de A Co-ruña y de la red provincial de carreteras, así como de aquellos otros que se puedan incorporar en el futuro.

Con ocasión del inicio de los trabajos de realización de la Fase V de la EIEL, se

ha puesto en marcha un nuevo convenio con el Laboratorio de Bases de Datos de la UdC, para abordar el desarrollo de la primera tanda de servicios a incluir en ideAC.

3. Requisitos funcionales de ideAC Como ya se ha comentado, el proyecto nace de la necesidad de dotar a la DPC de

un conjunto de aplicaciones que permitan gestionar y hacer uso de su información geográfica de manera descentralizada, siguiendo los principios de INSPIRE, y garan-tizando siempre la coherencia y calidad de los datos. Además, dichas aplicaciones deben estar basadas en software libre o de código abierto. Estos son, por tanto, los requisitos primarios que ideAC ha de cumplir.

La adopción de soluciones IDE, además, ha de permitir unificar en un único en-torno (y con una única base de datos) a todos los servicios y aplicaciones. De este modo, gisEIEL pasará a ser una aplicación de usuario ubicada por tanto en el tercer nivel de la ya conocida arquitectura propuesta por la iniciativa INSPIRE.

En lo que respecta a requisitos funcionales más específicos, el proyecto ideAC es un proyecto abierto, como no podía ser de otro modo dado que tanto las tecno-logías como los estándares, especificaciones y recomendaciones involucradas están en permanente evolución. No obstante, sus bases teóricas han sido establecidas a partir de los estudios contenidos en González [2] y [3].

Por otra parte, y debido a razones presupuestarias y organizativas, para este primer convenio de desarrollo se ha optado por implementar tan sólo los servicios considerados como “básicos” por el grupo de trabajo IDEE del Consejo Superior Geográfico. Esto es:

• Servidor de mapas (WMS). • Servidor de entidades (WFS).


• Servicio de catálogo de metadatos. • Servicio de nomenclátor.

Todos ellos han de cumplir con las correspondientes especificaciones del OGC, estándares ISO 19100, recomendaciones de INSPIRE, y del grupo de trabajo de la IDE de España, del Consejo Superior Geográfico, y las normas emanadas de este último grupo de trabajo. Este cumplimiento se asegurará mediante la realización de los correspondientes tests de conformidad. A continuación se describen estos servi-cios y sus componentes:

3.1. Servidor de mapas (WMS) Permitirá el acceso remoto a datos geográficos para su visualización y superpo-

sición, mediante la selección de capas temáticas diversas procedentes de distintos conjuntos de datos, sin necesidad de descargarlos al equipo cliente.

3.2. Servidor de entidades (WFS) Permitirán el acceso y el uso directo a los datos vectoriales contenidos en bases

de datos remotas, o desde equipos remotos a los contenidos en las bases de datos residentes en el servidor, así como a otros servicios de geoprocesamiento, sin nece-sidad de descargarlos al equipo cliente.

3.3. Servicio de catálogo de metadatos Es aquel que permitirá interoperar con la base de metadatos (catálogo) de la IG

contenida o servida a través de ideAC. Está formado por los siguientes componen-tes:

• Servicio de edición de metadatos (SEM): Permitirá crear, grabar, modificar,

actualizar o eliminar los metadatos y, por tanto el correspondiente catálo-go.

• Servicio de consulta de metadatos (SCM): Permitirá realizar búsquedas y consultas sobre el catálogo de metadatos, o sobre un conjunto de catálogos de metadatos estructurados en árbol, partiendo de criterios geográficos (po-sición, área), cronológicos (fecha de actualización de la información), to-pológicos (proximidad a, intersección con, yuxtaposición con, etc.), carto-gráficos (escala, altitud, precisión, resolución), tipológicos (Modelos Digi-tales de Terrenos o MDT, vector, ráster, imagen), o toponímicos (nombre de entidad de población, accidente geográfico o unidad administrativa, deno-minación de hoja cartográfica o de serie de imágenes, etc.), así como otros


que se puedan identificar en el futuro. • Servicio de gestión de datos (SGD): Permitirá acceder a los datos seleccio-

nados tras la correspondiente consulta y suministrárselos al usuario en las condiciones establecidas para el conjunto de datos de que formen parte. Es-tos datos se transmitirán a través de la red en formato GML (Geography Markup Language), de tal modo que las aplicaciones cliente puedan enten-derlos sin dificultad. Para ello harán uso de los:

• Servicios de importación/exportación XML/GML (SIE): Traducirán a y de es-tos lenguajes la información que circule a lo largo de la red de IDEs, para permitir su utilización por los demás servicios y aplicaciones.

• Servicio de registro (SRG): Permitirá registrar el catálogo de metadatos en otros nodos de acceso a la red de IDEs, así como el registro de otros catálo-gos de metadatos en el nodo de acceso a ideAC, de tal modo que se puedan realizar consultas y búsquedas en cascada contra todos los catálogos regis-trados.

3.4. Servicio de nomenclátor (Gazeteer) (SNG) Permitirá asociar los topónimos (nombres geográficos) a distintos sistemas de

georreferenciación, de tal manera que se facilite la realización de consultas partien-do indistinta o conjuntamente de criterios geográficos o toponímicos.

Compartirá con el servicio de catálogo las funcionalidades prestadas por: SGD, SIE y SRG, y contará además con lo siguientes componentes propios:

• Servicio de edición de nomenclátor (SEN): Permitirá crear, grabar, modifi-

car, actualizar o eliminar los datos contenidos en el nomenclátor de ideAC. • Servicio de consulta de nomenclátor (SCN): Permitirá realizar búsquedas y

consultas sobre los datos contenidos en el nomenclátor, o sobre un conjun-to de nomenclátores estructurados en árbol, partiendo de criterios toponí-micos (nombre de entidad de población, accidente geográfico o unidad administrativa, denominación de hoja cartográfica o de serie de imágenes, etc.), geográficos (posición, área), cronológicos (fecha de actualización de la información), topológicos (proximidad a, intersección con, yuxtaposi-ción con, etc.), cartográficos (escala, altitud, precisión, resolución), tipoló-gicos (MDT, vector, ráster, imagen), así como otros que se puedan identifi-car en el futuro.

Además de estos cuatro servicios básicos, se han implementado también diver-

sos servicios complementarios que han de permitir realizar tareas de administra-ción, gestión, coordinación y mantenimiento del nodo. Entre otras, realizan las siguientes funciones: actualización y mantenimiento de datos y servicios, identifi-cación de usuarios y gestión de sus privilegios de acceso, seguridad, etc.


4. Arquitectura del nodo Para la consecución de estos objetivos se ha implementado la arquitectura soft-

ware que se muestra en la figura 3. En la base de la figura se encuentra la base de datos de la EIEL de A Coruña. Esta base de datos no sólo incluye la información relativa a la EIEL, sino que también incluye los objetos geográficos utilizados para referenciar la información alfanumérica de la EIEL, así como la información adicio-nal que el equipo de trabajo de la EIEL ha decidido recoger a mayores. En términos de sistemas de información geográfica esta base de datos no contiene atributos del espacio, únicamente objetos geográficos [4]. Es decir, al no contener ortofotos o datos obtenidos de sensores no es necesario abordar el problema del almacena-miento de este tipo de información. En su lugar, para almacenar la información de la EIEL es suficiente con un sistema gestor de bases de datos que implemente el estándar Simple Features Specification for SQL de OGC e ISO [5].

Por encima del sistema de almacenamiento pueden apreciarse dos ramas dife-rentes en la arquitectura. A la izquierda de la figura se encuentran los componentes de la aplicación de escritorio gisEIEL, mientras que a la derecha se muestran los componentes de la aplicación webEIEL.

En el caso de la aplicación de escritorio gisEIEL no es necesario detallar su ar-quitectura en este capítulo. Esta aplicación consiste en una herramienta de consulta, visualización, análisis y edición de información geográfica. Como detalle de interés podemos mencionar que esta aplicación se conecta directamente al sistema de al-macenamiento en lugar de utilizar los componentes del nodo para conseguir una mayor eficiencia en el acceso a datos: la sobrecarga introducida por los servicios del nodo es demasiado elevada para los usuarios de gisEIEL que esperan del siste-ma una gran agilidad en el tratamiento de la información. Por otra parte es impres-cindible que gisEIEL incorpore funcionalidad para actuar como cliente de servicios WFS [6] y WMS [7] que permitan al usuario incluir en la visualización información y cartografía proveniente de otros nodos de la IDEE.

En la base de la aplicación webEIEL se encuentran dos servicios que acceden directamente al sistema de almacenamiento: el servicio de información geográfica (WFS) y el servicio de catálogo y metadatos (CS-W [8], ISO 19115 [9]). El servicio de información geográfica es el encargado de servir la información del sistema utilizando el estándar Web Feature Service de OGC. Utilizando este servicio cual-quier cliente del nodo ideAC puede obtener la información geográfica en un forma-to (GML [10]) representable en un sistema de información geográfica sin que los objetos pierdan su identidad y sus valores alfanuméricos asociados. Además, el servicio WFS se utilizará siguiendo el perfil WFS-G [11] como base del servicio de nomenclátor.

Por otra parte, el servicio de catálogo y metadatos permite a cualquier usuario del nodo ideAC consultar qué información está disponible en el nodo, cómo se relaciona esta información con otros elementos del nodo, y toda la información adicional que el estándar ISO 19115 permite representar de cada elemento de in-formación.


BDEIEL

SGBD (SFS for SQL)

GISEIEL

WebEIEL

WMS

WFS

Contenedor App. Web

Cliente WMSCliente WFS

Navegador Web Applet Java DHTML

PNGSVG

CS-W

Figura 3. Arquitectura del nodo ideAC

Un nivel por encima de estos dos servicios se encuentra el servicio de mapas

(WMS). Este servicio se utiliza para producir cartografía a partir de la información geográfica almacenada en el sistema. En este caso el resultado de una consulta es un mapa representado como una imagen que contiene la información solicitada y en la que los elementos individuales pierden su identidad así como la información alfanumérica asociada.

Finalmente, por encima de estos servicios se encuentra el interfaz de usuario de la aplicación webEIEL propiamente dicho. Este interfaz es el responsable de ofre-cer a los usuarios un entorno amigable para consultar la cartografía, el catálogo, los metadatos, el nomenclátor, y para realizar todas las tareas descritas en la sección anterior.

En este interfaz de usuario se ha decidido ofrecer dos modos de funcionamiento con diferente funcionalidad y orientados a tipos de usuario distintos. Por un lado se encuentra un interfaz de usuario dirigido a técnicos de la Diputación y a usuarios avanzados cuya principal característica es que su funcionamiento es muy similar al de una herramienta de visualización de información geográfica de escritorio. En este caso se trabaja con mapas vectoriales activos [12] representados en el lenguaje SVG, y el interfaz de usuario en la parte cliente está implementado con un applet Java. Las ventajas de este interfaz de usuario consisten en que el applet Java per-mite alcanzar un nivel de interactividad con la aplicación difícilmente alcanzable con una aplicación web pura, y en que al trabajar con información vectorial la cali-


dad de los mapas y la interactividad de los mismos es mucho más elevada. Sin em-bargo, esta aproximación necesita un mayor nivel de conocimientos por parte del usuario porque es necesario que la máquina virtual de Java esté instalada en el equipo y funcione correctamente, la aplicación tarda más en ejecutarse, su funcio-namiento es más complejo y la información tarda más en llegar al usuario.

Por otra parte, para los usuarios en general cuyo principal interés es consultar la cartografía se ha implementado una versión mucho más sencilla de la interfaz que utiliza imágenes para visualizar la cartografía y está implementada utilizando úni-camente HTML y Javascript. Esto permite que esta versión de la aplicación pueda ser ejecutada en cualquier navegador web sin excesivos requisitos. Además, su sencillez hace que sea indicada para usuarios poco expertos en sistemas de infor-mación geográfica.

5. Implementación basada en software de código abierto Basándonos en la arquitectura descrita en la sección, y teniendo en cuenta los

requisitos expresados por la Diputación Provincial de A Coruña, podemos resumir las características tecnológicas requeridas de los componentes que se utilicen para implementar tanto gisEIEL como webEIEL de la siguiente manera:

webEIEL • Conexión con sistemas gestores de bases de datos (SGBD) que implementen

el estándar Simple Features Specification for SQL (SFS). • Servicio web que implemente el estándar Web Feature Service (WFS). • Servicio web que implemente el estándar Web Map Service (WMS). • Servicio web de catálogo de metadatos. • Servicio web de nomenclátor.

gisEIEL • Conexión con sistemas gestores de bases de datos que implementen el es-

tándar Simple Features Specification for SQL (SFS). • Visualización de información geográfica en distintos sistemas de coorde-

nadas. • Edición de la información geográfica (incluidas las geometrías). • Cliente de servicios Web Feature Service (WFS). • Cliente de servicios Web Map Service (WMS).

Para comparar los distintos componentes software candidatos a ser utilizados en

la realización de este convenio, además de requerir la funcionalidad que se acaba de describir, se tuvieron en cuenta los siguientes criterios:


• Formatos adicionales soportados. Además de requerir la conectividad con el SGBD utilizando el estándar SFS, se valoró la capacidad de utilizar otros formatos para la información geográfica tales como GML o archivos en el formato shapefile de ESRI.

• Lenguaje y entorno de desarrollo. Por una parte, dado que la adaptación de los componentes software a las necesidades específicas era necesaria, se valoró la funcionalidad y comodidad del lenguaje utilizado en el desarrollo original. Por otra parte, dado que el sistema que se construyó tenía que in-tegrarse en los sistemas informáticos de la Diputación Provincial de A Co-ruña, se tuvo en cuenta la compatibilidad del entorno de desarrollo con di-chos sistemas informáticos.

• Soporte por parte de la comunidad de desarrollo. Se evaluó el apoyo por parte de la comunidad de usuarios de los componentes software.

• Capacidad de crecimiento. Se intentó valorar la posible evolución del componente software para evaluar la posibilidad del mismo de incorporar nuevas funcionalidades en un futuro inmediato que fueran de interés para nuestro desarrollo.

Para seleccionar los componentes software que se utilizaron como base para el

desarrollo se evaluaron una gran cantidad de alternativas. Sólo algunas se evalua-ron en profundidad, en concreto:

webEIEL • Deegree [13]. Este proyecto de software libre ofrece un conjunto de blo-

ques fundamentales para construir una infraestructura de datos espaciales implementado con los estándares de Open Geospatial Consortium (OGC) y el ISO/TC 211. Los servicios implementados por este proyecto son: Web Map Service (WMS), Transactional Web Feature Service (WFS), Web Cove-rage Service (WCS), Web Catalogue Service (CS-W), y Web Gazeteer Servi-ce entre otros.

• GeoServer [14]. Una implementación en software libre de los servicios Web Map Service (WMS) y Transactional Web Feature Service (WFS).

• MapServer [15]. Es un proyecto de software libre que implementa los ser-vicios Web Map Service (WMS), y Basic Web Feature Service (WFS).

• GeoNetwork [16]. Es una aplicación web (pero no es un servicio) que per-mite publicar metadatos y la información geográfica de una organización.

gisEIEL • JUMP [17]. El proyecto JUMP es un conjunto de aplicaciones de software

libre que proporcionan una extensa librería de programación y una interfaz gráfica de usuario para la visualización y manipulación de información


geográfica. Su diseño extensible hace que existan varios proyectos relacio-nados como puede ser deeJUMP [18], una adaptación hecha por el equipo de desarrollo de Deegree, y Open Jump Pilot [19].

• gvSIG [20]. Es una herramienta de código abierto orientada al manejo de información geográfica.

• UDIG [21]. Es tanto una aplicación de visualización y edición de informa-ción geográfica como una plataforma de desarrollo de nuevas aplicaciones.

• Saga [22]. Proporciona tanto una librería de programación coma una inter-faz gráfica para el análisis de información geográfica.

El proyecto GeoPISTA [23] del Ministerio de Ciencia y Tecnología no fue eva-

luado por los siguientes motivos: • Está basado en el proyecto JUMP sin añadir funcionalidad reseñable para

el objeto de nuestro desarrollo. El esfuerzo de acometer nuestra implemen-tación hubiera sido el mismo tanto si hubiéramos partido de JUMP como de GeoPISTA.

• Determinados desarrollos (el acceso a las bases de datos, por ejemplo) se implementaron en el proyecto GeoPISTA utilizando interfaces propieta-rios. La conexión con PostgreSQL no se hace a través del estándar SFS, si-no que se hace a través de un administrador de cartografía utilizando una interfaz desarrollada ad hoc.

• El proyecto no estaba terminado y ni el producto final ni el código fuente habían sido publicados todavía.

En las siguientes tablas (véase tabla 1 y tabla 2) podemos ver el resultado de la

comparación entre los distintos componentes. A la hora de seleccionar los componentes para implementar webEIEL, el hecho

de que MapServer esté implementado en C++, que funcione con tecnología CGI, y que necesite un sistema Unix para ejecutarse hacen que no fuera la mejor opción ya que impondría requisitos en los sistemas informáticos de la Diputacion que podrían no cumplirse. El resto de alternativas, al estar basadas en el lenguaje Java, permiten independencia de la plataforma hardware.

Además se hicieron pruebas para evaluar la calidad de los archivos SVG genera-dos y se apreció que los generados por GeoServer son de peor calidad que los ge-nerados por Deegree. En lugar de devolver en el archivo únicamente aquellos obje-tos geográficos visibles en la consulta actual, devuelve todos los objetos geográfi-cos y ajusta el rectángulo de visualización del archivo SVG en el cliente para evitar su visualización. Esto hace que independientemente de la zona visualizada, el SVG resultante siempre contenga la misma información. Así, a pesar de los problemas de Deegree (su gran complejidad a la hora de configurarlo, por ejemplo), se eligió este componente como base para la implementación de webEIEL.


Deegree GeoServer MapServer GeoNetwork

SFS Sí Sí Sí Sí

WFS Transaccional. Transaccional. Básico. Cliente

WMS Sí, con SLD Sí, con SLD Sí, con SLD Cliente

Catálogo Sí No No Sí

Nomenclátor Sí No No No

Formatos adicionales

Shapefile, GML

Shapefile, GML

Shapefile, GML

No aplicable

Lenguaje Java Servlet Java Servlet C++ CGI Java Servlet

Comunidad Limitada Activa Activa Activa

Crecimiento Limitado Elevado Elevado Elevado

Tabla 1. Comparación de componentes para webEIEL

JUMP gvSIG UDIG SAGA

SFS Sí Sí Sí No

Visualización Problemas de memoria y velocidad

Sí Sí Sí

Edición Completa No incluida Completa Completa

WMS Sí Sí Sí No

WFS Sí No incluido Sí No

WCS No Sí No No

Formatos adicionales

Shapefile, GML, CAD

Shapefile, GML, CAD, Ráster

Shapefile, GML, CAD

Múltiples ráster, inclui-do análisis

Lenguaje Java Java Java C++

Comunidad Activa Limitada Activa Activa

Crecimiento Limitado Elevado Elevado Elevado

Tabla 2. Comparación de componentes para gisEIEL


Para la implementación del catálogo de metadatos, aunque GeoNetwork parecía

muy prometedor en principio, al final se desechó en favor de un desarrollo propio. El motivo principal de esta decisión fue la gran complejidad que se detectó a la hora de adaptar GeoNetwork a nuestras necesidades, unido a la falta de documenta-ción para desarrolladores.

Con respecto a la implementación de gisEIEL, la elección de SAGA se descartó debido a que está implementado en C++ y a que tiene un sesgo muy importante hacia el análisis ráster.

Dado que uno de los requisitos básicos es que el componente software imple-mente la funcionalidad de edición de los objetos geográficos, y en el momento de tomar la decisión inicial, gvSIG no podía ser utilizado porque no poseía funcionali-dad para la edición de geometrías. Sin embargo, dado que la implementación de gisEIEL no era prioritaria, y dado que se sabía que esa funcionalidad estaba im-plementada pero no era pública, se decidió comenzar con la implementación de webEIEL y posponer la decisión. En el momento de retomar la decisión, la versión pública de gvSIG ya incluía dicha funcionalidad, por lo que fue el componente escogido.

Figura 4. Superposición de capas del WMS con Catastro


6. El nodo ideAC En el momento de redactar este capítulo el proceso de implementación del nodo

ideAC está a medio camino. Los servicios WMS y WFS ya están implementados y configurados. El servicio de catálogo también está en un estado avanzado. El resto de servicios y aplicaciones está en un estado preliminar por lo que no es posible todavía realizar una descripción detallada del interfaz de usuario del sistema. En cambio, si que podemos mostrar unas capturas de pantalla que ilustren el funcio-namiento del nodo ideAC.

En la figura 4 se muestra una captura de pantalla de la herramienta de visualiza-ción de información geográfica JUMP en la que se han superpuesto algunas capas extraídas del WMS del nodo ideAC (abastecimiento, saneamiento, calles, edifica-ciones) con la información extraída del WMS de catastro. En la figura 5 se muestra una captura de la misma herramienta en la que se ha incluido además información extraída del WFS del nodo ideAC, en concreto hoteles. Se puede observar cómo hay un hotel seleccionado en la parte inferior del centro de la imagen (con borde amari-llo), del que se muestran los datos en una ventana emergente superpuesta. Esto es posible porque los datos se extraen del WFS, con lo que conservan la identidad in-dividual, y no del WMS.

Figura 5. Superposición de datos del WFS


La última captura de pantalla es la que se muestra en la figura 6. En este caso se

muestran dos pantallas del catálogo de metadatos. En la figura 6(a) se muestra la lista de mapas disponibles en el sistema. Por otra parte, en la figura 6(b) se muestra el detalle de uno de los mapas del sistema. Desde esta pantalla de detalle se puede acceder a los metadatos detallados del mapa.

(a) Lista de mapas en el catálogo

(b) Detalle de un mapa en el catálogo

Figura 6. Catálogo de metadatos

7. Conclusiones y trabajo futuro

La conversión del servidor de mapas de la DPC en un nodo IDE va a permitir, an-

te todo, mejorar el intercambio de información geográfica y cartográfica entre la Diputación y otros órganos de la Administración, universidades y empresas intere-sadas en su uso. Además, la aplicación de los conceptos de interoperabilidad, es-


tandarización, y descentralización de la gestión de la información van a mejorar y potenciar sensiblemente el uso de IG en la propia Diputación y en los ayuntamien-tos de la provincia, además de repercutir en la disminución de los costes de captura, actualización y mantenimiento de dicha información.

Para mejorar aún más esa gestión de la IG, en anualidades sucesivas el nodo ideAC se irá completando, de acuerdo con las necesidades de sus usuarios, median-te la puesta en marcha de diversos servicios a mayores de los ya implantados. Igualmente, es de esperar que las distintas unidades de la DPC que integren su in-formación territorial en la IDE provincial pongan en marcha nuevas aplicaciones de usuario.

Entre los servicios ya previstos se cuentan los siguientes: • Servidor de coberturas (WCS): Similar a los anteriores, pero actuará sobre

datos en formato matricial (ráster). • Servicio de transformación de sistemas de coordenadas y de proyección

(STC): Permitirá la transformación dinámica de los sistemas utilizados en distintos conjuntos de datos de tal manera que se garantice su homogenei-dad y exacta correspondencia.

• Servicio de transformación de escalas (STE): Similar al anterior, permitirá homogeneizar distintos conjuntos de datos por la vía de modificar la escala de los que se vayan a utilizar para ámbitos geográficos distintos de los ori-ginales. En realidad, este servicio actuará sólo en aquellos casos en que la información precise ser utilizada a una escala inferior a la original, para lo que incorporará las correspondientes funciones de generalización.

• Servicio de traducción dinámica de información textual (STD). No es pro-piamente un servicio de geoprocesamiento, ya que no ha de ejecutar opera-ción alguna sobre la información espacial. Sin embargo, ha de ejecutarse en íntima relación con los de transformación de sistemas de coordenadas y proyecciones y de transformación de escalas, a fin de entregar la informa-ción al usuario final en los formatos óptimos para cubrir sus necesidades.

• Servicio de autentificación (SAF): Permitirá garantizar en todo momento la autenticidad, autoría y propiedad de la información gestionada a través de ideAC.

• Servicio de notificación de mejoras y actualizaciones (SNM): Gestionará el envío automático de mensajes a los usuarios registrados cada vez que se produzca una mejora, ampliación o actualización de los datos y servicios contenidos en ideAC. Deberá, por tanto, incluir funcionalidades de comu-nicación con los servicios de registro y de catálogo a fin de tener notifica-ción inmediata de cada modificación que se produzca.

• Servicio de comercio electrónico (SCE): Gestionará la venta, alquiler o, en general, contratación del uso de aquélla información o servicios de valor añadido que, en su caso, no se faciliten gratuitamente a través de ideAC en razón de su naturaleza, o por decisión en tal sentido de su productor o pro-pietario.


Referencias

[1] R. Béjar, P. Gallardo, M. Gould, P. R. Muro y F. J. Zarazaga, "A High level architecture for national SDI: The Spanish Case", 10th EC-GI & GIS Work-shop, Varsovia, 2004.

[2] P. A. González, “A Coruña Province SDI design”, MSc in Geographic Infor-mation Dissertation, City University, London, 2004.

[3] P. A. González, Análisis funcional de los servicios de red asociados a la In-fraestructura de Datos Espaciales de la Provincia de A Coruña (ideAC), Tra-bajo final del Curso de Experto Universitario en Sistemas de Comunicaciones: Redes, Internet y Servicios IP, IEEC-UNED, Madrid, 2005.

[4] N. R. Brisaboa, J. A. Cotelo Lema, M. R. Luaces, y J. R. Viqueira. “State of the Art and Requirements in GIS”. The 3rd Mexican International Conference on Computer Science (ENC), Aguascalientes, Mexico, 2001.

[5] Open Geospatial Consortium, Inc., Implementation Specification for Geo-graphic information - Simple feature access - Part 2: SQL option (SFS), ac-cedido el 10 de febrero de 2006 en http://portal.opengeospatial.org/files/?arti-fact _id =13228.

[6] Open Geospatial Consortium, Inc., Web Feature Service (WFS) Implementa-tion Specification, accedido el 10 de febrero de 2006 en https://portal.open geospatial.org/files/?artifact_id=8339.

[7] Open Geospatial Consortium, Inc., Web Map Service (WMS) Implementation Specification, accedido el 10 de febrero de 2006 en http://portal.opengeospa-tial.org/files/?artifact_id=5316.

[8] Open Geospatial Consortium, Inc., Catalogue Service Implementation Specifi-cation (2.0.1), accedido el 10 de julio de 2006 en http://portal.opengeospatial .org/files/?artifact_id=5929&version=2.

[9] Norma ISO 19115. Geographic Information – Metadata. [10] Open Geospatial Consortium, Inc., Geography Markup Language (2.1.2),

accedido 10 julio 2006 en http://portal.opengeospatial.org/files/?artifact_id= 11339.

[11] Open Geospatial Consortium, Inc., Gazetteer Service Profile of a WFS, ac-cedido 10 julio 2006 en http://portal.opengeospatial.org/files/?artifact_id= 13593.

[12] N. R. Brisaboa, M. R. Luaces, J. R. Paramá, D. Trillo, y J. R. Viqueira. “Im-proving Accessibility of Web-Based GIS Applications”, The 2nd International Workshop on Geographic Information Management (DEXA Workshop), Co-penhague, Dinamarca, 2005.

[13] Deegree: http://deegree.sourceforge.net/ (10 febrero 2006). [14] GeoServer: http://docs.codehaus.org/display/GEOS/Home (10 febrero 2006). [15] MapServer: http://mapserver.gis.umn.edu/ (10 febrero 2006). [16] GeoNetwork: http://sourceforge.net/projects/geonetwork (10 febrero 2006). [17] The JUMP Project: http://www.jump-project.org/ (10 febrero 2006).


[18] deeJUMP: http://demo.deegree.org/download/demos/deejump/deejump-2005 1102.zip (10 febrero 2006).

[19] JUMP Pilot Project: http://jump-pilot.sourceforge.net/ (10 febrero 2006). [20] gvSIG: http://www.gvsig.gva.es (10 febrero 2006). [21] uDIG: http://udig.refractions.net (10 febrero 2006). [22] SAGA GIS: http://www.saga-gis.uni-goettingen.de/html/index.php (10 febrero

2006). [23] GeoPISTA: http://www.geopista.com (10 febrero 2006).


El papel de Dublin Core en el desarrollo de las infraestructuras de datos espaciales

F. J. Zarazaga-Soria†, J. Nogueras-Iso†, E. Méndez-Rodríguez‡, R. Tolosana-Calasanz†, P. R. Muro-Medrano†

† Departamento de Informática e Ingeniería de Sistemas

Universidad de Zaragoza, María de Luna 1, 50018, Zaragoza e-mail: [email protected]

‡ Departamento de Biblioteconomía y Documentación

Universidad Carlos III de Madrid, 28903, Getafe (Madrid) e-mail: [email protected]

Resumen

Las tendencias actuales de caracterización de recursos de información geográfi-ca para su oferta a través de Infraestructuras de Datos Espaciales (IDE) se centran en la información geográfica más tradicional (mapas, coberturas, modelos digitales del terreno, etc.). Para ello han utilizado como soporte de descripción los trabajos del grupo TC 211 de ISO (fundamentalmente ISO 19115). No obstante, todavía que-da una ingente cantidad de servicios e información más heterogéneos susceptibles de ser ofrecidos a través de una IDE. El reto que se plantea en estos momentos es la definición de una estrategia que posibilite la incorporación de estas fuentes y servi-cios de información garantizando la interoperabilidad entre sistemas, sin que ello vaya en detrimento de una descripción o caracterización de recursos, adecuada, completa y suficiente. Es en este contexto donde Dublin Core puede jugar un papel fundamental como norma de metadatos (ISO 15836) de propósito general, fomen-tando la interoperabilidad en distintos dominios informativos, entre ellos también la información geoespacial. El objetivo de este capítulo es presentar un modelo de utilización del conjunto de elementos y principios de Dublin Core como base para el proceso de asignación de metadatos asociados a todo tipo de recursos en el con-texto de una IDE, así como las decisiones técnicas básicas que deberían tomarse para dar soporte a servicios de creación y búsqueda de información sobre este mo-delo general propuesto.

Palabras clave: metadatos, Dublin Core, interoperabilidad.


1. Introducción Desde que surge el concepto de Infraestructura de Datos Espaciales (IDE) en

1994 [1] se ha llevado a cabo un gran avance en el desarrollo de conceptos, mode-los y arquitecturas que han posibilitado la creación de una sólida base. Esta base ha permitido la puesta en funcionamiento de un número cada vez más importante de IDEs a niveles locales, regionales, nacionales y transnacionales. No obstante, basta con echar un rápido vistazo para observar que el eje central sobre el cual se susten-ta la mayor parte de estas iniciativas lo constituye la información geográfica más tradicional (mapas, coberturas, modelos digitales del terreno, etc.). Para ello se ha venido utilizado como soporte de caracterización de estas informaciones la norma ISO 19115 y la especificación técnica ISO 19139. En algunos entornos IDE ya se está comenzando a trabajar sobre la idea de caracterizar los servicios geográficos haciendo uso de la norma ISO 19119. Sin embargo se está dejando de lado toda una ingente cantidad de servicios e información más heterogéneos susceptibles de ser ofrecidos a través de una IDE (un ejemplo concreto puede encontrarse en [2]). Ya en 1998 Goodchild explicaba que la comunidad de sistemas de información geo-gráfica había venido trabajando con la información geográfica, mientras que la información geo-referenciada es mucho más amplia al incluir cosas tales como las fotografías, los videos, la música y la literatura que pueden dar una variable de localización [3].

El reto que se plantea en estos momentos es la definición de una estrategia que posibilite la incorporación de estas fuentes y servicios de información garantizando la interoperabilidad entre sistemas, sin que ello vaya en detrimento de una descrip-ción o caracterización de recursos, adecuada, completa y suficiente.

El resto del capítulo se estructura como sigue. A continuación se presenta una rápida revisión de los estándares de caracterización de información y servicios que están siendo utilizados en la mayor parte de las IDEs que se están construyendo. Seguidamente se propone Dublin Core como modelo base de caracterización a utilizar en las IDEs, y como este estándar va a posibilitar la integración de nuevas fuentes de información y servicios, así como la compatibilización con los modelos y servicios actualmente en uso. Este capítulo termina con un apartado de conclu-siones.

2. Estándares de metadatos en IDEs Dos son los grandes contribuidores en el ámbito de la estandarización en IDEs:

del comité técnico TC 211 de ISO y Open Geospatial Consortium (OGC). Como conjunción de los trabajos de ambas entidades se puede identificar el manejo de metadatos en dos grandes áreas: los catálogos de datos y servicios, y los capabili-ties o declaraciones de funcionalidad de los servicios OGC.


2.1. Catálogos de datos y servicios El OGC define una especificación de servicios de catálogo (Catalogue Services

Specification) a tres niveles de detalle: • Modelo general (General Model): Modelo abstracto que especifica un con-

junto de interfaces de servicios que soportan la funcionalidad de descubri-miento (discovery), acceso (access) y mantenimiento y organización (maintenance and organization) de catálogos de información geoespacial y sus recursos relacionados.

• Protocolo de conexión (Protocol Binding): Modelo que añade guías para el diseño de la implementación del modelo general. Esto incluye un mapeo entre las interfaces, operaciones y parámetros generales y los constructores disponibles en el protocolo seleccionado.

• Perfil de aplicación (Application profile): Modelo que extiende un proto-colo de conexión documentando las decisiones de implementación y selec-cionando una representación concreta para los contenidos de los catálogos.

El protocolo de conexión CSW (Catalogue Services for the Web) es la primera

propuesta de OGC en la cual se incluye referencia explícita a los modelos de meta-datos a utilizar en los procedimientos de intercambio de información. Los actuales trabajos de especificación de catálogo presentan tres perfiles de aplicación: CORE, ISO 19115/ ISO 19119 y ebRIM:

• Perfil CORE: Según la especificación de OGC para este perfil, se establece

una serie de términos por los cuales se puede interrogar al catálogo. La propia especificación indica que estos términos están basados en los pro-puestos por Dublin Core. De manera análoga, a la hora de devolver los re-sultados, se indica que las respuestas seguirán un modelo análogo al pro-puesto por Dublin Core. No obstante, en ninguno de los dos casos se esta-blece claramente cuál debe ser el esquema concreto a utilizar. De hecho, según las propuestas que se presentan en la especificación del perfil, parece ser que se plantea el uso del esquema XML de Dublin Core, mientras que el más extendido y completo es el esquema RDF.

• Perfil ISO 19115/ISO 19119: Esta perfil trata de cubrir el uso del catálogo OGC tanto como catálogo de metadatos de datos como de metadatos de ser-vicios. Las dos mayores limitaciones con el que se tropieza vienen de la mano de la mezcla de estándares y, fundamentalmente, de la no disponibi-lidad de modelos estándar de representación de estos estándares en XML (ISO 19139 está a punto de convertirse en estándar, mientras que no se co-noce la existencia de un trabajo específico de sustentación de ISO 19119 en XML).

• Perfil ebRIM: Según figura en la propia definición del término, ebRIM (ebXML Registry Information Model) especifica el modelo de información


utilizado por un registro ebXML (http://www.ebxml.org). Su cometido es describir el modo en el que va a poderse acceder a los servicios a través del registro ebXML al cual se encuentra vinculado. En el caso del catálogo OGC, ebRIM proporciona la descripción del modelo de metadatos que se está utilizando por la correspondiente implementación a la que se encuen-tra asociado. Como se puede observar, este perfil no fija ningún estándar de metadatos concreto a utilizar.

2.2. Los capabilities de los servicios OGC Una de las herramientas más utilizadas para la caracterización de los servicios

OGC de una IDE viene de la mano de las capabilities de sus servicios. En el modelo general de servicios que plantea OGC, todos los servicios heredan de OGC Web Ser-vice, que es una interfaz en el que se define como operación GetCapabilities. Esta operación tiene como cometido el proporcionar una descripción de las capacidades del servidor y suministrando al cliente información de los servicios que ofrece y de los elementos sobre los que ofrece el servicio. En este sentido, las capabilities de un servicio OGC constituyen los metadatos del mismo. No obstante, aunque esta descripción recoge muchos de los elementos que aparecen en estándares como Dublin Core e ISO 19119, no hay establecida ninguna correspondencia formal con los mismos.

3. Modelo base de metadatos para una IDE

3.1. Dublin Core La iniciativa de metadatos Dublin Core, simplemente Dublin Core o DC [4], es

actualmente el modelo de metadatos más aceptado para describir, recuperar e inter-cambiar información electrónica, independientemente del dominio científico o disciplinar. En sus orígenes (marzo 1995), el DC surge como un modelo de metada-tos dirigido a la descripción embebida en el código (entonces) HTML por parte de los autores de los recursos, para una recuperación más eficaz y cualificada en mo-tores y otras herramientas de búsqueda web, liderando el desarrollo de metadatos estructurales para la recuperación de información en Internet [5]. Con el tiempo, el Dublin Core ha ido evolucionando hacia un formato de registro para el intercambio de información y a un estándar básico para la interoperabilidad entre repositorios de información científica, sobre todo gracias a la integración del DC con el protoco-lo OAI-PMH [6], pero también a la versatilidad del esquema y al nivel de estandari-zación formal que ha adquirido.

El conjunto de elementos Dublin Core (DCMES) [7, 8], implica 15 elementos bá-sicos para la descripción y recuperación de recursos digitales independiente de la disciplina, tipo de información o dominio científico de los recursos. Desde su defi-


nición en 1995 hasta la actualidad, el interés por este modelo ha ido creciendo y su éxito se debe, entre otras razones a:

• El nivel de normalización formal que ha adquirido rápidamente. Uno de los

problemas habituales de los estándares para la web es que se desarrollan y utilizan en un nivel de facto o de especificaciones de dominio público, donde son muy pocos los que alcanzan en nivel de reconocimiento como estándar formal (de jure) ISO. En el caso del DC, es, desde el año 2003, un estándar internacional ISO 15836, pero alcanzó el rango de norma en el año 2001, entonces reconocida por la autoridad de normalización americana (NISO). Desde su proclamación como estándar ISO, distintos países han mostrado su credibilidad en este esquema de metadatos, reconociéndolo como estándar nacional, por ejemplo en España, se convertirá en una nor-ma UNE a lo largo del año 2006.

• Es un estándar simple y fácil de entender y usar, cuya codificación es inde-pendiente de una sintaxis particular y también de una disciplina o dominio científico específico. La mayoría de los estándares de metadatos nacen li-gados a una sintaxis de codificación (normalmente XML), el DC se puede codificar tanto en XML (fundamental en su uso con OAI [6]) como en RDF, en estructuras de bases de datos, e incluso en HTML (tanto en el código fuente de la cabecera como a través de microformatos). También, la mayor parte de los esquemas de metadatos surgen en un contexto de aplicación disciplinar o dominio particular (por ejemplo, FGDC-CSDGM –Federal Geographic Data Committee–, en el ámbito de la información geoespacial, TEI –Text Encoding Initiative–, en el contexto de la información literaria y/o humanística, etc.), sin embargo, el Dublin Core es un modelo de meta-datos de propósito general, aplicable a distintas disciplinas, distintos obje-tos de información digital o en distintos repositorios o colecciones digita-les.

• La simplicidad del DC no va en detrimento de su especificidad, ya que se puede usar con diferentes matizaciones, vocabularios o esquemas (Dublin Core Terms [9]) y establecer perfiles de aplicación específicos para un do-minio informativo particular.

• Hoy en día es un formato ampliamente aceptado con grandes usos y apli-caciones en todo el mundo. Por ejemplo, es el formato adoptado por múlti-ples programas y proyectos de e-Administración (e-government) en Aus-tralia, Canadá, Dinamarca, Finlandia, Irlanda, Nueva Zelanda y Reino Unido o para proyectos supranacionales como la Red Europea EUKN (Eu-ropean Urban Knowledge Network). Al ser un estándar ISO, cada vez más aplicaciones, de carácter libre o comercial, incluyen el Dublin Core como modelo de metadatos de salida y/o almacenamiento (por ejemplo, Co-nexión OCLC, DCPS, ContentDM, Metabrowser, etc.).


3.2. Nuevas posibilidades funcionales Imaginemos un escenario con tres sistemas de información distintos que cum-

plen cada uno de ellos su objetivo concreto sobre la base de caracterizar la infor-mación utilizando estándares internacionales: una biblioteca “en línea” que posibi-lita el acceso a libros digitales, informes y otras publicaciones, todas ellas caracte-rizadas utilizando como estándar MARC [10]; un servidor de información de even-tos culturales de una ciudad y cuyo modelo base es Dublin Core; y finalmente una IDE. Suponiendo que cada uno de estos servicios permitiese el acceso a sus funcio-nalidades de búsqueda por terceros sistemas de información, sería posible desarro-llar servicios especializados como un proveedor de información turística (eventos y publicaciones pueden ser unidos con informaciones referentes a las rutas a seguir durante un viaje turístico) o un proveedor de información cultural (publicaciones pueden ser vinculadas a un evento y adicionalmente se puede suministrar informa-ción relativa a las vías de acceso y ubicación del lugar donde ocurre el evento) tal y como se muestra en la figura 1.

Figura 1. Caso de uso de interoperabilidad

Tal y como se puede observar, la principal limitación con la que se cuenta es la

necesidad de entender y hacer que los demás entiendan la información que se inter-cambia. Para ello es necesario dotarse del nivel de modelo de datos común que puede corresponder con la propuesta hecha anteriormente sobre la base de Dublin Core. De este modo, si una IDE es capaz de ofrecer sus informaciones bajo esta perspectiva, se abren las puertas a una mayor explotación de la misma al posibilitar su inclusión como sistema legado en otros sistemas de información.

Por otro lado, si los propios servicios con los que opera la IDE son capaces de moverse sobre los esquemas de Dublin Core se nos abren otras dos puertas de su-ma importancia. Por un lado, se podrán integrar nuevos tipos de contenidos que, separándose un poco de lo que constituyen las clásicas informaciones geográficas, pueden jugar un papel fundamental a la hora de dotar a los usuarios de informacio-nes de interés. De esta manera, informaciones tabulares de censos, informes elec-trónicos (en formato PDF, HTML, PS, etc.) sobre determinadas áreas geográficas, o


incluso “hiper-enlaces” con direcciones web relevantes podrían ser incluidas con facilidad en nuestros servicios de catálogo. De otra parte, de manera relativamente sencilla se podrían incorporar las informaciones de otros sistemas legados a los resultados de los servicios de una IDE. Por ejemplo, el servicio de nomenclátor de la IDEE podría enlazar casi de manera automática con los almacenes de fotografías de los puntos de agua con los que cuenta la Confederación Hidrográfica del Ebro al objeto de poder mostrar fotografías de los elementos que cataloga.

3.3. Adaptación a Dublin Core de las IDEs actuales Cuatro son los componentes fundamentales en los que sería necesario trabajar

con vistas a sustentar el funcionamiento de una IDE sobre el modelo general de metadatos basado en Dublin Core: metadatos de datos y servicios, servicios de búsqueda, y servicios de nombres.

3.3.1. Metadatos de datos y servicios Dentro de los procesos de creación de metadatos y servicios, sería necesario que

los modelos que se manejasen permitiesen la compatibilidad con Dublin Core (al-gunas herramientas ya lo permiten, como es el caso de CatMDEdit (http://sourceforge.net/projects/catmdedit). DC ha demostrado su capacidad para servir de base al manejo de metainformación de diferentes tipos de fuentes a través de la definición de perfiles de aplicación o application profiles adaptando su semántica a un domi-nio de información particular, o a través del mapeo de elementos con otros esque-mas de metadatos (creación de crosswalks) que permiten configurar jerarquías de tipos de elementos, utilizando a Dublin Core como fundamento de conversión de todos ellos [11]. Para el caso concreto de información geográfica, ya existe una definición de pasarela o crosswalk que permite la correspondencia de elementos de ISO 19115 a Dublin Core sin pérdidas de información [12]. Esto ha dado pie a la definición de un perfil de aplicación específico para la creación de metadatos de información geográfica en el marco de un proyecto piloto para el lanzamiento de la directiva Europea INSPIRE [13] (Dublin Core Metadata Application Profile for Geographical Data Mining). Sería necesario llevar a cabo actuaciones semejantes para el caso de ISO 19119 o de las capabilities devueltas por los servicios OGC a través de la operación GetCapabilities.

3.3.2. Servicios de búsqueda La mayor parte de los motores de recuperación de información que dan soporte

a los servicios de búsqueda que operan en la actualidad se basan en los modelos XML de los estándares de la serie ISO 19100, o en modelos relacionales propieta-


rios. Por otra parte, a la hora de recuperar por parte del cliente las informaciones, prácticamente en ningún caso se ofrece la posibilidad de obtener la información en Dublin Core.

En el caso de los motores de recuperación, sería necesario modificarlos para que fuesen capaces de indexar y buscar sobre el modelo Dublin Core. Esto no tiene por qué resultar nada extraño ya que si se estudian los campos que componen DC se puede observar que éstos encajan bastante bien con lo que se denominan metadatos de búsqueda en [14]. Además, ya existen soluciones en la actualidad que trabajan sobre esta filosofía [15].

En la parte de los resultados de las búsquedas, OGC ya ofrece una solución sufi-cientemente satisfactoria mediante el perfil CORE de la especificación CSW del catá-logo. Sería necesario forzar a que todos los catálogos que se pongan en funciona-miento cumpliesen dicha especificación.

3.3.3. Servicios de nombres (servicio de nomenclátor, gazetteer) Un caso especial de servicios de una IDE lo constituyen los servicios de nombres

por el gran volumen de información que maneja (solamente la Xunta de Galicia cuenta con alrededor de un millón de topónimos), la gran cantidad de aplicaciones de los resultados obtenidos y los problemas de duplicados (especialmente a la hora de integrar nombres de varias fuentes). El estándar ISO 19112 [16] propone una especificación de contenidos para este tipo de servicios que se puede aproximar bastante a DC. Sin embargo, este modelo de contenidos deja pendiente toda una serie de flecos que trabajos como el que se está desarrollando en la actualidad para la elaboración del “Modelo Español de Nomenclátor” está poniendo de manifiesto. El uso de DC para la creación de este modelo puede suponer un factor fundamental para paliar estas deficiencias, así como facilitar la incorporación de contenidos de gran relevancia en los servicios de nombres (puntos de agua de la Confederación Hidrográfica del Ebro, elementos relevantes del Patrimonio Industrial [2], etc).

4. Conclusiones En este trabajo se ha presentado una propuesta de utilización de Dublin Core

como modelo base de todos los metadatos con los que se trabaje en una IDE. La adopción de este modelo algo más general que los que en la actualidad se están utilizando requeriría unos pequeños ajustes técnicos sobre las actuales soluciones tecnológicas, pero, sin embargo, sentaría unas prometedoras bases en tres líneas fundamentales: un mayor y mejor aprovechamiento de los datos y servicios que en la actualidad se están sirviendo por las propias IDEs, abriría las puertas a la incorpo-ración de nuevos datos y servicios que en la actualidad no se encuentran presentes, y haría más fácil la integración de las IDEs con otros sistemas de información al


objeto de incrementar las posibilidades funcionales que se prestan sobre los servi-cios de éstos.

Ya se están poniendo en marcha iniciativas destinadas a aprovechar Dublin Co-re como pivote sobre el que hacer girar los contenidos de información y la tecnolo-gía y servicios de una IDE construidos sobre esta base. Patrimonio Industrial y Pa-trimonio Paleontológico son dos áreas de gran interés en las cuales se están dando los primeros pasos.

Agradecimientos Este trabajo ha sido parcialmente financiado por el proyecto TIC2003-09365-

C02-01 del Plan Nacional de Investigación Científica y Desarrollo Tecnológico del Ministerio de Educación y Ciencia de España.

Referencias

[1] U.S. Federal Register, “Executive Order 12906. Coordinating Geographic Data Acquisition and Access: the National Spatial Data Infrastructure (U.S.)", Edition of the Federal Register, 13 abril 1994.

[2] F. J.Zarazaga-Soria, M. García, M. G. Hernández, P. Biel, F. J. López, J. F. Valero, “La IDEE como Herramienta de Ayuda a la Elaboración del Inventario del Patrimonio Industrial de Aragón”, Actas de Jornadas Técnicas de la Infraestructura de Datos Espaciales de España (JIDEE’05), Madrid, noviembre 2005.

[3] M. F. Goodchild, "The Geolibrary". Innovations in GIS 5, (eds.) S. Carver, Taylor and Francis, 1998.

[4] DCMI (Dublin Core Metadata Initiative): http://dublincore.org. [5] S. Weibel, T. Koch, “The Dublin Core Metadata Initiative: Mission, Current

Activities, and Future Directions”, D-Lib Magazine, vol. 6, nº 12, diciembre 2000.

[6] OAI-PMH (Open Archive Initiative-Protocol for Metadata Harvesting): http://www.openarchives.org/.

[7] DCMES 1.1. (Dublin Core Metadata Element Set): http://dublincore.org/ documents/dces/.

[8] E. Méndez, “Dublin Core, Metadatos y Vocabularios”. El Profesional de la Información, vol. 15, n. 2, marzo-abril, 2006.

[9] DCMI Metadata Terms: http://dublincore.org/documents/dcmi-terms/ (junio 2005).

[10] U.S. Library of Congress, "MARC standards", Network Development and MARC Standards Office, 2004, http://www.loc.gov/marc/.


[11] R. Tolosana-Calasanz, J. Nogueras-Iso, R. Béjar, P. R. Muro-Medrano, F. J.

Zarazaga-Soria, “Semantic interoperability based on Dublin Core hierarchical one-to-one mappings”, International Journal of Metadata, Semantics and Ontologies (en prensa).

[12] J. Nogueras-Iso, F. J. Zarazaga-Soria, J. Lacasta, R. Béjar, P. R. Muro-Medrano, “Metadata Standard Interoperability: Application in the Geographic Information Domain”, Computers, Environment and Urban Systems Vol 28, 2004.

[13] M. A. Latre, F. J. Zarazaga-Soria, J. Nogueras-Iso, R. Béjar, P. R. Muro-Medrano, “SDIGER: A cross-border inter-administration SDI to support WFD information access for Adour-Garonne and Ebro River Basins”. Proc. 11th EC GI & GIS Workshop, Alghero (Italia), junio 2005.

[14] D. Nebert, "Developing Spatial Data Infrastructures: The SDI Cookbook v.2.0", Global Spatial Data Infrastructure, 2004, http://www.gsdi.org.

[15] R. Tolosana-Calasanz, D. Portolés-Rodríguez, J. Nogueras-Iso, P. R. Muro-Medrano, F. J. Zarazaga-Soria, “CatServer: a server of GATOS”. Proc. 8th AGILE Conference on Geographic Information Science, Estoril (Portugal), mayo 2005.

[16] ISO 19112: 2003, “Geographic information – Spatial referencing by geographic identifiers”, International Organization for Standardization (ISO).


Medidas para impulsar la utilización del núcleo español de metadatos (NEM)

D. Ballari†, A. Sánchez Maganto‡, J. Nogueras-Iso§, A. Rodríguez Pascual‡, M. A. Bernabé Poveda†

† Laboratorio de Tecnologías de la Información Geográfica (LatinGEO)

Escuela Técnica Superior de Ingenieros en Topografía, Geodesia y Cartografía Universidad Politécnica de Madrid

Autovía de Valencia Km. 7, 28031, Madrid e-mail: [email protected]; [email protected]

‡ Instituto Geográfico Nacional

Calle General Ibáñez Ibero 3, 28003, Madrid e-mail: {asmaganto, afrodriguez}@fomento.es

§ Departamento de Informática e Ingeniería de Sistemas

Universidad de Zaragoza Calle María de Luna 1, 50018, Zaragoza


Resumen

El presente capítulo se centra en la descripción de las distintas iniciativas y ac-ciones que está realizando la Infraestructura de Datos Espaciales de España (IDEE) para promover la adecuada y generalizada creación de metadatos en los organismos pertenecientes a la Administración General del Estado (en adelante AGE), en la Administración regional y local. Se describe el trabajo desarrollado para impulsar, crear metodologías y facilitar la creación de metadatos con el objetivo de nutrir el catálogo de metadatos de la IDEE. Se resume el bagaje de experiencia acumulada en el proceso de creación de metadatos aplicando el Núcleo Español de Metadatos (NEM).

Palabras clave: infraestructuras de datos espaciales, IDE, IDEE, metadatos, perfiles de aplicación de metadatos, catálogos, núcleo español de metadatos, NEM.


1. Introducción Uno de los requisitos principales para el establecimiento de una Infraestructura

de Datos Espaciales (IDE) es contar con metadatos que describan la Información Geográfica, requisito esencial para localizar, describir y evaluar los datos disponi-bles [1].

A pesar del reconocimiento general de la importancia de los metadatos, su gene-ración dista de ser una tarea sencilla y atractiva. Diferentes obstáculos se interpo-nen a los creadores de metadatos, algunos de ellos son [2]:

• Los estándares de metadatos son demasiado difíciles y extensos de imple-

mentar. • La producción de metadatos requiere tiempo y otros recursos. • Hay pocos beneficios tangibles e incentivos para producir metadatos. • Falta de personal capacitado. • Dificultad de utilizar las herramientas de generación de metadatos.

Teniendo en cuenta estos obstáculos, el subgrupo de metadatos del grupo de

trabajo para el establecimiento de la IDEE, perteneciente a la Comisión de Geomáti-ca del Consejo Superior Geográfico, ha puesto en marcha una serie de actividades tendientes a superar las dificultades antes nombradas.

De esta forma se han promovido diferentes iniciativas para facilitar e impulsar la labor de creación de metadatos. Una de ellas está siendo llevada a cabo por el Instituto Geográfico Nacional en colaboración con la Universidad Politécnica de Madrid y la Universidad de Zaragoza, por medio del proyecto de investigación titulado: “Convenio para el desarrollo complementario de la tecnología y metodo-logía de captura de metadatos de Información Geográfica y del Catálogo de meta-datos de la IDEE y del Nodo del Instituto Geográfico Nacional de distribución e intermediación de datos y servicios geográficos”

Algunas de las acciones del citado proyecto de investigación, que serán detalla-das en el presente capítulo, son:

• Creación de una guía de usuario del perfil “Núcleo Español de Metadatos

(NEM)” de la norma ISO 19115. • Creación de un equipo de expertos para la ayuda y soporte a los distintos

organismos implicados en la generación de metadatos. • Establecimiento de un Plan de Formación del personal de la Administra-

ción General del Estado, de la Administración regional y local. • Apoyo al desarrollo y mantenimiento de la herramienta open source

CatMDEdit para la generación de metadatos de acuerdo a las normas de metadatos geográficos más utilizadas en el contexto de la información geográfica.


A continuación se detallan las características principales del Núcleo Español de Metadatos, como origen de las iniciativas de implementación, seguidamente se describe cada una de las acciones que se están llevando a cabo para impulsar su utilización. Se finaliza el artículo con una serie de conclusiones obtenidas a partir del trabajo de investigación realizado.

2. El Núcleo Español de Metadatos NEM, acrónimo de Núcleo Español de Metadatos, es una recomendación de me-

tadatos aprobada por el Consejo Superior Geográfico, a través de su Comisión de Geomática [3,11].

El NEM es un perfil de la norma internacional ISO 19115:2003 [10] que consti-tuye el conjunto de metadatos “mínimo” aconsejable por su utilidad y relevancia que permitirá realizar búsquedas, comparaciones, etc., a partir de metadatos que proceden de diferentes fuentes, sobre distintos conjuntos de datos, de una manera rápida, práctica, fácil y fiable. Se define, para ser utilizado por todos los catálogos generados en las diferentes organizaciones relacionadas con la información geográ-fica de manera que se consiga la interoperabilidad de metadatos en toda España.

El perfil NEM está formado por elementos de las dos normas de metadatos más importantes que existen hoy en día en esta materia, la norma internacional ISO 19115:2003 “Metadata” y la norma ISO 15836:2003 The Dublin Core Metadata Element Set, teniendo en cuenta además los proyectos más relevantes en curso en materia de metadatos, especialmente la Directiva Marco del Agua y las iniciativas IDE regionales. Este conjunto de elementos han sido considerados según la justifi-cación de su inclusión (véase figura 1):

• Elementos pertenecientes al núcleo de la norma ISO 19115 (Core Metadata

for Geographic Datasets) para la descripción de conjuntos de datos geo-gráficos. Se trata de un conjunto de 22 elementos, 7 de ellos de carácter obligatorio y otros 15 elementos de carácter opcional y condicional.

• Elementos adicionales incluidos por compatibilidad con la norma Dublin Core [10,12], que no tenían equivalente en el subconjunto ISO 19115 Core Metadata for Geographic Datasets. Por tanto, se incluyeron elementos adicionales como son: información de agregación, créditos y constricciones sobre el recurso.

• Elementos adicionales para descripción detallada de la calidad de los re-cursos de información geográfica [4]. Se consideró que el elemento “ge-nealogía” (lineage) incluido dentro del subconjunto ISO 19115 Core Meta-data for Geographic Datasets era insuficiente para detallar con profundi-dad la calidad de un recurso y se propuso la inclusión de elementos adicio-nales del modelo general de ISO 19115, relativos a la calidad.

• Propuestas de inclusión de elementos adicionales del modelo general de ISO 19115 realizadas por expertos subgrupo de trabajo del NEM. Entre estas


propuestas se incluyen los siguientes elementos: “palabras clave”, la “for-ma de presentación geoespacial”, el “nivel jerárquico” para identificar el tipo del recurso descrito, el “propósito del recurso”, y la “descripción de los usos específicos del recurso”. Varias de estas propuestas coinciden con las realizadas con otras recomendaciones y guías como la Guía GIS de la Directiva Marco del Agua (una de las primeras directivas en exigir de for-ma explícita la recopilación de información geográfica en la forma de ma-pas) [15], los borradores de las reglas de implementación para metadatos de la propuesta de directiva INSPIRE [14], o los perfiles de metadatos pro-puestos en el contexto del proyecto SDIGER [13, 16].

Figura 1. Definición del NEM

A continuación se describen las diferentes iniciativas para impulsar la utiliza-

ción del NEM, la creación de metadatos y, como consecuencia de ello, el progreso y ampliación del catálogo de la IDEE.

3. Medidas para impulsar la utilización del Núcleo Español de Metadatos (NEM)

En la introducción del presente artículo se ha mencionado una serie de obstácu-

los a los que se enfrentan los generadores de metadatos. En base a ellos se plantea-ron distintas iniciativas para lograr su superación, tal como muestra la tabla 1.


Obstáculo Iniciativa

Los estándares de metadatos son exten-sos. Núcleo español de Metadatos. (sección 2)

Los estándares de metadatos son com-plicados.

Guía de Usuario del Núcleo Español de Meta-datos. (Apartado 3.1)

Falta de personal capacitado.

Creación de un grupo de expertos catalogado-res de la Información Geográfica y Plan de Formación para el personal de la Administra-ción General del Estado, regional y local. (Apartado 3.2)

La producción de metadatos requiere tiempo y otros recursos.

Elaboración de una metodología de creación de metadatos basada en cuestionarios. (Apar-tado 3.3)

Dificultad de utilizar las herramientas de creación de metadatos.

Desarrollo y mantenimiento de la aplicación open source CatMDEdit. (Apartado 3.4)

Tabla 1. Tabla de obstáculos e iniciativas lanzadas

3.1. Guía de usuario del Núcleo Español de Metadatos

La implementación de metadatos es una tarea difícil y complicada que requiere

cierta especialización y considerable dedicación, pues, además de conocer bien las características técnicas y básicas del recurso a metadatar, hay que saber qué infor-mación hay que recoger en cada ítem de metadatos, cómo y con qué criterios. Ha surgido así, dentro del Subgrupo de Metadatos la necesidad de elaborar un docu-mento “guía de usuario NEM” [5] que describe para cada uno de los elementos que constituye el NEM, los criterios a seguir para rellenarlo, facilitando así, el trabajo de los responsables de la creación de metadatos en cada organización y haciendo po-sible la interpretación común del resultado final.

Esta guía se estructura, esencialmente, en los siguientes puntos principalmente: • Breve descripción de los diferentes niveles de información para los cuales

se pueden crear metadatos conforme a la recomendación NEM. • Tabla con los elementos que componen el NEM, describiendo los criterios a

seguir para rellenar cada uno de ellos así como una serie de recomendacio-nes para los mismos.

• Ejemplos de aplicación de dichos criterios para diferentes productos aso-ciados a la información geográfica [4].


Figura 2. Campos de la guía de usuario del NEM

Este documento así como el documento del Núcleo Español de Metadatos se

pueden descargar en el geoportal de la IDEE (www.idee.es).

3.2. Creación de un grupo de expertos catalogadores de la Información Geográfica

Los productores de datos se encuentran en la actualidad con la necesidad de

crear metadatos para que la información geográfica sea localizable mediante catá-logos en la web, pero al mismo tiempo se enfrentan con la escasez de tiempo para generarlos [1], la dificultad propia de creación de los metadatos, y la falta de per-sonal capacitado que sirva de referencia.

Teniendo esto presente, se creó un grupo especialistas para la generación de me-tadatos de la información geográfica. Este grupo es formador y consultor en mate-ria de metadatos de la geoinformación, para dar apoyo y asistencia a los órganos y organismos tanto de la Administración General del Estado como de la Administra-ción regional y local.

El objetivo de este grupo es ayudar a los productores de datos a dar los primeros pasos en la generación de metadatos, a través de:

• Realización de cursos de iniciación en metadatos. • Realización de cursos de alto nivel de metadatos. • Asesoramiento a las organizaciones para la implementación del Núcleo

Español de Metadatos (NEM) y la norma ISO 19115.


• Consultorías individualizadas para la definición de perfiles y plantillas de productos y organismos concretos.

El grupo de catalogadores creado pertenece al Laboratorio de Tecnologías de la

Información Geográfica (LatinGEO) – Universidad Politécnica de Madrid [6] – y cuenta con el apoyo de personal del Instituto Geográfico Nacional para la realiza-ción de las tareas descritas anteriormente.

3.3. Generación de un cuestionario de metadatos Para superar la barrera de la escasez de tiempo y falta de personal capacitado en

materia de metadatos, se ha diseñado una metodología de creación de metadatos basada en un cuestionario [7]. De esta forma los productores de datos proveen in-formación documental no estructurada, sin necesidad de pasar por los rigores de unos metadatos formales completamente estructurados [1], dejando esta tarea a los catalogadores de la información geográfica.

En el cuestionario se recoge la información necesaria para cumplimentar los metadatos a partir de preguntas simples, familiares y facilitando ejemplos, que guiarán al productor de datos en el momento de su completado.

Figura 3. Cuestionario de metadatos


El cuestionario (véase figura 3) se encuentra a disposición de todos aquellos que

deseen recoger información para generar metadatos de la información geográfica basados en la norma ISO 19115 y el Núcleo Español de Metadatos, con el objeto de nutrir el catálogo de metadatos de la IDEE.

La finalidad de estos cuestionarios es que el productor de datos, o persona que mejor conozca las características de los productos, sea capaz de aportar toda la información necesaria para crear los metadatos de sus productos sin tener la nece-sidad de conocer el perfil NEM, colaborando así en la creación de la documentación descriptiva de sus productos, y en consecuencia en el enriquecimiento de los catá-logos existentes en las IDE.

3.4. CatMDEdit: herramienta para la creación de metadatos CatMDEdit [8] es una herramienta de edición de metadatos que facilita la do-

cumentación de recursos, haciendo especial énfasis en la descripción de los recur-sos de información geográfica. Es una herramienta open source que ha sido des-arrollada por el consorcio TeIDE –consorcio constituido por grupos de investigación de la Universidad de Zaragoza, la Universitat Jaume I, y la Universidad Politécnica de Madrid para fomentar la investigación y el desarrollo tecnológico de las Infraes-tructuras de Datos Espaciales– y bajo el apoyo de varias instituciones y proyectos (ver http://catmdedit.sourceforge.net/), destacando entre ellos el apoyo otorgado por el Instituto Geográfico Nacional en su labor de coordinador para la creación de la Infraestructura de Datos Espaciales Española (http://www.idee.es/).

Figura 4. Ventana de visualización y edición de metadatos

La herramienta, cuyo aspecto se muestra en la figura 4, ha sido desarrollada ín-tegramente en Java (su arquitectura se describe en [8]) y presenta las siguientes funcionalidades:


• Edición de metadatos de acuerdo a la norma internacional ISO 19115 Geo-graphic Information - Metadata. Se proporcionan cuatro interfaces de edi-ción especializadas para esta norma:

o Una interfaz detallada de acuerdo al modelo general de ISO 19115. o Una interfaz reducida de acuerdo al "Núcleo Español de Metada-

tos" (NEM). o Una interfaz de acuerdo al perfil de aplicación de metadatos

SDIGER-INSPIRE, para la descripción de los recursos espaciales que serán incluidos en la propuesta de la directiva INSPIRE. Este perfil se ha producido dentro del marco del proyecto SDIGER [13,16].

o Una interfaz de acuerdo al perfil de aplicación de metadatos SDI-GER-WFD, desarrollado igualmente bajo el marco del proyecto SDIGER. Es un perfil de aplicación de ISO 19115 para la descrip-ción de los recursos según la Directiva Marco del Agua [15].

• Edición de metadatos conformes al perfil de aplicación de metadatos S

SDIGER-Dublin Core para minería de datos geográficos. Tomando como punto de partida el Dublin Core Spatial Application Profile definido por el CEN/ISSS Workshop on Metadata for Multimedia Information - Dublin Co-re (WS/MMI-DC), este perfil desarrollado bajo el marco del proyecto SDIGER está orientado a la minería de datos geográficos.

• Intercambio de registros de metadatos de acuerdo a distintos estándares y formatos: ISO 19115, Dublin Core y CSDGM (Content Standard for Digital Geospatial Metadata).

• Diferentes estilos de presentación de registros de metadatos en HTML y Ex-cel.

• Herramientas adicionales para facilitar la edición de metadatos: agenda de contactos, gestión de tesauros y conversión de sistemas de coordenadas.

• Generación automática de metadatos para algunos formatos de transferen-cia de datos como shapefile, DGN, ECW, FICC, GeoTiff, GIF/GFW, JPG/JGW, o PNG/PGW.

• Soporte multiplataforma (Windows, Unix), gracias al uso de Java como lenguaje de programación.

• Soporte multilingüe. Actualmente, se puede acceder a la aplicación en seis idiomas: castellano, inglés, francés, portugués, polaco y checo.

Cabe destacar que tanto esta herramienta, como otras con similares funcionali-

dades, son herramientas en constante evolución y desarrollo. La importancia de los metadatos para unir los distintos recursos de una IDE, la complejidad de las normas de metadatos y la escasa madurez de estas normas (la norma ISO 19115 se aprobó hace tan solo tres años) obligan a una mejora constante de las herramientas con el objeto de hacerlas más eficaces y transparentes al usuario. El objetivo ideal sería


conseguir integrar perfectamente los procesos de creación de datos y metadatos, consiguiendo automatizar lo máximo posible la creación de metadatos.

Así pues, dentro del proyecto donde se circunscribe este trabajo se ha decido impulsar el desarrollo de esta herramienta en los siguientes aspectos:

• Maximizar la ergonomía de la aplicación con el objeto de facilitar al

máximo posible la interacción con el usuario. Los diferentes actores de una IDE comparten una percepción generalizada de que la creación de metada-tos es una tarea tediosa y pesada. Por ello, resulta muy importante investi-gar sobre el uso de las herramientas de edición, para que los usuarios las consideren realmente como mecanismos de ayuda para realizar sus tareas. En base a estudios de uso [9] y normas de accesibilidad se intentará mini-mizar el tiempo requerido por un usuario para la creación de un registro de metadatos y mejorar el uso de la herramienta.

• Impulsar la implementación de la especificación técnica ISO 19139 que describe la serialización sobre XML del modelo de metadatos propuesto por ISO 19115. Se espera, que tras varios años de elaboración de borradores, se disponga de una versión definitiva en septiembre de 2006 que permita la interoperabilidad entre distintas herramientas de catalogación.

• Impulsar la creación de metadatos para la descripción de servicios. Distin-tas normas e iniciativas han surgido recientemente para la descripción de servicios. Se pretende estudiar y analizar cuáles son las más idóneas e inte-grarlas dentro de la herramienta CatMDEdit.

• Facilitar la descripción de series cartográficas y sus componentes. • Impulsar avances tecnológicos en aspectos de calidad, multilingüismo y

clasificación de información en el ámbito de los metadatos de datos geoes-paciales. Se avanzará en aspectos como la estimación de la calidad de me-tadatos, la recuperación multilingüe y la elaboración y puesta en marcha de sistemas de organización de conocimiento (tesauros, taxonomías y ontolo-gías) para la clasificación de la información.

4. Conclusiones Este trabajo ha presentado un conjunto de actividades orientadas a fomentar la

creación de metadatos, uno de los pilares fundamentales de una Infraestructura de Datos Espacial, ya sea a escala local, institucional, regional, nacional o global.

Este conjunto de medidas adoptadas ha tendido a la creación de metadatos que cumpliesen al menos con el Núcleo Español de Metadatos, un perfil cuya primera versión fue publicada en 2005 y que tras un año de vida dentro de la comunidad de usuarios española se puede afirmar que es un perfil consolidado, concensuado, estable y no restrictivo.


Entre las medidas adoptadas se ha descrito cómo se ha creado una serie de guías que facilitan la descripción de este Núcleo Español de Metadatos. Asimismo, se ha contado con un grupo de expertos catalogadores capaces de dar formación y sopor-te en materia de metadatos y que se encuentra a disposición de todos los interesa-dos. Una de las labores de este grupo de expertos catalogadores ha sido la elabora-ción de un cuestionario de metadatos para la recogida de información, que facilitará y agilizará la creación de metadatos.

Por último, se ha descrito cómo se ha apoyado el desarrollo y evolución de la tecnología de captura de metadatos de información geográfica desde el proyecto de investigación descrito en este trabajo, destacando asimismo aquellos aspectos más innovadores donde hay que seguir invirtiendo esfuerzos.

Los catálogos de metadatos pueden parecer en un principio grandes colosos cu-ya construcción resulta difícil de abordar, sin embargo, creemos que el conjunto de medidas implementadas facilita su creación y supone un avance significativo en apoyo de los creadores de metadatos. Aprovechando la experiencia acumulada y la retroalimentación de los usuarios, esperamos estar en disposición de continuar tra-bajando en esta línea y ser capaces de proporcionar más medios y herramientas de apoyo que faciliten la labor de los metadatadores.

Referencias

[1] Global Spatial Data Infraestructure. El Recetario IDE. Capítulo Tres: Metada-tos – Describiendo Datos Geoespaciales “, versión 2.0, enero 2004

[2] L. Wayne, “Institutionalize metadata. Before it institutionalizes you.”, Federal Geographic Data Committee, noviembre 2005.

[3] Consejo Superior Geográfico (Ministerio de Fomento), “SGTNEM_2005_01: Núcleo Español de Metadatos”. Infraestructura de Datos Espaciales Españo-la, 2005. http://www.idee.es/resources/recomendacionesCSG/NEM.pdf.

[4] Curso de IDEs AECI-IGN-UPM 2006. Núcleo Español de Metadatos. [5] Consejo Superior Geográfico (Ministerio de Fomento), “Guía de Usuario del

Núcleo Español de Metadatos”, http://www.idee.es/resources/recomendacio nesCSG/BorradorGuiaNEM.pdf.

[6] Laboratorio de Tecnologías de la Información Geográfica – LatinGeo: http://www.latingeo.com.

[7] Cuestionario para la Generación de Metadatos: http://mapas.topografia.upm.es /proyectometadatos/cuestionario

[8] F. J. Zarazaga-Soria, J. Lacasta, J. Nogueras-Iso, M. P. Torres, P. R. Muro-Medrano, “A Java Tool for Creating ISO/FGDC Geographic Metadata”. In Geodaten- und Geodienste-Infrastrukturen - von der Forschung zur praktischen Anwendung. Beiträge zu den Münsteraner GI-Tagen 26./27, IFGIprints 18, Münster (Alemania), junio 2003.


[9] M. Manrique, M. A. Bernabé, D. Ballari, “Guía de procedimiento de evalua-

ción heurística basado en perspectivas concretas. Informe de Usabilidad para la Herramienta CatMDEdit” (sin publicar).

[10] ISO 19115:2003, “Geographic information – Metadata”, International Organization for Standardization (ISO).

[11] A. Sanchez Maganto, A. Rodriguez Pascual, P. Abad Power, E. López Romero. “El Núcleo Español de Metadatos, perfil mínimo recomendado de metadatos para España”.

[12] ISO 15836:2003, “Information and documentation - The Dublin Core metadata element set”, International Organization for Standardization (ISO).

[13] M. A. Latre, F. J. Zarazaga-Soria, J. Nogueras-Iso, R. Béjar, P. R. Muro-Medrano, “SDIGER: A cross-border inter-administration SDI to support WFD information access for Adour-Garonne and Ebro River Basins”, Proceedings of the 11th EC GI & GIS Workshop, Sardinia (Italia), julio 2005.

[14] Commission of the European Communities (CEC), “Proposal for a Directive of the European Parliament and of the Council establishing an infrastructure for spatial information in the Community (INSPIRE)”. COM (2004) 516 final, 2004/0175 (COD).

[15] J. Vogt (ed.), “Guidance Document on Implementing the GIS Elements of the Water Framework Directive”, European Communities, 2002.

[16] F. J. Zarazaga-Soria, J. Nogueras-Iso, M. Á. Latre, A. Rodríguez, E. López, P. Vivas, P. R. Muro-Medrano, “Providing SDI Services in a Cross-Border Scenario: the SDIGER Project Use Case”. Research and Theory in Advancing Spatial Data Infrastructure Concepts, ESRI Press (en prensa).


Contribuciones de una IDE a la e-Ciencia: proyecto AWARE

C. Granell†, L. Díaz†, M. A. Esbrí†, M. Gould†, A. Lladós‡

† Centro de Visualización Interactiva (CEVI)

Departamento de Lenguajes y Sistemas Informáticos Universitat Jaume I

Avenida Sos Baynat s/n, 12071, Castellón e-mail: {carlos.granell, laura.diaz, gould}@uji.es

‡ Instituto Cartográfico de Cataluña

Parc Montjuic s/n, Barcelona e-mail: [email protected]

Resumen

En este capítulo analizamos el papel que potencialmente juegan las Infraestruc-turas de Datos Espaciales en el ámbito de la e-Ciencia. También describimos algu-nas de las mejoras que aportan los componentes de una Infraestructura de Datos Espaciales a la e-Ciencia, como por ejemplo, la reciente especificación de OGC para servicios de geo-procesamiento en la web. Finalmente describimos la implementa-ción de un servicio concreto de geo-procesamiento, de carácter medioambiental, desarrollado en el marco de un proyecto europeo en ejecución, como parte de la iniciativa europea Global Monitoring for Environment and Security (GMES).

Palabras clave: e-Ciencia, servicios web, servicios de geo-procesamiento, WPS.

1. Introducción Vivimos en una era sin precedentes en cuanto a volumen y diversidad de datos

aplicados a procesos de análisis y síntesis multidisciplinares. Los problemas me-dioambientales complejos como el cambio climático y el ciclo del agua transcien-den barreras geográficas y disciplinarias, y requieren soluciones científicas aplica-das a sistemas integrados de información geográfica [1].

La e-Ciencia aparece en el marco de Information Society Technologies (IST) del programa europeo y se define como “ciencia desarrollada a través de colaboracio-nes globales posibilitadas de forma distribuida en Internet”. Una característica co-


mún a todas estas colaboraciones científicas es la necesidad de acceso a grandes colecciones de datos, recursos de computación a gran escala (Grid [2]), y rapidez en la visualización de resultados. El desarrollo de la e-Ciencia está ligado a los avances en la computación, comunicación, teledetección y modelado, para mejorar el entendimiento de nuestro entorno y nuestra habilidad de monitorizar y predecir procesos físicos. Habilitar estos recursos, datos y herramientas de forma distribui-da, hace posible que los investigadores o usuarios científicos en general puedan compartirlos [3]. En este capítulo veremos el papel que desempeña la Infraestructu-ra de Datos Espaciales (IDE) y no solo la tecnología Grid, en la e-Ciencia poniendo como ejemplo un proyecto europeo perteneciente a GMES actualmente en ejecu-ción.

2. Antecedentes Una de la iniciativas que contribuye al desarrollo de la e-Ciencia es GMES [4]

(ver sección 2.1) y como parte de ella nace el proyecto AWARE (A tool for monito-ring and forecasting Available WAter REsource) [5] que tiene como objetivo el desarrollo de herramientas novedosas para la automatización de las tareas de moni-torización y predicción de la disponibilidad de agua y su distribución por aquellas cuencas hidrográficas donde el deshielo es el factor más importante del balance de agua anual, una condición que tienen en común las cuencas de la región alpina.

La Universitat Jaume I de Castellón (UJI) y el Institut Cartogràfic de Catalunya (ICC) se encuentran entre los participantes del proyecto, específicamente en el papel de proporcionar geo-servicios estandarizados con funcionalidad genérica, de tal forma que estén disponibles para toda la comunidad científica con intereses hidro-lógicos.

Para facilitar el acceso a estos datos científicos y servicios web el caso ideal es que pertenezcan a una IDE global, una infraestructura de datos espaciales común para la comunidad científica, que sirva de plataforma para la e-Ciencia y posibilite una armonización de los datos espaciales para facilitar su geo-procesamiento.

2.1. GMES GMES (Global Monitoring for Environment and Security) [4] es una iniciativa

colaborativa entre la Comisión Europea (EC) y la Agencia Espacial Europea (ESA). Nació bajo la responsabilidad de la Dirección General-Investigación, pasando más tarde a manos de la DG-Industria. GMES puede verse como una iniciativa I+D+I que persigue un intento de armonización política e industrial para el uso de datos perte-necientes al campo medioambiental o de seguridad. Fundamentalmente en este ámbito se trata con tres fuentes de datos espaciales: datos in situ, recogidos por los usuarios desde el mismo campo; datos procedentes de la Observación de la Tierra (OT); y datos cartográficos que pueden provenir de la IDE siguiendo la directiva de


INSPIRE. GMES tiene como finalidad armonizar el acceso a estas tres clases de datos, y siguiendo su nueva óptica industrial impulsar la explotación del sector espacial europeo con especial atención en las imágenes satélite (OT).

Los usuarios de datos OT, incluyendo científicos, industria e investigadores, se enfrentan a volúmenes de datos tan variados e inmensos que es difícil extraer in-formación relevante. GMES intenta reunir datos relevantes y servicios novedosos, fáciles de mantener y amigables con los que los responsables de la toma de deci-siones sean capaces de trabajar mejor en situaciones críticas relacionadas con la gestión del entorno y la seguridad. De esta forma orienta sus esfuerzos hacia el desarrollo y establecimiento de un número inicial de servicios que deben ser trasla-dados desde la visión de proyecto a corto plazo a servicios mantenidos a largo pla-zo.

La característica principal, según GMES, para este grupo de servicios iniciales puede resumirse de la siguiente manera:

• Mapas: información relevante desde escalas locales a europeas. • Pronóstico: información sistemática de corto a largo plazo de la evolución

ambiental de la tierra (aire, agua, recursos, etc.). • Actuación en situaciones críticas: información segura y en tiempo real para

la seguridad y la protección civil.

2.2. Infraestructuras de datos espaciales Conectar los científicos de los sectores GMES, con sus datos, modelos y servi-

cios supone una infraestructura muy similar a la que propone el sector de las in-fraestructuras de datos espaciales (IDE).

El objetivo de una IDE se centra fundamentalmente en facilitar el acceso a datos y servicios espaciales así como en coordinar el intercambio de dichos datos y servi-cios entre usuarios de diferentes niveles jurisdiccionales, haciendo posible en últi-ma instancia que los mismos datos y servicios sean compartidos entre múltiples usuarios. Las IDEs se han hecho muy importantes a la hora de determinar la forma en la que los datos son usados desde escalas locales a escalas internacionales. Compartir datos y servicios es muy útil desde el momento que permite al usuario economizar recursos, tiempo y esfuerzo tratando de adquirir nuevos conjuntos de datos, evitando la duplicación de costes asociados a la generación y al manteni-miento de los datos y su integración con otros conjuntos de datos.

Aunque las IDEs son principalmente marcos de colaboración institucional, tam-bién definen e implementan sistemas de información heterogénea distribuida, me-diante cuatro componentes software enlazados vía Internet [6]. Estos componentes tradicionalmente son:

• Editores de metadatos y servicios de catálogo asociados. • Almacenes de datos espaciales o bases de datos.


• Aplicaciones cliente para las búsquedas de usuarios y acceso a datos espa-

ciales. • Middleware o servicios de geo-procesamiento intermediarios que ayudan a

los usuarios a encontrar y transformar datos para su uso en las aplicaciones cliente.

La figura 1 resume los componentes tecnológicos esenciales, aceptados dentro

de las organizaciones de estándares geo-espaciales (Open Geospatial Consortium (OGC) y la ISO Comité Técnico 211) y sintetizado por el US Federal Geographic Data Committe (FGDC) [7] y la NASA. La arquitectura puede ser interpretada como una arquitectura tradicional de 3-capas, modelo cliente-middleware-servidor, don-de las aplicaciones cliente buscan datos (y servicios) espaciales en servicios de catálogo. Una vez encontrados los datos requeridos pueden ser transformados o procesados por servicios intermedios antes de su presentación al cliente. La arqui-tectura puede interpretarse también usando el modelo triangular de servicios web publish-find-bind [8], donde servicios de catálogo publican el contenido de los datos espaciales, estos datos son buscados y encontrados posteriormente por servi-cios de búsqueda, y por último enlazados, ejecutados y presentados al cliente.

Figura 1. Modelo de referencia de la arquitectura de las IDEs (fuentes: FGDC[9], e INSPIRE[10])


Hasta ahora las definiciones de IDEs han puesto poco énfasis en el geo-procesamiento que generalmente ocurre entre el descubrimiento y la presentación de los datos. Tradicionalmente el geo-procesamiento se ha llevado a cabo de forma local en los SIG de escritorio. Otro enfoque refleja el uso de clientes pesados y de servidores de datos distribuidos, donde el geoprocesamiento se lleva a cabo de forma local en el cliente. Este es el caso por ejemplo del cliente gvSIG (http:// www.gvsig.gva.es/). Debido al auge de los servicios web, otro enfoque consiste en desplazar el geoprocesamiento desde un plano local y centralizado a uno totalmente distribuido, donde el geoprocesamiento es implementado mediante servicios web remotos.

El proyecto AWARE se centra justo en este último enfoque distribuido, donde el geoprocesamiento se proporciona como geo-servicios distribuidos, permitiendo que su interfaz funcional sea descrito siguiendo nuevas especificaciones como la re-ciente OGC Web Processing Services.

3. OGC Web Processing Services Open Geospatial Consortium (OGC) define una arquitectura abierta e interope-

rable –basada en la reutilización de los componentes estandarizados [9]– permi-tiendo la creación de nuevas aplicaciones de forma flexible y escalable, facilitando además el cambio de componentes por otros similares, ya sea por motivos econó-micos, de funcionalidad o de rendimiento. Estas aplicaciones ofrecen al usuario la funcionalidad para solucionar un problema en concreto a partir de la unión y/o concatenación de operaciones atómicas ad hoc, en contraste con las aplicaciones SIG monolíticas, donde toda la funcionalidad está implementada en una caja negra a la que no tiene acceso el usuario.

Hasta el momento, se ha estado haciendo hincapié mayoritariamente en la im-plementación de servicios OGC de acceso y visualización de información geográfi-ca (WMS, WFS, WCS, servicio de catálogo), sin embargo, con la nueva especifica-ción de OGC (WPS) para acceder a servicios de geo-procesamiento es posible reali-zar operaciones más complejas de análisis y tratamiento de información espacial (por ejemplo, análisis espacial, camino mínimo en red, buffer, etc.).

Así nace el nuevo concepto de geo-servicios, servicios web definidos por W3C como "una aplicación software identificado por una URI, cuyo interfaz y enlaces pueden describirse y ser descubiertos como artefactos XML” [11], para no solo des-cubrir o presentar información espacial sino también para el caso de proporcionar funcionalidad de geoprocesamiento.


4. Geo-servicios en AWARE El propósito del proyecto AWARE es el de proveer mediante el uso integrado de

los recursos procedentes de la OT, herramientas novedosas para la monitorización y predicción de la disponibilidad y distribución del agua proveniente del deshielo en las cuencas alpinas.

El proyecto está dirigido a cubrir la brecha existente entre los proveedores de información ambiental (temperatura, precipitación, elevación, etc.) de una cuenca hidrográfica y los técnicos/científicos que manejan dicha información (trabajando para compañías hidroeléctricas, Administración local, etc.). De esta forma, el pro-yecto aborda esta problemática proporcionando servicios de catálogo para dar ac-ceso a repositorios de datos y servicios geográficos, e implementando servicios de geo-procesamiento sobre la información que manejan.

Partiendo de unos modelos hidrológicos existentes, el proyecto AWARE pretende automatizar su uso desarrollando un conjunto de geo-servicios que implementan los pasos necesarios para calibrar el modelo y realizar las predicciones de escorren-tía (runoff). Este conjunto de geo-servicios junto con otros componentes, tales co-mo asistentes al usuario, información estática de ayuda, faqs o enlaces a documen-tos relacionados, están disponibles a través de una interfaz web que permite a los usuarios (científicos, en primera instancia) ejecutar de forma sencilla el modelo escogido con sus propios datos a una escala local, obteniendo los resultados con-cernientes al área de interés indicada (generalmente el área de una determinada cuenca de estudio).

En la figura 2 se pueden ver las diferentes tareas que en conjunción con otros módulos componen el modelo hidrológico Snowmelt-Runoff Model (SRM) [12]. Cada una de las cajas de la figura representa una tarea implementada por uno o varios geo-servicios. En particular, nos centramos en la tarea etiquetada como dis-tribución espacial de temperatura (T) y precipitación (P) para cada zona de eleva-ción (caja 7, figura 2) como ejemplo de desarrollo de un geo-servicio.

Una de las subtareas de la tarea anterior consiste en el cálculo de la temperatura media que hay en cada una de las zonas de elevación en que ha sido dividida la cuenca hidrográfica. En el cálculo de este parámetro intervienen cuatro factores tomados a partir de los datos provenientes de imágenes satélites y de los datos in-situ. Estos factores representan la localización de cada una de las estaciones meteo-rológicas distribuidas por toda la cuenca hidrográfica, las mediciones de temperatu-ra tomadas en las estaciones, un modelo digital de terreno del área de estudio y las zonas de elevación en que ha sido dividida la cuenca hidrográfica.

El número de estaciones meteorológicas de que se dispone en la cuenca es redu-cido, por lo que hemos de recurrir a cálculos geo-estadísticos (algoritmos de inter-polación como kriging) para obtener la temperatura en los puntos para los que no se dispone de esta información.


Figura 2. IDEF0 del modelo SRM. Ilustra el flujo de los datos a través del modelo hidro-lógico SRM


Hay varias fuentes de información a las que se necesita acceder para realizar es-

tos cálculos: • Datos meteorológicos de temperatura media mínima de las estaciones me-

teorológicas (junto con las coordenadas y la elevación) obtenida a través de un Web Feature Service (WFS).

• Modelo digital de terreno (MDT) del área de estudio en formato GeoTiff ofrecido a través de un Web Coverage Service (WCS).

4.1. Prototipo inicial El prototipo WPS creado se ejecuta en un medio distribuido e interoperable,

ejemplificando la escalabilidad, flexibilidad y reusabilidad de los componentes en una IDE.

Cálculo de la distribución

espacial de latemperatura

Localización est. meteorológicas

Localización est. meteorológicas

DEMDEM

Temperatura en estaciones

seleccionadas

Temperatura en estaciones

seleccionadas

Algoritmos de interpolaciónAlgoritmos de interpolación

Temperatura media de cada

zona de elevación

Temperatura media de cada

zona de elevación

Zonas de elevaciónZonas de elevación

Figura 3. Modelo conceptual del geo-servicio creado

La implementación del geo-servicio está basada en la especificación para Web

Processing Service definida por el OGC [13] (versión 0.4.0), de forma que el acceso a los cálculos estadísticos que éste ofrece sea realizado de una manera interoperable y estándar. En la figura 3 se puede ver el modelo conceptual del geo-servicio pro-puesto, a modo de versión simplificada en la que no se muestran aspectos de la implementación.

La especificación OGC WPS proporciona acceso a cálculos y modelos geo-espaciales, del mismo modo que podríamos hacer a través de un sistema SIG tradi-cional (por ejemplo, cálculos estadísticos, análisis de buffers, etc.). A través de sus interfaces podemos describir y anunciar las capacidades ofrecidas por el servicio a través de sus metadatos (GetCapabilities), identificar los inputs requeridos para realizar los cálculos (DescribeProcess) e iniciar los cálculos, informar del estado de los mismos y devolver los outputs producidos (Execute).


Todas las operaciones del servicio implementado soportan peticiones realizadas a través de los métodos GET (parámetros codificados como pares clave-valor) y POST (documento XML que incluye todos parámetros) del protocolo de transporte HTTP.

Los cálculos geo-estadísticos proporcionados por este servicio son realizados de forma transparente para el usuario a través del programa estadístico R [14] y el paquete geo-estadístico para R, gstat [15], accesibles a través de una pasarela web (Rserve, http://stats.math.uni-augsburg.de/Rserve). <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Execute service="WPS" version="0.4.0" store="true" status="false" xmlns="http://www.opengeospatial.net/wps" xmlns:ows="http://www.opengeospatial.net/ows" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengeospatial.net/wps ..\wpsExecute.xsd"> <ows:Identifier>CalculateTemperatureMap</ows:Identifier> <DataInputs> <Input> <ows:Identifier>StationTemperature</ows:Identifier> <ows:Title>Station Temperature Measures</ows:Title> <ComplexValueReference ows:reference="http://geoinfo.dlsi.uji.es/cgi-bin/wps-test?service=WFS&version=1.0.0&request=GetFeature&typename=TempJan" schema="http://geoinfo.dlsi.uji.es/cgi-bin/wps-test?service=WFS&version=1.0.0&request=DescribeFeaturetype&typename=TempJan" /> </Input> <Input> <ows:Identifier>ElevationMap</ows:Identifier> <ows:Title>ElevationMap</ows:Title> <ComplexValueReference ows:reference="http://geoinfo.dlsi.uji.es/cgi-bin/wps-test?service=WCS&version=1.0.0&request=GetCoverage&bands=1&COVERAGE=dem&CRS=EPSG:4326&FORMAT=GEOTIFF&HEIGHT=128&WIDTH=146&BBOX=562.571355905512,4903.05270866142,660.287891338583,4988.722" /> </Input> <Input> <ows:Identifier>NumElevationZones</ows:Identifier> <ows:Title>Number of Elevation Zones</ows:Title> <LiteralValue>5</LiteralValue> </Input> </DataInputs> <OutputDefinitions> <Output> <ows:Identifier>InterpolatedTemperatureMap</ows:Identifier> <ows:Title>Interpolated temperature in each zone.</ows:Title> </Output> </OutputDefinitions> </Execute>

Como puede verse en el ejemplo de una petición Execute utilizando XML como forma de envío, el geo-servicio recibe los inputs –en este caso las mediciones de la temperatura en las estaciones meteorológicas y su localización (StationTemperatu-re) como una consulta al WFS, la capa de elevación en formato GeoTiff como una consulta al WCS (ElevationMap) y el número de zonas de elevación (NumEleva-tionZones) como un número entero– y el output a generar. El geo-servicio, de acuerdo a la especificación OGC WPS, devuelve una respuesta XML indicando si ha


finalizado satisfactoriamente o no. En caso afirmativo, la respuesta XML del geo-servicio incluye una URL desde la cual poder acceder a los resultados. En este caso, los resultados están codificados en un archivo GML [16] en el cual se presentan las temperaturas medias de cada una de las zonas de elevación indicadas y de los polí-gonos que las definen.

5. Conclusiones En un ámbito donde la comunidad científica tiene la necesidad de compartir da-

tos y funcionalidades para colaborar y economizar recursos se considera necesario la puesta en marcha de una IDE que resuelva estas necesidades, aportando un entor-no abierto e interoperable –basado en la reutilización de los componentes estanda-rizados proporcionados en ellas– facilitando la creación de nuevas aplicaciones de una manera más sencilla, flexible y escalable. Estas aplicaciones ofrecen al usuario la funcionalidad para solucionar un problema en concreto a partir de la unión y/o concatenación de operaciones simples ya existentes, en contraste con las aplicacio-nes SIG estándar, donde normalmente solo un pequeño porcentaje de las funciona-les ofrecidas es utilizado.

Para que una IDE de estas características funcione de manera global se requieren unas directivas con políticas de colaboración, de accesibilidad, y estándares que posibiliten la conexión semántica y sintáctica de cada componente, aunque no pre-tende resolver el problema de la composición de geo-servicios ad hoc [17]. Con este propósito en Europa se adopta INSPIRE como la directiva para la creación de IDEs, utilizando para la interconexión los interfaces definidos por las normas y los estándares del OGC. GMES se apoya en esta directiva para el desarrollo de unos servicios, que formando parte de una IDE, aportarán funcionalidades y datos reque-ridos en el mundo científico en el ámbito medioambiental y de la seguridad. El proyecto AWARE aporta uno de estos servicios impulsados por GMES, desarrollado mediante múltiples OGC Web Processing Services, ofreciendo un conjunto de fun-cionalidades estándar escalables y reutilizables.

La utilización de geo-servicios para el procesamiento de datos espaciales, per-mite compartir entre la comunidad científica no solo los datos sino también el pro-cesamiento (algoritmos) de los mismos. De esta forma, la capacidad de añadir geo-procesamiento distribuido en una IDE mejora la compartición de recursos (algorit-mos, datos) entre científicos (como por ejemplo científicos GMES), contribuyendo al avance de la e-Ciencia.

Agradecimientos Este trabajo ha sido parcialmente financiado por el proyecto AWARE de la Unión

Europea SST4-2004-012257.


Referencias

[1] M. K. Ramamurthy, “A new generation of cyberinfrastructure and data ser-vices for earth system science education and research”. Advances in Geo-sciences, Vol. 8, 2006.

[2] I. Foster, C. Kesselman, S. Tuecke, “The Anatomy of the Grid: Enabling Scal-able Virtual Organizations”. International Journal of Supercomputer Applica-tions, Vol. 15, No. 3, 2001.

[3] J. Graff, “E-Science Potencial”. International Ocean Systems, 6 – 7. Nov/Dic 2004.

[4] The Global Monitoring for Environment and Security (GMES): http://www. gmes.info/.

[5] AWARE Project, A tool for monitoring and forecasting Available WAter Re-source: http://www.aware-eu.info/es/home.htm.

[6] C. Granell, M. Gould, M.A. Bernabé y M.A. Manso, “Spatial Data Infrastructures”. H. Kasimi (ed.) Encyclopedia of Geoinformatics, Idea Group Press (en prensa).

[7] Federal Geographic Data Committee (FGDC): http://www.fgdc.gov. [8] K. Gottschalk, S. Graham, S. Krueger, J. Snell, “Introduction to web services

architecture”. IBM Systems Journal 41 (2), 2002, http://researchweb.watson.ibm.com/journal/sj/412/gottschalk.html (10 julio 2006).

[9] C. Granell, Reutilización de Servicios Web mediante componentes integrados. Tesis Doctoral. Departamento de Lenguajes y Sistemas Informáticos, Univer-sitat Jaume I, julio 2006.

[10] P. Smits, et al., “INSPIRE Architecture and Standards Position Paper”, Archi-tecture and Standards Working Group, 2002 http://inspire.jrc.it/documents/inspire_ast_pp_v4_3_en.pdf.

[11] Web services definition from W3C Web Services Architecture Working Group, Web Services Architecture Requirements, W3C Working Draft. http://www.w3.org/TR/2002/WD-wsa-reqs-20020819 (julio 2006).

[12] J. Martinec, A. Rango, and E. Major, “The Snowmelt Runoff Model (SRM) User's Manual”. NASA RP-1100. Greenbelt, Maryland, 1983.

[13] Open Geospatial Consortium Inc., “Web Processing Service”, discussion pa-per OGC 05-007r4, 2005.

[14] R Development Core Team, “R: A language and environment for statistical computing”. R Foundation for Statistical Computing, Vienna, Austria. http://www.R-project.org.

[15] E. J. Pebesma y C. G. Wesseling, “Gstat: a program for geostatistical model-ling, prediction and simulation”. Computers & Geosciences Vol. 24, No. 1, 1998. http://www.gstat.org.

[16] Open Geospatial Consortium Inc., “OpenGIS Geography Markup Language (GML) encoding specification”, 2004.


[17] R. Lemmens, A. Wytzisk, R. De By, C. Granell, M. Gould, P. Van Oosterom,

“Integrating Semantic and Syntactic Descriptions to Chain Geographic Ser-vices”. IEEE Internet Computing, Vol. 10, No. 5, 2006.


Unidades administrativas, una perspectiva ontológica

J. Lacasta Miguel†, F. J. López Pellicer†, J. Floristán Jusué†, J. Nogueras-Iso†, F. J. Zarazaga-Soria†

† Departamento de Informática e Ingeniería de Sistemas

Universidad de Zaragoza, María de Luna 1, 50018, Zaragoza e-mail: [email protected]

Resumen El conjunto de datos formado por las unidades administrativas que conforman la

organización territorial de un país tiene numerosas aplicaciones en una Infraestruc-tura de Datos Espaciales. Para explotarlo de forma adecuada es necesario poseer un modelo de información capaz de afrontar su diversidad. Este trabajo propone la representación de las unidades administrativas mediante una ontología de dominio, describiendo su estructura y sus usos. También se muestra su aplicación al caso particular de las unidades administrativas de España.

Palabras clave: unidades administrativas, ontologías, gazetteer, nomenclátor, identificadores geográficos.

1. Introducción Bajo el nombre genérico de “unidades administrativas”, como resultado de

cambios políticos, económicos, sociales y culturales, y para centralizar o descentra-lizar la gestión administrativa, los Estados han creado a lo largo de los siglos dife-rentes tipos de entidades de diversa naturaleza legal para cubrir ámbitos territoria-les específicos. Dado su carácter oficial, son conocidas y usadas en todos los ámbi-tos (público, privado, personal) para identificar recursos explícitamente (dónde se encuentra, a dónde se aplica) o como parte de otros identificadores de referencia (direcciones, límites administrativos, listas de entidades).

Dado su papel como datos de referencia para la construcción de otros conjuntos de datos geográficos más elaborados, las unidades administrativas se han converti-do en uno de los recursos más relevantes a publicar a través de distintas iniciativas de Infraestructuras de Datos Espaciales (IDE) que han surgido a escala local, regio-nal o nacional. De hecho, la propuesta de directiva INSPIRE para el establecimiento de una Infraestructura de Información Espacial en Europa incluye en su Anexo I a las unidades administrativas como uno de los temas prioritarios de publicación [1].


Además exige que sean publicadas cumpliendo unos determinados requisitos de calidad para facilitar la interoperabilidad de datos caracterizados geográficamente en base a ellos. Un buen ejemplo de aplicación lo encontramos en datos fronterizos. Su localización podría estar definida solo mediante sus coordenadas, pero si se utiliza adicionalmente una unidad administrativa como referencia se evitan clara-mente ambigüedades.

Las unidades administrativas distan de ser una colección estable y uniforme de tipos e instancias. Su diversidad, sus peculiaridades y su carácter evolutivo hacen necesario un modelo coherente que facilite su gestión y simplifique su uso. Este trabajo propone la representación de las unidades administrativas mediante un mo-delo general basado en una ontología de dominio reutilizable, que defina los con-ceptos básicos de las unidades y sus relaciones, y una serie de ontologías de aplica-ción, cada una describiendo en detalle los tipos de unidades administrativas especí-ficos de un país y sus instancias.

El capítulo se organiza como sigue. La sección 2 describe el estado del arte en la caracterización de las unidades administrativas. La sección 3 describe la ontolo-gía creada y sus características. La sección 4 muestra los usos que dicha ontología puede tener en una IDE. Termina con unas conclusiones y trabajo futuro.

2. Estado de la cuestión en la caracterización de las unidades administrativas

Un Estado para organizar su territorio define mediante leyes qué tipos de unida-

des administrativas pueden existir dentro de un área determinada y qué atribucio-nes legales tienen. Entre ellas puede estar la potestad de organizarse a su vez de forma autónoma creando nuevas unidades de orden inferior. Las unidades adminis-trativas creadas pueden con el tiempo cambiar de forma, fusionarse con otras e incluso, si hay un cambio en la norma legal, evolucionar a otro tipo de entidad. Este conjunto de características hace que no solo diferentes países tengan distintos tipos de unidades administrativas, sino que distintas zonas de un mismo país tengan tipos distintos, no necesariamente relacionados.

Existen numerosos trabajos que describen diferentes modelos generales para re-presentar cualquier tipo de entidad geográfica [2, 3], e incluso estándares interna-cionales como ISO 19109 [4]. En el ámbito más restringido de las unidades admi-nistrativas existen recopilaciones de los modelos administrativos de los distintos países usando distintos modelos de organización del conocimiento, en forma de listas [5], tesauros [7], u ontologías [8]. El estándar internacional ISO 19112 [9] describe el modelo lógico de un diccionario de nombres geográficos autorizados (nomenclátor), permitiendo describir las unidades administrativas como una jerar-quía, pero no considera problemas como las especializaciones de tipos, el multilin-güismo o la duración temporal (entendida como extensión temporal en el mundo legal).


El principal problema de los modelos y recopilaciones citados es la falta de una semántica adecuada en la representación de los tipos de unidades administrativas y las relaciones espaciales, temporales y de dependencia que presentan. Además, los datos que contienen o no son exhaustivos, presentando solo partes del modelo de unidades administrativas de uno o varios países o no se garantiza que los nombres usados para identificar las unidades sean los oficialmente reconocidos.

3. Ontología de unidades administrativas Para solventar los problemas de representación señalados en el punto anterior y

siguiendo el esquema descrito por Guarino [10], se ha creado un modelo de ontolo-gías (véase figura 1) en tres niveles: (1) una ontología de alto nivel que define tipos de datos y relaciones generales e independientes del contexto; (2) una ontología de dominio donde se definen los conceptos y relaciones reutilizables en el contexto de los modelos administrativos de diferentes países; (3) y una ontología de aplicación por país, donde se representan los tipos específicos de unidades administrativas de cada país, junto con las instancias concretas ya existentes.

Como ontología de alto nivel, se ha seleccionado la descrita en [11] por conte-ner todos los conceptos y relaciones básicas necesarias para construir la ontología de dominio. Esta ontología mezcla los conceptos de alto nivel de Wordnet [12], PENMAN [13] y CYC [14] entre otros, como una extensión de la ontología propuesta por Sowa [15]. El uso de esta ontología de alto nivel en otros entornos simplifica la combinación de nuestra ontología de dominio con otras ya existentes.

Dado que las unidades administrativas representan dominios legales cuya exis-tencia se basa en una norma oficial con carácter de ley que los regula, la ontología de dominio está basada en los conceptos generales de “Norma Reguladora” y “Dominio Legal”. Además, dada la organización jerárquica de los países, es habi-tual que una norma dé validez a otras para regular administrativamente zonas espe-cíficas. En la ontología, las unidades administrativas son especializaciones de un “Dominio Legal” y distinguimos cuatro tipos, “estado”, “división”, “organización” y “agrupación”. Los tres primeros son equivalentes a los dominios jurisdiccionales básicos definidos en ISO 15944-5 [16]. Así, un “estado” es una entidad que tiene naturaleza legal propia y con la cualidad de reconocimiento entre pares. Las divi-siones son las distintas particiones del territorio de un estado, y de entre ellas con-sideramos el “Municipio” como la entidad básica de división, agrupándose entre ellos para formar subdivisiones mayores o dividiéndose para formar entidades me-nores. Las organizaciones son agrupaciones de dominios jurisdiccionales, creadas con una finalidad determinada (ONU, Euro-regiones de la UE). A esos tres tipos básicos se añade el concepto “agrupación”. Se utiliza para tratar jerarquías funcio-


-nam

e[1]

: Id

entif

ier

-app

licat

ionA

rea[

1] :

Lega

l Dom

ain

-val

idity

[1] :

Tim

ePer

iod

-res

pons

ibili

ty[1

..*] :

Res

pons

ibili

ty

Reg

ulat

ory

Nor

m

10.

.*

clas

sifie

s4

+offi

cial

Nam

e[1]

: Id

entif

ier

-tran

slat

ion[

lang

][0..*

] : [N

atur

alLa

ngua

ge]D

escr

iptio

n-a

ltNam

es[la

ng][0

..*] :

[Nat

ural

Lang

uage

]Des

crip

tion

+app

licat

ionA

rea[

1] :

Gra

phM

odel

+tim

ePer

iod[

1] :

Tim

ePer

iod

Lega

l Dom

ain

Stat

e

0..*

0..*

unio

nOf4

Espa

ña: S

tate

Prov

inci

a

Prov

inci

a :

Reg

ular

oty

Nor

m

Div

isio

n

0..1

0..*

inLo

catio

n4

Agr

upat

ion

1..*

0..*

3 un

ionO

fEqu

ival

ents

Álav

a : P

rovi

ncia

Mun

icip

ality

Min

or E

ntity

Sub

Div

isio

n

-adm

inis

trativ

e-c

ensu

s tra

cts

-pos

tal d

istri

ct-s

choo

l dis

trict

s-..

.

«Con

trolle

dLan

guag

e»R

espo

nsib

ility

10.

.*

3 in

Loca

tion

Spai

n : R

egul

ator

y N

orm

Com

arca

Cua

drill

a

Com

arca

: R

egul

ator

y N

orm

La G

uard

ia-R

ioja

Ala

vesa

: C

uadr

illaCua

drill

a : R

egul

ator

y N

orm

3 in

Loca

tion

3 in

Loca

tion

0..*

0..* u

nion

Of4

10.

.*

3 in

Loca

tion

0..1

0..*

3 in

Loca

tion

Org

aniz

atio

n

NU

T3

offic

ialN

ame

: Ide

ntifi

ertra

nsla

tion[

lang

] : [N

atur

alLa

ngua

ge]D

escr

iptio

nal

tNam

es[la

ng] :

[Nat

ural

Lang

uage

]Des

crip

tion

appl

icat

ionA

rea

: Gra

phM

odel

timeP

erio

d : T

imeP

erio

d

Álav

a : N

UT3

3 un

ionO

fEqu

ival

ents

-Spat

ialE

ntity

-aut

hor :

Cau

salE

ntity

Nor

m

10.

.*

clas

sifie

s4

Top

Leve

l Ont

olog

y

Dom

ain

Ont

olog

y

Appl

icat

ion

Ont

olog

y

Inst

ance

s

Com

unid

ad A

uton

oma

Com

unid

ad A

uton

oma

: Nor

ma

Reg

ulad

ora

Pais

Vas

co :

Com

unid

ad A

uton

oma

3 in

Loca

tion

0..*

1

subN

orm

4

-Tim

ePer

iod

-Gra

phM

odel

… …

...

Figura 1. Ontología de Unidades Administrativas


nales con propósitos distintos al organizativo. Un claro ejemplo son las NUTS [17], divisiones de la Unión Europea establecidas con fines estadísticos y que crean divi-siones artificiales. Por ejemplo, establece la división “noroeste” de España que cubre las comunidades autónomas de Galicia, Principado de Asturias y Cantabria.

Para modelar los tipos de unidades específicos de un país, se ha creado una on-tología de aplicación que extiende los tipos descritos en la ontología de dominio y que ha sido enriquecida con las instancias existentes para los tipos definidos. En este primer paso nos hemos centrado en el caso de España, sin perder de vista la futura generación de las de los países limítrofes, creando la ontología de aplicación de las unidades administrativas por encima del municipio. Los datos utilizados son los proporcionados por el Registro de Entidades Locales del Ministerio de Admi-nistraciones Públicas, entidad encargada de recopilar los nombres oficiales de las unidades administrativas de España (asignados por las administraciones competen-tes), y por el Instituto Nacional de Estadística, que aporta información sobre los cambios año por año.

Las unidades administrativas tienen un “área de aplicación” la cual gestionan. Para representarla, los distintos modelos citados anteriormente han usado aproxi-maciones diferentes: un punto, un bounding box o mediante una geometría más o menos detallada. En los dos primeros casos se produce una gran pérdida de infor-mación, y aunque existen técnicas para regenerar las extensiones espaciales de una colección de datos usando como base el centroide o el bounding box [18] solo pro-ducen resultados aproximados, que aunque pueden ser suficiente para ciertos usos, no bastan si se quiere identificar de forma precisa la unidad administrativa a la que pertenece cierta entidad espacial. Por ello, en nuestra ontología de unidades de España, incluimos la información de geometrías proporcionadas por el Instituto Geográfico Nacional, organismo encargado en España de mantener las líneas límite entre jurisdicciones.

La experiencia nos ha mostrado que es muy frecuente que si algún servicio de una IDE necesita las unidades administrativas solo necesita un pequeño número de ellas y de sus relaciones, sin ser necesario que el sistema contenga toda la ontolo-gía. Por ejemplo, en un servicio web que proporcione el inventario del patrimonio industrial de Aragón, solo es necesario que tenga un subconjunto de la organiza-ción jerárquica de la comunidad (municipios y provincia a la que pertenecen), por lo que es irrelevante el resto del contenido de la ontología. En estos casos es intere-sante poder generar vistas, adaptadas a las necesidades de cada servicio, que solo contengan los elementos y relaciones que se necesiten. Dichas vistas, cuando sean usadas para los usos descritos en la siguiente sección, es conveniente que sean pre-sentadas en forma de estructuras jerárquicas tales como tesauros con el objetivo de simplificar su uso. Como formato de almacenamiento e intercambio de las vistas se ha decidido usar SKOS [19], ya que se está estableciendo como estándar de facto en la web semántica para la representación de modelos simples de conocimiento. Di-chas vistas pueden ser proporcionadas a los distintos servicios de la IDE para tareas de creación de metadatos o búsqueda, tanto clásica (buscador con un selector de


unidades) como exploratoria (creación de un mapa de tópicos de unidades ajustado a la colección de metadatos).

4. Aplicaciones de la ontología de unidades administrativas En [20] se detallan los usos que las ontologías léxicas pueden proporcionar a

una IDE y que se pueden resumir en: facilitar la creación del contenido de los meta-datos, facilitar las consultas a servicios y facilitar la armonización del contenido. La ontología de unidades administrativas puede tener estos mismos usos en ciertos contextos, pero la geometría asociada posibilita otros nuevos usos descritos aquí.

4.1. Facilitar la creación del contenido de los metadatos En una IDE, los recursos de información almacenados están descritos mediante

metadatos [21], con el objetivo de mejorar los procesos de recuperación de la in-formación; pero esta mejora depende principalmente de la calidad de su contenido. Una forma de mejorar el contenido es el uso para ciertos campos de un vocabulario previamente determinado, de forma que se aumente su homogeneidad y se simpli-fiquen los procesos de recuperación de información. Aquí, el uso de una ontología para modelar la terminología permite además razonar sobre ella.

En este contexto, las herramientas de creación de metadatos pueden usar la on-tología creada para proporcionar a los usuarios toda o parte de la jerarquía de uni-dades administrativas de un país y sus vecinos. Además, pueden hacer uso de la información espacial asociada para generar de forma automática el subconjunto de unidades administrativas que intersectan o contienen la posición espacial extraída del dato asociado o del bounding box ya creado en el metadato. Por ejemplo, el metadato del catálogo de IDEZar que describe el campo eólico de “Los Labrados” ha sido elaborado por una herramienta que no utiliza esta ontología, siendo asigna-do por error únicamente al municipio de Zaragoza a pesar de parte de él está en los municipios de Cuarte de Huerva y Cadrete.

4.2. Facilitar consultas a servicios Dentro del proceso de consulta de los servicios de una IDE, el uso de restriccio-

nes de carácter espacial es habitual, tanto en catálogos de datos, como en nomen-clátores, servidores de mapas o servidores de coberturas. Gracias a que en nuestra ontología almacenamos la geometría de las unidades, y dado que cubren todo el territorio de un país a distintos niveles, los servicios de búsqueda que la usen pue-den proporcionar los nombres de las unidades para fijar restricciones espaciales a las consultas, y luego ejecutar las búsquedas en base a la geometría espacial aso-ciada.


El servicio de acceso al catálogo de datos es un caso especial dado que los me-tadatos contienen palabras claves de lugar con los nombres de las unidades admi-nistrativas que contienen el dato referenciado. Por tanto, se puede hacer directa-mente una búsqueda temática (con restricciones de tipo “contenido jurídicamente en”), pero pudiendo aprovechar la existencia de la geometría de las unidades admi-nistrativas para los casos en que las palabras clave de lugar no estén introducidas en los metadatos y para permitir cierto grado de restricciones topológicas (“adya-cente a” y “contenido espacialmente en”). Así pues, una consulta que contenga como restricción la unidad “Zaragoza” (municipio) devolvería todos los metadatos que en sus palabras clave de lugar contienen el municipio de Zaragoza o cuyo bounding box, según el tipo de restricción indicada, está contenido, intersecta o cubre el polígono de Zaragoza.

La existencia de una jerarquía detallada de tipos de unidades existentes y la asignación de estos tipos a las instancias, simplifica la localización de recursos en áreas fronterizas en las que los tipos de unidades administrativas existentes son diferentes. Por ejemplo si estamos buscando los “municipios” con instalaciones de esquí existentes en una zona fronteriza de los pirineos entre España y Francia, la ontología permite descubrir que las “municipalités” francesas son equivalentes a los “municipios” españoles, y así poder mostrar la “municipalité” de Luz-Saint Sauveur que contiene la estación de esquí de Luz-Ardiden. También la existencia de tipos permite recuperar las unidades administrativas de un área geográfica que tengan una funcionalidad concreta, tales como distritos o secciones censales.

4.3. Facilitar la armonización del contenido La ontología de unidades administrativas también facilita la armonización de los

metadatos procedentes de otras organizaciones u otros dominios de aplicación con respecto de los metadatos ya existentes en el sistema y todos ellos respecto a las búsquedas realizadas por los usuarios.

En [20] se describe un proceso de armonización de ontologías léxicas basado en el uso de Wordnet [11], pero este proceso no es aplicable para las unidades admi-nistrativas ya que Wordnet no es exhaustivo (solo incluye países, regiones y capita-les de regiones). A pesar de esto, ciertas tareas de armonización pueden realizarse. La comparación de las etiquetas alternativas a los nombres oficiales y la geometría existente en la ontología, con el texto existente en las palabras clave de lugar y el bounding box del metadato, ayuda a detectar errores en los metadatos y corregirlos. Además, la ontología también puede ser usada como base de conocimiento para la identificación de unidades administrativas en consultas realizadas por un usuario. Por ejemplo, si se pregunta por “parques eólicos de Zaragoza”, se obtendría la pro-vincia y el municipio en Aragón y la población de Lugo, dejando al usuario la se-lección de la adecuada. Para facilitar esta tarea, se le puede proporcionar toda la información disponible en la ontología (nombres oficiales y alternativos, jerarquía organizativa y posición espacial).


5. Conclusiones En este capítulo se ha presentado una ontología de unidades administrativas pa-

ra modelar las divisiones administrativas de un país y se han descrito las ventajas que aportaría la inclusión de dicha ontología dentro de una IDE. El modelo presen-tado esta organizado en tres capas: una ontología de alto nivel que define tipos de datos y relaciones generales e independientes del contexto; una ontología de domi-nio donde se definen los conceptos y relaciones reutilizables en el contexto de los modelos administrativos de diferentes países; y una ontología de aplicación donde se representan los tipos específicos de unidades administrativas de un país junto con sus instancias. Respecto a los usos en una IDE, la existencia de una geometría asociada a las unidades permite facilitar la creación del contenido de los metadatos, las consultas a servicios y la armonización del contenido.

Los siguientes pasos de este trabajo consistirán en desarrollar un proceso auto-mático de generación de las instancias a partir de la información origen para los casos de España y Francia, y su integración real dentro de una IDE para mostrar su potencial real de aplicación. Además, se analizará el problema del mantenimiento de la información referenciada, ya que la alta frecuencia de cambios existente en la organización administrativa de un país (forma, estructura, nombre o potestades administrativas) hace que un gran número de metadatos se queden desfasados res-pecto a la situación administrativa real.


C02-01 del Plan Nacional de Investigación Científica y Desarrollo Tecnológico del Ministerio de Educación y Ciencia de España. El trabajo de J. Lacasta (ref. B139/2003) y J. López (ref. B136/2006) ha estado parcialmente financiado por una beca del Gobierno de Aragón.

Referencias

[1] Commission of the European Communities (CEC), “Proposal for a Directive of the European Parliament and of the Council establishing an infrastructure for spatial information in the Community (INSPIRE)”. COM (2004) 516 final, 2004/0175 (COD).

[2] D. Manov, A. Kiryakov, B. Popov, D.Ognyanoff, M. Goranov, “Experiments with Geographic Knowledge for Information Extraction”. Workshop of Analysis of Geographic References. Edmonton, Canada, 2005.


[3] R. Irie, B. Sundheim, “Resources for Place Analysis”. Fourth International Conference on Language Resources and Evaluation-LREC 2004, Lisboa, Portugal, 2004.

[4] ISO 19109: 2005, “Geographic information -- Rules for application schema”, International Organization for Standardization (ISO).

[5] Registro de entidades locales del GDAL: http://www.gdal.map.es/. [6] Relación de municipios del Instituto Nacional de Estadistica (INE):

http://www.ine.es/ [7] Tesauro EUROVOC extendido por el senado para incluir los municipios de

España: http://www.senado.es/basesdedatos/index.html. [8] M. S. Chaves, M. J. Silva, y B. Martins, “A Geographic Knowledge Base for

Semantic Web Applications”. Proc. of the 20th Brazilian Symposium on Databases, Minas Gerais, Brasil, octubre 2005.

[9] ISO 19109: 2003, “Geographic information – Spatial referencing by geographic identifiers”, International Organization for Standardization (ISO).

[10] N. Guarino, “Formal Ontologies and Information Systems”. Proceedings of FOIS'98, Trento, Italia, 1998.

[11] P. Martin, “Using the WordNet Concept Catalog and a Relation Hierarchy for Knowledge Acquisition”, Proceedings of 4th International Workshop on Peirce, University of California, Santa Cruz, agosto, 1995.

[12] C. Fellbaum (ed.), “Wordnet, An Electronic Lexical Database”. MIT Press, 1998.

[13] J. Bateman. “Upper modeling: Organizing knowledge for natural language processing”, Proc. of Fifth International Workshop on Natural Language Generation, Pittsburgh, PA, 1990.

[14] D. Lenat, R.Guha. Building large knowledge-based systems: representation and inference in the Cyc project, Addison-Wesley, 1990.

[15] J. Sowa. “Conceptual Graphs Summary. In Conceptual Structures: current research and practice”, Horwood Workshops, England , Ellis, 1992.

[16] ISO 15944-5: 2005, “Information technology – Business Agreement Semantic Descriptive Techniques. Part 5: Identification and Mapping of Various Categories of Jurisdictional Domains”, International Organization for Standardization (ISO).

[17] Regulation (EC) No 1059/2003 of the European Parliament and of the Council of 26 May 2003 on the establishment of a common classification of territorial units for statistics (NUTS) (Official Journal L 154, 21/06/2003).

[18] H. Alani, C. Jones, D. Tudhope, “Voronoi-based region approximation for geographical information retrieval with gazetteers”, International Journal of Geographical Information Science. Vol. 15, No. 4, 2005.

[19] A. Miles, B. Matthews, M. Wilson. “SKOS Core: Simple Knowledge organization for the WEB”. Proceedings of the International Conference on Dublin Core and Metadata Applications, 2005.


[20] J. Lacasta, P. Muro, J. Nogueras, J. Zarazaga, “Web Ontology Service, a key

component of a Spatial Data Infrastructure”, Proceedings of the 11th EC GI & GIS Workshop, Alghero, Sardinia (Italia), julio 2005.

[21] ISO 19115: 2003, “Geographic information – Metadata”, International Organization for Standardization (ISO).

[22] ISO 15836: 2003, “Information and documentation – The Dublin Core metadata element set”, International Organization for Standardization (ISO).


Ingeniería ontológica: el camino hacia la mejora del acceso a la información

geográfica en el entorno web

L. M. Vilches Blázquez†, A. F. Rodríguez Pascual†, M. A. Bernabé Poveda‡

† Subdirección General de Aplicaciones Geográficas. Instituto Geográfico Nacional.

Calle General Ibáñez de Íbero, 3, 28003, Madrid. e-mail: {lmvilches, afrodriguez}@fomento.es

‡ ETSI Topografía, Geodesia y Cartografía.

Universidad Politécnica de Madrid. Autovía de Valencia Km. 7.5, 28031, Madrid.


Resumen La consideración actual de interoperabilidad se centra en el establecimiento de

un lenguaje común que permite difundir y compartir cualquier tipo de información geográfica. Esto es lo que se ha dado en llamar interoperabilidad sintáctica. Tal concepción obvia los problemas derivados de la heterogeneidad semántica de la geo-información.

Las formas actuales de organización de la geo-información (catálogos de fenó-menos y tesauros) no son eficaces para solucionar los problemas derivados de la integración semántica de conjuntos de geodatos. Por ello, el desarrollo de ontologí-as se presenta como el instrumento adecuado para alcanzar interoperabilidad se-mántica en el entorno de las Infraestructuras de Datos Espaciales.

Este capítulo, también, presenta un caso de uso en el que se describen las prin-cipales características de una ontología marco de fenómenos hidrográficos con vistas a ser implementada en la IDEE. Dicha ontología tiene como objetivo definir un modelo de explotación más eficaz en la consulta, acceso y recuperación de la geo-información en el entorno web.

Palabras clave: ontología, web semántica, ingeniería ontológica, información geográfica, catálogo de fenómenos, tesauro, infraestructura de datos espaciales, IDEE.


1. Introducción Una de las principales motivaciones para el desarrollo de la Infraestructura de

Datos Espacial (IDE) es hacer más eficiente el trabajo con los geodatos [1, 2]. Para ello, se crean los estándares del Comité Técnico 211 del International Organiza-tion for Standardization (ISO/TC 211, www.isotc211.org), World Wide Web Con-sortium (W3C, www.w3.org) y del Open Geospatial Consortium (OGC, http://www. opengeospatial.org) con los que se resuelven problemas derivados de la diferencia de formatos de información, consiguiendo interoperabilidad, es decir [3]:

“la capacidad de comunicarse, para ejecutar programas, o para transferir da-tos entre varias unidades funcionales de una manera que requiera al usuario tener poco o nada de conocimiento de las características únicas de esas uni-dades”.

Con esto se alcanza una sintaxis homogénea para datos y servicios geográficos, es decir, interoperabilidad sintáctica.

La información ofrecida a través de los diferentes servicios –Web Map Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS), etc.– debe ser almacenada, ofertada y mantenida al nivel más adecuado [4]. Pero es generada, mantenida y actualizada por diversos productores, originando gran disparidad de fuentes y terminología. Adicionalmente, y debido a lo anterior, se encuentran dife-rencias de escala, tratamiento e interés. Esta situación no facilita los procesos de búsqueda, acceso e interpretación a la Información Geográfica (IG), resultado de la ausencia de una interoperabilidad semántica.

Este capítulo está dirigido a la comunidad geográfica que está interesada en co-nocer los avances tecnológicos en las IDEs con repercusión directa sobre la IG. A continuación, se describe el estado de estructuración actual de la geo-información. En la sección 3 se realiza una introducción al concepto de ontología, citando algu-nas de sus ventajas y posibilidades. Un breve comentario sobre las características de una ontología marco de fenómenos hidrográficos se realiza en la sección 4. Fi-nalmente, en la sección 5 se proporcionan algunas conclusiones y líneas de trabajo futuro.

2. Organización actual de la Información Geográfica La IG alojada en los servicios web de las IDEs presenta contenidos y estructuras

heterogéneas, derivados de la falta de consenso y de las inercias de los procesos de producción. Estos factores obstaculizan la consecución de una interoperabilidad sensu stricta (sintáctica y semántica) generando dificultades en las tareas de con-sulta, recuperación, explotación, actualización y visualización de la geoinforma-ción, en las que el usuario demanda sencillez, eficacia y seguridad.


Actualmente, la modelización semántica de la IG, es decir, la estructuración de los nombres, códigos, atributos y otras características asociadas a la geometría, es pobre y rudimentaria en la mayoría de los sistemas informáticos que la gestionan, ya sean Sistemas de Información Geográfica (SIG) o Infraestructuras de Datos Es-paciales (IDEs). Esto dificulta la posibilidad de conseguir eficientes búsquedas, accesos y recuperaciones de dicha información, consecuencia de las formas de estructuración de fenómenos geográficos empleadas por las organizaciones produc-toras de cartografía en nuestro país, entre las que destacan el catálogo de fenóme-nos y los tesauros.

En primer lugar, el catálogo de fenómenos (feature catalogue) es la forma más sencilla y utilizada para la organización de los conceptos asociados a la pura geo-metría (puntos, líneas, polígonos y textos) que describen la IG. Se corresponde con un simple listado de fenómenos geográficos agrupados en clases homogéneas, por ejemplo: municipio, montaña, acequia, iglesia, carretera, etc. Normalmente cada clase viene identificada por un código único que sirve para marcar las instancias (el municipio de Madrid, el Teide o la catedral de Burgos) pertenecientes a cada clase y que, eventualmente, pueden ir acompañadas de una definición y un conjunto de atributos.

Este listado posee importantes limitaciones, tales como la ausencia de cualquier tipo de estructuración y de relación entre elementos de manera explícita. Lo único que puede encontrarse, en ocasiones, es una jerarquía entre clases de fenómenos, determinada por los códigos asociados a las mismas. La norma internacional ISO 19110 Geographic Information – Methodology for Feature Cataloguing (http:// www.iso.org) establece cómo crear y describir de manera normalizada un catálogo de fenómenos.

Por otro lado, los tesauros, referencia básica de multitud de trabajos de todas las áreas de conocimiento, son vocabularios controlados que manifiestan relaciones, tanto semánticas como genéricas, entre conceptos que reflejan una parte del cono-cimiento. Con su uso se describe, básicamente, las relaciones entre los campos semánticos de cada término, considerando la inclusión de unos en otros, la simili-tud o la existencia de cierto solape, sin describir más matices.

En la actualidad, existen dos normas internacionales para la construcción de te-sauros, concretamente, la ISO 2788-1986 (http://www.iso.org), orientada a la crea-ción y desarrollo de tesauros monolingües y la ISO 5964-1985 (http://www.iso.org), dirigida a los tesauros multilingües. Estas normas han sido adoptadas y traducidas por la Asociación Española de Normalización y Certificación (AENOR, http://www. aenor.es).

La construcción de tesauros supone una considerable mejora en la estructura-ción de la información respecto a los catálogos de fenómenos. Este hecho deriva de la desaparición de la imprecisión y ambigüedad en el uso del lenguaje, motivada por la existencia de sinónimos y polisemias, y del establecimiento de relaciones (por ejemplo, término genérico, término específico, use, etc.) entre los conceptos. Estas mejoras provocan un leve acercamiento hacia la consecución de cierta inter-


operabilidad semántica, pero aún con muchas limitaciones, consecuencia de la sim-plicidad de las relaciones y de su falta de entendimiento con las máquinas.

En definitiva, las formas de organización actuales no facilitan la integración semántica del conjunto de la información, debido a sus carencias estructurales y a su ausencia de legibilidad por las máquinas, ya que están pensadas y realizadas para ser entendidas por el hombre. Por estos motivos, la gestión más sencilla y rutinaria de los datos se hace complicada y, en ocasiones, harto difícil. Además, esta situación provoca el incremento del coste en tiempo de cualquier información conseguida en la red, a pesar de la potencia y sagacidad crecientes de los buscado-res actuales disponibles.

3. Ontologías Las limitaciones estructurales, comentadas anteriormente, y la utilización de di-

versos vocabularios para describir la información presente en los servicios IDEs, evidencian diversos problemas que se manifiestan al preguntar e interpretar resul-tados producidos por la búsqueda sobre diferentes catálogos distribuidos [5]. Esto refleja la necesidad de un cambio que tenga como objetivo proporcionar un salto cualitativo, en funcionalidad y posibilidades, a la IG presente en la web.

La ingeniería ontológica, surgida de la web semántica (http://www.w3.org/ 2001/sw) proporciona los requisitos necesarios para mejorar las búsquedas de IG. Esta mejora se debe a que en lugar de utilizar palabras clave en los procesos de búsqueda, se centra en los significantes de los conceptos, es decir, en la semántica de la información. De esta manera, se obviará la asunción de que los datos deben ser entendidos exclusivamente por los usuarios y se pasará a un proceso de enten-dimiento recíproco entre hombre y máquina, en el que las máquinas pasarán a “comprender” los datos que procesan, actuando sin la necesaria y continuada su-pervisión actual.

Circunscribiéndose a las ontologías, una de las definiciones más divulgadas es la aportada por [6], que afirma que una ontología constituye “una especificación explícita y formal de abstracciones mentales, las cuales se conforman mediante un acuerdo de la comunidad experta en un dominio y en un diseño para un propósito específico”. Las “abstracciones mentales” establecen vocabularios que reflejan los fenómenos de la realidad a través de conceptos consensuados por una comunidad experta [7, 8, 9]. Por otro lado, la especificación formal de un vocabulario se puede dar en forma de lista plana de palabras, diccionario, taxonomía, diagrama Entidad-Relación, modelo UML (Unified Markup Language), esquema de XML (eXtensible Markup Language) y muchos otros posibles [10]. Además, [11] sostiene que las ontologías definen un “conjunto de relaciones entre sus términos, así como las re-glas que combinan términos y relaciones que amplían las definiciones dadas en el vocabulario”.

Entre las ventajas proporcionadas por las ontologías destacan: (i) la disminución de la confusión semántica. Reduce la ambigüedad terminológica al considerar si-


nónimos y polisemias, repercutiendo sobre la comunicación; (ii) la posibilidad de reutilización de conocimientos. Esto permite el aprovechamiento de ontologías realizadas sobre cualquier área de la IG, consecuencia de que el desarrollo de onto-logías refleja formas concretas de ver el mundo; (iii) la traducción e intersección semántica a través de mappings (cotejos) empleados para describir corresponden-cias entre fenómenos (por ejemplo, river, rivière y fleuve) y entre diferentes onto-logías (por ejemplo, ontología de fenómenos hidrográficos y ontología de las ciu-dades).

De esto se deduce que las ontologías constituyen el complemento ideal para las IDEs, más aún una vez que éstas comienzan a extenderse concediendo acceso pú-blico y abierto a la geo-información mediante múltiples servidores y servicios.

A diferencia de las formas de organización actuales, la construcción de ontolo-gías se presenta como una buena solución para alcanzar la interoperabilidad semán-tica entre los diferentes catálogos de IG. De esta manera se originará una importante mejora en la representación de esta información, que repercutirá de forma directa en los sistemas de minería de datos.

En definitiva, las ontologías deben permitir conceptualizar el conocimiento, ge-nerando formas comunes y compartidas de ver el mundo, y ayudar a que los siste-mas gestionen más información que datos, consecuencia de que el experto ha cedi-do parte de su conocimiento a los sistemas.

4. Un caso de uso: ontología de fenómenos hidrográficos El IGN ha comenzado a desarrollar una ontología de fenómenos hidrográficos,

con la pretensión de establecerla como un marco semántico genérico y de uso para todas las organizaciones productoras. Su objetivo es optimizar la búsqueda y recu-peración de la IG soportada por la Infraestructura de Datos Espaciales de España (IDEE).

4.1. Modelado de la ontología hidrográfica El modelado de esta ontología está basado, fundamentalmente, en cuatro crite-

rios: • La Directiva Europea Marco del Agua [12]. • Criterios semánticos, es decir, clasificación acorde a los significados. • La clasificación y estructura reflejada en el proyecto SDIGER (IDE para la

gestión de las cuencas de los ríos Adour-Garonne y Ebro) [13]. • La herencia de las fuentes de estudio, para facilitar posibles mappings y para ser

consecuente con las jerarquías de fenómenos creadas por los expertos.


4.2. Fuentes Debido a la pretensión de establecerse como modelo de convergencia se han te-

nido en cuenta multitud de fuentes de información a diferentes escalas (EuroGlo-balMap, EuroRegionalMap, bases cartográficas numéricas del IGN, diccionarios de datos de productores autonómicos, tesauro de la UNESCO, GEMET, etc).

En esta ontología aparecen alrededor de 100 conceptos relevantes pertenecien-tes al dominio de la hidrografía, incluyendo conceptos como río, embalse, mar, laguna, estuario, rápido, etc.

4.3. Relaciones ontológicas Los diferentes conceptos que componen esta ontología aparecen estructurados

en una taxonomía y relacionados mediante cuatro relaciones taxonómicas: subcla-se-de, descomposición-disjunta, descomposición-exhaustiva y partición.

Un concepto C1 es subclase-de otro concepto C2 si y sólo si todas las instancias de C1 son también instancias de C2 [14].

Una descomposición-disjunta de un concepto C es un conjunto de subconceptos de C que no tienen instancias comunes y que no cubren C, es decir, puede haber instancias del concepto C que no son instancias de ninguno de los conceptos que forman la descomposición [14]. Un ejemplo de esta relación aparece en la figura 1.

Una descomposción-exhausitva de un concepto C es un conjunto de subconcep-tos de C que lo cubren, es decir, tal que no existe ninguna instancia de C que no sea instancia de al menos uno de los conceptos de la descomposición. Los conceptos que pertenecen a este conjunto pueden tener instancias y subconceptos comunes [14]. La figura 2 muestra un ejemplo de este tipo de relación.

Figura 1. Ejemplo de Descomposición-Disjunta

Descomposición-Disjunta

Depósito

Capacidad: floatProfundidad: floal

EstanqueUso: Ornamental

CharcaUso: Riego

PiscinaUso: Recreacional

AbrevaderoUso: Ganado

subclase subclase


Descomposción-Exhausitva

Aguas_Marinas

Navegable: Tipo_Navegable

Aguas_Costeras

Distancia: 1 mila

Aguas_Territoriales

Distancia: 12 millas

Zona_Contigua

Distnacia: 24 millas

Alta_mar

Distancia: +200 millas

Area_Economica_Exclusiva

Distancia: 200 millas

subclase subclase subclase subclase

Figura 2. Ejemplo de descomposición-exhausitva

Una partición de un concepto C es un conjunto de subconceptos de C que no tienen instancias ni subconceptos comunes y que cubren C [13]. Un ejemplo de partición es mostrado en la figura 3.

Partición

Aguas_Continentales

Aguas_Superficiales Aguas_Subterráneas

subclase

Figura 3. Ejemplo partición

El siguiente paso del proceso de construcción de esta ontología fue la construc-ción de un diccionario de conceptos hidrográficos, consecuencia de la ausencia generalizada de definiciones en las fuentes consultadas. De esta manera, se contri-buye al respaldo semántico de la IG. A continuación, se establecieron relaciones ad hoc entre los diferentes conceptos. Este tipo de relaciones, contribuyen de forma explícita al enriquecimiento de la ontología, logrando un sistema mucho más po-tente y eficaz. Un ejemplo de esta relación en la figura 4.

Rio Mardesemboca

0..* 0..1 Figura 4. Ejemplo de relación ad hoc

El último paso conducirá a la implementación de esta ontología en la IDEE. Con-

tribuirá a gestionar esta información de manera más eficiente y autónoma, consi-guiendo resolver las dificultades estructurales de la IG y armonizar un marco homogéneo con el que caminar hacia la interoperabilidad semántica.


5. Conclusiones y trabajo futuro La consideración actual de interoperabilidad se circunscribe a la homogeneiza-

ción de la sintaxis de comunicación e intercambio, obviando el contenido de la información (semántica). La implementación de ontologías en las IDEs actuales puede conducir a importantes mejoras en los procesos de búsqueda, acceso, proce-samiento y explotación de la IG. Este hecho dará lugar a la apertura de nuevos hori-zontes y posibilidades en los usos y utilidades de los servicios IDE, derivando en un aumento de la confianza sobre la red, su utilidad y su uso. Por tanto, las ontologías se presentan como el instrumento más eficaz para alcanzar la interoperabilidad semántica que la IG necesita.

La siguiente fase del trabajo irá encaminada al enriquecimiento de esta ontolo-gía marco mediante la definición de constantes, axiomas formales y reglas. Ade-más, se procederá al poblamiento de instancias obtenidas de diferentes fuentes. De esta manera, se pretende contribuir a la formación de una ontología más completa y potente. No obstante, se prevé la ampliación de la construcción de ontologías a otros dominios del catálogo de fenómenos del IGN.

Referencias

[1] L. McKee, Who wants a GDI?, In Geospatial Data Infrastructure – Concepts, cases and good practice, Oxford University Press, New York, 2000.

[2] D. Nerbert, “Developing Spatial Data Infrastuctures: The SDI Cookbook”, Version 1.1, Global Spatial Data Infrastructure, Techical Committee. 2001

[3] ISO/TC-211 & OGC, “Geographic information Services Draft ISO/DIS 19119. OpenGis Service Architecture”. vs.4.3. Draft Version, ISO & OGC. 2002.

[4] Commission of the European Communities, “Proposal for a Directive of the European Parliament and of the Council establishing an infrastructure for spatial information in the Community (INSPIRE)”, COM(2004) 516 final, 2004/0175 (COD), 2004.

[5] L. Bernad, U. Einspanier, S. Haubrock, S. Hübner, W. Kuhn, R. Lessing, M. Lutz, U. Visser, “Ontologies for intelligent search and semantic translation in Spatial Data Infrastructures”, Photogrammetrie - Fernerkundung - Geoinformation (6), 2003.

[6] T. R. Gruber, “A Translation Approach to Portable Ontology Specifications”. Knowledge Acquisition, 5(2), 1993.

[7] Y. Bishr, “Overcoming the semantic and other barriers to GIS interoperability” Geographic Information Science, 12(4), 1998.

[8] F. Harvey, W. Kuhn, H. Pundt, Y. Bishr, “Semantic interoperability: A central issue for sharing geographic information” The Annals of Regional Science, 33(2), 1999.


[9] A. P. Sheth, “Changing focus on interoperability in information systems from system, syntax, structures to semantics”. Interoperating geographic information systems, Boston, Kluwer Academic Publishers, 1999.

[10] C. Batini, S. Ceri, B. Navathe, Conceptual Database Design, Redwood City, California, The Benjamin/Cummings publishing Company, 1992.

[11] Neches et al., “Enabling technology for knowledge sharing”. AI Magazine, 12(3), 1991.

[12] J. Vogt (ed.), “Guidance Document on Implementing the GIS Elements of the Water Framework Directive”, European Communities, 2002.

[13] M. A. Latre, F. J. Zarazaga-Soria, J. Nogueras-Iso, R. Béjar, P. R. Muro-Medrano. “SDIGER: A cross-border inter-administration SDI to support WFD information access for Adour-Garonne and Ebro River Basins”. Proceedings of the 11th EC GI & GIS Workshop, Alghero, Sardinia (Italia), julio 2005.

[14] O. Corcho, M. Fernández-López, A. Gómez-Pérez, A. López-Cima, “Building legal ontologies with METHONTOLOGY and WebODE”, Law and the Semantic Web, (ed.): Bran Selic, Springer-Verlag 2005.


IDEZar: procesos, herramientas y modelos ur-banos aplicados a la integración de datos muni-

cipales procedentes de fuentes heterogéneas

F. J. López Pellicer†, P. Álvarez†, P. R. Muro-Medrano†

† Departamento de Informática e Ingeniería de Sistemas Informáticos Universidad de Zaragoza

Calle María de Luna 1, 50018, Zaragoza e-mail: {fjlopez,alvaper,prmuro}@unizar.es

Resumen

Gran parte de los esfuerzos de la Infraestructura de Datos Espaciales de Zarago-za han sido aplicados al diseño e implementación de procesos de integración de datos de referencia de baja calidad. Tomando como base la propuesta de directiva INSPIRE, se ha desarrollado un conjunto de procesos, herramientas y modelos que ayudan a integrar de forma homogénea datos de referencia producidos en la admi-nistración local.

Palabras clave: datos de referencia, administración local, geodatabase, INSPIRE, integración.

1. Introducción La iniciativa IDEZar (Infraestructura de Datos Espaciales de Zaragoza) es el re-

sultado de la colaboración iniciada en el año 2004 entre el Ayuntamiento y la Uni-versidad de Zaragoza para la implantación de una Infraestructura de Datos Espacia-les (IDE) a escala local. Dos elementos relevantes en esta IDE son la política de in-tegración de datos y la arquitectura basada en servicios. Su importancia deriva de la existencia en el ámbito municipal de datos espaciales caracterizados por su gran volumen y heterogeneidad. Hay una amplia variedad de temáticas (identificadores de propiedad, figuras de protección medioambiental, restricciones urbanísticas, etc.) como plataformas (SIG, CAD, aplicaciones de oficina) amen de diferentes re-querimientos de calidad, disponibilidad, validez, extensión y formato. Además presentan problemas como lagunas de información, duplicidades e inconsistencias entre fuentes. La IDE, vista como herramienta que facilita el acceso y la explotación de información espacial clave [1], debe ser capaz de acceder a fuentes heterogéneas de datos y ofrecer una visión homogénea de la información como valor añadido.


Adelantándose a la futura directiva INSPIRE, la política de integración de datos ha establecido mecanismos para que se “reduzcan las duplicaciones en la recopilación de datos, y (se) promuevan y respalden la armonización, la difusión y la utilización de los datos de una forma lo más amplia posible” [2] dentro del Ayuntamiento. La arquitectura basada en servicios, que sigue los criterios de la Web Services Archi-tecture [3] impulsada por Open Geospatial Consortium (OGC), permite que los servicios municipales exploten el valor añadido al facilitar la construcción de apli-caciones y adaptadores sobre los servicios de la IDE.

Este capítulo presenta una solución para la implementación de la política de in-tegración de datos. Ésta pasa por establecer un modelo que describe los datos espa-ciales usados por la Administración local en la línea establecida por INSPIRE y que denominamos “modelo urbano” por la temática de la mayoría de sus datos. En este modelo los datos que INSPIRE denomina “datos de referencia”, datos que son utili-zados para caracterizar espacialmente a otros datos, tienen un papel diferenciado pues son los responsables de homogenizar la información. Este modelo se imple-menta en una geodatabase poblada a partir de la “integración de datos” proceden-tes de “fuentes heterogénea” mediante la aplicación de un conjunto de “procesos” y “herramientas”. Además, este modelo ha simplificado el diseño de nuevos servicios y aplicaciones.

Este capítulo se organiza como sigue, la sección 2 incide en la relación entre INSPIRE, los datos de referencia y la Administración local, la sección 3 caracteriza los problemas detectados desde 2004 hasta la fecha, la sección 4 muestra nuestra propuesta y la sección 5 su aplicación, para finalizar con unas conclusiones.

2. La directiva INSPIRE, los datos de referencia y la Adminis-tración local

La directiva INSPIRE señala qué temas considera como datos de referencia pero

no quién es responsable de su creación. Este punto analiza qué temas son idealmen-te del ámbito local y qué implicaciones tiene para su gestión.

Los Anexos I y II de la directiva INSPIRE concretan qué temas son considerados de referencia. En la tabla 1 se recogen aquellos temas y subtemas en los que la Administración local española es potencialmente responsable de su gestión y/o mantenimiento. Esta selección se basa en las competencias municipales y en el uso de dichos datos en la gestión municipal.

Salvo en el caso de las parcelas catastrales, el subtema local es tan amplio que la Administración local en su conjunto es responsable de la gestión de la mayoría de los datos. Cuando se aplique la directiva INSPIRE los sistemas de información loca-les deberán adaptarse para que estos temas soporten una identificación no ambigua de estos datos (sea o no con un sistema común de identificadores únicos [4]), ten-gan sus modelos establecidos y, por ende, existan mecanismos que eviten inconsis-tencias y errores.


Anexo I y II Definición INSPIRE Subtema local

Nombres geo-gráficos

Nombres de zonas, regiones, localidades, ciudades, periferias, poblaciones o asenta-mientos, o cualquier rasgo geográfico o topo-gráfico de interés público o histórico.

Nombres geográfi-cos locales.

Unidades administrativas

División del territorio nacional en unidades de administración a nivel local, regional y nacio-nal. Las unidades administrativas estarán separadas por límites administrativos. Tam-bién se incluirán las fronteras del territorio nacional y las costas.

Unidades adminis-trativas locales descentralizadas.

Redes de transporte

Redes de carreteras, ferrocarril, transporte aéreo y por vía navegable e infraestructuras correspondientes. Se incluirán las conexiones entre redes diferentes.

Red local de vías urbanas, caminos y vía rurales.

Identificadores de propiedad

Localización geográfica de las propiedades, efectuada sobre la base de la denominación de las direcciones, por ejemplo el nombre de la vía pública, el número de la finca, el código postal.

Tipo y nombre de vía pública y nú-mero de la finca.

Parcelas catas-trales

Áreas determinadas por límites catastrales y caracterizados por una situación jurídica espe-cífica de propiedad.

Propuestas de alteraciones catas-trales.

Tabla 1. Temas de referencia local. Ley 7/1985 reguladora de Bases de Régimen Local, formatos de intercambio del Instituto Nacional de Estadística (INE), formatos de inter-

cambio Dirección General del Catastro (DGC), elaboración propia

3. Problemas en la manipulación de datos de referencia Hay una serie de problemas en los datos de referencia que tienen que ser resuel-

tos con respecto a los datos para llegar a la situación señalada en el apartado ante-rior. Estos problemas se han detectado según se iban cumpliendo las metas marca-das a lo largo de estos dos años para IDEZar [5] con vistas al desarrollo de un geo-portal orientado a los ciudadanos (http://www.zaragoza.es/idezar). Los problemas detectados son:

• Baja calidad espacial. Es frecuente que no se disponga de información es-

pacial adecuada o falten relaciones con otros datos espaciales importantes para su explotación.


• Duplicidad de fuentes. Algunos de los temas tienen más de una lista de re-

ferencia que se solapan. • Un uso no sistemático. No todos los elementos de un tema están espacial-

mente caracterizados de la misma manera. Por ejemplo, al usar las direc-ciones en zonas rurales para identificar centros municipales discrecional-mente se indica o no la junta vecinal en la que se encuentra.

• Identificadores alternativos ad-hoc. En ausencia de reglas o acceso a listas controladas se identifican los datos temáticos mediante identificadores al-ternativos ad-hoc. Por ejemplo se pueden encontrar varias formas de escri-bir el nombre de la calle.

• Sesgo estadístico. El diseño de los nombres geográficos, las unidades ad-ministrativas y los identificadores de propiedad están orientados a identifi-car población. Gran parte de esta información se intercambia con el Institu-to Nacional de Estadística (INE) y son sus requisitos los que guían cómo deben ser los datos [6].

• Describen mal zonas despobladas. No son relevantes los nombres geográ-ficos que describen el territorio pero que no tienen población o cuya pobla-ción es diseminada en sentido estadístico.

• Falta de representación espacial adecuada. Excepción a este hecho son los temas relacionados con el urbanismo.

• Direcciones como texto libre. Consecuencia indirecta de los problemas an-teriores.

4. Propuesta de solución Para afrontar los problemas indicados en el punto anterior y encaminar la IDE en

la línea de la sección 2 nuestra propuesta plantea establecer como elemento central un modelo de datos de referencia urbanos acompañado de procesos y herramientas de integración de información y de servicios de red para su explotación.

4.1. Modelo urbano

El elemento central es un modelo de datos de referencia urbana. Alrededor de él

se establece una serie de modelos de datos temáticos que utilizan el modelo de datos de referencia para caracterizarse espacialmente. Forman parte las “unidades administrativas” (juntas municipales y vecinales), los “códigos postales”, las “vías urbanas” y los “números de finca o de policía”. Ejemplos de modelos temáticos son el “transporte público urbano”, las diferentes “regulaciones fiscales”, las “zonas saturadas”, las “divisiones censales” y los “centros municipales”. Este modelo se implementa en una geodatabase. El único requisito que se exige es la compatibili-dad de los almacenes de los datos de referencia y temáticos con la especificación SFS [7] de OGC.


Figura 1. Propuesta de solución

4.2. Procesos y herramientas Los procesos de incorporación y homogenización de información transforman

los datos en formato propietario o legado obtenidos de las diversas fuentes en datos correctamente referenciados. Estos procesos se implementan mediante scripts que encadenan aplicaciones Java y aplicaciones ETL-GIS. El primer paso del proceso de integración es la puesta bajo control tanto de las fuentes de datos como de los datos que éstas produce, su especificación (si existe) e información de proceso: cuándo se producen, se producen en sistemas legados, son relevantes para el proceso adminis-trativo, cómo se intercambian y en qué formatos. Tras analizar los datos bajo con-trol se diseñan los “procesos de extracción, transformación y carga” de la informa-ción en la geodatabase. Los procesos de transformación pueden clasificarse en:

• Procesos de limpieza. Aplican heurísticas de limpieza de datos. Comprue-

ban los dominios de los campos y su contenido. • Procesos de alineamiento. Relacionan dos o más datos entre sí. Depen-

diendo de la fuente, además de detectar duplicados, se detectan inserciones, modificaciones y borrados.

• Procesos de aumentación. Aplican heurísticas, procesos y herramientas pa-ra aumentar la información espacial asociada a los datos.


• Procesos de referenciación. Herramientas y procesos que permiten asociar

datos temáticos de forma sistemática con datos de referencia almacenados en la geodatabase.

Tras la transformación disponemos de datos normalizados y enriquecidos que

actualizaran mediante procesos de carga la geodatabase. Adicionalmente estos datos pueden ser devueltos a la fuente como datos normalizados.

4.3. Servicios de red

En nuestra propuesta las aplicaciones web acceden a la información mediante

servicios web de búsqueda y visualización. Estos servicios se caracterizan por no acceder directamente a los almacenes de datos temáticos y de referencia. Existen almacenes con datos con valor añadido adaptados a los requerimientos de las apli-caciones. Estos almacenes se han construido utilizando servicios web de transfor-mación que acceden directamente a los almacenes datos temáticos y de referencia.

5. Caso de aplicación Esta propuesta se ha aplicado en la construcción de las aplicaciones callejero y

nomenclátor de IDEZar (véase figura 2). El callejero es una de las aplicaciones más empleadas en la IDE local. El nomenclátor de calles es una aplicación diseñada para presentar toda la información textual asociada a las calles y que inicialmente estaba desperdigada en diferentes bases de datos. Los datos de referencia relevantes para la elaboración de un callejero son la vía, los números de finca a ella asociados así como la unidad administrativa (junta municipal, junta vecinal) y el código postal. Para la elaboración del nomenclátor se requiere además de información temática sobre fiscalidad, sobre restricciones zonales y sobre transporte público referenciada a rangos de portales o tramos de vías. En ambas aplicaciones casos el elemento clave es la vía.

Para cada tema los datos servidos proceden de más de una fuente como la Di-rección General de Catastro, el servicio de Información Geográfica y el servicio web del Ayuntamiento.

Por ejemplo, para obtener los números de finca (véase figura 3) que se encon-traban en la base cartográfica municipal en formato Microstation Design se utilizó una herramienta ETL-GIS. Se aplicaron diversas heurísticas de filtro y limpieza ade-cuadas a los usos del Ayuntamiento para extraer las etiquetas que representaban números de finca. Al faltar un atributo que informara de la calle a la que el número de finca se refiere, se combinó aplicando una serie de heurísticas con la informa-ción ya almacenada de vías, las cuales procedían de una fuente distinta. Los núme-ros de finca, ya correctamente referenciados a vías, fueron entonces almacenados.


Figura 2. Caso de aplicación del callejero y nomenclátor

Figura 3. Procesado de números de finca


Las dos aplicaciones, callejero y nomenclátor, comparten el mismo servicio de

búsqueda, basado en tecnología de catálogo. Solo el callejero utiliza un WMS para situar visualmente la calle o la dirección buscada. Aprovechando tecnologías que transforman consultas SQL en XML se han desarrollado herramientas de extracción, transformación y carga que producen un almacén de información optimizado para responder a consultas sobre direcciones. La compatibilidad de la geodatabase con SFS hace trivial la conversión de los datos de direcciones en una capa servida por el WMS.

6. Conclusiones Es evidente que la Administración local es la autoridad que mejor conoce las

parcelas donde residimos y trabajamos, cómo las identificamos, cuáles son las rutas en el primer y último kilómetro de cualquier viaje y con qué nombres identificamos las comunidades donde residimos. Es por tanto un actor básico en cualquier in-fraestructura espacial y se verá obligado, tanto por necesidades de modernización de la administración como por los requerimientos de directivas europeas, a dar los pasos necesarios para el uso de procesos, herramientas y modelos adecuados con el fin de mantener adecuadamente los datos de referencia. IDEZar es un ejemplo de cómo se está realizando este cambio.


C02-01 del Plan Nacional de Investigación Científica y Desarrollo Tecnológico del Ministerio de Educación y Ciencia de España. El trabajo de J. López (ref. B136/2006) ha sido parcialmente financiado por una beca del Gobierno de Aragón.

Referencias

[1] P. R. Muro-Medrano, M. Gould, M. A. Bernabé, “IDE-E: Technological ad-vances for a Web-based National Spatial Data Infrastructure, convergence with the European initiative INSPIRE TIC2003-09365-C02”, Jornada de Se-guimiento de Proyectos, Programa Nacional de Tecnologías Informáticas, 2005

[2] Comisión de las Comunidades Europeas, “Propuesta de Directiva del Parlamento Europeo y del Consejo por la que se establece una infraestructura de información espacial en la Comunidad (INSPIRE)”, Julio 2004 , COM(2004) 516 final.2004/0175 (COD)


[3] Open Geospatial Consortium, Inc., “OpenGIS Web Services Architecture”, Reference number OGC 03-025, 2003.

[4] Recomendation for Second Reading on the Council common position for adopting a directive of the European Parliament and of the Council establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) (12064/2/2005 – C6-0054/2006 – 2004/0175(COD)), 13 de junio de 2006

[5] F. J. López Pellicer, P. Álvarez, P. R. Muro-Medrano, “IDEZar: un ejemplo de implantación de una IDE local”, Jornadas Técnicas de las Infraestructuras de Datos Espaciales de España – JIDEE 05, Madrid, 2005

[6] Ministerio de la Presidencia. “Orden de 11 de Julio de 1997 sobre Comunicaciones electronicas entre las Administraciones publicas referentes a la Informacion de los Padrones municipales”, BOE de 16 de Julio de 1997, nº 0169

[7] Open Geospatial Consortium, Inc., ”Simple Features Implementation Specifi- cation for SQL (SFS)”, Document 99-049, 1999


IDENA: novedades y líneas de futuro

P. Echamendi†, S. Fontano†, M. Cabello†, M. A. Jiménez de Cisneros‡

† Trabajos Catastrales, S.A. Ctra. El Sadar s/n, 31006, Pamplona


‡ Dpto. de Obras Públicas, Transportes y Comunicaciones Avda. S. Ignacio 3, 31002, Pamplona


Resumen

El proyecto IDENA [1] se enmarca entre las distintas iniciativas que en los últi-mos años se han producido en Navarra y que se integran en la red de recursos de información que constituye SITNA (Sistema de Información Territorial de Navarra). Este sistema permite el acceso a información georreferenciada de todo tipo a una gama muy amplia de usuarios. En los dos últimos años, el desarrollo de IDENA (Infraestructura de Datos Espaciales de Navarra) ha supuesto la apertura de todo esto, gracias a la interoperabilidad entre informaciones y sistemas mediante la utili-zación de normas y especificaciones comunes [2].

Este capítulo presenta las últimas novedades que se están desarrollando en rela-ción con la Infraestructura de Datos Espaciales de Navarra. La reciente publicación de la IDE de Pamplona (http://ide.pamplona.es), por ejemplo, ha permitido la incor-poración de la perspectiva local al proyecto IDENA y, al mismo tiempo, un avance significativo en el desarrollo del portal. Al mismo tiempo, Navarra participa en un ambicioso proyecto europeo, CROSS SIS, junto con otras cuatro regiones europeas, Overijssel y Gelderland (Holanda), North-Rhine Westphalia (Alemania), Lower Austria (Austria).

Es objeto de este capítulo, además, difundir una iniciativa impulsada desde la Administración Foral que persigue la publicación en una web propia de un Inventa-rio de Planeamiento Urbanístico. La información que se considere más relevante podrá ser consultable a través de un servicio WMS. Palabras clave: Navarra, infraestructuras de datos espaciales, IDENA, IDEPamplo-na, CROSS SIS, GRISI, planeamiento.


1. IDEPamplona En el mes de marzo de 2006, y coincidiendo con la reunión del Grupo de Traba-

jo de la IDEE que tuvo lugar en Pamplona, se produjo la presentación de IDEPam-plona [3]. Este portal ofrece información territorial del término municipal de Pam-plona y herramientas para poder navegar sobre la misma. Nace, por otra parte, co-mo es lógico, con la idea de atender a los requerimientos de INSPIRE y de contribuir al desarrollo de las IDE en España. En ese sentido, representa un paso importante tanto en el desarrollo de las IDE locales como en el desarrollo de la IDE en la Co-munidad Foral de Navarra. Todos los desarrollos tecnológicos son propios de Tra-bajos Catastrales, S.A.

A semejanza de IDENA, el portal de IDEPamplona está constituido por dos ele-mentos principales: un cliente Map Viewer o visualizador de mapas y un buscador de metadatos. Sin embargo, aún no dispone de un apartado dedicado a descargas de información tal y como ofrece IDENA.

El Map Viewer (véase figura 1) permite acceder a la visualización de los mapas que muestran la información espacial de Pamplona. A su vez, permite también la conexión con otros servidores de información que sigan los mismos estándares y protocolos. Por defecto, se pueden activar los datos espaciales de IDENA de mayor interés para el ámbito de la ciudad. Además de disponer de las herramientas habi-tuales de navegación, ofrece también la posibilidad de visualizar la leyenda, activar o desactivar capas, acceder como ya se ha mencionado a otros servicios de mapas, realizar mediciones, trazar y descargar rutas GPS, imprimir mapas, etc.

Figura 1. Aspecto del visualizador de mapas de IDE Pamplona

El buscador de metadatos (véase figura 2) permite realizar búsquedas sobre los

metadatos de la información que contiene la IDE basándose en diferentes criterios establecidos por INSPIRE. El resultado de esta búsqueda ofrece un listado de todos los datos que reúnan esas características. De cada resultado se mencionan 5 carac-


terísticas principales (título, resumen, editor, formato y agregados, cuando sea apli-cable). Una vez encontrado y seleccionado el dato de interés para el usuario, se presentarán las opciones de: ver los datos en el mapa “Ver mapa”, Consultar los metadatos básicos o completos de ese dato “Ver detalles” o enlazar con una direc-ción web propuesta por el titular de la capa de información “Ir a sitio web””.

Figura 2. Aspecto del buscador de metadatos

La figura 3 muestra la ventana de resultados que devuelve las entradas que co-inciden con los criterios de búsqueda introducidos. Un aspecto interesante es que la búsqueda se realiza tanto en el catálogo de IDEPamplona como en el de IDENA. La procedencia de los resultados devueltos por uno y otro catálogo se identifican cla-ramente por medio de colores distintos. Este ejemplo muestra la total interoperabi-lidad entre ambos portales.

Las capas actualmente cargadas en IDEPamplona son: • Edificios del ayuntamiento, mercados municipales y oficinas de correo. • Equipamientos socioculturales, de ocio y centros educativos. • Cementerio y tanatorios. • Tráfico y transporte. • Edificios sanitarios y residencias de la tercera edad. • Recorrido del encierro. • Cárcel y juzgados. • Aseos municipales. • Colección de ortofotos históricas que muestran la evolución de la ciudad a

lo largo de los últimos 75 años. • Otros servicios de interés.


Figura 3. Ventana de resultados de una búsqueda

En cuanto al planteamiento de la arquitectura, la figura 4 muestra la solución ac-

tualmente en funcionamiento con la existencia de dos nodos IDE en Navarra en funcionamiento.

Figura 4. Esquema de servicios IDE en Navarra


2. CROSS SIS El Gobierno de Navarra y Trabajos Catastrales S.A. como socio tecnológico

participan en el proyecto europeo CROSS SIS [4]. El objetivo principal de este pro-yecto es fomentar el uso de información espacial para la toma de decisiones en territorios de la Unión Europea, la modernización de las administraciones regiona-les, promover el uso de INSPIRE y el desarrollo de la sociedad de la información.

Este proyecto persigue que cada socio ponga en marcha dos servicios de mapas mostrando información sobre los dos temas que se han elegido como experiencia piloto: el planeamiento y la estadística. Esto implica un esfuerzo de definición de los temas y variables a tratar y de homogeneización de la información, pero ade-más, se han determinado cuáles son los requisitos mínimos que cada servicio debe presentar y esto está suponiendo una transferencia de experiencias y conocimientos entre todos los socios para llegar a unos resultados homogéneos. En este caso con-creto, y dado el escaso tiempo disponible para la publicación de los servicios, se ha elegido utilizar un software open source, Map Server.

En la figura 5 se aprecian algunos de los mapas preparados para el piloto de planeamiento (en este caso sobre la ortofoto que suministra IDENA). Para este piloto se ha desarrollado el interfaz GetFeatureInfo para obtener información de los obje-tos del mapa. El resultado de la identificación de un objeto devuelve la información precisa así como enlaces a los planes de ordenación correspondientes en formato pdf.

Figura 5. Integración de información CROSS SIS en la IDEE


En el caso del piloto de estadística, el principal requerimiento técnico ha sido la

necesidad de implementar un servicio WMS-SLD (Styled Layer Descriptor). Esta especificación OGC, que permite al usuario elegir la simbología a aplicar al mapa, se ha estimado de gran interés para representar los datos estadísticos elegidos: po-blación, densidad, número de hogares, población ocupada y parada.

Figura 6. Pruebas realizadas utilizando un servicio WMS-SLD

En definitiva, este proyecto, que se terminará a lo largo de este año, pretende

realizar dos ejercicios prácticos que demuestren la validez de las IDEs como in-fraestructuras que soporten un buen desarrollo de políticas adecuadas en ámbitos transfronterizos. Es prioritario a la vez el traspaso de conocimientos entre los dis-tintos organismos que colaboran.

3. Inventario de planeamiento urbanístico El Gobierno de Navarra y Trabajos Catastrales S.A. vienen desarrollando desde

el año 1999 el Sistema de Información Urbanística de la Comunidad Foral, proyec-to destinado a generar una capa de información homogénea, continua y cierta, del planeamiento urbanístico y la ordenación territorial.

Los objetivos generales de este proyecto son: • Coherencia conceptual, con los términos y las definiciones de las determi-

naciones propias del planeamiento. • Coherencia gráfica, que evite inconsistencias en la cartografía urbanística,

y posibilite su implementación en sistemas de Información geográfica, siempre en el marco del DUT.


• Apropiable, que cumpliendo lo anterior sea accesible desde plataformas tecnológicas existentes sin grandes costes (comprensible y asequible).

Este sistema de información abarca, entre otras cosas, el inventario y e-registro

de la información pública relativa a los instrumentos de ordenación territorial y planeamiento, que se ha escaneado a este propósito. El inventario por sí mismo permitirá que la información sea accesible por todos los agentes sociales, públicos y privados, relacionados con el suelo. Desde el punto de vista técnico, la naturaleza de la información tratada aconsejó el desarrollo de un nuevo servidor de imágenes ráster, que ampliara las capacidades del que ya estaba funcionando, que fuera capaz de mostrar todos los planos urbanísticos existentes, generando bajo petición mosai-cos de varios planos distintos en tiempo real prescindiendo de sus respectivas cará-tulas para ofrecer una imagen continua al usuario.

Como idea general, se ha diseñado que el inventario sea la herramienta de con-sulta del planeamiento urbano en Navarra tanto por parte de los técnicos como del público en general. Los trabajos realizados para su creación han sido:

• Diseño y creación de una base de datos de planeamiento. • Escaneado de la documentación existente. • Digitalización, montaje y georreferenciación de las imágenes para que

pueden ser incluidas en cualquier servicio de mapas. Se ha realizado la georreferenciación tanto del plano completo como del marco que delimita el mapa.

• Publicación en Internet (de momento de acceso restringido). En las ilustraciones siguientes (véase figuras 7 y 8) podemos contemplar la con-

sulta de un plano utilizando el inventario de planeamiento y seguidamente la inte-gración de ese mismo plano en un cliente de pruebas junto con otras capas de in-formación ofrecidas por el WMS de IDENA.

Entre los retos que todavía quedan por delante antes de culminar este proyecto, se encuentra finalizar la creación de los metadatos correspondientes y, sobre todo, conseguir una integración ágil de tantas capas de información en un servicio WMS y que el usuario pueda encontrar fácilmente lo que realmente está buscando.


Figura 7. Consulta al inventario de planeamiento

Figura 8. Integración capas del inventario y de IDENA en un test

4. Conclusiones y líneas de futuro Entre las líneas de futuro que están abiertas en este campo está el de consolidar

la IDE de Pamplona y dotarla de más y mejores datos así como geo-servicios de utilidad para el ciudadano. En la misma situación se encuentra el portal del Gobier-no de Navarra, IDENA, aunque el volumen de peticiones que recibe así como la cantidad de información que presenta la colocan en buena posición para el futuro.

Actualmente se trabaja en la publicación de una serie de mejoras en el visuali-zador de mapas que permitan la aplicación de transparencias a las distintas capas


así como cambiar el orden de las mismas dentro del mismo servicio (por el momen-to sólo es posible cambiar el orden de los servicios de mapas). Al mismo tiempo se pretende incorporar en breve el enlace desde el Map Viewer a la ficha de metadatos correspondiente. También se están realizando la tarea de adaptar el catálogo de metadatos al estándar OGC con el objeto de abrir la puerta a posibles búsquedas encadenadas entre diferentes servicios de catálogo a través de la red. Conforme se vaya progresando en esta tarea, se irán realizando pruebas con otros organismos que dispongan de servicios de catálogos conformes a las especificaciones OGC para probar su validez y su rendimiento.

Como conclusión, podemos decir que los casos descritos en este capítulo ponen de relieve el interés suscitado en Navarra por las Infraestructuras de Datos Espacia-les. Los desarrollos completados o en marcha hacen concebir grandes esperanzas para los próximos años. IDENA, IDEPamplona o CROSS SIS son escaparates que per-miten la difusión libre y gratuita de información referida al territorio de Navarra con el objetivo de cumplir con los principios de INSPIRE. Sin embargo, todavía no se ha dado el gran salto que puede hacer que estas Infraestructuras se conviertan plenamente en soporte de desarrollo, en plataformas abiertas sobre las que se pue-dan implantar servicios geográficos que permitan crear valores añadidos sobre la información.

Referencias

[1] Web del proyecto IDENA: http://idena.navarra.es/. [2] R. Clerigué Arrieta, P. Echamendi Lorente, S. Fontano Ruiz, C. Sabando

Grasa, “IDENA, Infraestructura de Datos Espaciales de Navarra”, Jornadas Técnicas de la IDEE, Zaragoza, 2004, http://idee.unizar.es/jidee/documentos _en_linea/papers/JIDEE_idena.pdf.

[3] Web del proyecto IDEPamplona: http://ide.pamplona.es/. [4] Web del proyecto CROSS SIS: http://www.cross-sis.com/.


Integración de los municipios en la IDE regional. Primeros resultados y conclusiones

J. Guimet†

† Centro de Soporte IDEC Institut Cartogràfic de Catalunya

Parc de Montjuic s/n, 08038, Barcelona e-mail: [email protected]

Resumen La evolución del proyecto IDEC, desde sus inicios a mediados del 2002 [1], ha

conducido hacia la aplicación de los recursos tecnológicos disponibles y de los conocimientos adquiridos en ámbitos concretos. Las primeras formulaciones de IDEs sectoriales resultaron ser de gran interés, lo cual llevó a plantear a finales del 2004 una propuesta para integrar los entes locales en la IDE regional mediante la construcción de una IDE sectorial específica que tuviera en cuenta el ámbito de los entes locales y sus particularidades.

La participación de los entes locales es básica para garantizar la efectividad y la sostenibilidad de la IDEC, al integrar un gran número de proveedores nuevos en el sistema, que son al mismo tiempo usuarios, y que abrirán una buena parte de sus datos a los usuarios, ciudadanos, empresas y, también, a otras administraciones. Conseguir que los entes locales hagan inventario de sus geodatos, los describan en metadatos publicados en el servidor de catálogo IDEC, y publicar esta información mediante la conexión estándar de WMS en Internet, son los objetivos primarios del proyecto.

El documento presenta los primeros resultados de la iniciativa, el tipo de infor-mación disponible, los nuevos proyectos que pueden ser asumidos, las soluciones tecnológicas en desarrollo para dar soporte al proyecto y otros aspectos claves de su implementación.

Palabras clave: IDE, Administración local, IDE temática, proyecto IDEC LOCAL.


1. Escenario

1.1. El marco catalán IDE La IDE de Cataluña fue creada en 2002 [2]. Actualmente dispone de varios ser-

vicios en su geoportal (http://www.geoportal-idec.net), sobre todo en sus servicios de catálogo, donde se pueden encontrar más de 20.000 registros de metadatos pro-porcionados por 67 organizaciones y aproximadamente 30 servicios de metadatos que describen diferentes geoservicios proporcionados por una docena de Web Map Services (WMS), que hacen accesibles alrededor de 150 capas de referencia y geo-datos temáticos [3]. En estos momentos, una ley del Parlamento autonómico reco-noce la infraestructura IDEC y designa al Instituto Cartográfico de Cataluña (ICC) para realizar el desarrollo y mantenimiento de la IDEC mediante un Centro de So-porte específico.

Desde el principio, se ha adoptado la iniciativa de formar IDEs temáticas [4], en la medida de lo posible, más adaptadas a las necesidades específicas de dominios concretos. Una de estas IDE temáticas es el proyecto de IDEC LOCAL, el cual supone la integración de las administraciones locales en la IDE regional. Como IDE temáti-ca tiene su propio geoportal y servicios, siendo parte de los recursos catalanes de IDE.

En septiembre de 2005 se firmó un acuerdo entre la organización responsable del e-gobierno (CAOC) y el Instituto Cartográfico de Cataluña para promover y crear la IDEC LOCAL. Una primera convocatoria a la participación tuvo lugar a fina-les de 2005, con un resultado de 60 municipios comprometidos directamente con la iniciativa y otros 165 mostraron su interés para formar parte del proyecto en un próximo futuro. Una segunda convocatoria ha sido publicada recientemente, en julio de 2006, y se espera aumentar considerablemente la participación local [5].

1.2. Objetivos El objetivo general del proyecto IDEC LOCAL persigue conseguir la plena parti-

cipación de las administraciones locales (diputaciones, consejos comarcales, muni-cipios, organismos locales) en el desarrollo de la Infraestructura de Datos Espacia-les de Catalunya, en el ámbito de la generación de metadatos, catálogos, difusión y acceso a dichos datos mediante servidores de mapas OGC y aplicación a diversos proyectos.

Concretamente, los objetivos específicos que se persiguen son los siguientes: • Elaborar inventarios, formalizados en metadatos sobre los datos disponi-

bles y publicarlos en el servidor de catálogo IDEC o en otros catálogos co-nectados al mismo.


• Ubicar en servidores de mapas, ya existentes o bien de nueva implantación, la información territorial digital de que dispongan y descrita en los metada-tos.

• Definir la accesibilidad a las diferentes capas que componen dicha infor-mación, clasificándolas como:

o De libre acceso. o De libre acceso con pago por utilización. o De acceso restringido. o De acceso restringido con pago por utilización

• Promover la utilización de las tecnologías que hacen posible la interopera-bilidad, aplicándolas a una mejor gestión y conocimiento del propio territo-rio, compartiendo datos con otras administraciones e instituciones.

• Participar en proyectos de aplicación y, en los casos en que sea posible, rentabilizar los activos de información disponibles.

• Armonizar datos territoriales entre administraciones públicas [6].

1.3. Información disponible en activos y recursos

1.3.1. Situación actual de los entes locales La situación y los recursos utilizados en la gestión (captura, mantenimiento, ex-

plotación y difusión) de la información geoespacial no dependen del tamaño del municipio, sino más bien es producto de circunstancias históricas, en las que han influenciado tanto aspectos personales como de prioridades políticas. Se constata en general un nivel importante de desaprovechamiento de las opciones que las TIC aplicadas al componente espacial de la información que captura y explota el muni-cipio podrían permitir.

Puede apreciarse en el tabla 1 que aunque el tamaño del municipio tiene in-fluencia en el nivel de recursos disponibles, dichas diferencias no son proporciona-les al tamaño, como podría esperarse. Así, los municipios de más de 2000 habitan-tes tienen en un 50% los mismos recursos (información, personal, tecnología) que los de mayor tamaño, mientras que los de más de 10.000 habitantes presentan un porcentaje del 85%. Aun sin disponer de datos concretos respecto a los pequeños municipios, cabe esperar que las entidades supramunicipales suplirán sus carencias y por tanto podrán ser integrados en el proyecto.


< 2.001 hab > 2.001 hab > 10.001 hab > 50.001 hab

Aplicaciones

Catastro 0 15% 80% 100%Urbanismo 0 70% 90% 100%

Medio Ambiente 0 0 60% 75%Via pública 0 0 70% 85%

Servidor de mapas 0 15% 60% 85%

Información web

Callejero 0 0 10% 40%Catastro/Urb 0 0 0 25%

Tècnico SIG 0 30% 60% 100%

Tabla 1. Situación actual del nivel de recursos disponibles. (Nota: Aunque los datos están obtenidos de una muestra reducida se estima tienen un correcto nivel de fiabilidad. No se

incluyen diputaciones ni consejos comarcales)

1.3.2. Información disponible

La Administración local controla y gestiona principalmente territorio y produce

gran cantidad de datos georeferenciados interesantes, a nivel económico, con datos básicos y temáticos:

• Mapas topográficos. • Urbanismo. • Medioambiente. • Turismo. • Distribución de servicios públicos. • Catastro, callejero, etc.

Los municipios más grandes disponen de todos sus datos digitalizados, nor-

malmente ya publicados en WMS (en Intranet o Internet), y con frecuencia tienen un responsable de SIG. Muchos otros municipios más pequeños también tienen recur-sos adecuados (datos, recursos humanos y físicos) para formar parte de una geoin-fraestructura, y tener un impacto importante en ella. En el caso de los municipios más pequeños, varias organizaciones supramunicipales se ocupan de facilitarles los servicios que precisan, son estos últimos los agentes participantes, coordinando los esfuerzos, etc.


2. Enfoque y desarrollo Con la finalidad de conseguir la más amplia participación en el proyecto, dos lí-

neas de actuación han sido puestas en juego. Una primera, y elemental, consiste en subvencionar los costes que puedan con-

llevar para los entes locales la generación de los metadatos y la posterior publica-ción de la información en WMS (y activación de los conectores OGC), incluyendo, si fuere el caso por no disponer de dicho recurso, la instalación del software WMS-OGC, (se implementa software open source WMS de libre utilización). Asimismo se facilita el soporte técnico necesario para la ejecución de dichos objetivos. Final-mente en la línea de promoción de la integración de TIC en los entornos locales, y específicamente proyectos SIG, se priorizan aquellos proyectos cuyo desarrollo contribuya a una más rápida y fácil integración en el proyecto IDEC LOCAL.

La financiación de dichos trabajos corre a cargo del Consorcio Administración Abierta de Catalunya (CAOC), ente gestor de los programas de e-Administración. De esta forma, el Consorcio CAOC subvenciona las siguientes tareas:

• Creación de metadatos. • Publicación de datos en WMS/OGC (2.000 €). • Proyectos SIG relacionadas con el proyecto IDE.

Una segunda línea de actuación, probablemente más interesante y en línea con

los planteamientos del CAOC y, en general, con los objetivos que se persiguen en los programas del Gobierno electrónico, consiste en facilitar determinados módulos reutilizables y personalizables a partir de los recursos disponibles en la plataforma IDEC.

Ello representa una magnífica vía para la comprensión de los beneficios que comporta participar en una red colaborativa, en la que diversos proveedores com-parten sus respectivas informaciones, enriqueciendo al conjunto y facilitando me-dios de conocimiento territorial tanto al conjunto de las administraciones públicas como a los ciudadanos. En un principio dichas aplicaciones utilizan los servicios de acceso a recursos información de diversos departamentos del Gobierno y otras instituciones, así como geoservicios IDEC. El progreso del proyecto habrá de com-portar la ampliación de las bases de información disponibles con la integración de aquellas correspondientes a los propios entes locales.

Hasta el momento han sido desarrolladas las siguientes aplicaciones: • Visualizador de cartografía:

o Módulo totalmente personalizable mediante un simple formulario,

en el que el administrador selecciona los WMS a los que quiere ac-ceder o presentar mediante el mismo, decide si desea alguna fun-ción de interacción con el usuario, incorpora información propia del ente local ubicada en su propio servidor, etc. Desde la página


web municipal se conecta (link) con dicho cliente visualizador, que respeta el diseño de la página original (mashup).

o Como complemento, existe la posibilidad de crear otro visor para uso exclusivo interno del ente local, con información diferenciada.

• Catálogo de metadatos personalizado:

o Con ayuda de un formulario similar al de la aplicación anterior, el

ente local puede configurar una interfaz para acceso al catálogo IDEC, bajo una visión personalizada al mismo, que facilita acceso exclusivamente a los metadatos municipales.

o Alternativamente a la opción anterior, y para aquellos municipios que dispongan de pocos registros de metadatos, se facilitan ins-trucciones para realizar desde la página web municipal una llama-da única (sin filtros ni condiciones) a la lista de metadatos genera-dos.

• Creador de objetos geográficos:

o Permite, con la mera utilización del navegador, accediendo a un

cliente IDEC, y utilizando como fondo cualquier capa de informa-ción disponible (ortofoto, topográfico, callejero, etc.), editar obje-tos puntuales, lineales o superficiales, introduciendo atributos, links, imágenes u otras opciones, y almacenar los mismos en el servidor IDEC y/o generar ficheros que pueden ser publicados en el propio servidor municipal o ser usados en un SIG de escritorio.

El centro de soporte ofrece aplicaciones basadas en la plataforma de recursos

IDE como visualizadores personalizados (mapas y callejeros); ofrece la opción de personalizar servicios diversos como el de catálogo; y también ofrece la herramien-ta de edición para la creación de objetos geográficos o geoobjetos.

La figura 1 ilustra los interfaces de los formularios para la creación del visuali-zador personalizado mientras que la figura 2 presenta la interfaz de la aplicación para la generación de objetos geoespaciales. Algunas de las páginas web municipa-les que incorporan dichos visualizadores pueden encontrarse en http://www. ccsel-va.org/, http://www.cerverapaeria.com/, http://www.ajalella.org/, http://www.info garrotxa.com/, http://www.laroca.org/ y http://www.ajmalgrat.es/. La figura 3 des-taca las tecnologías aplicadas en la realización de los recursos antes descritos de las dos primeras figuras. En cualquier caso, la dirección web del geoportal IDEC (http://www.geoportal-idec.net/idelocal/) proporciona información adicional.


Figura 1. Formulario para la generación de visualizadores y personalización del catálogo.

Arquitectura

Figura 2. Generador de objetos geoespaciales

User’s control User’s control ViewerViewer

Street MapStreet Map

Intranet ViewerIntranet Viewer

Objects edition toolObjects edition tool

PublishPublish

Metadata CatalogMetadata CatalogGenerated applicationsGenerated applications

Web services W3c HTTP/POST

IDEC suite WS

- XY pixels Conversion to xy coordinates- Layers creation in the WMS- Files (shape) download

WebWeb servicesservices W3c W3c HTTP/POSTHTTP/POST

IDEC IDEC suitesuite WSWS

-- XY XY pixelspixels ConversionConversion to to xyxy coordinatescoordinates-- LayersLayers creationcreation in in the the WMSWMS-- Files (Files (shapeshape) ) downloaddownload

Web services W3c HTTP/POST

IDEC suite WS

- XY pixels Conversion to xy coordinates- Layers creation in the WMS- Files (shape) download

WebWeb servicesservices W3c W3c HTTP/POSTHTTP/POST

IDEC IDEC suitesuite WSWS

-- XY XY pixelspixels ConversionConversion to to xyxy coordinatescoordinates-- LayersLayers creationcreation in in the the WMSWMS-- Files (Files (shapeshape) ) downloaddownload


Figura 3. Tecnologías utilizadas 3. Resultados y conclusiones

El proyecto IDEC LOCAL es visto como un instrumento para emprender proyec-

tos nuevos, basado en su información conectada en red. Esto aumenta el interés de los participantes por las supuestas ventajas que se derivan de su participación.

También es importante la participación de las empresas privadas de servicios de valor añadido, no sólo en la etapa actual (proyectos SIG, metadatos, WMS, etc.), sino también para proyectos futuros.

A finales de 2006 se esperan conseguir los siguientes resultados: • 100 entidades usarán los visualizadores integrados en sus páginas web. • 100.000 accesos mensuales a callejeros de diferentes municipios. • 30 + usarán instrumentos de edición y publicarán capas nuevas. • 30 municipios tendrán su WMS (4/6 capas) conectados a la red IDEC LOCAL. • 60 municipios habrán publicado sus metadatos en el servicio de catálogo

(3000 registros nuevos), y otros 30 habrán publicado sus servicios de me-tadatos.

• Las primeras pruebas referentes a geoDRM y los primeros resultados de impacto estarán disponibles.

• Debería haberse obtenido un acuerdo inicial sobre la política de datos. • Se han planeado algunos proyectos nuevos que usarán WFS y tecnologías

de transacción. Las primeras conclusiones que se pueden extraer al poner en marcha el mencio-

nado proyecto se pueden resumir en los siguientes puntos: no es un problema de financiación; no es un problema tecnológico; no es un problema de disponibilidad

Web services W3c-SOAP

ICC GeoCodification

WebWeb servicesservices W3cW3c--SOAPSOAP

ICC ICC GeoCodificationGeoCodification

Web services W3c-SOAP

ICC GeoCodification

WebWeb servicesservices W3cW3c--SOAPSOAP

ICC ICC GeoCodificationGeoCodification

Web Map Services OGC

ICCDept .Medi Ambient i HabitatgeCREAFIGNCadastreLOCALRETAjuntaments

WebWeb MapMap ServicesServices OGCOGC

ICCICCDeptDept .Medi Ambient i Habitatge.Medi Ambient i HabitatgeCREAFCREAFIGNIGNCadastreCadastreLOCALRETLOCALRETAjuntamentsAjuntaments

Web Map Services OGC

ICCDept .Medi Ambient i HabitatgeCREAFIGNCadastreLOCALRETAjuntaments

WebWeb MapMap ServicesServices OGCOGC

ICCICCDeptDept .Medi Ambient i Habitatge.Medi Ambient i HabitatgeCREAFCREAFIGNIGNCadastreCadastreLOCALRETLOCALRETAjuntamentsAjuntaments

Web Features Services OGCWebWeb FeaturesFeatures ServicesServices OGCOGC

Web Coverages Services OGCWebWeb CoveragesCoverages ServicesServices OGCOGC

Web Features Services OGCWebWeb FeaturesFeatures ServicesServices OGCOGC

Web Coverages Services OGCWebWeb CoveragesCoverages ServicesServices OGCOGC


de datos; y no es un problema de restricción de acceso a datos. En realidad, se trata de una cuestión de actitud/cultura, prioridades políticas, organización, etc.

4. Retos actuales

4.1. Política de Datos Esta es una asignatura pendiente en todos los casos, pues hasta ahora no se daba

como necesidad perentoria el hecho de definir una política y unas condiciones para el acceso y difusión de los datos municipales. Puede afirmarse que la postura ini-cial de la mayoría de los entes locales es totalmente abierta a la compartición y libre acceso de la información.

Una propuesta será elaborada y comentada, a finales de año, con las organiza-ciones locales, e-administración (CAOC) y varios municipios, sobre la disponibili-dad y las restricciones de los diferentes tipos de datos, para poder adoptar una polí-tica final armonizada que contemple las siguientes posibilidades:

• Información de acceso libre y abierto a todos los usuarios. • Información de acceso libre pero que requiere previo registro del usuario. • Información de acceso libre pero que requiere previo registro del usuario y

pago. • Información de acceso libre pero restringido con registro previo. • Información de acceso restringido, de pago, y con registro previo.

4.2. Gestión de derechos digitales (control de acceso) Con objeto de que los proveedores (en este caso los municipios) puedan confiar

en las nuevas posibilidades, se les tiene que facilitar canales de distribución apro-piados y tecnologías de protección y copyright para garantizar un mínimo nivel de seguridad, especialmente si se quiere que participen también los pequeños provee-dores. Se está trabajando en algunos desarrollos que incluyen las tecnologías apro-piadas, como:

• DRM (Digital Rights Management). • SAML (Security Assertion Markup Language). • XACML (Access control Markup Language). • WPOS (Web Pricing and Ordering Services). • Control de accesos con WFS+PDP+PEP+FPS.


Un esquema de la arquitectura prevista para desarrollar dicho sistema de control

es la que se muestra en la siguiente figura 4:

Figura 4. Arquitectura propuesta

4.3. Evaluación del impacto Esto es una tarea pendiente, pero se está trabajando en ello. Con la participación

local se dispone de una base más amplia para analizar los impactos de la IDE. Se seguirá la propuesta de la Dirección General Information Society and Media – Eu-ropean Comission Proposal for e-Government, que considera estos tres elementos: eficacia económica, democracia y efectividad social.

4.4. Proyectos nuevos Según se ha mencionado anteriormente, la IDE temática local será una platafor-

ma para desarrollar proyectos nuevos operacionales, entre ellos: • Transacciones y proceso laboral (WFS-T): callejero (regional/Gobierno lo-

cal); utilities (Gobierno local/empresas privadas). • E-Gobierno: compartiendo datos con asociaciones profesionales (arquitec-

tos, ingenieros, etc.) (Gobierno local/instituciones). • Geoportales: planeamiento urbano, turismo (regional/Gobierno local).

MunicipalityWFS

MunicipalityMunicipalityWFSWFSMunicipalityWFS



MunicipalityMunicipalityWFSWFS

MunicipalityWFS




MunicipalityMunicipalityWFSWFS

WMSWMSWMS

PDP(Policy Decision Point)

PDPPDP(Policy Decision Point)

FPS(Feature Portrayal Service)

FPSFPS(Feature Portrayal Service)(Feature Portrayal Service)

ICC WFSICC WFSICC WFS Catalonia topographic data

Catalonia Catalonia topographic datatopographic data

X (Firewall rules)

PoliciesRoles

Layers styles

ViewerViewer


Referencias

[1] Geoportal IDEC – “Projecte IDEC, 2002, Dossiers de presentació v.1 & 2003, Dossiers de presentació v.2.”

[2] J. Guimet, “Spatial Data Infrastructures, a new paradigm within the domain of Geospatial information. The example of the catalan SDI Project (IDEC)”, 2005, http://www.geoportal-idec.net/geoportal/eng/pdf/ide_nouparadigma.pdf.

[3] Open GIS Consortium, Inc., “OpenGIS Reference Model”, 2002. [4] J. Guimet, “Thematic SDI’s: a way to spread out the benefits of interoperabil-

ity and to enhance the development of Regional SDI’s”. Proceedings of 10th EC-GIS workshop, 2004.

[5] J. Guimet, “SDI Catalonia: A Regional Approach”, Global Magazine for Geomatics, , Vol. 19, No. 6, junio 2005, http://www.giminternational.com /v_gim/archives/chapter_content.asp?v0=detail&v1=486.

[6] General Accounting Office – USA, “GIS: Challenges to Effective Data Shar-ing”, 2003.


IDERioja, despliegue de servicios IDE en el ámbito de la Administración local

G. López García†, R. Corredor Fernández‡, P. Martínez Pérez‡

† Sección de Sistemas de Información Geográfica y Cartografía Dirección General de Política Territorial

Consejería de Turismo, Medio Ambiente y Politica Territorial Gobierno de La Rioja

Prado Viejo, 62 bis, 26005, Logroño (La Rioja) e-mail.: [email protected]

‡ Agencia del Conocimiento y la Tecnología

Calle General Sanjurjo, 2 bajo, 26004, Logroño (La Rioja) e-mail: {ricardo.corredor, pablo.martinez}@saicar.es

Resumen

El desarrollo de servicios IDE en el ámbito de la Administración local se en-cuentra con dificultades añadidas, derivadas del reducido tamaño de muchas de estas administraciones. Con objeto de impulsar este desarrollo, el Gobierno de La Rioja ha iniciado un plan para la puesta en marcha de servicios IDE en todos los municipios de su Comunidad Autónoma, con utilidades pensadas y orientadas fun-damentalmente al usuario rural. Palabras clave: información geográfica, infraestructuras de datos espaciales, IDE, Administración local, La Rioja 1. Introducción

Acercar la información geográfica a los usuarios requiere de un instrumento que

permita que dicha información se canalice desde el productor hasta el consumidor. Si este instrumento atiende a unos estándares, se consigue que cualquier usuario pueda acceder con la misma herramienta al máximo número de productores y que al mismo tiempo un productor pueda atender al máximo número de usuarios.

El desarrollo actual de las Infraestructuras de Datos Espaciales (IDEs) está con-siguiendo en términos de operatividad un óptimo funcionamiento de este modelo, pero si se analiza el volumen de productores y consumidores, se observa que en la


actualidad sólo intervienen en el mismo una pequeña parte de los actores que debe-rían estar presentes.

En el caso de los productores es fácil comprobar que actualmente únicamente ofrecen servicios IDE los grandes organismos, capaces de contar con los medios económicos y técnicos necesarios para desarrollar estos servicios, en tanto que los pequeños productores de datos no están presentes en el mercado ya que, por una simple cuestión de tamaño, normalmente carecen de los medios y la tecnología necesarios. Este es el caso de la gran mayoría de los municipios que, aunque dispo-nen de fuentes de información geográfica de gran interés para el ciudadano, care-cen de la capacidad suficiente para ponerlas a su alcance.

De forma similar a lo que ocurre en el caso de los productores, existe otra grave carencia en el caso de los usuarios. Un ligero análisis sobre esta cuestión revelaría que actualmente los servicios IDE son utilizados casi exclusivamente por usuarios con una alta cualificación técnica, quedando fuera del modelo de información el usuario medio, que es el más numeroso y al que en mayor medida deberían ir diri-gidos los servicios IDE.

Conseguir que en este modelo de información pueda estar incluido el mayor número de productores y demandantes de información geográfica, es uno de los retos que se ha planteado el Gobierno de La Rioja. Para conseguir este objetivo y poder diseñar estrategias eficaces se ha partido de un sencillo análisis que se detalla a continuación.

2. Análisis de la situación En la Comunidad Autónoma de La Rioja existen actualmente 174 municipios,

disponen todos ellos de cartografía urbana 1:500 / 1:1.000. Además, esta informa-ción cartográfica no se encuentra disponible a través de Internet. Para resolver esta carencia el Gobierno de La Rioja, en el año 2005, ofreció a todos los ayuntamien-tos de la comunidad autónoma, con excepción de Logroño y Calahorra que admi-nistran su cartografía con medios propios, su colaboración para hacer llegar al ciu-dadano la cartografía urbana de forma gratuita, de la misma forma que lo hace el propio Gobierno regional con sus datos geográficos, dicho ofrecimiento es acepta-do por 171 ayuntamientos.

Por otra parte, aproximadamente el 50% de la población de La Rioja habita en Logroño, el resto se reparte entre sus municipios, la mayor parte de los cuales tiene un tamaño entre 100 y 1.000 habitantes. Además de este hecho, hay que destacar que una gran parte de la población que habita en Logroño procede del medio rural, con el que no ha perdido sus lazos, conservando en muchos casos sus fincas y casas de procedencia a las que acude regularmente los fines de semana y vacaciones, por lo que el principal foco de interés geográfico para un usuario potencial se sitúa en el ámbito rural.

Además, de entre todas las fuentes de información geográfica que pueden po-nerse al alcance del usuario rural a través de tecnologías IDE, la información catas-


tral destaca especialmente sobre todas las demás por obvias razones de índole eco-nómico, siguiendo en orden de interés la ortofotografía aérea, al hacer posible un fácil reconocimiento del territorio y la información geográfica propia del municipio (cartografía urbana y planeamiento urbanístico), quedando muy relegadas a un segundo plano las fuentes de información temática relativas a variables geofísicas, medioambientales o sociológicas.

Para que todo el sistema funcione a pleno rendimiento, además de disponer de información y de usuarios interesados para dicha información, se requiere que exis-tan puntos de acceso a Internet. En este sentido el lento desarrollo de Internet en el ámbito rural, debido en una buena parte a la escasez de infraestructuras y al desin-terés de su población por las nuevas tecnologías, resulta una circunstancia desfavo-rable.

En el caso de La Rioja, la Fundación Riojana para la Sociedad del Conocimien-to (FUNDARCO) lleva años realizando una labor de estimulación para fomentar el uso de Internet en el ámbito rural; potenciando el desarrollo de infraestructuras capaces de llevar la red a cualquier punto de la geografía riojana; formando y ani-mando a su población a través de cursos; facilitando el acceso mediante la ayuda financiera para la compra de ordenadores e instalando puntos de acceso a Internet gratuitos en una gran parte de los municipios.

3. Estrategias de desarrollo Una vez analizada la situación observamos que para desarrollar las tecnologías

IDE y fomentar su utilización en el ámbito municipal, en un colectivo de caracterís-ticas tan determinadas como es el usuario rural, se propone desarrollar el proyecto en base a las siguientes estrategias.

3.1. Habilitación de servicios IDE Con la habilitación de servicios IDE para la información geográfica municipal,

se pretende que cada municipio disponga de un servicio WMS propio al que se pue-dan ir incorporando en un futuro distintas capas de información.

3.2. Desarrollo de herramientas de consulta

Esta estrategia consiste en el desarrollo de herramientas de consulta extraordina-

riamente intuitivas que: • Resulten sencillas de manejar y no exijan ningún conocimiento previo. • Permitan al usuario incorporar fácilmente la información de su interés. • Respondan a sus expectativas.


• Sean accesibles desde las páginas que el usuario visita asiduamente.

En este sentido se propone el desarrollo de un visualizador muy básico, en el

que se ha primado la simplicidad de utilización sobre las funcionalidades de tipo técnico.

El acceso a dicho visualizador se debería poder realizar desde distintas páginas de ámbito local. El objetivo es que no tenga que ser el usuario quien haga el es-fuerzo de búsqueda y localización del visualizador, sino que éste lo encuentre dis-ponible en las páginas que visita más asiduamente.

3.3. Ahorro económico

Conseguir que este desarrollo no suponga una carga económica ni técnica para

los municipios, al no disponer éstos de recursos suficientes para este fin. Cualquier tipo de propuesta que suponga un coste añadido a las economías municipales se podría encontrar muy probablemente con una resistencia muy fuerte para su im-plantación.

Con el fin de minimizar los costes del proyecto, se ha propuesto el uso de soft-ware libre tanto para la puesta en funcionamiento de los servicios WMS, como para la plataforma de desarrollo del visualizador.

Para abaratar los costes del proyecto en base al principio de economía de esca-las, se indica la conveniencia de utilizar un solo servidor informático para sostener todos los servicios, desarrollar un único visualizador geográfico que mediante pa-rámetros se pueda personalizar para los distintos municipios y adaptar la informa-ción geográfica siguiendo un mismo patrón.

Dado que se pretende conseguir el coste óptimo para todo el proyecto, se estima conveniente que éste sea desarrollado por un solo equipo técnico a fin de capitali-zar el conocimiento adquirido a medida que se desarrolla el mismo.

En definitiva se trata de proveer soluciones compatibles, baratas, sencillas y ca-paces de responder a las expectativas que generan.

4. Acciones El Gobierno de La Rioja ha materializado la estrategia de desarrollo asumiendo

las siguientes acciones:

• Adaptación de la información geográfica municipal para su distribución mediante servicios IDE.

• Adquisición y gestión de un servidor donde concentrar servicios WMS mu-nicipales.

• Desarrollo de un visualizador universal parametrizado, capaz de ser inclui-do como un enlace en la página web municipal, así como en cualquier otra


perteneciente a grupos de interés tales como asociaciones culturales, de de-fensa del medio rural, páginas personales sobre el municipio, etc.

Para lograr que el coste para sostener estos servicios fuera el mínimo, las distin-

tas soluciones se han desarrollado mediante la utilización de software libre. La provisión de servicios WMS se ha realizado con Minnesota Web Map Server (http://mapserver.gis.umn.edu/) en tanto que el desarrollo del visualizador se ha realizado utilizando como base el entorno Ka-Map (http://ka-map.maptools.org/), adaptándolo a las necesidades del proyecto.

Los gastos derivados del desarrollo informático así como los de la compra del hardware y la conversión de la información han sido asumidos por la Dirección General de Política Territorial, habiendo supuesto éstos un esfuerzo económico muy razonable ya que el mismo servidor y el mismo visualizador provee una solu-ción para todos los municipios, por lo que la ratio coste/municipio resulta muy baja.

El único compromiso por parte de los municipios es el derivado de la cesión de la información cartográfica urbana para su puesta a disposición pública a través de Internet.

5. Soluciones

5.1. Servidores WMS Como ya se ha señalado anteriormente, para sostener los servicios WMS se ha

utilizado software libre, para ello el Gobierno de La Rioja ha asumido los trabajos de adaptación de la información geográfica municipal.

Esta adaptación ha consistido en el procesamiento de los distintos ficheros de cartografía urbana para su conversión en una serie de capas temáticas (shapefiles) en el entorno del núcleo urbano.

Con objeto de guardar una cierta homogeneidad para la información ofrecida por los distintos municipios, se ha realizado un análisis previo para estudiar y com-parar la estructura de las distintas cartografías urbanas. En un primer paso se trata-ba de conseguir un mínimo común para todos los municipios.

Cada servicio WMS compatible con la versión 1.1.1., se ha estructurado de la misma forma, pero de manera independiente para cada municipio, guardando entre todos ellos una completa analogía.

Nombre del servidor: “IDERIOJA nombredelmunicipio [Spain] WMS

Un ejemplo para el caso de Nájera (La Rioja): “IDERIOJA Najera [Spain] WMS”.


Los servicios se invocan mediante un parámetro (código INE +código alfanumé-

rico) que hace referencia a un servidor específico. Un ejemplo para el caso de Alfa-ro: código “011alfa”

GetCapabilities: http://www.iderioja.org/municipios/request.asp?mun=011alfa& GetFeatureInfo: http://www.iderioja.org/municipios/request.asp?mun=011alfa& GetMap: http://www.iderioja.org/municipios/request.asp?mun=011alfa&

Los formatos soportados son gif, jpeg, png, bmp, tiff, mientras que para los sis-

temas de coordenadas soportados tenemos el ED50/UTM zone30 y WGS 84. Para el caso de las capas se ha intentado seguir un patrón común. Un ejemplo para el caso de Arrendó (La Rioja) sería el siguiente:

Arnedo_Calles(Calles-Textos) Arnedo_Cotas(Cotas) Arnedo_Cultivos_Textos(Cultivos-Textos) Arnedo_Cursos_Agua(Cursos_Agua) Arnedo_Curvas_Nivel(Curvas Nivel) Arnedo_Edificios(Edificaciones) Arnedo_Edificios_Alturas(Edificaciones-Alturas) Arnedo_Edificios_Portales(Edificaciones-Portales) Arnedo_Parcelas(Parcelas) Arnedo_Termino_Municipal(Termino_Municipal)

5.2. Visualizadores de mapas

Habitualmente las herramientas IDE que están ubicadas en páginas específicas de información geográfica casi siempre fuera de los circuitos de consulta más po-pulares, requieren de conocimientos muy especializados sobre información geográ-fica, sistemas de coordenadas, proyecciones, datums y sobre la propia naturaleza de los servicios que se prestan respondiendo normalmente a una oferta de información pensada exclusivamente desde el punto de vista del que ofrece la información.

En el caso del visualizador que se ha desarrollado, se ha intentado que cumplie-ra los siguientes requisitos:

• Un solo desarrollo para todos los municipios, que se pudiera invocar me-

diante una URL parametrizada. Esto permite la incorporación de mejoras de funcionamiento de forma inmediata y automática en todos los municipios. Dado que la URL funciona como un enlace personalizado para cada muni-cipio, éste se puede incluir como un servicio en la página web del propio municipio o en cualquier otra que lo quiera referenciar. El enlace al visua-lizador del municipio de Haro (La Rioja) sería por ejemplo la siguiente URL www.iderioja.org/municipios/index.php?map=HARO, tal y como apa-rece en la figura 1.


Figura 1. Aspecto general del visualizador

• El visualizador incorpora únicamente lo ortofotografía de La Rioja, la in-

formación de la cartografía urbana, del WMS de la Comunidad Autónoma de La Rioja y el WMS de la Dirección General del Catastro, mediante una sencilla activación tipo checkbox (véase figura 2).

Figura 2. Selección de capas de información

• Una vez activada la información catastral el usuario, mediante un simple

clic conecta con la Oficina Virtual del Catastro para obtener la información catastral específica de la finca (véase figura 3).

• Se incorporan utilidades de zoom, mapa de referencia y funcionamiento a pantalla completa (véase figura 4).


Figura 3. Consulta catastral a partir del visualizador

Figura 4. Opciones de zoom, navegación y mapa guía

Figura 5. Enlaces a otros servicios


• Para simplificar al máximo su operativa se ha evitado incluir otras funcio-nalidades de carácter más técnico como son la selección de sistemas de co-ordenadas o la incorporación de nuevos servidores WMS.

• Para usuarios con mayores necesidades de información se han incluido en-laces a la página del Gobierno de Rioja para la descarga de cartografía en formato nativo, al visualizador IDERioja, de uso general que a su vez incor-pora como opción la activación de los servidores WMS municipales, al Sis-tema de Información Urbanística de La Rioja (SIU), al visualizador de la IDE Española (IDEE) y a la Oficina Virtual del Catastro, tal y como muestra la figura 5).

El estado actual de desarrollo del proyecto así como el acceso a los distintos vi-

sualizadores y servicios WMS, puede ser consultado a través de la página web www.iderioja.org/municipios

6. Calendario de actuaciones A lo largo del año 2006 se han desarrollado los trabajos para la puesta en mar-

cha de todos los municipios cabeceras de comarca, y está previsto abordar la totali-dad de los municipios a lo largo del año 2007, ampliando de forma paralela sus contenidos.

Con esta actuación, el Gobierno de La Rioja intenta impulsar la participación de los municipios riojanos en la Infraestructura de Datos Espaciales Española, sin pretender con ello suplantar las competencias propias de la Administración local en esta área, sino estimular su desarrollo.


gvSIG: un cliente avanzado para las infraestructuras de datos espaciales

A. Anguix Alfaro†, L. W. Sevilla Muelas‡, G. Carrión Rico‡

† IVER Tecnologías de la Información Calle Salamanca 52, 46005, Valencia


‡ Conselleria de Infraestructuras y Transporte Avenida Blasco Ibáñez 50, 46010, Valencia e-mail: {sevilla_lui, carrion_gab}@gva.es

Resumen En este capítulo analizaremos el papel de una aplicación cliente pesado dentro

del ámbito de las infraestructuras de datos espaciales. Describiremos la funcionali-dad que aporta una aplicación cliente de estas características desarrollado en soft-ware libre como es gvSIG.

Palabras clave: infraestructuras de datos espaciales, Open Geospatial Consortium, servicios, estándares, interoperabilidad, sistemas de información geográfica, clien-tes pesados, INSPIRE, software libre, IDE, OGC.

1. Introducción El mundo de la información geográfica está en plena transformación, revolución

y evolución que tiene su antecedente en los cambios producidos en los fundamen-tos en los que se apoya, y en los que aparecen términos desconocidos hace unos años como Infraestructuras de Datos Espaciales, estándares, interoperabilidad o software libre. Conceptos que se están asentando a un ritmo vertiginoso y que han traído consigo un nuevo modelo, posible gracias a Internet, que abarca a todos los segmentos de usuarios, generadores de datos y herramientas para su explotación. Un nuevo modelo en el que compartir es el factor clave.

Estamos en los comienzos de la nueva era de la información geoespacial, en el que todos pueden participar en mayor o menor medida. Una nueva era en la que las Infraestructuras de Datos Espaciales son el nuevo paradigma.


Según la Real Academia Española, en su segunda acepción, se define “Infraes-

tructura” como “conjunto de elementos o servicios que se consideran necesarios para la creación y funcionamiento de una organización cualquiera”.

Las Infraestructuras de Datos Espaciales se basan en servicios, son los protoco-los de comunicación entre servidores y usuarios de información. Del mismo modo que podemos encontrar distintos tipos de servidores, es preciso considerar que no hay una única clase de usuario de información espacial. Podemos encontrar desde los más básicos, que simplemente necesitan consultar la información mediante un geoportal, con cualquier navegador de Internet al uso, a usuarios con perfiles avan-zados, que requieren de herramientas que les permitan explotar la información geoespacial en el más amplio sentido.

En las Infraestructuras de Datos Espaciales nos encontramos con grandes canti-dades de información geoespacial suministradas por las entidades más indicadas para ello; la información catastral es aportada por la Dirección General del Catas-tro, la información geográfica nacional por el Instituto Geográfico Nacional, la información geográfica autonómica por el Instituto Cartográfico u organismo auto-nómico competente, el Plan General de Ordenación Urbano por el ayuntamiento correspondiente, etc.

gvSIG, al ser un cliente pesado, aporta al concepto de Infraestructura de Datos Espaciales esa capacidad de geoprocesamiento que necesitan usuarios avanzados de forma local, del mismo modo al ser un cliente avanzado activa la interoperabili-dad potencial de las Infraestructuras de Datos Espaciales uniendo en un mismo punto el acceso a multitud de servicios estándares y la capacidad de trabajar con distintos formatos de datos espaciales procedentes de diversas fuentes.

2. Motivaciones y requisitos de un cliente pesado para una IDE en software libre. Origen de gvSIG

El origen de gvSIG [1] debemos buscarlo a finales de 2002, cuando la Conselle-

ria de Infraestructuras y Transporte de la Generalitat Valenciana (en adelante la Conselleria) emprende un proceso de migración a sistemas abiertos bajo Linux de todos sus sistemas informáticos. Dentro de este proceso adquiere un especial relie-ve la migración del software de SIG y CAD, ya que por las características de la Con-selleria son relevantes los usuarios que trabajan, de una u otra manera, con infor-mación cartográfica. A esto se suma que dentro del mundo del software libre, en esos momentos, el SIG y el CAD son áreas prácticamente desconocidas.

Se realiza un estudio de la comunidad del software libre, comparando los pro-yectos relacionados con los Sistemas de Información Geográfica con el software propietario más extendido en el mercado y teniendo en cuenta las necesidades de una administración con las características de la Conselleria, máximo órgano res-ponsable del Consell de la Generalitat en materia de obras públicas, transportes, arquitectura, puertos y costas, energía y telecomunicaciones. Para conocer estas necesidades se diseña una encuesta que recoja la máxima información posible de


los usuarios que en aquel momento trabajaban con información geográfica, así como de los posibles usuarios potenciales. La encuesta recoge información de todo tipo, desde las tareas y funciones de cada uno de los encuestados al hardware y software que utilizaban, tanto gráfico como no gráfico, realizando especial hincapié en las herramientas SIG/CAD utilizadas, en los formatos, tipos de datos cartográfi-cos, operaciones habituales, frecuencia de actualización, programación a medida, etc.

Con toda la información recogida, tanto del estudio de necesidades como de software disponible en la comunidad del software libre, se concluye que no se en-cuentra lo suficientemente avanzado ningún proyecto que permita la migración de software propietario a abierto en los campos de los Sistemas de Información Geo-gráfica y Diseño Asistido por Ordenador (SIG/CAD), pero sí que se podía abordar la tarea de poner en marcha un proyecto de desarrollo encaminado a cubrir las caren-cias existentes.

La Conselleria sacó a concurso público el desarrollo de un SIG para solventar las necesidades de sus usuarios y que cumpliese las siguientes características:

• Portable: funcionará en distintas plataformas hardware/software, podrá uti-

lizarse con cualquier sistema operativo, en las distintas variantes de Linux, Windows o Mac OS X.

• Modular: será ampliable con nuevas funcionalidades una vez finalizado su desarrollo.

• De código abierto: el código fuente original con el que sea escrito estará disponible.

• Sin licencias: una vez finalizado el desarrollo no habrá que pagar nada por cada instalación que se realice, sin límite de número.

• Interoperable con las soluciones ya implantadas: será capaz de acceder a los datos de otros programas propietarios sin necesidad de cambiarlos de formato.

• Sujeto a estándares: sigue las directrices marcadas por el Open Geospatial Consortium (OGC) [2] y la Unión Europea.

El lenguaje de programación elegido, una vez evaluados pilotos en C y en Java,

es este último, asegurando así su funcionamiento multiplataforma y por tanto el requisito de portabilidad.

Los participantes iniciales del proyecto gvSIG son los siguientes: • Generalitat Valenciana a través de la Conselleria de Infraestructuras y

Transporte como impulsora del proyecto. • IVER Tecnologías de la Información, empresa ganadora del concurso, co-

autora, y que lleva el peso del desarrollo, disponiendo de un área dedicada en exclusiva a soluciones SIG e IDE en software libre.

• Universidad Jaume I, como coordinadora y supervisora de que el desarro-llo siga todos los estándares internacionales.


Durante el desarrollo de gvSIG es necesario reseñar un suceso que modifica la

evolución inicialmente prevista del proyecto: la Conselleria recibe el encargo de realizar un estudio del nuevo modelo que surge a la hora de trabajar con informa-ción geográfica, las Infraestructuras de Datos Espaciales. El estudio de la iniciativa INSPIRE [3] y de la IDE de carácter público plantea la evolución de gvSIG de cliente SIG a cliente IDE. Por tanto el proyecto gvSIG decide abordar el estudio y puesta en marcha de la implementación de una IDE en software libre. gvSIG se convierte en un cliente IDE, pudiendo integrar en una misma vista datos de distintos orígenes junto a datos locales.

Como cliente pesado dentro del marco de la IDE, gvSIG tiene como objetivo cu-brir las necesidades de cualquier usuario de información geográfica. Esto incluye un inmenso abanico de formatos y orígenes de información, temáticas, herramien-tas especializadas y comunes, etc., en el que se encuentra, integrado, el concepto de las Infraestructuras de Datos Espaciales. Y no debemos pasar por alto el hecho de que el usuario de información geográfica puede ser, lo es en realidad, cualquier usuario de información.

El proyecto se presenta, a través de su web (www.gvsig.gva.es), en agosto de 2004. A partir de ese momento las distintas versiones van sucediéndose en el tiem-po, ampliando cada vez más el número de funcionalidades disponible.

Actualmente gvSIG es un proyecto maduro, de evolución constante, con el pro-grama y fuentes descargables en la web del proyecto, y al que por la misma filoso-fía de trabajo de los proyectos de desarrollo en software libre se incorporan nuevos colaboradores dispuestos a mejorar el producto (Laboratorio RESO de la Universi-dad de Rennes, Instituto de Desarrollo Regional de Albacete, LatinGEO de la Uni-versidad Politécnica de Madrid, el departamento de sistemas informáticos y com-putación de la Universidad Politécnica de Valencia, el Instituto Geográfico Nacio-nal, Ministerio de Fomento, etc.).

3. Un cliente IDE desarrollado con software libre gvSIG es, en primer lugar, un proyecto de desarrollo en software libre, con la li-

cencia más abierta de las posible, la denominada GNU/GPL [4]. Esta licencia asegu-ra al usuario estas cuatro libertades:

• Ejecutar el programa con cualquier propósito (privado, educativo, público,

comercial, etc.). • Estudiar y modificar el programa (para lo cual es necesario tener acceso al

código fuente). • Copiar el programa de manera que se pueda ayudar a cualquiera. • Mejorar el programa, y hacer públicas las mejoras, de forma que se benefi-

cie toda la comunidad.


Estos derechos o libertades se traducen en claras ventajas para el usuario, desde la fundamental independencia de proveedores al acceso libre a la tecnología y la capacidad de decisión a la hora de invertir en nuevas herramientas, a la posibilidad de mejora del software por cuenta propia, ventajas por las que cada vez más usua-rios apuestan por los programas libres. Al fin y al cabo, de lo que se trata es de poseer o no poseer la tecnología.

gvSIG como cliente avanzado de interoperabilidad de las IDE pasa a formar par-te de una familia de programas que permiten montar el sistema IDE en software libre. Existen aplicaciones como MapServer [5], GeoServer [6], Deegree [7] o GeoNetwork [8] de la FAO/ONU, que junto con gvSIG ponen a nuestra disposición un abanico de posibilidades, en definitiva de elección, para no estar subordinados al software privativo.

4. El papel de un cliente pesado en el ámbito de una IDE gvSIG, como ya se ha comentado, se desarrolla alrededor del concepto de Sis-

tema Integral de Información Geoespacial. Esto significa que en gvSIG podemos encontrar, y encontraremos cada vez más, una gran variedad de herramientas para analizar, gestionar y trabajar con información geoespacial de todo tipo (cartografía vectorial, imágenes ráster, datos alfanuméricos, etc.). El ser un cliente IDE va a permitir que no sea discriminatorio el origen de los datos a la hora de aplicar esas herramientas, esto es, poder trabajar tanto con datos remotos como locales.

gvSIG es un cliente IDE, y como tal es cliente de los distintos servicios de las In-fraestructuras de Datos Espaciales. gvSIG es cliente compatible con varias especifi-caciones de interfaces OpenGIS: Web Map Service (WMS) [9], Web Feature Servi-ce (WFS) [10], Web Coverage Service (WCS) [11], de catálogo [12] y de nomen-clátor.

La especificación WMS produce mapas de datos espaciales referidos de forma dinámica a partir de información geográfica. Este estándar internacional define un “mapa” como una representación de la información geográfica en forma de imagen digital conveniente para la exhibición en una pantalla de ordenador. Un mapa no consiste en los propios datos. Los mapas producidos por WMS se generan normal-mente en un formato de imagen como PNG, GIF, JPEG. En gvSIG podremos acceder a estos servicios WMS y cargar estas imágenes de mapa como una capa más. Como podemos observar en la siguiente figura 1 en la que se muestra una composición de capas proporcionadas por diferentes WMS.


Figura 1. Vista formada por la composición de capas provistas por distintos WMS remotos

WFS es el acrónimo de Web Feature Service. Si el WMS utiliza formatos ráster

(phg, gif, jpeg) para compartir las capas, el estándar WFS utiliza GML, Geography Markup Language [13]. El WFS permite el acceso avanzado a información vecto-rial, lo que se traduce en gvSIG en poder trabajar con los datos como si fuera in-formación vectorial local, realizando análisis, leyendas temáticas, geoprocesamien-to, etc.

WCS es el acrónimo de Web Coverage Service. En este caso la información son capas ráster en formatos SIG originales. Con gvSIG podremos cargar estas capas, normalmente imágenes satélite u ortofotos, y realizar las acciones propias que gvSIG permite sobre cualquier capa ráster.

Así pues, gvSIG permite, como cliente IDE, añadir, cruzar con información lo-cal, y trabajar con capas remotas de distintos orígenes en cualquiera de las varian-tes propuestas por el Open Geospatial Consortium (OGC), WMS, WFS y WCS.

Además de estos servicios, dentro de la Infraestructura de Datos Espaciales, po-demos encontrar lo que se denominan servicios de descubrimiento, que como su nombre indica, nos van a servir para encontrar información que cumpla unos crite-rios de búsqueda.

Existen dos servicios de descubrimiento para las IDE, ambos implementados en gvSIG:


• Servicio de catálogo. Nos va a permitir la búsqueda de recursos cartográfi-cos mediante campos clave como nombre, escala, tema, etc., devolviendo una lista de los metadatos (datos que definen los recursos cartográficos) co-incidentes. El acceso a estos recursos puede ser directo, cargándolo gvSIG como una capa, o indirecto, mostrando una referencia del modo de obtener ese recurso. Por tanto, al utilizar gvSIG como cliente de catálogo, introdu-ciendo unos criterios de búsqueda, la aplicación nos devolverá como resul-tado aquellos recursos, ubicados en el servidor indicado, que los cumplen.

• Servicio de nomenclátor. Un nomenclátor, en nuestro caso, es una lista de topónimos georreferenciados, esto es, una lista en el que cada topónimo contiene información de las coordenadas geográficas donde se ubica. Con gvSIG podemos utilizar el servicio de nomenclátor para buscar la ubicación de un determinado topónimo, devolviéndonos la aplicación un zoom a la zona geográfica a la que se refiere dicho topónimo.

Como hemos visto gvSIG permite interoperar los distintos servicios IDE dentro

de un cliente SIG avanzado, poniendo a disposición del usuario las herramientas necesarias para cubrir desde las necesidades básicas de consulta a las complejas de análisis espacial. Estas herramientas las veremos en los siguientes apartados.

5. Funcionalidad de un SIG vectorial La primera fase que se abordó con gvSIG es la de cubrir las necesidades propias

de un usuario de un SIG vectorial. Necesidades que se han ido cubriendo en los dos últimos años, desde el inicio del proyecto, de manera progresiva, abordando en primer lugar las herramientas más básicas, para pasar a continuación a implementar aquellas de uso menos frecuente.

Actualmente podemos considerar a gvSIG como un completo SIG vectorial, de gran potencia y que permite trabajar con los formatos de datos más usuales en car-tografía, tanto vectorial como ráster.

Los formatos vectoriales con los que permite trabajar son el SHP (shape), DXF (formato de intercambio de AutoCAD), DWG (formato propio de AutoCAD) y DGN (formato propio de MicroStation), además de con bases de datos espaciales como PostGIS o MySQL.

Entre las herramientas disponibles encontramos las propias de carga de datos, navegación (zooms, encuadres, desplazamientos, etc.), consulta de información (información de un elemento, medición de distancias, etc.), cartografía temática (leyendas por valores únicos, por intervalos, autoetiquetado, etc.), selección de elementos (selección gráfica, selección por atributos, espacial, etc.), tablas (estadís-ticas, ordenación, relacionar tablas, enlazar tablas, etc.), constructor de mapas, herramientas de geoprocesamiento, etc. En definitiva, todo aquello que se necesita para poder trabajar con información vectorial.


En el horizonte cercano, se plantea seguir ampliando la funcionalidad de gvSIG

como SIG vectorial, añadiendo nuevas herramientas como un constructor de símbo-los avanzado, una herramienta de georreferenciación de datos alfanuméricos o un completo sistema de gestión de redes.

Podemos observar en la siguiente figura 2 un ejemplo de tratamiento de datos vectoriales con gvSIG.

Figura 2. Tratamiento de datos vectoriales en gvSIG

6. Integración de herramientas CAD en un cliente IDE Un programa de CAD, como su nombre indica, es un programa de diseño asisti-

do por ordenador. Como tal, un CAD tiene multitud de usos, desde el diseño indus-trial al arquitectónico, pasando por la edición de cartografía. En gvSIG el objetivo no era crear un CAD, sino implementar dentro de la aplicación aquellas herramien-tas necesarias para permitir edición cartográfica rigurosa, eliminando la dependen-cia de cualquier programa de CAD.


Así, gvSIG, dispone de herramientas de edición vectorial que permiten modifi-car, crear y eliminar elementos. Desde gvSIG podemos editar un fichero shape, una capa de nuestra base de datos espacial o un fichero CAD.

En todo momento gvSIG tiene en mente al usuario como cliente final y por tanto se intenta que las distintas funciones que va integrando gvSIG sean de fácil uso y no supongan una ruptura con los hábitos del usuario. Por ello, en la parte CAD, se ha habilitado una consola de comandos que permite trabajar de forma muy similar a alguno de los programas más extendidos del mercado.

gvSIG implementa herramientas de ayuda al dibujo, desde las rejillas o los co-mandos de deshacer, como la pila de comandos, a selecciones complejas de ele-mentos (dentro de circulo, fuera de rectángulo, etc.).

gvSIG dispone de herramientas para la inserción de elementos, como puntos, polígonos, líneas, elipses, etc., del mismo modo que dispone de herramientas para la modificación de los mismos, como la rotación de elementos o la simetría.

La evolución de gvSIG en la parte de edición rigurosa continuará, añadiendo más herramientas de uso frecuente, como alargar elementos, recortar, etc.

Es interesante reseñar que normalmente se aborda el mundo del SIG y del CAD como contrapuestos, cuando son, en realidad, complementarios. Por eso, desde gvSIG, lo que se busca, es su integración. La figura 3 muestra el modulo de CAD integrado en gvSIG.

7. Funcionalidad de un SIG ráster gvSIG dispone en la actualidad de algunas herramientas propias de un Sistema

de Información Geográfica ráster. Así con gvSIG podemos añadir algunos de los formatos más habituales para trabajar con datos ráster, georreferenciar imágenes, dotar de transparencia a la imagen, modificar el brillo y contraste, realce, etc.

Estas herramientas van a ser ampliadas de forma muy considerable en los próximos dos años, estando planificado integrar en gvSIG todas aquellas herra-mientas necesarias para trabajar como SIG ráster, en cualquiera de los ámbitos en que se utilizan estas aplicaciones, como la teledetección o la morfometría.

Así, gvSIG irá implementando en nuevas versiones, funciones básicas de SIG ráster, funciones de visualización y análisis visual (histogramas, filtros, tablas de color,etc.), funciones de tratamiento digital de imágenes (algebra de mapas, fun-ciones de transformación, fusión de imágenes, etc.), funciones de análisis espacial (funciones estadísticas, generación de modelos digitales del terreno, interpolación de superficies, perfiles de imagen, etc.) y funciones de análisis temporal/multi/ hiperespectral.

Del mismo modo, y dentro de la filosofía integradora de herramientas geoespa-ciales de gvSIG, se implementará un modulo avanzado de vectorización y pasteri-zación, que permita el paso entre ambos tipos de datos.

Como parte del SIG ráster se desarrollaran las herramientas necesarias para el es-tudio y tratamiento de datos hidrológicos.


Figura 3. Integración de CAD en gvSIG

8. Futuro trabajo de desarrollo gvSIG surgió con la idea de satisfacer las necesidades de los usuarios de la Con-

selleria de Infraestructuras y Transporte y por extensión de la Generalitat Valen-ciana. Inicialmente como un cliente SIG, posteriormente complementando el mundo SIG e IDE, lejos de aquellas visiones que los quieren presentar como antagónicos. En su evolución numerosas entidades, –empresa, administración y universidad principalmente– se acercan con interés al proyecto.

Las condiciones de uso del proyecto, las propias del software libre, proporcio-nan un plus de confianza que permite que de forma fluida se establezcan numerosas y variadas colaboraciones. Desde aquellos que quieren acercarse a la herramienta como usuario a los que quieren colaborar en su desarrollo, pasando por empresas que quieren incorporar a gvSIG en su portafolios o universidades que quieren utili-zar la herramienta para sus prácticas por poner algunos ejemplos.

Por otra parte, nos encontramos que en la Unión Europea a nivel tecnológico, se potencian las ayudas en I+D+I, especialmente aquellas destinadas a invertir en co-


nocimiento, priorizando que éste sea abierto como apuesta estratégica de la Unión Europea para fijar su posición en el mercado TIC en todo el mundo.

La conjunción de estos factores permite a gvSIG abordar un plan de desarrollo futuro con un doble objeto, de una parte dar respuesta a todas las necesidades rela-cionadas con el manejo de la información geoespacial, de otra que esta respuesta sea mediante la integración de tecnologías libres.

En este sentido además de los próximos proyectos orientados a dotar la herra-mienta de funcionalidades avanzadas ráster completo que permita ser usado en áreas como la teledetección, la geomorfometría, las imágenes RADAR o la hidrolo-gía, incorporar herramientas para la edición cartográfica rigurosa o continuar en la incorporación de funcionalidades propias de un SIG vectorial, se inician con distinta prioridad otras áreas de desarrollo.

Podemos destacar entre los nuevos proyectos aquellos relacionados con los aná-lisis de redes, SIG 3D (visualización, edición y composición de mapas 3D, integra-ción en dispositivos móviles, geoestadística), SIG 4D (gestión completa de capas de datos multitemporales), y RTGIS (procesado de datos espacio-temporales en tiempo real).

En definitiva, un amplio y ambicioso horizonte posible tanto por la escalabili-dad y modularidad de la herramienta como por su naturaleza libre.

9. Conclusiones Como hemos ido viendo en los distintos apartados, gvSIG es en realidad muchas

aplicaciones, muchos conceptos integrados en una única aplicación; aspectos habi-tualmente contrapuestos en el mundo de la información geográfica que gvSIG inte-gra (SIG/CAD, local/remoto, visor/SIG, técnico/usable, vector/ráster) forman parte de gvSIG en un todo.

Así gvSIG es todo lo ya comentado, un SIG vectorial, un SIG ráster, una aplica-ción de escritorio, un cliente avanzado de servicios remotos multiprotocolo (más allá de las IDE formales), un marco extensible para aplicaciones geoespaciales es-pecíficas, una aplicación multilingüe, etc., para convertirse en un cliente avanzado de las Infraestructuras de Datos Espaciales.

Entre las conclusiones podemos citar: • El mundo IDE es un complemento excepcional al mundo SIG. Debemos ob-

servarlos de forma complementaria. • Interoperabilidad y estándares se deben convertir en algo más que declara-

ciones de buena voluntad. Son claves si el mundo de la Información Geo-gráfica no quiere seguir permanentemente como hermana menor en el mundo de la informática.

• Software libre es sinónimo de compartir el conocimiento. • Compartir el conocimiento y la colaboración a partir del mismo son los va-

lores fundamentales de un nuevo modelo.


• gvSIG pretende ser una manifestación de este modelo y está concebido pa-

ra dar la mejor respuesta posible desde el punto de vista técnico. Modulari-dad, escalabilidad, internacionalización, portabilidad y usabilidad se en-cuentran en su carta de presentación.

• Y hablando de software libre o soluciones open source, un software no es libre hasta que se libera. A todo proyecto que se presente como tal se le debería exigir que explicite como puedo acceder a él.

• gvSIG es un proyecto abierto a todas aquellas colaboraciones y que preten-de en torno al proyecto consolidar una comunidad que sea la que vaya diri-giendo la evolución del mismo.

Citando al pensador, economista y político inglés John Stuart Mill no existe una

mejor prueba del progreso de una civilización que la del progreso de la coopera-ción.

Referencias

[1] Proyecto gvSIG: http://www.gvsig.gva.es/. [2] Open Geospatial Consorium: http://www.opengeospatial.org/. [3] Portal de INSPIRE: http://www.ec-gis.org/inspire/. [4] Licencia GNU/GPL: http://www.gnu.org/copyleft/gpl.html. [5] MapServer: http://mapserver.gis.umn.edu/. [6] GeoServer: http://docs.codehaus.org/display/GEOS/Home. [7] Deegree: http://deegree.sourceforge.net/. [8] GeoNetwork: http://www.fao.org/geonetwork/srv/es/main.home. [9] Web Map Service: http://www.opengeospatial.org/standards/wms. [10] Web Feature Service: http://www.opengeospatial.org/standards/wfs. [11] Web Coverage Service: http://www.opengeospatial.org/standards/wcs. [12] Catalogue Service: http://www.opengeospatial.org/standards/cat. [13] Open Geospatial Consortium Inc., “OpenGIS Geography Markup Language

(GML) encoding specification”, 2004.


GeoBovino: un ejemplo de geo-trazabilidad

M. A. Manso Callejo†, M. Núñez Jiménez†

† Laboratorio de Tecnológicas de la Información Geográfica (LatinGEO) Universidad Politécnica de Madrid

Autovía de Valencia Km 7, 28031, Madrid (España) e-mail: [email protected]

Resumen

GeoBovino nace como una iniciativa que pretende ofrecer un servicio sencillo

para consultar los datos referentes a la trazabilidad del ganado bovino. Por trazabilidad se entiende [1]:

“aquellos procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a través de unas herramientas determinadas”.

La información sobre la trazabilidad animal está legislada, y existen normativas para el correcto etiquetado y seguimiento del animal, pero el problema es hacerle llegar esa información tanto a consumidores como a profesionales.

La finalidad de GeoBovino es paliar ese problema, permitiendo recuperar la in-formación sobre el animal o piezas del mismo. Para ello el proyecto se basa en todo ese trabajo previo para conseguir los datos de la trazabilidad del animal.

GeoBovino ha sido concebido como un servicio web que, a través de Internet, permite la recuperación de la información almacenada por los distintos organismos y entidades que se ocupan de la trazabilidad del ganado bovino. El servicio permite recuperar toda la información disponible a partir del crotal del animal (identifica-dor), el cual se halla presente en las etiquetas de canal y corte según el estándar de etiquetado UCC-EAN-128 [2].

Palabras clave: GeoBovino, trazabilidad, servicio web.

1. Introducción La trazabilidad de la carne de vacuno en España está garantizada por distintas

directivas de rango comunitario ((CE) num.1760/2000, (CE) num. 1825/2000) y otras disposiciones adicionales a nivel nacional (Real Decreto 1698/2003 de 12 de


diciembre). Estas normativas definen cómo deben identificarse las reses y cómo debe ser etiquetada toda la carne o los productos derivados de la misma. Aunque esta legislación posibilita identificar el animal al que pertenece el producto cárnico, no se definen normas para documentar la vida del animal antes de su sacrificio.

GeoBovino se ha definido como un prototipo de servicio de información en la web que proporciona información alfanumérica, gráfica, descriptiva y enlaces en relación con la trazabilidad cárnica, sanitaria y geográfica de un producto cárnico derivado del vacuno. En el prototipo de servicio GeoBovino se han modelado las diferentes fuentes de información que gestionan los distintos actores (administra-ción, ganaderos e industrias cárnicas), en relación a un producto cárnico de vacuno. Posteriormente, cada una de las fuentes de información es gestionada por un servi-cio web específico. Estos servicios tienen la finalidad de flexibilizar el modelo arquitectónico del prototipo hacia un sistema distribuido en la web. Como conse-cuencia, se proporciona una mayor independencia en la gestión y explotación de la información. El prototipo, desarrollado en Java, se encarga de coordinar las consul-tas y procesar los resultados, para mostrarlos en un simple visor de páginas web, de acuerdo con unos estilos de visualización definidos.

La componente geográfica de la trazabilidad se gestiona mediante pares de co-ordenadas geográficas asociadas a una fecha ya sea la de nacimiento, movimiento o sacrificio del animal. El servicio web, que proporciona dicha información, codifica las coordenadas y el atributo fecha en un archivo codificado en GML. Esta traza representa los movimientos registrados del animal a lo largo de su vida. La visuali-zación de dicha traza se realiza de forma conjunta con otras fuentes de informa-ción, en forma de cliente ligero de servicios de mapas (WMS). De este modo los usuarios pueden navegar y acercarse en la medida de lo posible a la ubicación de la explotación ganadera por la que paso la res [3, 4]. El prototipo diseñado tiene por objeto ser una maqueta funcional y operativa que demuestre cómo se podría pro-porcionar a los consumidores, de una forma amigable, más información sobre todos los productos cárnicos de vacuno que consumen.

El resto del documento se estructura de la siguiente forma: en primer lugar, se hace una aproximación del problema que se pretende resolver, después se describe la estructura que se le ha dado al prototipo, para pasar seguidamente a describir su funcionamiento. Por último, se valoran los resultados obtenidos y se finaliza con las conclusiones y los agradecimientos.

2. Aproximación al problema Toda la información sobre trazabilidad animal, necesaria para poder ofrecer este

servicio, se halla en manos del ministerio de Agricultura Pesca y Alimentación (MAPA) o en el de las Comunidades Autónomas (CCAA), de los ganaderos, de las asociaciones de ganaderos, de los centros de sacrificio y despiece, así como de los establecimientos de venta.


El principal problema desde el punto de vista del consumidor reside en que el etiquetado, que transporta la información necesaria, se ajusta a un estándar hasta que llega a los establecimientos de venta y una vez allí cada comercio gestiona internamente la relación de cada producto que pone a la venta con el canal o pieza suministrada y la mayor parte de la información presente en el etiquetado no es accesible para el consumidor. Por esta razón no es viable aplicar la recuperación de información desde los datos presentes en las etiquetas finales de venta al público (bandeja con un producto cárnico). Por este motivo, el proyecto GeoBovino sólo contempla el seguimiento del animal desde su registro al nacer, hasta su sacrificio y despiece.

Dado que existe una serie de entidades encargadas de gestionar la información de los animales, el primer paso fue comprender el cometido de cada uno de estos actores:

• El MAPA o las CCAA mantienen la información de los traslados del animal

(SIMOGAN) y el registro de explotaciones ganaderas (REGA). • Los centros cárnicos llevan la información del sacrificio y despiece de los

animales. • Por último la asociación de ganaderos y los propios ganaderos llevan toda

la información de los acontecimientos que le suceden al animal en el día a día. Se decidió unir ambos actores al apreciar que la información que ges-tiona la asociación de ganadera y los ganaderos son muy dependientes en-tre sí.

Los siguientes pasos tras definir dichos actores fueron definir los modelos de

datos de cada una de las entidades y crear un servicio web autónomo que permitie-ra la recuperación de la información para cada una de las entidades de manera in-dependiente.

2.1. Base de datos Se ha utilizado como sistema gestor de bases de datos (SGBD) PostGresSQL

version 8.14, y se han creado 3 bases de datos distintas, simulando cada una de ellas a uno de los diferentes organismos o entidades anteriormente citados. En cada uno de ellos se almacena información de la vida del animal. Estas tres bases de datos podrán estar en lugares físicos y/o lógicos distintos, pero la información de cada una de ellas está relacionada con las demás por el crotal del animal [5]:

1. Movimientos y explotaciones ganaderas. En ella se registran las coordena-

das geográficas de las explotaciones ganaderas, y se asocia a un desplaza-miento o traslado en base a esas coordenadas y el crotal del animal.


2. Asociación de ganadería y ganadero. Aquí se registra toda la información

del animal, desde las características propias, pasando por tratamientos y controles sanitarios realizados, hasta su alimentación.

3. Centro cárnico de sacrificio y despiece. En ella se almacena la información relativa al sacrificio y al despiece del animal, reflejando además que pieza proviene de que animal.

2.2. Servicios web

“Un servicio web, es un recurso software que se ejecuta en un servidor web remoto, en respuesta a la solicitud hecha por un cliente. Los servicios web son equivalentes a cualquier aplicación que corre en un equipo local, sólo que la información necesaria para llevar a cabo una tarea específica es en-viada al servidor y el resultado de esa tarea, devuelto al usuario” [6].

Los servicios web se han implementado usando Java, el JDK versión 5.0 y el servidor de aplicaciones Apache Tomcat versión 5.5 [7, 8].

En base a la idea de dar independencia a cada uno de los actores participantes en la trazabilidad, se diseño un servicio web por cada actor y después uno adicional que pretende dar un servicio global basándose en la información de los tres, y ade-más permite un acceso más sencillo a estos servicios web en los que se apoya.

Ministerio Centro cárnico

Alimentación Control Sanitario

Tratamiento Sanitario

Explotación ganadera

Ternero Lote

Centro cárnico Canal

Pieza Explotación ganadera

Movimiento

Asociación-Ganadero

Figura 1. Esquema de la base de datos.


2.2.1. Servicios web basados en SOAP

“SOAP (Simple Object Access Protocol) es un protocolo estándar creado por el W3C que define cómo dos objetos en diferentes procesos pueden comu-nicarse por medio de intercambio de datos XML.” [9, 10].

Se han creado tres servicios web, cada uno de ellos se encarga del acceso y re-cuperación de la información de su correspondiente base de datos. De esta manera cada servicio web representa a cada una de las entidades y ofrece un servicio de acceso a la información contenida en la base de datos de su entidad.

Cada uno de los servicios permite hacer peticiones (basadas en SOAP) desde cualquier programa que implemente este sistema, pudiendo invocar los métodos expuestos por el servicio para obtener la información correspondiente de la entidad.

2.2.2. Servicio web global Este servicio no es propiamente un servicio web sino una aplicación que se eje-

cuta en servidor y permite el uso de los servicios web anteriormente descritos. Está implementado de tal forma que simula un servicio web, haciendo el papel de puerta de entrada a los 3 servicios web basados en SOAP.

Este servicio acepta peticiones por URL y mediante XML usando los métodos POST y GET. Estas peticiones deben ser realizadas según unas reglas específicas de construcción, pero se puede consultar la forma de usarlo mediante la petición get-Capabilities del servicio. El resultado de esta petición es la información que des-cribe el acceso al servicio codificada en XML.

Entre las peticiones que es capaz de procesar, las dos mas importantes son los métodos de acceso global a la información de los servicios web descritos, ya que cada una de esas peticiones resulta a su vez en otras tres peticiones sobre los servi-cios web SOAP, y el posterior procesamiento de la información de respuesta para generar la respuesta global.

2.3. Aplicación web de consulta Se ha implementado una aplicación web que tras visitar la página introductoria

del servicio, nos permite elegir entre 2 opciones de consulta.

2.3.1. Servicio básico Esta página web en HTML presenta un pequeño formulario que permite realizar

peticiones al servicio global, pudiendo invocar los 2 métodos distintos que presen-ta, el de acceso a la información de canal o el de acceso a la información de pieza


del animal [11]; para ello solo hay que introducir el crotal del animal y el número de pieza de modo que se recupera la información del animal en formato de página web.

2.3.2. Servicio avanzado Esta segunda página web utilizando programada en javascript, y que muestra un

formulario más complejo, que permite atacar al servicio global o a los servicios web, incluso permite invocar métodos más concretos [12]. Además de introducir el crotal y la pieza, se debe de indicar el formato de salida ya que se permite solicitar la información en formato XML o en forma de página web. Este servicio también permitirá ver un ejemplo de construcción de petición URL o XML construida a partir de los datos seleccionados en el formulario. De esta forma se dota al sistema final de una interfaz sencilla para aprender a explotar el servicio.

3. Proceso de consulta

3.1. Servicios web basados en SOAP Los servicios web basados en SOAP permiten realizar solicitudes externas a los

mismos utilizando la metodología que impone SOAP. Esta implementación de los servicios los deja abiertos para su uso desde otras aplicaciones que implementen este sistema de mensajería, de modo que se pueda acceder a los métodos públicos de cada uno de los servicios web. Esto se realiza importando las librerías adecuadas de Axis (herramienta de trabajo basada en SOAP y WSDL) que pone a disposición de los programadores una serie de métodos para realizar los accesos a los servicios web. Por otro lado [13]:

“WSDL describe la interfaz pública a los servicios web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo”.

3.2. Servicio web global Si lo que se desea es el acceso al servicio global, o simplemente acceder a los

servicios independientes pero de una manera más sencilla, entonces se puede acce-der utilizando un navegador:


• Utilizando la página web de consulta con dos opciones (básica/avanzada). • Enviando parejas de parámetros/valores (GET o POST) como URL,

http://localhost:8080/GEOBOVINO/servlet/Principal?service=SWMinisterio&request=getMovimientos&version=1.0&crotal=501&output=xml.

• Enviando un texto en XML (GET o POST) como URL en el navegador, donde los pares parámetro/valor están embebidos en un documento XML:

<?xml version="1.0" encoding="UTF-8"?> <trazability xmlns:xsi="…" xsi:noNamespaceSchemaLocation ="…">

<service version="1.0">SWMinisterio</service> <request>getMovimientos </request> <parameters crotal="501" /> <output>xml</output>

</trazability El acceso a los servicios implementados exige utilizar una serie de parámetros

para su funcionamiento:

• Service: se trata del nombre del servicio que se desea utilizar: SWGeoBo-

vino (servicio global), SWMinisterio (lleva la parte de movimientos del animal), SWCarnico (informa sobre despiece y sacrificio del animal), SWAsogan (informa sobre datos del ternero, alimentación y sanidad). El atributo version indica la version del servicio.

• Request: es el nombre del método que se invoca: o SWGeobovino: getCapabilities indica las capacidades del servicio,

getCanal recupera todos los datos de un animal. La resolución de esta petición se realiza llamando a los tres servicios web, y lla-mando a sus métodos globales (getMovimientos, getCarnico y ge-tAsogan), getPieza recupera todos los datos de una pieza. La reso-lución de esta petición se realiza llamando a los tres servicios web, y llamando a sus métodos globales (getMovimientos, getCarnico y getAsogan).

o SWMinisterio: getCapabilities indica las capacidades del servicio, getMovimientos recupera todos los traslados que ha hecho el ani-mal, y las coordenadas geográficas de las explotaciones ganaderas de origen y destino.

o SWCarnico: getCapabilities indica las capacidades del servicio, getCarnico recupera toda la información tanto de sacrificio como de despiece, getDespiece recupera la información relativa a la pie-za, getSacrificio recupera la información relativa al sacrificio.

o SWAsogan: getCapabilities indica las capacidades del servicio, getAsogan recupera toda la información del ternero, su alimenta-ción e información sanitaria, getTernero recupera los datos básicos del animal, getCebo recupera la información relativa al cebo o ali-


mentación del animal, getSanidad recupera la información relativa a tratamientos y controles sanitarios del animal.

• Parameters: Son los parámetros propios de la consulta. El crotal siempre

es obligatorio, y la pieza en cambio es opcional, debiendo aparecer sola-mente si se está invocando un método que nos devuelva información sobre ella.

• Output: Con este parámetro, se indica el formato en que queremos recibir la respuesta de la consulta: HTML, desde la aplicación web, por defecto se devuelve este formato o XML, al acceder al servicio por peticiones URL este será el formato por defecto.

3.3. Funcionamiento del servicio

Una vez realizada la petición, el servicio web lo procesa. La primera tarea que

se realiza es la transformación de la petición a XML si es necesario. El siguiente paso es la validación de la petición mediante un XML-Schema, de manera que se valida la estructura las peticiones. Si algo fallase se devolvería un mensaje de error como respuesta.

1) Petición a partir de formularios HTML. 2) Petición por URL 3) Petición mediante XML

Servicio Web Ministerio

Servicio Web Asociación ganadera

Servicio Web Centro cárnico

Aplicación Web (Servicio global)

Acceso externo a los servicios Web mediante mensajería SOAP para resolver peticiones parciales

Respuesta en XML

Acceso interno mediante mensajería SOAP para resolver las peticiones

BD BD BD

Transformación XSLT

Aplicar plantilla XSL al documento XML

Respuesta en HTML

Figura 2. Esquema del prototipo.


Si la solicitud es correcta el servicio web global atenderá a la petición. Si se tra-ta de una petición a alguno de los servicios web SOAP, el servicio global redirige la petición mediante los métodos de mensajería SOAP; si fuera una llamada a algún método del servicio global, éste realizaría peticiones a los tres servicios web SOAP y recogería todas las respuestas para crear una respuesta compuesta por las tres respuestas de los servicios web SOAP. Creada la respuesta en XML y dependiendo del formato de salida seleccionado, el resultado se muestra directamente el XML o se toma el XML y se le aplica una plantilla XSL para que mediante un proceso XSLT se transforme ese fichero XML en una pagina web de respuesta al usuario [15].

3.4. Interfaz del servicio web global Como se indicó anteriormente no es estrictamente un servicio web, y aunque

implementa métodos públicos que orquestan las llamadas a otros servicios, es ca-paz de procesar peticiones dirigidas expresamente a él. Este servicio a diferencia de los otros tres, permite peticiones por paso de parámetro-valor a través de URL, e incluso mediante XML usando los métodos POST y GET. Estas peticiones deben ser realizadas según unas reglas de construcción, pero se puede consultar la forma de usarlo mediante la petición getCapabilities del servicio. Este servicio pone a dispo-sición del usuario dos métodos de acceso global a la información de los servicios web descritos, ya que procesa dos tipos de peticiones que resultan en tres peticio-nes sobre los servicios web SOAP, y un posterior procesamiento de la información recogida para su presentación al usuario.

• getCanal: Este método se apoya en los otros tres servicios web, y devuelve

el conjunto de las peticiones de los tres. Invoca los métodos de cada servi-cio web que devuelven toda la información de cada servicio. No se incluye información en el apartado de despiece, debido a que se está solicitando in-formación a nivel de canal, ni tampoco un nombre de pieza a recuperar.

• getPieza: Este método también se apoya en los otros tres servicios web, y devuelve el conjunto de las peticiones de los tres. Además incluye infor-mación en el apartado de despiece debido a que se está solicitando infor-mación a nivel de pieza, por lo cual se le proporciona un nombre de pieza para recuperar.

• getCapabilities: La petición getCapabilities, se responderá con un texto en formato XML que especifica las capacidades del servicio, es decir, los mé-todos que se pueden invocar.


4. Resultados Hasta la fecha el prototipo presenta las siguientes características. Se ha diseñado

una base de datos que no sólo atiende a las exigencias del problema, sino que se ha realizado de la manera más genérica posible en perspectiva a futuros cambios o ampliaciones. El código fuente se ha estructurado notablemente para favorecer de igual manera, las posibles ampliaciones o modificaciones que puedan tener lugar en un futuro. Se han desplegado los 3 servicios web basados en mensajería SOAP de manera satisfactoria dotando al sistema de independencia y autonomía. La estructu-ra con la que se ha dotado al proyecto permite la explotación independiente de los servicios web basados en SOAP, pero al mismo tiempo son la base para el funcio-namiento del servicio web global. Se ha puesto a disposición de los usuarios un sistema de consulta muy sencillo a través de una página web, de manera que sin comprender el funcionamiento sea fácil de usar ya que solo deben suministrarse los datos del animal y pieza del mismo. Se realiza la validación de las peticiones. Se ha conseguido devolver a los usuarios de los servicios web los errores que ocurren: peticiones, validaciones, servicios y acceso a bases de datos. Se ha dotado al proto-tipo de ficheros de configuración que permitan independencia en su implantación. El hecho de resolver las peticiones con respuestas escritas en lenguaje XML las hace especialmente compatibles por cualquier sistema, ya que es un estándar de libre distribución. Además para mayor facilidad del usuario se ha implementado una plantilla utilizando el lenguaje XSL que permite la transformación de las respuestas, pasando de XML a una página web lo que hace que el contenido y presentación de las consultas al servicio global sean mas claras y completas.

5. Conclusiones En la fase de análisis se ha detectado dificultades a la hora de integrar la infor-

mación de los distintos centros cárnicos y asociaciones ganaderas, ya que cada asociación ganadera se realiza de manera independiente, gestionando su propia información, y por tanto se decidió enfocar el proyecto desde el punto de vista de la asociación ganadera. Por ello se decidió que existiera un servicio web de consul-ta por cada asociación ganadera, que contuviera cada una de ellas la información sobre los ganaderos asociados, los centros cárnicos a los que se acude desde dicha asociación y además la información que almacenan las administraciones (Ministe-rio y CCAA).

El grado de desarrollo del prototipo está al 80% y aunque está funcionando, aún tiene que someterse a un riguroso proceso de pruebas de funcionamiento, y además se le pretenden añadir las siguientes mejoras: la más destacable es la inclusión de un cliente WMS, incluir la metodología de Struts para dar más consistencia y segu-ridad al espacio web de la aplicación [16], añadir un esquema de despiece donde se resalte la pieza sobre la que se ha consultado, valorar la posibilidad de introducir


un repositorio de fotografías de los animales y añadir estilos, para mejorar el aspec-to del espacio web de consulta mediante hojas de estilo CSS [17].

GeoBovino pretende además de poner a disposición de los consumidores y pro-fesionales un espacio web donde realizar sencillas consultas de la información del animal y más importante aún, ofrecer el soporte necesario para futuras aplicaciones que requieran de dicha información ofreciéndola en forma de servicios web.

Referencias

[1] Concepto de Trazabilidad: http://www.aecoc.es/web/codificacion.nsf/0/ 925B46B62071AAB5C1256F2E00506B2E?OpenDocument.

[2] Etiquetado de ganado: http://www.belt.es/articulos/fichas_prof/ seg_inform/copia_seg_CD.htm.

[3] Geography Markup Language (GML): es.wikipedia.org/wiki/GML. [4] Web Map Service (WMS): es.wikipedia.org/wiki/WMS. [5] Sistema gestor de Bases de datos Postgre: www.postgresql.org. [6] Servicio Web: fbio.uh.cu/bioinfo/glosario.html. [7] Lenguaje Java: www.java.sun.com. [8] Servidor de aplicaciones Tomcat: www.tomcat.apache.org. [9] Mensajeria SOAP: es.wikipedia.org/wiki/SOAP. [10] eXtensible Markup Language (XML): es.wikipedia.org/wiki/XML. [11] Javascript: www.w3schools.com/js. [12] Hyper Text Markup Language (HTML): http://www.w3schools.com/html. [13] Descripción de Web Service WSDL: es.wikipedia.org/wiki/WSDL. [14] Tutoriales sobre XML-Schemas: www.w3schools.com/schema. [15] Extensible Stylesheet Language (XSL): www.w3.org/Style/XSL. [16] Paquete de seguridad para espacios Web, Struts: www.struts.apache.org. [17] Cascading Style Sheets, (CSS): http://es.wikipedia.org/wiki/Css.


PostGIS en producción cartográfica: CartoCiudad

M. M. Gamo†, M. A. Manso Callejo†

† Laboratorio de Tecnologías de la Información Geográfica (LatinGEO) Universidad Politécnica de Madrid

Autovía de Valencia Km 7, 28031, Madrid e-mail: [email protected], [email protected]

Resumen CartoCiudad consiste en la obtención de la base de datos oficial de red viaria

con estructura topológica de SIG de ciudades y núcleos de población españoles basada en cartografía digital oficial con viales e información textual. Este proyecto se construirá en base a asistencias técnicas y consultorías para su creación y mante-nimiento a partir de los datos suministrados por las siguientes fuentes oficiales: Instituto Geográfico Nacional (IGN), Dirección General del Catastro (DGC), Institu-to Nacional de Estadística (INE), Correos y en determinados casos, cartografía digi-tal que puedan aportar las empresas licitadoras. Una vez analizadas las fuentes de datos y el pliego de prescripciones técnicas (PPT), se han ido analizando y elabo-rando un conjunto de procedimientos que dan respuesta a la metodología de pro-ducción de CartoCiudad basándose en el sistema de gestión de bases de datos (SGBD) PostgreSQL y la extensión espacial PostGIS y como herramientas gráficas de visualización se utiliza gvSIG y deeJUMP, todas ellas bajo licencias open sour-ce.

Entre las finalidades de CartoCiudad están la localización (directa e inversa) e identificación de puntos de interés, el cálculo de itinerarios peatonales, la georrefe-renciación de puntos de interés, la localización de direcciones postales y la geoco-dificación.

Palabras clave: cartografía navegable, CartoCiudad, SIG, open source, PostGIS.

1. Introducción CartoCiudad es un proyecto que consiste en generar cartografía digital oficial de

ciudades y núcleos de población españoles con viales e información textual. Cons-tituye una base de datos oficial de red viaria, con estructura topológica de SIG, que asegura la continuidad geográfica en todo el territorio nacional, partiendo para su


generación de las fuentes de datos oficiales de información geográfica que se des-criben en el siguiente epígrafe.

La relevancia de este proyecto radica en la navegación asistida, la localización directa e inversa de direcciones postales, la georreferenciación de emplazamientos de puntos de interés y todas las aplicaciones prácticas que se le puedan encontrar desde un entorno de Investigación, Desarrollo e Innovación (I+D+I) y de una In-fraestructura de Datos Espaciales (IDE).

El resto del capítulo se estructura de la siguiente forma: en primer lugar se pre-senta el problema, las fuentes de datos y la metodología propuesta para dar solu-ción a los requisitos planteados en el PPT, se exponen de forma descriptiva los algo-ritmos que se han desarrollado sobre PostGIS y se finaliza con las conclusiones, agradecimientos y las referencias bibliográficas.

2. Fuentes de datos de partida Para la ejecución de este proyecto se parte de las siguientes fuentes oficiales de

información cartográfica:

• Base cartográfica numérica a escala 1:25.000 (BCN25) utilizada como car-

tografía de referencia, en especial las categorías correspondientes a redes hidrográficas, redes de transportes y entidades de población.

• Cartografía catastral urbana de la Dirección General del Catastro (DGC) a escala 1:1.000

• Información sobre nombres de calles y direcciones postales obtenida del Censo Electoral, así como información sobre distritos y secciones censales del Instituto Nacional de Estadística (INE) a escala 1:1.000.

• Información actualizada sobre los distritos postales que realiza y mantiene la Sociedad Estatal de Correos y Telégrafos (Correos).

• La cartografía digital, que en determinados casos puedan aportar las em-presas licitadoras.

3. Metodología

En este apartado se describen las distintas fases que materializan el desarrollo

del proyecto CartoCiudad.


3.1. Estado de la cuestión En primer lugar se realizó un estudio detallado de las diferentes fuentes carto-

gráficas de datos de partida, IGN, DGC, INE y Correos mediante la descripción adi-cional de las mismas a través de los correspondientes metadatos.

3.2. Propuesta metodológica A fin de generar las capas de información de acuerdo con los modelos de datos

especificados en el pliego de prescripciones técnicas (PPT) de CartoCiudad, se de-sarrolla una metodología fundamentada en productos con licencia open source tal como el Sistema Gestor de Base de Datos (SGBD), PostgreSQL y la extensión espa-cial PostGIS. De esta manera pueden distinguirse las siguientes fases de trabajo que se describen a continuación.

3.2.1. Carga de los archivos shapefile a PostgreSQL

Se ha utilizado la herramienta shp2pg que permite transformar un archivo sha-

pefile en un archivo de texto con las sentencias SQL que crean la tabla, cargan los elementos y actualizan el directorio de tablas con geometrías (geometry_columns).

3.2.2. Concordancia geométrica de las fuentes de datos cartográficas

Esta sección comprende los siguientes tres pasos: • Case geométrico: La primera fase a realizar consiste en comparar y asegu-

rar la adaptación geométrica de las distintas fuentes de datos con respecto a la base cartográfica numérica a escala 1:25.000 (BCN25) adoptada esta úl-tima como referencia a través de un análisis visual.

• Transformaciones geométricas: Una vez efectuada la constatación anterior se realizarán las transformaciones geométricas, en caso se ser necesarias, para ajustar las distintas fuentes de datos respecto a la BCN25. Ante posi-bles irregularidades geométricas relativas a las distintas fuentes se realizará un nuevo contraste con otras fuentes oficiales tales como ortofotos digita-les del Plan Nacional de Ortofotografía Aérea (PNOA).

• Transformación de coordenadas origen: El tercer paso consiste en la trans-formación de coordenadas origen UTM (European Datum de 1950) a coor-denadas geográficas (Datum, ETRS89).


3.2.3. Procesamiento de las capas iniciales de información cartográfica

El tratamiento de las distintas fuentes de datos de partida se realizará con la pla-

taforma open source de administración y desarrollo pgAdminIII adoptando ésta como servidor de base de datos objeto-relacional PostgreSQL con el módulo de extensión de funcionalidad PostGIS. Este procedimiento se efectuará mediante distintas funciones desarrolladas en lenguaje de programación plpgSQL (Procedu-ral Language PostgreSQL).

Capa ELEMTEX. La capa ELEMTEX de Catastro contiene información geométrica

de tipo lineal asociada a los diferentes rótulos de la toponimia urbana (número de portales, nombres de calle, etc.). El procesamiento de la capa ELEMTEX para la extracción de los números de los portales consiste en la ejecución de dos pasos:

• Seleccionar los rótulos correspondientes a los números de los portales que

responden a la codificación del atributo TTGGSS (tipo, grupo, subgrupo) ‘189401’.

• Calcular el punto medio de la geometría lineal asociada a dichos rótulos representando así la posición del número del portal.

Figura 1. Resultado de la extracción de los números de policía

El pseudocódigo del algoritmo que permite realizar estos dos pasos es el que se

muestra a continuación:

PARA CADA geometría DE elemtex ORDENADO ASCENDENTEMENTE POR rotulo HACER SI (geometría.ttggss = 189401) ENTONCES

INSERTAR EN TABLA portales LOS VALORES (geometría.gid, geome-tría.rotulo, calcular_centroide(geometría.the_geom))

FIN SI FIN PARA

El procedimiento para la extracción de la toponimia urbana simbolizando así

posibles puntos de interés (POI) de la capa ELEMTEX es análogo al visto para los números de los portales, que se puede resumir en dos pasos:

• Selección de aquellos rótulos que representen la toponimia urbana (cole-

gios, bibliotecas, hospitales etc.) correspondiendo éstos al atributo TTGGSS de valor ‘189300’.


• Calcular el punto medio de la entidad lineal asociada a estos rótulos mate-rializando así la posición de la toponimia referente a los POI.

El pseudocódigo que realiza esta operación es:

PARA CADA geometría DE elemtex ORDENADO ASCENDENTEMENTE POR rotulo HACER

SI (geometría.ttggss = 189300) ENTONCES INSERTAR EN TABLA toponimia LOS VALORES (geometría.gid, geome-tría.rotulo, calcular_centroide(geometría.the_geom))

FIN SI FIN PARA

La capa ELEMTEX también contiene información relativa a la red de carreteras o

que cruzan los núcleos de población. A diferencia de los dos casos anteriores, nú-meros de portales y puntos de interés, el tratamiento de la capa ELEMTEX es distinto y está compuesto por las siguientes dos fases:

• Seleccionar los rótulos de atributo TTGGSS con valor ‘189802’ que corres-

ponden a la toponimia de la red de carreteras, así como aquellos rótulos que definen los puntos kilométricos, eliminando los espacios en blanco existentes entre palabras, uniendo textos que pertenecen a un mismo rótulo y reclasificando los rótulos por el tipo de vía.

• Calcular el punto medio de la entidad lineal asociada a los anteriores rótu-los simbolizando así la posición de la toponimia de la red de carreteras.

La función plpgSQL desarrollada para este fin es similar a las anteriores pero

con aplicación según las características de la red de carreteras y una vez realizada la reclasificación anteriormente indicada.

PARA CADA geometría DE elemtex ORDENADO ASCENDENTEMENTE POR rotulo HACER SI (geometría.ttggss = 189802) ENTONCES

INSERTAR EN TABLA toponimia LOS VALORES (geometría.gid, geome-tría.rotulo, calcular_centroide(geometría.the_geom))

FIN SI FIN PARA

En estos tres casos (número de portales, puntos de interés POI y red de carrete-

ras) pueden presentarse ciertas particularidades que deben detectarse y solucionarse de acuerdo al modelo de datos de CartoCiudad.

Capa EJES. El tratamiento de la capa EJES de la DGC y Tramo de Correos dará como resultado una capa que denominaremos TRAMERO, la cual contendrá los segmentos de los viales. Los pasos a seguir a este fin son los siguientes.

En primer lugar, tenemos que asegurar la continuidad de las geometrías lineales mediante el procesamiento de la capa EJES y Tramo. Esta fase se realizó a través de una iteración triple de una función plpgSQL generada a este fin.


Figura 2. Solución de los problemas de continuidad geométrica

En segundo lugar, cada una de las calles debe representarse mediante una sola polilínea con un inicio y un final sin presentar ramificaciones que generen horqui-llas.

Figura 3. Unión de los segmentos de viales en polilíneas únicas Se ha detectado que existen varios casos en los que esta operación no puede rea-

lizarse en su totalidad ya que aparecen excepciones en forma de horquillas, etc.

Figura 4. Detección de horquillas y geometrías singulares

Luego, se debe calcular cada uno de los puntos de intersección entre dos calles

distintas y entre los ramales de una misma vía. Los puntos resultantes quedarán almacenados en una nueva capa denominada cruces.

Figura 5. Cálculo de los puntos de intersección de las vías A continuación se dividen las calles por los puntos de intersección anteriormen-

te calculados. En base a los puntos de intersección de las vías con otras o consigo mismas, realizar el tramificado (corte de la geometría).


Figura 6. Tramificación de los viales

Los últimos dos pasos consisten en la normalización y la designación del código

INE. En la normalización, se establece una correlación entre la denominación de la vía usada por la DGC y la utilizada por el INE. Hay que realizar la correlación entre el archivo de texto con estructura de base de datos, proporcionado por INE, con la columna “nombre” de la DGC, utilizando el operador like de SQL, ya que los nom-bres de INE están normalizados y son los de referencia. Finalmente, es necesario designar el código INE de población a los ejes, tramos y cruces del proceso descri-to. Este proceso es trivial ya que lo único que hay que hacer es conocer el código INE del municipio y establecer el valor del atributo correspondiente de las distintas tablas con ese valor.

Capa de las vías de comunicaciones de la BCN25. Las vías de comunicación de la BCN25 del IGN sirven como base de referencia para los tramos de las carreteras. De acuerdo con esto, el procesamiento de la primera de las capas enunciadas con-sistirá en la ejecución de tareas análogas a la capa anterior definidas previamente. Así pueden distinguirse: continuidad, polilíneas únicas, intersección, división. Su ejecución consistirá así mismo en la utilización de diferentes funciones para cada uno de estos trabajos.

Capas de fondo urbano y rústico de la DGC: MASA, PARCELA y CONSTRU. Existen tres capas que se utilizarán como cartografía de referencia para el fondo urbano, MASA, PARCELA y CONSTRU con el objetivo de representar los portales, la toponi-mia y los viales previamente divididos en tramos.

Capa de distritos y secciones censales del INE. El INE proporciona información de los distritos y secciones censales mediante la capa callejero (fuente de datos vectorial).

Capa de códigos postales de Correos. De forma análoga a los distritos y sec-ciones censales, Correos también suministra la capa de tramo (capa vectorial). El procesamiento de estas dos capas, INE (secciones y distritos censales) y Correos (Códigos Postales), consiste en buscar todos los tramos de las fuentes con dichos códigos (agrupar por código) y calcular el polígono que los encierra.

3.2.4. Obtención de las capas del proyecto CartoCiudad

La generación de cada una de las capas de este proyecto se hará de acuerdo al

modelo de datos definido en el “Pliego de prescripciones técnicas”.


3.2.5. Obtención de la documentación de las fuentes y los procesos: metadatos

El proyecto CartoCiudad debe contar con la documentación adecuada que acre-

dite el mantenimiento y actualización de la información contenida en él. Para la consecución de este fin se generarán los correspondientes metadatos, según el es-tándar internacional de metadatos ISO 19115 y en base al Núcleo Español de Meta-datos (NEM), del producto describiendo detalladamente sus características.

4. Discusión de resultados Se han implementado un conjunto de funciones que demuestran la potencia de

cálculo y análisis de las extensiones PostGIS. Se ha podido depurar los errores en los algoritmos desarrollados gracias a la ca-

pacidad de conexión y visualización de datos espaciales almacenados en post-greSQL desde herramientas SIG open source (deeJUMP, Qgis, gvSIG, uDIG).

Se han desarrollado funciones en plpgSQL que permiten detectar analíticamente en qué vías existen peculiaridades geométricas (horquillas, etc.).

Se han desarrollado funciones que permiten identificar los números de portales que pueden estar incorrectamente asignados.

Los resultados obtenidos de la aplicación de PostGIS en el proyecto CartoCiu-dad ponen de manifiesto su potencia, en el ámbito de la producción cartográfica, constituyendo por tanto una herramienta de gran utilidad.

El procedimiento empleado permite conocer y analizar las debilidades existen-tes, así como detectar posibles errores en la construcción de los algoritmos imple-mentados en forma de funciones plpgsql mediante su análisis visual.

Se ha constatado que en muchos casos la consecución de determinados objeti-vos algorítmicos requiere de la aplicación iterativa de procedimientos para obtener el fin deseado.

5. Conclusiones y desarrollos futuros La metodología propuesta en este proyecto apuesta por una filosofía de trabajo

open source. Esta filosofía requiere un esfuerzo adicional en formación ya que el usuario dispone de menor número de funciones y procedimientos en aplicaciones comerciales, si bien se tienen las contraprestaciones adicionales de no tener que pagar licencias de uso por el software y de que los desarrollos realizados puedan ser usados por el resto de usuarios si el equipo de desarrolladores consideran opor-tunos incluirlos en las siguientes versiones del producto.


Agradecimientos El proyecto CartoCiudad ha sido financiado parcialmente por el Instituto Geo-

gráfico Nacional (IGN) a través del convenio de colaboración Cartociudad firmado entre el propio IGN y la Universidad Politécnica de Madrid (UPM).

Referencias [1] Instituto Geográfico Nacional (IGN), “Pliego de prescripciones técnicas para

la contratación de asistencia técnica para la ejecución del proyecto CartoCiudad en la Comunidad Autónoma de Castilla La Mancha”, BOE nº exp. 06.103, 2006.

[2] M. A. Manso, Metodología del proceso de armonización e integración de datos para el proyecto CartoCiudad, Universidad Politécnica de Madrid, 2005.

[3] Documentación de PostGIS: http://postgis.refractions.net/docs/. [4] Modelo de Nomenclátor de España v1.0: http://www.idee.es/resources/reco-

mendacionesCSG/Propuesta_MNE_v1.0.pdf. [5] Documentación de EuroRoadS: www.euroroads.org. [6] Documentación de Web Gazetteer Services: https://portal.opengeospatial.org/

files/?artifact_id=7175.


Análisis de los servicios WMS disponibles: hacia un conjunto de recomendaciones

para su implementación

P. Abad Power†, A. Rodríguez Pascual†, J. A. Alonso Jiménez† A. Sánchez Maganto†, L. M. Blázquez Vilches†

† Subdirección General de Aplicaciones Geográficas.

Instituto Geográfico Nacional. Calle General Ibáñez de Íbero 3, 28003, Madrid.

e-mail: {pabad, afrodriguez, jaajimenez, asmaganto, lmvilches}@fomento.es

Resumen La Comisión de Geomática del Consejo Superior Geográfico, el órgano supe-

rior, consultivo y de planificación del Estado en el ámbito de la cartografía, definió en noviembre de 2002 el grupo de trabajo para el establecimiento de la Infraestruc-tura de Datos Espaciales de España, que está formado por representantes de orga-nismos relacionados con la información cartográfica de los tres niveles de la Ad-ministración (nacional, regional y local) así como la empresa privada y las univer-sidades. Debido a la gran diversidad de información geográfica existe, dicho grupo de trabajo ha comenzado a definir recomendaciones a seguir, con la finalidad de lograr homogeneizar todos los datos y conseguir la interoperabilidad que desde Europa, la futura directiva INSPIRE, nos va a exigir.

Son cada vez más las organizaciones en España que están creando servicios de mapas (Web Map Service), y esta especificación establece unos determinados crite-rios “informáticos” que son necesarios seguir para crear un servicio de mapas in-teroperable. Pero desde un punto de vista “geográfico”, no se establecen unos crite-rios a seguir que garanticen una homogeneidad en el modo de visualizar la infor-mación, en cuanto a estilos, nombre de capas, sistemas de referencia soportados, etc.

Palabras clave: infraestructura de datos espaciales, servicios de mapas, web map service, sistemas geodésicos de referencia, INSPIRE, OGC.


1. Introducción En el marco de las Infraestructuras de Datos Espaciales (IDEs), tanto la informa-

ción geográfica, como los servicios, juegan un papel primordial ya que éstos defi-nen la funcionalidad que el sistema va a ofrecer a los usuarios, proporcionándoles la oportunidad de acceder a los datos. Uno de los pilares fundamentales de las In-fraestructuras de Datos Espaciales son los servicios de mapas (Web Map Service) [1, 2], por su papel central y por ser el servicio Open GeoSpatial Consortium (OGC) que empieza a proliferar más intensamente dentro del paradigma de las IDEs. Este estándar facilita el acceso a los datos, ofreciendo la posibilidad de poder visualizar mapas georreferenciados, ya sean ráster o vectoriales, e incluye como operaciones básicas: la descripción de las capacidades de un servicio concreto, la visualización de una parte del mapa y la consulta de los atributos de un fenómeno del mapa que el productor decida publicar.

El susceptible incremento de organizaciones cartográficas en España que están creando servicios de mapas (WMS) está evidenciando que, además de que el manejo de tales WMS no puede ser desempeñado por usuarios que carezcan de un sustan-cioso grado de experiencia en su utilización, existen problemas para garantizar el aprovechamiento de toda la información cartográfica y permitir su superposición sobre cartografía procedente de una fuente diferente.

Los datos que se visualizan en un Web Map Service proceden de diferentes or-ganizaciones y, en consecuencia, presentan las características definidas por éstas en el momento de su creación. Para que resulte viable manejar datos procedentes de fuentes tan diversas, es necesario que, tanto los datos como los servicios, cumplan una serie de requisitos y condicionantes básicos. En esta presentación se muestran los resultados y conclusiones de un análisis realizado con distintos servicios WMS integrados en la IDEE.

Muchas son las razones que han hecho que el Web Map Service sea el servicio más implantado en los geoportales de Infraestructuras de Datos Espaciales en Es-paña, en particular:

• Es una de las especificaciones OGC más estables dentro del conjunto defi-

nido por este consorcio. • Posibilita que las organizaciones e instituciones cartográficas proporcionen

al usuario la capacidad de visualizar su información geográfica a través de la red y de superponerla con información geográfica procedente de otras fuentes.

• No es necesario esperar a tener metadatos para poder visualizar y manejar los datos.

• Evita las limitaciones surgidas de la existencia de distintas política de datos y de difusión de información geográfica abriendo una posibilidad muy in-teresante al permitir la publicación de información sin permitir la descarga.


En este capítulo se realiza un estudio de cuáles son las características mínimas y

los requisitos aconsejables que un Web Map Service debe cumplir según criterios racionales de eficiencia desde el punto de vista cartográfico y de usuabilidad. Para ello, tras una enumeración de los WMS que han sido estudiados, se destacan aque-llos problemas que pueden dificultar la interoperabilidad de la información y su manejo por parte de los usuarios; se ha tomado como referencia, por una parte, la experiencia acumulada por el personal del Instituto Geográfico Nacional y, por otra, el estudio inicial del grupo de trabajo del CEN/TC 287 dedicado a Web Map Services [6] y a analizar qué es aconsejable, tanto para la implementación de estos servicios como para la adecuación de los datos que se muestran, con el objeto de garantizar la interoperabilidad total de la información geográfica.

2. Servicios WMS evaluados En esta sección se enumeran todos los WMS que han sido objeto del presente es-

tudio. Estos servicios han sido clasificados, atendiendo a su ámbito geográfico, en tres niveles diferentes: nivel nacional, nivel regional y nivel local (véase tablas 1, 2 y 3), añadiendo además otros WMS interesantes para el estudio que quedan fuera de las categorías anteriores (véase tabla 4).

Instituto Geográfico Nacional • Mapa Base: contiene las bases cartográficas numéricas a escala 1:25.000,

1:200.000, 1:1.000.000 y 1:2.000.000. http://www.idee.es/wms/IDEE-Base /IDEE-Base. • Redes Geodésicas: contiene información de los vértices geodésicos perte-

necientes a todas las redes geodésicas observadas por el IGN. http://www.idee.es/wms/IDEE-Referencia/IDEE-Referencia.

• Cuadrículas: contiene las cuadrículas. http://www.idee.es/wms/IDEE- Cua-dricula-Hojas/IDEE-Cuadricula-Hojas.

• CORINE: cobertura del suelo. http://www.idee.es/wms/IGN-Corine/IGN-Corine

Dirección General del Catastro • Catastro: http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx.

Instituto Nacional de Estadística • Lim. Administrativos: http://www.idee.es/wms/IDEE-Limite/IDEE-Limite.

Tabla 1. WMS a nivel nacional


Instituto de Cartografía de Andalucía (ICA). Junta de Andalucía: Conseje-

ría de Obras Públicas y Transportes • Cartografía vectorial: http://andaluciajunta.es/IDEAndalucia/IDEAwms/ wms?Servicename=MTA100. • Ortofotos 2004: http://andaluciajunta.es/IDEAndalucia/IDEAwms/ wms?Servicename=Ortofoto2004. • Mapa Topográfico 1:10.000 ráster: http://andaluciajunta.es/IDEAndalucia/ IDEAwms/wms?Servicename=MTA10R.

Castilla la Mancha • http://161.67.10.43/cgi-bin/sde/mapserv.exe?map=cedercam.map

Junta de Castilla y León. Consejería de Fomento. Dirección General de Vi-

vienda, Urbanismo y Ordenación del Territorio • Cartografía 1:10.000: http://www.sitcyl.jcyl.es:80/wmsconnector/ com.esri.wms.Esrimap/BasicaTerritorialE10?. • Cartografía a escalas regionales: http://161.67.10.43/cgi-bin/sde /mapserv.exe?map=cedercam.map. • Ortofotos 1:10.000 e información ráster: http://www.sitcyl.jcyl.es:80/ wmsconnector/com.esri.wms.Esrimap/ImagenesRaster?.

Institut Cartogràfic de Catalunya (ICC). Departament de Política Territo-

rial i Obres Públiques • Cartografía 1:5.000: http://galileo.icc.es/wms/servlet/icc_bt5m_v_r?. • Ortofoto 1:5000: http://galileo.icc.es/wms/servlet/icc_orto5m_r_r?. • Ortofoto 1:25.000: http://galileo.icc.es/wms/servlet/icc_orto25m_r_r?.

Xunta de Galicia • http://sitga.xunta.es/wmsgalicia/request.asp.

Gobierno de La Rioja • Cartografía topográfica y ortofoto: http://wms.larioja.org/request.asp. • WMS de diferentes municipios.

Comunidad Autónoma de la Región de Murcia: Consejería de Industria y

Medio Ambiente. Dirección General Ordenación del Territorio y Costas • Info. sobre el planeamiento urbanístico, patrimonio cultural y deslindes de

costas: http://massotti.carm.es/wmsconnector/com.esri.wms.Esrimap/wms?.


Gobierno de Navarra • Cartografía vectorial, ortofotos e información ráster: http://idena.navarra.es

/ogc/wms.aspx. País Vasco • http://www1.euskadi.net/servlet/com.esri.wms.Esrimap?ServiceName=GVa

sco Generalitat Valenciana, Instituto Cartográfico Valenciano • http://icvmapas.icar.upv.es/servicio_wms.

Tabla 2. WMS a nivel regional

IDEC • IDE-COSTES: http://www. geoportal-idec.net/idecostes. • IDE-Local: geoportal creado para la AOC (Administración Abierta de Cata-

luña) para acoger los servicios de la IDE de las Administraciones locales ca-talanas. http://www.geoportal-idec.net/idelocal.

IDEPamplona • Ayuntamiento del Pamplona, información territorial: http://ide.pamplona.es

/ogc/wms.aspx.

IDEZar • Información municipal: http://idezar.unizar.es/wms/IDEZar_base/IDEZar_

base. • Información urbana: http://idezar.unizar.es/wms/IDEZar_tematicoUrbano/

IDEZar_tematicoUrbano.

Tabla 3. WMS a nivel local

• Altas climático digital de la península ibérica: http://www.opengis.uab.es/ cgi-bin/iberia/Miramon5_0.cgi?. • Cartografía digital de seguimiento: http://mercurio.ebd.csic.es/cgi-bin/ seguimiento/MiraMon5_0.cgi?. • Universidad de Alicante: http://www.sigua.ua.es/cgi-bin/mapserv4.2.1.exe? map=d:/carto/sigua/map/ogc.map. • Serv. santuarios: http://mapas.topografia.upm.es/cgi-bin/santu/santuarios. • Atlas Virtual de las Aves Terrestres de España, Sociedad de Amigos del

Museo Nacional de Ciencias Naturales CSIC, con la colaboración de la Sociedad Española de Ornitología: http://161.111.161.171/cgi-bin/ AtlasA-ves.exe?

Tabla 4. Otros WMS


3. Problemática detectada en los WMS La proliferación de servicios de mapas y de las capas ofrecidas por los WMS

exige la determinación de una serie de pautas comunes que facilite la integración semántica de todos estos servicios; todo ello sin perjuicio de las necesidades in-herentes a cada uno de los organismos.

Uno de los aspectos que dificultan la integración de información procedente de diferentes servicios de mapas es la estructuración y denominación de las capas ofrecidas. Si a esta heterogeneidad de nombres y jerarquías de capas existentes se añade la distribución de estas capas en varios servidores, la integración de informa-ción por criterios temáticos, de escala, de sistemas de referencia, etc., la visualiza-ción de toda la información disponible en una IDE deja de poder efectuarse de for-ma cómoda y clara y se complica enormemente.

A continuación se enumeran las principales diferencias que se han observado al analizar los WMS que existen en España, clasificándolas por categorías.

3.1. Sistemas geodésicos de referencia (SGR) Los sistemas geodésicos de referencia constituyen uno de los aspectos más sen-

sibles para la compartición y visualización de información geográfica puesto que una manipulación incorrecta puede introducir desplazamientos de los datos repre-sentados. El uso adecuado de los mismos conlleva la evaluación de 3 puntos distin-tos:

• El sistema geodésico de referencia en que se encuentra almacenada la in-

formación. • Los SGR soportados por el servicio de mapas. • Los SGR soportados por la aplicación cliente.

Un sistema de referencia terrestre [5], en general, tiene como objeto proporcio-

nar una herramienta sobre la que es posible dotar de coordenadas a puntos de la superficie de la Tierra. En 1972, España adoptó oficialmente el sistema European Datum ED50, en función de los trabajos realizados para la definición del European Datum por la subcomisión RETRIG de AIG (Asociación Internacional de Geodesia).

La sucesora de RETRIG es la subcomisión de EUREF (European Reference Fra-me), continuadora de sus trabajos en un salto cualitativo de mucho más calado, ya que nace como consecuencia de la utilidad de las técnicas geodésicas espaciales, en particular el GPS, para el mantenimiento de los marcos geodésicos de referencia globales y continentales así como de dotar de un marco de referencia continental para Europa.

La intención del datum ED50 (European Datum 1950) fue dotar a toda Europa de una homogeneidad geodésica que los sistemas locales no poseían, que hoy en día es oficial en España. La unificación no ha sido conseguida de forma general


debido a diversas causas, entre ellas la heterogeneidad que presenta ED50 según zonas y la complicación de todo orden que tal medida lleva consigo. Por tanto, en algunos países, coexisten ED50 y los antiguos datums locales, además de los distin-tos sistemas de proyección.

El concepto moderno de SGR [5] conlleva la calificación de ED50, también, co-mo un sistema local; de ahí que, unido a las posibilidades de los avances tecnológi-cos, es esté en un proceso de transición hacia un sistema de referencia geodésico global a nivel mundial.

La transición de los diferentes sistemas geodésicos de referencia en Europa al ETRS89 (European Terrestrial Reference System 1989) forma parte del paquete de recomendaciones de EUREF y del grupo VIII de EuroGeographics para Europa para los próximos años [7], junto con las siguientes proyecciones cartográficas:

• Transversa Mercator para grandes escalas hasta 1:500.000. • Cónica conforme de Lambert para escalas menores de 1:500.000. • Azimutal equiárea para fines estadísticos.

ETRS89 está reconocido como datum más apropiado para Europa por la comu-nidad científica. Está definido con una precisión de 1cm y es consistente con ITRS.

Recomendado también en la futura directiva europea INSPIRE [3], que establece los criterios para la creación una Infraestructura de Datos Espaciales en el ámbito Europeo

Actualmente la mayor parte de la cartografía ofrecida por los WMS no está dis-ponible ni en el SGR ETRS89 ni en las anteriores proyecciones recomendadas. Tanto para escalas pequeñas como grandes, el SGR que predomina es el ED50 y la proyec-ción UTM, donde en algunos casos no se corresponde el huso de la proyección UTM con la zona geográfica de España.

Además de disponer de cartografía almacenada en un determinado SGR el WMS debe poder soportar el SGR WGS84, siguiendo por tanto las recomendaciones del CEN/TC 287.

3.2. Nombres y niveles jerárquicos de las capas No existe una normalización a la hora de asignar nombres a las capas. Cada or-

ganización los establece según sus propios criterios en función de su cartografía, por lo que nos encontramos con denominaciones muy diferentes para nombrar ca-pas con la misma información. Como consecuencia, en multitud de ocasiones, es necesario visualizar las capas para poder determinar el tipo de información que contienen.

Aunque los metadatos de cada capa contengan información de sus característi-cas, se debería establecer por lo menos una nomenclatura común para todas las capas que posean el mismo tipo de información geográfica asociada.


Otro problema a considerar es el multilingüismo, en España existen cuatro idiomas oficiales y, por tanto, cada nombre que se asigna a las capas de un servicio de mapas está condicionado al idioma de su Comunidad Autónoma. Este aspecto no debe ser obviado por parte de las comunidades bilingües a la hora de definir sus servicios de mapas.

Debido a la heterogeneidad de la información de cada WMS, es necesario que la información se ofrezca de manera estructurada y agrupada. Pero de nada sirve la adopción de dichas medidas si el visualizador que se utiliza no tiene la capacidad de mostrar la información tal y como se define, presentándola siempre como una lista plana.

3.3. Estilos de las capas Debido a que cada cartografía tiene asociada unos criterios de simbología pro-

pios, que son definidos a nivel autonómico, pueden observarse discrepancias al solapar información proveniente de distintas fuentes; éstos problemas se incremen-tan en los límites fronterizos entre CCAA.

3.4. Leyendas de las capas Muchos de los actuales WMS carecen de leyenda y ésta, dada la relevancia de la

información que aporta, debería ser un elemento que no puede obviarse a la hora de representar información cartográfica.

En función de cómo esté estructurada la información, es necesario tener en cuenta dos aspectos distintos:

• La leyenda debe representar y contener la misma información que el WMS. • Si la información cartográfica está estructurada en capas, sería aconsejable

que cada una de las capas vaya acompañada de una leyenda independiente, evitándose el uso de una leyenda general para todas las capas.

Otro de los inconvenientes existentes es la utilización de largas leyendas que las

hacen inteligibles. Éste es el caso de los mapas geológicos, en los que la vasta in-formación necesaria para su interpretación imposibilita su reducción.

3.5. Metadatos de capas Los metadatos de capas presentan información sobre el tema de la capa, escala

de visualización, precisión de la información, extensión geográfica, actualización de la información, etc.


En un WMS no sólo se muestran productos completos e indivisibles (MDT, orto-

fotos, mapas ráster, etc.) sino que también se ofrecen partes de ellos. Esto conlleva la necesidad de realizar metadatos para todos los niveles jerarquizados de un con-junto de datos: producto, unidad, capas, etc. posibilitando la observación del pro-ducto desde diferentes vistas sectoriales y permitiendo al cliente adaptar la visuali-zación de la información a sus propios intereses.

4. Puntos a considerar Actualmente el Comité Técnico 287 del Centro Europeo de Normalización

(CEN/TC 287 “Información Geográfica”) está trabajando en la elaboración de un borrador para la implementación de un servicio de mapas teniendo en cuenta la norma ISO 19128 sobre WMS y que, entre otros puntos, presenta un conjunto de recomendaciones que facilitan la interacción entre distintos sistemas [6].

A continuación se enumeran algunos de los requisitos mínimos que han sido ex-traídos del borrador que está siendo desarrollado en el marco de la anterior iniciati-va:

• El WMS debe ser conforme a la implementación de ISO 19128 Geographic

Information – Web Map Server Interface. • El WMS debe soportar al menos el formato Portable Network Graphics

(PNG; tipo MIME “image/png”). • En los casos en los que un WMS no proporcione una cobertura completa pa-

ra las capas seleccionadas, deben soportarse imágenes transparentes. • El WMS debería soportar, cuando se excede el rango de escala útil, imáge-

nes vacías o simplificadas. La información sobre el rango de escala útil de-be proporcionarse en la respuesta a la petición GetCapabilities.

• La respuesta a la petición GetCapabilities debe contener: o Metadatos. o El campo <LegendURL>. o Un atributo schemaLocation que sea una instancia de un esquema

XML que enlace al espacio de nombres del WMS 1.3 al esquema del Anexo E.1 de la norma ISO 19128.

• Para la identificación del Sistema de Referencia de Coordenadas (Coordi-

nate Referente System, CRS), debe usarse el espacio de nombres del Euro-pean Petroleum Survey Group (EPSG), y para la Uniform Resource Identi-fier (URI) los códigos del EPSG. Deben emplearse los registros oficiales de ISO una vez que hayan sido establecidos.


• El WMS debe soportar el CRS WGS84 en coordenadas geográficas, identifi-cadas mediante EPSG:4326. Además, se recomienda que la implementación de WMS también soporte los siguientes CRS [4]:

o ETRS89 (coordenadas elipsoidales) (EPSG:4258); o ETRS89/ETRS-LAEA (EPSG:3035) para representación y análisis es-

tadístico pan-Europeo; o ETRS89/ETRS-LCC (EPSG:3034) para la cartografía pan-Europea a

escalas pequeñas o iguales a 1:500.000; o ETRS89/ETRS-TM26 a ETRS89/ ETRS-TM39 (EPSG:3038 a

EPSG:3051) para la cartografía pan-Europea a escalas mayores a 1:500.000.

• Si se usa un sistema de referencia de coordenadas (CRS) adicional, deben

identificarse sus parámetros de transformación mediante un identificador del sistema de referencia de coordenadas válido y documentado.

• Si el WMS que se implementa es consultable, la operación que debe sopor-tar GetFeatureInfo es al menos INFO_FORMAT=text/html.

• Todas las excepciones de servicio deben proporcionarse en inglés. 5. Conclusiones

Las infraestructuras de datos espaciales tienen como claro objetivo permitir la

integración de información georreferenciada proveniente de distintas fuentes. Para que este objetivo se consolide es imprescindible dedicar esfuerzos a la superación de los obstáculos existentes en los ámbitos informático y humano.

Actualmente, la inmensa mayoría de los actores participantes ha adoptado di-versos estándares, especialmente los promovidos por el Open Geospatial Consor-tium, que posibilitan tanto la distribución de sus propios datos como el uso de aquéllos provenientes de otras organizaciones. Sin embargo, aunque los problemas de carácter informático empiezan a ser resueltos todavía existen enormes vacíos en los ámbitos cartográfico y de usabilidad que demandan múltiples esfuerzos de con-solidación por parte de las organizaciones implicadas.

Las entidades colaboradoras en la constitución de Infraestructuras de Datos Es-paciales deben concienciarse de la importancia de los aspectos cartográfico y de uso pues de otro modo la información será difícilmente integrable o su manipula-ción exigirá un esfuerzo tan sumamente elevado que puede desencadenar el fracaso de este tipo de paradigma.


Referencias

[1] ISO 19128: 2005, “Geographic Information – Web Map Server Interface”, International Organization for Standarization (ISO).

[2] OpenGeospatial Consortium, Inc., “Web Map Service (WMS) Implemen-tation Specification v1.3”.

[3] Proposal for a Directive of the European Parliament and of the Council establishing an infrastructure for spatial information in the Community (INSPIRE)

[4] A. Annoni, C. Luzer, E. Gubler y J. Ihde (eds.), Map projections for Europe. European Commision, 2001.

[5] J. González-Matesanz y A. Dalda, “Development of the ED50-ETRS89 transition”, EUREF Symposium, Toledo, España, 2003

[6] WG5. CEN/TC 287, “Geographic information – Web Map Server European profile”.

[7] Megrim, “Conclusions and recommendations”, Spatial Reference Workshop, Marne-la-Vallée, Francia, 1999.

Contenidos - Universitat Jaume Icanut/books/libroAvancesIDE.pdf · en marcha la Infraestructura de...

Documents

Transcript of Contenidos - Universitat Jaume Icanut/books/libroAvancesIDE.pdf · en marcha la Infraestructura de...