Jidee 06

Jornadas Técnicas de la IDE Española 2006
CAstellón, 19 y 20 de octubre de 2006

Índice general
3
Sesión 0
1. IDE de múltiples niveles 7

1.1. La Infraestructura de Datos Espaciales de España (IDEE): Un proyecto colectivo y globa-
lizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Proceso de transformación de webEIEL en un nodo de la red de IDEs (ideAC). Estado
actual y actuaciones de futuro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3. Costes de construcción de una IDE: el caso de uso del Proyecto SDIGER. . . . . . . . . . 42
1.4. Integración de los entes locales en la IDEC. Primeros resultados y conclusiones. . . . . . . 53
2. Metadatos 65
2.1. Metadatos: Extracción y derivación automática de atributos. . . . . . . . . . . . . . . . . 67
2.2. El papel de Dublin Core en el desarrollo de las Infraestructuras de Datos Espaciales. . . . 77
2.3. Metadatos para Capas y Series Cartográcas. Modelo de Herencia de Metadatos. . . . . . 87
2.4. Metadatos de teledetección. El día después. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3. Servicios 105
3.1. Contribuciones de una IDE a la e-Ciencia: Proyecto AWARE. . . . . . . . . . . . . . . . . 107
3.2. Evaluación de la calidad de datos raster mediante aplicaciones RIA: una realidad derivada
de los servicios propuestos en una IDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.3. Análisis de los servicios WMS disponibles: hacia un conjunto de recomendaciones para su
implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.4. Geo-bovino: Un ejemplo de Geo-trazabilidad. . . . . . . . . . . . . . . . . . . . . . . . . . 133
4. Metadatos y Semántica 141

4.1. Unidades administrativas, una perspectiva ontológica. . . . . . . . . . . . . . . . . . . . . 143
4.2. El impacto de la calidad de los metadatos en los servicios de búsqueda de una IDE. . . . . 153
4.3. Ingeniería Ontológica: El camino hacia la mejora del acceso a la información geográca en
el entorno web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
4.4. Aspectos de modelos e infraestructura de servicios para el soporte de un servicio nacional
estándar de nomenclátor en Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.5. Infraestructura de Datos Espaciales en el Instituto Cartográco Valenciano. Proyecto Cart@.178
5. Demos 199
5.1. GeoMedia-OGC y Google Earth. (Intergraph) . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.2. Desarrollo de un cliente Web OGC rico. (Prodevelop) . . . . . . . . . . . . . . . . . . . . 202
5.3. GEOPISTA: una aproximación al E-Government en la Administración Local. (Proyecto
Geopista) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.4. Soluciones para la construcción de Geoportales: SIG al alcance de todos. (ESRI) . . . . . 213
6. IDE regionales y sectoriales 215

6.1. IDEAndalucía abierta al público. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.2. IDERioja, despliegue de servicios IDE en el ámbito de la Administración Local. . . . . . . 219
6.3. EUROPARC-España, un ejemplo de IDE sectorial para los Espacios Naturales Protegidos. 230
6.4. IDEZar: Procesos, herramientas y modelos urbanos aplicados a la integración de datos
municipales procedentes de fuentes heterogéneas. . . . . . . . . . . . . . . . . . . . . . . . 232
6.5. IDENA: Novedades y líneas de futuro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
7. SIG 253
7.1. PostGis en producción cartográca: CartoCiudad. . . . . . . . . . . . . . . . . . . . . . . 255
7.2. Herramientas GIS para la Gestión Medioambiental. . . . . . . . . . . . . . . . . . . . . . . 265
7.3. SITMUN: Sistema de Información Territorial en red para la administración local. . . . . . 275
7.4. Interfaces tangibles de usuario aplicados a la Información Geográca: Cartografía interac-
tiva mediante Visión por Ordenador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
7.5. Infraestructura de Datos Espaciales. Servicio WFS de la D.G. del Catastro. . . . . . . . . 295
8. EXPOSICIÓN DE POSTERS 309

8.1. Medidas para impulsar la utilización del Núcleo Español de Metadatos (NEM). . . . . . . 311
8.2. Situación actual de los metadatos en el ámbito internacional. . . . . . . . . . . . . . . . . 323
8.3. Pasarela XML para la construcción de consultas a WFS con esquemas heterogéneos a partir
de un GUI común: aplicación a la generación de informes sobre la Directiva Marco del Agua.335
Jornadas Técnicas de la IDE Española, Castellón 2006. 5

Sesión 0
8.4. El desarrollo de los Sistemas de Observación de la Tierra (SOT) en el marco de las Infra-
estructuras de Datos Espaciales (IDEs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
8.5. Utilización de servicios de una IDE en una aplicación web para la gestión de la información
de la Directiva Marco del Agua. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
8.6. StyledCat: Denición de un catálogo de estilos (SLD). . . . . . . . . . . . . . . . . . . . . 341
8.7. Solución corporativa para la gestión descentralizada de metadatos: Cliente Web de admi-
nistración de metadatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
6 Jornadas Técnicas de la IDE Española, Castellón 2006.

SESIÓN 1
IDE DE MÚLTIPLES NIVELES
7
La Infraestructura de Datos Espaciales de España (IDEE): Un proyecto... Sesión 1
La Infraestructura de Datos Espaciales de

España (IDEE): un proyecto colectivo y
globalizado
A. Rodríguez†, P. Abad†, J. A. Alonso†, A. Sánchez†.
† Instituto Geográfico Nacional

Calle General Ibáñez de Ibero, 3 28003 Madrid
Tlf: 915.979.661 Fax: 915.979.764. e-mail: afrodriguez@fomento.es
Resumen
En los últimos años, el sector de la Información Geográfica (IG) ha experimentado

un importante cambio de paradigma: desde los Sistemas de Información Geográfica
(SIG) se ha evolucionado a las Infraestructuras de Datos Espaciales (IDE). Este
nuevo concepto incluye un conjunto de datos, servicios, metodologías, normas,
estándares y acuerdos, que permiten visualizar, superponer, consultar y analizar 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
sistemas 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 inspiradas 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
europea.
En esta comunicación se presentan diversos aspectos de la IDE de España,
proyecto 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
futuras.
Palabras clave: Infraestructuras de Datos Espaciales, Información Geográfica,

Open Geospatial Consortium, Servicios, Interoperabilidad, Globalización,
Cartografía, INSPIRE.

Sesión 1 La Infraestructura de Datos Espaciales de España (IDEE): Un proyecto...
1 Introducción
Decimos que las Infraestructuras de Datos Espaciales (IDE) constituyen un nuevo
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
caracterí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 el
1989-11-09 constituye el acto inaugural de la aldea global en que vivimos [3].
Volviendo a la información geoespacial, estamos pasando: de los SIG,
considerados 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 basados 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 difusió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, dónde un gran número de actores colaboran en implementar servicios
públicos o fácilmente accesibles para la comunidad, en una dinámica de
colaboració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
creciente 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
sistemas 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
inversiones 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 referencia
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
cartográfico cualquiera pueda ser automatizado sin que la información
espacial suponga una rémora.
3) Poner a disposición del ciudadano toda la Información Geográfica
gestionada por las AA. PP. a través de servicios IDE libres, abiertos y
gratuitos, por lo menos a nivel de 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
general, 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
oficial, de otros datos, cuya fiabilidad será directamente proporcional de la
fiabilidad de la organización productora de los datos. Si alguien desea
integrar 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 ISO19100, está alineada con las iniciativas, proyectos y
disposiciones legales, que abogan por promover la libre circulación de la
información, y que reconocen el derecho de los ciudadanos a acceder a los datos
que gestionan 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 sector
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 Universidades,
Bibliotecas y Centros de Investigación de todo el mundo, que promueve 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

último es proporcionar a cada persona del planeta una suerte de “SIG simple” o
elemental, que le permita al menos buscar, ver y consultar datos geográficos
disponibles, 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 protecció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 tales
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 que 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 cartografía
y datos geográficos siguiendo un modelo de financiación basado en las ventas, y el
proceso a seguir para modificar leyes, decretos, estatutos, normas y burocracia para
que los gobiernos cambien esta situación es largo, complejo 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
gratuitos de catálogo y visualización, y deja abierta la posibilidad de establecer
servicios 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
sector.
3 Organización de la IDEE
La Infraestructura de Datos Espaciales de España (IDEE), es un proyecto
coordinado 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
Comunidades Autónomas,…) cuya presidencia ejecutiva y secretaría técnica
desempeña el Instituto 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,…), para el

intercambio 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 ISO19115, que
comprende el núcleo dicha norma ISO19115, más los ítems necesarios para tener
en cuenta Dublín Core Metadata, los metadatos contemplados en la Directiva
Marco del Agua y la descripción de la calidad.
- Una Guía de usuario del NEM v1.0, que establezca los criterios básicos para
rellenar los campos del NEM.
- Definición de un conjunto de Servicios Mínimos Recomendados a implementar

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 correspondientes
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 implementar
servicios de Gazetteer, con las ventajas que supone para armonización, intercambio
y gestión distribuida de nombres geográficos.
- Recomendación para la implementación de servicios WMS, en la que se fijan una

serie de criterios básicos, como una nomenclatura común y estándar para las capas
en el primer nivel, un Sistema de Coordenadas común que se recomienda
soportar,…
4 Estado actual del proyecto

El Geoportal de la IDEE (vease fig. 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
servicios 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ómenos (WFS); y Servicio de Coberturas (WCS).
Figura 1 Página principal del Geoportal IDEE
Integra un total de más de 28 servidores ofreciendo servicios, y permite el acceso a

más de 560 capas de información disponible, ofrecidas por instancias
gubernamentales en los tres ámbitos, estatal, regional y local, universidades,
empresas privadas,...
Presenta una interfaz en cinco idiomas (español, inglés, vasco, catalán y gallego),
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
acceder a la visualización y consulta de una gran abanico de datos de distinta
procedencia, temática y resolución (ver figura 2).
A nivel estatal, tenemos:
- La información de las Bases Cartográficas Numéricas del Instituto Geográfico
Nacional, a las escalas 1:1.000.000, 1:200.000 y 1:25.000, así como los 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.
- 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 Catastro 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 censales 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
Infraestructuras de Datos espaciales de los Ministerios de Fomento, Medio
Ambiente y el Fondo Europeo de Garantía Agraria (FEGA) está estudiando la
puesta en funcionamiento de un servicio de mapas que publique las ortofotos del
SIGPAC, que recubren toda España con un metro de resolución y algunas zonas
con medio metro.
A nivel regional, existe una gran número de iniciativas que han implementado ya o
están trabajando para implementar en breve, en unos casos servicios interoperables
que den visibilidad a su cartografía, y en otros casos Geoportales e Infraestructuras
de Datos Espaciales Regionales, tan interesantes como las de Cataluña, Navarra,
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
excepció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

tecnológico.
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.
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 bien número de Ayuntamientos están muy interesados en abrir
su Geoportal 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 existentes o
que publican datos de referencia: el Atlas Climatológico de la Península Ibérica
desarrollado por la Universidad Autónoma de Barcelona; la IDE de Costas,
integrada 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 inventario de más de un millón de especies florales y su
distribución espacial sobre cartografí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ásicosde 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 funcionalidades
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 datos.
- Guardar la imagen que se está mostrando en el visualizador en un momento

determinado en una variedad de formatos que incluye los más utilizados (JPG,
PNG, GIF).
- Superponer interactivamente un Servicio de Mapas (WMS) del que conocemos su

dirección URL o uno de los definidos por defecto en el menú habilitado 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 superpuestos:

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

manera muy simple, aunque no de acuerdo a ninguna especificación Open
Geospatial Consortium: sencillamente muestra en pantalla un inventario de los
servicios disponibles 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 un experto 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 dónde se recogen todos los parámetros (servicios
invocados, ámbito de visualización, enlaces activos, Sistema de Referencia
utilizados, etcétera) 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 conforme 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
datos, ofrece la obtención libre y abierta en formato GML (Geographic Markup
Language) 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

Autó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 productores

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 informació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
producidos desde la primera versión (1990) hasta la vigente (2000), y obtener una
estadística del tanto por ciento de superficie municipal ocupada por un tipo o más
de cubierta, a gusto del usuario. El interés de esta elemental aplicación de análisis
superficial 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 (ver figura 3).
4.3.4 Aplicación de análisis del MDT, otro ejemplo sencillo de análisis en línea
realizado sobre el Modelo Digital del Terreno 1:200.000 del IGN, basado en el
estándar Web Coverage Service (WCS). La aplicació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.

Figura 3. Visualización de los cambios 1990-2000 en el Corine-Land Cover
4.3.5 Servicio temporal de mapas catastrales. Gracias a que la Dirección General

del Catastro ha implementado un servicio de mapas WMS que admite el parámetro
TIME en la forma AAAA-MM-DD, el visualizador del Geoportal es capaz de
realizar llamadas sucesivas a ese servicio especificando 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 Heart. La IDEE es además capaz de interoperar con el
visualizador Google Herat, aunque no se trate de un visualizados estándar OGC.
Utilizando una pasarela desarrollada por un experto de la Dirección General del
Catastro, es posible superponer un servicio WMS cualquiera que cumpla los
estándares con la visualización ofrecida por Google Heart, y como ejemplo, en el
Geoportal IDEE hay sendos plug-in de libre descarga que permiten dicha

superposición utilizando los servicios de mapas de catastro y de la cartografía

básica del IGN.
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, que permite acceder a los
servicios estándar más usuales WMS y de Nomenclátor desde plataformas PDA y
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ándar 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
correspondiente 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éricos, gestionados por el INE.
4.5 Clientes pesados
Para completar el panorama existente en España vale la pena mencionar la

aparición del proyecto de Software Libre gvSIG (www.gvsig.gva.es), impulsado
por la Consellería 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 facilidades de edición de datos, análisis vectorial y ráster, edición
orientada al trazado en papel, etcétera [15].
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 Infraestructura de
Datos Espaciales que gestione los datos geográficos relativos a la Directiva Marco
del Agua, en las cuencas hidrográficas del Ebro y del Adour-Garona, situadas en
dos países distintos (Francia y España).
Es un proyecto piloto para la implementación de INSPIRE, financiado por la
Comisió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 Extremadura), se
encuadra bajo el paraguas del programa INTERREG III A, y tiene como 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 Asociaciones 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
abrumadora, 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 visitantes, 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
cartográfica más visitadas en nuestro país: Google Heart; el SIG de Parcelas
Agrícolas (SIGPAC) del Ministerio de Agricultura, Pesca y Alimentación, que
muestra ortofotos de toda España de 1 metro de resolución; la Oficina Virtual del
Catastro,….
En ese sentido, el Grupo de Trabajo de la IDEE, en la reunión celebrada en
Valladolid el pasado mes de Junio, decidió formar un Subgrupo de Trabajo bajo la
denominació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,…que se elaboren para cumplir el primer objetivo.
- Analizar las medidas a tomar para lograr la difusión y promoción es
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,…
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

informació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
necesaria 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, sobre todo,
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 la Infraestructura 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 significativa disminución de los costes de gestión y utilización que implica
el acceso interoperable 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,
regional y local), del entorno universitario y del sector privado.
Esta impresionante oferta de información geográfica, junto con las funcionalidades
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
especialistas, 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 las 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
implicados: 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
compartes, 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, 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_dire
ctive_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 in “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-06-21/23.
[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... Sesión 1
Proceso de transformación de webEIEL en un nodo de la red de

IDEs (ideAC). Estado actual y actuaciones de futuro
(1) (2) (3) (1)
N.R. Brisaboa , P.A. González , M. Lorenzo , M. R. Luaces .
(1) Laboratorio de Bases de Datos, Fac. de Informática

Universidad de A Coruña
Campus de Elviña s.n., 15071 A Coruña
Tlf: 981.167.000. Fax: 981.167.000. e-mail: {brisaboa, luaces}@udc.es
(2) Servicio de Asistencia Técnica a Municipios

Diputación Provincial de A Coruña
Av. Alférez Provisional s.n., 15006 A Coruña
Tlf: 981.183.300 Fax: 981.183.308. e-mail: pedro.gonzalez@dicoruna.es
(3) 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
Tlf: 981.183.300 Fax: 981.183.308. e-mail: miguel.lorenzo@dicoruna.es
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
destaca 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 colaboració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 distribuída 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

Sesión 1 Proceso de transformación de webEIEL en un nodo de la red de IDEs...
integrados en la red de IDEs.
En el artículo se presenta en primer lugar una breve descripción de la aplicación webEIEL y de los
condicionantes que presenta, para a continuación establecer 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 municipios 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 BD territorial y gestionarlos y publicarlos mediante
aplicaciones SIG integradas, en la mayor medida posible, en la Red. Para ello se suscribieron
sendos convenios con la Universidad de A Coruña (UdC) mediante los cuales 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.
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
El resultado final del segundo de los convenios mencionados fue la implantación de dos
aplicaciones: sigEIEL (posteriormente renombrada como gisEIEL) y webEIEL, independientes entre
sí, pero que hacían uso del mismo conjunto de datos. 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.

webEIEL, por tanto, es la aplicación de publicación en web (http://www.dicoruna.es/webeiel/) y

distribución de los datos contenidos en la Base de Datos Territoriales 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á construida sobre

tecnologías GeoMedia Web Map, de Intergraph, y con los datos contenidos en formato GeoMedia
SmartStore, a fin de mejorar los ratios de transmisión a la red.
Figura 2. Página de acceso a webEIEL
Esta base tecnológica implica varias consecuencias:

1. Debido al acuerdo corporativo existente entre Intergraph y Micrososoft, 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 datos sea innecesariamente más lenta de lo deseable
2. 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 algunas de sus funciones no se ejecuten
adecuadamente sobre otros navegadores. Y entre éstas una muy esencial: la visualización
de los mapas temáticos
3. 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
4. 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 Informática de la

Diputación Provincial de A Coruña (DPC) decidió ir migrando las aplicaciones corporativas a
entornos de software libre o de código abierto (Open Source).
Todo ello, junto con la evolución de las tecnologías asociadas a Internet, el propio éxito obtenido

por nuestro servidor de mapas, y el lanzamiento de la iniciativa INSPIRE (INfrastructure for Spatial
InfoRmation in Europe) de la Comisión Europea, 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
supervisar la IDE provincial y corporativa.
Rol: Proveedor oficial de los datos georreferenciados de la EIEL de A
Coruñ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 garantizando 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 entorno (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 tecnologí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, y
• 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 (GT-IDEE), 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 servicios y sus componentes:
3.1 Servidor de mapas (WMS):
Permitirá el acceso remoto a datos geográficos para su visualización y superposició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 necesidad 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. Esta formado por los siguientes componentes:
• Servicio de edición de metadatos (SEM): Permitirá crear, grabar, modificar, actualizar o
eliminar los metadatos y, por tanto el correspondiente Catálogo
• 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 (posición, área), cronológicos (fecha de
actualización de la información), topológicos (proximidad a, intersección con,
yuxtaposición con, ...), cartográficos (escala, altitud, precisión, resolución), tipológicos
(DEM, vector, raster, imagen), o 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), así como otros que se puedan identificar en el futuro.
• Servicio de gestión de datos (SGD): Permitirá acceder a los datos seleccionados tras la
correspondiente consulta y suministrárselos al usuario en las condiciones establecidas para
el conjunto de datos de que formen parte. Estos datos se transmitirán a través de la red en
formato GML (Geography Markup Language), de tal modo que las aplicaciones cliente
puedan entenderlos sin dificultad. Para ello harán uso de los
• Servicios de importación/exportación XML/GML (SIE), que traducirán a y de estos
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álogos 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 registrados.
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 partiendo 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, modificar, actualizar o
eliminar los datos contenidos en el (o los) 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 conjunto 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, yuxtaposición con, ...),
cartográficos (escala, altitud, precisión, resolución), tipológicos (DEM, vector, raster,
imagen), así como otros que se puedan identificar en el futuro.
Además de estos cuatro servicios básicos, se han implementado también diversos servicios
complementarios que han de permitir realizar tareas de administración, gestión, coordinación y
mantenimiento del nodo. Entre otras, realizan las siguientes funciones: actualización y
mantenimiento de datos y servicios, identificació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 software que se muestra
en la figura 1. 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 adicional 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 almacenamiento 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 diferentes 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 arquitectura en este

artículo. 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 almacenamiento 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 sistema una gran
agilidad en el tratamiento de la información. Por otra parte es imprescindible 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.

GISEIEL
Navegador Web Applet Java DHTML
Cliente WFS Cliente WMS
SVG PNG
Contenedor App. Web WebEIEL
WMS
WFS CS-W
SGBD (SFS for SQL)
BD
EIEL
Figura 3: Arquitectura del nodo ideAC
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 cualquier cliente del nodo ideAC puede obtener la información geográfica en un
formato (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, como 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 información.
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 ofrecer 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.
La ventajas de este interfaz de usuario consisten en que el applet Java permite 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 calidad de los mapas y la interactividad de los mismos es
mucho más elevada. Sin embargo, 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 funcionamiento 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 únicamente 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 informació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).
• Servizo web de catálogo de metadatos.
• Servizo web de nomenclátor.
gisEIEL
• Conexión con sistemas gestores de bases de datos que implementen el estándar Simple
Features Specification for SQL (SFS).
• Visualización de información geográfica en distintos sistemas de coordenadas.
• 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 especificas 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 integrarse en los sistemas informáticos de la
Diputación Provincial de A Coruña, se tuvo en cuenta la compatibilidad del entorno de
desarrollo con dichos 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 evaluaron en profundidad, en concreto:
webEIEL
• Deegree [13]. Este proyecto de software libre ofrece un conjunto de bloques fundamentales
para construir una infraestructura de datos espaciales implementado os estándares do Open
Geospatial Consortium (OGC) e o ISO/TC 211. Los servicios implementados por este
proyecto son: Web Map Service (WMS), Transactional Web Feature Service (WFS), Web
Coverage Service (WCS), Web Catalogue Service (CS-W), y Web Gazeteer Service 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 servicios Web Map
Service (WMS), y Basic Web Feature Service (WFS).
• GeoNetwork [16]. Es una aplicación web (pero no es un servicio) que permite 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 relacionados como pode ser deeJUMP [18], una adaptación hecha
por el equipo de desarrollo de Deegree, u Open Jump Pilot [19].
• gvSIG [20]. Es una herramienta de código aberto orientada al manejo de información
geográfica.
• UDIG [21]. Es tanto una aplicación de visualización y edición de información geográfica
como una plataforma de desarrollo de nuevas aplicaciones.
• Saga [22]. Proporciona tanto una librería de programación coma una interfaz gráfica para el
análisis de información geográfica.
El proyecto GeoPISTA [23] del Ministerio de Ciencia y Tecnología no fue evaluado 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 implementació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 propietarios. La conexión con PostgreSQL no

se hace a través del estándar SFS, sino 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 podemos ver el resultado de la comparación entre los distintos
componentes.
webEIEL
Deegree GeoServer MapServer GeoNetwork

SFS Si Si Si Si
WFS Transaccional. Transaccional. Básico. Cliente
WMS Si, con SLD Si, con SLD Si, con SLD Cliente
Catálogo Si No No Si
Nomenclátor Si No No No
Formatos Shapefile, GML Shapefile, GML Shapefile, GML No aplicable
adicionales
Lenguaje Java Servlet Java Servlet C++ CGI Java Servlet
Comunidad Limitada Activa Activa Activa
Crecimiento Limitado Elevado Elevado Elevado
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 generados y se apreció que
los generados por GeoServer son de peor calidad que los generados por Deegree. En lugar de
devolver en el archivo únicamente aquellos objetos geográficos visibles en la consulta actual,
devuelve todos los objetos geográficos 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
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 documentación para desarrolladores.
gisEIEL
JUMP gvSIG UDIG SAGA

SFS Si Si Si No
Visualización Problemas de Si Si Si
memoria y

velocidad
Edición Completa No incluida Completa Completa
WMS Si Si Si No
WFS Si No incluido Si No
WCS No Si No No
Formatos Shapefile, GML, Shapefile, GML, Shapefile, GML, Múltiples raster,
adicionales CAD CAD, Raster CAD incluido análisis
Lenguaje Java Java Java C++
Comunidad Activa Limitada Activa Activa
Crecimiento Limitado Elevado Elevado Elevado
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 raster.
Dado que uno de los requisitos básicos es que el componente software implemente 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 funcionalidad 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
implementada 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 artículo 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
funcionamiento del nodo ideAC.
En la figura 2 se muestra una captura de pantalla de la herramienta de visualizació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, edificaciones) con la información extraída del WMS de
Catastro. En la figura 3 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
como hay un hotel seleccionado en la parte inferior del centro de la imagen (con borde amarillo),
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 individual, 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 4. En este caso se muestran dos
pantallas del catálogo de metadatos. En la figura 4(a) se muestra la lista de mapas disponibles en el
sistema. Por otra parte, en la figura 4(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, ante 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 interesadas en su uso. Además, la aplicación de los
conceptos de interoperabilidad, estandarizació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
ayuntamientos 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, mediante 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 informació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 (raster)
˙ 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 homogeneidad 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 originales. En realidad, este servicio actuará sólo
en aquéllos 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 propiamente un
servicio de geoprocesamiento, ya que no ha de ejecutar operació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 informació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 comunicación con los servicios de
registro y de catálogo a fin de tener notificació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 propietario
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 Workshop, Varsovia, 2004
[2] P.A. González, “A Coruña Province SDI design”, MSc in Geographic Information
Dissertation, City University, London, 2004
[3] P.A. González, “Análisis funcional de los servicios de red asociados a la Infraestructura de
Datos Espaciales de la Provincia de A Coruña (ideAC)”, Trabajo 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, and J.R. Viqueira. State of the Art and
Requirements in GIS. En Proc. of the 3rd Mexican International Conference on Computer
Science (ENC), Aguascalientes, Mexico, 2001.
[5] Open Geospatial Consortium, Inc.. Implementation Specification for Geographic information -
Simple feature access - Part 2: SQL option (SFS). Accedido el 10 de Febrero de 2006 en la
URL http://portal.opengeospatial.org/files/?artifact_id=13228

[6] Open Geospatial Consortium, Inc. Web Feature Service (WFS) Implementation Specification.
Accedido el 10 de Febrero de 2006 en https://portal.opengeospatial.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.opengeospatial.org/files/?artifact_id=5316
[8] Open Geospatial Consortium, Inc. Catalogue Service Implementation Specification (2.0.1).
Accedido el 10 de Julio 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 el 10 de
Julio en http://portal.opengeospatial.org/files/?artifact_id=11339
[11] Open Geospatial Consortium, Inc. Gazetteer Service Profile of a WFS. Accedido el 10 de Julio
en http://portal.opengeospatial.org/files/?artifact_id=13593
[12] N.R. Brisaboa, M.R. Luaces, J.R. Paramá, D. Trillo, and J.R. Viqueira. Improving
Accessibility of Web-Based GIS Applications. En Proc. of the 2nd International Workshop on
Geographic Information Management (DEXA Workshop). Copenhagen, Denmark, 2005.
[13] Deegree. Accedido el 10 de Febrero de 2006 en la URL http://deegree.sourceforge.net/
[14] GeoServer. Accedido en la URL http://docs.codehaus.org/display/GEOS/Home el 10 de
Febrero de 2006
[15] MapServer. Accedido el 10 de Febrero de 2006 en la URL http://mapserver.gis.umn.edu/
[16] GeoNetwork Accedido en la URL http://sourceforge.net/projects/geonetwork el 10 de Febrero
de 2006
[17] The JUMP Project. Accedido en la URL http://www.jump-project.org/ el 10 de Febrero de
2006
[18] deeJUMP. Accedido en la URL http://demo.deegree.org/download/demos/deejump/deejump-
20051102.zip el 10 de Febrero de 2006
[19] JUMP Pilot Project. Accedido el 10 de Febrero de 2006 en la URL http://jump-
pilot.sourceforge.net/
[20] gvSIG. Accedido el 10 de Febrero de 2006 en la URL http://www.gvsig.gva.es
[21] uDIG. Accedido el 10 de Febrero de 2006 en la URL http://udig.refractions.net
[22] SAGA GIS. Accedido el 10 de Febrero de 2006 en la URL http://www.saga-gis.uni-
goettingen.de/html/index.php
[23] GeoPISTA. Accedido el 10 de Febrero de 2006 en la URL http://www.geopista.com

Sesión 1 Costes de construcción de una IDE: el caso de uso del Proyecto SDIGER.
Coste de desarrollo de una IDE: el caso de uso del

proyecto SDIGER
E. Fernández-Villoslada, J. Nogueras-Iso, M.A. Latre, R.Béjar,

P.R.Muro-Medrano, F.J. Zarazaga-Soria,
Departamento. de Informática e Ingeniería de Sistemas

Universidad de Zaragoza, María de Luna 1, 50018 Zaragoza
Tlf: 976 762 134 Fax: 976 761 914.
e-mail: {evaf, jnog, latre, rbejar, prmuro, javy}@unizar.es
Resumen
El desarrollo de cualquier sistema de información en general, y el de una

Infraestructura de Datos Espaciales en particular, lleva asociado todo un conjunto
de costes que es necesario estimar previamente, para luego hacer un seguimiento de
los mismos y una posterior evaluación una vez finalizado al objeto de verificar el
más que probable desfase entre lo estimado y lo real. El resultado de este análisis
permite identificar problemas y aprender para futuros desarrollos.
Palabras clave: Análisis de costes, Infraestructuras de Datos Espaciales, IDE,

proyecto SDIGER.
1 Introducción
El desarrollo de cualquier sistema de información en general, y el de una
Infraestructura de Datos Espaciales (IDE) en particular, lleva asociado todo un
conjunto de costes que es necesario estimar previamente, para luego hacer un
seguimiento de los mismos y una posterior evaluación una vez finalizado al objeto
de verificar el más que probable desfase entre lo estimado y lo real. El resultado de
este análisis permite identificar problemas y aprender para futuros desarrollos.
Además una estimación precisa es muy importante para posteriormente poder:
realizar un análisis costo-beneficio y financiero adecuado; realizar análisis de
inversión acertados; proveer la base para la evaluación gerencial de múltiples

Costes de construcción de una IDE: el caso de uso del Proyecto SDIGER. Sesión 1
proyectos; servir de fundamento para los cronogramas, asignación de personal,

gerencia de proyectos y definición de estructura; y evitar problemas como la
renegociación de contratos, sobretiempos, incrementos de los costos de los usuarios
o de los costos de los proyectos
El mayor hándicap con el que se cuenta en la actualidad en el mundo de las
infraestructuras de datos espaciales es la no existencia de trabajos previos que se
hayan preocupado de identificar las fuentes de los problemas asociados a su
construcción y puesta en funcionamiento, así como de la realización de una
contabilidad previa que permita partir de una base razonable sobre la que apoyar
trabajos de planificación. Por ello, será necesario basarse en la experiencia del
grupo desarrollador del proyecto, así como en métodos tradicionales de análisis de
costes. Hay que tener en cuenta que todo análisis de costos involucra tanto
costo/beneficio como costo/efectividad. La determinación del costo y beneficio
analiza los costos de un procedimiento específico o de la aplicación de una
tecnología a sus probables beneficios en términos monetarios. En contraste, la
evaluación de costo y efectividad se refiere a los costos de un procedimiento y sus
beneficios estimados en efectos relacionados con el cumplimiento al 100% de los
objetivos planteados inicialmente.
El objetivo de este artículo es presentar el trabajo realizado dentro del marco del
proyecto SDIGER [1,2,3] para estimar los costes de implantación de una IDE a
nivel Europeo. SDIGER es un proyecto piloto de la propuesta de Directiva
INSPIRE [4] consistente en el desarrollo de una Infraestructura de Datos
Espaciales en Europa para apoyar el acceso a recursos de información geográfica
requeridos por la Directiva Marco del Agua (DMA) [5] dentro de un contexto
inter-administrativo y transfronterizo. El contexto elegido como prototipo para el
desarrollo del proyecto ha sido la zona transfronteriza entre Francia y España, zona
donde coexisten más de dos lenguas oficiales y donde se entrecruzan la cuenca
hidrográfica del Adour-Garonne, gestionada por L'Agence de l'Eau Adour-
Garonne, y la cuenca hidrográfica del Ebro, gestionada por la Confederación
Hidrográfica del Ebro (ver portal del proyecto en http://www.sdiger.net).
Sin embargo, a pesar de poner en marcha la IDE en un contexto específico, el
principal objetivo del proyecto es que esta experiencia sirviese para estimar el coste
de implementar una IDE a nivel europeo, identificando los problemas encontrados
y las experiencias de éxito implicadas en el desarrollo del mismo. La siguiente
sección describe la forma de representar la extrapolación del prototipo del proyecto
SDIGER a un contexto más general, que pueda extenderse a otros países y cuencas
hidrográficas. A continuación la sección 4 presenta una fórmula capaz de
extrapolar dicha valoración para un número flexible de cuencas hidrográficas y sus

autoridades competentes. Y por último, este artículo termina con una serie de
conclusiones.
2 Representación del contexto de extrapolación
2.1 Selección de la unidad de extrapolación

Uno de los principales problemas encontrados durante el proceso de valoración de
la implantación de SDIGER a nivel europeo es la heterogeneidad que podemos
encontrar en dos aspectos principales: la organización administrativa de los estados
miembros de la Unión Europea; y el estado de las tecnologías y disponibilidad de
datos en el contexto de Infraestructuras de Datos Espaciales.
La heterogeneidad en la organización administrativa del país afecta en la definición
de la granularidad usada para extrapolar el proyecto SDIGER. Se podría considerar
la extrapolación del proyecto SDIGER como la adición de un nuevo país, p. ej. la
participación de una nueva Agencia Cartográfica, una nueva Agencia de Medio
Ambiente, etcétera. Sin embargo, esta asunción no es realista porque muchos
países europeos en vez de establecer agencias centralizadas a nivel nacional han
delegado estas responsabilidades en agencias federales/regionales. El proyecto
SDIGER, puesto en práctica a ambos lados de la frontera entre Francia y España no
ha afrontado todas las posibilidades de organización administrativa ya que es muy
amplia. Aunque Francia esté más centralizada que España, España no es un
ejemplo de país federal como Alemania. Y en el caso del Reino Unido o Bélgica es
todavía bastante más diferente de Alemania.
La heterogeneidad en el estado tecnológico de las IDEs hace más complejo este
ejercicio de extrapolación porque no es posible asumir una infraestructura básica.
De hecho, la estimación de costes para un escenario extrapolado debe ser
suficientemente flexible para proporcionar estimaciones más exactas para todos los
casos (no disponibilidad de infraestructura, algunos servicios disponibles o
disponibilidad de una IDE avanzada).
Por lo tanto, hemos pensado apropiado usar una cuenca hidrográfica (y su
autoridad competente respectiva) como la unidad incremental para los escenarios
de extrapolación. Hay dos motivos principales para esta elección. Por un lado, cada
cuenca hidrográfica es una unidad indivisible cuya responsabilidad cae sobre una
Autoridad Competente en cada Estado miembro. Y por otra parte, el estado de la
tecnología y la disponibilidad de datos es o debería ser bastante homogéneo. Ya
que la Directiva Marco del agua (DMA) ha entrado en vigor, y por tanto las
Autoridades Competentes de cada cuenca hidrográfica están obligadas a

proporcionar una serie de datasets en unos plazos concretos. Estos datasets son
precisamente las capas requeridas para los escenarios de la aplicación web de
SDIGER. El estado de la tecnología no es homogéneo hoy día, pero en el futuro
(cuando la DMA esté en un estado más avanzado) todas las Autoridades
Competentes deberían alcanzar un nivel tecnológico comparable con el fin de
poder proporcionar los datos requeridos. Al menos, una infraestructura de la
cuenca hidrográfica lo suficientemente restringida para proporcionar una
estimación razonable.
2.2 Selección de la unidad de medida

Otro problema adicional con el que nos encontramos para las estimaciones de coste
es la selección de un conjunto unificado de unidades que sea capaz de proporcionar
un conjunto homogéneo de valores.
Una primera aproximación habría sido seleccionar una unidad monetaria para
poder incluir en las estimaciones tanto el coste de los recursos humanos, como del
software necesario. Sin embargo, no resulta aconsejable incluir el coste del
software en las estimaciones ya que este coste depende de demasiadas variables
(quien es el cliente, número de equipos donde se instalará el software, impacto del
proyecto, políticas impositivas de cada país,…). Lo que sí resulta razonable es
considerar que todas las soluciones software tendrán un coste similar en cuanto a
los recursos humanos necesarios para su instalación y la adaptación.
Por otro lado, las diferencias existentes dentro de la Unión Europea en cuanto a la
valoración de la mano de obra tampoco permiten establecer un precio uniforme
para todos los estados miembros de la Unión Europea. Así pues, la decisión final
ha sido utilizar un “día laborable normalizado” como unidad estándar para la
evaluación y la estimación de los costes presentados. Esta unidad estándar
corresponde con el trabajo hecho durante un día laborable (37.5 horas de trabajo
por semana, que es 7.5 horas de trabajo por día) por " una mano de obra
normalizada ". " Una mano de obra normalizada " representa las capacidades de
una persona con un nivel medio/alto de experiencia en una área específica. La
Tabla 1 presenta una tabla de equivalencias entre " mano de obra normalizada " y
los distintos niveles de formación y experiencia.
Tabla 1. Mano de obra normalizada

Nivel de formación y experiencia Equivalencia unidades
Director de proyecto (> 3 años de experiencia ) 3

Director de proyecto (< 3 años de experiencia ) 2

Ingeniero de software (> 3 años de experiencia en análisis) 2.5
Ingeniero de software (< 3 años de experiencia en análisis) 1.5
Ingeniero de software (> 3 años de experiencia en diseño) 1
Ingeniero de software (< 3 años de experiencia en diseño) 0.75
Programador software (> 3 años de experiencia) 0.75
Programador software (< 3 años de experiencia) 0.5
Creador de metadatos (> 1 año de experiencia) 0.5
Creador de metadatos (< 1 año de experiencia) 0.25
Administrador de sistemas (> 3 años de experiencia) 1
Administrador de sistemas (< 3 años de experiencia) 0.75
Ingeniero en Geodesia (> 3 años de experiencia) 1.5
Ingeniero en Geodesia (< 3 años de experiencia) 1
Geógrafo (> 3 años de experiencia) 1
Geógrafo (< 3 años de experiencia) 0.75
2.3 Desglose de actividades a estimar

Esta sección proporciona un desglose de las actividades requeridas para la
implantación del proyecto SDIGER a nivel Europeo. Estas actividades están
organizadas en tres niveles:
• Actividades asumidas. Se presupone que las instituciones que van a
participar en el proyecto han recopilado un mínimo de información que es
absolutamente necesaria para el desarrollo del proyecto. Si no se dispone
de esta información será imposible ejecutarlo.
• Modelado y actividades reutilizables. Este segundo nivel está constituido
de las actividades (incluyendo la definición de modelos, desarrollo de
metodologías y tecnología, y decisiones tomadas en cuanto al software y
hardware) que han sido realizadas para el Proyecto SDIGER y que pueden
ser utilizadas en los escenarios extrapolados, de manera que no se tendrán
que repetir.

• Actividades específicas del contexto. Este tercer nivel consiste en las

actividades que dependen de la naturaleza de las entidades implicadas en el
escenario de aplicación, p. ej. el conjunto mínimo de servicios e
información que se deberían proporcionar en el contexto del proyecto
SDIGER.
Se debe indicar que la valoración de costes que se realiza debe centrarse en las
actividades consideradas en el segundo y tercer nivel porque las actividades
consideradas en el primer nivel son asumidas en el escenario de extrapolación. La
estimación de gastos de las actividades del segundo nivel representan los gastos
fijos del proyecto independientemente del número de cuencas hidrográficas y
autoridades competentes implicadas. Adicionalmente, se debe prestar una atención
especial a la estimación de gastos del tercer nivel ya que representan el coste de
incorporar al proyecto una nueva cuenca hidrográfica y autoridad competente. Y
como se ha mencionado en el apartado dos, este tercer nivel abarca un gran número
de factores desconocidos.
Para desarrollar este análisis, en primer lugar, será necesario considerar los gastos
de definición del modelo y de las actividades reutilizables basadas en los presentes
gastos que la puesta en práctica de proyecto SDIGER supone, y que podrán ser
utilizadas en los contextos extrapolados. Este concepto se refiere a la valoración de
los gastos fijos incurridos en la puesta en práctica de un IDE, que incluye, la
definición del escenario de aplicación, la definición de perfiles metadata, desarrollo
de herramientas de edición de metadata, definición de modelos comunes, desarrollo
de un geoportal internacionalizado, diseño e implementación de un catálogo para el
cliente, diseño e implementación de “gazetteer”, implementación de un
visualizador de mapas internacionalizado y la configuración de algunas capas fijas,
desarrollo de aplicaciones Web que requieren el análisis, el diseño y la
implementación de componentes de software expresamente creados para la
implementación de los casos de uso definidos en el escenario de aplicación,
adquisición de software y hardware, adaptación para infraestructuras multilingüe y
otras actividades incluidas dentro de la gestión general del proyecto.
En segundo lugar, será necesario valorar los costes de las actividades que dependen
de la naturaleza de las entidades implicadas en el escenario de aplicación del
proyecto, tomando como referencia los verdaderos costes de implementación del
proyecto SDIGER. Esta clase de gastos puede ser identificada como costes
variables y dentro de esta clasificación encontramos: reingeniería de datos,
reingeniería de aplicaciones Web, reingeniería de los datos de índice geográfico,
reingeniería de datos de tesauro, recopilación de metadatos, configuración de
servicios (servicios de catálogo, gazetteer, acceso a datos, tesauros etc.), adaptación
multilingüe, personalización de las aplicaciones Web (esta actividad incluye el

estudio de legislación y el ajuste de algunos parámetros de software),

mantenimiento de servidores, actividades relacionadas con la adquisición de
hardware y el software (esta adquisición depende de la situación específica de las
instituciones del país implicado en el proyecto) y otras actividades relacionadas
con la comunicación y la coordinación con los directores del Proyecto.
4 Estimación de costes
El objetivo de esta sección es proporcionar la estimación de costes de las
actividades descritas en la sección 2.3, con el fin de proporcionar posteriormente
una fórmula que nos permita obtener la estimación de costes para un número
flexible de cuencas hidrográficas y sus autoridades competentes.
Para realizar la estimación de costes para el escenario de extrapolación se ha
construido una tabla de estimación donde se facilita para cada actividad la siguiente
información:
• Coste unitario. Esta es la estimación unitaria del coste de cada actividad en
días laborables normalizados. Se debe tener en cuenta que la estimación de
costes de estas actividades está altamente influenciada por los problemas
encontrados en el desarrollo de estas actividades.
• Factor de escalabilidad. Indica la unidad usada para escalar cada actividad
en un contexto específico dentro de un escenario de extrapolación.
Sobre esta tabla de estimación, resulta inmediato estimar los costes para un
escenario de extrapolación específico ya que solo hay que valorar el número de
unidades necesarias en ese contexto, calcular el número de “días laborables
normalizados” requeridos por actividad, y obtener la suma total de “días laborables
normalizados”.

Tabla 2. Estimación de actividades reutilizables

Coste
Coste Factor de Nº unidades
Actividades unitario escalabilidad contexto contexto
1. Definición del escenario de
aplicación 40 40
2. Definición de los perfiles de
metadatos 60 60
3. Herramienta de edición de
metadatos 120 120
4. Definición de modelos comunes 0
4.1. Datos geográficos 60 60
4.2. Contenidos de gazetteer 20 20
4.3. Contenidos de tesauros 5 5
5. Desarrollo de infraestructura para No
No aplicable
geoportales internacionalizados aplicable
5.1. Infraestructura 40 40
5.2. Cliente de catálogo 50 50
5.3. Cliente de gazetteer 20 20
5.4. Visualizador de mapas 20 20
5.5. Aplicaciones Web 180 180
6. Adquisición hardware y software 12 12
7. Infraestructura para adaptación
multilingüe 25 25
8 Gestión general 80 80
Un extracto de esta tabla de estimación se muestra en las tablas 2 y 3. La

Tabla 2 muestra la estimación de las actividades reutilizables (independientes del

contexto). La Tabla 3 muestra la estimación de las actividades que si son
dependientes del contexto y donde la columna “Factor de escalabilidad” cobra todo
su sentido. Adicionalmente, se puede observar como se han rellenado las columnas
"Número de unidades contexto” y “Coste contexto” para realizar los cálculos
correspondientes al prototipo llevado a cabo dentro del proyecto SDIGER en la
zona transfronteriza de España y Francia (cuencas hidrográficas del Ebro y Adour-
Garonne), incluyendo el mantenimiento de la infraestructura durante un año. La
columna "Coste contexto" presenta el número total de días laborables por actividad
y la estimación total de días laborables es 1180.
Tabla 3. Estimación de actividades específicas del contexto (CH=Cuenca
Hidrográfica)
Coste
Coste Factor de Nº unidades context
Actividades unitario escalabilidad contexto o
1. Reingeniería de datos
1.1. Datos geográficos 20 CH 2 40
1.2. Datos de gazetteer 15 CH 2 30
1.3. Datos de tesauros 5 tesauro 8 40
2. Recopilación de metadatos 10 CH 2 20
3. Configuración de servicios
3.1. Servicios de catálogo 15 centralizado 1 15
3.2. Servicios de gazetteer 10 centralizado 1 10
3.3. Servicios de visualización 12 CH 2 24
3.4. Servicios de acceso a datos 12 CH 2 24
3.5. Servicios de tesauros 10 centralizado 1 10
4. Adaptación multilingüe 31 idioma 3 93
5. Personalización Aplicación Web 10 CH 2 20
6. Adquisición hardware y software 10 CH 2 20
7. Mantenimiento anual de
servidores 26 CH 2 52
8. Otras actividades 25 CH 2 50

5 Conclusiones
Este trabajo ha presentado un método para poder estimar la implantación de una
IDE a nivel Europeo que involucre a varias instituciones de distintos estados
miembros. Se ha descrito la forma de hacer una representación genérica de un
contexto de extrapolación, incluyendo la definición de unidades de extrapolación,
unidades de medida y un desglose genérico de actividades. Y sobre esa
representación genérica del contexto, se ha ofrecido una tabla de estimación para
contextos de extrapolación basada en los costes reales de implantación en la zona
trans-fronteriza de las cuencas del Adour-Garonne y del Ebro.
Sin embargo, hay que reconocer que las asunciones que se deben tomar para poder
realizar estimaciones en el contexto de las IDEs pueden influir en su objetividad
[6]. En primer lugar, hay múltiples variables que hacen difícil la estimación exacta
de los gastos. Por ejemplo, hay que tener en cuenta los siguientes factores
desconocidos: estado tecnológico en cada cuenca hidrográfica, el estado de
implementación de la Directiva Marco del Agua, o la disponibilidad de recursos
humanos en las Agencias Competentes para la implantación de SDIGER, su
experiencia y formación. En segundo lugar, cabe mencionar que la mayor parte de
las actividades del caso real implementado en las cuencas Ebro y Adour-Garonne
han sido realizadas por un equipo de alta cualificación con amplia experiencia en el
desarrollo de proyectos relacionados con IDEs. Además, hay una buena relación
entre las entidades socias debido a una historia común de proyectos anteriores. Y
por último, la mayor parte del software usado en el prototipo implementado por el
proyecto ha sido desarrollado por propias entidades desarrolladoras del proyecto.
En todo caso y aun reconociendo el margen de error inherente a cualquier actividad
de estimación de costes, el trabajo presentado en este artículo permite monitorizar
el desarrollo de proyectos con funcionalidades y arquitecturas similares. Los
resultados aquí expuestos son trasladables con relativa facilidad a otros ámbitos ya
que los recursos y servicios ofrecidos por una IDE se pueden reutilizar en distintos
contextos. Es decir, aunque el diseño de las aplicaciones Web tengan un carácter
específico, los servicios y los patrones arquitecturales sobre los que se construyen
esas aplicaciones son completamente reutilizables.
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] M.A. Latre, F.J. Zarazaga-Soria, R. Béjar, P.R. Muro-Medrano, J. Nogueras-
Iso, “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, ESDI: Setting the Framework Alghero, Sardinia, 29th
June - 1st July 2005
[2] F.J. Zarazaga-Soria, J. Nogueras-Iso, M.A. 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”. Aceptado para su publicación en
Research and Theory in Advancing Spatial Data Infrastructure Concepts,
ESRI Press (editor: H. Onsrud), 2006
[3] J. Nogueras-Iso, M.A. Latre, R. Béjar, P.R. Muro-Medrano F.J. Zarazaga-Soria.
“SDIGER: Experiences and identification of problems on the creation of a
transnational SDI”, View Document. Actas de las Jornadas Técnicas de la
Infraestructura de Datos Espaciales de España (JIDEE’05), Madrid (Spain),
24-25 November 2005
[4] Commission of the European Communities (CEC), 2004. 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)
[5] Official Journal (OJ) of the European Union, 2000. Directive 2000/60/EC of
the European Parliament and of the Council of 23 October 2000 establishing a
framework for Community action in the field of water policy. The EU Water
Framework Directive - integrated river basin management for Europe. L 327,
22/12/2000 pp. 0001-0073 (2000)
[6] R.A. Longhorn, “MOTIIVE Experiences Using Simulation Software to Assess
SDI Cost-Benefit”. Proc. 12th EC-GI & GIS Workshop, ESDI: From
Inspiration to Implementation, Innsbruck (Austria), June 2005

Integración de los entes locales en la IDEC. Primeros resultados y... Sesión 1
Integración de los municipios en la IDE regional. Primeros resultados y

conclusiones.
Jordi Guimet
Centro de Soporte IDEC – Institut Cartogràfic de Catalunya

Parc de Montjuic s/n, 08038 Barcelona
Tel. 567 15 00, Fax 567 15 67 e-mail: jguimet@icc.es
Resumen
La evolución del proyecto IDEC, desde sus inicios a mediados del 2002, ha conducido hacia la
aplicación de los recursos tecnológicos disponibles y de los conocimientos adquiridos en ámbitos
concretos. Las primeras formulaciones de IDE’s 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 garantir 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, otras administraciones. Conseguir que los ente 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 informació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, proyecto IDEC.LOCAL, IDE temática
I.- Escenario
El marco catalán IDE
La IDE de Cataluña fue creada en 2002. Actualmente dispone de varios servicios 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 proporcionados por 67 organizaciones y
aproximadamente 30 servicios de metadatos que describen diferentes geoservicios
proporcionados por una docena de WMS, que hacen accesibles alrededor de 150 capas de
referencia y geodatos temáticos. En estos momentos, una ley del parlamento autonómico

Sesión 1 Integración de los entes locales en la IDEC. Primeros resultados y...
reconoce la infraestructura IDEC y designa al Instituto Cartográfico de Cataluña para realizar el

desarrollo y mantenimiento de la IDEC mediante un Centro de Soporte específico.
Desde el principio, se ha adoptado la iniciativa de formar IDE’s temáticas, en la medida de lo

posible, más adaptada a las necesidades específicas de dominios concretos. Una de estas IDE
temáticas es el proyecto de IDE LOCAL, el cual supone la integración de las administraciones
locales en la IDE regional. Como IDE temática tiene su propio geoportal y servicios, siendo parte
de los recursos catalanes de IDE.
Origen
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 IDE LOCAL. Una
primera convocatoria a la participación tuvo lugar a finales 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, esperando aumentar considerablemente la participación local.
Objetivos
Objetivo general
Conseguir la plena participación de las administraciones locales (Diputaciones, Consejos

comarcales, municipios, organismos locales) en el desarrollo de la Infraestructura de Datos
Espaciales 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.
Objectivos específicos
- Elaborar inventarios, formalizados en metadatos sobre los datos disponibles y publicarlos

en el servidor de Catálogo IDEC o en otros catálogos conectados 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 metadatdos
- Definir la accesibilidad a las diferentes capas que componen dicha información,

clasificandolas como:
o De lilbre acceso
o De libre acceso con pago por utilización
o De acceso restringido
o De acceso restringido con pago por utilitzación
- Promover la utilización de las tecnologías que hacen posible la interoperabilidad,

aplicándolas a una mejor gestión y conocimiento del propio territorio, 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ública
Información disponible en activos y recursos
Situación actual de los entes locales
La situación y los recursos utilizados en la gestión (captura, mantenimiento, explotación y

difusión) de la información geospacial 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
municipio podrian permitir.
Puede apreciarse en el cuadro siguiente que aunque el tamaño del municipio tiene influencia en el
nivel de recursos disponibles, dichas diferencias no son proporcionales al tamaño, como podría
esperarse. Así, los municipios de más de 2000 habitantes 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 supliran sus carencias y
por tanto podran ser integrados en el Proyecto.
(Nota: Aunque los datos estan obtenidos de una muestra reducida se estima tienen un correcto
nivel de fiabilidad. No se incluyen Diputaciones ni Consejos Comarcales)
< 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%

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)
-…
Los municipios más grandes disponen de todos sus datos digitalizados, normalmente 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 recursos adecuados (datos, recursos
humanos y físicos) para formar parte de una geoinfraestructura, 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, siendo estos últimos los agentes participantes,
coordinando los esfuerzos, etc.
II.- 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 conllevar para los entes
locales la generación de los metadatos y la posterior publicació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-free WMS de libre
utilización). Asimismo se facilita el soporte técnico necesario para la ejecución de dichos
objetivos. Finalmente en la línea de promoción de la integración de TIC’s 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”, ente gestor de los programas de e-Gobierno.
El Consorcio AOC
E-government (e-Administración)
funds the tasks of: subvenciona:
- creating metadata
- creación de metadatos
- publishing data
- publicación de indatos
WMS en /OGC (2.000(2.000
WMS /OGC €) €)
- and
- y GIS projects
proyectos SIG closely related
relacionados con with the project
el proyecto IDE

Una segunda línea de actuación, probablemente más interesante y en línea con los planteamientos
del Consorcio AOC 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 via para la comprensión de los beneficios que comporta participar
en una red colaborativa, en la que diversos proveedores comparten sus respectivas informaciones,
enriqueciendo al conjunto y facilitando medios 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 comportar 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 desarrollados las siguientes aplicaciones:
- Visualizador de cartografia.
o Módulo totalmente personalizable mediante un simple formulario, en el que el

adminsitrador selecciona los WMS a los que quiere acceder o presentar mediante
el mismo, decide si desea alguna funció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 del anterior
- Catálogo de metadatos personalizado
o Con ayuda de un formulario similar al de la aplicación anterior, el ente local

puede configurar una interficie para acceso al catálogo IDEC, bajo una vision
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 instrucciones para realizar desde la
página web municipal una llamada única (sin filtros ni condiciones) a la lista de
metadatos generados.
- Creador de objetos geográficos
Permite, con la mera utilización del navegador, accediendo a un Cliente IDEC, y utilizando como
fondo cualquier capa de información disponible (ortofoto, topográfico, callejero....), editar objetos
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 usuados en un desktop SIG

El Centro de Soporte ofrece aplicaciones basadas en la Plataforma de

Recursos IDE :
- Visualizadores personalizados (mapas y callejeros)

- Personalización de diversos servicios (Catálogo ....)
- Herramienta de edición para la creación de geoobjetos
Las figuras siguientes ilustran los interfaces formulario, para la creación del visualizador
personalizado, y el correspondiente al editor de objetos
1.-Formulario para la generación de visualizadores y personalización del Catálogo.

Arquitectura
User’s control Viewer
Street Map
Objects edition tool Generated applications

Metadata Catalog
Intranet Viewer
Publish

Algunas de las pàginas web municipales que incorporan dichos visualizadores:
http://www.ccselva.org/ http://www.cerverapaeria.com/ http://www.ajalella.org/

http://www.infogarrotxa.com/ http://www.laroca.org/ http://www.ajmalgrat.es/
Más información en la dirección:
http://www.geoportal-idec.net/idelocal/IDECServlet?pag=noticies&home=s
La siguiente figura presenta la interficie de la aplicación para la generación de objetos

geoespaciales
2.- Generador de objetos geoespaciales
Web services W3c

Web services W3c
HTTP/POST
HTTP/POST
ÆIDEC suite WS
ÆIDEC suite WS
- XY pixels Conversion to
- XY pixels Conversion to
xy coordinates
xy coordinates
- Layers creation in the
- Layers creation in the
WMS
WMS
- Files (shape
(shape)
) download
- Files (shape) download

La última figura destaca las tecnologías aplicadas en la realización de los recursos antes descritos:
3.- Tecnologías utilizadas
Web services W3c

W3c-
-SOAP
Web services W3c-SOAP
Æ ICC GeoCodification
Æ ICC GeoCodification
Web Map Services OGC

Web Map Services OGC
Æ ICC
ÆICC
Æ Dept .Medi Ambient i Habitatge
ÆDept .Medi Ambient i Habitatge
Æ CREAF
ÆCREAF
Æ IGN
ÆIGN
Æ Cadastre
ÆCadastre
Æ LOCALRET
ÆLOCALRET
Æ Ajuntaments
ÆAjuntaments
Web Coverages Services OGC Web Features Services OGC

Web Coverages Services OGC Web Features Services OGC
III.- Resultados y conclusiones
El proyecto IDE LOCAL es visto como un instrumento para emprender proyectos 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, ...), sino también para proyectos futuros.

A finales de 2006
- 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 IDE 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 metadatos
- 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.
Primeras conclusiones
Poner en práctica el mencionado proyecto:
- No es un problema de financiación
- No es un problema tecnológico
- No es un problema de disponibilidad de datos
- No es un problema de restricción de acceso a datos
SINO: una cuestión de actitud / cultura, prioridades políticas, organización, etc.
IV.- Retos actuales

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 inicial 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 organizaciones locales, el e-
gobierno (CAOC) y varios municipios, sobre la disponibilidad 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 abierta 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 que requiere el previo registro
- información de acceso restringido, de pago, y que requier el previo registro

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 apropiados 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 proveedores. Se está trabajando en algunos desarrollos que
incluyen las tecnologías apropiadas, 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 el

siguiente:
WMS
WMS
PDP
PDP Policies
Roles
(PolicyDecision
(Policy DecisionPoint)
Point)
Viewer
Layers styles
FPS
FPS
(FeaturePortrayal
(Feature PortrayalService)
Service)
X (Firewall rules)
Municipality
Municipality
Municipality
Municipality
WFS
WFS
Municipality
Municipality
WFS
WFS ICCWFS
ICC WFS Catalonia
Municipality
Municipality
WFS
Catalonia
topographic data
WFS
topographic data
WFS
WFS

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 D.G.
Information Society and Media – European Comission Proposal for e-governemnt, que
considera estos tre elementos:
- Eficacia económica
- Democracia
- Efectividad social
Proyectos nuevos
Según se ha mencionado anteriormente, la IDE temática local será una plataforma para
desarrollar proyectos nuevos operacionales, entre ellos:
- Transacciones y proceso laboral (WFS-T): callejero (regional – gobierno local);

“utilities” (gobierno local / empresas privadas)
- E-Gobierno: Compartiendo datos con asociaciones profesionales (arquitectos,
ingenieros, ....) (gobierno local / instituciones)
- Geoportales: planeamiento urbano, turismo (regional - gobierno local)

Referencias
- Open Gis Consortium, 2002, OpenGIS Reference Model.
- General Accounting Office – USA, 2003, GIS: Challenges to Effective Data Sharing.
- Geoportal IDEC - Projecte IDEC, 2002, Dossiers de presentació v.1 & 2003, Dossiers de
presentació v.2.
- Guimet, J., 2004, Thematic SDI’s: a way to spread out the benefits of interoperability and to
enhance the development of Regional SDI’s, proceedings, 10th EC-GIS workshop.
- Guimet, J., 2005, Spatial Data Infrastructures, a new paradigm within the domain of Geospatial
information. The example of the catalan SDI Project (IDEC) http://www.geoportal-
idec.net/geoportal/eng/pdf/ide_nouparadigma.pdf
- Guimet, J., 2005, SDI Catalonia: A Regional Approach, Global Magazine for Geomatics, June
2005, Volume 19, Issue 6
http://www.giminternational.com/v_gim/archives/chapter_content.asp?v0=detail&v1=486

SESIÓN 2
METADATOS
65
Metadatos: Extracción y derivación automática de atributos. Sesión 2
El papel de Dublin Core en el desarrollo de las

Infraestructuras de Datos Espaciales
Zarazaga-Soria, F. J.†, Nogueras-Iso, J. †, Méndez-Rodríguez, E. ‡
Tolosana-Calasanz, R. †, Muro-Medrano, P. R.†
† Departamento de Informática e Ingeniería de Sistemas

Tlf: 976 762 134 Fax: 976 761 914. e-mail: iaaa@unizar.es
‡ Departamento de Biblioteconomía y Documentación

Universidad Carlos III de Madrid, Madrid, 128, 28903 Getafe (Madrid)
Tlf: 916 248 620. Fax: 916 249 212. e-mail: emendez@bib.uc3m.es
Resumen
Las tendencias actuales de caracterización de recursos de información geográfica

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 queda
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
servicios 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,
fomentando la interoperabilidad en distintos dominios informativos, entre ellos
también la información geoespacial. El objetivo de este artículo 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 contexto 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 modelo general propuesto..
Palabras clave: Metadatos, Dublin Core, Interoperabilidad.

Sesión 2 Metadatos: Extracción y derivación automática de atributos.
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, modelos 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
sustenta 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 geográfica había venido trabajando con la información geográfica,
mientras que la información geo-referenciada es mucho más amplia en al incluir las
cosas tales como las fotografías, los videos, la música y la literatura que se 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
descripción o caracterización de recursos, adecuada, completa y suficiente.
El resto del artículo 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 artículo termina con un apartado de
conclusiones.
2 Estándares de metadatos en IDEs

Dos son los grandes contribuidores en el ámbito de la estandarización en IDEs: el
grupo 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 capabilities 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 conjunto
de interfaces de servicios que soportan la funcionalidad de descubrimiento
(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 protocolo de
conexión documentando las decisiones de implementación y seleccionando 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
metadatos 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 establecen
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 propuestos por
Dublin Core. De manera análoga, a la hora de devolver los resultados, se indica
que las respuestas seguirán un modelo análogo al propuesto por Dublin Core.
No obstante, en ninguno de los dos casos se establece 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
servicios. Los dos mayores handicaps con el que se tropieza vienen de la mano
de la mezcla de estándares y, fundamentalmente, de la no disponibilidad 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 conoce 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 encuentra
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 Service, 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
intercambiar información electrónica, independientemente del dominio científico o
disciplinar. En sus orígenes (marzo 1995), el DC surge como un modelo de
metadatos 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 motores 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 protocolo OAI-PMH [6], pero también a la versatilidad del esquema y al
nivel de estandarizació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
definició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, siendo
muy pocos los que alcanzan en nivel de reconocimiento como estándar formal
(de iure) 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 norma UNE a lo largo de
este año.
• Es un estándar simple y fácil de entender y usar, cuya codificación es
independiente 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 ligados
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 un contexto de aplicación disciplinar o dominio
particular (p. ej.: 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 metadatos de propósito general, aplicable a
distintas disciplinas, distintos objetos de información digital o en distintos
repositorios o colecciones digitales.
• La simplicidad del DC, no va en detrimento de su especificidad, ya que se
puede usar con diferentes matizaciones, vocabularios o schemes (Dublin Core
Terms [9] y establecer perfiles de aplicación específicos para un dominio
informativo particular.

• Hoy en día es un formato ampliamente aceptado con grandes usos y

aplicaciones en todo el mundo. Por ejemplo es el formato adoptado por
mútipes programas y proyectos de e-government en Australia, Canadá,
Dinamarca, Finlandia, Irlanda, Nueva Zelanda y Reino Unido o para proyectos
supranacionales como la Red Europea EUKN (European 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 (ej., Conexión OCLC, DCPS, ContentDM, Metabrowser,…).
3.2 Nuevas posibilidades funcionales
Imaginemos un escenario con tres sistemas de información distintos que cumplen

cada uno de ellos su objetivo concreto sobre la base de caracterizar la información
utilizando estándares internacionales: una biblioteca “en línea” que posibilita el
acceso a libros digitales, informes y otras publicaciones, todas ellas caracterizadas
utilizando como estándar MARC [10]; un servidor de información de eventos
culturales de un ciudad y cuyo modelo base es Dublin Core; y finalmente una IDE.
Suponiendo que cada uno de estos servicios permitiese el acceso a sus
funcionalidades de búsqueda por terceros sistemas de información, sería posible
desarrollar 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 informació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 de entender y hacer que los demás entienda la información que se
intercambia. 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 suma
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
informaciones de interés. De esta manera, informaciones tabulares de censos,
informes electrónicos (en formato pdf, html, ps, …) 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 servicios de
Nomenclator 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 las zonas fundamentales en las 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.
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
(algunas 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 dominio de información particular, o a través del mapeo de
elementos con otros esquemas 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.
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
propietarios. 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
porque 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
suficientemente 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
funcionamiento cumpliesen dicha especificación.
Servicios de nombres (servicio de nomenclator, 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 Nomenclator” 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
incorporación de nuevos datos y servicios que en la actualidad no se encuentran
presentas, 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 servicios de éstos.
Ya se están poniendo en marcha iniciativas destinadas a aprovechar Dublin Core
como pivote sobre el que hacer girar los contenidos de información y la tecnología
y servicios de una IDE construidos sobre esta base. Patrimonio Industrial y
Patrimonio Paleontológico son dos áreas de gran interés en las cuales se están
dando los primeros pasos.
Agradecimientos
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.)",
The April 13,1994, Edition of the Federal Register.
[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, Spain, 24-
25 Noviembre 2005

[3] M. F. Goodchild, "The Geolibrary". Innovations in GIS 5, ed. 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, Dec. 2000, vol. 6, nº 12.
[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, pag. 84
[9] DCMI Metadata Terms (Junio 2005): http://dublincore.org/documents/dcmi-
terms/
[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”, Aceptado para su publicación en
International Journal of Metadata, Semantics and Ontologies (IJMS&O),
2006
[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), pag. 611 - 634
[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, ESDI Setting the Framework. Alghero(Italia),June 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).
ISBN 972-8093-13-6, Mayo 2005
[16] ISO 19112. “Geographic information -- Spatial referencing by geographic
identifiers” International Organization for Standardization (ISO), 2003

El papel de Dublin Core en el desarrollo de las Infraestructuras de... Sesión 2
Metadatos para Capas y Series Cartográficas.

Modelo de Herencia de Metadatos
A. Zabala†, X. Pons†,‡, J. Masó‡.
† Departament de Geografia.
Universitat Autònoma de Barcelona
Facultat de Filosofia i Lletres. Edifici B. 08193, Cerdanyola del Vallès
Tlf: 935.811.527. Fax: 935.812.001. e-mail: alaitz.zabala@uab.cat
xavier.pons@uab.cat
‡ Centre de Recerca Ecològica i Aplicacions Forestals

Edifici C.08193, Cerdanyola del Vallès
Tlf: 935.811.312. Fax: 935.814.151. e-mail: joan.maso@uab.cat
Resumen
Esta comunicación describe una implementación del modelo relacionar los

metadatos de diferentes niveles jerárquicos (serie y capa) definiendo relaciones de
herencia que posibilita definir de manera consistente y sin redundancias los
metadatos de productos complejos. Esta implementación ha sido aplicada a la 3a
edición completa del Mapa Topográfico 1:5 000 del Instituto Cartográfico de
Catalunya.
Palabras clave: Metadatos, ISO19115, niveles jerárquicos, herencia
1 Introducción
Los metadatos pueden referirse a diferentes niveles jerárquicos de los datos
geográficos. El estándar ISO 19115 [1] reconoce diferentes niveles jerárquicos de
la información geográfica como son: serie, conjunto de datos, hoja, modelo, objeto,
atributo, servicio,…. Además, el estándar ISO 19115 reconoce que potencialmente
existen muchos metadatos “reutilizables” al implementar una colección de
metadatos. Al crear diferentes niveles de descripción, los vínculos jerárquicos

Sesión 2 El papel de Dublin Core en el desarrollo de las Infraestructuras de...
permiten la reutilización así como las búsquedas filtradas según el nivel de

abstracción deseado. En una implementación jerárquica, los metadatos generales
pueden ser heredados por los metadatos de niveles jerárquicos inferiores que, en
caso necesario, sobrescriben o se añaden al valor general evitando la necesidad de
muchas copias de muchos campos de los metadatos.
MiraMon es el software de sistema de información geográfica que se elabora

enteramente en el CREAF. El “Gestor de Metadatos de MiraMon” (GeMM) es la
herramienta de gestión de metadatos y relaciones entre tablas alfanuméricas de
datos de MiraMon. Desde su primera versión el GeMM ha permitido documentar
los metadatos de capas de cualquiera de los formatos soportados por MiraMon. El
primer documento de análisis y diseño del GeMM (2002) [2] ya consideraba la
descripción de metadatos a nivel de capa y de serie. Esta posibilidad junto con la
definida en el estándar ISO 19115 son las que se concretan en el modelo extendido
ahora presentado.
2 Objetivos
El objetivo es desarrollar un modelo que permita definir de manera sólida y sin
redundancias los metadatos de productos complejos como por ejemplo una edición
de un Mapa Topográfico completo.
Modelización de la realidad
Capas de información
Usos del suelo

Realidad
Parcelas
Límites administrativos
Ríos
Topografía
Edificios
Figura 1. Ejemplo de algunas componentes temáticas de un mapa topográfico

Un Mapa Topográfico contiene diversas componentes temáticas o capas para

representar algunos objetos de la realidad, por ejemplo: ríos, parcelas, curvas de
nivel, carreteras, ferrocarril, edificios, etc. (ver figura 1). Algunos de los metadatos
de las diferentes capas que forman el mapa topográfico son comunes a todos los
mapas, por ejemplo parte del título (“Mapa topográfico”) o la escala equivalente.
Tradicionalmente, a causa de la necesidad de manejo de la cartografía en papel,

cada una de estas capas se suele dividir en fragmentos siguiendo una estructura
regular que divide el territorio en diversas hojas usando un Corte Cartográfico
(generalmente el corte publicado por el organismo encargado de generar la
cartografía oficial de un territorio, ver figura 2). Esta división se mantiene
generalmente en la distribución de cartografía digital oficial.
Figura 2. Ejemplo de división en hojas (1:5 000) de un mapa topográfico

3 Definición del modelo

3.1 Niveles jerárquicos considerados
Aunque el estándar ISO19115 permite a priori cualquier relación de jerarquía entre

niveles, por razones practicas de implementación, el modelo se ha restringido a la
definición de 4 niveles. Estos niveles encajan perfectamente con la implementación
necesaria para el Mapa Topográfico donde se pueden distinguir diferentes
conjuntos de datos (datasets) que requieren metadatos diferentes y diferentes
herencias entre ellos (ver figura 3).
Multiserie
Serie Hoja de la Serie
Capa-Hoja
Figura 3. Esquema de los niveles jerárquicos considerados en el modelo
La Capa-Hoja es el nivel jerárquico inferior y se corresponde en este modelo con

cada una de las componentes temáticas para una hoja concreta, por ejemplo la
hidrografía de la hoja 289-127: Barcelona - Montjuïc del Mapa Topográfico
1:5 000 del Instituto Cartográfico de Catalunya (ICC).
La Serie es el concepto de serie tradicional en cartografía. Agrupa y describe

aquellas capas de un tema y fecha (versión) determinados, que por su extensión
espacial son poco prácticas en una sola pieza (ficheros demasiados grandes) y, por
lo tanto, se ‘cortan’ en varias hojas o Capas-Hoja (típicamente siguiendo cortes

cartográficos más o menos normalizados. Por ejemplo la Serie hidrografía Mapa

Topográfico 1:5 000 del Instituto Cartográfico de Catalunya (ICC) está formada
por las diversas capas-hojas de hidrografía que siguen el corte del MTN 1:5 000 del
IGN).
La Hoja, u Hoja de serie, esta formada por las diferentes capas temáticas para un
fragmento concreto del corte cartográfico en hojas y fecha (versión) concreta. Así,
por ejemplo todas las capas del topográfico 1:5 000 para una hoja (unidad espacial)
determinada forman la “Hoja de serie”.
Finalmente, la Multiserie es el conjunto de Capas-Hoja de todas las Series y para

todas las Hojas, por ejemplo todo el Topográfico 1:50 000 de una cierta versión.
Es importante destacar la importancia de los Cortes Cartográficos en este modelo.

Generalmente las diversas Multiseries se basan en unos pocos cortes cartográficos
rígidamente definidos por los organismos productores de cartografía que, además,
tienen características propias y definidas para cada fragmento del corte (para cada
Hoja) que se pueden propagar a las diversas Capas-Hojas, por ejemplo las diversas
codificaciones o el nombre de una hoja. Los Cortes Cartográficos son un tipo
concreto de Capas-Hojas en las que los objetos que las forman (de tipo polígono)
definen los límites de corte de las diversas Series de una Multiserie. Habitualmente
esta distribución espacial sigue una retícula cuadrada pero puede usarse otro tipo de
límites poligonales, por ejemplo una división administrativa.
La descripción de metadatos a nivel de objeto o de atributo está prevista en la ISO

19115 pero no es contemplada en este modelo al no resultar necesaria en las
implementaciones previstas.
3.2 Descripción del nivel jerárquico
a) Opciones de ISO 19115: El estándar de metadatos ISO 19115 [1] tiene un

miembro “hierarchyLevel”, Nivel jerárquico del conjunto de los datos (traducción
del NEM [3]), que se describe seleccionando uno de los valores de la lista
controlada MD_ScopeCode: serie, conjunto de datos, hoja, modelo, objeto,
atributo, servicio,… De los cuatro tipos de conjuntos de datos definidos (ver
apartado anterior), tres de ellos corresponden al nivel jerárquico de serie (Serie,
Hoja de Serie y Multiserie) y el último (Capa-hoja) corresponde al nivel jerárquico
de conjunto de datos.

b) Particularidades del modelo desarrollado: Usando tan sólo el miembro

“hierarchyLevel” no es posible diferenciar entre los tres tipos diferentes de Serie ni
entre una Capa-Hoja normal y una que es, además, un Corte Cartográfico. Para ello
usamos el miembro “hierarchyLevelName” de ISO 19115, Nombre del Nivel
Jerárquico, para poder diferenciarlos. Este miembro de los metadatos se describe,
en el estándar, mediante una cadena de texto libre. Nuestro modelo utiliza algunos
‘valores especiales’ para indicar el tipo de serie o de capa.
3.2 Descripción de las relaciones con otros niveles jerárquicos
a) Opciones de ISO 19115: Una vez establecidos los tipos de series y capas,
debemos fijar cómo definir para un conjunto de metadatos sus relaciones con otros
conjuntos de metadatos. El estándar nos ofrece dos vías para definir estas
relaciones: el miembro Identificador del padre “parentIdentifier” y la sección
Información de agregación “aggregateInfo”. El primero se utiliza para identificar
el conjunto de metadatos del cual el conjunto de metadatos forma parte. Sólo es
posible definir un parentIdentifier. En segundo lugar la sección “aggregateInfo”
aporta información sobre la agregación de datos (no de metadatos). Se pueden
definir diversas agregaciones para un mismo conjunto de metadatos.
b) Particularidades del modelo desarrollado: En el modelo se usará

“parentIdentifier” para referirnos directamente a la Multiserie desde los metadatos
de la Capa-Hoja, la Serie y las Hojas de Serie. Desde la Capa-Hoja se usaran dos
ocurrencias de la sección “aggregateInfo” para referir a qué Serie y Hoja de Serie
pertenece esa Capa-Hoja. La información de agregación que describe la Serie se
identifica por tener un valor para el miembro Código del tipo de asociación igual
a “Parte de una Base de Datos Continua” y una marca activada (propia, que amplia
el estándar) para diferenciarla de las diferentes agregaciones con el mismo tipo de
asociación (ver figura 4). La información de agregación que describe la Hoja de
Serie se marca con un tipo de asociación igual a “Mención del trabajo principal” y
una marca propia activada.

Figura 4. Descripción de la Serie de la que forma parte la Capa-Hoja
Desde los metadatos de la Hoja de Serie también se usa la sección “aggregateInfo”

para referir a qué corte cartográfico corresponde esta Hoja de Serie. La información
de agregación que describe el Corte Cartográfico des de la Hoja de Serie se
identifica por tener un valor para el miembro Código del tipo de asociación igual a
“Mención del trabajo principal” y una marca propia activada.
4 Herencia de metadatos
En el momento que una capa se define como hija de alguno (o todos) los niveles
superiores definidos (tipos de serie), los valores de los metadatos de esta Capa-
Hoja participan de diversos tipos de herencia jerárquica dependiendo del campo de
metadatos del que se trate. Así, pueden quedar fijados, heredados (pero ampliables)
o sugeridos (heredables o no) por los niveles jerárquicos superiores según un
conjunto de reglas de herencia descrito en esta comunicación.
4.1 Metadatos de los diversos niveles
La Serie contiene los metadatos que aplican de forma general a todas las Capas-
Hoja que la forman, como por ejemplo una parte del título, información sobre
cómo se capturan los datos (linaje), fecha general temática, calidad general o
relaciones con las bases de datos (típicamente tablas que actúan de diccionario).
Los metadatos comunes a todas las Capas-Hoja que forman parte de cada Hoja de
Series se extraen de dos ubicaciones diferentes: el corte cartográfico y el fichero de
metadatos de la Hoja de serie. Algunos de estos metadatos dependen estrictamente
del Corte cartográfico y por lo tanto se extraen de él, por ejemplo las diversas
codificaciones de la Hoja o el nombre de la misma. La Hoja de Serie y la Capa-
Hoja pueden heredar estos metadatos desde el Corte Cartográfico. En cambio otros
metadatos están relacionados con esa Hoja de Series des del punto de vista de la

Multiserie de la que forman parte, como por ejemplo la empresa o la fecha del
vuelo fotogramétrico a partir del que se han restituido las diversas informaciones
de esa Hoja del topográfico. Estos metadatos se guardan en el nivel jerárquico de la
Hoja de Series y pueden ser heredados por la Capa-Hoja.
Los metadatos comunes al nivel jerárquico de Multiserie son, por ejemplo, parte
del título (“Mapa topográfico”), la escala equivalente, etc.
4.2 Tipos de Herencia de Metadatos
Se utilizan diversos tipos de herencia entre los niveles jerárquicos:

a) Sin herencia: Algunas entradas de metadatos tienen sentido por ellas mismas en
todos los niveles jerárquicos y no se define ninguna regla de herencia entre ellas.
Ejemplo: Identificador del fichero de metadatos, Nivel jerárquico, Fecha de
creación de los metadatos.
b) Herencia obligada: Para algunas entradas de metadatos, si el nivel jerárquico

superior define el valor de una entrada de metadatos, los niveles jerárquicos
inferiores han de tomar obligatoriamente ese valor. Ejemplo: Sistema de referencia
horizontal (ver figura 5).
Figura 5. Herencia obligada de entradas de metadatos
c) Herencia ampliable: Para algunas entradas de metadatos, de número de

ocurrencias N, los valores definidos por los niveles jerárquicos superiores deben
ser asumidos por el nivel jerárquico inferior que, a su vez, puede definir valores
adicionales. Ejemplo: Idioma de los metadatos, Organismos relacionados con los
metadatos (ver figura 6), Título alternativo.

Figura 6. Herencia ampliable de entradas de metadatos
d) Herencia particularizada: Para algunas entradas de metadatos, los valores

definidos por los niveles jerárquicos superiores pueden ser asumidos o modificados
por el nivel jerárquico inferior que, en cambio, no puede considerarlos indefinidos.
Así, los niveles jerárquicos superiores definen valores generales que aplican a
todos los niveles jerárquicos inferiores que, a su vez, pueden definir valores
particulares. Ejemplo: Escala Equivalente (ver figura 7), Parámetros de calidad.
Figura 7. Herencia particularizada de entradas de metadatos
e) Herencia combinada: Para algunas entradas de metadatos, típicamente de texto

libre, se ha diseñado un modo de combinación de manera que el valor de la entrada
de metadatos para un nivel jerárquico concreto se obtiene a partir del valor de los
otros niveles más un complemento de ese nivel. Por ejemplo, para una capa se
puede definir que el Título esté formado por el título de la Multiserie, seguido de
guión, el título de la Serie, otro guión, y el código y topónimo de la Hoja de Serie.
Esto se codifica usando un patrón del estilo: “*Multiserie:Titulo* – *Serie:Titulo*
– Hoja *Corte:CodigoHoja* : *Corte:ToponimoHoja*” donde los literales entre
asteriscos indican que se debe tomar el contenido del metadato y nivel jerárquico
indicado. El resultado del título resultante para una Capa-Hoja concreta seria, por
ejemplo: “Topográfico 1:5 000, v. 3, ICC – Caminos y senderos – Hoja 286-124 :
Sant Bartomeu de la Quadra”, donde “Topográfico 1:5 000, v. 3, ICC” es el título
de la Multiserie, “Caminos y senderos” el título de la Serie y “286-124” y “Sant
Bartomeu de la Quadra” el código y topónimo de la Hoja de Series,
respectivamente.

5 Mapa Topográfico 1:5 000 del Instituto Cartográfico de

Catalunya
Gracias al acuerdo firmado en enero de 2006 entre el Instituto Cartográfico de
Cataluña (ICC) y el CREAF toda la cartografía oficial de Cataluña producida por el
ICC (mapas topográficos 1:50 000 y 1:5 000, ortofotos 1:25 000 y 1:5 000, etc.)
estará disponible este año en formato MiraMon.
En estas distribuciones se usa el modelo de metadatos presentado. El Mapa

Topográfico 1:5 000 v.2.0 [4] y [5] es una Multiserie formada por 28 Series y
4.273 Hojas de Serie, con un total de mas de 75.000 Capas-Hojas (no todas las
Series son necesarias en todas las Hojas de Serie).
6 Conclusiones
Este desarrollo permite definir de una manera consistente y sin redundancias los
metadatos de productos complejos como por ejemplo una edición de un Mapa
Topográfico completo. También permite exportar un conjunto completo de
metadatos para cualquier nivel jerárquico siguiendo las reglas de herencia. Futuras
versiones del modelo, podrían contemplar otros tipos de series como la temporal o
metadatos a niveles jerárquicos inferiores como objetos y atributos.
Referencias
[1] International Organization for Standardization, “International Standard:
Geographic information – Metadata. ISO 19115:2003”, ISO TC 211, 2003.
[2] Valentín, A., X. Pons, “El Gestor de Metadades de MiraMon (GeMM 1.0)”,
Documento interno de trabajo del grupo MiraMon, 2000.
[3] Subgrupo de Trabajo del Núcleo Español de Metadatos, “Núcleo Español de
Metadatos (NEM v1.0)”, 2005
[4] Institut Cartogràfic de Catalunya, “Especificacions tècniques ICC: 1:5 000 :
BT-5M v2.0”, Generalitat de Catalunya. Barcelona, 2001
[5] Institut Cartogràfic de Catalunya, “Diccionari de Dades de la Base
topogràfica 1:5 000 v2.0 (BT-5M)”, Generalitat de Catalunya. Barcelona,
2001

Metadatos para Capas y Series Cartográcas. Modelo de Herencia de... Sesión 2
METADATOS: EXTRACCIÓN Y DERIVACIÓN AUTOMÁTICA

DE ATRIBUTOS.
MANSO CALLEJO, M.A.

BERNABÉ POVEDA, M.A.
Universidad Politénica de Madrid, ETSI en Topografía, Geodesia y Cartografía: Grupo Mercator
Autovía de Valencia Km 7, 28031 Madrid (España)
m.manso@upm.es
ma.bernabe@upm.es
RESUMEN
Para que una Infraestructuras de Datos Espaciales sea útil a una amplia comunidad de
usuarios es necesario que existan catálogos o repositorios sobre los que poder realizar
búsquedas o consultas relacionadas con información geográfica (I.G.) o con servicios Web
que se apoyan en la I.G.. Para que los usuarios puedan realizar consultas simples o complejas,
los catálogos deben de contener un inventario bien detallado de los productos y servicios
ofrecidos por quien produce los datos, distribuye los productos o presta dichos servicios. Esta
descripción detallada de productos o servicios son los Metadatos.
Uno de los componentes fundamentales de las IDES son los estándares, que actúan
como mecanismos reguladores, cuyo objetivo es garantizar la interoperabilidad entre sistemas
y aplicaciones. En el contexto de los Metadatos de productos el estándar Internacional
ISO19115-2003 ha sido asumido por la Agencia Española de Normalización (AENOR)
como estándar de metadatos para la I.G. Éste documento recoge de una manera formal los
nombres de los atributos que pueden formar parte de un registro de Metadatos y sus
significados.
ISO19115-2003 define aproximadamente 400 atributos organizados en clases y tipos
de datos que cubren todas las facetas previstas para los metadatos: identificación, información
espacial, sistemas de referencia espacial, calidad, distribución, aplicación y la referencia al
propio estándar de metadatos usado en la descripción. ISO19115-2003 define cuales de los
atributos son obligatorios, cuales son optativos y cuales están condicionados en función del
tipo de I.G. que se esté describiendo. De esa enorme colección de metadatos, los países,
regiones, comunidades y organizaciones pueden definir libremente subconjuntos (llamados
perfiles o plantillas) de metadatos, más simples o más elaboradas, en función de sus
necesidades. Este es el caso del Núcleo Español de Metadatos (NEM).
Independientemente de que las organizaciones utilicen el estándar completo o perfiles

de metadatos, lo cierto es que el número de atributos que se deben cumplimentar para
completar un registro de metadatos es elevado. Este hecho incrementa los costes económicos
derivados del tiempo destinado a crear los metadatos. La administración, agencia o compañía
que desee poner en marcha una IDE debe prever por tanto, recursos económicos iniciales para
la creación de metadatos y debería prever también recursos humanos con conocimientos
avanzados en el dominio del conocimiento (I.G.) que permitan crear metadatos de una forma
manual y supervisada y mantener actualizados dichos metadatos.

Sesión 2 Metadatos para Capas y Series Cartográcas. Modelo de Herencia de...
Desde un punto de vista práctico, la creación de metadatos es un proceso lento,

meticuloso, sistemático y no libre de errores. En la mayoría de los casos la información que se
debe describir es digital y es necesario disponer de aplicaciones informáticas que puedan
visualizar los datos, acceder a los atributos que deben de ser almacenados como atributos en
el registro de metadatos, realizar transformaciones de coordenadas, interpretar los Sistemas de
Referencia por Coordenadas usados, etc… A estas actividades se ha de añadir la búsqueda de
información relativa a la razón por la que se generó el conjunto de datos, el pliego de
prescripciones técnicas al que debería ajustarse el producto, los resultados de los controles de
calidad aplicados a los productos, los procesos de revisión y mantenimiento previstos, etc…
El personal especializado en la creación de metadatos, debe destilar toda esta información
para trasladarla de forma legible y estructurada sobre un documento de texto utilizando un
lenguaje de marcas (XML) o haciendo uso de una aplicación informática de edición.
Estos trabajos de edición de metadatos no están libres de errores. En unos casos los
errores son meramente mecanográficos (olvidar un separador decimal, cambiar de lugar la
coma), en otros casos los errores son por conmutación de valores entre atributos duales
(ancho-alto, este-oeste, norte-sur) y finalmente también se pueden interpretar erróneamente
los Sistemas de Coordenadas y como consecuencia las transformaciones de coordenadas
serán erróneas. Los errores mencionados ocurren tanto en los documentos en papel como en
los documentos digitales ya que en ambos casos han de buscarse los datos y transcribirlos
sobre la herramienta de edición de metadatos.
Desde el punto de vista productivo, otro aspecto importante es el tiempo que utiliza un
operador y por lo tanto, el coste económico que supone utilizar una herramienta informática
para abrir el documento digital que se está describiendo, leer los datos necesarios, trascribirlos
sobre el editor de metadatos y procesar algunos cálculos (transformación de coordenadas).
El resto del documento se estructura de la siguiente forma:
Se presenta un estudio realizado sobre los errores tipográficos cometidos en la edición

manual de metadatos en lo referente a las extensiones geográficas y los Sistemas de
Referencia por Coordenadas.
Se presenta un estudio realizado para determinar el tiempo, y por tanto coste de

operador, ocupado en la recuperación de los atributos de la I.G. almacenados en los propios
soportes digitales de almacenamiento.
En tercer y último lugar se presenta un estudio en el que se comparan y cuantifican los

atributos de la I.G. almacenados en los archivos o bases de datos desde un punto de vista
teórico de formato de archivo, con los datos que pueden extraerse usando herramientas
informáticas de distintos tipos (ArcCatalog, Gdal/OGR, otras de desarrollo propio).
Para finalizar el documento se presentan las conclusiones, los agradecimientos y las

referencias bibliográficas.

Metadatos de teledetección. El día después. Sesión 2
METADATOS DE TELEDETECCIÓN.
EL DÍA DESPUÉS
AMARO CORMENZANA, ALBERTO*,
PRADO ORTEGA, ELENA*,
JIMENEZ MICHAVILA, MARCOS*.
* ÁREA DE TELEDETECCIÓN
(INSTITUTO NACIONAL DE TÉCNICA AEROESPACIAL I.NT.A)
Ctra de Ajalvir s/n. Torrejón de Ardoz (Madrid)
amaroca@inta.es, jimenezm@inta.es, pradooe@inta.es
Resumen
La presentación tiene como objetivo mostrar el estado actual de acceso a los

metadatos de Teledetección tanto por parte de los usuarios, como de las
aplicaciones. Una situación que, en principio, no variará mucho en el momento en
que aparezca la publicación definitiva de la especificación ISO19139, prevista para
este año 2006.
Desde hace unos años, se encuentran definidas claramente las recomendaciones de

la directiva INSPIRE y las líneas de trabajo que vienen marcadas por el entorno de
la normativa ISO aplicable a los metadatos de información geográfica. En España,
impulsados por el Consejo Superior Geográfico y sus grupos de trabajo, han ido
apareciendo muchos proyectos, catálogos e IDE's en los que el contenido de
información fundamental se basa en entornos GIS.
En el campo de la Teledetección, aunque muchos datos se pueden tratar

directamente de acuerdo con las recomendaciones del Nucleo Español de
Metadatos (NEM), y por tanto ajustándose a la recomendación mínima aplicable,
nos encontramos con información específica que no encaja fácilmente en los
metadatos que nos ofrece esta recomendación y tampoco en la norma principal: la
ISO19115 que define todos los metadatos de información geográfica disponibles.
El día después lo marcará la publicación definitiva de la especificación técnica

ISO19139, que contendrá la definición del esquema XML. En ese momento, el
esquema de validación de ficheros XML será aceptado y servirá para discernir la
información que se ajusta a los requisitos de interoperabilidad.

Sesión 2 Metadatos de teledetección. El día después.
Con independencia del formato interno que se utilice en los catálogos, si se quiere
que la información que acompaña a las imágenes de teledetección sea fácilmente
interpretable y localizable, deberá ajustarse a estos estándares. Esto garantizará la
posibilidad de intercambiar datos entre usuarios, organismos y aplicaciones
diferentes, es decir, cumplir los principios básicos de INSPIRE y un ahorro
evidente de documentación adicional.
La intención de esta presentación es mostrar las dificultades encontradas y las

soluciones adoptadas en el Área de Teledetección del INTA, donde se lleva
trabajando varios años con los sucesivos borradores de la norma ISO19139 para
preparar ficheros XML y con la norma ISO19115 para localizar los metadatos más
apropiados:
1) Dificultad de ubicación de algunos datos en los metadatos de la ISO19115.

2) Definición de extensiones a la norma.
3) Presentación y visualización de los metadatos.
Con respecto al último punto, la visualización de los ficheros XML, de acuerdo con
los comentarios que recibimos por parte de los usuarios, es un concepto crítico que
también podrá empezar a resolverse a partir de la aparición de la norma ISO19139.
Los usuarios necesitan localizar la información en extensos y complicados ficheros
XML, por lo que el lenguaje de hojas de estilo para XML y sus transformaciones,
que simplifican la apariencia de los metadatos, pronto se convertirán en un
requerimiento común.
También es importante comentar el estado actual de las aplicaciones disponibles

para el tratamiento de imágenes de Teledetección, esencialmente en su adaptación a
la normativa ISO. Así como citar la disparidad entre los formatos de imágenes de
satélites que, evidentemente, dificulta la consecución de criterios de
interoperabilidad.
A modo de conclusión, la identificación de los aspectos propios de la

Teledetección que necesitan un enfoque diferente, así como la aportación de todos
los profesionales especializados en este campo, señalan el camino que hay que
recorrer a partir del momento en que la especificación ISO19139 se convierta en el
documento válido para conectar a los usuarios con la información o viceversa.
Palabras clave: IDEE, metadatos, teledeteccion, sensor hiperespectral, XML

1 INTRODUCCIÓN
El impulso que durante estos últimos años ha recibido el tratamiento e
incorporación de metadatos a la información geográfica se entiende a partir del
desarrollo de la iniciativa de la Comisión Europea INSPIRE [1] (Infraestructure for
Spatial Information in Europe). Esta recomendación intenta agrupar a todos los
órganos implicados en esta área de trabajo para conseguir alcanzar un objetivo
fundamental: la interoperabilidad de la información, es decir, facilitar el
intercambio de diferentes tipos de datos entre diferentes organismos, usuarios y
aplicaciones.
Para conseguir estos objetivos se utilizan, entre otros mecanismos, las normas ISO
relacionadas con la información geográfica generadas por el grupo de trabajo
TC211 [2].
Hay dos normas que constituyen la referencia principal: la ISO19115 "Metadatos
de Información Geográfica" y la ISO19139 "Implementación del Esquema XML",
y a partir de ellas se accede a un elevado número de normas adicionales.
El objetivo de la interoperabilidad requiere facilitar que todos los usuarios y/o

aplicaciones conozcan cómo llegar a los datos. Y para que esto se pueda llevar a
cabo es necesario especificar cómo se debe presentar y guardar la información (los
metadatos). De modo que sea posible acceder a un campo de información
simplemente conociendo cual es la posición exacta en la que se guarda dentro de
un fichero de metadatos.
El formato que se utiliza para guardar los metadatos es, por su idoneidad y
universalidad, el XML (Extensible Markup Language). Un formato que ya se
estaba utilizando en otras aplicaciones (muchas de ellas relacionadas con la
transmisión de información por la red), y que permite, por su estructura
jerarquizada, la distribución de los metadatos en entidades o agrupaciones de
elementos.
Es la norma ISO19115 la que se encarga de definir hasta 409 metadatos y su
jerarquía, pero no hace referencia al modo en el que se deben presentar los
metadatos.
Para resolver cual es el formato más adecuado, el TC211 ha desarrollado otra
norma, la ISO19139, que referencia un esquema completo de los metadatos
especificados en la ISO19115 y define cómo debe hacerse la creación y validación
de ficheros con formato XML para garantizar la normalización entre las fuentes de

datos. Actualmente esta norma es un borrador pero su publicación definitiva se

producirá durante el año 2006.
Todo este esfuerzo, permitiría resolver la unificación de formatos de modo local,

cada organismo puede hacer un esfuerzo de adaptación a un formato único de
metadatos en XML, pero es necesario cubrir otro requisito de INSPIRE: el acceso y
la localización de la información.
En esta línea de distribución, catalogación e intercambio de información a través de
Internet, tiene un papel fundamental el consorcio de empresas y organizaciones
OpenGis [3].
Durante los últimos años se han publicado recomendaciones que, por su aceptación
general, se convierten casi en estándares, para definir cómo deben ser los servicios
web de intercambio de información a través de Internet.
Por ejemplo, están plenamente extendidos, el WMS (servicio web de mapas), WFS
(servicio web de "features") o el WCS (servicio web de catálogo).
Estos son los puntos fundamentales que están permitiendo la proliferación de IDE's
(Infraestructuras de Datos Espaciales) y son la base para entender y trabajar por la
interoperabilidad.
Sin embargo, detrás de todos estos esfuerzos, ha existido habitualmente una
filosofía más próxima al mundo GIS, de datos vectoriales y se ha contemplado la
información procedente de la teledetección, como información auxiliar, como una
capa de información adicional.
En el Área de Teledetección del Instituto Nacional de Técnica Aeroespacial

(I.N.T.A.) se lleva trabajando desde finales del 2003 con la idea de adaptar la
información a estos estándares y recomendaciones comentados previamente. Se
han encontrado muchas dificultades y es, en cierta medida, el objetivo de esta
presentación, comentarlas.
La publicacion de la especificación ISO19139 permitirá validar los ficheros XML

que prentendan adaptarse a la normativa ISO19115.
Dicho de un modo más sencillo, si un fichero de metadatos no pasa el esquema
definido en la ISO19139, significa que su información no es accesible para otras
aplicaciones y/o usuarios. Es decir, seguirá siendo un formato local, no
interoperable.
Como ya se ha comentado previamente, la publicación de esta especificación

ISO19139, está prevista antes de que acabe 2006. Y ese momento representará el

punto de inicio de un trabajo muy laborioso para adaptar los catálogos, formatos y
aplicaciones al esquema XML.
La pregunta es: ¿cuál es la capacidad de adaptación a estos cambios en el ámbito de

la teledetección en España ?
En este artículo se presentan los pasos que ya se han dado en el INTA, las
dificultades encontradas y, a modo de conclusión, algunas de las medidas
necesarias para alcanzar la interoperabilidad en el ámbito de la teledetección.
2 Incorporación de información específica de teledetección a

los metadatos definidos en la norma ISO19115.
En el Área de Teledetección del INTA [4] se trabaja fundamentalmente con los
datos obtenidos mediantes nuestros propios sensores aeroportados: el
multiespectral DAEDALUS1268 y el hiperespectral AHS [5][6], de reciente
adquisición. Y en alguna campaña o proyecto específico, con datos procedentes de
alguno de los sensores que montan los satélites comerciales de teledetección.
Así mismo, en el Área de Teledetección se cuenta con el CREPAD [7] ubicado en

la estación de Maspolomas (Gran Canaria) desde donde se distribuyen datos y
productos procedentes de los sensores: AVHRR (NOAA), SeaWiFs (SEASTAR),
MOS (IRS-PR) y Meris (ENVISAT).
El proyecto de incorporación de los metadatos a ficheros XML según la normativa

ISO se inició a finales de 2003 y ha tenido varias fases:
Estudio de la normativa ISO.

Desarrollo de una aplicación (IME [8]) para comprender la jerarquía de la
norma ISO19115 y poder realizar todos los pasos siguientes.
Definición del Perfil de metadatos (selección, entre todos los que ofrece la
ISO19115, de los metadatos que mejor se adaptan a la información)
Creación de plantillas con la información global (ficheros de texto que
contienen, ya rellenos, los datos que no cambian entre campañas)
Generación, lectura y validación de ficheros XML.
Generación de hojas de estilo y HTML (para facilitar la interpretación de
los ficheros XML)

Figura 1. Software IME version 4.0 (INTA)
Todas estas fases se han cumplimentado utilizando la norma ISO19115:2003 y los

borradores de la norma ISO19139 que han ido apareciendo.
Actualmente se está trabajando con la versión 4.0 del Software IME que ya incluirá
la versión definitiva del esquema de la ISO19139 y permitirá, por tanto, la
validación de los ficheros XML.
Durante este proceso se intentó una aproximación al Nucleo Español de Metadatos

(NEM v.1.0) [9], una importante iniciativa del Grupo de Trabajo de la IDEE para
definir un conjunto mínimo de metadatos que permitan poner en marcha nuevas
Infraestructuras de Datos Espaciales y contar de un modo unificado con una misma
base de metadatos para trabajar con la información geográfica.

3 Comparación NEM - Perfil INTA
Ya durante la fase de definición del Perfil del Área de Teledetección [10][11] se

encontraron problemas de localización de algunos metadatos que, para las
imágenes de teledetección, son fundamentales.
Las tablas siguientes muestran una comparación entre los metadatos que incorpora
el NEM y los que fue necesario incorporar o modificar para trabajar con datos de
teledetección:
Entidad principal NEM PERFIL-INTA

spatialRepresentationInfo NO SE Aunque se ofrecen tres opciones
UTILIZA aplicables a Teledetección:
MD_GridSpatialRepresentation
Representación espacial de
los datos. MD_Georectified
MD_Georeferenceable
Se ha optado por la primera, para evitar
la multiplicación de perfiles.
Para imágenes georreferenciables o
georreferenciadas, se indica "1-yes" en
transformationParameterAvailability
Y el sistema de referencia de la imagen
se indica en referenceSystemInfo
Figura 2. spatialRepresentationInfo (perfil INTA de teledetección)

metadataExtensionInfo NO DEFINE Se define una extensión para
EXTENSIONES contemplar la información relativa a

A LA NORMA. sensores aeroportados:

acquisitionInformation
Descripción de las
Por lo tanto es necesario identificar en
extensiones a los
MD_MetadataExtensionInformation
metadatos.
todos los metadatos que se incorporan
Figura 3. metadataExtensionInfo
(perfil INTA de teledetección)
Figura 4. acquisitionInformation

contentInfo NO ESTÁ Se utiliza MD_ImageDescription
INCLUIDO para incluir información sobre las
bandas con MD_Band
Descripción del contenido (sequenceIdentifier, maxValue,
de los datos, tanto minValue, units y bitsPerValue).
vectoriales como raster. Así como información sobre la
cobertura nubosa y el nivel de
proceso:
processingLevelCode y
cloudCoverPercentage

Figura 6. dimension
Figura 5. contentInfo

identificacionInfo Incluye de Se añaden a los elementos del
MD_DataIdentification, los NEM: graphicOverview para
siguientes elementos: identificar fichero "quicklook"
Información básica de las imágenes.
citation, abstracta, purpose,
sobre los recursos a
credit, pointOfContact, En citation no se incluye
los que se aplican los
descriptiveKeywords, citedResponsibleParty pues
metadatos.
resourceSpecificUsage, puede ser redundante con la
resourceConstraints, información de pointOfContact.
aggregationInfo,
En restricciones, no se incluye
spatialRepresentationType,
accessConstraints porque no se
spatialResolution, language,
trabaja con restricciones de
characterSet, topicCategory y
acceso a los datos entregados.
extent.
La inclusión de
Restricciones:
otherConstraints abre la
Pueden ser : posibilidad de incluir texto libre
para definir restricciones
MD_LegalConstraints
especiales.
Donde el NEM utiliza:
Restricciones:
accessConstraints,
Se incluye
useConstraints,
MD_SecurityConstraints para
otherConstraints.
manejar información restringida.
Y MD_SecurityConstraints Concretamente el elemento

classification
que no es incluido en el NEM.
Información sobre
Información sobre
agregaciones:
agregaciones definidas en el
conjunto de datos Se usa para identificar
información que engloba todos
Se incluyen en
los datasets, por ejemplo
aggregationInfo los
información sobre otras
elementos:
campañas de vuelo relacionadas
aggregateDataSetName,
y/o datos auxiliares.
aggregateDataSetIdentifier,
associationType e No se utiliza
initiativeType aggregateDataSetIdentifier
porque si se identifica
directamente el
aggregateDataSetName no es
necesario.
Figura 8. resourceConstraints
Figura 9. aggregationInfo
Figura 7. identificationInfo (perfil INTA de teledetección)
4 Metadatos de teledetección.

La norma ISO19115 considera los datos raster como una información auxiliar, una
imagen con datos binarios que se incorpora frecuentemente a los datos vectoriales
y que por tanto necesita estar presente entre los metadatos.
Sin embargo, la información tratada en el campo de la teledetección contempla
muchas variables adicionales de difícil ubicación, así como formatos y procesos
específicos.
4.1 Datos raster
Los datos raster se pueden definir como una malla regular, formada por celdas,
cada una de las cuales lleva asociado un valor numérico. Estos valores pueden
representar variables como el nivel digital observado, radiancias, reflectancias,
temperaturas o alturas (en el caso de tratarse de modelos digitales del terreno).
Además los datos almacenados pueden consistir también en variables temáticas
derivadas como: índices de vegetación, resultados de algún tipo de algoritmo o
clasificaciones temáticas.
La entidad que comprende esta información es contentInfo (ver figura10)

Figura 10. contentInfo

En esta entidad se han incluido metadatos específicos sobre la imagen o sobre la
geometría que, o bien apuntan a codelists que deberían ser ampliados o bien
permiten "texto libre" que imposibilita la homologación a la hora de localizar la
información.
Por otro lado, el metadato utilizado para representar unidades de medida: uom
define, únicamente: Area, Time, Velocity, Volume, Angle, Scale y Length, que
resultan insuficientes para definir las diferentes variables que puede representar una
imagen raster.
4.2 Procesamiento de los datos
Los procesos que se aplican sobre los datos en bruto pueden ser complejos y
requerir una referencia en los metadatos y además pueden modificar la geometría y
la variable original almacenada en la imagen. Por ello es importante que el usuario
conozca todos los procesos aplicados sobre la imagen hasta obtener el producto que
llega a sus manos.

Para explicar estos procesos se utiliza la entidad LI_Lineage, pero la limitación en

los metadatos que contiene, obliga en muchas ocasiones a recurrir a los elementos
de tipo "texto libre" (como por ejemplo description) para añadir una explicación
pormenorizada de los algoritmos.
Figura 11. lineage

4.3 Volumen de los datos
Una imagen obtenida y procesada con el sensor aeroportado hiperespectral AHS

(80 canales) del INTA, puede alcanzar un tamaño de 1 o 2 Gigas.
Este dato afecta principalmente a la fase de distribución de información por
Internet.
Las especificaciones como WMS (Web Map Service) de OpenGis facilitan la
incorporación de una capa raster sobre los datos vectoriales como respuesta a la
solicitud de una aplicación cliente. Pero es necesario acudir a la especificación
WCS (Web Coverage Service) para manejar con más eficiencia datos raster,
aunque necesitará una revisión más profunda cuando se trate de datos de
teledetección con un volumen tan elevado.
¿Cómo guardar esta información en la base de datos del catálogo?, ¿cómo resolver
los problemas de escalas?, estas y otras preguntas, sobre la velocidad, formatos de
compresión, etc… surgen en cuanto se hacen pruebas de respuesta a una petición
de una imagen de teledetección via servicio web.

4.4 Multiplicidad de formatos
No existe un formato unificado para los ficheros de teledetección.

En función de su origen (sensor) o aplicación, podemos encontrar multitud de
extensiones diferentes para contener una información, en muchos casos, muy
similar.
Por ejemplo:
HDF-EOS[12] (Formato de productos procedentes del "NASA Earth Observing
System" (EOS)
CEOS [13](Formato que se utilizan para datos radar: Radarsat, ERS, JERS-1)
Los datos procedentes del sensor AVHRR[14] de NOAA pueden venir en varios
formatos en función del equipo de recepción utilizado (Level 1b 8-bit/10-bit/16-bit
HRPT/LAC, Level 1b 8-bit/10-bit/16-bit GAC, Dartcom16-bit HRPT, Satlantic16-
bit HRPT, etc…)
Hay formatos genéricos como MrSID [15], GeoTiff [16], JPEG2000 [17]
Y formatos especifícos para cada aplicación: Erdas [18], Geomatica [19], ENVI
[20].
SPOT [21] utiliza el formato Dimap, LANDSAT [22] utiliza FastL7, HDF o
GeoTiff.
Queda pendiente una conexión de todos estos formatos con el XML validado que
presente la norma ISO19139. Y al mismo tiempo es necesario resolver la definición
y ubicación de los metadatos que todos los organismos implicados consideren
obligatorios.
5 Conclusiones
En el campo GIS se lleva trabajando varios años tanto a nivel nacional como
internacional con la normativa y las recomendaciones ya comentadas.

Este trabajo ya realizado sirve de base para la incorporación de la información

geográfica proveniente de otros campos, como ocurre con la teledetección.
Sin embargo hay muchos elementos específicos de teledetección que requieren una
revisión por parte de los principales organismos, profesionales y empresas que
trabajan en esta área.
Todas las dificultades que se han encontrado en el trabajo realizado en el Área de

Teledetección del INTA se pueden resumir en la necesidad de tomar decisiones
individualmente ante la dificultad de encontrar otras referencias.
Actualmente está muy abierta la ubicación de los datos de las imágenes dentro de
la jerarquía de la ISO19115. Los borradores de la futura norma ISO19115-part2
("Metadata for imagery and gridded data") todavía no pueden garantizar que las
modificaciones que vendrán, solucionen los problemas que se han presentado.
En todo caso esta ampliación de la norma todavía tiene un largo camino por delante
y el día de la publicación del esquema definitivo propuesto por la ISO19139, está
muy próximo.
Por todo ello es fundamental que a nivel nacional se unifiquen criterios en cuanto
a:
Selección de perfiles de teledetección (orientando su estudio a partir de los
diferentes sensores disponibles)
Necesidad de disponer, de la misma manera que se ha hecho con el Núcleo
Español de Metadatos, de un Núcleo de Metadatos de Teledetección.
Localización de metadatos (ubicación consensuada de la información más
crítica, eludiendo en lo posible los campos de "texto libre" para incorporar
largos párrafos de esta información.
Extensiones a la norma ISO19115 (será inevitable añadir nuevos metadatos
y, si se quiere que sean interoperables, deberan incorporar una ampliación
también para el esquema de la ISO19139).
Estudio de las recomendaciones OpenGis para servicios WEB aplicadas
especialmente a los catálogos de imágenes de teledetección.
Referencias

[1] INSPIRE Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT

AND OF THE COUNCIL establishing an infrastructure for spatial
information in the Community). http://inspire.jrc.it.
[2] ISO-TC211. Standardization in the field of digital geographic information.
http://www.isotc211.org/
[3] OPENGIS. Open Geospatial Consortium. http://www.opengeospatial.org/
[4] INTA. Instituto Nacional de Técnica Aeroespacial. http:// www.inta.es
[5] AHS Sensor hiperespectral del Instituto Nacional de Técnica Aeroespacial.
http://www.crepad.rcanaria.es/es/info/npoc/indexlab.html
[6] Alix Fernandez Renau, Jose Antonio Gomez, Eduardo de Miguel (2005) “The
INTA AHS system”. Proceedings of SPIE Volume: 5978
[7] CREPAD. Centro de Recepción, Proceso, Archivo y Distribución de datos de
Observación de la Tierra. http://www.crepad.rcanaria.es.
[8] IME (ISO Metadata Editor)
http://www.crepad.rcanaria.es/es/info/metadatos/index.htm
[9] N.E.M. http://www.idee.es/resources/recomendacionesCSG/NEM.pdf
[10] Domínguez Barroso A., Amaro Cormenzana, A. y de Miguel Llanes, E.
(2005) “Perfil de metadatos del Servicio de Teledetección de INTA”. XI Congreso
Nacional Teledetección de Tenerife.
[11] Amaro Cormenzana A., Domínguez Barroso M. y Jiménez Michavila M.
(2005) “Metodología para la generación de Metadatos según la normativa
ISO19115 (Metadatos de Información Geográfica) e ISO19139 (Especificación de
la Implementación)”. XI Congreso Nacional Teledetección de Tenerife.
[12] HDF EOS http://hdf.ncsa.uiuc.edu/hdfeos.html

[13] CEOS. http://www.ifremer.fr/cersat/en/data/manuals/ceos.htm
[14] AVHRR. http://www.nesdis.noaa.gov/
[15] MrSID. http://www.lizardtech.com/
[16] GeoTiff. http://www.remotesensing.org/geotiff/spec/geotiffhome.html
[17] JPEG2000. http://www.jpeg.org/jpeg2000/
[18] Erdas. http://www.erdas.com
[19] Geomatica. http://www.geomatica.com
[20] ENVI. http://www.rsinc.com
[21] SPOT . http://www.spotimage.fr
[22] LANDSAT. http://landsat.usgs.gov

SESIÓN 3
SERVICIOS
105
Contribuciones de una IDE a la e-Ciencia: Proyecto AWARE. Sesión 3
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: gould@lsi.uji.es
‡ Instituto Cartográfico de Cataluña

Parc Montjuic s/n Barcelona
e-mail: allados@icc.es
Resumen
En este capítulo analizaremos el papel que potencialmente juegan las IDEs en el

ámbito de la e-Ciencia. También describimos algunas de las mejoras que aportan
los componentes de una IDE a la e-Ciencia, por ejemplo, la reciente especificación
de OGC para geo-procesamiento en la Web. Finalmente describimos la
implementación de un WPS en un proyecto europeo en ejecución, en un contexto
medioambiental marcado por GMES.
Palabras clave: e-Ciencia, Servicios Web, 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
medioambientales complejos como el cambio climático y el ciclo del agua
transcienden barreras geográficas y disciplinarias, y requieren soluciones
científicas aplicadas 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

Sesión 3 Contribuciones de una IDE a la e-Ciencia: Proyecto AWARE.
colaboraciones globales posibilitadas de forma distribuida en Internet”. Una

característica comú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 distribuida, hace posible que los investigadores o usuarios
científicos en general puedan compartirlos.[3]. En este capítulo veremos el papel
que desempeñan las IDEs y no solo la tecnología Grid, en la e-Ciencia poniendo
como ejemplo un proyecto europeo perteneciente a GMES actualmente en
ejecució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 monitoring
and forecasting Available WAter REsource)[5] que tiene como objetivo el
desarrollo de herramientas novedosas para la automatización de las tareas de
monitorizació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 y
de tal forma que estén disponibles para toda la comunidad científica con intereses
hidroló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 pertenecientes 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
IDEs 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
informació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 decisiones 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 trasladados desde la visión de proyecto a corto plazo a servicios
mantenidos a largo plazo.
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);
• 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 servicios
supone una infraestructura muy similar a la que propone el sector de las
infraestructuras de datos espaciales (IDE).

Una IDE es fundamentalmente la facilitación y la coordinación del intercambio y la

compartición de datos y servicios entre usuarios de diferentes niveles
jurisdiccionales en el ámbito de los datos espaciales. 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 mantenimiento de los datos y su integración con
otros conjuntos de datos.
Aunque las IDEs son principalmente marcos de colaboración institucional también
definen e implementan sistemas de información heterogénea distribuida, mediante
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
espaciales.
• 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

los 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) [9] y la NASA. La arquitectura puede ser interpretada
como una arquitectura tradicional de 3-capas, modelo cliente-middleware-servidor,
donde las aplicaciones cliente buscan datos espaciales que son encontrados
posteriormente, estos datos pueden ser transformados o procesados por servicios
intermedios antes de su presentación en ese cliente. La arquitectura puede
interpretarse también usando el modelo triangular de servicios web “publish-find-
bind” [7] donde servicios de catálogo publican el contenido de los datos espaciales,
estos datos son buscados y encontrados posteriormente por servicios y por último
enlazados y ejecutados.
Hasta ahora las definiciones de IDEs han puesto poco énfasis en el geo-
procesamiento que ocurre posteriormente al descubrimiento y transformación de
los datos. El geo-procesamiento se lleva a cabo de 3 maneras posibles:
1. Sistema de información geográfica. (SIG)
2. Cliente pesado, por ejemplo gvSIG (http://www.gvsig.gva.es/)

3. Servicios Web.
El proyecto AWARE tiene su enfoque en esas dos últimas formas de
geo-procesamiento.
3 OGC Web Processing Services

Open Geospatial Consortium (OGC) define una arquitectura abierta e interoperable
- basada en la reutilización de los componentes estandarizados [8] – permitiendo 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
GIS monolíticas, donde toda la funcionalidad está implementada en una caja negra
a la que no tiene acceso el usuario.
Figura 1. Modelo de referencia de la arquitectura de las IDEs (fuentes: FGDC[9] , e

INSPIRE[10])
Hasta el momento, se ha estado haciendo hincapié mayoritariamente en la

implementación de servicios OGC de acceso y visualización de información
geográfica (WMS, WFS, WCS, servicio de catálogo), sin embargo, con la nueva
especificación de OGC (WPS) para acceder a de servicios de geo-procesamiento es

posible realizar operaciones más complejas (ej. 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] pero que en este
caso encapsulan funcionalidad SIG (es decir, geo-procesamiento).
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 Observación de la Tierra, 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…) de una cuenca
hidrográfica y los técnicos/científicos que manejan esta información (trabajando
para compañías hidroeléctricas, administración local, etc.).
El proyecto aborda esta problemática proporcionando servicios de catálogo para
dar acceso 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
escorrentía. Este conjunto de geo-servicios junto con otros componentes, tales
como asistentes al usuario e información estática, 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 concernientes al área de interés indicada.
En la figura 2 se pueden ver los servicios de geo-procesamiento que en conjunción

con otros módulos componen el modelo hidrológico SRM [12]. Uno de estos geo-
servicios es el que realiza el cálculo de temperaturas por zonas de elevación.
Uno de los pasos intermedios a realizar antes de poder ejecutar estos modelos es 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élite y de los datos in-situ. Estos factores representan la localización de cada
una de las estaciones meteorológicas distribuidas por toda la cuenca hidrográfica,
las mediciones de temperatura tomadas en estas, un modelo digital de elevación 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

reducido, por lo que hemos de recurrir a cálculos geo-estadísticos (kriging) para
obtener la temperatura en los puntos para los que no se dispone de esta
información.
Hay varias fuentes de información a las que se necesita acceder para realizar estos
cálculos:
- Datos meteorológicos: Temperatura media mínima de las estaciones

meteorológicas (junto con coordenadas y elevación) obtenidas a través de
un Web Feature Service (WFS).
- Modelo de elevación digital de del área de estudio en formato GeoTiff
ofrecido a través de un Web Coverage Service (WCS).

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

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.
Localización est.
meteorológicas
DEM Temperatura
Cálculo de la
media de cada
Temperatura en distribución zona de elevación
estaciones espacial de la
seleccionadas temperatura
Zonas de elevación
Algoritmos de
interpolación
Figura 3 – Modelo conceptual del geo-servicio creado
La implementación del geo-servicio está basada en la especificación para WPS

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

geo-espaciales, del mismo modo que podríamos hacer a través de un sistema GIS
tradicional (ej. 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
(GetCapabilities) a través de sus metadatos, 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 en etiquetas XML).
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-estadistico 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&am
p;CRS=EPSG:4326&FORMAT=GEOTIFF&HEIGHT=128&WIDTH=146&BBOX=562.5713
55905512,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 envio, el geo-servicio recibe los inputs – en este caso las mediciones de la
temperatura en las estaciones meteorológicas y su localización
(StationTemperature) como uma 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 (NumElevationZones) como un número entero – y el output a generar. El
geo-servicio devuelve una respuesta XML, indicando si este ha finalizado
satisfactoriamente o no, y en caso afirmativo, una URL desde la cual poder acceder

a los resultados. En este caso, un archivo GML 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 datos
y funcionalidades para colaborar y economizar recursos se considera necesario la
puesta en marcha de una IDE que resuelva estas necesidades, aportando un entorno
abierto e interoperable - basado en la reutilización de los componentes
estandarizados 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 aplicaciones GIS estándar, donde normalmente solo un pequeño
porcentaje de las funcionales ofrecidas es utilizado. Aunque no pretende resolver el
problema de composición de servicios [16].
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 elemento. 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
requeridos en el mundo científico en el ámbito del medioambiente y la seguridad.
El proyecto AWARE aporta uno de estos servicios impulsados por GMES,
desarrollado como diferentes OGC Web Processing Services, ofreciendo un
conjunto de funcionalidades estándar escalables y reutilizables.
Referencias
[1] M. K. Ramamurthy, A new generation of cyberinfrastructure and data

services for earth system science education and research. Advances in
Geosciences, 8: 69 – 78. Junio 2006
[2] I. Foster, C. Kesselman, S. Tuecke, The Anatomy of the Grid: Enabling

Scalable Virtual Organizations. CIntl J. Supercomputer Applications Vol.
15, No. 3. 2001

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

Noviembre/Diciembre 2004.
[4] The "Global Monitoring for Environment and Security"

http://www.gmes.info/
[5] AWARE Project: A tool for monitoring and forecasting Available WAter REsource
http://www.aware-eu.info/es/home.htm
[6] C. Granell, M. Gould, M.A. Bernabé y M.A. Manso. Spatial Data

Infrastructures. In H. Kasimi (Ed.) Encyclopedia of Geoinformatics, Idea
Group Press, en prensa.
[7] 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 (accessed 4 April 2002)
[8] C. Granell. Reutilización de Servicios Web mediante components integrados. Tesis

Doctoral. Departamento de Lenguajes y Sistemas Informaticos. Universitat Jaume I. 2006
[9] Federal Geographic Data Committee (FGDC): http://www.fgdc.gov

Geospatial Interoperability Reference Model (GIRM):
http://gai.fgdc.gov/girm
[10] P. Smits, et al (2002): INSPIRE Architecture and Standards Position

Paper. Architecture and Standards Working Group.
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 (Aug.
19, 2002);
http://www.w3.org/TR/2002/WD-wsa-reqs-20020819
[12] Martinec, J., Rango, A., and Major, E. The Snowmelt Runoff Model
(SRM) User's Manual. NASA RP-1100. Greenbelt, Maryland, p. 110. 1983

[13] Open Geospatial Consortium Inc. Web Processing Service. Discussion

paper OGC 05-007r4.
[14] R Development Core Team. R: A language and environment for

statistical computing. R Foundation for Statistical Computing, Vienna,
Austria. ISBN 3-900051-07-0. 2006.
URL http://www.R-project.org
[15] E. J. Pebesma and C. G. Wesseling, Gstat: a program for geostatistical

modelling, prediction and simulation. Computers & Geosciences Vol. 24,
No. 1, pp. 17-31. 1998.
URL http://www.gstat.org
[ 16] R.Lemmens, C. Granell, et al. Integrating Semantic and Syntactic

Descriptions for Chaining Geographic Services. IEEE Internet Computing.
September-October 2006.

Sesión 3 Evaluación de la calidad de datos raster mediante aplicaciones RIA:...
GeoBovino: Un ejemplo de Geo-trazabilidad

M.A. Manso Callejo
M. Núñez Jiménez
Universidad Politénica de Madrid, ETSI en Topografía, Geodesia y Cartografía:

LatinGEO (Laboratorio de Tecnológicas de la Información Geográfica)
Autovía de Valencia Km 7, 28031 Madrid (España)
m.manso@upm.es
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: “aquellos procedimientos preestablecidos y autosufi-
cientes que permiten conocer el histórico, la ubicación y la trayectoria de un pro-
ducto o lote de productos a lo largo de la cadena de suministros en un momento
dado, a través de unas herramientas determinadas”. [1]
La información sobre la trazabilidad animal esta 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 infor-
mació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]
1. Introducción
La trazabilidad de la carne de vacuno en España está garantizada por distintas di-
rectivas 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 como deben identificarse las reses y como
debe ser etiquetada toda la carne o los productos derivados de la misma. Aunque

Evaluación de la calidad de datos raster mediante aplicaciones RIA:... Sesión 3
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.
Geo-Bovino 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 “Geo-Bovino” se han modelado
las diferentes fuentes de información que gestionan los distintos actores (adminis-
tración, ganaderos e industrias cárnicas), en relación a un producto cárnico de va-
cuno. Posteriormente, cada una de las fuentes de información es gestionada por un
servicio 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 con-
sultas 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 coorde-

nadas 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ñando tiene por
objeto ser una maqueta funcional y operativa que demuestre como se podría pro-
porcionar a los consumidores, de una forma amigable, más información sobre to-
dos 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 eti-
quetado, 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 inter-
namente la relación de cada producto que pone a la venta con el canal o pieza su-
ministrada y la mayor parte de la información presente en el etiquetado no es acce-
sible 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 acto-
res:
- 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, que llevan la información del sacrificio y despiece de los
animales.
- Por último la asociación de ganaderos y los propios ganaderos, que 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 gestiona la
asociación de ganadera y los ganaderos son muy dependientes entre 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 permitiera la
recuperación de la información para cada una de las entidades de manera indepen-
diente.
2.1) Base de datos

Se ha utilizado como sistema gestor de bases de datos (SGDB) PostGresSQL ver-
sion 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 po-
drá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 coorde-

nadas geográficas de las explotaciones ganaderas, y se asocia a un despla-
zamiento 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 informa-
ción relativa al sacrificio y al despiece del animal, reflejando además que
pieza proviene de que animal.
Asociación-Ganadero
Alimentación Control Tratamiento

Sanitario Sanitario
Explotación Lote Ternero

ganadera
Ministerio Centro cárnico
Movimiento Centro
Canal
cárnico
Explotación
Pieza
ganadera
Figura 1. Esquema de la base de datos.
2.2) Servicios web
“Un servicio web, es un recurso software que se ejecuta en un servidor web remo-
to, en respuesta a la solicitud hecha por un cliente. Los servicios web son equiva-
lentes 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 enviada al servidor y el resul-
tado de esa tarea, devuelto al usuario” [6].

Los servicios Web se han implementado usando Java, el JDK version 5.0 y el ser-
vidor de aplicaciones Tomcat de apache 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 además
permite un acceso mas sencillo a estos servicios Web en los que se apoya.
2.2.1) Servicios Web basados en SOAP

“SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar creado
por el W3C que define cómo dos objetos en diferentes procesos pueden comuni-
carse por medio de intercambio de datos XML.” [9,10].
Se han creado tres servicios Web, cada uno de ellos se encarga del acceso y recupe-
ració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 cual-
quier programa que implemente este sistema, pudiendo invocar los métodos ex-
puestos por el servicio para obtener la información correspondiente de la entidad.
2.2.1) Servicio Web global

Este servicio, no es propiamente un servicio Web sino una aplicación que se ejecu-
ta 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 puer-
ta 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
getCapabilities del servicio. El resultado de esta petición es la información que
describe 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 servicios
Web SOAP, y el posterior procesamiento de la información de respuesta para gene-
rar 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 mas 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 ó 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 librerias adecua-
das de Axis (herramienta de trabajo basada en SOAP y WSDL) que pone a disposi-
ción de los programadores una serie de librerías, que contienen métodos para reali-
zar los accesos a los servicios Web. Por otro lado “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” [13].

3.2) Servicio Web global

Si lo que se desea es el acceso al servicio global, o simplemente acceder a los ser-
vicios independientes pero de una manera más sencilla, entonces se puede acceder
utilizando un navegador:
- Utilizando la página Web de consulta con dos opciones (básica y 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:
http://localhost:8080/GEOBOVINO/servlet/Principal?xml=<?xml ver-
sion="1.0" encoding="UTF-8"?><trazability xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation ="file:C:\\...\\peticion.xsd"> <service ver-
sion="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: SWGeoBovino
(servicio global), SWMinisterio (lleva la parte de movimientos del animal),
SWCarnico (informa sobre despiece y sacrificio del animal), SWAsogan (in-
forma sobre datos del ternero, alimentación y sanidad)
- Version, indica la versión 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 serviciosWeb, y llamando a sus métodos globales (getMo-
vimientos, getCarnico y getAsogan), getPieza, recupera todos los datos de una
pieza. La resolución de esta petición se realiza llamando a los tres servicios-
Web, y llamando a sus métodos globales (getMovimientos, getCarnico y getA-
sogan).
o SWMinisterio: getCapabilities, indica las capacidades del servicio, getMovi-
mientos, recupera todos los traslados que ha hecho el animal, 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, getDespie-
ce, recupera la información relativa a la pieza, getSacrificio, recupera la infor-
mación relativa al sacrificio.

o SWAsogan: getCapabilities, indica las capacidades del servicio, getAsogan,

recupera toda la información del ternero, su alimentación e información sanita-
ria, getTernero, recupera los datos básicos del animal, getCebo, recupera la in-
formación relativa al cebo o alimentación del animal, getSanidad, recupera la
información relativa a sanidad del animal, es decir, tratamientos y controles sa-
nitarios.
- Parámetros: Son los parámetros propios de la consulta. El crotal siempre es
obligatorio, y la pieza en cambio es opcional, debiendo aparecer solamente 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.
Acceso externo a los

servicios Web mediante
mensajería SOAP para
resolver peticiones
parciales
Servicio Web Servicio Web Servicio Web

BD Ministerio BD Asociación ganadera BD Centro cárnico
Acceso interno
mediante mensajería
SOAP para resolver
las peticiones
Transformación
Aplicación Web
XSLT
(Servicio global)
1) Petición a partir de formularios
HTML.
2) Petición por URL Aplicar plantilla XSL al
3) Petición mediante XML documento XML
Respuesta en 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 trata

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. Una vez creada la respuesta en XML y
dependiendo del formato de salida seleccionado, el resultado se muestra directa-
mente el XML o se toma el XML y se le aplica una plantilla XSL para que median-
te un proceso XSLT se transforme ese fichero XML en una pagina Web de res-
puesta al usuario [15].
3.4) Interfaz del servicio Web global

Como se indicó anteriormente no es estrictamente un servicio Web, y aun-
que implementa métodos públicos que orquestan las llamadas a otros servi-
cios, es capaz de procesar peticiones dirigidas expresamente a él. Este servi-
cio 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 construc-
ción, pero se puede consultar la forma de usarlo mediante la petición getCa-
pabilities del servicio. Este servicio pone a disposició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 peticiones sobre los
servicios Web SOAP, y un posterior procesamiento de la información reco-
gida para su presentación al usuario.
A) GetCanal: Este método se apoya en los otros tres servicios Web, y de-
vuelve el conjunto de las peticiones de los tres. Invoca los métodos de
cada servicio Web que devuelven toda la información de cada servicio.
Solamente se que no se incluye información en el apartado de despiece,
debido a que se está solicitando información a nivel de canal y no se in-
cluye un nombre de pieza que recuperar.
B) 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 in-
formación en el apartado de despiece debido a que se está solicitando
información a nivel de pieza, por lo cual se le proporciona un nombre de
pieza para recuperar.

C) 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 BBDD que no sólo atiende a las exigencias del problema, sino
que se ha realizado de la manera mas 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 mensa-
jeria SOAP de manera satisfactoria dotanto al sistema de independiendencia y au-
tonomía. La estructura 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 funcionamiento 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 erro-
res que ocurren: peticiones, validaciones, servicios y acceso a BBDD. Se ha dotado
al prototipo de ficheros de configuración que permitan independencia en su im-
plantación. El hecho de resolver las peticiones con respuestas escritas en lenguaje
XML las hace especialmente compatibles por cualquier sistema, ya que es un es-
tándar de libre distribución. Además para mayor facilidad del usuario se ha imple-
mentado 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 informa-
ción de los distintos centros cárnicos y asociaciones ganaderas, ya que cada asocia-
ción ganadera se realiza de manera independiente, gestionando su propia informa-
ción, y por tanto se decidió enfocar el proyecto desde el punto de vista de la aso-
ciación ganadera. Por ello se decidió que existiría un servicio Web de consulta por
cada asociación ganadera, conteniendo 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 (Ministerio y
CCAA).
10

El grado de desarrollo del prototipo está al 80% y aunque esta 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 mas 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 profe-

sionales 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.
6. Referencias
[1] Concepto de Trazabilidad:
http://www.aecoc.es/web/codificacion.nsf/0/925B46B62071AAB5C1256F2E0050
6B2E?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
11

Análisis de los servicios WMS disponibles: hacia un conjunto de... Sesión 3
EVALUACIÓN DE LA CALIDAD DE DATOS RASTER

MEDIANTE APLICACIONES RIA1: UNA REALIDAD DERIVADA
DE LOS SERVICIOS PROPUESTOS EN UNA IDE
Martinez Lorente, Sergio 1

Mogollón Díaz, Alexander 2
Béjar Hérnández, Rubén3
Zarazaga Soria, Fco. Javier 4
Muro-Medrano, Pedro R. 5
Universidad de Zaragoza (España), sergiom@unizar.es 1, rbejar@unizar.es3, javy@unizar.es 4, prmuro@unizar.es 5

Universidad Pontificia de Salamanca , Campus Madrid (España), alxmog@upsam.net 2
El presente trabajo propone un método alternativo para evaluar la calidad de datos ráster utilizando
aplicaciones RIA y servicios WCS 2 de una IDE. Se ha utilizado el contexto de los Modelos
Digitales de Elevación (MDE) para transmitir los conceptos que se presentan a lo largo de todo el
texto.
La existencia de información raster tanto a nivel local como global de la superficie terrestre y la
proliferación de productos cartográficos en este formato, como lo son los MDE, ofrecidos por los
programas SRTM de la NASA, y el GTOPO30 del Servicio Geológico de los Estados Unidos,
generan la necesidad de evaluar la calidad de los mismo antes de su uso. A pesar de que existen
técnicas sistemáticas de evaluación de los componentes cuantitativos y cualitativos de la calidad de
un producto raster, acceder a ellos implica un coste económico generado por la adquisición de
software y de personal cualificado que ejecute la labor, y un coste temporal generado por el ciclo de
trabajo llevado a cabo, en el cual se involucran la localización y descarga de forma local de los
datos, la transformación a formatos compatibles y su posterior evaluación, como tareas
independientes y secuenciales.
Esta situación exige la adecuación de una tecnología que permita el acceso y consulta a cualquier
archivo raster de forma abierta e interoperable, lo cual es fácilmente realizable si se siguen las
especificaciones WCS propuestas por el OGC asociadas con las nuevas tecnologías web. Con ellas
es posible crear una arquitectura sencilla pero eficaz, capaz de soportar funciones tradicionalmente
asociadas a clientes GIS, como la visualización simultánea de información de diversas fuentes de
una misma área geográfica para realizar comparativas (benchmarks).
Para soportar este tipo de funcionalidad, además del servicio de tipo WCS, es necesario contar con
una aplicación Web, destinada a los usuarios que carecen de las herramientas. Para logralo
utilizamos la tecnologia RIA (Rich Internet Application), en auge durante el último año. Estas
aplicaciones web permiten una interactividad con el usuario con capacidades similares a las de un
desarrollo de escritorio, explotando la posibilidad de que los navegadores de Internet permitan una
comunicación asíncrona con servicios Web, lo que permite que la GUI implementada se comporte
de una forma más dinámica e interactiva.
En las aplicaciones RIA basadas en tecnología Web estándar, se utiliza el objeto

XMLHTTPRequest como vía de comunicación asíncrona con el servidor. Este objeto permite el
1
Rich Internet Application
2
Web Coverage Server

Sesión 3 Análisis de los servicios WMS disponibles: hacia un conjunto de...
intercambio de información textual con el servidor (típicamente en XML). Para poder usar este tipo
de comunicación asíncrona en la aplicación, se hace necesario que el WCS pueda servir datos en
formato texto. Como la especificación de OGC admite que un WCS puede ofrecer los datos en
varios formatos, se puede optar por usar uno textual, cualquiera tipo ASCII, como el ESRI ASCII
Grid, a la hora de implantar el servicio.
La creación de estas herramientas se encaminan a cambiar la metodología que, hasta ahora, se ha

venido utilizando para adquirir y evaluar la información raster y se justifica en las pautas de calidad
existentes dentro de la norma ISO 90003.
La generación de un sistema en línea y en tiempo real para ejecutar estas tareas minimiza costes
temporales, reduciendo el tiempo de espera de la información en soportes físicos. Por otro lado, la
validación de los datos será un proceso mas ágil basado en comparativos visuales implementados en
el cliente web. Las herramientas que se incluyen se basan en proporcionar productos visuales y
alfanuméricos, atendiendo a umbrales de discrepancia de los datos, calculados a partir de métodos
estadísticos, lo cual permite discernir acerca del estado de los mismos y de los errores temáticos de
los productos. En este escenario se centra la atención en los MDE por ser uno de los productos
cartográficos mas extendidos y utilizados, en los cuales se centran los esfuerzos en conocer y
controlar la imprecisión de los datos asumidos en el proceso de generalización. Sin embargo, la
herramienta puede resultar igualmente útil con cualquier otro tipo de información de naturaleza
raster. Como esta herramienta Web requiere visualización y acceso a datos simultáneamente, resulta
interesante utilizar tecnología RIA ya que ofrece comunicación asíncrona, necesaria para la
ejecución de estas tareas de forma concurrente.
De esta manera la validación de los datos dejaría de estar supeditada a la tenencia de una
herramienta específica, y no se requeriría un conocimiento especializado para su uso, al contrario de
lo que ocurre cuando se utilizan sistemas raster potentes de escritorio. Así, se consigue que el
acceso y la evaluación de la calidad de dichos datos sean servicios en línea que permitan al usuario
validar los datos globales de una forma detallada para un uso SIG especifico.
En un panorama ideal donde los componentes de una IDE se generalicen, este tipo de herramientas
cambiarían la lógica de negocio en el contexto de la información raster y el cliente podrá acceder,
evaluar y adquirir el dato en línea. Asímismo serán un posible complemento a los servicios de
catálogo de datos de una IDE derivado de la ISO 19115. La norma establece la posibilidad de que la
descripción de calidad desde la perspectiva cuantitativa y cualitativa no es de carácter obligatoria.
Sin embargo, el uso de los datos raster exige la evaluación de la calidad temática y semántica en
todo contexto que maneje información geográfica. En el supuesto de que la información relativa a la
calidad del dato se encuentre presente, el resultado visual obtenido será un complemento que la
corrobore.
3
La calidad es la adecuación o ideoneidad que tiene un dato o un conjunto de ellos para un uso determinado (fitness for
use)

Geo-bovino: Un ejemplo de Geo-trazabilidad. Sesión 3
Análisis de los servicios WMS disponibles: hacia un

conjunto de recomendaciones para su implementación
Paloma Abad Power†, Antonio Rodríguez Pascual†, José Ángel Alonso Jiménez†, Alejandra
Sánchez Maganto†, Luís Manuel Blázquez Vilches†.
† Subdirección General de Aplicaciones Geográficas.

Instituto Geográfico Nacional.
C/ General Ibáñez de Íbero, 3. 28003. Madrid.
Tlf: 91 597 9664 Fax: 91 597 9646 e-mail: pabad@fomento.es, afrodriguez@fomento.es,
jaajimenez@fomento.es, asmaganto@fomento.es, lmvilches@fomento.es
Resumen
La Comisión de Geomática del Consejo Superior Geográfico, el órgano superior, 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 Infraestructura de Datos Espaciales de España,
que está formado por representantes de organismos relacionados con la información cartográfica
de los tres niveles de la Administración (Nacional, regional y local) así como la empresa privada
y las universidades. Debido a la gran diversidad que 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 criterios “informáticos” que
son necesarios seguir para crear un servicio de mapas interoperable. Pero desde un punto de
vista “geográfico”, no se establecen unos criterios a seguir que garanticen una homogeneidad en
el modo de visualizar la informació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 información
geográfica, como los servicios, juegan un papel primordial ya que éstos definen 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 Infraestructuras 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 sustancioso 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.

Sesión 3 Geo-bovino: Un ejemplo de Geo-trazabilidad.
Los datos que se visualizan en un Web Map Service proceden de diferentes organizaciones y,
en consecuencia, presentan las características definidas por la organización 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 España, en particular:
• Es una de las especificaciones OGC más estables dentro del conjunto definido 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 interesante al permitir
la publicación de información sin permitir la descarga.
En este artículo 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 aquellos 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 este apartado se enumeran todos los WMS que han sido objeto del presente estudio. Estos
servicios han sido clasificados, atendiendo a su ámbito geográfico, en tres niveles diferentes:
nivel nacional, nivel regional y nivel local.
A Nivel Nacional:
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 pertenecientes 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-Cuadricula-Hojas/IDEE-Cuadricula-Hojas
- CORINE: Cobertura del suelo

http://www.idee.es/wms/IGN-Corine/IGN-Corine
D.G. de Catastro
- Catastro
http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx

Instituto Nacional de Estadística

- Límites Administrativos
http://www.idee.es/wms/IDEE-Limite/IDEE-Limite
A Nivel Regional
Instituto de Cartografía de Andalucía (ICA). Junta de Andalucía: Consejerí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. D.G. de Vivienda, 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 Territorial i Obres Públiques.

- IDEC: Cartografía 1:5.000
http://galileo.icc.es/wms/servlet/icc_bt5m_v_r?
- IDEC: Cataluña Ortofoto 1:5000
http://galileo.icc.es/wms/servlet/icc_orto5m_r_r?
- IDEC: Cataluña Ortofoto 1:25.000
http://galileo.icc.es/wms/servlet/icc_orto25m_r_r?
Xunta de Galicia
IDEG:
http://sitga.xunta.es/wmsgalicia/request.asp
Gobierno de la Rioja
IDERioja: Cartografía topográfica y ortofoto
http://wms.larioja.org/request.asp
IDERioja: WMS de diferentes municipios, como por ejemplo
http://www.iderioja.org/municipios/request.asp?mun=138sdom&
Comunidad Autónoma de la Región de Murcia: Consejería de Industria y Medio Ambiente. D. G.

Ordenación del Territorio y Costas. Unidad de Información Territorial
Información sobre el planeamiento urbanístico, patrimonio cultural y deslindes de costas
http://massotti.carm.es/wmsconnector/com.esri.wms.Esrimap/wms?
Gobierno de Navarra
IDENA: 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=GVasco
Generalitat Valenciana, Instituto Cartográfico Valenciano

http://icvmapas.icar.upv.es/servicio_wms
A Nivel Local
- IDE-COSTES de IDEC: Acceso a la información relativa a la costa.
http://www.geoportal-idec.net/idecostes
- IDE-Local de IDEC: Geoportal creado para la AOC (Administración Abierta de Cataluña) para acoger
los servicios de la Infraestructura de Datos Espaciales de las Administraciones Locales catalanas.
http://www.geoportal-idec.net/idelocal
- IDEPamplona, Ayuntamiento del Pamplona. Información territorial

http://ide.pamplona.es/ogc/wms.aspx
Ayuntamiento de Zaragoza
- IDEZAR: Información municipal
http://idezar.unizar.es/wms/IDEZar_base/IDEZar_base
- IDEZAR: Información urbana

http://idezar.unizar.es/wms/IDEZar_tematicoUrbano/IDEZar_tematicoUrbano
Otros WMS
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
Servidor de 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/AtlasAves.exe?
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 inherentes 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 información por criterios temáticos, de escala, de

sistemas de referencia, etc., la visualización de toda la información disponible en una IDE deja
de poder efectuarse de forma 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:
a. Sistemas Geodésicos de Referencia, SGR.

Los sistemas geodésicos de referencia constituyen uno de los aspectos más sensibles para la
compartición y visualización de información geográfica puesto que una manipulación incorrecta
puede introducir desplazamientos de los datos representados. El uso adecuado de los mismos
conlleva la evaluación de 3 puntos distintos:
• El sistema geodésico de referencia en que se encuentra almacenada la información.
• Los SGRs soportados por el servicio de mapas.
• Los SGRs soportados por la aplicación cliente.
Un Sistema de Referencia Terrestre [5], en general, tiene como objeto proporcionar una
herramienta sobre la que es posible dotar de coordenadas a puntos de la superficie de la Tierra.
En 1972, España adopto 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 Frame), siendo
está 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, siendo éste en España oficial hoy
en dí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 distintos sistemas de proyección.
El concepto moderno de SGR [5], conlleva la calificación de ED50, también, como un
sistema local; de ahí que, unido a las posibilidades de los avances tecnológicos, 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 (Megrim, 1999, [7]) para los
próximos años, 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 comunidad
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 esta disponible 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 proyecció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
b. Nombres y niveles jerárquicos de las capas
No existe una normalización a la hora de asignar nombres a las capas. Cada organización los
establece según sus propios criterios en función de su cartografía, encontrándonos
denominaciones muy diferentes para nombrar capas 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ísticas, 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.
c. Estilos de las capas

Debido a que cada cartografía tiene asociada unos criterios de simbología propios, que son
definidos a nivel autonómico, pueden observarse discrepancias al solapar información
proveniente de distintas fuentes; éstos problemas se incrementan en los límites fronterizos entre
CCAA.
d. 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 información necesaria
para su interpretación imposibilita su reducción
e. 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, ortofotos, 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 conjunto de datos: producto, unidad, capas,

etc. posibilitando la observación del producto desde diferentes vistas sectoriales y permitiendo
al cliente adaptar la visualizació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 de estándar 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 para facilitar la interacción
entre distintos sistemas [6].
A continuación se enumeran algunos de los requisitos mínimos que han sido extraídos del
borrador que está siendo desarrollado en el marco de la anterior iniciativa:
1. El WMS debe ser conforme a la implementación de ISO 19128 “Geographic
Information – Web Map Server Interface”.
2. El WMS debe soportar al menos el formato Portable Network Graphics (PNG; tipo
MIME “image/png”).
3. En los casos en los que un WMS no proporcione una cobertura completa para las capas
seleccionadas, deben soportarse imágenes transparentes.
4. El WMS debería soportar, cuando se excede el rango de escala útil, imágenes vacías o
simplificadas. La información sobre el rango de escala útil debe proporcionarse en la
respuesta a la petición GetCapabilities.
5. La respuesta a la petición GetCapabilities debe contener:
a) Metadatos.
b) El campo <LegendURL>.
c) 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.
6. Para la identificación del Sistema de Referencia de Coordenadas (Coordinate Referente
System CRS), debe usarse el espacio de nombres del European Petroleum Survey Group
(EPSG), y para la Uniform Resource Identifier (URI) los códigos del EPSG. Deben
emplearse los registros oficiales de ISO una vez que hayan sido establecidos.
7. El WMS debe soportar el CRS WGS84 en coordenadas geográficas, identificadas
mediante EPSG:4326. Además, se recomienda que la implementación de WMS también
soporte los siguientes CRSs [4]:
a) ETRS89 (coordenadas elipsoidales) (EPSG:4258) ;
b) ETRS89 / ETRS-LAEA (EPSG:3035) para representación y análisis
estadístico pan-Europeo;
c) ETRS89 / ETRS-LCC (EPSG:3034) para la cartografía pan-Europea a
escalas pequeñas o iguales a 1:500.000;
d) 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.
8. 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.
9. Si el WMS que se implementa es consultable, la operación que debe soportar
GetFeatureInfo es al menos INFO_FORMAT=text/html.
10. 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 han adoptado diversos
estándares, especialmente los promovidos por el Open Geospatial Consortium, 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 consolidación por parte de las organizaciones implicadas.
Las entidades colaboradoras en la constitución de infraestructuras de datos espaciales deben
concienciarse de la importancia de los aspectos cartográfico y de usabilidad pues de otro modo
la información será difícilmente integrable o su manipulación exigirá un esfuerzo tan
sumamente elevado que puede desencadenar el fracaso de este tipo de paradigma.
6. Referencias
• [1] Norma ISO 19128: “Geographic Information – Web Map Server Interface”.
• [2] Especificación del OpenGeospatial Consortium “Web Map Service (WMS)
Implementation 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] Annoni, A., Luzer, C., Gubler, E. and Ihde, J. (Editors), 2001. Map projections for
Europe. European Commision, 131 pp.
• [5] González-Matesanz, J. and Dalda, A., 2003. Development of the ED50-ETRS89
transition, EUREF Symposium, Toledo, España.
• [6] WG5. CEN/TC 287. Geographic information – Web Map Server European profile.
• [7] Megrim, 1999. Conclusions and recomendations, Spatial Reference Workshop, Marne-
la-Vallée, Francia

SESIÓN 4
METADATOS Y SEMÁNTICA
141
Unidades administrativas, una perspectiva ontológica. Sesión 4
Unidades administrativas, una perspectiva

ontológica
Javier Lacasta Miguel
Francisco Javier López Pellicer
Juanjo Floristán Jusué
Javier Nogueras Iso
Francisco Javier Zarazaga Soria
Departamento de Informática e Ingeniería de Sistemas.

Universidad de Zaragoza
e-mail: {jlacasta,fjlopez,juanf, jnog ,javy}@unizar.es
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
Infraestructura 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 de España.
Palabras clave: Unidades Administrativas, Ontologías, Gazetteer, Nomenclator,

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 descentralizar la
gestión administrativa, los estados han creado a lo largo de los siglos diferentes
tipos de entidades de diversa naturaleza legal para cubrir ámbitos territoriales
específicos. Dado su carácter oficial, son conocidas y usadas a todos los niveles
(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 convertido

Sesión 4 Unidades administrativas, una perspectiva ontológica.
en uno de los recursos más relevantes a publicar a través de distintas iniciativas

Infraestructuras de Datos Espaciales (IDE) que han surgido a nivel local, regional 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
claramente 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
modelo general basado en una ontología de dominio reutilizable, que defina los
conceptos básicos de las unidades y sus relaciones, y una serie de ontologías de
aplicación, cada una describiendo en detalle los tipos de unidades administrativas
específicos de un país y sus instancias.
El artículo 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 ontologí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 del arte en la caracterización de las unidades

administrativas
Un estado para organizar su territorio define mediante leyes que tipos de unidades
administrativas pueden existir dentro de un área determinada y qué atribuciones
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 administrativas
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
representar cualquier tipo de entidad geográfica [2][3], e incluso estándares

internacionales como ISO19109 [4]. En el ámbito más restringido de las unidades

administrativas existen recopilaciones de los modelos administrativos de los
distintos países usando distintos modelos de organización del conocimiento, en
forma de listas [5][6], tesauros [7] u ontologías [8]. El estándar internacional
ISO19112 [9] describe el modelo lógico de un diccionario de nombres geográficos
autorizados (nomenclátor), permitiendo describir las unidades administrativas
como una jerarquía, pero no considera problemas como las especializaciones de
tipos, el multilingü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
ontologías (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 de las
unidades existentes.
Como ontología de alto nivel, se ha seleccionado la descrita en [11] por contener
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.

146
Sesión 4
Top Level Ontology
classifies4
Norm SpatialEntity TimePeriod GraphModel
-author : CausalEntity - - - … … ...
1 0..*
unionOf4
subNorm4 0..*
0..*
0..*
Legal Domain
Regulatory Norm
Domain Ontology
classifies4 +officialName[1] : Identifier 3 unionOfEquivalents
-name[1] : Identifier
-translation[lang][0..*] : [NaturalLanguage]Description
-applicationArea[1] : Legal Domain
-altNames[lang][0..*] : [NaturalLanguage]Description
1 -validity[1] : TimePeriod 1 0..* 1..*
+applicationArea[1] : GraphModel
-responsibility[1..*] : Responsibility
+timePeriod[1] : TimePeriod
«ControlledLanguage»
Responsibility
-administrative
-census tracts
-postal district
-school districts 3 inLocation 0..*
Organization State Division Agrupation
-...
1 0..*
inLocation4 3 inLocation
0..1 0..1
0..*unionOf40..* 3 inLocation 0..*

Sub Division Municipality Minor Entity
0..*
1 0..*
Application Ontology
Comunidad Autonoma Provincia Comarca Comarca : Regulatory Norm NUT3
Comunidad Autonoma : Norma Reguladora Provincia : Regularoty Norm

Cuadrilla Cuadrilla : Regulatory Norm
Figura 1: Ontología de Unidades Administrativas

3 inLocation 3 inLocation 3 inLocation Álava : NUT3
España: State Pais Vasco : Comunidad Autonoma Álava : Provincia La Guardia-Rioja Alavesa : Cuadrilla officialName : Identifier
Instances translation[lang] : [NaturalLanguage]Description
altNames[lang] : [NaturalLanguage]Description
applicationArea : GraphModel
Spain : Regulatory Norm timePeriod : TimePeriod
3 unionOfEquivalents
ontología de dominio esta basada en los conceptos generales de “Norma

existencia se basa en una norma oficial con carácter de ley que los regula. La
Dado que las unidades administrativas representan dominios legales cuya
Jornadas Técnicas de la IDE Española, Castellón 2006.

Unidades administrativas, una perspectiva ontológica.
Reguladora” y “Dominio Legal”. Además, dada la organización jerárquica de los

países, es habitual que una norma de validez a otras para regular
administrativamente zonas especificas. 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 divisiones son las distintas particiones
del territorio de un estado, y de entre ellas consideramos el “Municipio” como la
entidad básica de división, agrupándose entre ellos para formar subdivisiones
mayores o dividiéndose para formar entidades menores. Las organizaciones son
agrupaciones de dominios jurisdiccionales, creados 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 funcionales 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 divisiones 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
ontologí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 de Ministerio de
Administraciones Públicas, entidad encargada de recopilar los nombres oficiales de
las unidades administrativas de España (asignados por las administraciones
competentes), 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
aproximaciones 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
informació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
producen 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, no siendo necesario que el sistema contenga toda la ontologí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
organización jerárquica de la comunidad (municipios y provincia a la que
pertenecen), siendo irrelevante el resto del contenido de la ontología. En estos
casos es interesante 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 presentadas 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 decido 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. Dichas 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
metadatos, 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],[22] con el objetivo de mejorar los procesos de recuperación de la
informació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 simplifiquen 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

ontología creada para proporcionar a los usuarios toda o parte de la jerarquía de
unidades 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
asignado 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 a los servicios de una IDE, el uso de restricciones
de carácter espacial es habitual, tanto en catálogos de datos, como en
nomenclá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 pueden 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 asociada.
El servicio de acceso al catálogo de datos es un caso especial dado que los
metadatos contienen palabras claves de lugar con los nombres de las unidades
administrativas que contienen el dato referenciado. Por tanto, se puede hacer
directamente 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 administrativas 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 (“adyacente 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,
esta 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
administrativas, ya que Wordnet no es exhaustivo (solo incluye países, regiones y
capitales 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ían, la provincia y el municipio en Aragón y la población de
Lugo dejando al usuario la selecció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).
Conclusiones
En este artículo se ha presentado una ontología de unidades administrativas para
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 presentado
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 dominio
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 harmonización del contenido.

Los siguientes pasos de este trabajo serán desarrollar un proceso automá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
respecto de la situación administrativa real.
Agradecimientos
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), 2004. 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. “005. Edmonton, Canada.
[3] R. Irie B. Sundheim. “Resources for Place Analysis”. Fourth International
Conference on Language Resources and Evaluation- LREC2004. 317-320.
2004. Lisbon, Portugal.
[4] ISO 19109. “Geographic information -- Rules for application schema”
International Organization for Standardization (ISO), 2005.
[5] Registro de entidades locales del GDAL. http://www.dgal.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, and B. Martins. A Geographic Knowledge Base for
Semantic Web Applications. In Proc. of the 20th Brazilian Symposium on
Databases, Minas Gerais, Brazil, pages 40–54, October, 3–7 2005.

[9] ISO 19109. “Geographic information -- Spatial referencing by geographic

identifiers” International Organization for Standardization (ISO), 2003.
[10] Guarino, N. Formal Ontologies and Information Systems. Proceedings of
FOIS'98, 3-15. 1998.Trento, Italy
[11] P. Martin, “Using the WordNet Concept Catalog and a Relation Hierarchy
for Knowledge Acquisition”, Proceedings of Peirce'95, 4th International
Workshop on Peirce, University of California, Santa Cruz, August 18, 1995.
[12] C. Fellbaum (Ed). Wordnet, An Electronic Lexical Database. MIT Press.
1998.
[13] J. Bateman. “Upper modeling: Organizing knowledge for natural language
processing”. In Proc. of Fifth International Workshop on Natural Language
Generation, 1990. Pittsburgh, PA.
[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”, England , Ellis. Horwood Workshops, 1992.
[16] ISO 15944-5 Information technology — Business Agreement Semantic
Descriptive Techniques. Part 5: Identification and Mapping of Various
Categories of Jurisdictional Domains. International Organization for
Standardization (ISO), 2005.
[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, 2005, vol. 15, no. 4, pag. 287 — 306.
[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, ESDI Setting the Framework, 2005, 19-22
[21] ISO 19115. Geographic information – Metadata. International Organization
for Standardization (ISO), 19115:2003
[22] ISO 15836. Information and documentation - The Dublin Core metadata
element set. International Organization for Standardization (ISO).
15836:2003.

El impacto de la calidad de los metadatos en los servicios de búsqueda... Sesión 4
El impacto de la calidad de los metadatos en los servicios de búsqueda

de una IDE
Tolosana-Calasanz, Rafael1
Nogueras-Iso, Javier2
Zarazaga-Soria, F. Javier3
University of Zaragoza (Spain) , rafaelt@unizar.es 1, jnog@unizar.es 2, javy@unizar.es 3
ABSTRACT
A medida que se avanza en la investigación y en el desarrollo en el contexto de Información Geográfica y crece el
volumen de metadatos creados, surgen nuevos requisitos en el rendimiento de los sistemas de recuperación de
información geográfica. En este sentido sorprende detectar que los aspectos concernientes a la creación de metadatos
con calidad razonable han recibido relativamente poca atención. En el mundo de la informática se suele utilizar el
acrónimo GIGO (Garbage In, Gargage Out) para describir el problema derivado de utilizar como entrada de un sistema
datos erróneos: la salida será inevitablemente inexacta o incorrecta; es decir, el uso de información de poca calidad
limita el rendimiento de un sistema. Consecuentemente, es imprescindible que los sistemas de recuperación de
información geográfica cuenten con metadatos de calidad para que se puedan obtener buenos resultados en general y, en
particular, en los servicios de búsqueda.
Sin embargo, antes de estudiar concretamente el impacto de la calidad de los metadatos geográficos en los servicios de
búsqueda, hay que analizar el concepto de calidad. La calidad es una cuestión subjetiva, influenciada por la complejidad
de muchos factores humanos. Estos factores dependen de cada individuo y, además, los juicios personales suelen tener
variabilidad a medida que pasa el tiempo y evolucionan las circunstancias de esas personas. La noción de calidad es un
concepto que parece percibirse de forma inmediata y directa pero que a menudo es difícil de argumentar utilizando
razonamientos lógicos. Debido a estas razones, la comunidad científica reconoce que la definición de la calidad de los
metadatos no está exenta de dificultades. Un metadato de buena calidad se define a veces como un registro que es útil
en un número de contextos diferentes, siendo útil también respecto a las estrategias de búsqueda y términos que se
pueden emplear para localizarlo. Otras definiciones son menos ambiciosas y simplemente hablan de adecuación al
propósito perseguido (“fitness for purpose”). Siguiendo estos razonamientos, parece que los metadatos geográficos
serán adecuados para su propósito si describen bien los datos y esas descripciones son útiles para sus usuarios.
Uno de los problemas que los sistemas de recuperación de información geográfica tienen que resolver es proporcionar
al usuario la información que satisface sus requisitos o sus intereses. Un usuario especifica una consulta y el sistema le
devuelve una lista de resultados ordenados de manera que los que se han considerado más relevantes aparecen en las
primeras posiciones de la lista. Los métodos de clasificación o “ranking” que utilizan los sistemas para hacer eso están
basados en cuantificar la similitud entre la pregunta del usuario y el recurso en la colección. Esa cuantificación o
valoración puede interpretarse como una estimación de la relevancia o utilidad de un recurso candidato a satisfacer las
necesidades de un usuario. No obstante, la mayoría de las veces, para el usuario el hecho de especificar sin ambigüedad
sus intereses es difícil o, lo que es peor, hay usuarios que no saben exactamente lo que están buscando. Dos grandes
aspectos pueden considerarse para resolver el problema adecuadamente: en primer lugar, mejoras en las interfaces
gráficas de usuario que faciliten tanto la exploración de la información como la especificación de las consultas y, en
segundo lugar, mejoras en los algoritmos, métodos, estructuras de datos y modelos en el área de la recuperación de la
información que se adapten a las particularidades especiales que presentan los metadatos geográficos.
Lo propuesto en este resumen está dentro del ámbito de este segundo aspecto. A grandes rasgos, las peculiaridades de
los metadatos geográficos son dos principalmente: el componente conocido como espacial, atributo geométrico o
extension espacial que describe la localización, la forma o la orientación; y el componente que describe los datos
geográficos por medio de atributos no espaciales. La recuperación de información teniendo en cuenta el componente
espacial se basa en asignar puntuaciones y elaborar “rankings” o clasificaciones a partir de las características
geospaciales tales como el tamaño, la forma y la distancia. La recuperación de información atendiendo al componente
no espacial puede basarse en técnicas tradicionales de recuperación de información que se apoya en propiedades
estadísticas que se aparecen en los términos de los metadatos. Existe una enorme y extraordinaria variedad de técnicas
al respecto que puede encontrarse en la literatura para resolver el problema, aunque la naturaleza de la información
geográfica debe tenerse en cuenta.

Sesión 4 El impacto de la calidad de los metadatos en los servicios de búsqueda...
Cuando se combinan ambas estrategias de “ranking” se pueden obtener buenas listas de resultados; aunque, en
determinadas circunstancias, podrían no ser suficientemente satisfactorias. Por ejemplo, los catálogos de geodatos están
progresivamente recibiendo metadatos de diferentes organismos, metadatos que fueron creados de forma heterogénea
por equipos de trabajo distintos y con criterios diferentes, metadatos que describirán con mayor o menor fortuna datos
geográficos. En estos casos, los usuarios esperan recibir una lista ordenada de manera que las descripciones que mejor
le convengan aparezcan al principio. Está claro, que aquellas descripciones más ricas y mejor realizadas, esto es,
aquellos metadatos de mejor calidad deberían aparecer antes que los de calidad más baja. En estudios anteriores, hemos
tratado de estimar la calidad de los metadatos geográficos. Pretendemos, a partir de ahora, definir nuevos algoritmos de
“ranking” que incorporen esa estimación y podamos, de esa manera, recuperar información geográfica con mayor grado
de satisfacción.

Ingeniería Ontológica: El camino hacia la mejora del acceso a la... Sesión 4
Ingeniería ontológica: El camino hacia la

mejora del acceso a la información geográfica
en el entorno web
Luis Manuel Vilches Blázquez†, Antonio F. Rodríguez Pascual†, Miguel Ángel
Bernabé Poveda‡
† Subdirección General de Aplicaciones Geográficas.

Tlf: 91 597 9660 Fax: 91 597 9646 e-mail: {lmvilches|afrodriguez}@fomento.es
‡ ETSI Topografía, Geodesia y Cartografía.

Universidad Politécnica de Madrid.
Km. 75 Autovía de Valencia, 28031. Madrid.
Tlf: 91 336 6487. Fax: 91 336 7932. e-mail: ma.bernabe@upm.es
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 semántica en el entorno de las Infraestructuras de Datos
Espaciales.
Esta comunicación, también, presenta un caso de uso en el que se describen las

principales 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.

Sesión 4 Ingeniería Ontológica: El camino hacia la mejora del acceso a la...
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 las Infraestructuras de
Datos Espaciales (IDEs) 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
Organization for Standardization (ISO/TC 211)1, World Wide Web Consortium
(W3C)2 y del Open Geospatial Consortium (OGC)3 con los que se resuelven
problemas derivados de la diferencia de formatos de información, consiguiendo
interoperabilidad, es decir, “la capacidad de comunicarse, para ejecutar
programas, o para transferir datos entre varias unidades funcionales de una
manera que requiera al usuario tener poco o nada de conocimiento de las
características únicas de esas unidades”[3]. 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
diferencias 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 artículo está dirigido a la comunidad geográfica que está interesada en conocer
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-infomación.
En la sección 3 se realiza una introducción al concepto de ontología, citando
algunas 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. Finalmente, en la sección 5 se proporcionan algunas conclusiones y
líneas de trabajo futuro.
1
http://www.isotc211.org/
2
http://www.w3.org/
3
http://www.opengeospatial.org/

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
consulta, recuperación, explotación, actualización y visualización de la geo-
informació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
Espaciales (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
productoras de cartografía en nuestro país, entre las que destacan:
1.- 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 geometrí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
ISO191104 “Geographic Information – Methodology for feature cataloguing”
establece cómo crear y describir de manera normalizada un catálogo de fenómenos.
2.- 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
4
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39965

conocimiento. 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
similitud o la existencia de cierto solape, sin describir más matices.
En la actualidad, existen dos normas internacionales para la construcción de

tesauros, concretamente, la ISO 2788-19865, orientada a la creación y desarrollo de
tesauros monolingües y la ISO 5964-19856, 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)7.
La construcción de tesauros supone una considerable mejora en la estructuració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 (ej.:
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
interoperabilidad semántica, pero aún con muchas limitaciones, consecuencia de la
simplicidad 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
buscadores actuales disponibles.
3 Ontologías
Las limitaciones estructurales, comentadas anteriormente, y la utilización de
diversos vocabularios para describir la información presente en los servicios IDEs,
evidencian diversos problemas que se manifiestan al preguntar e interpretar
resultados 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.
5
6
7
http://www.aenor.es

La Ingeniería Ontológica, surgida de la Web Semántica8, 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 entendimiento 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 supervisión actual.
Circunscribiéndose a las ontologías, una de las definiciones más divulgadas es la

aportada por [6]. 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 reglas 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
sinó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
ontologí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
correspondencias entre fenómenos (ej.: río, river, rivière y fleuve) y entre
diferentes ontologías (ej.: ontología de fenómenos hidrográficos y ontología de las
ciudades)
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.
8
http://www.w3.org/2001/sw/

A diferencia de las formas de organización actuales, la construcción de ontologías

se presenta como una buena solución para alcanzar la interoperabilidad semántica
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,

generando formas comunes y compartidas de ver el mundo, y ayudar a que los
sistemas gestionen más información que datos, consecuencia de que el experto ha
cedido 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
recuperació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 criterios:
- La Directiva Europea Marco del Agua9 .
- Criterios semánticos, es decir, clasificación acorde a los significados.
- La clasificación y estructura reflejada en el Proyecto SDIGER10 (IDE para
la gestión de las cuencas de los ríos Adour-Garonne y Ebro) [12].
- 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 tenido
en cuenta multitud de fuentes de información a diferentes escalas (EuroGlobalMap,
EuroRegionalMap, Bases Cartográficas Numéricas del IGN, Diccionarios de datos
de productores autonómicos, Tesauro de la UNESCO, GEMET, etc).
9
http://europa.eu.int/eurlex/pri/en/oj/dat/2000/l_327/l_32720001222en00010072.pdf
10
http://www.idee.es/sdiger/

En esta ontología aparecen alrededor de 100 conceptos relevantes pertenecientes 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: Subclase-
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” [13].
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. [13] Un ejemplo de esta relación aparece en la Figura 2.
Depósito
Capacidad: float
Profundidad: floal
subclase subclase
Estanque Piscina Abrevadero Charca

Uso: Ornamental Uso: Recreacional Uso: Ganado Uso: Riego
Descomposición-Disjunta
Fig. 1. Ejemplo de Descomposición-Disjunta
Una Descomposción-Exhausitva de un concepto C es un conjunto de subconceptos

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
[13]. La Figura 3 muestra un ejemplo de este tipo de relación.

Aguas_Marinas
Navegable: Tipo_Navegable
subclase subclase subclase subclase
Aguas_Costeras Aguas_Territoriales Zona_Contigua Area_Economica_Exclusiva Alta_mar

Distancia: 1 mila Distancia: 12 millas Distnacia: 24 millas Distancia: 200 millas Distancia: +200 millas
Descomposción-Exhausitva
Fig. 2. Ejemplo de Descomposció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 4.
Aguas_Continentales
subclase
Aguas_Superficiales Aguas_Subterráneas
Partición
Fig.3. Ejemplo Partición
El siguiente paso del proceso de construcción de esta ontología fue la construcción

de un diccionario de conceptos hidrográficos, consecuencia de la ausencia
generalizada de definiciones en las fuentes consultadas. De esta manera, se
contribuye 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 potente y eficaz. Un ejemplo de esta relación en la Figura 1.
desemboca
Rio Mar
0..* 0..1
Fig.4. Ejemplo de relación ad hoc.
El último paso conducirá a la implementación de esta ontología en la IDEE.

Contribuirá a gestionar esta información de manera más eficiente y autónoma,
consiguiendo resolver las dificultades estructurales de la IG y armonizar un marco
común con el que caminar hacia la interoperabilidad semántica.

5 Conclusiones y trabajo futuro

La consideración actual de interoperabilidad se circunscribe a la homogeneizació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,
procesamiento y explotación de la IG. Este hecho dará lugar a la apertura de
nuevos horizontes 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 ontología

marco mediante la definición de constantes, axiomas formales y reglas. Ademá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.
6 Referencias
[1] L. McKee, Who wants a GDI?, In Geospatial Data Infrastructure – Concepts,
cases and good practice, New York, Oxford University Press, 2000, pag. 13-
24.
[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, 1993, 5(2), pag.199-220.
[7] Y. Bishr, “Overcoming the semantic and other barriers to GIS
interoperability” Geographic Information Science, 1998, 12(4), pag.199-314.

[8] F. Harvey, W. Kuhn, H. Pundt, Y. Bishr, “Semantic interoperability: A central

issue for sharing geographic information” The Annals of Regional Science,
1999, 33(2), pag. 213-232.
[9] A. P. Sheth, “Changing focus on interoperability in information systems from
system, syntax, structures to semantics”. Interoperating geographic
information systems. 1999. Boston, Kluwer Academic Publishers.
[10] C. Batini, S. Ceri, B. Navathe, Conceptual Database Design. 1992. Redwood
City, California, The Benjamin/Cummings publishing Company.
[11] Neches et al., “Enabling technology for knowledge sharing”. AI Magazine,
1991, 12(3), pag.16-56.
[12] 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, ESDI Setting the Framework. 2005. pag 5-
7. Alghero, Sardinia (Italia).
[13] Corcho O, Fernández-López M, Gómez-Pérez A, López-Cima. A Building
legal ontologies with METHONTOLOGY and WebODE. Law and the
Semantic Web. Springer-Verlag. 2005, Editor: Bran Selic. ISBN: 3540250638.

Aspectos de modelos e infraestructura de servicios para el soporte de... Sesión 4
Aspectos de modelos e infraestructura de

servicios para el soporte de un servicio
nacional estándar de nomenclátor en Web
F.J .López-Pellicer, R. Bejar,

F. J. Zarazaga-Soria, P. R. Muro-Medrano
Departamento de Informática e Ingeniería de Sistemas

Tlf: 976 762 134 Fax: 976 761 914. e-mail: iaaa@unizar.es
Resumen
Este artículo describe cómo se concibe un nomenclátor para los Sistemas de
Información Geográfica, las Bibliotecas Digitales, los Procesos de
Estandarización Toponímica y la Cartotoponimia y cómo influye en su
publicación en una Infraestructura de Datos Espaciales.
Palabras clave: IDE, SIG, Biblioteca Digital, Procesos Estandarización,

Nomenclátor.
1 Introducción
Un nombre geográfico es un nombre propio usado consistentemente en un
lenguaje para referirse o identificar a un lugar, fenómeno o área que tenga una
identidad reconocible en la superficie de la Tierra [1] cuya “principal función
(...) es servir como etiqueta, y como tal, su significado semántico, aun cuando
sea evidente, es una consecuencia de su rol como etiqueta” [2]. Una colección
de nombres geográficos organizada de una determinada forma es un
nomenclátor. Una de esas formas es el nomenclátor nacional estándar cuyo
propósito final es normalizar el uso de nombres geográficos en las
administraciones públicas. En este nomenclátor encontramos fenómenos
naturales, poblaciones humanos, divisiones políticas, áreas administrativas,
rutas de transporte y estructuras creadas por el hombre -millones de nombres a
JIDEE06 Jornadas Técnicas de la IDE en España

Castellón de la Plana / Castelló de la Plana, España, 18-20 octubre de 2006.

Sesión 4 Aspectos de modelos e infraestructura de servicios para el soporte de...
nivel nacional -. Solo la microtoponimia no utilizada en la administración o sin

relevancia cultural suele quedar fuera de esta colección.
En una Infraestructura de Datos Espaciales (IDE), entendida como la colección
de tecnologías, políticas y acuerdos institucionales que facilitan la
disponibilidad y acceso a datos espaciales [3], nomenclátor es el nombre
genérico del conjunto de acuerdos, estándares e infraestructuras que dan
soporte al acceso a colecciones de nombres geográficos y a servicios basados en
dichas colecciones. El nomenclátor nacional estándar puede publicarse a través
del punto de acceso a la IDE correspondiente acompañado de los
correspondientes estándares e infraestructuras. Por ejemplo, en la IDE de
España se está elaborando una propuesta de Modelo de Nomenclátor de España
[4] con el fin de facilitar el intercambio de nomenclátores nacionales estándar
entre las administraciones y la implementación de servicios de nomenclátor.
Cómo sean esos acuerdos, estándares e infraestructuras es el resultado del
equilibrio entre los distintos tipos de usuario del nomenclátor nacional
estándar: los Sistemas de Información Geográfica, las Bibliotecas Digitales,
los Procesos de Estandarización Toponímica y la Cartotoponimia. Para cada
una el nomenclátor tiene un rol distinto: un Sistema de Referencia, un
Diccionario Geográfico, un Nomenclátor Estándar o un Índice de Topónimos.
El problema que se afronta en una IDE es organizar de tal manera la publicación
del nomenclátor nacional estándar de tal forma que satisfaga de forma adecuada
cada uno de estos roles.
Este artículo tiene dos objetivos. El primero es describir dichos modelos de
nomenclátor, señalar las similitudes y diferencias, y las implicaciones sobre las
infraestructuras. El segundo es proponer una infraestructura que facilite la
publicación de un nomenclátor teniendo en cuenta las consecuencias de los
requerimientos detectados. Ambos objetivos se analizan en el contexto de la
publicación del servicio nacional estándar de nomenclátor mediante una IDE.
Este artículo se organiza de la siguiente manera. En el apartado 2 se define qué
rol tiene un nomenclátor para cada una de estas áreas. En el apartado 3 se
describe las necesidades que dan origen a estos roles. En el apartado 4, se
muestra que cada uno de los modelos tiene características y peculiaridades
propias que complican que solo a partir del nomenclátor nacional se cumpla una
su adecuada publicación en la IDE. En el apartado 5 se afronta cómo una IDE
debe publicar un nomenclátor nacional estándar y cómo cada una de estas
publicaciones responde a cada una de dichas áreas. En el apartado 6 se describe
una solución que se está utilizando para publicar nomenclátores. Finalmente, en
el apartado 7 se establecen algunas conclusiones.

2 Roles de un nomenclátor
Tal como se ha indicado, hay cuatro áreas que requieren vistas diferentes del
nomenclátor nacional estándar: los Sistemas de Información Geográfica (SIG),
las Bibliotecas Digitales (BD), los Procesos de Estandarización Toponímica
(PET) y la Cartotoponimia (CT).
Para los SIG un nomenclátor es el conjunto de estándares e infraestructuras
que dan soporte al uso de nombres geográficos como identificadores espaciales
con tipo dando lugar a Sistemas de Referencia por Identificadores Geográficos.
Un ejemplo es el nomenclátor definido en el estándar ISO 19112 [5]. En estas
condiciones, por ejemplo, la geometría de una finca puede ser sustituida por
una representación compacta, comprensible y multiuso: “parcela catastral Coso
6, Zaragoza”.
En una DB un nomenclátor es un diccionario geoespacial de nombres
geográficos. Sus componentes esenciales son nombres geográficos, huellas
espaciales y tipos. Dentro de esta aproximación el nomenclátor puede tomar la
forma de tesauro de nombres geográficos. Un ejemplo del primer tipo es el
nomenclátor de Alexandria Digital Library (ADL Gazetteer) [6] y de los
segundos es el Tesauro Getty de Nombres Geográficos (TGN) [7]. Los nombres
contenidos se utilizan para georreferenciar indirectamente recursos
electrónicos [8]. Por ejemplo, el área aplicación de una norma del
ayuntamiento de Zaragoza publicada en su página Web puede ser descrita como
“World; Europe; España; Aragón; Zaragoza; Zaragoza” según TGN o
“Zaragoza; Spain” indicando que es de tipo “populated places” según ADL
Gazetteer.
Como resultado de un PET el nomenclátor es el medio por el cual se disemina
los nombres geográficos oficiales establecidos. El modelo que sirve de base a
estos nomenclátores ha sido asentado en a lo largo de las Conferencias de las
Naciones Unidas en la Estandarización de Nombres Geográficos que han tenido
lugar desde 1967 [1]. Así un nomenclátor es una lista en un orden lógico de los
nombres geográficos organizados por divisiones administrativas. Si el nombre
geográfico es oficial debe adjuntar información adicional como el tipo de
entidad geográfica identificada, su localización y extensión, así como nombres
alternativos y variaciones en la ortografía, y para cada nombre su lenguaje.
También se considera aceptable incluir información como la elevación, el
número de habitantes, su localización en hojas de series cartográficas oficiales,
información gramatical, transliteraciones, etc. Dada su complejidad, en 1977 se
propuso la elaboración de nomenclátores concisos como paso intermedio al
nomenclátor nacional. En el caso de España [4], este es una lista que contiene
el nombre geográfico preferente aplicado cada una de las entidades culturales o

naturales con nombre. Cada entrada incluye, además, otros nombres de uso
restringido y aquellas denominaciones oficiales anteriores de menos de 100
años, cada una con su idioma respectivo y su fuente de procedencia. Para
identificar la entidad a la que se aplica se indica su tipo, las divisiones
administrativas hasta el segundo orden que la incluyen, un punto representativo
así como la hoja de una serie cartográfica donde este punto se sitúa.
Finalmente, para la CT un nomenclátor es un índice de topónimos, la lista de
nombres geográficos normalizados de una unidad administrativa en la que
junto a cada nombre oficial hay al menos la suficiente información adicional
que permite localizarlo en forma escrita en un mapa e identificar a qué entidad
representada gráficamente se refiere. En mapas digitales, esta lista de topónimos
tiene prácticamente los mismos atributos que la información representada
gráficamente: una etiqueta, un atributo de tipo y un punto, sin información
adicional. Hay que tener en cuenta que la CT es un proceso orientado a mostrar
gráficamente en un mapa las formas escritas de una entidad geográfica
acompañando a su representación gráfica mediante un punto, una línea o un
área [1].
3 Necesidades cubiertas por un nomenclátor

Hemos visto en el apartado anterior los cuatro roles de un nomenclátor: un
Sistema de Referencia, un Diccionario Geográfico, un Nomenclátor Estándar o
un Índice de Topónimos. Estos roles está relacionados con necesidades como
poder referenciar espacialmente en forma humana – la traducción a coordenadas
es relevante -, describir espacialmente en forma humana – la traducción a
coordenadas no es relevante -, minimizar los costes por errores de interpretación
y reforzar la autoridad nacional.
Los nomenclátores SIG, creados por expertos en información geográfica y en
geomática, son el resultado de la necesidad de normalizar la descripción
indirecta de propiedades espaciales mediante nombres geográficos. Los
nomenclátores BD, creados principalmente por biblioteconomistas e
historiadores, surgen de la necesidad de catalogar documentos que pueden
tener referencias espaciales futuras, contemporáneas e históricas. Es decir, los
nomenclátores SIG contienen información cuyo uso es referencial mientras que
los nomenclátores BD contienen información cuyo uso es descriptivo.
La información contenida en un nomenclátor PET no sirve para un uso práctico
descriptivo o referencial. En realidad tiene objetivos que dan satisfacción a
necesidades sociales en lo económico y en lo político. El económico es derivado
de la reducción de costes derivados de errores en el uso los nombres geográficos

por administraciones, empresas y ciudadanos. El político es resultado del

aumento de la autoestima nacional tanto mediante la protección y/o
recuperación de la herencia lingüística como por el refuerzo de la autoridad
sobre el territorio al establecer que nombres son de uso oficial. Entre otros, este
resultado se ve en forma de mapas en los que aparecen las formas oficiales y/o
estandarizadas de una entidad.
Los nomenclátores CT solo tienen como objetivo ser reflejo de las formas
escritas presentadas en un mapa. En ese sentido cubren las mismas necesidades
que los PET pero circunscritos al ámbito de la comunicación visual de
localizaciones.
Pero estas necesidades se pueden satisfacer parcialmente con nomenclátores
producidos para otros usos. En este sentido un nomenclátor es un artefacto
fácilmente reutilizable (Figura 1).
Figura 1Un mismo nomenclátor tiene muchos usos
4 Comparación de los modelos de nomenclátor

En los dos apartados anteriores se han revisado los roles y las necesidades que
cubren los nomenclátores en diferentes áreas. En este apartado resumimos las
principales características que comparten los modelos de contenidos de
nomenclátor y proponemos qué contenidos debería tener el nomenclátor que se
publicara mediante una IDE para dar satisfacción a las diferentes vistas.
Tomemos como modelos prototípicos el ADL Gazetteer Content para las BD,

el Modelo de Nomenclátor de España para los PET, el estándar ISO 19112 para
los SIG y la capa de topónimos de la mayoría de las Bases Topográficas para la
CT. La Figura 2 muestra dichos modelos de una forma simplificada.
Figura 2 Diversos modelos de nomenclátor
Para estos ejemplos el nombre y su aplicación a entidades naturales y culturales

es un elemento inseparable. De hecho se habla de forma indistinta de catálogos
de nombres y catálogos de instancias. Por ejemplo, en el estándar ISO 19112 se
define un nomenclátor como “catálogo de instancias (de localización) de una o
más clases de fenómenos que contienen cierta información sobre posición” y
un poco más adelante lo define también como un “catálogo de identificadores
geográficos que describen instancias de localización” o abstracciones del
mundo.
El tratamiento de los nombres es muy variado. El diccionario geográfico y el
nomenclátor estándar tienen la información más amplia, destacando en
particular el idioma. En ambos casos se incluyen nombres alternativos. No se da
el caso en los sistemas de referencia y en los índices de topónimos.

Solo para describir e identificar es necesario un tesauro de tipos. En cuanto la

tipología, solo el sistema de referencia define simultáneamente un sistema de
tipos. En los diccionarios geográficos en forma de tesauro, el tesauro de tipos
forma parte de él. En el resto de los casos los tipos vienen dados.
La localización espacial se describe de diferentes formas. El diccionario
geográfico y el sistema de referencia requieren de la extensión y en su ausencia
de la posición, mientras que los nomenclátores estándar y los índices de
topónimos se conforman con una posición aproximada. Estos utilizan para
completar la información espacial referencias a hojas de series cartográficas y a
unidades administrativas.
El aspecto temporal o es sobredimensionado o es implícito. El aspecto temporal
en el diccionario geográfico tiene como objetivo la descripción histórica:
conocer para cada atributo su valor a lo largo del tiempo. En el sistema de
referencia no hay aspecto temporal tal cual, solo es una marca de validez. El
aspecto temporal en los nomenclátores estándar y los índices de topónimos esta
implícito en su condición de “foto fija” asociada a la fecha de su publicación.
Las relaciones jerárquicas de contención son relevantes para los sistemas de
referencia y los diccionarios geográficos si se presentan como tesauros.
Considerando lo anterior, si se creara un único repositorio del que se sirvieran
todos los servicios del nomenclátor estándar este debería ser una al estilo de las
BD pero incluyendo: un tesauro de tipos y la huella de la entidad siguiendo los
requisitos de los sistemas de referencia, los puntos de localización con la idea de
ser utilizados en mapas y un tratamiento diferenciado a las relaciones de
jerarquía según sean de división o de contención.
5 Papel del nomenclátor estándar en una IDE

En este apartado se analiza las implicaciones de publicar un nomenclátor
nacional estándar mediante el punto de acceso de una IDE. Desde nuestro punto
de vista las implicaciones están condicionadas principalmente por las
necesidades y objetivos de la visión PET del nomenclátor. El resto de las
visiones condicionan el diseño de servicios específicos.
Hay que tener en cuenta que dado que en el contexto europeo el concepto de
IDE es el resultado acumulado en el campo de los datos geográficos de una
continuada serie de Directivas de la Comunidad Europea, aquellas que traten de
nombres geográficos condicionarán cómo se publica este nomenclátor. La más
importante de todas ellas es la propuesta de directiva INSPIRE. En ella, los
nombres geográficos definidos como cualquier rasgo geográfico o topográfico

de interés público o histórico son un conjunto de datos espaciales que las

autoridades públicas deben de mantener y difundir. INSPIRE todavía no ha sido
aprobada por lo que las reglas de implementación no han sido definidas. Es
previsible que las reglas de implementación para los nombres geográficos siga
las recomendaciones de los PET por tres motivos: los nomenclátores estándares
PET se suelen publicar en los puntos de acceso de las IDE nacionales para su
difusión, suelen coincidir la autoridad la que administra la IDE y con la que
elabora el PET, y ambas participan en el proceso de decisión de INSPIRE.
Según los PET el éxito de un nomenclátor nacional estándar está en la
capacidad de dar a autoridades, empresas y público en general información útil
sobre los nombres oficiales de una forma rápida y sencilla. Por ello, para una
óptima difusión los nombres normalizados, la IDE debe proporcionar servicios
de catálogo que usen nombres geográficos estándar para describir, servicios de
proceso que los utilicen referenciar y servicios de datos que produzcan mapas
donde aparezcan rotulados.
En consecuencia, el punto público de descubrimiento, acceso y distribución de
datos y servicios espaciales de la IDE nacional debe, en relación con los
nomenclátores estándar:
• Describir los tipos de nomenclátores que hace disponibles, qué servicios
los proveen y qué modelo de distribución se aplica. Por ser datos de
naturaleza oficial se debe considerar en la política de distribución la
política de notificación y difusión de las novedades, las correcciones y
las actualizaciones.
• Difundir el modelo de contenido de cada uno de ellos así como su
implementación en diferentes formatos de intercambio estandarizados.
Estos formatos de intercambio deben recoger el contenido en función
del servicio y del las necesidades usuario. No tienen las mismas
necesidades de información las administraciones, las empresas o los
ciudadanos.
• Facilitar su descubrimiento publicando su existencia en los servicios de
catálogo y su difusión haciéndolo accesible mediante servicios de datos
(colecciones de datos, elaboración de mapas digitales) y servicios de
proceso, en particular el servicio de nomenclátor. Estos servicios
deberían poderse integrar en aplicaciones desarrolladas por terceros.
Notar que lo relacionado con servicios de búsqueda y catálogo está
influenciado por la visión BD mientras que la elaboración de mapas
digitales está influenciado por la visión CT.
• Si se ha descentralizado la autoridad o la gestión toponímica el nodo de

la IDE y en función de las políticas de descentralización y

actualización, se establecerán procesos de harvesting y búsquedas en
cascada.
• En función de la política de distribución, establecer servicios de
harvester para mantener sincronizadas las copias remotas de los
usuarios de forma incremental.
• En función de la política de notificación, establecer servicios de
suscripción-notificación para notificar los cambios en el contenido de
los nomenclátores.
• Finalmente, como parte de la política de difusión, proporcionar
aplicaciones de nomenclátor, tanto de demostración como para usuarios
avanzados, que permitan realizar preguntas basadas en nombres
geográficos utilizando mapas como medio para transmitir el contexto
espacial de las respuestas.
La visión SIG del nomenclátor es determinante en el diseño de los Servicios de
Nomenclátor entendidos como parte de los Servicios de Proceso (SP) de la IDE.
La funcionalidad que deberían ofrecer en base al nomenclátor estándar estaría
formada por:
• La traducción de nombres geográficos a sus coordenadas geoespaciales;
es un papel similar a los Servicios de Transformación de Coordenadas,
salvo que uno de los sistemas de referencia que intervienen en la
transformación es un Sistema de Referencia Basado en Identificadores
Geográficos.
• El soporte, e incluso la sustitución en su lugar, a otros SP como los
Servicios de Geocodificación y los Servicios de Tesauro Geográficos.
• El soporte a Servicios de Datos basados en localización como los
Servicios de Directorio.
• El soporte a Servicios de Catálogo que realicen búsquedas basadas en
descripciones espaciales textuales.
Un ejemplo de la arquitectura resultante se puede ver en la Figura 3.

Figura 3 Arquitectura básica con harvesting
6 Nuestra solución
En los aparatados anteriores hemos analizado los modelos y servicios
relacionados con la publicación de un nomenclátor estándar en una IDE. En este
apartado proponemos una infraestructura orientada a facilitar la publicación de
un nomenclátor teniendo en cuenta las consecuencias de los requerimientos
detectados.
Nuestra propuesta es un sistema libremente basado en los diccionarios
geográficos en el que hay al menos tres tipos de elementos de primera clase o
recursos (Figura 4): el nombre, la entidad y el tipo. Este sistema utiliza el
vocabulario Dublín Core [9] como base de una ontología para definir las
propiedades de cada uno de estos recursos. Además, utilizando esta misma
ontología se describen tanto las fuentes de datos como Con esta ontología se
definen adicionalmente fuentes de colecciones de nombres y pasarelas entre el
modelo del repositorio y los modelos de cada una las fuentes. Utilizando esta
información se diseñan y construyen las transformaciones que a partir de
elementos de la colección fuente se crean entidades (features) con su tipo (type)
y sus topónimos (names). De igual manera se han establecido pasarelas y
transformaciones estables entre el modelo del repositorio y los modelos de
vistas optimizadas para cada uno de los formatos y servicios de la IDE.

Figura 4 Modelo básico
Figura 5 Correspondencias
Por ejemplo (ver Figura 5), utilizando dichas pasarelas a partir de los datos del
Nomenclátor Geográfico del IGN se puebla la base de conocimientos. Esta
labor es dependiente de la fuente, y es posible que en sucesivas recolecciones se
tenga que realizar ajustes (set once, use once). La ventaja aparece al transformar
de la base de conocimientos a los modelos de cada uno de los servicios (set
once, use many), que es estable mientras que la base de conocimientos no sufra
un cambio sustancial.
De forma resumida, el sistema esta formado por procesos e adaptación y carga,
uno por cada tipo de fuente, un framework de transformación al modelo de

Dublín Core, procesos de transformación a modelos optimizados para diferentes

servicios y una serie de tareas de limpieza, integración de fuentes,
deduplicación y aumentación de información orientados a mejorar y enriquecer
la colección de nombres (Figura 6)
Figura 6 Explotación del nomenclátor
7 Conclusiones
Se pueden señalar las siguientes conclusiones:
• El diseño del nomenclátor en una IDE es complejo por tener que
responder a necesidades de descripción, referenciación, normalización y
dibujo, por señalar algunas. El modelo resultante es sobrecargado.
• Por la particular preponderancia del nomenclátor PET, la mayor parte
del contenido publicado va a ser consistente con sus requisitos. El
modelo PET no es adecuado ni para describir, ni para referenciar,
aunque si vale para la producción de mapas digitales. En consecuencia
las visiones BD y SIG van a tener problemas de adecuación de los
datos, pero no así la visión CT.
• Las necesidades del PET implica servicios adicionales en una IDE
como servicios de harvesting y de búsqueda en cascada sobre

colecciones de datos (que no de metadatos), y servicios de suscripción-

notificación.
• Debido a la complejidad del problema se necesita una infraestructura
especializada e integrar colecciones de nombres y generar cada una de
las vistas. Además este sistema debe servir para, partiendo de los
nomenclátores PET, integrar información de otras fuentes y poder
aumentar la calidad de las visiones BD y SIG.
Agradecimientos
El trabajo de F. J. López-Pellicer (ref. B136/2006) ha estado parcialmente financiado
por una beca del Gobierno de Aragón.
Referencias
[1] United Nations Group of Experts on Geographical Names, UNGEGN (2006),
Manual for the national standardization of geographical names, United Nations
Publication, New York.
[2] Kadmon, N. (2000), Toponymy: the lore, laws and language of geographical names,
Vantage Press, New York.
[3] Douglas D. Nebert, G., ed. (2004), Developing Spatial Data Infrastructures: The
SDI Cookbook, Global Spatial Data Infrastructure Association.
[4] Alcázar, A., Azcárate M. (2006), Situación actual del Nomenclátor Geográfico
Conciso de España, en Technical Papers of the 23rd Session of the UNGEGN, UNGEG
[5] AENOR (2005),UNE-EN ISO 19112:2005 Información geográfica. Sistemas de
referencia espaciales por identificadores geográficos.
[6] Alexandria Digital Library Gazetteer, (1999-) , Santa Barbara CA: Map and Imagery
Lab, Davidson Library, University of California, Santa Barbara. Copyright UC regents.
http://www.alexandria.ucsb.edu/gazetteer/
[7] Getty Thesaurus of Geographic Names. The J. Paul Getty Trust.
http://www.getty.edu/research/conducting_research/vocabularies/tgn/
[8] Hill, L.L. (2000), Core Elements of Digital Gazetteers: Placenames, Categories, and
Footprints, en ECDL '00: Proceedings of the 4th European Conference on Research
and Advanced Technology for Digital Libraries, Springer-Verlag, London, pp. 280—
290.
[9] Dublin Core Metadata Initiative (2005), DCMI Abstract Model.
http://es.dubincore.org/documents/abstract-model/

Sesión 4 Infraestructura de Datos Espaciales en el Instituto Cartográco...
Infraestructura de Datos Espaciales en el Instituto Cartográfico

Valenciano. Proyecto Cart@.
Rodríguez Barreiro, J. Z., Conti Bueno, L.

{zoilo_jor, conti_lui}@gva.es
Instituto Cartográfico Valenciano

Av. de los Naranjos s/n Universidad Politécnica de Valencia. Ed. 9B.
460021 Valencia
Resumen.
El Instituto Cartográfico Valenciano, a través del proyecto Cart@, ha

desarrollado un sistema de información que, en línea con la propuesta de directiva
INSPIRE, pretende difundir y liberalizar el uso de la información geográfica tanto en
instituciones públicas como en el conjunto de la sociedad, proporcionar las
herramientas necesarias de localización y visualización de los datos geográfico, así
como catalogar y dar publicidad a la información espacial mediante la generación de
metadatos actualizados.
1. Introducción.
El sistema Cart@ del Instituto Cartográfico Valenciano consiste en un sistema

de información integral destinado a satisfacer las necesidades cartográficas tanto del
propio Instituto como de los usuarios de cartografía en general a través de un
completo acceso a los productos y servicios del ICV, ya sea mediante el visor
cartográfico, ya sea mediante el catálogo de metadatos, combinando en ambos casos
criterios espaciales y alfanuméricos. Y siempre con la posibilidad de integrar en el
visor nuevas capas procedentes de servidores de mapas WMS externos, así como de
servir los mapas del ICV a cualquier otro portal capaz de incorporar capas WMS.
Cart@ se integra de este modo en el marco de referencia definido por el GDSI

(Global Spatial Data Infrastructures) a nivel internacional, por la futura directiva
INSPIRE (Infrastructure for Spatial Information in Europe) a nivel europeo y por el
grupo de trabajo de la Comisión de Geomática del Consejo Superior Geográfico para
el establecimiento de la Infraestructura de Datos Espaciales de España a nivel
nacional.
Además, el proyecto Cart@ incluye el desarrollo de una herramienta para la

generación, gestión y mantenimiento de los metadatos de los productos del ICV,
fundamentales para el correcto funcionamiento del sistema, puesto que integran y dan
coherencia a la información cartográfica.
El sistema ha sido desarrollado junto con la empresa Aurensis S.A. utilizando

librerías, componentes y lenguajes de programación basados en software libre, a
excepción de las librerías Latino Objects empleadas para transformar la cartografía a
formatos de CAD cuando el cliente así lo solicite.

Infraestructura de Datos Espaciales en el Instituto Cartográco... Sesión 4
2. Modelo de datos y estructura de la base de datos.
El modelo de datos para almacenar y gestionar la información que maneja el

sistema Cart@ se ha desarrollado utilizando el SGBDR (Sistema de Gestión de Base
de Datos Relacional) de licencia GNU PostgreSQL (http://www.postgresql.org) con el
módulo espacial PostGIS incorporado para el almacenamiento y gestión de la
geometría de los datos geográficos vectoriales.
En cuanto a la información ráster (ortoimágenes y fotogramas), así como los

productos previamente elaborados para la venta (mapas en formato pdf) se
almacenarán en ficheros fuera de la base de datos.
El modelo conceptual de datos, como se observa en la figura 1, se estructura

en cuatro bloques fundamentales relacionados entre sí, sirviendo de conexión entre la
parte cartográfica y la parte comercial los metadatos de los orígenes de
datos/productos.
Figura 1: Modelo conceptual de datos.
El bloque de cartografía corresponde a las diferentes capas vectoriales

continuas, a las ortofotos, a los MDT, etc.
Cada uno de estos elementos cartográficos se relaciona con un origen de datos

almacenado en la base de datos si se trata de cartografía vectorial o en ficheros fuera
de ella si se trata de imágenes. A su vez, a partir de estos orígenes de datos se
obtienen las capas que el usuario puede gestionar mediante el visor cartográfico.
Como se observa, es posible que cada capa visor esté formada por diferentes
orígenes de datos. Por ejemplo la capa del visor cartográfico Canales y acequias de la
serie CV10 (cartografía a escala 1:10.000 de la Comunidad Valenciana) está formada
por cuatro orígenes de datos en la base de datos: Acequias_CV10, Canales_CV10,
Acequias_CV10_txt y Canales_CV10_txt.

El bloque de metadatos es el que conecta los orígenes de datos con los

productos solicitados por los clientes, dado que cada origen de datos y cada producto
se relacionan de forma unívoca con un metadato.
Como último bloque del modelo conceptual de datos aparece el bloque

comercial, dentro del cual cada producto o productos se relaciona de muchos a
muchos con los pedidos. Los clientes se relacionarán de uno a muchos con los
productos, puesto que un mismo cliente puede obtener varios productos.
En lo que se refiere a la arquitectura de la base de datos, se describe de forma

somera en la figura 2. Como se observa, existen en realidad dos bases de datos sobre
PostgreSQL:
Figura 2: Estructura de la base de datos.
La primera de ellas denominada CAPAS contiene un único esquema de datos

compuesto por las capas cartográficas continuas. Se trata de una estructura de tablas
dinámica puesto que el número de capas/tablas no es fijo al poderse añadir capas de
una nueva serie o reestructuras las de las series cartográficas existentes.
En cuanto a la segunda base de datos denominada ICV2, contiene dos

esquemas diferentes: uno primero que contiene las tablas del subsistema del visor
cartográfico y las del subsistema de compras, y un segundo esquema completamente
diferente con las tablas de los metadatos que implementan el modelo de la ISO 19115.
A diferencia de la base de datos CAPAS, en ICV2 ambos esquemas tienen una
estructura de tablas fija.

En cuanto a las relaciones entre subsistemas, como se estableció en el modelo

conceptual de datos, las capas cartográficas de CAPAS se relacionan con las capas
del visor cartográfico de ICV2 (a través de los orígenes de datos), y éstas a su vez se
relacionan con el subsistema de compras a través de los metadatos.
El establecimiento de un modelo de datos como el descrito supone para el

Instituto Cartográfico Valenciano una gran evolución en su modo de almacenar y
gestionar la información cartográfica vectorial, pasando de la gestión en ficheros en
formato de CAD y divididos por hojas cartográficas a disponer de una base de datos
geográfica con capas de cartografía continua.
Esta migración ha supuesto la realización de numerosos procesos de

tratamiento masivo de los datos cartográficos del ICV, que han sido realizados en su
mayor parte mediante el paquete de software FME (Feature Manipulation Engine) de
la empresa canadiense Safe Software (http://www.safe.com), consistente en una
colección de herramientas ETL (Extract, Transform and Load) para el tratamiento de
información cartográfica.
Las operaciones realizadas a partir de los dgn de las hojas han sido de forma
somera las siguientes:
— Definir y generar una serie de capas continuas de todo el territorio

agrupando los elementos geográficos de forma coherente.
— Comprobación de la consistencia topológica a nivel de capa
(conectividad, elementos cerrados, etc.).
— Asignar unos atributos básicos a cada uno de los elementos.
En lo que se refiere a la toponimia de los elementos geográficos, se ha incluido

en un campo de cada tabla/capa de la base de datos, sin embargo, a efectos de
representación en el visor cartográfico se han conservado las capas de toponimia
directamente procedentes del dgn, evitando de este modo el etiquetado automático de
los elementos por parte del servidor de mapas.
Estas operaciones se han aplicado a las dos series de referencia completas

que actualmente tiene el Instituto Cartográfico Valenciano: la serie CV10 y la serie
CV300, realizándose en breve para las zonas del territorio en los que ya existe la serie
CV05 a escala 1:5.000.
Además, para evitar el salto de escalas tan significativo existente entre las
cartografías a escala 1:300.000 y a escala 1:10.000, se ha realizado una
generalización de la serie CV10 a escala 1:100.000, de modo que para la navegación
en el visor cartográfico el salto entre escalas sea más gradual.

La adopción de un modelo de datos como el descrito es imprescindible tanto

para el funcionamiento del sistema Cart@ como para la gestión futura de la
información en el ICV. Así, la base de datos geográfica proporciona una infraestructura
de datos adecuada para el mapping dinámico del visor cartográfico y de la IDE, y
además posibilita el recorte de cartografía a la carta por parte de los usuarios, que de
este modo no dependen de la tradicional distribución por hojas.
3. Arquitectura del sistema.
En cuanto a la arquitectura del sistema se describe en la figura 3. Como se

observa, se basa en dos servidores:
Figura 3: Arquitectura del sistema.
— icvmapas o servidor de aplicaciones. Contiene el geoportal del ICV

construido utilizando el servidor de aplicaciones web Apache Web Server
(www.apache.org) y PHP (www.php.net) como lenguaje de programación
para el desarrollo de las funcionalidades. El servidor de mapas empleado
ha sido MapServer (http://mapserver.gis.umn.edu/). Además, el servidor de
aplicaciones contiene los servicios de mapa WMS de la IDE.
— icvdatos o servidor de datos. Almacena las dos bases de datos

anteriormente descritas (con los datos vectoriales y los metadatos), y por
otra parte, los ficheros de información ráster y los preparados para la
venta.
Ambos servidores ejecutan el sistema operativo Linux.
Los técnicos del ICV actúan como clientes internos trabajando contra ambos
servidores en Intranet, mientras que los usuarios externos del geoportal se conectarán

a través de Internet, al igual que los servicios de la CECA cuando un cliente externo
desee realizar una compra pagando con tarjeta de crédito.
4. Componentes del sistema Cart@. Portal web o geoportal.
El geoportal es uno de los pilares básicos del sistema Cart@, siendo el que
permita el acceso a través de Internet a los servicios y productos del ICV. La
visualización de la información cartográfica estará basada en las especificaciones de
interoperabilidad del OGC (Open Gis Consortium), sentando las bases para la puesta
en marcha de la IDE de la Comunidad Valenciana, en la que el ICV es el nodo
regional.
El geoportal está compuesto por varios módulos (visor cartográfico, servicios

WMS, catálogo de metadatos, módulo de vuelos fotogramétricos y comercio
electrónico), cuyas características se describen a continuación.
4.1. Visor cartográfico.
Se trata del módulo que se visualiza por defecto al entrar en el geoportal. Se

emplea fundamentalmente para la visualización gráfica de los productos cartográficos
del ICV, aunque está íntimamente relacionado con el módulo de comercio electrónico,
dado que es sobre el visor donde se indica el área geográfica y las capas de interés
para el cliente.
Navegación
Medición
Opciones
de
selección y
recorte
Compra
Localizador
Información
Ayuda
Conexión a
otros
servidores IDE
Impresión
Información
cartográfica Transparencia
Figura 4: Interfaz del visor cartográfico.

Para la elaboración de los mapas en tiempo real que permitan un mapping

interactivo se utiliza, como se ha indicado, el servidor de mapas MapServer que es
compatible con los estándares OGC (WMS, WFS no transaccional, WCS, GML). Los
mapas se servirán en formato WMS.
El visor se estructura, tal como se aprecia en la figura 4. En la zona derecha se

encuentran las herramientas; la zona central ha sido dedicada a la ventana de
visualización; la parte derecha a la estructura de capas, a las leyendas dinámicas y a
la localización por localidad; la parte inferior se dedica a la información y opciones
cartográficas; finalmente, en la esquina inferior derecha se encuentra la herramienta
de transparencia y la conexión a otros servidores IDE.
4.1.1. Gestión de capas.
La visualización de capas se gestiona de forma automática en función de la

escala de visualización, dando preferencia por norma general a las capas de imagen, y
superponiendo a éstas las capas vectoriales fundamentales. El sistema, además
cuenta con un sistema de restricciones por escala, de modo que el usuario no pueda
cargar capas de mucho peso a escalas pequeñas, evitando la excesiva ralentización
del sistema.
Aparte de la cartografía que se muestra por defecto según la escala, el usuario

puede gestionar todas aquellas capas cuya visualización esté permitida para esa
escala mediante el árbol de capas (figura 5), apareciendo el resto deshabilitadas. Para
facilitar la gestión de las capas, éstas aparecen agrupadas de forma coherente por
serie cartográfica o por tipo de producto, siguiendo una estructura de niveles
jerárquicos que pueden desplegarse o replegarse según las necesidades.
Figura 5: Gestión de las capas mediante el árbol.

4.1.2. Herramientas de navegación e información.
Para la navegación por la cartografía se dispone de las tradicionales

herramientas de navegación, incluyendo el zoom a la visualización anterior y la
localización por coordenadas (figura 6).
Además, el visor contiene un mapa guía o localizador dinámico, sobre el cual

se pueden realizar zooms cuyo ámbito geográfico se asigna de forma automática a la
ventana principal de visualización, lo cual incrementa sobremanera la comodidad para
el desplazamiento de unas zonas a otras del territorio.
Figura 6: Mapa guía o localizador.
En cuanto a las herramientas de información consisten en una utilidad de

identificación de elementos geográficos que muestra los datos asociados a los mismos
en la base de datos y en la herramienta de ayuda detallada de utilización del sistema.
4.1.3. Buscador de localidades.
Para la localización rápida por localidades se ha habilitado un buscador

realmente versátil. Permite la restricción geográfica en la búsqueda, ya sea por
provincia, por comarca, por municipio o cualquier combinación de estas tres entidades.
Además es posible aplicar un filtro en base a una
serie de caracteres que se introduzca.
El resultado será una lista de todas las

localidades, ya sean capitales de municipio o
entidades de población, que cumplan con los
criterios establecidos. Además, la búsqueda se
realiza sobre una base de datos con todos los
nombres posibles que identifiquen a una localidad,
puesto que incluye el nombre en castellano, en
valenciano, nombres no oficiales pero usados
tradicionalmente, etc.
Figura 7: Buscador de localidades.

Por último, el resultado se muestra por orden alfabético pero dando prioridad a
las capitales municipales sobre las entidades de población. Cuando se selecciona un
ítem de la lista se centra en la ventana de visualización.
4.1.4. Medición de distancias y superficies.
Estas herramientas poseen una funcionalidad variable en función de la

configuración de otras utilidades de la aplicación, puesto que no sólo sirven para la
medición. Ésta es utilidad más básica de las mismas y consiste en medida de
distancias y superficies. En este último caso, existen diversos modos de definir la
superficie de interés: mediante un rectángulo, mediante un polígono irregular y
mediante pares de coordenadas.
Figura 8: Medición de superficies irregulares o determinación del área de recorte.
4.1.5. Herramientas de recorte y selección. Definición de la información a obtener.
Las herramientas de superficie pueden servir además para definir un recorte o

para seleccionar una serie de hojas cartográficas. Ello depende del estado de la
utilidad Tipo de recorte, lo cual está íntimamente ligado con la compra de cartografía,
puesto que el recorte o selección definirá exactamente qué quiere obtener el usuario.
Por tanto, en el proceso de compra de cartografía, los primeros pasos se

definen desde el visor cartográfico, y son por este orden:
— Definir el tipo de recorte, que puede ser poligonal o una serie cartográfica
(figuras 8 y 9).
Si el tipo de recorte especificado es poligonal, la superficie definida

determinará el recorte de la cartografía del área establecida (figura 8). En
este caso el sistema realizará la intersección de las capas del árbol cuyo
carrito se haya activado con el área definida.

Por el contrario, si en Tipo de recorte se especifica una de las series

cartográficas del ICV (figura 9), automáticamente pasa a visualizarse la
malla de hojas de dicha serie, y el área que se defina seleccionará las
hojas con las que intersecte. En este caso, el sistema realizará el recorte
de las capas que se indiquen cruzándolas con los límites de las hojas
cartográficas señaladas.
Figura 9: Selección de hojas de una serie cartográfica.
— Indicar en el árbol de capas las capas que se quieren comprar activando el

icono del carro de la compra existente junto a cada una (figura 5).
— Seleccionar la herramienta simbolizada con un carro de la compra en la

barra de botones, con lo que los productos indicados se añaden al carro de
la compra de la tienda virtual.
4.1.6. Obtención de cartografía maquetada e impresión.
Para la obtención de información cartográfica de forma gratuita el sistema

contempla dos herramientas: la de impresión, que simplemente permite imprimir la
zona visualizada con las capas visibles en ese momento, y una utilidad más completa
que realiza la maquetación del ámbito geográfico visualizado y genera un PDF en
formato A4 que el usuario puede descargarse.
10

Figura 10: Cartografía gratuita maquetada.
4.1.7. Transparencia de las capas.
La herramienta de transparencia permite dar un mayor o menor grado de

transparencia/opacidad a las capas poligonales o de imagen.
Para asignar transparencia a una capa determinada se activa el icono

correspondiente existente en el árbol de capas junto al nombre de la misma. De este
modo, dicha capa pasa a visualizarse sobre todas las demás y con el grado de
transparencia/opacidad que se establezca de forma dinámica.
Se trata de una herramienta de gran utilidad para la comprobación de cambios,

puesto que se puede comparar la ortofoto actual con ortofotos históricas, para la
detección de zonas cartográficas a actualizar, comprobación de los usos del suelo
cartografiados, etc.
4.1.8. Sistemas de referencia.
El sistema Cart@ permite visualizar y obtener la información cartográfica en

diferentes sistemas de referencia, tanto en ED50 como en ETRS89. En ambos
sistemas hay posibilidad de obtener las coordenadas en UTM y en geodésicas. Si se
opta por UTM como sistema cartográfico de representación es posible realizar la
proyección tanto en el huso 30 como en el 31.
11

4.1.9. Leyenda de las capas.
Para identificar los diferentes elementos geográficos, además de la herramienta

de información puede emplearse la leyenda, que se actualizará de forma dinámica a
medida que se activan y desactivan capas.
4.2. Servicios WMS.
El modelo de datos de Cart@ se ha diseñado teniendo en cuenta que su base

de datos se utilizará como Base de Datos georeferenciada de la IDE de la Comunidad
Valenciana. Para ello el servidor de mapas empleado, MapServer, se ha configurado
para que sirva mapas en formato WMS de forma para que sean consumidos por el
visor cartográfico u cualquier otro portal que sea capaz de incorporar capas WMS. A
su vez, el visor cartográfico permitirá añadir al mapa que el usuario está visualizando
nuevas capas que provengan de servidores de mapas WMS externos.
Para acceder a la información de servidores externos se emplea la herramienta

Servidores, mediante la cual será posible, o bien acceder a uno de los servidores
disponibles en una lista existente por defecto, o bien agregar un nuevo servidor
externo asignándole un nombre y definiendo su url (figura 11).
Figura 11: Conexión a servidores externos.
Una vez agregado el servidor se indican las capas del mismo que se desean
visualizar. Como resultado se agregarán al árbol de capas del ICV y se visualizarán de
forma automática (figura 12).
12

Figura 12: Visualización y gestión de capas de servidores externos.
Por otra parte, cualquier portal capaz de incorporar capas WMS podrá
conectarse al servidor de Cart@ y visualizar junto con las suyas las capas que ofrece
el ICV mediante este servicio.
4.3. Catálogo de metadatos.
El catálogo de metadatos permite localizar cualquiera de los productos del ICV,

ya sea actual u obsoleto, a través de consultas a sus metadatos. Para ello se han
habilitado una serie de condiciones tanto gráficas como alfanuméricas, y una vez
obtenida la lista de resultados que las cumplen será posible visualizar el producto,
acceder a sus metadatos o añadirlo al carro de la compra.
Figura 13: Catálogo de metadatos.
13

La condición gráfica de búsqueda de productos viene dada por un visor

cartográfico sencillo con las capas imprescindibles para posibilitar la localización. La
extensión geográfica visible en cada momento en dicho visor indicará el área en la
cual se realizará la búsqueda (figura 13).
Además, mediante un localizador de topónimos habilitado a tal efecto será

posible localizar el topónimo de interés y utilizar el ámbito geográfico del mismo como
restricción espacia para la búsqueda. Dicho
localizador trabaja contra la base de datos
toponímica de la cartografía a escala 1:10.000
de la Comunidad Valenciana, que cuenta con
más de 50.000 topónimos.
Uno de los problemas existentes a la

hora de localizar un topónimo consiste en las
repeticiones, puesto que los más comunes
aparecen diversas veces a lo largo del territorio.
Para solventarlo, en los topónimos repetidos, el
localizador permite elegir el término municipal
en el que se desea localizar, restringiéndose al
ámbito espacial del mismo.
Figura 14: Localizador de topónimos.
En lo que se refiere a las restricciones alfanuméricas sobre la base de datos de

metadatos, las que se han implementado son (figura 13): Tipo de producto, temática,
escala, fecha de edición, responsable de los datos y nombre. Esta última actúa como
un filtro para localizar los productos en base a la cadena alfanumérica especificada.
Estas condiciones pueden especificarse todas o cualquier combinación de

ellas.
Como resultado de la búsqueda realizada en base a estas condiciones

espaciales y alfanuméricas se obtiene un listado de los productos que las satisfacen
(figura 15). Sin embargo, como se observa, dada la gran cantidad de productos
existentes, el listado no contiene la totalidad de productos del ICV que cumplen la
condición, sino que este primer nivel de búsqueda se restringe a los niveles de serie y
de conjunto de datos.
Si se selecciona, por ejemplo una serie, ya se muestran todas las hojas de la

serie contenidas en el ámbito espacial especificado.
14

Figura 15: Listado resultado de la búsqueda (primer nivel).
Como se observa, para cada producto existen diversas opciones representadas

por iconos (figura 15). La primera de ellas consiste en ver un resumen de los
metadatos del producto; la segunda en ver los metadatos completos (figura 16); la
tercera en localizar de forma somera el producto sobre el visor sencillo del catálogo de
metadatos; la cuarta posibilidad consiste en visualizar el producto en el visor
cartográfico; la última opción consiste en añadir el producto al carro de la compra.
Estas opciones no están siempre habilitadas al completo, puesto que una serie
completa no puede añadirse al carro de la compra, un producto obsoleto no puede
visualizarse en el visor cartográfico, etc.
Figura 16: Índice de los metadatos de un producto.
15

4.4. Módulo de vuelos.
El módulo de vuelos del sistema Cart@ ha sido diseñado para que los usuarios
puedan tener acceso a las imágenes de los vuelos fotogramétricos del ICV. Del mismo
modo, será posible obtener la información de calibración de la cámara y los
parámetros de orientación. Puesto que se trata de un producto con muy diferentes
usos, el ICV ha decidido tratarlo de modo especial, de forma que las peticiones se
realicen por un canal diferente al resto de productos. Así, será el propio usuario el
encargado de determinar a través de la aplicación cuales son los fotogramas de su
interés.
Al acceder al módulo de vuelos el cliente indicará sobre el mapa de la

Comunidad Valenciana qué zona le interesa. El sistema le indicará los vuelos
existentes en la misma con sus principales características, de modo que sea el usuario
quien indique el vuelo que se ajusta a sus necesidades. Entonces el sistema centrará
la visualización en dicho vuelo (figura 17).
Figura 17: Zoom al vuelo fotogramétrico seleccionado.
Mediante las herramientas de navegación es posible acercarse a la zona de

interés, observándose los diferentes centros de proyección de los fotogramas.
Entonces, con la herramienta de selección el usuario puede indicar los fotogramas que
desea, que se irán añadiendo a una lista (figura 18). Además, a cada selección de
fotograma se destacará el ámbito geográfico que cubre la imagen. Si con ello no fuera
suficiente, existe también la opción de visualizar el fotograma que se indique en un
formato reducido.
16

Figura 18: Ejemplo de fotogramas seleccionados.
La lista de fotogramas así definida alimentará de forma automática un

formulario que el cliente deberá completar con sus datos. Este formulario, mediante la
herramienta Enviar petición será enviado por correo electrónico al Instituto
Cartográfico Valenciano, que tramitará la solicitud.
4.5. Comercio electrónico.
El portal permite tanto a clientes esporádicos como a habituales realizar la

compra de productos del ICV directamente a través de Internet.
Figura 19: Productos añadidos al carro de la compra.
17

Como se ha indicado en puntos anteriores, el proceso de compra se inicia en el

visor cartográfico indicando qué capas se quiere comprar y el ámbito geográfico. Esta
información se añade entonces a la cesta de la compra. Ésta realiza el cálculo
automático del presupuesto (detalle y total), pudiendo el cliente gestionar los productos
eliminándolos o añadiéndolos.
Además, el cliente tiene la posibilidad de solicitar presupuestos, los cuales se

irán acumulando en su cuenta, pudiendo ser rescatados en cualquier momento, y
decidiendo cuáles va a transformar en compra y cuáles no.
Las diferentes formas de pago que admite el ICV y las diversas formas de
entrega de los productos son restringidas de forma adecuada por el sistema,
posibilitando para cada forma de pago los modos de entrega correspondientes.
El módulo de comercio electrónico incorpora para el pago a través de Internet

una Plataforma de pago electrónico que utilizará los servicios de transacciones de la
CECA (Confederación Española de Cajas de Ahorros). Esta plataforma garantiza la
confianza y seguridad en la interrelación ya que el trámite se realiza directamente a
través de los servidores de la CECA sin intervención por parte del ICV.
Una vez se ha realizado, el sistema elabora el producto solicitado y lo

almacena en un servidor ftp del ICV. Entonces simplemente se le comunica al cliente
vía correo electrónico de que la información solicitada ya está disponible.
5. Componentes del sistema Cart@. Punto de venta.
El punto de venta será una extensión del sistema Cart@, ofreciendo además
un conjunto de funcionalidades de acceso restringido a usuarios internos del Instituto.
Por otra parte, el sistema almacenará en la base de datos toda la información

de interés para la gestión contable del ICV, desde los datos del cliente, hasta las
facturas, pasando por los pedidos, presupuestos, descuentos, etc. Además, la
explotación conjunta de toda esta información orientará en buena medida la política
comercial del Instituto.
Así, las ventas presenciales se realizarán por parte de los usuarios internos del
ICV mediante Cart@, abandonando el sistema actual, de modo que todas las ventas
se encuentren reflejadas en un único sistema contable, de facturación, etc.
Por otra parte, los usuarios de Cartoteca podrán gestionar los pedidos
realizados, puesto que sólo una parte de ellos se realizarán de forma automática por
Internet. Para cada uno de estos pedidos presenciales, por teléfono u otra vía diferente
de Internet, será posible indicar los diferentes estados del producto (elaborado,
pagado, entregado), así como carcelar los pedidos que no han derivado finalmente en
compra.
18

Figura 20: Gestión de los pedidos.
Los pedidos que no se gestionen totalmente a través de Internet conllevan un

trabajo adicional de grabación en CD o DVD, o de impresión previo a su entrega, ya
sea en la propia ventanilla del ICV o a domicilio. Esta gestión final de los productos
también es facilitada por el sistema Cart@: la impresión de mapas la realizará de
forma automática una vez el personal de ventas indique que se ha pagado el producto;
en cuanto a las grabaciones, los productos se almacenarán en carpetas con su
referencia y el nombre CD o DVD según la grabación se deba hacer en uno u otro
soporte en función del peso de los archivos correspondientes.
6. Mantenimiento y administración del sistema.
El mantenimiento y la administración del sistema se realizarán mediante dos

herramientas implementadas sobre Microsoft Access que atacan directamente a las
tablas de PostgreSQL.
La primera herramienta permite actualizar los parámetros de las capas de los

visores de los diferentes módulos del sistema (visor cartográfico, catálogo de
metadatos y módulo de vuelos). Es decir, se podrá establecer los orígenes de datos de
cada capa, entre que escalas debe estar visible, si debe ser visible por defecto o no, si
debe tener transparencia por defecto, etc (figura 21).
Del mismo modo se podrán añadir nuevas capas a los visores sin más que
indicarles uno o varios orígenes de datos y especificar todos los parámetros para su
correcta visualización.
19

Figura 21: Herramienta de administración de capas.
Una segunda herramienta de mantenimiento/administración permite la gestión

interna del subsistema de compras. Así, permite establecer los parámetros de los
puntos de venta, gestionar la lista de usuarios y de pedidos y fundamentalmente la
lista de productos. De este modo será posible incluir nuevos productos con sus
características específicas (precio, IVA, metadatos, ficheros asociados) y modificar los
parámetros de los existentes.
Figura 22: Herramienta de administración de productos.
20

7. Conclusiones.
El sistema Cart@ es la apuesta del Instituto Cartográfico Valenciano por

acercar los productos cartográficos tanto a los tradicionales usuarios de este tipo de
información como al resto de la sociedad.
Para ello ha liberalizado al máximo de sus posibilidades la cartografía de la que

dispone, posibilitando la visualización de toda ella a través del visor cartográfico, así
como la localización y acceso a sus metadatos a través del catálogo. Además se
ofrece la posibilidad de descarga gratuita de cartografía, así como el acceso a las
capas del ICV desde servidores capaces de integrar capas WMS.
Todo ello compatibilizado con la, a día de hoy, ineludible venta de productos
cartográficos, realizada a través de una tienda virtual realmente versátil que permite a
los clientes una gran variedad de modos de solicitar los datos de su interés en base a
recortes sobre capas continuas.
21

SESIÓN 5
DEMOS
199
GeoMedia-OGC y Google Earth. (Intergraph) Sesión 5
GeoMedia-OGC y Google Earth
Autor principal
Nombre : Josep
Apellidos: Fornons Castellarnau
Intergraph como miembro estratégico del OGC, está evolucionando la tecnología

GeoMedia, manteniéndola continuamente adaptada a los estándares del OGC.
Asimismo, nuestro entorno de publicación de información geográfica en Internet,

basado en GeoMedia WebMap y Web Publisher versión 6.0 permite la publicación de
cualquier entorno de trabajo GeoMedia como servicio WMS, WFS.
A lo largo del último año se ha producido un fenómeno espectacular en la

distribución de información espacial a través de navegadores gratuitos de cobertura
mundial, como pueden ser el de Google, Yahoo o de Microsoft.
Con la llegada de estos productos se ha conseguido interesar por la información

geoespacial a un número creciente de usuarios y es previsible continúe dicha
tendencia.
Intergraph es consciente de esta necesidad por lo cual dispone de integraciones

que permiten integrar información geospacial siguiendo especificaciones OGC en el
entorno Google Earth

Sesión 5 Desarrollo de un cliente Web OGC rico. (Prodevelop)
Desarrollo de un cliente Web rico-OGC

M. Montesinos†, J. Carrasco†, C. Larrea†
† PRODEVELOP
C/ Conde Salvatierra, 34. 46004 Valencia
http://www.prodevelop.es
{mmontesinos, jcarrasco}@prodevelop.es; clarrea@collaborative.es
Resumen
El auge de los servicios de interoperabilidad OGC está generando una amplia

difusión de aplicaciones cliente que hacen uso directa o indirectamente de este tipo
de servicios.
Actualmente existen dos grandes grupos de clientes OGC: clientes ligeros basados
en tecnología Web y clientes pesados basados en aplicaciones de escritorio.
En este artículo mostramos las características y ventajas de un cliente Web OGC

utilizando técnicas de Rich Internet Applications (RIA) para conseguir acercar las
capacidades tradicionales de aplicaciones de escritorio a entornos Web..
Palabras clave: SIG, software libre, Free and Open Source Software (FOSS),
OGC, cliente, Rich Internet Applications (RIA).
1 Introducción
Desde la aparición del primer Sistema de Información Geográfica –Canadian
Geographical Information System CGIS– [1], hasta la situación actual, los Sistemas
de Información Geográfica han sufrido una vertiginosa evolución desde el punto de
vista de la arquitectura de aplicaciones.
Tras la aparición en la escena tecnológica de los servicios Web, gracias al esfuerzo

integrador de la comunidad internacional, se fundó el Open GIS Consortium –
nacido del proyecto GRASS como la Open GRASS Foundation–, posteriormente
rebautizado como Open Geospatial Consortium (OGC) [2], del que destacan sus
estándares de interoperabilidad. En este artículo nos centraremos en los servicios
de publicación de información geográfica.

Desarrollo de un cliente Web OGC rico. (Prodevelop) Sesión 5
La aparición de servicios de publicación de mapas utilizando técnicas de servicios

Web ha reestructurado la utilización de los sistemas de información geográfica. Ha
permitido la creación de Infraestructuras de Datos Espaciales –IDE–, que entre
otros servicios proporcionan información a otras IDEs o servidores de mapas, así
como a clientes de IDEs consumidores de estos servicios.
El éxito de la utilización efectiva de una IDE depende entre otros factores de la

apariencia y capacidades de los clientes de dicha IDE con los que interactúa un
usuario. Actualmente existen varias opciones, destacando la utilización de
herramientas GIS de escritorio o clientes HTML. Las herramientas GIS de
escritorio ofrecen una alta riqueza funcional, pero adolecen de la universalidad y
alcance de los clientes HTML, quienes por el contrario carecen de una atractiva
oferta funcional e interactiva.
El estado del arte en el desarrollo de aplicaciones Web permite hoy en día

enriquecer las capacidades de interacción y procesamiento de los clientes Web,
disminuyendo la separación existente entre clientes ligeros y pesados. Las
aplicaciones RIA –Rich Internet Application–, concebidas en 2002 por Jeremy
Allaire [3], son aplicaciones Web que incorporan gran parte de las funcionalidades
y características de las aplicaciones de escritorio tradicionales, manteniendo en el
lado del servidor aspectos como datos, estados, … Hoy en día se consideran como
una tecnología que forma parte de la Web 2.0 –término acuñado por Tim O’Reilly
[4].
Uno de los objetivos de Prodevelop ha sido innovar en la arquitectura de desarrollo

de clientes Web de mapas, incorporando los últimos avances en RIA.
2 Entorno
El sistema desarrollado se enmarca dentro de un proyecto de desarrollo real, donde
junto a una aplicación de gestión Web se requiere disponer de un conjunto de
funcionalidades de gestión espacial de forma integrada.
Desde el punto de vista tecnológico el sistema desarrollado debía de cumplir una

serie de características heredadas del sistema de gestión:
• Servidor de base de datos relacional: Oracle 9i.

• Arquitectura de aplicaciones Web Java 2 Enterprise Edition –J2EE,

actualmente renombrado a JavaEE –Java Enterprise Edition– [5]
• Servidor de aplicaciones Web: IBM WebSphere.
• Utilización de software libre en la medida de lo posible.
• Interfaz amigable y rica en funcionalidades.
3 Arquitectura
Para el diseño de la arquitectura se han identificado y construido cuatro
componentes principales:
• Georrepositorio: Repositorio de información espacial y alfanumérica.

• Servidor OGC: Servicios de publicación de mapas.
• Servidor Web: Componentes de servidor.
• Cliente rico: cliente sobre navegador Web con capacidades RIA.
Georrpositorio
Almacena en base de datos toda la información de gestión y espacial del sistema en
un único repositorio integrado. El motor de base de datos utilizado ha sido Oracle
Spatial.
La carga y actualización de datos se realiza directamente desde AutoCad, a través

de un paquete de Oracle desarrollado ex profeso y una extensión de AutoCad que
se comunica con este paquete. El resultado es la disposición de cartografía
actualizada por parte de delineantes sin necesidad de formación en nuevas
herramientas. Como herramienta de validación y consulta espacial se ha utilizado
gvSIG [6], atacando a los servicios WMS creados que se describen posteriormente.
Servidor OGC
Servicios de publicación de mapas conforme a los estándares OGC WMS, WFS(-
T) y WCS. El producto utilizado ha sido deegree para todos los estándares, que
permite ser desplegado en un contenedor J2EE.
Servidor Web
Componentes de la aplicación Web desplegados en el servidor de aplicaciones.
Contiene dos módulos:

• Servidor OpenLaszlo [7]1.

• Aplicación Web J2EE encargada de la comunicación con los módulos
alfanuméricos, gestión de permisos, persistencia de estado, asistencia al
cliente rico en la generación de peticiones WMS, SLD, … Desarrollada
siguiendo el patrón MVC2 –Modelo Vista Controlador–, sobre el
framework Apache Struts [8].
Cliente Rico
Frente a la opción de utilizar un cliente ligero basado en DHTML, se ha optado por
crear una RIA (Rich Internet Application) implementando un cliente basado en
Flash. Para el desarrollo se ha utilizado OpenLaszlo [7], un proyecto open-source
apoyado por IBM, de forma combinada con AJAX (Asynchronous JavaScript And
XML) [9] para acelerar el rendimiento.
La arquitectura del sistema es la siguiente:
Figura 1. Arquitectura del sistema completo
1
Ver Cliente Rico.

4 Ventajas de un cliente rico

El cliente resultante permite un amplio alcance de usuarios finales, pues funciona
sobre navegadores Web, de forma integrada en otras aplicaciones. Por otro lado la
potencia y riqueza de un cliente Flash ofrece una serie de funcionalidades en un
ambiente multiplataforma, que van mucho más allá de los tradicionales clientes
Web ligeros,
La implementación del cliente OGC rico nos ha permitido conseguir disponer de

las siguientes ventajas:
• Funcionalidad enriquecida: utilización de comportamientos no

alcanzables con widgets HTML estándar (componentes ya creados o
“creables” como paneles y cortinas desplegables, menús, animaciones
fluidas, drag-and-drop, transparencias, interactividad y procesamientos
avanzados en local, …).
• Rendimiento elevado: Todas las generaciones de mapas, leyendas,
consultas, etc., se realizan por medio de AJAX o XML, sin necesidad de
renderizar de nuevo la página.
• Open source: todo el desarrollo se realiza con herramientas free-and-
open-source.
• Fácil despliegue: Utilización de aplicación Flash, disponible en el 97,3%
de los navegadores según Millward Brown [10], sin problemas de
funcionamiento en plataformas diferentes, y sin necesidad de instalación
de la aplicación.
Figura 2. Censo de principales plug-ins instalados en navegadores

• Características avanzadas de desarrollo: facilidades adicionales respecto a

JavaScript –programación orientada a objetos con abstracción, herencia,
…–, basado en estándares, interfaz de usuario declarativa, …
La utilización de un cliente OGC de mapas RIA basado en Flash no era muy

conocida al principio del proyecto, pero ya comienzan a verse ejemplos de
aplicaciones de esta tecnología como Trippermap [11], FlashEarth [12] o las
referencias de S. Crawford [13].
En definitiva, se presenta una aplicación web rica que da un paso más en la

exposición de servicios de mapas basados en estándares, con una experiencia de
uso altamente satisfactoria para el usuario final, no sólo en funcionalidad, sino
también por la independencia tecnológica del proveedor del servicio.
5 Aspecto del cliente rico desarrollado

El cliente rico desarrollado se incrusta dentro de una aplicación Web, con el
siguiente aspecto:
Figura 3. Aspecto del cliente enriquecido incrustado en una aplicación real

El cliente creado consta de los siguientes componentes:
Figura 4. Principales componentes del cliente rico
Figura 5. Aspecto de paneles laterales desplegables

6 Conclusiones
La apuesta por la innovación en la aplicación de las últimas tecnologías disponibles
en el desarrollo Web de aplicaciones a un cliente de mapas de servicios OGC, ha
dado como resultado un producto de un alto valor añadido, valorado muy
positivamente por el usuario –Ente Público Portos de Galicia de la Xunta de
Galicia– por su interactividad y facilidad de uso.
La implementación de un cliente de mapas basado en RIA permite acercar las

capacidades de un cliente ligero tradicional a las de un cliente pesado, ofreciendo
una nueva alternativa en la parte cliente de las IDEs, que seguro va a tener un papel
crucial en los próximos años.
Referencias
[1] Dueker, K.J. (1979) “Land Resource Information Systems: A review of
fifteen years experience”.
[2] Open GIS: http://www.opengeospatial.org/
[3] Jeremy Allaire (2002), Macromedia. “Macromedia Flash MX. A next-
generation rich client”
http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf
[4] Tim O'Reilly (2004) Web 2.0:
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-
web-20.html
[5] Java Enterprise Edition: http://java.sun.com/javaee/
[6] Proyecto gvSIG: http://www.gvsig.gva.es
[7] Proyecto OpenLaszlo: http://www.openlaszlo.org/
[8] Proyecto del framework Apache Struts: http://struts.apache.org/
[9] Asynchronous JavaScript And XML (AJAX):
http://www.uberbin.net/archivos/internet/ajax-un-nuevo-acercamiento-a-
aplicaciones-web.php
[10] Millward Brown (Adobe 2006). Censo de aplicaciones Flash:
http://www.adobe.com/products/player_census/flashplayer/
[11] Trippermap: http://www.trippermap.com/
[12] FlashEarth: http://www.flashearth.com/

[13] S. Crawford (FOSS4G 2006):

http://www.foss4g2006.org/contributionDisplay.py?contribId=169&sessi
onId=50&confId=1

GEOPISTA: una aproximación al E-Government en la Administración... Sesión 5
GEOPISTA: una aproximación al E-Government en la Administración

Local
Autores: Antonio Hoyuela Jayo, Fernando Tricas Lamana, Pablo Gallardo Konczanin
GEOPISTA se ha planteado como una plataforma para integrar servicios de la

administración general del Estado en relación a la administración local (censo de
población, consulta y mantenimiento de Catastro, integración de cartografías base de
distintas fuentes, etc…). Además, a través de su implementación a nivel local, permite
la posibilidad de esta información (callejero, plan urbanístico, infraestructuras, etc…)
ser servida al ciudadano como parte de una IDE local a través de WMS y otros servicios
web.
GEOPISTA además desarrolla un conjunto de funcionalidades específicas de

competencias asociadas a la administración local como la gestión de licencias,
concesiones y autorizaciones, la gestión del patrimonio municipal o la actualización de
la información urbanística o de infraestructuras con una interface amigable y
personalizada para un conjunto de variables y dominios estandarizados a distintos
niveles. GEOPISTA para ello ha intentado adaptarse a los estándares más actuales de la
información geográfica. Así, podemos considerar GEOPISTA como un Sistema de
Información Territorial y como una herramienta de colaboración administrativa entre
los principales organismos públicos con competencias en el territorio: Dirección
General de Catastro, Instituto Nacional de Estadísticas, Instituto Geográfico Nacional
Diputaciones Provinciales, Mancomunidades, Ayuntamientos, etc...
Se han desarrollado estas funcionalidades a través de servicios Web que son una
colección de protocolos y estándares que sirven para intercambiar datos entre
aplicaciones permitiendo que software desarrollado en lenguajes de programación
diferentes y ejecutadas sobre cualquier plataforma puedan utilizar estos Servicios Web
para intercambiar datos en redes de ordenadores como Internet. Para asegurar la
interoperabilidad y extensibilidad de estos servicios es necesaria la adopción de
estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de
la arquitectura y reglamentación de los servicios Web.
Al igual que es necesaria la regulación mediante estándares de los servicios Web para
información alfanumérica es también necesaria la existencia de estándares y protocolos
que regulen el intercambio de información gráfica. Para ello el Open GeoSpatial
Consortium ha definido un conjunto de especificaciones que regulan la implementación
de los Servicios Web Geográficos (OWS: OGC Web Services). Estas especificaciones
incluyen actualmente los Web Map Service (WMS), Web Feature Service (WFS) y
Web Coverage Service (WCS) y pretenden definir fundamentalmente aspectos como las
peticiones – respuestas que se intercambian, parámetros que se deben incluir, lenguajes
utilizados en el intercambio, etc. GeoPISTA ha sido diseñada e implementada de
acuerdo a estos estándares, de tal forma que garantiza la interoperabilidad con otras
aplicaciones que igualmente los satisfagan, tales como el servicio WMS de Catastro o la
base de datos IDEE del IGN.

Sesión 5 GEOPISTA: una aproximación al E-Government en la Administración...
El futuro del proyecto pasa por consolidar esta línea de trabajo ampliando los servicios
normalizados de las administraciones públicas involucradas en la gestión local y, al
mismo tiempo, adaptando dichos contenidos y competencias a las casuísticas
regionales, provinciales o locales a través de las herramientas de customización
disponibles o en vías de desarrollo dentro del proyecto. Entre estas administraciones
están el INE, el Catastro, las administraciones urbanísticas regionales, etc… La
disponibilidad de estos servicios no será exclusiva del proyecto GEOPISTA y podrá
extenderse a otras aplicaciones que bajo el paradigma de la estandarización de la
información y de las tecnologías de la información geográfica (OGC) así lo permitan.
En definitiva, este proyecto, en la medida en que ha conseguido dirigir hacia un objetivo
común los intereses de los principales actores en la producción, intercambio y
explotación de información geográfica, puede considerarse un primer paso hacia una
IDE en el ámbito de la Administración Local.

Soluciones para la construcción de Geoportales: SIG al alcance de... Sesión 5
"Soluciones para la construcción de Geoportales: SIG al alcance de todos"

Ponente: Beatriz Alonso Wehrli, Mario Pisa
Resumen:
Las soluciones para difundir metadatos y mapas en la red han evolucionado para ofrecer servicios de
funcionalidad GIS como posicionamiento, análisis, edición. El futuro de la tecnología GIS está en la red
con soluciones escalables que permitan construir "Portales Geográficos" para ofreces servicios GIS y
acercar la tecnología al usuario.
Los Geoportales están incorporando la última tecnología para que el usuario aproveche al máximo la
potencia de los Sistemas de Información Geográfica con los objetivos:
- Accesibilidad de la información geográfica desde un portal. ¿Que es un portal? ¿Que servicios

incorpora? La construcción de servicios de metadatos, integración con servicios avanzados de búsqueda
de información.
- Consulta de la información geográfica mediante la publicación de mapas, servicios de descarga, y la
publicación de información 3D. La revolución de poder visualizar la información en 3D en la red ha
abierto una nueva dimensión en los Portales Geográficos
- Explotación de la funcionalidad SIG en Internet desde las integración de los análisis más básicos hasta
los más avanzados:
- Servicios de posicionamiento, geocodificación, rutas y búsquedas espaciales
- Servicios de análisis de información geográfica, todas las posibilidades en la red: edición, análisis
raster, geoprocesamiento de información
En las Sistemas de Información es cada vez más importante construir sistemas capaces de interactuar con
otros, independientes de la plataforma tecnológica, robustas y escalables y que exponen su funcionalidad
a través de la red. Los servicios WEB son la solución para compartir funcionalidad en la red y permiten
desplegar sistemas complejos en entornos corporativos y distribuidos. Por ello las soluciones de ESRI
incorporan la posibilidad de trabajar con las últimas tendencias tecnológicas (SOA, WEB 2.0, etc.) para la
construcción de servicios WEB integrados en los Portales Geográficos.
Posibles sesiones tecnológicas:
- Herramientas para el desarrollo de servicios SIG en Internet. Desde el punto de vista más práctico entrar
en el detalles del desarrollo de servicios WEB utilizando las últimas tendencias tecnológicas.
- Documentación de la información desde ArcGIS. Documentación desde ArcMap con el editor NEM
integrado, almacenamiento en la Base de Datos Relacional y Gestión.
- Herramientas para la construcción de Portales SIG: Solución que integra el módulo de administración,
módulo de publicación de metadatos y módulos de usuario (herramientas de búsqueda en catálogo,
exploración de metadatos y acceso a servicios). Herramientas para la construcción de catálogos
distribuidos.

SESIÓN 6
IDE REGIONALES Y SECTORIALES
215
IDEAndalucía abierta al público. Sesión 6
III JORNADAS TÉCNICAS IDEE, JIDEE´06

Castellón 18,19 y 20 de Octubre de 2006
IDEAndalucía abierta al Público. Resumen de Comunicación.
En la última reunión del Grupo de Trabajo de la IDEE perteneciente a la

Comisión de Geomática del Consejo Superior Geográfico, celebrada en
Pamplona el pasado 24 de Marzo, se informó de la reciente puesta en
explotación al público de la Infraestructura de Datos Espaciales de Andalucía
(http://www.andaluciajunta.es/IDEAndalucia/).
Esta iniciativa, en la que se trabaja en el Instituto de Cartografía de
Andalucía desde hace tiempo, por fin se pone al alcance de los ciudadanos.
Se añade así este proyecto, al resto de servicios de cartografía que ya
se ofrecen a través de internet desde el portal del ciudadano de la Junta de
Andalucía (http://andaluciajunta.es/) y también desde la página de la
Consejería de Obras Públicas y Transportes (http://www.copt.junta-
andalucia.es/obraspublicasytransportes/).
En esta fase inicial de la puesta en explotación de la IDEAndalucía se

ofrecen:
. Herramientas de búsqueda general, temática, localización y visualización

de datos geográficos.
. Servidor de Mapas, Visualizador.
Actualmente IDEAndalucía contiene la siguiente información geográfica:
MTA100 (Mapa Topográfico de Andalucía 1:100.000)

Mapa continuo del territorio dividido por temas con una alta precisión
geométrica y una rigurosa estructura topológica.
La Geodatabase del Mapa Topográfico de Andalucía 1:100.000 se
estructura en catorce grandes apartados temáticos:
Relieve Infraestructuras de Telecomunicaciones
Hidrografía Patrimonio
Medio Marino Servicios
Sistema Urbano División Administrativa
Viario Zonas Militares
Infraestructuras Hidráulicas Infraestructuras del Transporte
Infraestructuras Energéticas
Capas Raster(sombreado orográfico, usos del suelo y mosaico Landsat).
Es una cartografía derivada, realizada a partir de la información contenida

en una cartografía básica de escala 1:10.000, que a su vez se ha obtenido a
partir de procesos de observación y medición de la superficie terrestre. Se
ha consolidado como la principal base cartográfica a escalas intermedias y
es el referente de la planimetría adoptada por los distintos sistemas de
información geográfica que en los últimos años se han venido
implementando en Andalucía. Contiene la información completa de la
planimetría, la altimetría y toponimia de la región en diferentes formatos.

Sesión 6 IDEAndalucía abierta al público.
MTA10 (Mapa Topográfico de Andalucía 1:10.000)
Mosaico del territorio andaluz formado por 2746 hojas que constituye la
cartografía básica regional con cobertura territorial completa en formato “raster”
georreferenciado.
Se ha obtenido a partir del escaneo de las hojas originales, asignándole

sus coordenadas y rectificadas geométricamente.
Este producto presenta una representación detallada y actual y un

amplio contenido planimétrico, altimétrico y toponímico.
La IDEAndalucía ya se encuentra conectada con otras infraestructuras

de datos espaciales de ámbito nacional de conformidad con las directrices
estatales, europeas y mundiales para compartir, difundir y contrastar nuestra
información.
Trabajamos actualmente con los siguientes objetivos:
. Implantación y desarrollo de un servicio WFS para la obtención de

datos espaciales contenidos en IDEAndalucia en formato vectorial desde
el servidor de mapas web.
. Revisión y actualización de los metadatos existentes. Mejora de las

búsquedas para incorporar nuevos elementos por los que el usuario
pueda discriminar los metadatos a mostrar.
. Mejora de las funcionalidades de nuestro visualizador.
. Incorporación de nuevos contenidos, como la ortofoto digital generada

a partir del vuelo fotogramétrico color a escala 1/60.000 de junio-octubre
de 2.004 y organizada según la distribución de las hojas del Mapa
Topográfico de Andalucía 1:10.000.
La versión actual de la IDEAndalucía se debe considerar como el inicio

del proyecto de IDE en el geoportal de Andalucía. Se persigue la construcción
de una Infraestructura de Datos Espaciales única para nuestro territorio, donde
tenga cabida la información espacial producida por todas aquellas instituciones,
públicas y privadas con competencias en los distintos ámbitos sectoriales, que
deseen incorporarse al proyecto.
Por estas razones desde el Instituto de Cartografía de Andalucía se está

iniciando una labor de difusión y formación en nuestro entorno geográfico del
conocimiento, la tecnología y las nuevas expectativas de todo tipo que nos
ofrecen las Infraestructuras de Datos Espaciales.
Esperamos exponer con detalle el estado de este proyecto en las

Jornadas Técnicas previstas para el próximo Octubre en Castellón.

IDERioja, despliegue de servicios IDE en el ámbito de la... Sesión 6
IDERioja, despliegue de servicios IDE en el

ámbito de la Administración Local
G. López García (1), R. Corredor Fernández (2), P. Martínez Pérez (3)
(1)
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)
Tlf: 941.291.100 ext 4578 Fax: 941.291.778 c.e.: gonzalo.lopez@larioja.org
(2)
Agencia del Conocimiento y la Tecnología
C/General Sanjurjo, 2 bajo
26004 Logroño (La Rioja)
Tlf: 941.291.143 Fax: 941.252.724 c.e.: ricardo.corredor@saicar.es
(3)
Agencia del Conocimiento y la Tecnología
C/General Sanjurjo, 2 bajo
26004 Logroño (La Rioja)
Tlf: 941.291.143 Fax: 941.252.724 c.e.: pablo.martinez@saicar.es
Resumen
El desarrollo de servicios IDE en el ámbito de la Administración Local se

encuentra 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
fundamentalmente al usuario rural.
Palabras clave: Información geográfica, Infraestructuras de Datos Espaciales,

IDE, Administración Local, La Rioja
1 Introducción

Sesión 6 IDERioja, despliegue de servicios IDE en el ámbito de la...
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á

consiguiendo 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 deberí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, disponiendo de fuentes de

información geográfica de gran interés para el ciudadano, carecen 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 dirigidos los servicios IDE.
Conseguir que en este modelo de información puedan estar incluidos 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:

2 Análisis de la situación
En la Comunidad Autónoma de La Rioja existen actualmente 174 municipios,

disponiendo todos ellos de cartografía urbana 1:500/1:1.000.
Esta informació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 ayuntamientos de la comunidad autónoma, con excepción de Logroño y
Calahorra que administran su cartografía con medios propios, su colaboración para
hacer llegar al ciudadano la cartografía urbana de forma gratuita, de la misma
forma que lo hace el propio Gobierno Regional con sus datos geográficos, siendo
dicho ofrecimiento aceptado por 171 ayuntamientos.
Por otra parte, aproximadamente el 50% de la población de La Rioja habita en

Logroño, repartiéndose el resto 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.
Por otra parte, de entre todas las fuentes de información geográfica que pueden
ponerse al alcance del usuario rural a través de tecnologías IDE, la información
catastral destaca especialmente sobre todas las demás por obvias razones de índole
econó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 por dicha información, se requiere de la
existencia de 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 desinterés de su población por las nuevas tecnologías, resulta
una circunstancia desfavorable.
En el caso de La Rioja, la Fundación Riojana para la Sociedad del Conocimiento

(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
animando 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ísticas
tan determinadas como es el usuario rural, se propone desarrollar el proyecto en
base a las siguientes estrategias:
1- Habilitar servicios IDE para la información geográfica municipal.
Se pretende de esta manera que cada municipio disponga de un servicio

WMS propio al que se puedan ir incorporando en un futuro distintas capas
de información.
2- Desarrollar herramientas de consulta extraordinariamente 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 esfuerzo de búsqueda y localización del visualizador, sino
que éste lo encuentre disponible en las páginas que visita más asiduamente.
3- 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 implantación.
Con el fin de minimizar los costes del proyecto, se ha propuesto el uso de

software 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

escalas, se indica la conveniencia de utilizar un solo servidor informático
para sostener todos los servicios, desarrollar un único visualizador
geográfico que mediante parámetros se pueda personalizar para los
distintos municipios y adaptar la informació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 capitalizar el conocimiento adquirido a medida que se desarrolla el
mismo.
En definitiva se trata de proveer soluciones compatibles, baratas, sencillas y

capaces de responder a las expectativas que generan.
4 Acciones
La estrategia de desarrollo se ha materializado en las siguientes acciones:

1 - El Gobierno de La Rioja ha asumido las siguientes funciones:
• Adaptación de la información geográfica municipal para su distribución

mediante servicios I.D.E.
• Adquisición y gestión de un servidor donde concentrar servicios WMS

municipales.
• Desarrollo de un visualizador universal parametrizado, capaz de ser

incluido 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 defensa del medio rural, páginas personales sobre el
municipio, etc…
Para lograr que el coste para sostener estos servicios fuera el mínimo, las distintas
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” en
tanto que el desarrollo del visualizador se ha realizado utilizando como base el
entorno Ka-Map, 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
solució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, asumiendo el Gobierno de La Rioja 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 comparar
la estructura de las distintas cartografías urbanas. En un primer paso se trataba 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
Ejemplo para el caso de Nájera (La Rioja): “IDERIOJA Najera [Spain] WMS”
Servicios:
Los servicios se invocan mediante un parámetro (código INE+código

alfanumérico) que hace referencia a un servidor específico
Ejemplo para el caso de Alfaro: 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&
Formatos Soportados: gif, jpeg, png , bmp, tiff
Sistemas de coordenadas soportados: ED50/UTM zone30, WGS 84
Capas:
Para las capas se ha intentado seguir un patrón común:

Ejemplo para el caso de Arnedo (La Rioja)
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)
Arnedo_Viales(Viales)
5.2 Visualizadores de mapas
Habitualmente las herramientas IDE, están ubicadas en páginas específicas de

información geográfica casi siempre fuera de los circuitos de consulta más
populares, 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 cumpliera

los siguientes requisitos:
1- Un solo desarrollo para todos los municipios, que se pudiera invocar

mediante 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 municipio, éste se puede incluir como un servicio en la página web
del propio municipio o en cualquier otra que lo quiera referenciar.
Enlace al visualizador del municipio de Haro (La Rioja)
http://www.iderioja.org/municipios/index.php?map=HARO

Ilustración 1: Aspecto general del visualizador
2- El visualizador incorpora únicamente lo ortofotografía de La Rioja, la

información de la cartografía urbana, del WMS de la C.A. de La Rioja y el
WMS de la D.G. del Catastro, mediante una sencilla activación tipo
checkbox.
Ilustración 2: Selección de capas de información
3- 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.

Ilustración 3: Consulta catastral a partir del visualizador
4- Se incorporan utilidades de zoom, mapa de referencia y funcionamiento a

pantalla completa.
Ilustración 4: zoom, navegación y mapa guía
5- Para simplificar al máximo su operativa se ha evitado incluir otras

funcionalidades de carácter más técnico como son la selección de sistemas
de coordenadas o la incorporación de nuevos servidores WMS.

6- Para usuarios con mayores necesidades de información se han incluido

enlaces 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
incorpora como opción la activación de los servidores WMS municipales,
al Sistema de Información Urbanística de La Rioja (SIU), al Visualizador
de la IDE Española (IDEE) y a la Oficina Virtual del Catastro.
Ilustración 5: Enlaces a otros servicios
El estado actual de desarrollo del proyecto así como el acceso a los distintos
visualizadores 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 marcha
de todos los municipios Cabeceras de Comarca, estando previsto abordar la
totalidad 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, no
pretendiendo con ello suplantar las competencias propias de la Administración
Local en este área, sino estimular su desarrollo.

Sesión 6 EUROPARC-España, un ejemplo de IDE sectorial para los Espacios...
EUROPARC-España,
un ejemplo de IDE sectorial para los Espacios Naturales Protegidos.
Autores:
Joan Masó[1], Núria Julià[1], Carlota Martínez[2] y José A. Atauri[2]
[1]
Proyecto MiraMon
Centro de Investigación Ecológica y Aplicaciones Forestales CREAF
Fac. Ciencias
[2]
Fundación Fernando González Bernáldez /EUROPARC-España
Oficina Técnica EUROPARC-España
ICEI. Finca Mas Ferré. Edif. A. Campus de Somosaguas, Madrid
Palabras clave: Espacios naturales, IDE sectorial, servicios web

Contribución: IDEE
EUROPARC-España es una organización en la que participan las instituciones

implicadas en la planificación y gestión de los espacios naturales protegidos del Estado
español. Constituye el principal foro profesional donde se discuten y elaboran
propuestas para la mejora de estos espacios.
Uno de los objetivos de EUROPARC-España, es la mejora del acceso a la información

sobre los espacios naturales protegidos en el Estado español. Para dar cumplimiento a
este objetivo, desde sus inicios EUROPARC-España ha acumulado una larga
experiencia en la integración de datos procedentes de las administraciones autonómicas,
afianzando las relaciones con los correspondientes organismos encargados de la
planificación y gestión de los espacios protegidos. Esta voluntad se ha plasmado en la
creación y mantenimiento de una base de datos de los espacios naturales protegidos de
España y en su difusión a través de su portal web (el “Observatorio de los espacios
naturales protegidos”).
De esta forma EUROPARC-España se ha configurado, no sólo como un proyecto, sino

como una realidad con objetivos comunes a los de las IDE's pero careciendo de
cartografía. Algunas de las herramientas típicas de una IDE como el catálogo de datos
("el Observatorio") y un buscador de espacios protegidos ya existen desde hace años en
su web.
En este contexto, el CREAF y EUROPARC-España han establecido un acuerdo por el

cual se incorporan tecnologías SIG interoperables que convierten el portal de
EUROPARC-España en una IDE sectorial. La cartografía es recogida, homogenizada y
posteriormente distribuida por Internet, a través de servicios web conformes con OGC e
ISO, mediante un portal que permite la visualización, consulta, impresión y descarga de
los datos.
Como primer paso se ha recogido la información cartográfica sobre los espacios

naturales protegidos actualmente declarados por las comunidades autónomas, y algunas
entidades regionales y locales con responsabilidad en la gestión de espacios protegidos.
Durante este proceso se han detectado las siguientes problemáticas: distintas escalas de

EUROPARC-España, un ejemplo de IDE sectorial para los Espacios... Sesión 6
trabajo (entre 1:5 000 y 1:50 000), distintos sistemas de referencia según la región de
origen, distinta codificación de la identificación de cada espacio, diversidad de
tipologías de figuras de protección dependiendo del organismo gestor, distinta
representación de los espacios protegidos de pequeño tamaño (que pueden aparecer
como punto, línea o polígono), espacios que por su situación geográfica, comparten
competencias entre diversas entidades, coincidencia de la delimitación de algunos
espacios con límites administrativos en diversas escalas, escasa o nula documentación
de metadatos y diversidad en su formato.
Esta comunicación discute las soluciones adoptadas para cada problemática enumerada.
Para facilitar su distribución y resolver algunos de los problemas planteados, se ha
preparado una única capa a una escala común de 1:25 000 coincidente con la escala de
los límites administrativos editados por el IGN en el sistema de referencia UTM30N
sobre el Dàtum ED50 (excepto para Canarias). Esta capa podrá ser descargada desde el
portal de EUROPARC-España junto con las capas originales aportadas por los
organismos implicados, siempre que estos lo estimen oportuno.
Así mismo, un servidor de mapas WMS permitirá la interoperabilidad de las bases con
otras informaciones integradas en las IDE's. El servidor estará accesibledesde la propia
web de EUROPARC-España junto con otra información interoperable procedente de
otros servidores mediante un cliente ligero basado en HTML dinámico y JavaScript.
Se ha establecido un protocolo de actualización de los datos que garantice que, como

mínimo una vez al año, pueda actualizarse la cartografía unificada. Gracias a este
proyecto, EUROPARC-España contribuye a la comunidad de la IDE española no sólo
aportando servidores de datos específicos sino difundiendo, entre los técnicos y usuarios
de los datos, nuevas herramientas y metodologías interoperables que faciliten el acceso
y el intercambio de información y promoviendo en las administraciones responsables de
los espacios protegidos la adopción de los estándares sugeridos por la Directiva
INSPIRE.

Sesión 6 IDEZar: Procesos, herramientas y modelos urbanos aplicados a la...
IDEZar: Procesos, herramientas y modelos

urbanos aplicados a la integración de datos
municipales procedentes de fuentes
heterogéneas
López Pellicer, F.J., Álvarez, P., Muro-Medrano, P.R..
Departamento de Informática e Ingeniería de Sistemas Informáticos.

Edificio Ada Byron, C/ María de Luna 1, 50018 Zaragoza
{fjlopez,alvaper,prmuro}@unizar.es
Resumen
Gran parte de los esfuerzos de la Infraestructura de Datos Espaciales de Zaragoza

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
administració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
resultado de la colaboración iniciada en el año 2004 entre el Ayuntamiento y la
Universidad de Zaragoza para la implantación de una Infraestructura de Datos
Espaciales (IDE) a nivel local. Dos elementos relevantes en esta IDE son la política
de integració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 (GIS, CAD, aplicaciones de oficina) amen de
diferentes requerimientos de calidad, disponibilidad, validez, extensión y formato.

IDEZar: Procesos, herramientas y modelos urbanos aplicados a la... Sesión 6
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 Architecture [3] impulsada por Open
Geospatial Consortium (OGC), permite que los Servicios municipales exploten el
valor añadido al facilitar la construcción de aplicaciones y adaptadores sobre los
servicios de la IDE.
Este artículo presenta una solución para la implementación de la política de
integración de datos. Esta pasa por establecer un modelo que describe los datos
espaciales 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
utilizados para caracterizar espacialmente a otros datos, tienen un papel
diferenciado pues son los responsables de homogenizar la información. Este
modelo se implementa en una geodatabase poblada a partir de la integración de
datos procedentes 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 artículo se organiza como sigue, el apartado 2 incide en la relación entre
INSPIRE, los datos de referencia y la administración local, el apartado 3
caracteriza los problemas detectados desde 2004 hasta la fecha, el apartado 4
muestra nuestra propuesta y el apartado 5 su aplicación. Finalizamos con unas
breves conclusiones.
2 La directiva INSPIRE, los datos de referencia y la

Administración local
La directiva INSPIRE señala que temas considera como datos de referencia pero no
quién es responsable de su creación. Este punto analiza que temas son idealmente
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.
Anexo I y II Definición INSPIRE Subtema local

Nombres Nombres de zonas, regiones, localidades, Nombres geográficos locales.
geográficos ciudades, periferias, poblaciones o
asentamientos, o cualquier rasgo
geográfico o topográfico de interés público
o histórico.
Unidades División del territorio nacional en unidades Unidades administrativas
Administrativa de administración a nivel local, regional y locales descentralizadas.
s nacional. Las unidades administrativas
estarán separadas por límites
administrativos. También se incluirán las
fronteras del territorio nacional y las
costas.
Redes de Redes de carreteras, ferrocarril, transporte Red local de vías urbanas,
transporte aéreo y por vía navegable e caminos y vía rurales.
infraestructuras correspondientes. Se
incluirán las conexiones entre redes
diferentes.
Identificadores Localización geográfica de las Tipo y nombre de vía pública y
de propiedad propiedades, efectuada sobre la base de la número de la finca.
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.
Parcelas Áreas determinadas por límites catastrales Propuestas de alteraciones
Catastrales y caracterizados por una situación jurídica catastrales.
específica de propiedad.
Fuentes: Ley 7/1985 reguladora de Bases de Régimen Local, formatos de intercambio del Instituto Nacional de
Estadística (INE), formatos de intercambio Dirección General del Catastro (DGC), elaboración propia
Tabla 1 Temas de referencia local
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
locales 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]), tengan sus modelos establecidos y, por ende, existan mecanismos que eviten
inconsistencias y errores.
3 Problemas en la manipulación de datos de referencia

Hay una serie de problemas en los datos de referencia que tienen que ser resueltos a
nivel de datos para llegar a la situación señalada en el apartado anterior. Estos
problemas se han detectado según se iban cumpliendo las metas marcadas a lo
largo de estos dos años para IDEZar [5] con vistas al desarrollo de un geoportal
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
espacial 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
referencia que se solapan.
• Un uso no sistemático. No todos los elementos de un tema están
espacialmente caracterizados de la misma manera. Por ejemplo, al usar las
direcciones en zonas rurales para identificar centros municipales
discrecionalmente 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 alternativos ad-hoc. Por ejemplo se pueden encontrar varias
formas de escribir el nombre de la calle.
• Sesgo estadístico. El diseño de los nombres geográficos, las unidades
administrativas e los identificadores de propiedad está orientado a
identificar población. Gran parte de esta información se intercambia con el
Instituto 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
població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
anteriores.

4 Propuesta de solución
Para afrontar los problemas indicados en el punto anterior y encaminar la IDE en la
línea del apartado 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.
Figura 1 Propuesta de Solución
4.1 Modelo urbano

El elemento central es un modelo de datos de referencia urbana. Alrededor de él se
establecen una serie de modelos de datos temáticos que utilizan el modelo de datos
de referencia para caracterizarse espacialmente. Forman parte del modelo de
referencia 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

compatibilidad de los almacenes de los datos de referencia y temáticos con la

especificación SFS [7] de OGC.
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, los datos que
estas 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
administrativo, cómo se intercambian y en que formatos. Tras analizar los datos
bajo control se diseñan los procesos de extracción, transformación y carga de la
información en la geodatabase. Los procesos de transformación pueden clasificarse
en:
• Procesos de limpieza. Aplican heurísticas de limpieza de datos.
Comprueban los dominios de los campos y su contenido.
• Procesos de alineamiento. Relacionan dos o más datos entre si.
Dependiendo de la fuente, además de detectar duplicados, se detectan
inserciones, modificaciones y borrados.
• Procesos de aumentación. Aplican heurísticas, procesos y herramientas
para 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
aplicaciones. Estos almacenes se han construido utilizando servicios de Web de

transformación que acceden directamente a los almacenes datos temáticos y de

referencia.
Fuentes Procesos Modelos urbanos Servicios Aplicaciones
Nacional
Tematicos
Dirección
General Extracción Restricciones
Catastro zonales
Búsqueda
(Catálogo)
Local Nomenclátor
Servicio Limpieza (todo
Web Tematicos alfanumérica)
Transporte
Gerencia de Público
Alinea-
Urbanismo Transformación
miento
(centrada en la
Hacienda vía)
Municipal Callejero
Aumenta-
(información
Servicio de ción
visual y
Estadística Referencia textual de
localización)
Referen-
ciación Visualización
Corporativo (WMS)
Tematicos
TUZSA
Carga Fiscalidad
Datos temáticos
<<Tramo>> <<Tramo>> <<Tramo>>

Fiscal Zona Saturada Línea Bus
* * *
Datos de referencia
Vía
*
Unidad Número de
Código Postal
Administrativa Finca
Figura 2 Caso de aplicación del Callejero y Nomenclátor

5 Caso de aplicación
Esta propuesta se ha aplicado en la construcción de las aplicaciones callejero y
nomenclátor de IDEZar (ver 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
Dirección General de Catastro, el Servicio de Información Geográfica y el Servicio
Web del ayuntamiento.
Figura 3 Procesado de números de finca

Por ejemplo, para obtener los números de finca (ver Figura 3) que se encontraban
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
adecuadas 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
información ya almacenada de vías, las cuales procedían de una fuente distinta. Los

números de finca, ya correctamente referenciados a vías, fueron entonces

almacenados.
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, cuales 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
infraestructura 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.
Agradecimientos
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] Muro-Medrano, P.R, Gould, M., Bernabé, M.A. “IDE-E: Technological
advances for a Webbased National Spatial Data Infrastructure, convergence
with the European initiative INSPIRE TIC2003-09365-C02”, Jornada de
Seguimiento 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: “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] López Pellicer, F.J., Álvarez, P. 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: OpenGIS® Simple Features Implementation
Specification for SQL (SFS), 99-049, 1999

Sesión 6 IDENA: Novedades y líneas de futuro.
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
Tlf: 948 289000 Fax: 948 249209 e-mail: idena@navarra.es
‡ Dpto. de Obras Públicas, Transportes y Comunicaciones

Avda. S. Ignacio 3, 31002 Pamplona
Tlf: 848427449. e-mail: idena@navarra.es
Resumen
Esta comunicación trata de presentar la situación actual de una serie de proyectos

que se están desarrollando en Navarra en el contexto de las IDE.
El proyecto IDENA [1] se enmarca entre las distintas iniciativas que en los últimos
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 que la
utilización de normas y especificaciones comunes ha facilitado. [2]
Esta comunicación presenta las últimas novedades que en relación con la

Infraestructura de Datos Espaciales de Navarra se están produciendo. La reciente
publicación de la IDE de Pamplona (http://ide.pamplona.es), por ejemplo, ha
permitido la incorporació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 esta comunicación, además, difundir una iniciativa impulsada desde la

Administración Foral que persigue la publicación en una Web propia de un

IDENA: Novedades y líneas de futuro. Sesión 6
Inventario 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, IDE

Pamplona, CROSS SIS, GRISI, Planeamiento.
1 IDEPAMPLONA
En el mes de marzo de 2006, y coincidiendo con la reunión del Grupo de Trabajo
de la IDEE que tuvo lugar en Pamplona, se produjo la presentación de
IDEPamplona [3]. Este portal ofrece información territorial del término municipal
de Pamplona y herramientas para poder navegar sobre la misma. Nace, por otra
parte, como 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 las
IDE en la Comunidad Foral de Navarra. Todos los desarrollos tecnológicos son
propios de Trabajos Catastrales, S.A.
A semejanza de IDENA, el portal de IDEPamplona está constituido por dos

elementos 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 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 habituales 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 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 características
principales (título, resumen, editor, formato y agregados, cuando sea aplicable).
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
dirección web propuesta por el titular de la capa de información <’Ir a sitio web’>
Figura 2. Aspecto del buscador de metadatos

La ventana de resultados devuelve las entradas que coinciden 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 claramente por medio de
colores distintos. Este ejemplo muestra la total interoperabilidad entre ambos
portales.
Figura 3. Ventana de resultados de una búsqueda
Las capas actualmente cargadas en IDEPamplona son:
- Edificios del ayuntamiento - Otros servicios de interés

- Equipamientos socioculturales - Recorrido del encierro
- Equipamientos ocio - Cárcel y juzgados
- Cementerio y tanatorios - Aseos municipales
- Mercados municipales - Residencias de la tercera edad
- Centros educativos - Transporte
- Tráfico - Oficinas de correos
- Edificios sanitarios

- Colección de ortofotos históricas ciudad a lo largo de los últimos 75

que muestran la evolución de la años.
En cuanto al planteamiento de la arquitectura, la figura siguiente muestra la

solución actualmente 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
proyecto 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
regionales, 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
ademá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 concreto, 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 imagen siguiente 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
objetos 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:
població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
infraestructuras que soporten un buen desarrollo de políticas adecuadas en ámbitos
transfronterizos. Es prioritario a la vez el traspaso de conocimientos entre los
distintos organismos que colaboran.
3 INVENTARIO DE PLANEAMIENTO URBANÍSTICO

El Gobierno de Navarra y Trabajos Catastrales SA, vienen desarrollando desde el
año 1999 el Sistema de Información Urbanística de la Comunidad Foral, proyecto
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 determinaciones

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
mosaicos 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 consulta

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 podemos contemplar la consulta de un plano

utilizando el Inventario de Planeamiento y seguidamente la integración de ese
mismo plano en un cliente de pruebas junto con otras capas de informació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
Gobierno 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 visualizador

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 momento
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 esta comunicación
ponen de relieve el interés suscitado en Navarra por las Infraestructuras de Datos
Espaciales. Los desarrollos completados o en marcha hacen concebir grandes
esperanzas para los próximos años. IDENA, IDE Pamplona o CROSS SIS son
escaparates que permiten 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 puedan 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] Clerigué Arrieta, R.; Echamendi Lorente, P.; Fontano Ruiz, S.; Sabando
Grasa, C , “IDENA, Infraestructura de Datos Espaciales de Navarra”, JIDEE.
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/

SESIÓN 7
SIG
253
PostGis en producción cartográca: CartoCiudad. Sesión 7
PostGIS en producción cartográfica:

CartoCiudad
MM. Gamo†, MA. Manso‡.
Laboratorio de Tecnologías de la Información Geográfica (LatinGEO).

Universidad Politécnica de Madrid Autovía de Valencia Km 7, 28031 Madrid
Tlf: 913.311.968 Fax: 913.311.968.
†mmgamo@topografia.upm.es ‡m.manso@upm.es
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 mantenimiento a partir de los datos
suministrados por las siguientes fuentes oficiales: Instituto Geográfico
Nacional (IGN), Dirección General del Catastro (DGC), Instituto Nacional de
Estadística (INE), Correos y en determinados casos, cartografía digital 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
elaborando un conjunto de procedimientos que dan respuesta a la
metodología de producción de Cartociudad basándose en el sistema de
gestión de bases de datos (SGDB) 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 Source.
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
georreferenciación de puntos de interés, la localización de direcciones
postales y la geocodificación.
El resto del documento se estructura de la siguiente forma: en primer lugar se
presenta el problema, las fuentes de datos y la metodología propuesta para dar
solución a los requisitos planteados en el PPT, se exponen a nivel descriptivo
los algoritmos que se han desarrollado sobre PostGIS y se finaliza con las
conclusiones, agradecimientos y las referencias bibliográficas.
Palabras clave: Cartografía navegable, CartoCiudad, SIG, OpenSource y
PostGIS.

Sesión 7 PostGis en producción cartográca: CartoCiudad.
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.
Constituye 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 describen 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
Infraestructura de Datos Espaciales (IDE).
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

cartografí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 empresas
licitadoras.
3 Metodología
En este apartado se describen las distintas fases que materializan el desarrollo del
proyecto CartoCiudad.

3.1 Estado del arte o de la situación

En primer lugar se realizó un estudio detallado de las diferentes fuentes
cartográficas de datos de partida, IGN, DGC, INE y Correos mediante la
descripción adicional 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
desarrolla 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
espacial PostGIS. De esta manera pueden distinguirse las siguientes fases de
trabajo:
a) Carga de los archivos Shapefile a PostgreSQL

Se ha utilizado la herramienta “shp2pg” que permite transformar un archivo
Shapefile 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).
b) Concordancia geométrica de las fuentes de datos cartográficas

Esta sección comprende los siguientes tres pasos:
1. Case geométrico: La primera fase a realizar consiste en comparar y asegurar 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 última como
referencia a través de un análisis visual.
2. 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 posibles irregularidades
geométricas relativas a las distintas fuentes se realizará un nuevo contraste con
otras fuentes oficiales tales como ortofotos digitales del Plan Nacional de
Ortofotografía Aérea (PNOA).

3. Transformación de coordenadas origen: El tercer paso consiste en la

transformación de coordenadas origen UTM (Datum Europeo de 1950) a
coordenadas geográficas (Datum, ETRS89).
c) Procesamiento de las capas iniciales de información cartográfica

El tratamiento de las distintas fuentes de datos de partida se realizará con la
plataforma 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
(procedural language postgreSQL).
1. Capa ELEMTEX de Catastro

Esta capa contiene información geométrica de tipo lineal asociada a los diferentes
rótulos de la toponimia urbana (número de portales, nombres de calles…)
Número de portales
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.
Figura1: 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, geometría.rotulo,
calcular_centroide(geometría.the_geom))
FIN SI
FIN PARA
Toponimia urbana: Puntos de Interés POI

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 (colegios,

bibliotecas, hospitales etc.) correspondiendo éstos al atributo TTGGSS de valor
‘189300’.
• Calcular el punto medio de la entidad lineal asociada a estos rótulos
materializando así la posición de la toponimia referente a los POI.
El pseudocódigo que realiza esta operación es:

INSERTAR EN TABLA toponimia LOS VALORES (geometría.gid, geometría.rotulo,
FIN SI
FIN PARA
Toponimia urbana: Red de Carreteras

La capa ELEMTEX también contiene información relativa a la red de carreteras
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 estas dos fases:
• Seleccionar los rótulos de atributo TTGGSS con valor ‘189802’ que

corresponden 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ótulos

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.
INSERTAR EN TABLA toponimia LOS VALORES (geometría.gid, geometría.rotulo,
FIN SI
FIN PARA
En estos tres casos (número de portales, puntos de interés POI y red de carreteras)
pueden presentarse ciertas particularidades que deben detectarse y solucionarse de
acuerdo al modelo de datos de CartoCiudad.
2. Capa EJES de la DGC y Tramo de Correos

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:
a) Continuidad: 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.
b) Polilíneas únicas: Cada una de las calles debe representarse mediante una sola
polilínea con un inicio y un final sin presentar ramificaciones que generen
horquillas.
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
realizarse en su totalidad ya que aparecen excepciones en forma de horquillas etc.

Figura 4: Detección de horquillas y geometrías singulares.
c) Intersección: 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.

PARA CADA geometría1 DE unionvias_misma_via3 ORDENADO ASCENDENTEMENTE POR via HACER
PARA CADA geometria2 DE unionvias_misma_via3 DONDE (via DISTINTO DE
geometria1.via) ORDENADO ASCENDENTEMENTE POR via HACER
SI hay_interseccion(geometria2.the_geom, geometria1.the_geom) ENTONCES
SI (tipo_geometria(calcular_interseccion(geometria2.the_geom,
geometria1.the_geom)) = punto) ENTONCES
INSERTAR EN TABLA cruces LOS VALORES (geometria1.via,
geometria2.via, calcular_interseccion(geometria2.the_geom,
geometria1.the_geom))
SI NO
numero_puntos =
calcular_numero_geometrias(calcular_interseccion(geometría
1.the_geom, geometria2.the_geom)
PARA CADA i DESDE 1 HASTA numero_puntos HACER
INSERTAR EN TABLA cruces LOS VALORES
(geometria1.via, geometria2.via,
devolver_geometria(calcular_interseccion(geometri
a2.the_geom, geometria1.the_geom), i))
FIN PARA
FIN SI
FIN SI
FIN PARA
FIN PARA
d) División: Dividir las calles por los puntos de intersección anteriormente

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.

e) Normalización: Correlación entre la denominación de la vía usada por la DGC y

la utilizada por el INE. Hay que correlar 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 nombres de INE están normalizados y son los
de referencia.
f) Código INE: Designar el código INE de población a los ejes, tramos y cruces
del proceso descrito. 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.
3. 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 consistirá 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.
4. 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 toponimia y los viales previamente divididos en tramos.
5. Capa de distritos y secciones censales del INE

El INE proporciona información de los distritos y secciones censales mediante:
Capa callejero (fuente de datos vectorial)
6. Capa de códigos postales de Correos

De forma análoga a los distritos y secciones censales, Correos también suministra
la capa:
Capa 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.
d) 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”.
e) Obtención de la documentación de las fuentes y los procesos: Metadatos
El proyecto CartoCiudad debe contar con la documentación adecuada que acredite
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
estándar Internacional de Metadatos ISO 19115 y en base al Núcleo Español de
Metadatos (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 PosGIS.
Se ha podido depurar los errores en los algoritmos desarrollados gracias a la
capacidad de conexión y visualización de datos espaciales almacenados en
postgreSQL 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 CartoCiudad
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 existentes,
así como detectar posibles errores en la construcción de los algorítmos
implementados en forma de funciones plpgsql mediante su análisis visual.
Se ha constatado que en muchos casos la consecución de determinados objetivos
algorítmicos requieren 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
oportunos incluirlos en las siguientes versiones del producto.
6 Agradecimientos
El proyecto CartoCiudad ha sido financiado parcialmente por el Instituto
Geográ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).
7 Referencias bibliográficas
[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”, B.O.E.,
2006, nº exp. 06.103, pag. 1—15
[2] MA. Manso, "Metodología del proceso de armonización e integración de datos
para el proyecto CartoCiudad", Universidad Politécnica de Madrid, 2005,
pag. 1—14
[3] Documentación de PostGIS: http://postgis.refractions.net/docs/ Código de campo c
[4] Modelo de Nomenclátor de España v1.0:
www.idee.es/resources/recomendacionesCSG/Propuesta_MNE_v1.0.pdf Código de campo c
[5] Documentación de EuroRoadS: www.euroroads.org Código de campo c
[6] Documentación de Web Gazetteer Services:

https://portal.opengeospatial.org/files/?artifact_id=7175 Código de campo c

Herramientas GIS para la Gestión Medioambiental. Sesión 7
Herramientas GIS para la gestión

medioambiental.
J.L. Casado†, S. Belmonte†, J. García-Consuegra†, A. López‡,
M.A. Gallardo¦, L. Serna¦.
† Laboratorio de Sistemas de Información Distribuida e Ingeniería del Software.

Universidad de Castilla la Mancha
Campus Universitario
Parque Científico y Tecnológico s/n 02071 Albacete
Tlf: 967.599.200 Fax: 967.599.343. e-mail: jlcasado@dsi.uclm.es,
seve_belmonte@dsi.uclm.es, jdgarcia@dsi.uclm.es
‡ Asociación para el Desarrollo Integral Mancha-Júcar Centro

C/Nueva, 13 02638 Montalvos (Albacete)
Tlf: 967.276.430. Fax: 967.276.408. e-mail: agls.mancha-jucar@cedercam.org
¦ Concejalía de Medio Ambiente del Ayuntamiento de la Roda

Plaza Capitán Escribano Aguado, 1 02630 La Roda (Albacete)
Tlf: 967.441.403. Fax: 967.441.190 e-mail: medioambiente@laroda.es
Resumen
Enmarcados dentro de la Red de Ciudades Saludables y Sostenibles, la mayoría de

ayuntamientos han venido realizando en los últimos años un gran esfuerzo en
materia de gestión medioambiental. Este esfuerzo se ha materializado en una serie
de políticas y planes de actuación. Dentro de estas líneas surge este trabajo, en el
que se pretendía aplicar toda esta experiencia acumulada y forma de trabajar a un
sistema informático que fuera capaz de dar soluciones rápidas y eficientes, tanto a
tareas diarias, como a problemas puntuales. Para ello, se han realizado una serie de
herramientas SIG adaptadas a la gestión de Residuos Sólidos Urbanos.
Palabras clave: Sistemas de Información Geográfica (SIG), Gestión

medioambiental, Residuos Sólidos Urbanos (RSU), código libre.
1 Introducción

Sesión 7 Herramientas GIS para la Gestión Medioambiental.
En la actualidad existe una preocupación creciente por el medioambiente y el

mantenimiento del mismo, muchos de los esfuerzos de gestión dentro de la
administración van encaminados en esta línea.
Nuestro proyecto surge motivado por la necesidad de generar una metodología de

trabajo, así como las herramientas SIG que la soporten. En su desarrollo, se hizo en
estrecha colaboración con expertos medioambientales que transmitieran sus
conocimientos y necesidades.
Así, se pretendía que la una metodología que abarcase desde las etapas de
definición de las aplicaciones informáticas hasta los procesos de implantación de
los métodos de trabajo en los distintos municipios, con dos objetivos
fundamentales:
• Automatizar o por lo menos marcar las putas para el desarrollo e

integración de nuevas funcionalidades, dentro del sistema desarrollado una
vez terminado este proyecto.
• Implantar e integrar las aplicaciones obtenidas en cualquier equipo de
trabajo medioambiental que lo desease.
Finalmente, el conjunto herramientas inicial obtenido se ha desarrollado en un

entorno amigable y fácil uso para usuarios inexpertos, basados en tecnología SIG
de código libre, que permiten interrelacionar los diversos datos propios de la
gestión de Residuos Sólidos Urbanos (RSU) y el cálculo de los indicadores de
sostenibilidad asociados a los mismos. Entre ellas se encuentran un gestor de
información, herramientas de optimización y un generador de informes.
2 Metodología
El proyecto que motivó este desarrollo fue desarrollar una primera herramienta
SIG, para la gestión de Residuos Sólidos Urbanos (RSU), dentro de un ambicioso
proyecto por cubrir las necesidades de gestión medioambiental, para ayuntamientos
relativamente pequeños, como los que nos podemos encontrar en la comarca de
Mancha-Júcar-Centro, en Castilla-La Mancha.
Para facilitar el desarrollo, desde el punto de vista informático, y la interacción con

los técnicos medioambientales, se concretó una metodología que abarcase todas las

etapas del ciclo de vida del software, desde la especificación o recogida de

requisitos hasta el mantenimiento de las herramientas una vez en fase de
explotación.
En cuanto a esta metodología [1] no entraremos en detalle ya que no es de

primordial interés para la audiencia de este artículo, simplemente comentar que,
dada la naturaleza del proyecto, en cuanto a tiempos de ejecución y conocimientos
de los participantes, se optó por una metodología ágil basada en cortas iteraciones
de realimentación de requisitos, es decir, reuniones periódicas no separadas en el
tiempo con el fin de encauzar los desarrollos en la línea adecuada lo antes posible y
de obtener productos o prototipos funcionales en la mayor brevedad posible.
Con todo esto, se consiguió que el dialogo entre los técnicos medioambientales y
los desarrolladores fuese lo más ágil y participativo posible, que los requisitos del
sistema estuviesen refinados en fechas tempranas del proyecto y que los propios
técnicos medioambientales se involucrasen positivamente en el desarrollo
aportando su conocimiento al mismo.
El otro elemento importante para el éxito, desde el punto de vista de técnicos

medioambientales y responsables del ayuntamiento, fue la gran labor en la
búsqueda y recopilación de información relativa al municipio (realización de
estudios parciales de campo, adquisición de información cartográfica, económica,
social, medioambiental, informes estadísticos) en diferentes formatos, para su
posterior estudio y tratamiento.
3 Estudio previo
Entrando en el contexto del trabajo realizado, éste estaba enmarcado o promovido,
por una asociación de nueve municipios, con poblaciones que oscilan entre los 150
a los 24.000 habitantes. Aunque durante el desarrollo se trabajó únicamente con
uno de ellos debido a su dilatada experiencia en temas medioambientales, el
objetivo final era dar servicio a todos los municipios que forman parte de dicha
asociación.
Para cubrir las necesidades de cada ayuntamiento para la gestión en temas

medioambientales, había que dotar a cada uno de ellos de las herramientas
necesarias para dicha gestión así como de los mecanismos de implantación de las
mismas y la formación necesaria, tanto en el uso de las herramientas como en
temas medioambientales.

Uno de los primeros aspectos a estudiar era el sistema en el que se desarrollarían

las aplicaciones, lenguaje y sobre que plataforma. Dado el número de
ayuntamientos que conformaban la mancomunidad y el presupuesto disponible
para la ejecución del proyecto, era inabordable una solución que no pasase por la
utilización de tecnología de código libre, ya que los costes de las herramientas GIS
sujetas al pago de licencias eran superiores al presupuesto.
Tomada esta decisión, se realizó un estudio de las herramientas GIS de escritorio

de código libre existentes en el mercado [2], la cual nos serviría de base para el
desarrollo de las herramientas mencionadas anteriormente. En una primera
selección general, se vio que en esos momentos las apuestas más fuertes eran las de
JUMP [3], gvSIG [4] y uDig [5]. Tras estudiar detalladamente cada una de las
herramientas, se optó por utilizar JUMP, ya que en el momento del estudio era la
solución de código libre más estable, conocida y documentada de las tres. Por lo
que sería la de más fácil implantación para los usuarios finales. Además, los
técnicos con los que se estaba trabajando, ya la habían utilizado con anterioridad y
apoyaron esa opción desde el principio.
Por otra parte, se vio que a uDig y gvSIG se les vislumbraba un futuro muy
halagüeño, aspecto que se tuvo en cuenta. Por lo que también se estudió la
estructura y modelo de cada uno de ellos, así como sus posibilidades de extensión.
A grandes rasgos, no se apreciaron grandes diferencias, los tres trabajan su
extensibilidad mediante Plugins por lo que adaptar un desarrollo a otro no sería
excesivamente costoso, si se partía de esta premisa en su desarrollo.
En cuanto a la implantación y formación del personal en el uso de las herramientas,

se generó la documentación de ayuda necesaria en cada uno de los temas sobre un
portal web colaborativo (wiki) que permite la actualización continua y la
participación de todos los usuarios de las herramientas, complementado por una
serie de cursos en los que participarían los técnicos de los ayuntamientos
interesados en esta iniciativa.
4 Requisitos
Como se ha comentado anteriormente, el núcleo central de este trabajo era
conseguir un sistema que permitiese, a los técnicos en medioambiente de un

ayuntamiento, realizar las labores propias de la gestión de residuos dentro de las

competencias que se les otorgaban.
La utilización de un SIG como herramienta base fue uno de los primeros requisitos,
ya que se debería trabajar con la posición geográfica de los contenedores o puntos
de recogida y como veremos posteriormente, también se requerían algunas
optimizaciones basadas en dicha información georeferenciada. Por otro lado, la
mayoría de los técnicos medioambientales actualmente poseen un buen
conocimiento de los SIG como usuarios, llegando en algunos casos incluso a
programar sus propias funcionalidades. De todas las especificaciones obtenidas se
desgranaron las siguientes funcionalidades básicas con las que se dotó al sistema:
1. Gestión de información, en la que se facilitan las interfaces necesarias

para todas las tareas referentes a la inserción y mantenimiento de información
referente a gestión RSU. Una de las claves exigida era la flexibilidad en
modificaciones en la estructura de la información, ya que sufre modificaciones
continuas. En muchas ocasiones estas modificaciones vienen por la disponibilidad
de nueva información en formato digital o nuevas obligaciones.
2. Herramientas de optimización, en la que se insertan una serie

funcionalidades para la ayuda en la toma de decisiones, entre otras, caben destacar
dos algoritmos que trabajan sobre información georeferenciada.
a. El optimizador para el posicionamiento de contenedores dentro

del casco urbano. Que contempla tanto las directrices marcadas en materia
de gestión de residuos, así como otros aspectos, tales como el número de
habitantes asociados a un contenedor dado, la ordenación urbanística,
frecuencia de recogida, etc.
b. El optimizador de rutas de recogida de residuos sobre dichos

contenedores. Como parámetros de entrada al algoritmo, se pasa tanto el
punto de inicio (salida de los camiones de recogida), punto de fin (planta
de tratamiento), así como una cartografía del terreno, información sobre la
ubicación de los contenedores, y estimaciones tales como el coste total de
Kg. de residuos recogidos por ruta. El objetivo será minimizar las
distancias a recorrer por los camiones de recogida.
3. Generador de informes, que permite al experto de medio ambiente

trabajar sobre toda la información del sistema en conjunto y realizar el análisis de

la misma, y el estudio de históricos de actuaciones con el fin de mejorar

planificaciones futuras.
4. Carga de datos, herramienta para la inserción en el sistema de

información externa, con el fin de mantener la misma actualizada con respecto a
otras fuentes de datos externas como puede ser la del catastro.
Estas funcionalidades básicas fueron ampliadas para aumentar las posibilidades

ofrecidas al los técnicos de medioambiente, permitiendo no solo la gestión de RSU
sino también la gestión integral de la limpieza viaria y la lucha antivectorial
(control de plagas).
5 Resultados
Atendiendo a los requisitos especificados, se desarrollaron una serie de plugins
sobre JUMP que soportan la funcionalidad requerida. A estas herramientas se tiene
acceso a través de la barra de menú del propio JUMP como se describe en las
figuras 1 y 2. Existen dos bloques fundamentales, uno de posicionamiento que en
el que se engloban las herramientas de optimización (posicionamiento de
contenedores y rutas) y otro en el que se enmarcan las referentes al mantenimientos
de los datos (inserción, consulta, modificación y borrado).
Figura 1. Acceso a las herramientas de Posicionamiento.
Figura 2. Acceso a las herramientas de Gestión de Datos.
En cuanto al algoritmo de posicionamiento de contenedores, se pide como dato de

entrada la capa de tramos de vial (calles) sobre la que realizar los cálculos, así

como la de población que contendrá los números de policía y los habitantes en cada
uno de ellos. Como se muestra en la figura 3, con todo esto se obtiene una nueva
capa con la estimación de la posición de los contenedores. El algoritmo maneja
datos como la distancia máxima entre contenedores y la distancia de los ciudadanos
al contenedor más cercano.
Figura 3. Formulario de posicionamiento de contenedores.
Por otra parte, el algoritmo de optimización de rutas tomará como datos de entrada
la capa de tramos de vial (calles) y la de localización de contendores, seleccionado
qué atributos dentro de esas capas sirven para indicar el sentido de circulación de
las calles, la cantidad de población asignada a cada contenedor, y cuál de los
puntos de recogida (contenedor) es el descargadero donde el camión descargará los
residuos. Dando otros datos como cantidad de residuos generados (persona/día) y
el PMA del camión, como se muestra en la figura 4, se obtiene una nueva capa de
puntos, en la que cada uno de ellos pertenecerá a una ruta indicando el orden en el
que se recogerá cada uno de ellos dentro de cada ruta.
Figura 4. Formulario de generación de Rutas.

Sobre la nueva capa obtenida podremos realizar modificaciones manuales tales

como el cambio del orden de recogida dentro de una ruta o el cambio de un
contenedor de una ruta a otra.
En el otro conjunto de herramientas se agrupan las herramientas de inserción y

tratamiento de la información. Entre las funcionalidades señaladas se encuentra la
de inserción de datos, en la cual, para intentar estandarizar este proceso sin tener
que ceñirnos a un formato fijo de los datos de entrada, se decidió dar la posibilidad
de insertar en el sistema cualquier información que pudiese ser cargada en JUMP.
En cuanto al destino de la información, se restringió a cualquier base de datos
PostgreSQL, ya que ésta fue la tecnología elegida para dar soporte a la información
del sistema. En cualquier caso, como la conexión con la misma se hace mediante
JDBC, se podría utilizar como destino cualquier otro gestor de base de datos o
fichero de texto.
En el formulario de carga de datos simplemente se tendrá que seleccionar la capa

origen que queremos insertar en la base de datos y la tabla de la base de datos
destino, para posteriormente establecer la correlación entre los atributos del origen
y del destino de cada una de las entidades. Figura 5.
Figura 5. Formulario de Carga de Datos.
Al igual que la carga de datos, el generador de informes trabaja directamente contra

la base de datos PostgreSQL mediante JDBC. Para generalizar el tipo de consultas
o de informes que se pudiesen obtener se ha dotado al usuario de un pequeño
asistente para la generación de consultas SQL, en el que se deberá especificar las
tablas de las que se quiere consultar, las columnas y las restricciones o filtros

dentro de las mismas, como resultado se podrá obtener un EXCEL con el que se
podrá trabajar libremente (Figura 6).
Figura 6. Formulario de Informes.
Después de estudiar junto a los técnicos de medioambiente las diferentes opciones,

se decidió que la más adecuada era la del generador de consultas SQL, ya que en
este caso los usuarios tenían ciertos conocimientos técnicos en la materia y era la
mejor posibilidad para dar total flexibilidad en la generación de informes sin tener
que utilizar ningún tipo de plantilla.
Por último, la herramienta de gestión de información nos servirá para insertar

nueva información (registro a registro) o mantener actualizada la ya existente.
Como en los dos casos anteriores, la flexibilidad era una de las características
primordiales de las que debía disponer el sistema, por lo que se optó por facilitar al
usuario un explorador de entidades para poder navegar por toda la base de datos e
ir insertando, eliminando o modificando cualquiera de ellas. La forma de mostrar la
información será mediante una vista de árbol para la navegación por las diferentes
capas del sistema y una rejilla de datos con el fin de soportar cualquier tipo de
datos del origen (Figura 7).
Además esta forma de trabajar nos aporta la flexibilidad mencionada ya que el
sistema se adapta a cambios en el modelo de datos, es decir, a la inserción de
nuevas capas o de nuevos atributos en las mismas.

Figura 7. Formulario de Gestión de residuos.
6 Conclusión
Esta experiencia es la demostración práctica de que la gestión de RSU, al igual que
otros muchos temas ambientales puede ser llevada a cabo mediante aplicación de
tecnología SIG, utilizando código libre.
En esta línea, es muy extenso el abanico de posibilidades que se abre a raíz de esta
experiencia, dado el éxito de la misma, se ha visto que este tipo de herramientas
específicas pueden ser de gran utilidad. Es más, el empleo de una metodología
idónea puede dar solución a multitud de problemas o cuestiones planteadas por los
expertos de cualquier campo.
Referencias
[1] J.L Casado, "Metodología para la localización de estructuras en el ámbito
urbano. Un caso práctico”, PFC EPSA, Junio 2005.
[2] FreeGis, software libre relacionado con SIG. http://www.freegis.org
[3] JUMP Unified Mapping Platform (JUMP), http://www.jump-project.org/
[4] gvSIG, GIS de la Generalitat Valenciana. http://www.gvsig.gva.es/
[5] User-friendly Desktop Internet GIS (uDig),
http://udig.refractions.net/confluence/display/UDIG/Home

SITMUN: Sistema de Información Territorial en red para la... Sesión 7
SITMUN, Sistema de Información Territorial

en red para la administración local
Nunes Alonso, J., Ferrero Beato, I., Martínez Marín, J.,
Quirós Jiménez, J.
Laboratori d'Informació Geogràfica i de Teledetecció, LIGIT

Universitat Autònoma de Barcelona, Edifici B, 08193 Bellaterra
Tlf: 935 811 891 Fax: 935 812 001 e-mail: ligit@uab.es
Resumen
SITMUN es un proyecto desarrollado gracias al Programa INTERREG III-B

SUDOE de la Unión Europea. Lo integran siete socios principales y trece socios
colaboradores de distintas regiones de la zona SUDOE (Sudoeste de Europa).
La idea de SITMUN surge a partir de la constatación de la dificultad que supone la
implantación de proyectos SIG a nivel municipal. La solución adoptada consiste en
el desarrollo de un SIT municipal centralizado y gestionado por entes supramunici-
pales, que permita dotar de funcionalidades SIG a los ayuntamientos que, teniendo
la necesidad, no disponen de medios ni conocimientos para la implantación de un
SIG propio. Asimismo, SITMUN aparece como una solución idónea para implantar
servicios Intranet de SIG en el seno de organizaciones medias y grandes, donde la
dificultad radica en la desigual capacidad de implantación de herrramientas SIG en
los distintos departamentos, la capacidad limitada de desarrollo de aplicaciones
finales por parte de la organización y la falta de herramientas suficientemente
generales, versátiles y sin un coste económico desorbitado.
Para lograr los objetivos propuestos, SITMUN utiliza la tecnología de servidores
de mapas web, que permite que la herramienta sea gestionada y administrada por
una entidad de ámbito supramuncipal, con la idea de minimizar el coste a las
entidades locales y maximizar el número de municipios usuarios con capacidad
SIG. Con el fin de dar solución a la multiplicidad de aplicaciones posibles dentro
de la gestión municipal y supramunicipal, SITMUN se ha desarrollado en forma de
generador de aplicaciones web configurables que permita generar servicios de
mapas y funciones de consulta, localización, descargas, etc. personalizadas para
cada usuario final, y para cada territorio y dominio de aplicación a los que pueda
tener acceso cada usuario.
Palabras clave: SIG municipal, servidores de mapas web, intranet.

Sesión 7 SITMUN: Sistema de Información Territorial en red para la...
1 Introducción
La dificultad que supone la implantación de un sistema de información geográfica
en las administraciones públicas, en particular los entes locales, de reducidas
dimensiones, con escasos recursos técnicos y económicos es un problema
recurrente que ha limitado enormemente la implantación de las tecnologías de la
información geográfica en la administración local, restringida en la práctica
después de dos décadas a los municipios grandes y, en menor medida, medianos.
En general, incluso para las organizaciones grandes el grado de implantación de
SIGs corporativos y de extensión interna del uso de tales herramientas de gestión, y
por tanto de la información georeferenciada, es desigual y dista todavía de ser
completa y normalizada.
Las iniciativas llevadas a cabo por parte de las administraciones supramunicipales
(Diputaciones, Comunidades Autónomas, Administración del Estado) para superar
esta dificultad y promover el uso de las tecnologías de la información geográfica en
las administraciones locales, en particular en los municipios pequeños, han seguido
distintas estrategias que, no obstante, no han producido cambios realmente
sustanciales en cuanto al grado efectivo de utilización de dichas tecnologías.
Gran parte de las aproximaciones seguidas se han basado en dotar a los municipios
de la tecnología SIG necesaria, bien mediante el apoyo económico para financiar la
adquisición de equipos y programas, bien mediante el desarrollo de herramientas
de SIG de tipo open source, específicas para ayuntamientos o de caràcter general,
que en cualquier caso inciden también en el factor econòmico. Paralelamente, las
iniciativas de normalización, mediante modelos de datos y estándares, desarrolla-
das conjuntamente o no con herramientas de software, así como las actuaciones en
el terreno de los datos, ya sea fomentando la producción de datos o, más reciente-
mente el acceso remoto a los mismos mediante servicios web, han contibuído a
crear las condiciones necesarias, aunque no suficientes, para la implantación
generalizada de las tecnologías de la información geogràfica en la administración
local, incidiendo en el factor de la información, sobre todo en cuanto a disponibi-
lidad de datos, y en menor medida en los factores de gestión y de conocimiento.
Unas y otras aproximaciones resultan especialmente útiles para aquellas adminis-
traciones locales que están en condiciones de asumir la gestión y mantenimiento de
la información, así como la implantación y administración de la infraestructura
tecnològica necesaria tanto para llevar a cabo esa gestión como para hacer efectivo
el uso de la información en el funcionamiento ordinario de la corporación. Esas
condiciones, no obstante, lejos de ser las más habituales son más bien excepciona-
les, no sólo en los municipios pequeños que por otra parte son mayoría, sino
también en los de dimensiones medias, por debajo de 50.000 habitantes, y aún en
algunos de mayor tamaño. Así, sólo en la medida en que los factores de recursos

humanos, conocimiento y capacidad de gestión estén resueltos puede darse un

mayor grado de autonomía en la implantación y utilización de la tecnología. Ello se
refleja en la paradoja de que, existiendo más tecnología e información, y habiendo
soluciones de coste cero o casi para ambas, el número de administraciones locales
con un SIG propio no haya aumentado exponencialmente en los últimos años.
Por el contrario, para un nivel de entrada, que es el de la mayor parte de los
ayuntamientos de dimensión media o pequeña, se precisa disponer de la capacidad
de uso de la información, sin los costes de gestión propia de la misma. Más que
tecnología y datos, se precisan servicios de información personalizados proporcio-
nados por un proveedor externo, lo cual es posible mediante la tecnología de
servicios web que permite independizar las aplicaciones finales de uso de la
información con respecto a la infraestructura de gestión de ésta.
Por otra parte, aun cuando se disponga de capacidad de implantación de la
tecnología y de gestión de la información, la extensión del uso de la información y
de las herramientas SIG a los usuarios finales del conjunto de la organización sólo
será posible mediante aplicaciones finales personalizadas, lo cual implica una
notable capacidad de desarrollo de aplicaciones para la que generalmente hay que
recurrir en mayor o menor grado a proveedores externos. También ahí, la
utilización de tecnología web y el grado de personalización resultan críticos.
El proyecto SITMUN surge pues de la constatación de esas dificultades y, habida
cuenta de las limitaciones de otras aproximaciones, se plantea desde el inicio como
el desarrollo de un sistema de información territorial gestionado de forma
centralizada para proveer de aplicaciones SIG altamente personalizadas tanto a las
administraciones locales que no poseen inicialmente capacidad de implantación
propia, como a las administraciones que teniendo ya implantado un SIG no
disponen o no pueden emplear su capacidad de desarrollo de aplicaciones en
producir todas y cada una de las aplicaciones de usuario final necesarias para llegar
al conjunto de la organización.
En este sentido SITMUN aparece también como una solución idónea para
implantar servicios Intranet de SIG en el seno de organizaciones medias y grandes,
donde la dificultad radica en la desigual capacidad de implantación de herrramien-
tas SIG en los distintos departamentos, la capacidad limitada de desarrollo de
aplicaciones finales por parte de la organización y la falta de herramientas
suficientemente generales, versátiles y sin un coste económico desorbitado.
Promovido por Diputación de Barcelona en la primavera de 2002, el proyecto
SITMUN se ha llevado a cabo entre octubre de 2003 y junio de 2005 como
proyecto del Programa INTERREG III-B SUDOE, con financiación parcial
FEDER (55% del presupuesto total de 882.000 €). El proyecto ha sido desarrollado
por siete socios principales (Diputación de Barcelona, que ha actuado como
coordinador, Gobierno de Cantabria, Consorci d'Informàtica Local de Mallorca,

Consell Insular de Menorca, Universitat Autònoma de Barcelona, Universitat de les

Illes Balears y Associaçao de Municípios da Terra Quente Transmontana) y ha
contado con la participación de trece socios colaboradores (Diputació de
Tarragona, Diputació de Girona, Diputació de Lleida, Consorci LOCALRET,
Agence Départamental d’Aide aux Collectivités Locals des Landes, Associaçao de
Municípios do Oeste, Red PARTENALIA Arco Latino, Université de Perpignan,
Câmara Municipal do Funchal, Universidad Católica de Chile, Universidad de
Alicante, Ajuntament de Sant Boi de Llobregat, Associaçao de Municípios do Alto
Tâmega, Câmara Municipal de Faro).
Entre los objetivos del proyecto SITMUN, además de desarrollar herramientas que
permitan proveer de servicios de información territorial de apoyo a la gestión
municipal, figuran el de asegurar el mantenimiento de la información territorial
mediante la gestión a cargo de administraciones supramunicipales y facilitar la
homogeneidad de estructura de la información cartográfica, así como la creación de
una red europea de administraciones para la cooperación en la implantación y
desarrollo de sistemas de información territorial.
SITMUN tiene como destinatarios tanto las administraciones supramunicipales
como las administraciones municipales:
• Administraciones supramunicipales: Diputaciones, Comunidades Autónomas,
Cabildos, Consejos Insulares, Mancomunidades,..., para proveer de:
− servicios de información territorial a los ayuntamientos de su ámbito.
− servicios de información territorial intranet a nivel interno.
• Administraciones municipales: Ayuntamientos de:
− Municipios pequeños: para disponer de funcionalidad SIG a través de los
servicio proporcionados por una administración supramunicipal, que se
hace cargo además de la gestión y mantenimiento de los datos.
− Municipios medianos/grandes: para disponer de servicios de información
territorial intranet a nivel interno mediante una implantación propia de la
aplicación SITMUN.
La aplicación SITMUN, resultante del proyecto, consta de un cliente de usuario, un
cliente de administración, un motor de aplicaciones y un módulo de
administración. Actualmente exiten seis implantaciones operativas de SITMUN
(Diputación de Barcelona, Gobierno de Cantabria, Consorcio de Informática Local
de Mallorca, Consejo Insular de Menorca, Asociaçao da Terra Quente
Transmontana, y Diputación de Lleida) y se halla en proceso de constitución la Red
Europea SITMUN (más en información en http://www.sitmun.org).
A continuación se describen los aspectos más relevantes del análisis, definición
(funcionalidades y arquitectura) e implementación de la aplicación SITMUN.

2 Análisis de requerimientos
Una vez iniciado el desarrollo del proyecto, al objtivo inicial de dessarrollar una
aplicación SIG en web para proveer de servicios de información territorial a los
municipios, se añadió el objetivo de que la aplicación pudiese utilizarse igualmente
como aplicación intranet para proveer de servicios de información georeferenciada
a los distintos departamentos de una administración supramunicipal cualquiera. Es
decir no sólo de caràcter local (Diputaciones, Consejos insulares, mancomunida-
des, etc), sino también de carácter regional o autonómico.
Esta ampliación del alcance de la aplicación a desarrollar varió por completo la
naturaleza de la misma, los requerimientos a satisfacer y las soluciones de
implementación a adoptar. En pocas palabras, significó el paso de una aplicación
específica para la gestión municipal, que aun cuando amplia y diversa, y por tanto
necesitada de un grado considerable de personalización y configurabilidad, se
basaba en un dominio de aplicación acotado, a una aplicación universal para
cualquier dominio de aplicación, contenido de información y funcionalidad, ámbito
territorial y perfil de usuario, que, no obstante, para ser efectiva debía mantener un
alto grado de personalización y, con mayor razón aún, ser totalmente configurable.
2.1 Necesiadades a cubrir: contenido y funcionalidad variables
En síntesis, los requerimientos a satisfacer resultaban ser muy amplios, por cuanto
pasaban a ser múltiples i variables en todos los aspectos, pues se trataba de
desarrollar una aplicación única y personalizada de contenido y funcionalidad
variable, en función de:
• Dominios de aplicación múltiples y diversos:
− cualquier dominio de aplicación (municipal urbano, rústico, regional,
sectorial)
− distintos en cuanto a:
- tipos de información territorial
- escalas de la información cartogràfica (en origen y de visualización)
- extensión territorial
- formalización de la información
- formalización de tareas
- funcionalidad requerida
• Àmbitos territoriales variables
− para cada dominio de aplicación (núcleo/s urbano/s, municipio, conjuntos
de municipios)
− para cada perfil de usuario en cada dominio de aplicación (el propio
municipio, varios municipos conjuntamente o de uno en uno)

• Perfiles de usuario múltiples y diferenciados:

− usuarios municipales con perfiles distintos, usuarios regionales, público,...
− distintos en cuanto a:
- información visualizable / consultable
- funcionalidad disponible
- ámbito territorial accesible
2.2 Características a preservar: aplicación integrada y personalizada
Con independencia del vasto número de dominios de aplicación, ámbitos territoria-

les y perfiles de usuario a satisfacer, en ningún caso debía renunciarse al alto grado
de personalización de las aplicaciones o servicios a proporcionar a los usuarios
finales, en tanto que característica esencial y diferenciadora de SITMUN y condici-
ón imprescindible para su efectividad real. En otras palabras, para cada perfil de
usuario y dominio de aplicación, la aplicación SITMUN vista por el usuario final
debía aparecer como una aplicación distinta, a medida, con el contenido de
información cartogràfica/alfanumèrica y funcionalidad apropiadas y con acceso
sólo al ámbito territorial establecido para aquel usuario.
Por otra parte, desde el punto de vista técnico, tanto de implementación, como de
gestión del sistema y administración de la aplicación, ésta debía constituir una
única aplicación, múltiple, configurable y ampliable.
3 Definición de la aplicación SITMUN

3.1 Solución adoptada: generador de aplicaciones web
La solución adoptada para satisfacer los requerimientos mencionados de desarrollar

una única aplicación, con aspecto y comportamiento de múltiples aplicaciones para
los distintos usuarios finales, ha sido la implementación de un generador de
aplicaciones web:
• Configurables: contenidos, funcionalidades, aspecto parametrizados
• Dinámicas: cambiantes según parámetros de conexión al servicio
De este modo es posible proporcionar servicios de mapas y funciones de consultas
alfanumèricas, de localización, de descarga de datos y/o documentos, personaliza-
dos para cada usuario, territorio y dominio de aplicación.
Esta definición parte de algunas premisas básicas como son:
• Modularidad, que permite:
− independizar grupos de tareas / funciones entre sí

− distribuir la funcionalidad según dominios de aplicación y perfiles de

usuario
− reutilizar funciones
− crecer en el futuro de forma escalable mediante adición de funciones a
módulos, programación de módulos nuevos,...
• Configurabilidad, con el fin de:
− definir el comportamiento dinámico del aplicativo para cada dominio de
aplicación y usuario
− administrar contenidos, funcionalidades, perfiles de usuario
− ampliar contenidos y tareas
− personalizar el aspecto de la aplicación: imagen corporativa, idioma,...
• Personalización de la aplicación de usuario final:
− màxima para dominios de aplicación más formalizados (municipal urbano)
− orientación funcional a tareas (funciones específicas para cada fin)
− orientación funcional a usuario (mínima acción, máximo resultado)
− interfície orientada a usuario (a medida, simple, intuitiva)
Figura 1. Arquitectura lógica de la aplicación SITMUN

3.2 Arquitectura lógica de la aplicación SITMUN
La figura 1 muestra la arquitectura lógica de la aplicación SITMUN. En la misma

puede apreciarse la distribución modular de las funcionalidades, así como los
distintos componentes, tanto del lado servidor, como del lado cliente. De acuerdo
con esta arquitectura, la implementación inicial de SITMUN se organiza en 9
módulos funcionales (que proporcionan servicios y funcionalidades al usuario
final), de los cuales 3 son básicos y por tanto comunes a todos los servicios
/aplicaciones de usuario final y 6 son módulos opcionales específicos para
determinadas aplicaciones o perfiles de usuario, además de 1 módulo de gestión
(para la configuración y administración de contenidos, servicios, usuarios, etc.):
• Módulos funcionales
Básicos (comunes para todas las aplicaciones)
− Módulo servidor de mapas web: servicios de mapas configurables
− Módulo de localización: mediante direcciones, topónimos, parcelas,...
− Módulo servidor de catálogo de metadatos (no implementado inicialmente)
Adicionales (variables según dominio de aplicación y perfil de usuario)
− Módulo de consultas alfanuméricas
− Módulo de información ampliada
− Módulo de generación dinámica de informes
− Módulo de visualización de documentos asociados
− Módulo de descarga de mapas imprimibles
− Módulo de descarga de datos (según condiciones / restricciones aplicables)
• Módulos de gestión
− Módulo de administración: configuración de contenidos, funcionalidades,
aplicaciones, ámbitos territoriales y usuarios
3.3 Arquitectura funcional de la aplicación SITMUN
Desde el punto de vista funcional SITMUN consta de tres aplicaciones cliente, dos
para el usuario final (el cliente general SITMUN y el cliente específico de consulta
de metadatos SITMUN), integradas entre sí, y una para la administración de la
aplicación (cliente de administración SITMUN), así como de dos aplicaciones del
lado servidor (el motor de aplicaciones SITMUN, que realiza las distintas
funciones de servidor de mapas, consultas alafanuméricas remotas, etc.; y el
módulo de administración, que ejecuta las funciones de gestión de la base de datos
de administración de la aplicación SITMUN, en la que se almacenan los valores de
la multitud de parámetros que definen cada función, contenido, aplicación, perfil de

usuario, etc). La funcionalidad de los distintos clientes y aplicaciones del lado

servidor es la siguiente:
• Cliente general SITMUN
– funcionalidad general de visualización, navegación, interacción, consulta,
selección, selección espacial, medidas, etc.
– funcionalidad de localización (según dominio y perfil de usuario).
– acceso al catálogo de metadatos, a través del cliente de metadatos.
– acceso a funcionalidad adicional (según dominio y perfil de usuario).
– llamada a clientes de visualización de resultados (navegador web,
aplicaciones externas, ...).
Figura 2. Aspecto del cliente general SITMUN
• Cliente específico de consulta de metadatos SITMUN

– visualización de metadatos para capas seleccionadas en el cliente general
(ficha resumen o ficha completa)
– consulta del índice completo del catálogo de metadatos
– búsquedas por condiciones (título, productor, territorio, palabras clave,...)

– visualización de metadatos para capas seleccionadas en el índice del

catálogo o en los resultados de búsquedas (ficha resumen o completa)
– acceso al cliente general para visualizar los datos, desde el índice del
catálogo o desde la ficha de metadatos
Figura 3. Aspecto del cliente de administración SITMUN
• Cliente de administración SITMUN

Configuración:
– capas a incluir en el servidor de mapas (fuentes de datos, simbolización, ...)
– aplicaciones (capas incluídas, funcionalidades disponibles, servicios de
localización, ...)
– ámbitos territoriales aplicables (según aplicación y usuario)
– elementos a localizar en los servicios de localización
– fichas de información ampliada
– consultas alfanuméricas preestablecidas
– documentos asociados al territorio

– documentos dinámicos a generar (fichas / informes / cédulas)

– documentos imprimibles disponibles para descarga
– datos disponibles para descarga
– perfiles de usuario
Administración:
– servicios de mapas (generación, arranque, parada)
– territorios disponibles
– usuarios (altas, bajas, modificaciones)
• Motor de aplicaciones SITMUN
– control de acceso (verificación de usuarios).
– configuración dinámica del servicio de mapas y funciones adicionales,
según parámetros asociados al usuario para el dominio de aplicación
(contexto) y territorio elegidos, de entre los registrados para el usuario.
– gestión de peticiones efectuadas sobre el servicio de mapas y resto de
funciones de consulta, localización, generación / visualización /descarga de
documentos.
• Módulo de administración SITMUN
– gestión de modificaciones de parámetros de configuración almacenados en
la base de datos de administración de la aplicación SITMUN.
3.4 Administración de la aplicación SITMUN
La complejidad de una aplicación totalmente parametrizada a fin de conseguir un

comportamiento y aspecto configurables y dinámicos ha implicado desarrollar una
base de datos de almacenamiento de parámetros de acuerdo con la estructura lógica
de funcionamiento de la aplicación, así como una aplicación en si misma,
independiente de la aplicación de servicios y cliente para usuarios finales,
destinada a la administración de dicha base de datos (módulo y cliente de
administración SITMUN).
Tal como muestra la figura 4, cada usuario final puede poseer múltiples perfiles y
acceso a múltples ámbitos territoriales. Asimismo, para cada perfil y contexto
(dominio de aplicación) se dispone de acceso a determinados grupos de capas de
información cartográfica, definiendose por otra parte un contexto como un
conjunto de capas de información cartográfica (visibles / consultables en el servicio
de mapas) y opcionalmente un conjunto de funciones adicionales de entre las
establecidas. Los grupos de capas constan a su vez de un conjunto de capas de
información cartográfica que se comporta como un único ítem (visible / no visible)
en el servicio de mapas para mayor facilidad de uso. Finalmente la abstracción de
las distintas funciones en una serie de tipos básicos generales (consultas alfanumé-

Figura 4. Modelo conceptual de administración de la aplicación SITMUN
cas, localizaciones y descargas de ficheros), permite gran versatilidad para definir

funcionalidades personalizadas mediante la combinación de tipos y la especifi-
cación de los parámetros particulares de cada consulta, localizador, etc. Porúltimo
la vinculación de capas y funciones a ámbitos territoriales permite establecer si
existe o no disponibilidad de las mísmas para un territorio dado, con lo que es
posible definir aplicaciones generales que tengan mayor o menor contenido /
funcionalidad según dispobilidad parcial de información. Igualmente se han
generalizado los orígenes de datos tanto cartográficos, como alfanuméricos, de
modo que es posible acceder a distintos formatos y ubicaciones locales o remotas,
ya se trate de ficheros o de conexiones a bases de datos espaciales o alfanuméricas.
Cabe señalar que en el caso de las consultas alfanuméricas es posible almacenar los
parámetros para una consulta directa a una base de datos (sentencias SQL,
argumentos, etc.) como el URL y los parámetros necesarios para efectuar la
consulta a través de otro servicio web de terceros.
4 Implementación
La implementación del motor de aplicaciones SITMUN se ha realizado utilizando
JSP y Java (J2EE). Para módulo de administración se ha empleado Java (J2EE)

mediante el entorno que proporciona MyEclipse y utilizando Hibernate para crear

las clases de objetos persistentes a partir de la base de datos de administración de
SITMUN, así como Struts para desarrollar las páginas JSP del cliente a las que
posteriormente se ha modificado la capa de presentación para implementar el
aspecto final de la interface. El cliente general SITMUN, mediante el cual acceden
los usuarios finales al servicio de mapas y aplicaciones de SITMUN de acuerdo
con la configuración correspondiente a cada usuario en cada territorio y dominio de
aplicación, ha sido implementado mediante JavaScript para conseguir las
prestaciones de HTML dinámico.
Figura 5. Arquitectura de implementación de SITMUN
La aplicación SITMUN se apoya en un conjunto de componentes de software de

base, para los cuales caben distintas opciones, dado que la aplicación SITMUN es
independendiente de la mayor parte de software de base empleado. Como gestor de
bases de datos relacional, para albergar la base de datos de administración de

SITMUN, las bases de datos alfanumèricas asociadas a la información cartogràfica

y el almacenamiento de los datos espaciales pueden emplearse Oracle o SQL
Server. Para el servidor de datos espaciales admite Oracle Spatial o ArcSDE, y
tamién en caso de prescindir de base de datos espacial soporta la utilización de
ficheros en formato shape. En la implementación actual (figura 5), el servidor de
mapas empleado es ArcIMS, si bien la aplicación en sí sólo utiliza las funciones
del servidor de mapas para la visualización y funciones básicas de navegación y
consulta interactiva por lo que puede adaptarse fácilmente a otros servidores de
mapas. Por último, el servidor de aplicaciones (motor de servlets) y el servidor
Web son componentes generales, disponibles en la mayoría de organizaciones,
pudiendo emplearse la mayor parte de productos comerciales o open source
disponibles. En las implantaciones existentes de SITMUN se ha empleado
generalmente Apache y TomCat Jakarta y también en alguos casos Internet
Information Server y su correspondiente motor de servlets.
5 Conclusiones
SITMUN proporciona una solución idónea para dotar a los municipios pequeños y
medios de funcionalidad SIG y aplicaciones finales de gestión personalizadas
basadas en información georeferenciada, con las ventajas evidentes de coste cero
para las organizaciones usuarias, facilidad de uso y universalidad (exclusivamente
aplicaciones y servicios web), y de liberación de los costes de gestión y
mantenimiento de la información, así como de desarrollo de aplicaciones finales, al
hacerse cargo de todas estas funciones centrales la administración municipal que
actua como proveedor de servicios.
Igualmente, en la medida en que permite generar aplicaciones finales web
personalizadas sin necesidad de programación alguna (basta establecer los
parámetros de configuración mediante el cliente web de administración) y
utilizando un único servicio de mapas integrado, proporciona una buena solución
como aplicación para desarrollar el SIG Intranet en administraciones grandes o, de
hecho, en cualquier organización puesto que los contenidos de información y las
funciones adicionales son totalmente libres y configurables.
SITMUN tiene como principal destinatario los municipios pequeños y medios para
los que se ofrece como una opción a nivel de entrada, sin coste alguno. El principal
impacto o papel de SITMUN en la implantación de las tecnologías de la
información geográfica en la administración local puede consistir en un efecto
dinamizador de arranque para un uso inicial de la información y la tecnología entre
los municipios de este segmento, a partir del cual una vez iniciados pueden requerir
y optar por soluciones de mayor autonomía y alcance funcional (incluída la propia

evolución de SITMUN en ese sentido). Adicionalmente, SITMUN puede tener

también un papel dinamizador y normalizador en el terreno de la información
territorial manejada por las administraciones locales al asumir las administraciones
supramuniciopales la gestión, organización y mantenimiento de la información.
Ambos efectos pueden extenderse, aunque en menor grado, a nivel interno de las
administraciones grandes (municipales y supramunicipales) al permitir implantar
SIGs Intarnet con rapidez, sin costes de desarrollo y probablemente sin inversión
adicional, por cuanto la mayor parte de software de base está ya disponible y la
licencia de uso de la aplicación SITMUN se obtiene gratuitamente con la simple
adhesión a la Red Europea SITMUN.
En el plano técnico, cabe remarcar la robustez de la arquitectura de SITMUN, así
como las soluciones ideadas para desarrollar una aplicación dinámica que se
comporta como múltiples aplicaciones a nivel cliente siendo una única aplicación y
un único servicio de mapas a nivel servidor con la consiguiente simplicidad de
administración. De ambos aspectos destaca sin duda la robustez de arquitectura, en
la medida en que independiza la aplicación de los componentes de software de base
fácilmente intercambiables o sustituibles por los preferibles en cada caso, y sobre
todo el hecho de que las soluciones actuales de implementación de las distintas
funciones y el desarrollo de nuevas funciones puede ser sustituido o enriquecido
por otras opciones basadas en nuevas tecnologías de servicios web a medida que
aparezcan o se consoliden. En este sentido, SITMUN puede y debe evolucionar en
tres grandes ejes de desarrollo. En primer lugar, la incorporación de tecnologías
web de mayor nivel de integración (servicios web basados en SOAP, interfaces
basadas en AJAX, servicios OGC para la información georeferenciada). En
segundo lugar, el acceso de terceros a las distintas funciones y servicios
indvidualizada con el fin de poder incluirlos en sus aplicaciones web o de
componer su versión particular de SITMUN, a modo de SITMUN a la carta. Por
último, y como es lógico, el desarrollo de nuevas funcionalidades más
diversificadas y de mayor alcance, entre las cuales y a título de ejemplo cabe
mencionar la bidireccionalidad de las funciones de información alfanumèrica paea
tareas de gestión y de actualización, la edición gráfica en entorno web, la obtención
de mapas temáticos personalizados desde el cliente final, y un largo etcétera que
los propios usuarios, tanto finales como proveedores, están ya explicitando a los
pocos meses de implantación y que sin duda no hará sino crecer en el futuro.

Sesión 7 Interfaces tangibles de usuario aplicados a la Información Geográca:...
Interfaces tangibles de usuario aplicados a la

Información Geográfica:
Cartografía interactiva mediante Visión por Ordenador
Jorge Cano Fuentes, Miguel A. Bernabé, Miguel A. Manso
Laboratorio de Tecnologías de la Información Geográfica (LatinGEO)

E.T.S.I. en Topografía, Geodesia y Cartografía
Universidad Politécnica de Madrid
Campus Sur, Crta. Valencia, km. 7,5, 28031 Madrid
e-mail: jcano@topografia.upm.es, ma.bernabe@upm.es, m.manso@upm.es
Resumen
En el Laboratorio de Tecnologías de la Información Geográfica (LatinGEO), se está actualmente

trabajando en un prototipo de visualizador basado en el concepto Tangible User Interfaces
(TUIs), que se entienden como la interrelación entre un producto material y un software de
control, que en conjunto generan una respuesta unificada para el usuario. En base a un estímulo
(dinámico, acústico, variación de un campo, etc.) del mundo real “percibido” por el ordenador,
éste es capaz de procesar y generar una respuesta, resultando un cambio físico en un dispositivo
de salida (monitor, dispositivo de feedback táctil,…) [1].
En el caso del visualizador prototipo, el usuario actúa como input a través de movimientos de su
cuerpo .El ordenador capta dichos movimientos y genera una respuesta en pantalla que deriva en
una visualización tridimensional de la información geográfica.
1. Introducción
La generalización en el uso de los sistemas informáticos exige hacer más natural y accesible la
comunicación y la interacción entre los usuarios y los ordenadores. El área de investigación
denominada IPO o Interacción Persona-Ordenador, aparece como consecuencia de la anterior
necesidad y se desarrolla gracias a la mejora de los equipos informáticos y a la aparición de
herramientas y aplicaciones cada vez más sofisticadas.
Las GUIs o Interfaces Gráficas de Usuario (Graphic User Interfaces), nacen como puentes de
comunicación entre el hombre y la máquina, y son sistemas de metáforas gráficas
correspondientes a acciones reales (copiar, pegar, cortar, acercar, deshacer, tirar, etc.) que utilizan
ventanas y botones que se manipulan desde la pantalla del ordenador utilizando el ratón como
dispositivo de entrada.
En este sentido, el ratón permite al usuario, con el uso exclusivo de su mano, controlar acciones y
objetos que ocurren y existen sobre la pantalla, mientras que en el mundo real la interacción con
los objetos se realiza utilizando más partes del cuerpo [2]. Esta interacción con el ordenador por
medio del ratón, conduce a que el usuario sea consciente en todo momento que aquello que es
capaz de mover con el ratón es algo que está situado “fuera de su realidad”. Utilizando más partes

Interfaces tangibles de usuario aplicados a la Información Geográca:... Sesión 7
de su cuerpo, el usuario puede recibir otras sensaciones de mayor integración de las imágenes de
la pantalla con la propia realidad.
El presente trabajo ofrece una alternativa, en el campo de la visualización cartográfica, que

implica una mayor participación física y sensorial y propone nuevos escenarios de interacción
basados en el cuerpo y su movimiento.
Palabras clave: Interface tangible, vision por ordenador, cartografía,
2. Visualizador cartográfico
2.1. Antecedentes
El presente estudio viene motivado por el interés de posibilitar que la visualización de la

información geográfica real pueda incorporarse en entornos poco utilizados con anterioridad,
(ocio, juego, viajes) e incluso hacerla más atractiva y dinámica para entornos de docencia. Para
ello se ha creado un navegador cartográfico basado en visión por ordenador. El usuario interactúa
con la información geográfica mediante los movimientos de su cuerpo, que son captados por una
cámara de video y procesados por el ordenador.
Uno de los objetivos perseguidos es la creación de un sistema sencillo con la posibilidad de

realizar el montaje en cualquier entorno, como por ejemplo en una agencia de viajes o en un aula,
sin que sea necesario variar las condiciones de dicho entorno.
Para la utilización de otros sistemas similares es preciso contar con unas condiciones ambientales
muy específicas o con la utilización de elementos externos al usuario (sensores, reflectores, etc.)
lo que complica la instalación. Como ejemplo de este tipo de sistemas podemos ver el trabajo
realizado por Golan Levin y Zachary Lieberman en la instalación “Messa di voce” (figura 1). Para
calcular la posición de la cabeza del visitante y emular la salida de los sonidos de su boca, se
necesita un fondo iluminado que cree un contraste entre su sombra y el entorno, lo que requiere
de una superficie amplia, un sistema de iluminación y un proyector de video.
Figura 1.Instalación “Messa di voce”

En el visualizador propuesto (figura 2) se utiliza únicamente un ordenador y una webcam, las

partes visibles del sistema son una pantalla y la cámara, que se sitúa sobre esta, obteniendo un
conjunto compacto que puede ubicarse en prácticamente cualquier sitio.
Figura 2.Visualizador
2.2. Desarrollo
El desarrollo del visualizador surge a partir del estudio de algunas interfaces en las que se utiliza
el movimiento del cuerpo para controlar las acciones que realizan algunas aplicaciones de
entretenimiento, tales como las del juego para PlayStation EYETOY.
En el prototipo que se presenta la imagen del usuario se superpone a un plano situado dentro de
un escenario tridimensional, y según la posición y el movimiento del usuario se producen los
desplazamientos dentro del entorno virtual, que en este caso es un Modelo Digital del Terreno
(MDT), sobre el que pueden superponerse distintas imágenes, como ortofotografías y mapas, que
aportan las texturas y la información geográfica al escenario.
Figura 3. Prototipo A
En la figura 3 se ve una captura de la aplicación, en la que se observa el entorno virtual, en este

caso parte de la cartografía de La Rioja, superpuesta sobre un modelo digital que proporciona
tridimensionalidad. En la parte central de la imagen se puede observar la zona de interacción y de
información. Esta zona está formada por un plano semitransparente que contiene la imagen
recogida por la cámara de video, donde se observa tanto al usuario como un puntero 2D
(amarillo) que se desplaza siguiendo el movimiento de dicho usuario.

Interfaces tangibles de usuario aplicados a la Información Geográca:... Sesión 7
Tanto en la parte inferior, por medio de una barra de desplazamiento, como en la zona de
interacción, por medio de cuatro punteros que indican la situación NSEW, puede apreciarse el
valor de la rotación que está tomando la cámara virtual en un instante.
Únicamente cuando el usuario se mueve frente a la pantalla, se produce un desplazamiento dentro

del entorno, consiguiendo así una relación más natural entre el entorno real y el virtual.
Para avanzar en línea recta, el puntero amarillo ha de estar en una posición centrada respecto al
eje vertical, y según sea el desplazamiento que se desee dentro del entorno, se deberá desplazar el
cuerpo en una u otra dirección. Con este sistema también existe la posibilidad de desplazarse
verticalmente al terreno, lo que permite tener distintos niveles de zoom.
En la parte superior izquierda de la imagen central se observa el puntero 3D (rojo), que también
es sensible a los movimientos y que se desplaza por el terreno. Muestra las coordenadas punto del
terreno sobre el que se encuentra en cada momento. En la figura 3 la información que aparece
(z:1842) es la altura en metros del punto del terreno sobre el nivel del mar. En cualquier caso
podría desarrollarse el sistema según las necesidades de información requeridas para cada
aplicación.
2.3. Datos técnicos
El modelo digital del terreno utilizado en este prototipo cubre toda la Comunidad Autónoma de
La Rioja, con una resolución en altimetría de 25 metros.
Las imágenes utilizadas para conseguir la textura del terreno son ortofotos y mapas del Servicio
Geográfico Ejército, con una resolución máxima de 2.048 píxeles de lado. Con este material se ha
obtenido una resolución final de 8 metros por píxel.
Figura 2. Modelo digital del terreno y ortofoto (izq.), modelo 3D (der.)
El entorno de creación de la aplicación ha sido DirectorMX, utilizando TrackThemColorsXTRA

para la captura de video.
La posición del usuario se calcula utilizando un algoritmo de detección de movimiento, por lo que
si no existe movimiento frente a la cámara, la aplicación está en estado de reposo.

El sistema calcula las zonas donde ha habido movimiento, es decir, las partes de la imagen actual
en las que existen diferencias de color o brillo respecto del fotograma anterior. Estas zonas
delimitan una serie de rectángulos. Los centros de estos rectángulos se promedian, y se obtienen
unas coordenadas X e Y , que son utilizadas para manejar la vista dentro del escenario 3D.
El hecho de que después del procesado de la imagen el sistema simplifique y obtenga un punto
2D hace sencilla la utilización del navegador.
2.4. Conclusiones
El sistema desarrolla un método y una aplicación educativa cercana al mundo del videojuego, que
persigue una mezcla entre lo lúdico y lo pedagógico, que facilita el proceso de enseñanza y
aprendizaje.
Bajo coste de la instalación del sistema, tanto en medios materiales como humanos.
Facilidad para incorporar nuevos escenarios.
2.5. Futuras aplicaciones
Con vistas a mejorar el estudio y comprensión del territorio por estudiantes, se proponen las
siguientes posibilidades de aplicación:
• Juegos relacionados con la ubicación y la localización

• Elección de rutas en búsqueda de hitos informativos.
• Visualización en 3D de distintas características asociadas al terreno. Ejemplo: clima,
edafología, usos del suelo, etc.
• Creación de un modo en el que varios usuarios cooperen e interaccionen.
• Visualización de datos remotos.
• Sistema de inmersión estereoscópica para la visualización, utilizando para ello un
conjunto de ordenadores conectados en red.
REFERENCIAS
[1] Tur Costa, Antonio (2004). “Evaluación de Dispositivos Hardware y Software”
[2] Dan O´Sullivan and Tom Igoe, “Physical Computing”, 2002

Infraestructura de Datos Espaciales. Servicio WFS de la D.G. del... Sesión 7
Servicio WFS de la D.G. del Catastro.

Infraestructura de Datos Espaciales
A. Cano, L. Virgós, J. M. Olivares, F. J. Quintana, F. García Cepeda
Subdirección General de Estudios y Sistemas de Información

Dirección General de Castastro
Paseo de la Castellana 272, 28046 Madrd
1. Introducción
Siguiendo la propuesta de la directiva europea INSPIRE , Infraestructura

para Información Espacial en Europa, y en consonancia con el Consejo Superior
Geográfico, organismo que coordina la creación de la IDEE, Infraestructura de
Datos Espaciales de España, la Dirección General del Catastro inició su
andadura en un novedoso campo que tiene por objetivo la interoperatibilidad
entre interfaces que presentan información geográfica.
Las tecnologías, los estándares, los acuerdos entre instituciones y la

actual filosofía acerca de la liberalización de los datos sientan los cimientos para
que organismos públicos se unan a este tipo de iniciativas.
La Dirección General del Catastro recopila, mantiene y actualiza un gran

volumen de datos catastrales, y como gestor de los mismos, comienza a crear
nuevos servicios Web definidos bajo las directrices y estándares establecidas
por el Open Geospatial Consortium – OGC – .
En la actualidad la D.G.C. brinda un servicio WMS de desarrollo propio

que se encuentra en producción, el cual ha despertado un gran interés a tenor del
éxito contrastado hasta la fecha. Siguiendo este camino, en esta comunicación
se presenta la puesta en marcha de un servicio WFS inicialmente de acceso
restringido y gratuito destinado a entidades con acuerdos o convenios. En un
futuro próximo se prevén otros servicios tales como un servicio de Gazetteer
contribuyendo al crecimiento de la IDEE. Todos estos servicios amplían los
interfaces para la gestión y publicación de datos de carácter público siempre
bajo las restricciones propias impuestas por la actual legislación sobre
protección de datos de carácter personal.
En la OVC, Oficina Virtual del Catastro, se proporciona un visualizador

de la cartografía catastral basado en los mismos principios definidos por los
estándares de el Open Geospatial Consortium (OGC). Esta experiencia es el
punto de partida que lleva a la D.G.C. a implementar otros servicios web
estándar bien mediante desarrollo propio o a partir de productos de software
libre.

Sesión 7 Infraestructura de Datos Espaciales. Servicio WFS de la D.G. del...
Directrices y Estándares.
2. IDE y Sistema de Información Catastral
Los Servicios Web son una puerta de enlace con el Sistema de

Información de la Dirección General del Catastro cumpliendo así objetivos
básicos de esta Dirección General en cuanto a la mejora en la calidad y eficacia
de los recursos de asistencia al ciudadano, así como, en cuanto a los medios de
difusión de la información que esta Dirección General debe potenciar en virtud
del cumplimiento de sus competencias.
Para el desarrollo de sus competencias, esta Dirección cuenta con un

entramado humano y tecnológico que constituye en su conjunto un Sistema de
Información denominado Sistema de Información Catastral, el cual se divide en
varios subsistemas, uno de los cuales se denomina Sistema de Información
Geográfica Catastral (SIGCA) que nutre a los servicios Web WMS y WFS.
Dicho subsistema se compone de bases de datos con información

geográfica en formato digital, aplicaciones para su mantenimiento y
actualización, y un gran equipo humano distribuido a nivel nacional que
gestiona el dato día a día. Otras entidades externas tanto de carácter público
como privado, ayuntamientos, notarios y registradores o empresas privadas de
asistencia técnica, colaboran constituyendo el fuerte entramado que subyace
alrededor de estos Servicios Web.

Sistema de Información de la D.G.C
El ámbito territorial sobre el que tiene competencias la Dirección

General del Catastro cubre todo el área nacional, exceptuando Navarra y el País
Vasco que cuentan con sistemas propios para la gestión catastral. Un conjunto
de Gerencias Regionales y Territoriales repartidas por todo el territorio son las
encargadas de realizar el trabajo de actualización y mantenimiento de la
información, ya sea gráfica o alfanumérica, alojando los datos recopilados en
sus propias bases de datos.
Los Servicios Centrales, cuentan con una sincronización diaria de las

mismas, obteniendo así todas las modificaciones y actualizaciones que se hayan
originado. Esta estructura constituye una base de datos distribuida, con un
almacenamiento central ubicado en Madrid, que a su vez es la fuente de datos,
tanto para la Oficina Virtual del Catastro (OVC) como para los servicios WMS
y WFS.
En la base de datos centralizada se alojan mas de 41,7 millones de parcelas

rústicas y 12,5 millones de parcelas urbanas, a lo que hay que añadir el resto de
elementos geométricos y atributos que componen la información cartográfica
catastral. Tal volumen de datos provoca que los servicios Web ofertados por la
Dirección General del Catastro sean de gran interés y destaquen tanto a nivel
nacional como internacional.

3. Cartografía Catastral:
La Dirección General del Catastro ejerce las competencias sobre

formación y mantenimiento del Catastro Inmobiliario en un ámbito territorial
que abarca España, exceptuando Navarra y el País Vasco, que como
anteriormente se dijo, poseen competencias propias en esta materia. Dentro de
estas funciones se encuentran la elaboración y gestión de la cartografía catastral
así como la difusión de la información.
La información cartográfica catastral en soporte digital se almacena en la

base de datos central BDNC Base de Datos Nacional del Catastro. Contiene
datos geográficos, así como datos alfanuméricos asociados de libre difusión
según la ley orgánica de protección de datos de carácter personal.
Los datos se encuentran estructurados dentro de la BDNC en bases de

datos distintas para cada delegación. Como se detalló anteriormente las
gerencias se corresponden con provincias, no obstante algunas provincias
pueden contar con varias gerencias.
Es importante considerar que cada provincia puede quedar cubierta por

uno o dos husos, según define la proyección U.T.M. utilizada para representar la
cartografía catastral. Debido a esto, la unidad territorial, que se ha definido
como el Municipio, se encuentra en ocasiones bajo dos husos aunque alojada en
una misma base de datos.

Distribución B.D. por provincias.
Los procesos de replica automatizados desde las Gerencias Regionales y

Territoriales que se llevan a cabo día a día mantienen esta información
actualizada en la base de datos central BDNC.
Las características técnicas de la Cartografía Catastral que se almacena

son las siguientes:
• Sistema de referencia: Sistema Oficial de España ED50 para

Península y Baleares (husos 29, 30 y 31) y Sistema WSG84 para
Canarias (husos 28).
• Sistema de Representación: Proyección U.T.M. en los husos 27,
28, 29, 30 y 31.
• Ámbito de unidades de proceso: Término municipal.
• Productos cartográficos: Mapa continuo con cartografía de zonas
urbanas y rústicas.
- Cartografía Catastral de Urbana: Escalas de
representación 1:500 y 1:1.000
- Cartografía Catastral de Rústica: Escalas de
representación 1:2.000 y 1:5.000
4. Servicio WFS:
Podemos definir un servicio WFS (Web Feature Service ) como un

servicio de mapas que publica cartografía en formato vectorial proporcionando
un medio de gestión y visualización de datos geográficos a través de la red en
un formato editable.
Un servicio WFS estándar garantiza la interoperatibilidad entre interfaces, y

es aquel que es capaz de procesar una consulta realizada mediante una instancia

que se construye según los criterios definidos por el OGC a través de la

especificación:“Web Feature Service Implementation Specification” .
Para la implementación de un Servidor WFS de la D.G.C. se ha optado por

un recurso de Software Libre que cumpla un conjunto de requisitos mínimos
necesarios para cubrir el objetivo de publicar los datos cartográficos de carácter
público en formato vectorial almacenados en la BDNC.
La selección se llevó a cabo bajo tres requisitos establecidos previamente.

El primero imponía la necesidad de que el producto estuviera registrado por el
OGC garantizando así la interoperabilidad y el cumplimiento de los estándares
sobre servicios WFS. Un segundo requisito quedaba determinado por la
compatibilidad con la tecnología empleada por la Dirección General del
Catastro, destacándose, por ejemplo, la necesidad de que el servidor de Internet
compatible con el producto fuese “Internet Information Server” de Microsoft,
así como que el producto soporte ArcSDE. El tercer y último requisito trataba
de aprovechar el trabajo desarrollado por entidades con una reconocida
trayectoria al elegir un producto que ya estuviese en producción suficientemente
probado asegurase un funcionamiento estable.
Este conjunto de requisitos básicos determino que la elección del producto

fuese sencilla, concluyéndose en el producto MapServer de UMN MapServer
Project.
5. MapServer -UMN MapServer Project -:
El producto MapServer es un entorno de desarrollo de Software Libre que

sirve para construir aplicaciones Web de datos espaciales.
MapServer puede emplearse para el desarrollo de clientes WMS y WFS,

opera como servidor WMS y WFS no transaccional, cumple con la
especificación WMC (web map context), y soporta las especificaciones para la
definición de los estilos de visualización SLD (Style Layer Descriptor), y FE
Filter Encoding para la definición de filtros espaciales, lógicos y aritméticos.
En relación con los formatos soportados, este producto soporta todos los
incluidos en las librerías GDAL/OGR, incluyendo ESRI Shapefiles y ESRI
ArcSDE formatos empleados mayoritariamente por este organismo.
En la pagina oficial podemos encontrar un paquete con el código fuente que

debe ser compilado para la obtención del CGI encargado de recibir y ejecutar
las peticiones solicitadas a los servicios que brinda.
Existen un conjunto de librerías externas necesarias para el funcionamiento

del producto de las cuales algunas son obligatorias y otras opcionales, en el caso
de que se deseen otros formatos alternativos. Un ejemplo de algunas librerías
opcionales y obligatorias son JPEG library PNG library Zlib FreeType PROJ.4
GDAL/OGR ArcSDE EPPL7

Mapserver se compone del producto, básicamente un CGI junto con unas

librerías, y un fichero de configuración denominado mapfile. Se accede a través
de un servidor de Internet y en el caso en que se implemente un cliente se
incluirán plantillas HTML si dicho cliente se ha desarrollado a partir de este
lenguaje y con los objetos que brinda el propio producto.
Es compatible con varias fuentes de datos, las cuales deben ser tipo vector
para un servicio WFS, como por ejemplo OGR, PostGIS, SDE, SDO,… En el
caso de la D.G.C. la fuente de datos está en ArcSDE almacenada en Oracle.
Servicio WFS.
Una petición a un Servicio Web de MapServer se realiza invocando el

MapServer CGI y definiendo la variable “map” para determinar la ubicación del
fichero de configuración Mapfile, por ejemplo:
http://localhost/mapserver/mapserv.exe?map=c:\mapserver\mapfile\ejemplo.map
A continuación se incluyen en esta URL el resto de parámetros que

cumplen el estándar de la OGC y que determinan como es el servicio que se
invoca, la versión del mismo, y el operador deseado, sin olvidar la capa de datos
sobre la que se realiza la consulta. Un ejemplo de una petición con los
parámetros mínimos necesarios quedaría de la siguiente forma:
&SERVICE=WFS&version=1.0.0&REQUEST=GETfeature&typename=masa&

Las operaciones que admite el Servicio son las básicas para un Servidor
WFS no transaccional: GetCapabilties, DescribeFeatureType and GetFeature,
descritas en profundidad dentro de las especificaciones de la OGC para este tipo
de servicios.
MapServer cuenta con un conjunto de API’s (Interfaz de Programación

de Aplicaciones) son un conjunto de especificaciones de comunicación entre
componentes software, se utilizan mediante el lenguaje Mapscript. Mediante
Mapscript se pueden generar aplicaciones que se comuniquen directamente con
dichas API’s.
6. Servicio WFS –MapServer- de la D.G.C.:
El servicio WFS (Web Feature Service ) de la D.G.C., es un servicio de

mapas por Internet para publicar la cartografía catastral en formato vectorial
junto con aquellos atributos de libre difusión según la normativa legal vigente.
El servicio se invoca a partir de una URL definida manualmente en un

navegador de Internet, o mediante el uso de aplicaciones GIS o visualizadores
de mapas Web que soporten dichos servicios.
GML transformado a gráfico mediante la herramienta TatukGis.
El resultado de una petición al servicio WFS de la D.G.C. devuelve

información en un derivado del lenguaje de marcado XML llamado GML, por
tanto se obtiene un documento en GML que contiene información catastral

compuesta por geometrías y datos alfanuméricos asociados de las diferentes

capas definidas en el modelo de datos de la BDNC.
Para conocer las capas y sus propiedades principales que brinda el servicio
podemos invocar al operador GetCapabilities que devuelve un documento XML
detallando las características y la estructura de la información que se publica.
Ejemplo:
&SERVICE=WFS&version=1.0.0& REQUEST=GETCAPABILITIES&
En este ejemplo se muestra el resultado de invocar al operador

GETCAPABILITIES del servicio WFS de la D.G.C. .
El resultado de esta petición es similar al ejemplo siguiente:
Una petición de información se realiza invocando al operador

GETFEATURE e indicando al menos la capa sobre la que se realiza la misma.
Ejemplo:
http://localhost/mapserver/mapserv.exe?map=c:\mapserver\mapfile\ejemplo.map&SE
RVICE=WFS&VERSION=1.0.0&REQUEST=GETFEATURE&TYPENAME=MASA

Parte del resultado de esta petición sería el siguiente:
En el caso de que las peticiones se realicen desde visualizadores de mapas

Web o aplicaciones GIS compatible con este tipo de servicios, el documento
GML generado se presenta directamente transformado en un mapa, y puede ser
visualizado conjuntamente con otros servicios Web de este organismos u otros
compatibles con las especificaciones de la OGC.
7. Configuración del Servicio WFS de la D.G.C.:
La información que publica el servicio se encuentra distribuida por

gerencias territoriales. Aunque estas gerencias se corresponden con las
provincias del territorio nacional sobre las que ejerce competencias la D.G.,
existen algunas provincias que cuentan con varias gerencias.

Bajo esta estructura organizativa la base de datos se compone de distintas

bases de datos para cada una de las gerencias. Este criterio no conlleva
problema alguno en el caso del almacenamiento de la información alfanumérica,
pero si en el caso de la información gráfica.
Para almacenar los datos gráficos en la base de datos empleando el sistema

de representación UTM. era necesario tener en cuenta la división del territorio
por husos. Las gerencias, según su ubicación geográfica pueden quedar
incluidas en un huso o en dos.
En el caso en que queden en dos husos las bases de datos gráficas

almacenan coordenadas pertenecientes a husos distintos. No obstante, se optó
por el criterio de que la unidad territorial, que queda constituida por el
Municipio, se encontrase en un solo huso, seleccionando uno de ellos cuando
este necesariamente partido por una división de estos.
Por esta causa, y teniendo en cuenta que, según recoge la especificación de

la OGC para este tipo de servicios, la información que se brinda solo puede
hacerse en un solo sistema de representación, por lo que datos en husos distintos
no son convertidos a un solo huso, al invocar el servicio deberán incluirse
nuevos parámetros no estándares pero que determinen con detalle que datos se
desean consultar.
Los datos que ofrece este servicio WFS se encuentran en el sistema de

referencia y huso de origen, no permitiendo dicho servicio, según recoge la
especificación OGC, obtener los datos en varios sistemas de referencia.
Podemos conocer cual es el sistema de referencia y huso de origen de cada
delegación mediante una petición de las propiedades del servicio con el
parámetro request igual a getcapabilities (request=getcapabilities), según se
recoge con anterioridad. Ejemplo: EPSG:23030 identifica el sistema de
referencia, proyección cartográfica y huso (Para conocer mas acerca de EPSG
visitar: http://www.epsg.org/Geodetic.html)
Una petición al servicio, incluirá la delegación y el huso donde se ubica el

término municipal que contiene los datos que se desean, o bién directamente el
código del Término Municipal discriminando el servicio la base de datos donde
se realizará la búsqueda.
En realidad se han creado tantos servicios como gerencias y husos existen

generando para ello tantos ficheros mapfile de configuración del producto como
han sido necesarios.
El usuario final, debe saber que no podrá consultar información de distintas

gerencias o husos bajo una misma petición.

Ö MA P # Objeto MAP
engloba al resto
Ö NAME WebFeatureServer_WebMapServer
Ö STATUS ON
Ö CONFIG MS_ERRORFILE "c:/webapplication/mapserver/temp/mapserv_err.log"
Ö UNITS METERS
Ö FONTSET "../etc/fonts.txt"
Ö PROJECTION
Ö "init=epsg:23030"
Ö END
Ö EXTENT 510000 4200000 685000 4370000
Ö SIZE 500 500
Ö W EB # Objeto WEB
define los parámetros necesarios para acceder desde un interfaz
Ö METADATA # W EB.
Ö "wms_title" "WFS D.G.Catastro en pruebas" ##required
Ö "wms_onlineresource" "http://localhost/WebApplication/ServidorWFS.aspx?delegacion=02&"
Ö "wms_abstract" "Web Map Server mantenido por la Dirección General del Catastro. Este
servicio es de uso restringido, ofrece la Cartografía Catastral actualizada a diario. No está permitido la
descarga masiva de grandes porciones de cartografía. La D.G. del Catastro se reserva el derecho de
restricción del servicio."
Ö "wms_keywordlist" "WMS, CARTOGRAFIA, CATASTRO"
Ö "wms_contactperson" "LINEA DIRECTA DEL CATASTRO, contacte llamando al 902 37 36
35"
Ö "wms_contactorganization" "Oficina Virtual del Catastro, DIRECCIÓN GENERAL DEL
CATASTRO"
Ejemplo de parte de un fichero de configuración mapfile.
Para solucionar este tipo de problemas se ha optado por incluir un script

desarrollado en ASP y que es el encargado de componer la URL final que llega
al CGI MapServer. A partir de una petición que solo incluye la denominación
del script , los parámetros estándares del servicio WFS y la Delegación y Huso
o el Término Municipal, el scripts forma la URL que se lanza y que incluye los
parámetros necesarios para llamar al servicio que se desea.
Por otro lado, para evitar el colapso de los servidores provocado por
peticiones de datos de forma masiva y debido al gran tamaño de las bases de
datos a que se accede, se ha impuesto una restricción en el máximo número de
vectores que devuelve el servicio. Este criterio se ha establecido mediante el
parámetro MAXFEATURE fijándolo en 3000 features, hecho que conlleva que
si se realiza una petición sin parámetros que filtren la consulta a un conjunto de
features menos de 3000, el servicio entregará datos hasta llegar a este máximo.
Pueden emplearse el resto de parámetros que se recogen en la

especificación de la OGC y que permiten, bien filtrar la consulta a partir de los
datos alfanuméricos asociados mediante el parámetro filter o bien establecer un
ámbito geométrico que restringe el número de datos a los incluidos o que toquen
al mismo mediante el parámetro BBox.
Otros parámetros incluidos en los ficheros de configuración mapfile han

servido para publicar los textos que constituyen las etiquetas de los datos
geométricos importantes para interpretar los datos y para configurar servicios
WMS debido a que este producto también puede operar como servidor WMS.

8. Conclusiones:
El servicio WFS que publica información catastral utilizado conjuntamente

con el servicio WMS, permite navegar por toda la información almacenada en la
BDNC localizando ámbitos de interés que podrán obtenerse en formato
vectorial para un posterior proceso o edición lo que permite una consulta on-line
del último estado en que se encuentran los datos y evita replicas de bases de
datos.
La otra posibilidad de consulta de datos mediante filtros permite obtener

datos concretos bajo un conjunto de criterios predefinidos, por ejemplo solicitar
una parcela por su referencia catastral, o un conjunto de parcelas ubicadas en
una calle.
Estos medios de obtención o consulta on–line de datos gráficos en formato

vectorial elimina la necesidad de bases de datos duplicadas evitando así que
estas no se encuentren en el mismo grado de actualización en el momento en
que se opera con las mismas.
Este servicio WFS, junto con el servicio WMS y la Oficina Virtual del
Catastro constituye un conjunto de recursos de acceso a los datos cartográficos
del catastro a partir de diferentes medios tecnológicos y con diferentes formatos
de salida.
9. Referencias:
[1] MapServer http://mapserver.gis.umn.edu/

[2] MapTools DM Solutions Group http://www.maptools.org/
[3] Open Geospatial Consortium OGC http://www.opengeospatial.org/

SESIÓN 8
EXPOSICIÓN DE POSTERS
309
Medidas para impulsar la utilización del Núcleo Español de Metadatos... Sesión 8
“Medidas para impulsar la utilización del

Núcleo Español de Metadatos (NEM)”
Daniela Ballari†, Alejandra Sánchez Maganto‡, Javier Nogueras-Iso‡‡, Antonio
Rodríguez Pascual‡, Miguel Ángel Bernabé†.
† Laboratorio de Tecnologías de la Información Geográfica (LatinGEO)

Escuela Técnica Superior de Ingenieros en Topografía, Geodesia y Cartografía
Autovía de Valencia Km. 7,5, 28031 Madrid
Tlf: 913311968 Fax: 913311968.
e-mail: daniela@topografia.upm.es; ma.bernabe@upm.es
‡ Instituto Geográfico Nacional

C/General Ibáñez Ibero, 3; 28003; Madrid
Tlf: 91 5979664 Fax: 91 5979764
e-mail: asmaganto@fomento.es; afrodriguez@fomento.es
‡‡Departamento de Informática e Ingeniería de Sistemas

C/María de Luna 1, 50018 - Zaragoza
Tlf: 976762358 Fax: 976761914.
e-mail: jnog@unizar.es
Resumen
El presente artículo se centra en la descripción de las distintas iniciativas y acciones
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 (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.

Sesión 8 Medidas para impulsar la utilización del Núcleo Español de Metadatos...
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, siendo este un requisito esencial para localizar, describir y evaluar los
datos disponibles [1].
A pesar del reconocimiento general de la importancia de los metadatos, su
generación dista de ser una tarea sencilla y atractiva. Diferentes obstáculos se
interponen a los creadores de metadatos, algunos de ellos son [2]:
• Los estándares de metadatos son demasiado difíciles y extensos de implementar.
• 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ática 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
metodología de captura de metadatos de Información Geográfica y del Catálogo de
metadatos 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 detalladas
en el presente artículo, 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 Administració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
metadatos 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 ISO19115:2003 [10] que constituye
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
justificación de su inclusión (ver Figura 1):
• Elementos pertenecientes al núcleo de la norma ISO19115 (Core Metadata for
Geographic Datasets) para la descripción de conjuntos de datos geográ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 ISO19115 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 recursos

de información geográfica [4]. Se consideró que el elemento “genealogía”
(lineage) incluido dentro del subconjunto ISO19115 Core Metadata for
Geographic Datasets era insuficiente para detallar con profundidad la calidad
de un recurso y se propuso la inclusión de elementos adicionales del modelo
general de ISO19115, relativos a la calidad.
• Propuestas de inclusión de elementos adicionales del modelo general de
ISO19115 realizadas por expertos Subgrupo de Trabajo del NEM. Entre estas
propuestas se incluyen los siguientes elementos: “palabras clave”, la “forma 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 forma explícita la
recopilación de información geográfica en la forma de mapas) [15], los
borradores de las reglas de implementación para metadatos de la propuesta de
directiva INSPIRE [14], o los perfiles de metadatos propuestos 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 utilizació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áculos a
los que se enfrentan los generadores de metadatos. En base a ellos se plantearon
distintas iniciativas para lograr su superación, tal como se muestra en Tabla 1.

Tabla 1. Tabla de obstáculos e iniciativas lanzadas

Obstáculo Iniciativa
Los estándares de metadatos son Núcleo español de Metadatos.
extensos (Apartado 2)
Los estándares de metadatos son Guía de Usuario del Núcleo Español de
complicados. Metadatos. (Apartado 3.1)
Creación de un grupo de expertos
catalogadores de la Información
Falta de personal capacitado
Geográfica y Plan de Formación para el
personal de la Administración General del
Estado , regional y local (Apartado 3.2)
Elaboración de una metodología de
La producción de metadatos requiere
creación de metadatos basada en
tiempo y otros recursos
Cuestionarios (Apartado 3.3)
Dificultad de utilizar las Desarrollo y mantenimiento de la
herramientas de creación de aplicación Open Source CatMDEdit
metadatos (Apartado 3.4)
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é
informació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
documento “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 posible 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 recomendaciones
para los mismos.
• Ejemplos de aplicación de dichos criterios para diferentes productos asociados 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 a través de 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
personal capacitado que sirva de referencia.
Teniendo esto presente, se creó un grupo especialistas para la generación de
Metadatos de la Información Geográfica. Este grupo es formador y consultor en
materia 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
Administració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
realizació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
informació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 (ver 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 conozcan 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
necesidad 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

documentación de recursos, haciendo especial énfasis en la descripción de los
recursos de información geográfica. Es una herramienta Open Source (código
abierto) que ha sido desarrollada por el consorcio TeIDE1 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
íntegramente en Java (su arquitectura se describe en [8]) y presenta las siguientes
funcionalidades:
1
TeIDE es un consorcio constituido por grupos de investigación de la Universidad de
Zaragoza (Depto. de Informática e Ingeniería de Sistemas), la Universitat Jaume I (Depto.
de Lenguajes y Sistemas Informáticos), y la Universidad Politécnica de Madrid (Depto. de
Ingeniería Topográfica y Cartografía), cuyo objetivo es fomentar el la investigación y el
desarrollo tecnológico de las Infraestructuras de Datos Espaciales.

• Edición de metadatos de acuerdo a la norma internacional "ISO19115.

Geographic Information - Metadata". Se proporcionan cuatro interfaces de
edición especializadas para esta norma:
o Una interfaz detallada de acuerdo al modelo general de ISO19115.
o Una interfaz reducida de acuerdo al "Núcleo Español de Metadatos"
(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 SDIGER –
WFD, desarrollado igualmente bajo el marco del proyecto SDIGER. Es
un perfil de aplicación de ISO19115 para la descripción de los recursos
exigidos por la Directiva Marco del Agua [15].
• Edición de metadatos conformes al perfil de aplicación de metadatos 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 Core (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: ISO19115, Dublin Core y CSDGM (Content Standard for Digital
Geospatial Metadata).
• Diferentes estilos de presentación de registros de metadatos en HTML y Excel.
• 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 transferencia 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 6 idiomas:
castellano, inglés, francés, portugués, polaco y checo.
Cabe destacar que tanto esta herramienta, como otras con similares
funcionalidades, 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 ISO19115 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 de investigación 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 metadatos es una
tarea tediosa y pesada. Por ello, resulta muy importante investigar sobre la
usabilidad 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 usabilidad [9] y normas de accesibilidad se intentará minimizar el tiempo
requerido por un usuario para la creación de un registro de metadatos y mejorar
la usabilidad de la herramienta.
• Impulsar la implementación de la especificación técnica ISO19139 que describe
la serialización sobre XML del modelo de metadatos propuesto por ISO19115.
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. Distintas
normas e iniciativas han surgido recientemente para la descripción de servicios.
Se pretende estudiar y analizar cuales son las más idóneas e integrarlas dentro de
la herramienta CatMDEdit.
• Facilitar la descripción de series cartográficas y los componentes de esas series.
• Impulsar avances tecnológicos en aspectos de calidad, multilinguismo y
clasificación de información en el ámbito de los metadatos de datos
geoespaciales. Se avanzará en aspectos como la estimación de la calidad de
metadatos, la recuperación multilingüe y la elaboración y puesta en marcha de
Sistemas de Organización de Conocimiento (tesauros, taxonomías y ontologías)
para la clasificación de la información.
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 nivel 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 como se han 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
soporte en materia de metadatos y que se encuentra a disposición de todos los
interesados. Una de las labores de este grupo de Expertos catalogadores ha sido la
elaboració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 como 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 cuya

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
trabajando 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: Metadatos –
Describiendo Datos Geoespaciales “ Versión 2.0. Enero 2004
[2] Lynda 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ñola. 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.Borrador.
http://www.idee.es/resources/recomendacionesCSG/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] Zarazaga-Soria FJ, Lacasta J, Nogueras-Iso J, Torres MP, Muro-Medrano PR (2003). 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. Juni 2003, pp 17-30. IFGIprints 18, Münster, Germany.
[9] M. Manrique, M.A. Bernabé, D.Ballari. (2006) Guía de procedimiento de evaluación
heurística basado en perspectivas concretas. Informe de Usabilidad para la Herramienta
CatMDEdit. (Sin Publicar)
[10] International Organization for Standardization (ISO). Geographic information -
Metadata. ISO 19115:2003.
[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] International Organization for Standardization (ISO). Information and documentation -
The Dublin Core metadata element set. ISO 15836:2003.
[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, Ver documento. Proceedings of the 11th EC GI &
GIS Workshop, ESDI Setting the Framework. Alghero, Sardinia (Italy), 29 June -1 July
2005.
[14] Commission of the European Communities (CEC), 2004. 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] Vogt, J. (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. Aceptado para su publicación en Research and Theory in Advancing
Spatial Data Infrastructure Concepts, ESRI Press (editor: H. Onsrud), 2006.

Situación actual de los metadatos en el ámbito internacional. Sesión 8
Situación actual de los metadatos en el ámbito

internacional
Alejandra Sánchez Maganto, Antonio F. Rodríguez Pascual, Paloma Abad Power, Luís Manuel
Blázquez Vilches, José Ángel Alonso Jiménez
Subdirección General de Aplicaciones Geográficas.

Tlf: 91 597 9664 Fax: 91 597 9646
E-mail: asmaganto@fomento.es, afrodriguez@fomento.es, pabad@fomento.es,
lmvilches@fomento.es, jaajimenez@fomento.es
Resumen
En un principio, los metadatos han sido considerados como atributos descriptivos de las
principales características de los recursos relacionados con información de tipo geográfica
(mapas, ortofotos, modelos digitales del terreno,..), pero según vamos profundizando en el
conocimiento de esta materia, vamos descubriendo cómo los metadatos van aportando
numerosas utilidades y aplicaciones que a los usuarios les sería muy interesante conocer para
poder beneficiarse de las mismas.
Moverse dentro del mundo de los metadatos no es una labor sencilla, pero es interesante mostrar
como se desenvuelven en la materia las organizaciones de diferentes países para poder tomar
ideas, recoger experiencias y sacar conclusiones, intentando realizar un completo inventario,
que resulte interesante e instructivo para los que se mueven en el mundo de los metadatos y que
nos sirva a todos aquellos que estamos relacionados con las infraestructuras de datos espaciales.
En esta presentación se mostrarán qué normas, perfiles y recomendaciones en materia de

metadatos se están siguiendo en la actualidad en diferentes países de todo el mundo,
pretendiendo abarcar un amplio ámbito internacional y especificando cuáles de estas normas nos
afectan directamente. Una vez introducidas las normas que se siguen, presentaremos las
herramientas que existen para su creación y que se están utilizando a día de hoy, describiendo
sus principales características.
Palabras Clave
Infraestructura de Datos Espaciales, metadatos, ISO 19115, Núcleo Español de

Metadatos, Dublin Core, perfil, catálogo, software libre.
1. Introducción
Los datos asociados a la información geográfica modelan el mundo real para poder
realizar una posterior visualización mediante medios muy diversos. Esta visión que se
da del mundo real, tiene unas características propias que un usuario de este tipo de
información debe conocer y que van a quedar reflejadas a través de los metadatos.
Los metadatos, datos sobre los datos, van a permitir a un productor de datos describir
las características del conjunto de datos que produce, de modo que cualquier usuario
pueda conocer: en qué sistema de referencia se encuentran, que organismo los ha
producido, que fecha de creación tienen, las medidas de calidad que los evalúan, etc.

Sesión 8 Situación actual de los metadatos en el ámbito internacional.
Dentro del mundo de la Información Geográfica, que gira a unas velocidades cada vez
más desconcertantes, se han ido definiendo recomendaciones para la creación de los
metadatos, cuya finalidad principal es proporcionar una estructura “jerárquica y
concreta” que permita describir exhaustivamente cada uno de los datos digitales a los
que hacen referencia. Estas recomendaciones, creadas y aprobadas por organismos de
normalización a partir de opiniones de expertos en esta materia:
• Suministran a los productores de datos criterios para caracterizar sus datos

geográficos con propiedad.
• Facilitan la gestión de los metadatos y su organización.
• Permiten a los usuarios utilizar los datos de un modo más eficiente, determinando sí
serán de utilidad para ellos.
• Facilitan el acceso a los datos, su adquisición y una mejor utilización de los datos
logrando una interoperabilidad de la información cuando esta procede de fuentes
diversas.
A continuación se procede a enumerar normas de metadatos que existen en la

actualidad, así como extensiones y perfiles de las mismas, y a describir sus principales
características.
2. Content Standard for Digital Geospatial Metadata
En 1994, el Comité de Datos Geográficos Federal (FGDC) de los Estados Unidos

aprobó de acuerdo a la orden ejecutiva 12096 "Coordinating Geographic Data
Acquisition and Access: The National Spatial Data Infrastructure," una norma de
metadatos para la Información Geográfica:” Content Standard for Digital Geospatial
Metadata (CSDGM)”, según la cuál, todas las agencias federales que creasen
metadatos debían hacerlo cumpliendo dicha norma. En 1998 se revisó dando lugar a una
versión 2, que es la que está vigente en la actualidad.
Esta norma está formada por 220 elementos, que se organizan en series que, a su vez,
están agrupadas en diferentes secciones que contienen información sobre el tipo de
valores que pueden contener cada elemento, así como su clasificación en obligatorios,
opcionales y condicionales.
Cada sección se divide en tres partes:
• Definición de la sección: que incluye el nombre y la definición de la misma.
• Reglas de producción: que describen los diferentes niveles jerárquicos entre los
elementos y sus relaciones.
• Lista de los componentes de los elementos: que proporciona el nombre y la
definición de cada elemento en la sección e información sobre los valores que
pueden tomar los datos.
Figura 1: Secciones de la Norma CSDGM

Una de las principales características que se ha implementado en la versión actual de la

norma es la posibilidad de implementar perfiles. Cómo ejemplos tenemos:
• Para información raster: “Content Standard for Digital Geospatial Metadata:
Extensions for Remote Sensing Metadata”, que incluye elementos para describir
sensores, plataformas, etc.
• Para información de costas: “Metadata Profile for Shoreline Data”, que incluye
términos para clasificar las líneas de costa desde distintos puntos de vista.
• Para datos de Biología: “Biological Data Profile of the Content Standard for Digital
Geospatial Metadata”.
El FGDC está desarrollando, en la actualidad, un perfil que cumpla con la norma

Internacional ISO 19115, haciendo una correspondencia o cotejo (mapping) de los
elementos del Core de ISO con los elementos del FGDC.
3. Dublín Core Metadata Initiative
La iniciativa de Metadatos Dublin Core (DCMI) es una organización dedicada a

la promoción y difusión de normas sobre interoperabilidad de metadatos y al desarrollo
de vocabularios especializados en metadatos para la descripción de recursos de manera
que el usuario pueda obtener búsquedas y recuperaciones de un modo rápido y eficiente.
Se creó en Dublín en 1995 y fue consensuada en un principio electrónicamente en
Internet, con la finalidad de establecer normativas rápidas y fácilmente modificables, así
definieron el perfil de metadatos Dublín Core.
Los elementos que constituyen este perfil son una norma para la descripción de
un recurso, entendiéndose por recurso: un fichero, un servicio, una publicación, un
programa, una página web, un autor, una fuente, una organización,...
Este esquema de metadatos, es muy utilizado en el ámbito mundial, por:
• Su simplicidad, formada sólo 15 elementos, muy básicos y generales, para describir

cualquier tipo de recurso.
• Su independencia semántica: permite su estructuración de un modo muy sencillo en
formato XML.
• Su generalidad: es aplicable en cualquier disciplina y ámbito semántico
(biblioteconomía, ciencias, geomática, negocios,…).
• Su nivel de normalización: esta iniciativa ha adquirido ya el rango de norma
internacional, correspondiéndose con la norma ISO 15836:2003 “Information and
Documentation- The Dublín Core Metadata Element Set”.
• Se está convirtiendo en una infraestructura de desarrollo muy importante en la Web
Semántica y una de las claves para la interoperabilidad.
Se han desarrollado perfiles, para determinadas aplicaciones, como por ejemplo: el

perfil de aplicación para bibliotecas (http://es.dublincore.org/documents/library-
application-profile/)
4. ISO 19115: 2003 – Geographic Information Metadata
La Organización de Estandarización Internacional (ISO), organización no

gubernamental compuesta por representantes de Organismos de Normalización

nacionales, es la encargada de producir Normas Internacionales que son de obligado

cumplimiento. La familia ISO 19100 es una de las familias de normas creadas en esta
organización a través del Comité Técnico 211, denominado “Geomática/Información
Geográfica”, y dentro de esta familia se encuentra la norma ISO 19115
Dicha norma ha sido elaborada con la colaboración de 33 países miembros de

ISO/TC211 y de expertos de 16 países dentro del Grupo de Trabajo correspondiente. En
1996 se disponía ya de un primer borrador, en Febrero del 2001 la secretaría del Comité
Técnico 211 anunció que la Norma ISO 19115, Geographic Information-Metadata
había sido aprobada para ser publicada como Borrador de Norma Internacional (DIS).
En el año 2003 se aprobó el texto definitivo como Norma Internacional de metadatos y
fue adoptada como Norma Europea por CEN/TC 287 ese mismo año en la reunión
plenaria celebrada en Delft. Además el Comité 148 de “Información Geográfica
Digital” de AENOR (Asociación Española de Normalización) ha decidido adoptarla
como Norma Española, realizándose su traducción al castellano “UNE-EN ISO
19115:2003”.
Esta norma está formada por 409 elementos y define 27 listas controladas,
mediante las que se definen los valores permitidos para algunos campos y proporciona
un modelo y un conjunto de terminología, definiciones y procedimientos para la
ampliación de metadatos.
La norma ISO 19115 proporciona información sobre la identificación, la calidad,

la extensión geográfica y temporal, el sistema de referencia y la distribución de los
datos espaciales y se aplica a la catalogación de conjuntos de datos, de series de
conjuntos de datos, de subconjuntos de datos y a las entidades geográficas individuales
así como a sus atributos.
Como complemento a esta norma, se está elaborando una segunda parte ISO
19115-2 “Geographic Information- Metadata for imaggery and gridded data”, una
extensión para datos ráster y malla, que en la actualidad se encuentra en estado de
“Comitte Draft (CD)”. Por otro lado existe un “Technical Especification” disponible de
la Especificación Técnica 19139 “Geographic Information –Metadata- XML schema
implementation”, que proporciona un mecanismo para volcar el contenido de los
metadatos definidos de acuerdo a ISO19115 en XML.
4.b Perfiles de la norma ISO 19115: 2003
Debido a que la aplicación de la norma internacional de metadatos ISO19115 es

muy compleja y no esta exenta de problemas, en muchos sectores, regiones y países se
tiende a la definición de perfiles y conjuntos mínimos de campos exigibles o
recomendables. La propia ISO 19115 aplica esta aproximación al problema definiendo
un Núcleo o Core con sólo 22 elementos de los 409 que la constituyen. A continuación
se describen, como ejemplo, algunos perfiles de esta norma que se están implementando
en diferentes regiones del mundo.
4.b.1. Núcleo Español de Metadatos (NEM)

NEM es el acrónimo de Núcleo Español de Metadatos, un conjunto mínimo de

elementos de metadatos recomendados en España para su utilización a la hora de
describir mediante el uso de metadatos los recursos relacionados con la información
geográfica. Está formado por la unión de elementos de ISO 19115 y de Dublín Core.
Este perfil va a permitir realizar (búsquedas, comparaciones, etc.) a partir de metadatos
que procedan de diferentes fuentes, sobre distintos conjuntos de datos, de una manera
rápida, práctica, fácil y fiable.
En España, existe una Infraestructura de Datos Espaciales (IDEE), cuyo Geoportal

se abrió en 2004, coordinada y desarrollada desde la Comisión de Geomática del
Consejo Superior Geográfico, dicho Consejo definió en Noviembre de 2002 un Grupo
de Trabajo para la IDEE en el que los organismos de los diferentes niveles de la
administración, las universidades y las empresas privadazas intercambian experiencias y
llegan a los consensos necesarios para la implementación de una IDE en España, abierta
y eficaz, de acuerdo con las directrices marcadas por INSPIRE (The INfrastructure for
SPatial InfoRmation in Europe), siguiendo las especificaciones de interoperabilidad de
Open Geospatial Consortium. En Noviembre de 2004 se creó el Subgrupo de Trabajo
del Núcleo Español de Metadatos (SGT NEM), cuya función principal fue definir y
mantener el Núcleo Español de Metadatos. Este perfil está formado por:
• 22 elementos de la Norma Internacional ISO 19115, pertenecientes a su Core.
• 3 elementos pertenecientes a Dublín Core.
• 3 elementos adicionales pertenecientes a ISO 19115, propuestos a partir de
sugerencias recibidas de los miembros del Grupo de Trabajo de la IDEE.
• 2 elementos pertenecientes a ISO 19115, propuestos por su utilización en la
Directiva Marco del Agua (Water Framework Directive)
• Elementos pertenecientes a ISO 19115 y relativos a la calidad.
Figura 2: Conjuntos de elementos que forman NEM
Este perfil es, en la actualidad, un perfil consolidado y no restrictivo que representa un

conjunto mínimo de metadatos a implementar en cualquier catálogo que se cree en
España y que deja libertad para poder añadir más elementos en función de las
características de los datos en cada organización, institución, etc. De este modo han ido
surgiendo a partir de NEM otros perfiles en diferentes comunidades autónomas de
España, así:
• Comunidad Foral de Navarra

En la Comunidad Foral de Navarra se ha creado la Infraestructura de Datos
Espaciales de Navarra (IDENA). Para su catálogo de metadatos se ha definido el “perfil
IDENA de metadatos”, que adopta el perfil NEM pero lo modifica completándolo según
sus necesidades. De esta manera se ha definido el Núcleo IDENA de Metadatos, como

la suma del: Núcleo Español de Metadatos más otros elementos adicionales,

pertenecientes a ISO 19115, que son: “título alternativo”, “identificador del padre”,
“frecuencia de mantenimiento”, “estado”,”metadatos sobre el distribuidor”,
“información suplementaria”.
• La Rioja
En la Rioja se ha creado la Infraestructura de Datos Espaciales de la Rioja
(IDERioja). Los metadatos de su catálogo siguen el perfil de metadatos de la Rioja,
perfil “C.A.R”, que tiene como base el NEM.
• Comunidad Valenciana
En la Comunidad Valenciana, se ha definido el perfil de metadatos IDECV, que en
su primera versión recoge además de los elementos que componen NEM los campos de
“palabras clave”, “nivel de topología” y “especificación de formatos de distribución”
todos ellos pertenecientes a ISO 19115.
Andalucía y Extremadura son otros claros ejemplos de comunidades que están

considerando al perfil NEM como base en el perfil de sus metadatos.
4.b.2. Perfil IDEC

Subconjunto del estándar ISO 19115 elaborado por la Infraestructura de Datos
de Cataluña que ha sido adaptado a las características y particularidades de Cataluña.
El Perfil IDEC está formado por el Core de ISO y para su concreción se han diseñado
dos tesauros (uno de objetos y otro de topónimos) que ayudan a describir los metadatos
de una forma más rápida y homogénea, facilitando su posterior búsqueda.
4.b.3. ANZLIC Metadata
En febrero de 2001en ausencia de una norma de metadatos que cumplir,

ANZLIC (Australia and New Zealand the Spatial Council) definió un conjunto mínimo
de metadatos para ser incluidos en la infraestructura de datos espaciales de Australia
“ASDD” denominado “ANZLIC Metadata Guidelines”. Posteriormente se aprobó la
Norma Internacional ISO 19115 y se adoptó por Australia y Nueva Zelanda como
Norma (AS/NZS ISO 19115:2005)
Actualmente en el proyecto de metadatos ANZLIC (Julio 2006) se está desarrollando un

nuevo perfil para Australia y Nueva Zelanda, que cumple con la norma Internacional
ISO 19115. Dicho perfil ANZLIC adoptará los elementos del núcleo de AS/NZS ISO
19115 con 2 modificaciones: el elemento “file identifier” será obligatorio y el elemento
“parent identifier” se incluirá en el núcleo del perfil.El perfil se documentará de acuerdo
a AS/NSZ ISO 19106 –Profiles y dicho perfil se hará circular entre el comité técnico
para ser aprobado en Noviembre de 2006 por el Consejo ANZLIC.
5. Ejemplos de implementación de Normas de Metadatos
Se muestra mediante una tabla algunos ejemplos de portales de información geográfica

(a nivel nacional y superior) en los que se implementación las normas de metadatos
descritas:

País Implementación
Canadian Geospatial Data Infrastructure

Canada
FGDC
CSDGM EEUU
y perfiles Clearinghouse de Nicaragua
Nicaragua
Ordenance Survey
Reino Unido
Clearinghouse Nacional de datos Geográficos
Uruguay
Departamento de Medio Ambiente
Australia
Dublin Universidad de Arizona
EEUU
Core
Librería Oncológica
Italia
Dinamarca Geodata-Info
España Infraestructura de Datos Espaciales
Francia Conseil National de l'Information Géographique
Finlandia National Geographic Information
Holanda Geodan
Región del Digital Map of The Baltic Sea Region

Báltico
ISO
Reino Unido GI Gateway
19115 y
perfiles República Checa MIDAS (Sistema de Información)
Portugal Sistema Nacional de Informacao Geográfica
Australia ANZLIC - The Spatial Information Council

Nueva Zelanda
Indonesia National Coordination Agency for Surveys and Mapping
Japón Geographical Survey Institute
Antártida Antarctic Spatial Data Infrastructure
6. Herramientas para la creación de metadatos
Para la creación de los metadatos, es necesario utilizar herramientas definidas para esta
función que:
• se pueden conseguir libremente a través de la web y se permite descargar sólo la
herramienta o la herramienta más su código para poder desarrollarla en función de
las necesidades, son las conocidas como “herramientas de Software libre” y

• otras, que para conseguirlas es necesario comprarlas a empresas propietarias.
A continuación se hace un pequeño inventario de herramientas, describiendo algunas de

sus características:
6.1. Herramienta y Software libre
a) CatMDEdit
Herramienta para la creación de metadatos de recursos asociados a la

información geográfica, desarrollada por el consorcio TEIDE: Universidad de Zaragoza
(Departamento de la Informática y de la Ingeniería de Sistemas), más la Universidad
Jaume I (Departamento de los Sistemas de Información), y la Universidad Politécnica
de Madrid (Departamento de Topografía y de Cartografía) y apoyada parcialmente con
los proyectos: IDEE y SDIGER (Spatial Data Infrastructure for Adour-Garonne and
Ebro River Basins).En la actualidad está herramienta se encuentra en su versión 3.7.1.
Algunas de sus principales características son:
• Multi-plataforma (Windows, Unix).

• Multilingüe: versión española, inglesa, francesa, polaca, portuguesa y checa.
• Edición de los metadatos según ISO 19115. Presenta cuatro interfaces para la
edición de metadatos: norma ISO 19115 detallada, Núcleo Español de
Metadatos, Perfil SDIGER, Perfil Directiva Marco del agua.
• Diversos estilos para la presentación de los archivos de metadatos
• Generación automática de los metadatos: permite la generación automática de
los meta datos para los formatos de un ciertos datos como Shapefile, DGN,
ECW, FICC, GeoTiff, GIF/GFW, JPG/JGW, PNG/PGW.
Esta herramienta se utiliza en la creación de metadatos, por ejemplo, de la

Infraestructura de datos Espaciales de España (IDEE), la Infraestructura de Datos
espaciales de Navarra (IDENA),etc.
b) GeoNetwork
Catálogo de metadatos desarrollado por la FAO – UN (Food and Agriculture

Organization of the United Nations ), la WFP-UN (World Food Programme of the
United Nations) y la UNEP (United Nations Environment Programme), que se
distribuye bajo licencia GPL (General Public License) y que integra las siguientes
aplicaciones:
• Editor de metadatos que soporta los estándares ISO 19115, FGDC y Dublín Core.
• Servidor de catálogo para la publicación de metadatos.
• Catálogo de metadatos, que permite la búsqueda de información geográfica tanto en
un servidor de catálogo local como uno remoto.
• Detalles técnicos: multilingüe, desarrollado en Java, XML/XSL.
El principal objetivo de GeoNetwork es mejorar el acceso a una amplia gama de

información de tipo geográfica, junto con los metadatos asociados, a diferentes escalas,

proveniente de una gran diversidad de fuentes, organizada y documentada de una

manera consistente y estandarizada.
Esta herramienta se implementa y utiliza en muchos países del mundo, por ejemplo, en
Mozambique (http://www.setsan.org.mz/geonetwork/srv/en/main.search) y en
organizaciones como, por ejemplo, en la Organización Mundial de la Salud
(http://www.who.int/geonetwork/srv/en/main.search), el Instituto Internacional de la
Gestión del agua (http://geonetwork.iwmi.org:8080/geonetwork/srv/en/main.home)
c) M3CAT
Herramienta de catalogación, multiestándar y multilingüe, desarrollada por “Intelec

Geomatics”. El acceso a la aplicación se realiza a través de un navegador, que nos
presenta una interface muy fácil de manejar.
Figura 3: Pantalla de la herramienta M3CAT.
Sus principales características son:

• Soporta los estándares ISO 19115, Dublín Core y FGDC.
• Se pueden especificar extensiones de los datos a través de WMS.
• Importación de perfiles de metadatos, mediante archivos XSL.
• Herramientas para la validación de metadatos
Cómo ejemplos de uso de esta herramienta se encuentra el catálogo de la infraestructura

de datos de Canadá y los metadatos del Sistema de Información sobre la Biodiversidad
de Colombia.
6.2. Herramientas libres:
a) MetaD
Programa de edición y exportación de metadatos desarrollada para la creación de

metadatos de la Infraestructura de Datos Espaciales de Cataluña, que se encuentra en la
versión 2.1.1. Algunas de sus características son:
• Creación de metadatos según el perfil IDEC.

• Implementa el estándar ISO 19139
• Multilingüe: catalán, castellano, inglés.
b) ISO Metadata Editor “IME”
Aplicación desarrollada por el área de teledetección del INTA (Instituto

Nacional de Técnicas Aerospacial) para facilitar el trabajo y la compresión de las

normas ISO19115 e ISO19139, y validar la interoperabilidad de los ficheros XML de

metadatos. Algunas de sus características son:
• Creación y edición de perfiles.
• Localización de metadatos.
• Creación y lectura de ficheros XML y creación de archivos en HTML.
• Perfil para trabajar contexto multilingüe según ISO 19139.
c) Metadata Entry Tool “MET”
ANZLIC ha creado una herramienta para la creación de metadatos “MET” (Metadata

Entry Tool) que está desarrollada en Microsoft Access 97 y permite a los usuarios crear
metadatos según el perfil ANZLIC, además MET puede utilizarse dentro de las
organizaciones para almacenar y gestionar los registros de metadatos.
Cómo, en la actualidad, se está modificando el perfil de metadatos, ANZLIC está
desarrollando una nueva herramienta de metadatos, el nuevo MET reemplazará a la
versión Microsoft Access y:
• Estará libremente disponible “Online”.
• Cumplirá con el nuevo perfil que está ahora bajo desarrollo.
• Producirá registros XML que facilitará el intercambio de metadatos.
d) MIG EDITOR
Herramienta creada por el Sistema Nacional de Información Geográfica de Portugal,

que permite crear metadatos según ISO 19115 y generar su salida en esquema XML. El
objetivo principal de este editor es producir los metadatos del Registro Nacional de
Cartografía y se encuentra en idioma Portugués.
6.3. Herramientas Propietarias
a) Geomedia Catalogue
El catálogo Geomedia es una herramienta de Intergraph para la creación de

metadatos cuyas principales características son:
• Permite la creación y gestión de metadatos de acuerdo a la norma de FGDC e ISO
19115 y exporta metadatos según los esquemas definidos en ISO 19139.
• Permite la creación automática de metadatos asociados a ficheros de SIG.
• Permite avanzadas búsquedas: espaciales, según temáticas, etc.
• Importa/ Exporta metadatos y publica en formato HTML.
• Para su utilización es necesario tener instalado Geomedia o Geomedia profesional.
b) ESRI “Arc-Catalog”
Herramienta para la creación y mantenimiento de metadatos, que sigue los

estándares de FGDC e ISO, si bien estos estándares pueden ser ampliados mediante
personalizaciones realizadas directamente por el usuario.
ESRI ha desarrollado un módulo para esta herramienta que permite crear metadatos
conforme a NEM (Núcleo español de metadatos) que incorpora:
• Ficheros de configuración en XML siguiendo las especificaciones del NEM para los
campos obligatorios, secciones, dominios y valores por defecto.
• Plantilla para la visualización de metadatos desde ArcCatalog.
10

• Herramientas de exportación e importación de los metadatos.
c) MDWeb (Francia)
Herramienta para la gestión y generación de Metadatos creada en Francia, que cumple

la Norma ISO 19115. Es un servidor de aplicaciones, que funciona bajo Windows y
Unix, que necesita una base de datos PostgreSQL y que está diseñada para la
manipulación de metadatos vía web.
Existe un catálogo desarrollado a partir de esta herramienta “MedWeb Technology Test
Area” que nos permite hacer consultas sobre información sanitaria
(http://medweb5.bham.ac.uk/databases/interop/combinedsearch) y un prototipo que está
en pruebas que nos permite consultar información de diferentes temáticas
(http://www.mdweb-project.org/demo/)
6.4. Herramientas para Dublín Core
Se han implementado herramientas para crear metadatos según el perfil Dublín Core,
como por ejemplo: MKDoc, DC-assist, Dublín Core Viewer Extensión, etc. Todas estás
herramientas vienen descritas en la página oficial de la iniciativa.
7. Conclusiones
Las Infraestructuras de Datos Espaciales, van afianzándose cada vez más como
tecnologías clave dentro del ámbito de la información geográfica. Aunque todavía los
servicios de visualización de mapas (Web Map Service) son los más implantados dentro
de una IDE, se empieza a observar como los metadatos, tanto asociados a datos como a
servicios, van mereciendo más atención y dedicación de recursos dentro de las
organizaciones e instituciones responsables de la producción de los datos. Los
metadatos y su principal aplicación, el servicio de catálogo (Catalogue Service Web),
comienzan progresivamente a establecer su propia línea de desarrollo dentro de las
IDEs.
En materia de metadatos, cada país, cada región y cada sector evoluciona a muy
diferente velocidad en función de sus recursos, medios y necesidades, pero es muy
interesante parar y detenerse para mostrar cuál es “el estado del arte” de los metadatos,
para aprender de otras experiencias, poder estudiar los desarrollos más avanzados y
tener una idea clara de su grado de implantación y evolución con el fin de iluminarnos
con alguno de los rayos de luz que alumbran el ámbito internacional.
La filosofía de las IDEs se basa principalmente en compartir para crecer y evolucionar,

los metadatos son una parte fundamental dentro de las IDEs, por ello, con esta
presentación, se ha querido compartir conocimientos y experiencias adquiridos en la
actualidad esperando poder evolucionar todos conjuntamente.
8. Referencias
• FGDC: http://www.fgdc.gov/metadata
• TOOL: http://www.fgdc.gov/metadata/online-metadata-resources
• ISO 19115-Geographic Information Metadata: http://www.iso.org/
11

• ISO 19115-2 Geographic information – Metadata – Part 2:. Extensions for imagery and
gridded data: http://www.iso.org/
• Dublín Core Initiative: http://dublincore.org/
• NEM (Núcleo Español de Metadatos):
www.idee.es/resources/recomendacionesCSG/NEM.pdf
• Perfil IDENA: www.tracasa.es/html/es/IDE.pdf
• Pefil CAR: http://www.iderioja.org/
• Perfil IDECV: http://66.102.9.104/search?q=cache:JjjEMGd-
RBEJ:www.gvsig.gva.es/fileadmin/conselleria/images/Documentacion/articulos/JIDEE_Zar
agoza_2004_IDE_y_Sw_libre.pdf+PERFIL+DE+METADATOS+DE+LA+Comunidad+va
lenciana&hl=es&gl=es&ct=clnk&cd=1
• ANZLIC Metadata: http://www.anzlic.org.au/infrastructure_metadata.html
• http://ncl.sbs.ohio-state.edu/ica/3_spatial.html
• Open Source: http:// www.opensource.org/
• CatMDEdit: http://sourceforge.net/projects/catmdedit
• Geonetwork: http://sourceforge.net/project/showfiles.php?group_id=72096
• M3CAT: http://www.intelec.ca
• MetaD:http://www.geoportal-idec.net/geoportal/IDECServlet?pag=metad&home=s
• IME: http://www.crepad.rcanaria.es/metadata/index.htm
• MET: http://www.anzlic.org.au/infrastructure_MET.html
• MIG Editor: http://snig.igeo.pt/menu/Frameset_metadados_MIG.htm
• Geomedia Catalogue:
http://support.intergraph.com/Geospatial/Downloads/ExpansionPacks.asp?ID=102&SORT=
Title
• Esri Arc-Catalog: http://www.esri-es.com/index.asp?pagina=440
• Proyecto MDweb: http://www.mdweb-project.org/index.php?lang=en
• Herramienta MDWeb: http://www.ier.ml/mdweb/docMDweb_fr.html
• Catalogue “DEMO” MDWeb: http://www.mdweb-project.org/demo/
• Herramientas Dublín Core: http://dublincore.org/tools/
• http://www.gsdi.org/
12

Pasarela XML para la construcción de consultas a WFS con esquemas... Sesión 8
Pasarela XML para la construcción de consultas a WFS con esquemas

heterogéneos a partir de un GUI común: aplicación a la generación de
informes sobre la Directiva Marco del Agua
Enrique Andreu, Rubén Béjar, Sergio Martínez
Department of Computer Science and Systems Engineering, University of Zaragoza
E-50018 Zaragoza, Spain
{enriquea, rbejar, sergiom} @unizar.es
INTRODUCCIÓN:
Durante el desarrollo del prototipo de la aplicación para la obtención de informes de
la Directiva Marco del Agua (DMA), enmarcado dentro del proyecto europeo SDIGER,
surgió el problema de poder visualizar y obtener los datos geográficos relacionados con
la Directiva Marco del Agua, estos datos deben ser mantenidos y gestionados por cada
país miembro de la Unión Europea (UE).
La solución más natural para servir la información geográfica siguiendo estándares

y promoviendo la interoperabilidad pasaba por la utilización de Web Feature Server’s
(WFS) que cumplieran las especificación del Open Geospatial Consortium (OGC).
La exigencia de la obtención de los datos se podía resolver fácilmente interrogando

a los propios WFS’s que los contenían, por su parte para la visualización de la
información geográfica se eligió la instalación de un Web Map Server (WMS) cuyas
peticiones estarían basadas en Styled Layer Descritor (SLD) para salvaguardar la
interoperabilidad entre los distintos elementos de la arquitectura. Estas peticiones
definirían como fuente de datos los WFS’s de los países miembros y tendría la
capacidad de restringir tanto los datos a visualizar como el estilo (colores, grosores,
tramas…) de estos.
A pesar de plantear una arquitectura basada en la interoperabilidad, el hecho de no

haber establecido un modelo de datos común en los distintos WFS’s hacía que cada
estado miembro poseyera su propio modelo de datos en su WFS. La falta de un modelo
común no sólo se hizo notable en el nombre de los distintos feature types y los
property’s asociados a estos, si no también en la forma de estructurar los datos dentro de
los WFS’s. La solución que se debía plantear no sólo debía tener en cuenta el problema
de traducción de los nombres de feature types y property’s sino que debía gestionar las
diferencias estructurales entre los distintos WFS’s
Se busca obtener un subconjunto de los datos geográfico servidos por los distintos
WFS’s que cumplan una serie de restricciones que vendrán definidas por el interfaz
gráfico. A partir de las restricciones definidas en el GUI se deben generar las consultas
necesarias para poder visualizar los datos (el estilo de visualización vendrá definido
también por el GUI), u obtenerlos de forma tabular.
SOLUCIÓN:
La solución planteada parte del interfaz gráfico (GUI) como elemento común y
generador de las peticiones a los distintos WFS’s, busca apoyarse en el interfaz gráfico
para establecer la forma de construir las consultas realizando un mapeo entre los
elementos del GUI y las acciones que debe realizar para formar las consultas,
definiendo los feature types y los property names a los que hay que interrogar, para ello
se crea una pasarela XML que lo defina.

Sesión 8 Pasarela XML para la construcción de consultas a WFS con esquemas...
Entendemos por elemento del GUI a todos aquellos componentes del interfaz con el
que usuario puede interactuar y sirven como entrada de información (checkBoxes,
radioButtons, comboBox, cajas textuales...), cuando se habla del estado de estos
elementos del GUI se hace referencia a las distintas disposiciones en las que un
elemento puede permanecer después de que el usuario haya podido interactuar, en el
caso de los checkBoxes y radioButons pueden estar seleccionados o no, en el caso del
comboBox la entrada que ha seleccionado, el texto introducido en el caso de las cajas
textuales…
La pasarela es un fichero XML que se compone de cuatro partes:

• Identificación del WFS, posee un nombre que lo identifica dentro del fichero
XML, la url del servidor WFS y el bounding box, con su correspondiente
CRS, de los datos geográficos que sirve.
• Mapeo del GUI con los feature types, en esta sección se indica a que features
types se debe interrogar en función del estado de los elementos del GUI. Así
mismo se describe el nombre del property name que contiene la geometría y
el tipo de geometrías que contiene (líneas, puntos, polígonos…).
• Restricciones a aplicar a los property name’s de los feature types, esta parte
codifica una restricción sobre los property name’s indicando a cual o cuales
feature types aplicar. Estas restricciones no se codifican en ningún lenguaje
específico, sólo cuando se construye la consulta se codifica en el lenguaje de
interrogación de los WFS’s (filter encoding).
• Presentación, se define el estilo de visualización en función del estado de los
elementos del GUI, que symbolizer y sobre que feature type aplicar, esta
sección sólo se utiliza en caso de necesitar realizar peticiones a un WMS
donde sea necesario especificar un estilo a través de petición de SLD.
CONCLUSIONES
En este abstract se ha descrito una solución adoptada para el desarrollo de una
aplicación concreta y unas determinadas tecnologías, sin embargo detrás de esto
subyace un concepto de interoperabilidad basado en el usuario y en el interfaz gráfico
con el que este va a interactuar.
Se presenta el interfaz gráfico de interrogación como el eje principal a través del
cual se van generando los mapeos necesarios para construir las consultas, frente a otras
soluciones donde se crea un modelo común sobre el que se intentan mapear los distintos
modelos, cosa que no puede resultar fácil si todos los modelos no fueron diseñados con
el mismo fin, esta solución sigue el camino de definir la forma de construcción de las
peticiones basándose en un elemento de interrogación común como es el GUI.

El desarrollo de los Sistemas de Observación de la Tierra (SOT) en el... Sesión 8
El desarrollo de los Sistemas de Observación de la Tierra (SOT) en el

marco de las Infraestructuras de Datos Espaciales (IDEs)
José Antonio Álvarez-Robles, Orietha Castillo, Miguel Ángel Latre, Ruben Béjar, Pedro
Rafael Muro-Medrano
Zaragoza, España
[jantonio, oriecas, latre, rbejar, prmuro]@unizar.es
Por Observación de la Tierra entendemos la colección, procesado, modelado y

diseminación de datos del Sistema Tierra. Estos datos se obtienen por medio de
sensores in situ, junto al objeto o fenómeno de interés, o usando técnicas de
teledetección, a través de sensores en satélites o aerotransportados. Su principal
característica es su gran cobertura espacial y resolución temporal. Los datos e imágenes
de observación terrestre tienen un gran potencial en importantes áreas, como el campo
medioambiental, ordenación del territorio, agricultura y control de desastres. Por ello,
los sistemas de observación terrestres se ha convertido en los últimos tiempos en una
poderosa herramienta para el estudio del Sistema Tierra.
Como recientes estudios han revelado, es necesario alcanzar un acuerdo entre países que
proporcione el uso óptimo de los recursos públicos de observación terrestre, evitando
así la innecesaria duplicación de los datos y ofreciendo un servicio global. Con el fin de
promover esta idea, en los últimos años han aparecido diferentes iniciativas a diferentes
escalas. La mas importante es el Sistema de Sistemas de Observación Global Terrestre
(GEOSS) cuyo objetivo principal es la observación coordinada, eficiente y sostenible
del Sistema Tierra a escala global, para mejorar el seguimiento del estado de la Tierra y
aumentar tanto en conocimiento de sus procesos como en la capacidad de predicción
sobre los mismos. En Europa, la Comisión Europea y al Agencia Espacial Europea
(ESA) han puesto en marcha el programa GMES (Global Monitoring for Environment
and Security) con el objetivo de desarrollar las capacidades de control medioambiental
para el beneficio de los ciudadanos europeos. En nuestro país, recientemente el gobierno
español ha anunciado su intención de desarrollar un Sistema de Observación Terrestre
Nacional en el plazo de unos años.
El Grupo para la Observación de la Tierra (GEO), grupo encargado del desarrollo de

GEOSS, ha reconocido que el futuro desarrollo de los Sistemas de Observación
Terrestre pasa por estar estrechamente unido a las infraestructuras de datos espaciales y
en las arquitecturas de información orientada a servicios. A su vez, la ESA reconoce la
importancia de incorporar la información de GMES en la iniciativa INSPIRE. Se trata,
por tanto, de promover el acceso interoperable de los datos de los distintos Sistemas de
Observación de la Tierra en el marco de las IDEs. Para ello, es necesario incorporar
determinadas funcionalidades basadas en estándares, adaptándolas a las características
especiales que estos datos poseen. Estas funcionalidades son:
Catalogación de los datos siguiendo el estándar internacional de metadatos geográficos

(ISO 19115) y el servicios de catalogo OGC. Tanto en el proceso de catalogación de los
datos e imágenes como en el acceso a los metadatos, se debe prestar especial interés a la
componente temporal.

Sesión 8 El desarrollo de los Sistemas de Observación de la Tierra (SOT) en el...
Visualización y acceso a los datos siguiendo estándares OGC web services como por
ejemplo Servicios de mapas (WMS). En este caso, la especificación sobre Style Layer
Descriptor (SDL) cobra especial interés en la representación de imágenes
multiespectrales. Para el acceso a información geoespacial de forma transaccional, se
deben emplear los servicios WFS y WCS. El primero permite acceso a información
codificada en GML que a partir de la versión 3 puede almacenar información raster,
mientras que el segundo proporciona un servicio de acceso más especializado en
coberturas raster en varios formatos. Por último, el recientemente especificado servicio
de observación por sensores (SOS) proporciona una API para la gestión de sensores y la
recuperación de sus dato. Se especifica para sensores in situ (Sensores meteorológicos,
etc) como sensores remotos (Ej. satélites) ofreciendo información en tiempo real o en su
caso con un gran nivel de actualización de los datos.
Servicios de procesado de imágenes: sin duda alguna, el gran potencial de los datos de
Observación de la Tierra es que a través de su procesado se puede obtener una
importantísima información sobre el sistema Tierra. Actualmente, las llamadas
arquitecturas orientadas a servicio puede proporcionar una serie de herramientas de
procesamiento que hasta ahora solo se podía realizar con un costoso software de
escritorio. Entre las iniciativas más importantes en este sentido podemos destacar Web
Processing Service (WPS), Web Coverage Processing Service (WCPS) y Web Image
Classification Service (WICS). El primero ofrece de un servicio de procesamiento
general (tanto vectorial como raster) que posibilita el cálculos o modelado de datos
georreferenciados. Los otros dos servicios son específicos para el procesamiento de
datos grid e imágenes georreferenciadas.

Utilización de servicios de una IDE en una aplicación web para la... Sesión 8
UTILIZACIÓN DE SERVICIOS DE UNA IDE EN UNA

APLICACIÓN WEB PARA LA GESTIÓN DE LA INFORMACIÓN
DE LA DIRECTIVA MARCO DEL AGUA
Orietha Castillo Zalles, José Antonio Álvarez-Robles, Miguel Ángel Latre,
Pedro Rafael Muro-Medrano
E-50018 Zaragoza, España
[oriecas, jantonio, latre, prmuro]@unizar.es
La Directiva Marco del Agua (DMA) tiene como objetivo tener aguas europeas en “buen estado”
para 2015 e impone a los estados miembros nuevos requisitos de gestión de información y que
informen periódicamente a la Comisión Europea de su progreso.
La Confederación Hidrográfica del Duero (CHD) está encargada de la implantación de la DMA

en la parte española de la cuenca del Duero. Utiliza una aplicación de escritorio (DMA-Duero),
elaborada inicialmente para la Confederación Hidrográfica del Ebro, que sigue una arquitectura
cliente-servidor, donde la lógica de negocios esta dividida en la base de Datos (Oracle), en la
que se almacena toda la información relativa a la DMA (red fluvial, masas de agua, zonas
protegidas y relaciones entre ellos) y en la aplicación cliente, que sigue el patrón MVC (Model-
View-Controller) para la visualización y edición de la información alfanumérica. Además, integra
un visualizador/editor de información geográfica desarrollado en Java (JGISView), que permite
su visualización, búsqueda y selección.
Debido a las limitaciones del ancho de banda de salida de la CHD, la base de datos de la DMA-
Duero se encuentra alojada en un servidor externo. La aplicación de escritorio se ejecuta de
forma remota desde la CHD y las empresas consultoras encargadas de la ejecución de los
trabajos de la DMA en el Duero. Ello origina problemas de velocidad de acceso, configuración y
actualización del software, haciéndose necesario, para poder trabajar adecuadamente,
disponer de una aplicación en un entorno web (DMA-Duero Web), que debe desarrollarse
además en un periodo de tiempo muy limitado.
La aplicación DMA-Duero Web presenta las siguientes ventajas con respecto a la de escritorio:
- El acceso a los datos es compartido.
- El acceso a los datos es mediante web, lo que implica que no es necesario hacer ningún
tipo de configuración en los clientes.
- A diferencia de la aplicación de escritorio, no es necesario habilitar puertos específicos
para el acceso a los datos (excepto el de web), lo que disminuye la posibilidad de
agujeros de seguridad en el sistema.
- Ante nuevas actualizaciones no es necesario hacer ninguna modificación en los clientes.
- Permite la reutilización de servicios web implementados en el marco de IDEs (como
IDEE).
- Permite orientar desarrollos necesarios para DMA-Duero Web hacia el marco de
servicios web que puedan ser luego reutilizados (WMS y WFS).
El proyecto plantea implementar una arquitectura con entorno web, donde la lógica de negocios esta
dividida una capa de datos, una capa de servicios y una de cliente. Al establecer la arquitectura se
plantean distintas configuraciones:
Para la visualización y edición de información alfanumérica de las entidades relativas a la DMA:
- Arquitectura de aplicación web (Servlets y JSPs), accediendo a los datos directamente a

través de un RDBMS o de un WFS.
- Utilización de un WFS y hojas de estilo.
Para la visualización y selección de información espacial:

Sesión 8 Utilización de servicios de una IDE en una aplicación web para la...
- Servicios de mapas (WMS) (de las entidades de la DMA en el Duero; de la IDEE para la
cartografía básica) y cliente web que acceda a ellos.
En este trabajo, desde el punto de vista del contexto del desarrollo de la aplicación DMA-Duero web
se analizan las ventajas y desventajas de las posibles arquitecturas: los problemas encontrados en la
arquitectura con WFS se refieren principalmente a la eficiencia, estandarización, volumen y gestión
del GML; la pérdida de la capa de modelo y la lógica de negocio (por otra parte, ya
implementada en la aplicación de escritorio) y el incremento de la funcionalidad ubicada en el
cliente. Por otra parte, esta arquitectura, permite un mecanismo muy simple para la
visualización de la información alfanumérica; puede soportar operaciones de transacción y
permite que parte de la funcionalidad a desarrollar consista en servicios web, que luego pueden
ser reutilizados o integrados en una IDE.
En cambio, para la visualización de la información espacial, se utiliza un cliente que accede a

WMS, reutilizando contenidos de servicios de mapas ya implementados (WMS de IDEE). Son,
además, altamente eficientes, ya que el resultado de su invocación es la imagen que se va a
mostrar al usuario. Este enfoque da pie, a su vez, a añadir en el cliente de visualización otras
funcionalidades típicas de las IDEs, tales como la visualización de mayor número de capas o la
selección de zonas de trabajo a través de otros servicios de IDEE (catálogo y nomenclátor,
respectivamente).
Tras analizar con detenimiento, las ventajas y desventajas de las arquitecturas propuestas, se
ha optado, para la información alfanumérica, por la arquitectura de una aplicación web
(Servlets y JSPs) que accede a los datos directamente a través de un RDBMS, mantiene la
capa de modelo de la lógica de negocio ya implementada y, para la información espacial, la
creación de WMS y reutilización de los de IDEE. El esquema de la arquitectura se presenta a
continuación (con flechas de color rojo se resaltan las alternativas que han sido tenidas en
cuenta pero, finalmente, no implementadas) y será descrito con más detalle en la comunicación
completa.
En la comunicación completa, se proporcionará una evaluación de las diferencias estimadas en

el tiempo de implementación y de eficiencia en ejecución de las distintas alternativas.

StyledCat: Denición de un catálogo de estilos (SLD). Sesión 8
StyledCat: Definición de un catálogo de estilos

(SLD)
A. Maldonado1, M.A. Bernabé2, M.A. Manso3
Departamento de Ingeniería Topográfica y Cartográfica
Km. 7,5 Autovía de Valencia, 28031 Madrid
Tlf: 913311968
1
e-mail: a.maldonado@topografia.upm.es
2
e-mail: ma.bernabe@upm.es
3
e-mail: m.manso@upm.es
Resumen
El presente artículo trata sobre la definición de un repositorio-catálogo-registro de

estilos para la representación cartográfica de los distintos fenómenos geográficos,
basándose en la simbología normalizada de las distintas Organizaciones
Cartográficas, tales como el Instituto Geográfico Nacional, el Ministerio de Medio
Ambiente, el Instituto Nacional de Estadística, etc. El catálogo proporcionará una
rápida y fácil identificación de los diversos estilos utilizados por dichos organismos
oficiales y su aplicación a documentos obtenidos vía WFS.
Se trata de definir un repositorio en el que almacenar los estilos individualizados de

los fenómenos geográficos, donde se disponga de la capacidad de interactuar con
los mismos para insertar, borrar y actualizar nuevos estilos. El repositorio debe de
responder como catálogo sobre el que buscar y descargar estilos.
Una de las aplicaciones del repositorio-catálogo es la generación de estilos en el

formato Style Layer Descriptor (SLD) definido por Open Geospatial Consortium
(OGC), para ser visualizados mediante Servidores de Mapas en Red conformes con
OGC.
Palabras clave: Simbología, WMS, SLD, catálogo.

Sesión 8 StyledCat: Denición de un catálogo de estilos (SLD).
1 Introducción
A continuación se muestran tres ejemplos de mapas obtenidos a partir de un WMS

http://mapas.topografia.upm.es/cgi-bin/larioja
Figura 1. Ej. 1 de mapa obtenido del WMS de La Rioja
Figura 2. Ej. 2 de mapa obtenido del WMS de La Rioja
Figura 3.Ej. 3 de mapa obtenido del WMS de La Rioja
Los tres son mapas obtenidos del mismo servidor, muestran la misma información
geográfica (parámetro Layers= viascomunicacion en los tres casos) y de la misma
zona (mismo BBox). Sin embargo han sido solicitados con estilos de simbolización
distintos (distinto parámetro SLD_BODY). El mapa resultante es muy distinto en
cada caso: la estética, la legibilidad y la información que aportan al lector hacen
que unos mapas tengan mayor calidad cartográfica que otros.

Esta posibilidad es la que nos ha llevado a desarrollar este catálogo de estilos, que
proporciona a los usuario los estilos de simbolización (SLD) normalizados por las
diversas organizaciones cartográficas, para las distintas temáticas (relieve,
hidrografía, comunicaciones,…), de modo que los mapas obtenidos con estos
estilos sean de alta calidad visual.
2 Justificación-Motivación de este trabajo

La realización de este trabajo se ve justificada en los dos aspectos que se exponen a
continuación:
2.1 Ausencia en estos momentos de un catálogo de estilos

normalizados de simbolización
Las instituciones cartográficas disponen de un sistema de simbolización

normalizado para cada una de sus series o productos. Si esta capacidad de
simbolización se hace pública y accesible a través de un geoservicio en Internet,
cualquier usuario (con nociones cartográficas o no) podría acceder a ella y
aplicarla, dotando a sus mapas de la simbología estandarizada y normalizada
diseñada por estas instituciones.
Se ha detectado la carencia de un servicio que almacene, gestione, estructure y

proporcione acceso a esta simbología, lo que facilitaría la confección de mapas
visualmente correctos a multitud de profesionales pertenecientes a ramas de la
ciencia como la geología, comunicaciones, agricultura, medio ambiente o cualquier
otra en la que se precise de la construcción de un documento cartográfico.
2.2 Pérdida de calidad cartográfica en los mapas obtenidos a partir de

un WMS.
Frente a las numerosas ventajas que ofrecen los WMS en la obtención de mapas,
existe como gran inconveniente la ausencia de calidad cartográfica de los mapas
vectoriales rasterizados y obtenidos mediante estos servicios. Para solventar este
inconveniente se puede aprovechar la posibilidad de aplicación de la especificación
SLD para personalizar el mapa. Sin embargo, la preparación manual de un

documento XML consistente con la especificación SLD por parte de cualquier

usuario trae consigo algunos obstáculos:
1. La falta de nociones sobre semiología gráfica para diseñar la simbología.
2. y lo tedioso que resulta la elaboración de estos documentos SLD.
Son por tanto estas dos razones las que nos hacen proponer un repositorio-catálogo
de estilos que proporcione al usuario el documento SLD correctamente construido
a partir del estilo, normalizado por una organización cartográfica, una vez elegido
por el mismo. De este modo, simplemente habría que descargar del repositorio el
estilo y aplicarlo directamente en un cliente SIG-IDE de escritorio o a través de un
WMS para la obtención del mapa ajustado a ese estilo.
3 Objetivo general
El objetivo general que se busca con este trabajo es la creación de un repositorio-
catálogo de estilos que proporcione a los usuarios de las IDE la obtención de estilos
normalizados por los diferentes organismos cartográficos que, aplicados a los
WMS, den lugar a mapas normalizados o reglados según esos organismos.
Repositorio – catálogo de Estilo en tres

estilos formatos
BBDD con Peticiones de

+ acceso TXT
USUARIO
parámetros
Simbología de SLD
los distintos
SVG
organismos
cartográficos
Figura 4.Esquema de la definición del catálogo
4 Posibles formatos de devolución del estilo

Los estilos que devuelva el catálogo deberán ser proporcionados en distintos

formatos (txt, sld y svg) con la finalidad de ampliar su diversidad de uso y
aplicaciones:
- txt: Finalidad simplemente descriptiva del estilo de simbología elegido.

- sld: Para poder ser aplicado directamente a los WMS en la obtención de
mapas
- svg: Proporciona de forma visual, a modo leyenda, el estilo que se
descarga
5 Características del catálogo

El catálogo – repositorio de estilos está compuesto fundamentalmente de una base
de datos PostgresSQL a la que se accede a través de un conjunto de peticiones que
han sido diseñadas para permitir la interacción del usuario con la base de datos.
El catálogo realizará una generación dinámica del estilo deseado y en el formato

solicitado tras la petición de descarga de estilo.
Todo este sistema estará armonizado con las especificaciones de OGC en la medida
de lo posible.
5.1 Creación de una base de datos Postgres.
La base de datos almacenará mediante seis tablas interrelacionadas los datos de

cada estilo de simbolización: Los parámetros de estilo, el organismo que lo genera
y las categorías que engloba cada estilo, permitirán realizar las búsquedas de una
manera cómoda y eficaz sobre el catálogo.
A continuación una breve descripción de las seis tablas:
- Tabla de los estilos: Contiene información del organismo que genera el estilo, las
categorías (relieve, hidrografía, comunicaciones,…) y las subcategorías (curvas

de nivel, ríos, lagos, carreteras, caminos,…) que engloban el estilo. También

permite realizar búsquedas del estilo deseado según unos criterios de búsqueda.
- Tabla de reglas (“Rules”) de simbolización: Basada en las especificaciones

Styled Layer Descriptor [1] y Filter encoding [2] de OGC, de modo que contiene
las reglas de simbolización de cada estilo (límites máximos y mínimos de la
escala de visualización del símbolo, selección de fenómenos a los que se aplica el
estilo por medio de sus atributos,…).
- Cuatro tablas de simbolizaciones (“Symbolizers”): Una para la puntual

(PointSymbolizer de la especificación SLD de OGC), otra para la lineal
(LineSymbolizer), otra para la poligonal (PolygonSymbolizer), y otra para la
textual (TextualSymbolizer). Contienen los parámetros de los estilos almacenados
en las distintas tablas dependiendo de la geometría del elemento.
La interrelación de las seis tablas está basada en el hecho de que un estilo contiene
una o más reglas, y una regla contiene una o más simbolizaciones. Esta
interrelación se explica en el ejemplo del apartado 6.
5.2 Capacidad del usuario de interacción con la base de datos.
Para asegurar la capacidad de interacción del usuario con la base de datos se han
diseñado una serie de operaciones de interface. Estas operaciones se pueden
englobar en cuatro grupos según su funcionalidad:
1. Operaciones de búsqueda: Permiten recorrer la base de datos introduciendo

varios parámetros de búsqueda y encontrar el estilo deseado. (Ej.:
GetCapabilities, GetCategories,…).
2. Una operación de obtención o descarga de estilo: Tiene como respuesta el

estilo especificado en la petición. (Formatos posibles = svg, sld, texto.)
Ejemplo: GetStyle(ID=2, Format=SLD)

3. Operaciones de transacción: Permiten el acceso a la base de datos para

realizar operaciones de inserción, edición, borrado.(Ej: Insert, Update, Delete)
4. Una operación para diseñar y materializar un nuevo estilo propio:

Permite definir a un usuario un nuevo estilo personalizado pero sin llegar a
almacenarlo, simplemente pare obtenerlo en formato SLD y aplicarlo en un
WMS o poder visualizarlo en formato SVG. (Ej: ParseStyle).
5.3 Generación dinámica de los estilos.
Los estilos son generados dinámicamente por el catálogo. Este proceso surge como
una petición de un usuario que conoce el identificador de estilo deseado y que
invoca una petición GetStyles. Cada estilo es construido a partir de los parámetros
almacenados en la base de datos relativos a ese identificador.
El formato de devolución del estilo es el especificado en la petición, y por defecto
es el formato SLD.
5.4 Armonización con especificaciones OGC
Todo este sistema será integrado en un servicio lo más armónico posible con las
especificaciones OGC, consiguiéndose así un uso más intuitivo para la comunidad
de usuarios de las IDE.
Para ello los esquemas de peticiones son diseñados basándose en los esquemas de
las especificaciones OGC.
6 Conclusiones
Tras este trabajo se establecen una serie conclusiones sobre la simbolización
cartográfica y su aplicación a las IDEs en base a los siguientes resultados:

- Posibilidad de llevar a cabo una definición, de manera concreta, de la

simbología cartográfica mediante la parametrización de sus características
y atributos.
- Capacidad para poder realizar un almacenamiento estructurado y

organizado de la simbología utilizada por las distintas organizaciones.
Almacenamiento estructurado que permita realizar búsquedas sistemáticas
a partir de condiciones impuestas.
- Posibilidad para los usuarios de las IDEs, de generar cartografía sin errores
semánticos a partir de los WMS.
7 Ejemplo
El siguiente ejemplo muestra la concordancia de la interrelación entre las tablas de

estilos, reglas y simbolizaciones con la especificación Styled Layer Descriptor
(SLD).
La simbolización del mapa de la figura, obtenido a partir de un WMS,
Figura 5.Ejemplo de mapa
se corresponde con la definida mediante el documento SLD que se muestra a

continuación.
En este documento se ve como un estilo de nombre “Estilo Carreteras” está
compuesto de varias reglas o rules, y cada una de estas reglas está compuesta de
varias simbolizaciones, en este caso del tipo LineSymbolizer.
<StyledLayerDescriptor>
<NamedLayer>
<Name>viascomunicacion</Name>

<UserStyle>
<Name>EstiloCarreteras</Name>
<Abstract>TipoGeom</Abstract>
<FeatureTypeStyle>
<Rule>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>VCOM_VIALT</ogc:PropertyName>
<ogc:Literal>AUTOP</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<LineSymbolizer>
<Stroke> Simbolización 1
<CssParameter name="stroke">#ff0000</CssParameter> Regla nº 1, que
<CssParameter name="stroke-width">2</CssParameter> Color rojo, ancho 2 selecciona los viales
</Stroke> de tipo autopista
</LineSymbolizer>
<LineSymbolizer>
<Stroke>
<CssParameter name="stroke">#FDE802</CssParameter> Simbolización 1
<CssParameter name="stroke-width">1</CssParameter> Color amarillo, ancho 1
</Stroke>
</LineSymbolizer>
</Rule>
<Rule>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>VCOM_VIALT</ogc:PropertyName>
<ogc:Literal>CAUT1</ogc:Literal>
</ogc:PropertyIsEqualTo> Regla nº 2, que
</ogc:Filter> selecciona los viales
<LineSymbolizer> de tipo auton 1er
<Stroke> orden
<CssParameter name="stroke">#56D689</CssParameter> Simbolización 1
<CssParameter name="stroke-width">2</CssParameter>
</Stroke> Color verde, ancho 2
</LineSymbolizer>
</Rule>
…… (Otras reglas)
<StyledLayerDescriptor>
Para obtener dicho documento SLD, el catálogo debe de contener los parámetros
correspondientes, estructurados en las distintas tablas, y teniendo en cuenta la
interrelación entre estilos, reglas (rules) y simbolizaciones (symbolizers): Un estilo
contiene una o varias reglas, y cada regla contiene una o varias simbolizaciones.
En la tabla de reglas, se almacenarían estas reglas o rules del siguiente modo:
ID regla Nombre atributo Operador Valor atributo ID simbolizaciones
… …. … …. …
4 VCOM_VIALT = Autop {2,3}

5 VCOM_VIALT = Caut1 {4}
… … … … …
Y en la tabla de simbolizaciones se almacenarían las simbolizaciones que contienen

las anteriores reglas:
ID Simbolización Color Grosor Discont.

… … … …
2 ff0000 (rojo) 2 0
3 Ff00ff (amarillo) 1 0
4 00ff00 (verde) 1 0
… … … …
Referencias
[1] Open GIS Consortium Inc.(2002): Styled Layer Descriptor Implementation
Specification. Reference number of this OpenGIS© Project Document: OGC
02-070. Version: 1.0.0.
[2] Open GIS Consortium Inc.(2001): Filter Encoding Implementation

Specification. Reference number of this OpenGIS© Project Document: OGC
02-070. Version: 1.0.0

Solución corporativa para la gestión descentralizada de metadatos:... Sesión 8
Solución corporativa para la gestión

descentralizada de metadatos: Cliente Web de
administración de metadatos
Joan Nunes Alonso1, Ignacio Ferrero Beato2, y Laura Sala Martín3
1 Laboratorio de Información Geográfica y Teledetección (LIGIT),

Universitat Autònoma de Barcelona (UAB),
Edifici B, 08193 Bellaterra, (Barcelona)
http://www.uab.es/ligit. e-mail: joan.nunes@uab.es

http://www.uab.es/ligit. e-mail: ignacio.ferrero@uab.es

http://www.uab.es/ligit. e-mail: laurasala77@hotmail.com
Resumen
El cliente web de administración de metadatos se concibe como una solución para

la gestión descentralizada de metadatos en entornos corporativos; de modo que
todas las tareas en relación a los metadatos se puedan desarrollar desde un entorno
web común, de manera descentralizada y sin la necesidad de que todos los usuarios
potenciales dentro de la organización dispongan de un software GIS específico
para la gestión de metadatos. Se han tipificado diferentes perfiles de usuarios que
interactúan sobre el catálogo en diferentes niveles dependiendo del tipo de
actuación que pueden realizar sobre el mismo (edición, validación, publicación,
actualización y administración de metadatos).
El cliente web de administración del Catálogo es una aplicación cliente-servidor,
desarrollada con tecnología JAVA, J2EE, y Xforms. El acceso a las

Sesión 8 Solución corporativa para la gestión descentralizada de metadatos:...
funcionalidades en el cliente web se produce a través de las distintas interfaces:

Información, Validación, Edición y Publicación.
Desde la interfaz de información se accede a las funcionalidades de consulta sobre

los documentos publicados en el catálogo, visualización de metadatos, descarga de
los ficheros xml publicados, así como el acceso directo a la actualización de los
metadatos publicados, que pueden ser incorporados en el catálogo desde la misma
aplicación.
La interfaz de validación de los metadatos permite a los usuarios con perfil

administrador llevar a cabo la validación de los metadatos pendientes de ser
verificados para su publicación definitiva en el catálogo.
Desde la interfaz de edición, se lleva a cabo la edición y la actualización de

metadatos. Esta interfaz se ha desarrollado mediante la creación de formularios
Xforms, debido a la multitud de ventajas de éstos frente a los tradicionales
formularios HTML, sobretodo en cuanto a la posibilidad de enviar los formularios
de datos como XML. La edición y actualización de metadatos en web se produce
mediante un conjunto de formularios estructurados en el modelo de asistente, con
el fin de permitir la validación estructural y formal de los metadatos de manera
progresiva; por otro lado, permite la documentación de entidades y elementos de
metadados de documentación reiterada mediante la réplica de la parte del
formulario que contiene dicho ítem o entidad. Desde la misma interfaz se accede,
una vez completada la edición o actualización de metadatos, a la interfaz de
publicación.
Por último la publicación de metadatos se lleva a cabo desde la interfaz de

publicación; que puede producirse o bien a través de la carga de un fichero de
metadatos del cliente o bien a través de la publicación de metadatos editados o
actualizados desde la misma aplicación. En cualquier caso, el usuario puede
visualizar los metadatos en formato html (a través de la aplicación de una hoja de
estilos xsl) antes de incorporarlos al directorio del Catálogo de metadatos
centralizado.
El cliente web de administración de metadatos se ha incorporado al conjunto de

herramientas que integran el Catálogo de metadatos de la Diputación de Barcelona,
para la implementación corporativa del Catálogo.

Palabras clave: Administración, metadatos, Xforms, catálogo.
1 Introducción
El éxito en la implementación de la solución para la gestión descentralizada de
metadatos en entornos corporativos, depende en gran medida de que se disponga de
protocolos de trabajo donde se establezcan claramente los roles y jerarquías con
relación a la generación, mantenimiento, actualización, publicación y recuperación
de metadatos de información así como de los mecanismos de interrelación entre los
diferentes entes.
Por ello, en las etapas conceptuales, previas al desarrollo de la solución

corporativa para la gestión descentralizada de metadatos, se hizo especial hincapié
en la necesidad de definir los distintos procedimientos en relación a los metadatos
dentro de una organización así como de tipificar los distintos perfiles de usuario en
función de su nivel de interacción con dichos procedimientos.
Figura 1. Tabla resumen de perfiles y procedimientos en relación a los metadatos

El cliente web de gestión de metadatos debe de poder integrarse en el

funcionamiento de cualquier organización, para ello se tipificaron distintos
escenarios en función del nivel de restricciones en el control del acceso al catálogo
de metadatos de la organización.
El control del acceso se materializa a través del fichero de control de acceso de

usuarios al Catálogo, (Acces Control List), en el que el usuario con perfil
administrador, introduce cada uno de los nombres de usuario con su contraseña y
con su rol o perfil en relación a los metadatos, que se haya asignado dentro de la
organización. Este fichero de control està vinculado al cliente web de
administración y al Catálogo de metadatos centralizado.
2 El Cliente web de gestión de metadatos

El cliente web de administración de metadatos se concibe como una solución para
la gestión descentralizada de metadatos en entornos corporativos; de modo que
todas las tareas en relación a los metadatos se puedan desarrollar desde un entorno
web común, de manera descentralizada y sin la necesidad de que todos los usuarios
potenciales dentro de la organización dispongan de un software GIS específico
para la gestión de metadatos.
Todas las funcionalidades se desarrollan gracias de la interacción entre la

aplicación y el Catàlogo de metadatos de la organización, que debe de
implementar-se a partir de la tecnología de ESRI mediante la generación de un
servicio de metadatos en ArcIMS.
La publicación del servicio de metadatos automatiza la creación de una base de

datos en ArcSDE que se gestiona mediante ORACLE. No obstante i para la plena
funcionalidad de la aplicación web es necesario generar, previamente a la
publicación del servicio, una tabla de administración que se asocia al servicio de
metadatos a través del fichero *.axl, de configuración. Este fichero debe incorporar
para cada registro (fichero de metadatos publicados en el catálogo), información
respecto al usuario publicador, fecha de publicación de los metadatos en el
catálogo, estado del fichero de metadatos en relación a su validación y fecha en la
que se produce la validación por parte del usuario con perfil administrador.

El cliente de administración es una aplicación cliente-servidor, desarrollada con

tecnología JAVA, J2EE, y Xforms. El acceso a las funcionalidades se produce a
través de las distintas interfaces: Información, Validación, Edición y Publicación.
Para acceder a la aplicación, los usuarios deben identificarse con el nombre de
usuario y contraseña que les ha sido asignado por el usuario administrador, de tal
manera que en función del perfil de usuario proporcionado la aplicación muestra al
usuario únicamente las interfaces que le permitan acceder a las funcionalidades a
las cuales tiene acceso.
Figura 2. Esquema de la arquitectura de implementación.
A continuación se describen cada una de las interfaces haciendo especial hincapié

en la definición de las funcionalidades que se ejecutan en cada una de éstas.

2.1 Interfaz de información del estado
La interfaz de información del estado del catálogo es la interfaz inicial del cliente
web de gestión de metadatos. A continuación se muestra una imagen de la interfaz
y una descripción de las funcionalidades que se desarrollan en la misma.
Figura 2. Imagen de la interfaz de información del estado
Consultas sobre los documentos publicados

Si el usuario tiene el perfil administrador puede realizar consultas acerca de los
documentos que han sido publicados en el catálogo por los diferentes usuarios con
perfil publicador. Dispone de consultas predefinidas así como la posibilidad de
definir y ejecutar consultas por fecha de publicación. Si el usuario tiene el perfil
publicador, solo puede consultar los documentos que como usuario publicador ha
publicado en el catálogo, pudiendo también definir y ejecutar consultas con
criterios temporales.
En ambos casos el resultado de las consultas es un listado de los documentos

publicados donde para cada registro se muestra información sobre el estado y la
fecha de publicación y validación (en caso de que el documento esté validado).

Visualización de metadatos publicados

Pulsando sobre el nombre del documento se accede a la visualización del
documento en formato html.
Descarga de ficheros de metadatos publicados en formato xml

Al pulsar sobre el nombre de un documento, una vez realizada alguna de las
consultas, predefinidas o temporales, además de acceder a la visualización del
documento, se genera una barra inferior donde se proporciona un botón que
permite llevar a cabo la descarga del documento de metadatos en formato xml.
Acceso directo a la actualización de fichero de metadatos publicados

En la misma barra inferior hay un botón que permite acceder a la interfaz de
edición de metadatos, en la que se carga el fichero de metadatos que se quiere
actualizar.
Figura 3. Visualización de metadatos publicados y acceso a la actualización y

descarga del documento xml.

2.2 Interfaz de publicación de metadatos
Desde la interfaz de publicación de metadatos los usuarios con perfil publicador y

administrador pueden llevar a cabo la publicación de documentos xml en el
catálogo centralizado de la organización.
El acceso a la interfaz se produce mediante el botón de la barra de acceso a las
diferentes interfaces, o bien desde la interfaz de edición y actualización de
metadatos una vez que se ha finalizado la edición o actualización de un fichero de
metadatos.
La publicación de metadatos se completa con tres pasos que conllevan la elección
del fichero de metadatos, la elección del directorio del catálogo y la ejecución de la
publicación.
Cuando los usuarios acceden a la interfaz de publicación desde la interfaz de
edición y actualización de metadatos, sólo deben de completar los dos últimos
pasos de la publicación: la elección del directorio del catálogo y la ejecución de la
publicación.
Elección del fichero

Para seleccionar el fichero de metadatos a publicar, el usuario debe de pulsar un
botón que permite acceder a un dialogo de exploración de los ficheros almacenados
en el cliente. Una vez seleccionado el fichero de metadatos se proporciona al
usuario la visualización en formato html de los metadatos seleccionados.
Elección del directorio del catálogo

Para que el usuario pueda elegir el directorio del catálogo en el que quiere
almacenar los datos se le proporciona un árbol en el que se representa la estructura
de directorios del catálogo de metadatos. El usuario debe elegir el directorio en el
que desea que se almacenen los metadatos en el catálogo.
Ejecución de la publicación
En el último paso de ejecución de la publicación, los usuarios deben pulsar el botón
que ejecuta la publicación del fichero de metadatos y lo relaciona con el directorio
seleccionado.

Figura 4. Interfaz de publicación de metadatos
Cuando el usuario tiene el perfil publicador, en la tabla de administración del

catálogo se genera un registro con el fichero de metadatos publicado el nombre de
usuario del usuario publicador, y la fecha de publicación; en el campo
correspondiente al estado este fichero permanece en estado de no validado hasta
que el administrador proceda a su validación definitiva en el catálogo.
En cambio, la publicación de metadatos por parte de un usuario con perfil

administrador implica que estos ficheros estén automáticamente validados desde su
publicación.

2.3 Interfaz de validación de metadatos
Desde esta interfaz el administrador lleva a cabo la validación de los documentos

que han publicado usuarios del catálogo de metadatos con perfil publicador.
Figura 5. Interfaz de validación de metadatos
El acceso a la interfaz validación de metadatos esta permitido únicamente a los

usuarios que se identifiquen como administrador/es del catálogo de metadatos de la
organización
El usuario administrador tiene acceso a la consulta de los documentos de metadatos

que están pendientes de validación. Esta consulta se puede restringir a un usuario
en concreto o bien realizar-la sobre todos los documentos publicados
independientemente del usuario publicador.
El resultado de las consultas es un listado con el nombre de los documentos de

metadatos pendientes de validación y con su correspondiente fecha de publicación.
El administrador puede visualizar los metadatos pendientes de validar pulsando

sobre el nombre del documento, para comprobar que estén bien documentados.

Una vez comprobados los metadatos, el administrador puede escoger entre ejecutar
o no la validación de los metadatos. La ejecución de la validación implica la
modificación del campo correspondiente al estado del documento en la tabla de
administración del catálogo, que pasa a estar validado. Además, se añade la fecha
en la que se ha producido la validación del documento en el campo
correspondiente.
2.4 Interfaz de edición y actualización de metadatos

En las frases iniciales de desarrollo de la aplicación se analizaron las distintas
opciones para la edición en web de metadatos, inicialmente se evaluó la posibilidad
de programar la edición de metadatos en web mediante la utilización de la clase
JDOM con distintos procesos que permitieran cargar en memoria un fichero xml,
que se modificaría mediante formularios html tradicionales.
Partiendo de este primer análisis se pusieron de manifiesto distintos aspectos a los

que había que dar respuesta: por un lado la necesidad de trabajar con ficheros xml
muy largos, que además podían ser distintos en cuanto a la presencia de entidades y
elementos de metadatos cuya ocurrencia no esta limitada a un número, de modo
que los formularios debían ser dinámicos con el fin de controlar éstas posibles
repeticiones de elementos y entidades de metadatos.
Estos requerimientos pusieron de manifiesto las limitaciónes de JDOM así como la

necesidad de buscar otras alternativas para la implementación de la edición de
metadatos en web, en este sentido la utilización de XForms se empezó a perfilar
como la opción óptima.
XForms, es un nuevo lenguaje de etiquetado para formularios Web, diseñado para

ser el sustituto de los formularios tradicionales HTML y que nos permite distinguir
el propósito del formulario de su presentación. De entre las muchas ventajas que
ofrece XForms frente a los formularios HTML la más relevante para los propósitos
de la aplicación es la posibilidad de enviar los formularios de datos como XML, ya
que XForms es precisamente XML.
Para la implementación de XForms hubo una primera fase de documentación en la

que se consultaron básicamente distintos recursos en web:
http://www.w3.org/TR/xforms/index.html#contents
http://www.infoescena.es/achuter/web/w3cdocs/xforms-for-html-
authors_es.html#InitialValues
http://www.w3schools.com/xforms/default.asp

http://www.w3.org/MarkUp/Forms/
http://www.w3c.es/divulgacion/guiasbreves/XForms
http://sourceforge.net/projects/chiba
En una fase posterior se utilizó la implementación java OpenSource de W3C de

XForms del proyecto chiba.
2.4.1 Descripción de la interfaz de edición y actualización de metadatos
La interfaz de edición y actualización de metadatos es la interfaz inicial y única del

cliente web de gestión de metadatos cuando los usuarios que ejecutan la aplicación
son usuarios del perfil editor.
Cuando los usuarios tienen el perfil administrador o publicador, el acceso a la

interfaz se lleva a cabo mediante el botón de la barra de acceso a las diferentes
interfaces, o bien desde la interfaz de información del estado del catálogo a través
de la funcionalidad de acceso a la actualización de metadatos.
La edición de metadatos se lleva a cabo mediante un conjunto de formularios

XForms que estarán estructurados en forma de asistente.
Figura 6. Asistente de edición de metadatos

Las ventajas de XForms permiten que la validación se produzca de manera

progresiva, también se da información al usuario sobre las restricciones de
obligatoriedad y de dominio de cada elemento de metadatos, y se proporciona al
usuario una definición ampliada del concepto al que se refiere cada ítem o
elemento de metadatos.
Por otro lado se facilitan al usuario las listas que contienen los nombres
correspondientes a los listados de códigos de dominio para los elementos de
metadatos que tienen el dominio restringido a códigos y enumeraciones propuestos
en la norma ISO de metadatos.
Figura 7. Formulario de edición de metadaotos
Por último, se facilita al usuario la documentación de las características del sistema

de referencia.
Toda la información que tiene que ser proporcionada para facilitar la edición de
metadatos, se almacena en ficheros xml que se asocian al código de los formularios
XForms.

Actualización de metadatos
Para la actualización de metadatos el usuario cuenta con el mismo asistente que
sirve para llevar a cabo la edición; sin embargo en el caso de la actualización de
metadatos, el fichero de metadatos actualizado es una instancia del formulario. De
modo que la información que ya está en el XML se muestra en el asistente de
edición de metadatos.
Acceso directo a la publicación de metadatos

Una vez editados o actualizados los metadatos éstos se pueden publicar
directamente mediante un enlace que permite acceder a la interfaz de publicación
de metadatos.
3 Conclusiones
La importancia y utilidad de los metadatos dentro de una organización toma
especial relevancia cuando éstos son accesibles. Es habitual que dentro de las
organizaciones exista un departamento de SIG, que dispone de recursos y software
específico, no obstante el desarrollo de las tecnologías y los sistemas de
información ha generado un mapa en el que distintos departamentos trabajan, se
nutren y generan información geográfica. A menudo la implementación de los SIG
en estos departamentos puede diferir en cuanto a las tecnologías que se utilizan, así
como en el ritmo y desarrollos de implementación.
En este escenario es necesario disponer de un sistema que permita centralizar en

un mismo catálogo los metadatos de información generada o en uso en el seno de
las organizaciones, pero sobretodo, y como se avanzaba al principio de esta
reflexión final, es de vital importancia que los metadatos sean accesibles a todos
los usuarios.
El desarrollo del cliente web de gestión y administración de metadatos permite que

todas las funcionalidades se desarrollen en un entorno web común, manteniendo la
idiosincrasia e independencia de los distintos departamentos en su relación con la
información geográfica.
Finalmente señalar que el cliente web de administración de metadatos se ha

incorporado al conjunto de herramientas que integran el Catálogo de metadatos de
La Diputación de Barcelona, para la implementación corporativa del Catálogo.

Jidee 06

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jidee 06

Uploaded by

Copyright:

Available Formats

Jornadas Técnicas de la IDE Española 2006

CAstellón, 19 y 20 de octubre de 2006

1. IDE de múltiples niveles 7

4. Metadatos y Semántica 141

6. IDE regionales y sectoriales 215

8. EXPOSICIÓN DE POSTERS 309

Jornadas Técnicas de la IDE Española, Castellón 2006. 5

6 Jornadas Técnicas de la IDE Española, Castellón 2006.

IDE DE MÚLTIPLES NIVELES

La Infraestructura de Datos Espaciales de

† Instituto Geográfico Nacional

En los últimos años, el sector de la Información Geográfica (IG) ha experimentado

Palabras clave: Infraestructuras de Datos Espaciales, Información Geográfica,

Jornadas Técnicas de la IDE Española, Castellón 2006. 9

10 Jornadas Técnicas de la IDE Española, Castellón 2006.

2 Filosofía y objetivos de la IDEE

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

Jornadas Técnicas de la IDE Española, Castellón 2006. 11

sus servicios si así lo desean, en la IDEE, distinguiendo claramente lo que

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

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

- Convención de Aarhus [8], que establece el derecho de los ciudadanos a acceder a

- Iniciativa Open Archives [10], dirigida a definir especificaciones estándar para

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

12 Jornadas Técnicas de la IDE Española, Castellón 2006.

eficacia y rendimiento, proceder a la descarga de los datos geográficos para su

Sabemos que, al menos en apariencia, esta aproximación choca con la protección

El CSG definió en Noviembre de 2002 un Grupo de Trabajo para la IDEE, como

Jornadas Técnicas de la IDE Española, Castellón 2006. 13

Las principales recomendaciones consensuadas hasta ahora dentro del GT IDEE

- Definición de un conjunto de Servicios Mínimos Recomendados a implementar

- Establecimiento de unas directrices sobre arquitectura que definan el papel que

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

- Recomendación para la implementación de servicios WMS, en la que se fijan una

4 Estado actual del proyecto

14 Jornadas Técnicas de la IDE Española, Castellón 2006.

Figura 1 Página principal del Geoportal IDEE

Integra un total de más de 28 servidores ofreciendo servicios, y permite el acceso a

Jornadas Técnicas de la IDE Española, Castellón 2006. 15

4.1 Datos disponibles

16 Jornadas Técnicas de la IDE Española, Castellón 2006.

constelación de proyectos en este ámbito de la administración y su alto nivel

Figura 2. Superposición de cartografía del IGN 1:25.000 sobre (de izquierda a

Jornadas Técnicas de la IDE Española, Castellón 2006. 17

A nivel temático, existe ya un notable conjunto de aplicaciones y Geoportales que

4.2 Servicios básicos

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

- Guardar la imagen que se está mostrando en el visualizador en un momento

- Superponer interactivamente un Servicio de Mapas (WMS) del que conocemos su

18 Jornadas Técnicas de la IDE Española, Castellón 2006.

- Funcionalidades para una correcta visualización de servicios WMS superpuestos:

Por otro lado, en la IDEE se ofrece un Catálogo de Servicios que funciona de

4.3 Servicios adicionales

Jornadas Técnicas de la IDE Española, Castellón 2006. 19

- La geometría de las unidades administrativas españolas (Comunidades

El objetivo es poner a libre disposición de usuarios, desarrolladores y productores

20 Jornadas Técnicas de la IDE Española, Castellón 2006.

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

4.3.5 Servicio temporal de mapas catastrales. Gracias a que la Dirección General

Jornadas Técnicas de la IDE Española, Castellón 2006. 21

superposición utilizando los servicios de mapas de catastro y de la cartografía

4.4 Últimos desarrollos

4.5 Clientes pesados