Jidee 05
Jidee 05
Jidee 05
3
Sesión 0
1. Catastro 7
1.1. Control de Calidad en el Área de Cartografía Informatizada de la D.G. del Catastro . . . 9
1.2. Sistema de entrada, actualización y publicación en la ovc . . . . . . . . . . . . . . . . . . . 19
1.3. WMS de la Dirección General del Catastro . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Metadatos 111
4.1. Denición de Perles y creación de cheros XML de metadatos para imágenes de Tele-
detección, según la normativa ISO, utilizando la aplicación IME (ISO Metadata Editor)
desarrollada en el Servicio de Teledetección del INTA . . . . . . . . . . . . . . . . . . . . . 113
4.2. El Núcleo Español de Metadatos, perl mínimo de metadatos recomendados para España 122
4.3. Editor de Metadatos NEM V 1.0 para ArcGIS . . . . . . . . . . . . . . . . . . . . . . . . 133
CATASTRO
7
Control de Calidad en el Área de Cartografía Informatizada de la D.G.... Sesión 1
Introducción.
De acuerdo al Real Decreto Legislativo 1/2004, de 5 de marzo, por el que se aprueba el texto refundido de
la Ley del Catastro Inmobiliario (TRLCI) las competencias de la D.G. del Catastro quedan establecidas
de la siguiente manera:
Art. 4.- La formación y el mantenimiento del Catastro Inmobiliario, así como la difusión de la
información catastral, es de competencia exclusiva del Estado. Estas funciones, que comprenden, entre
otras, la valoración, la inspección y la elaboración y gestión de la cartografía catastral, se ejercerán por
la D. G. del Catastro, directamente o a través de las distintas fórmulas de colaboración que se establezcan
con las diferentes Administraciones, entidades y corporaciones públicas.
No obstante lo dispuesto en el párrafo anterior, la superior función de coordinación de valores y la
aprobación de las ponencias de valores se ejercerán en todo caso por la D.G. del Catastro.
Al final de la década de los ochenta se comenzó a desarrollar en lo que era entonces el Centro de Gestión
Catastral y Cooperación Tributaria la aplicación que permitía informatizar la cartografía catastral,
teniendo como soporte físico estaciones de trabajo y como software Arc Info junto con desarrollos en C y
en Unix, pero no fue sino hasta 1996, siendo ya Dirección General del Catastro, al pasar a la arquitectura
cliente-servidor que se amplió el campo de usuarios y por ende el conocimiento de la aplicación al utilizar
ordenadores personales como equipo genérico formando una red interna apoyada por servidores y
enlazada a los Servicios Centrales.
La aplicación sufrió modificaciones al cambiar a ArcSde y Map Object como elementos de desarrollo
junto con Oracle como Base de datos (ver fig.3).
Estos cambios han facilitado la divulgación de la cartografía no solo en el ámbito interno de la D.G. del
Catastro sino también en la disponibilidad de la información para terceros: Notarios, Registradores de la
Propiedad, Ayuntamientos, Diputaciones y público en general a través de la Oficina Virtual del Catastro
(http://ovc.catastro.meh.es/ ) etc.
52 Gerencias
Territoriales
ÓRGANOS ÓRGANOS
CENTRALES TERRITORIALES
CONSEJO SUBDIRECCIÓN
SUPERIOR DE LA GENERAL DE
PROPIEDAD VALORACIÓN E JUNTAS TÉCNICAS
GERENCIAS
INMOBILIARIA INSPECCIÓN TERRITORIALES DE
REGIONALES COORDINACIÓN
COMISIONES SUBDIRECCIÓN
SUPERIORES DE GENERAL DE
COORDINACIÓN ESTUDIOS Y
INMOBILIARIA DE SISTEMAS DE
RÚSTICA Y URBANA INFORMACIÓN CONSEJOS
TERRITORIALES DE
GERENCIAS LA PROPIEDAD
SUBDIRECCIÓN TERRITORIALES INMOBILIARIA
GENERAL DE
PLANIFICACIÓN Y
ATENCIÓN AL
CIUDADANO
SECRETARÍA
GENERAL
CONSULTAS
FICC
DESCARGA
CERTIFICACIONES
SDE SIGECA
SIGCA2 CRUCE
CHEQUEO PLAN
TRAZADOS
VALIDACIÓN
Entorno Administración
MANTENIMIENTO Entorno Cliente
DATOS de Partida
La Cartografía Catastral se divide en dos tipos: Rústica y Urbana, así mientras que el origen de la
cartografía rústica procede de la digitalización de ortofotos a 1/5000, la urbana tiene diferentes orígenes,
desde el levantamiento ex novo, bien por medios topográficos o por medios fotogramétricos, hasta la
aceptación de una cartografía procedente de otro organismo o institución que esté en convenio con la
D.G. pasando por la digitalización y/o transformación de un formato a otro, por ejemplo de soporte papel
a digital o de formato dgn a FICC (Formato de Intercambio de Cartografía Catastral), en escalas 1/500 y
mayoritariamente en escala 1/1000.
El volumen estimado y en formato digital a fecha de Octubre de 2005 de todo el ámbito territorial
gestionado por la D.G. del Catastro (7557 municipios) es el del cuadro siguiente:
Ante tal volumen de datos de partida se procedió a efectuar una serie de controles de tipo informático
para permitir la entrada de datos en el sistema. En un principio se controló la validación sintáctica de los
cinco ficheros FICC, esto es, que cada campo de cada registro contuviera el dato adecuado al mismo, para
una vez superado este pasar a la verificación topológica donde cada recinto no tuviera tramos abiertos ni
careciera de los centroides identificativos de los mismos, entre otros controles. Se hizo especial hincapié
en los aspectos catastrales, naturalmente, sin embargo se procuró transmitir a las empresas encargadas de
la realización de la cartografía que tuvieran en cuenta otros aspectos meramente cartográficos como por
ejemplo la colocación de los textos a lo largo de los objetos que definen y no en línea recta, horizontal o
vertical, el dibujo de signos convencionales: masa de árboles, zonas verdes, etc.
Un ejemplo de la validación de formato o sintáctica es la figura 4:
DIRECCION GENERAL DEL CATASTRO VERIFICACION DATOS DIGITAL. GERENCIA(162): CUENCA PAGINA : 01
--------- ------- --- --------
DE CARTOGRAFIA URBANA MUNICIPIO(900): cuenca FECHA : 12-
M. ECONOMIA Y HACIENDA
-- -------- - -------- CODIGO DE CINTA LIT. MUNICIPIO: CUENCA HORA : 13:5
EMPRESA: GRAFOS
CODIGO NUM REG E FORMATO GENERICO PIC POSIC CAMPO ERRONEO DESCRIPCION DEL ERROR
------ ------- - ----------------- ----- ----- ----------------- ---------------------------------------------------
145501 151 G AAAAAAAAAAA A(11) 33-43 I+0 Volumen no encontrado en tabla
145501 152 G AAAAAAAAAAA A(11) 33-43 II+0 Volumen no encontrado en tabla
145501 153 G AAAAAAAAAAA A(11) 33-43 I+0 Volumen no encontrado en tabla
145501 154 G AAAAAAAAAAA A(11) 33-43 I+0 Volumen no encontrado en tabla
145501 180 G AAAAAAAAAAA A(11) 33-43 I+0 Volumen no encontrado en tabla
145501 182 G AAAAAAAAAAA A(11) 33-43 I+0 Volumen no encontrado en tabla
145501 1182 G AAAAAAAAAAA A(11) 33-43 FUTBOL Volumen no encontrado en tabla
145501 1183 G AAAAAAAAAAA A(11) 33-43 ATLETISMO Volumen no encontrado en tabla
145501 1209 G AAAAAAAAAAA A(11) 33-43 IXO Volumen no encontrado en tabla
145501 1251 G AAAAAAAAAAA A(11) 33-43 DEPORTES Volumen no encontrado en tabla
145501 1252 G AAAAAAAAAAA A(11) 33-43 DEPORTES Volumen no encontrado en tabla
145501 1255 G AAAAAAAAAAA A(11) 33-43 FUTBOL Volumen no encontrado en tabla
145501 1266 G AAAAAAAAAAA A(11) 33-43 DEPORTES Volumen no encontrado en tabla
145501 1267 G AAAAAAAAAAA A(11) 33-43 DEPORTES Volumen no encontrado en tabla
Interrumpida la salida de errores G del formato AAAAAAAAAAA
Por cada uno de los cinco ficheros se detallan los errores encontrados y se proporciona un resumen final.
En cuanto a la validación de topología se localizan los errores de topología tanto lineales como
superficiales, ejes de calle y parcelas por ejemplo obteniendo tanto salidas gráficas como numéricas de
los mismos, la figura 5 es un ejemplo de la primera.
Una vez conseguida la aceptación por parte de los técnicos encargados de las validaciones se introduce el
municipio en la base de datos de forma provisional puesto que aún queda una serie de comprobaciones, la
primera de las cuales es realizar el cruce de datos entre las referencias catastrales gráficas (SIGCA) y las
alfanuméricas (SIGECA). Para ello se dispone del módulo de cruces en la aplicación.
Este módulo efectúa una comparación entre las referencias catastrales existentes en ambas bases de datos
y proporciona un listado de salida, tipo hoja de cálculo, donde por diferentes códigos numéricos se
pueden estudiar los diferentes errores encontrados, las figuras 6 y 7 son un ejemplo de lo dicho,
Dentro del módulo de cruces la salida de resultados es una hoja de cálculo tipo Excel por lo que se puede
trabajar con ella independientemente de la aplicación. Para conseguir profundizar en las causas de las
discrepancias se efectúan controles de cruce cada trimestre y se obtienen datos para las tomas de
decisiones más correctas posibles a partir de salidas como la correspondiente al 2º trimestre de este año y
que vemos en la figura 8.
Total Total
Delegación general % Parámetros considerados Del. general %
x 87 Total Municipios x 298
131690 Total RCs SIGCA 672446
135766 Total RCs SIGECA 747442
130020 95,77% Total CONJUNTA 660645 88,39%
128641 94,75% Total Coincide RC y Direcc. 650488 87,03%
Total Coincide RC, Dir y
95483 70,33% SSuelo 503373 67,35%
89619 66,01% Total Coinciden Todo 445793 59,64%
5864 4,32% Total Mal Sup. Constru. 57580 7,70%
33158 24,42% Total Mal Sup. Suelo 147115 19,68%
1379 1,02% Total Mal Dir. 10157 1,36%
x 105 Total Municipios x 352
300603 Total RCs SIGCA 215224
345449 Total RCs SIGECA 214076
285687 82,70% Total CONJUNTA 210896 98,51%
284090 82,24% Total Coincide RC y Direcc. 208586 97,44%
Total Coincide RC, Dir y
191829 55,53% SSuelo 158258 73,93%
178182 51,58% Total Coinciden Todo 152407 71,19%
13647 3,95% Total Mal Sup. Constru. 5851 2,73%
92261 26,71% Total Mal Sup. Suelo 50328 23,51%
1597 0,46% Total Mal Dir. 2310 1,08%
x 93 Total Municipios x 215
166488 Total RCs SIGCA 237483
172490 Total RCs SIGECA 237244
160141 92,84% Total CONJUNTA 231846 97,72%
159906 92,70% Total Coincide RC y Direcc. 207630 87,52%
Total Coincide RC, Dir y
134788 78,14% SSuelo 173223 73,01%
128788 74,66% Total Coinciden Todo 168329 70,95%
6000 3,48% Total Mal Sup. Constru. 4894 2,06%
25118 14,56% Total Mal Sup. Suelo 34407 14,50%
235 0,14% Total Mal Dir. 24216 10,21%
x 248 Total Municipios x 26
169385 Total RCs SIGCA 149026
168825 Total RCs SIGECA 149725
159386 94,41% Total CONJUNTA 148230 99,00%
134787 79,84% Total Coincide RC y Direcc. 141958 94,81%
Total Coincide RC, Dir y
104304 61,78% SSuelo 102406 68,40%
99128 58,72% Total Coinciden Todo 94549 63,15%
5176 3,07% Total Mal Sup. Constru. 7857 5,25%
30483 18,06% Total Mal Sup. Suelo 39552 26,42%
24599 14,57% Total Mal Dir. 6272 4,19%
Fig. 8 Ejemplo de salida de resultados del 2º trimestre de 2005 (urbana)
Se han establecido hasta tres niveles de corrección de los resultados del cruce, para, de una manera
secuencial, ir depurando los datos, esos tres niveles corresponden a los siguientes detalles:
• Nivel 1. Las diferencias entre Referencias Catastrales de ambas bases de datos superen el 10% y
el 20%.
• Nivel 2. El total de las Referencias Catastrales existentes en ambas bases de datos deberían
alcanzar valores cercanos al 100% una vez corregido el nivel 1.
• Nivel 3. Este nivel tiene en cuenta tres aspectos en el caso de la cartografía urbana: distinta
dirección, diferencia en la superficie construida y diferencia en la superficie de suelo, de los tres
este último y el primero son los responsables del 98% del total que no cruzan. En el caso de
rústica se considera únicamente el tercer aspecto.
Este tercer nivel a su vez se subdivide en dos
Nivel 3.1. Es un desarrollo del tercer aspecto del nivel 3, es decir de la discrepancia
entre el valor de la superficie de suelo entre SIGCA y SIGECA.
Nivel 3.2. es también el desarrollo del aspecto primero del nivel 3, diferencia de
direcciones entre SIGCA y SIGECA.
Un primer análisis de los niveles de control referidos al 2º trimestre proporciona las siguientes
consideraciones:
La cartografía está desactualizada en la mayoría de las delegaciones que superan el 10% en el
nivel 1, únicamente en un caso sucede lo contrario. Esto es debido a que se introducen actualizaciones en
SIGECA que no se contemplan en SIGCA simultáneamente, circunstancia que cada vez tiende a irse
eliminando al aplicar la metodología adecuada.
Profundizando en las causas de la falta de coincidencia entre Referencias Catastrales se llega a la
conclusión que la mayor parte de las mismas se deben a errores de escritura y/o a la diferencia temporal
con que se incluyeron los datos en SIGCA y en SIGECA.
Puesto que la Referencia Catastral es un dato unívoco de la parcela no deben existir parcelas idénticas
que tengan diferentes referencias en ambas bases de datos, para evitarlo se han desarrollado programas
que convierten y unifican las referencias una vez comprobadas las parcelas. Además de ser un campo
clave que permite georeferenciar cualquier cosa asociada a ello, que se ha exigido en IRPF, que es lo que
exigen entre otras cosas los Notarios y Registradores de la Propiedad, etc.
A través de Sigca2 se pueden realizar mapas temáticos del cruce, obteniendo resultados como el de la
figura9 y su simbología en la figura 10.
Con estos datos se lleva a cabo la averiguación de las causas de las discrepancias entre una base y otra
para una vez corregidas obtener la homogeneidad tanto en cantidad como en nombre entre SIGCA y
SIGEGA respecto a las Referencias Catastrales.
A continuación se procede a analizar las diferencias de superficies de suelo entre las BBDD,
estableciendo como se ve en la figura 8 unos tramos de diferencias expresados en porcentajes que
permiten visualizar en que zonas se producen las citadas diferencias. La mayor parte de las veces se debe
a la materialización de un desarrollo urbanístico que no se ha contemplado simultáneamente en ambas
bases, caso por ejemplo de una Unidad de Ejecución en un PGOU. En el caso de cartografía rústica la
causa puede proceder de una concentración parcelaria.
Respecto a la causa 3.2 exclusiva de la cartografía urbana la causa fundamental de las diferencias de
dirección proceden de errores de escritura y sobretodo a falta de actualización en la denominación de las
vías. En principio el Ayuntamiento correspondiente es el responsable del nombre y número de las vías, si
esas modificaciones no se comunican, no se manifiestan en SIGECA, en cambio si se ha llevado a cabo
una actualización cartográfica es posible que se introduzcan los nuevos nombres y de ahí que se
produzcan esas diferencias de dirección entre ambas bases de datos. Un ejemplo de los errores de
escritura lo muestra la figura 11.
Para controlar esas deficiencias además de otras posibles desigualdades entre las bases de datos se
dispone dentro del módulo de cruces de la opción de verificación geométrica, ver figura 12.
En la misma se puede controlar la coincidencia de los rótulos de las vías con los nombres de los ejes de
las mismas, así como la coincidencia de los ejes con el atributo de ejes en las parcelas y del atributo del
número de policía de estas con los rótulos de policía.
El resultado de salida son una serie de ficheros en formato hoja de cálculo además de unos resúmenes
indicando las cantidades de parcelas afectadas por las diferencias, un ejemplo es la figura 13.
Además de cuantificar los resultados se pueden visualizar para darse una idea de la ubicación de los
errores. En el caso de la figura 14 se muestran, en color verde, las parcelas en que su atributo de eje de vía
no coincide con el número asignado a la vía.
Por último un ejemplo compuesto de salida alfanumérica de información de parcelas con diferencias en
dirección.
MINISTERIO
DE HACIENDA
Dirección General del Catastro
SISTEMA DE ENTRADA,
ACTUALIZACIÓN Y
PUBLICACIÓN EN LA OVC
francisco.quintana@catastro.meh.es
MINISTERIO
DE HACIENDA
INTRODUCCIÓ
INTRODUCCIÓN
Dirección General del Catastro
MINISTERIO
DE HACIENDA
SIC
Dirección General del Catastro
Distribución geográfica
GERENCIAS
TERRITORIALES SS.CC
SIGCA
65 BDNC OVC
BDTC
SIGECA
MINISTERIO
DE HACIENDA
SIC: SUBSISTEMAS
Dirección General del Catastro
Consolidación titulares
Gestión y Mantenimiento, Gestión y Mantenimiento, Servicio Consulta y
con AEAT, Certificaciones
Valoración, Certificación, Certificación Descriptiva y Certificación, PADECA,
nacionales
Notificaciones, Informes Gráfica, Visualizador cartografía,
Intercambiador de datos
(Notarios, Registradores,
Ayuntamientos. Etc)
MINISTERIO
DE HACIENDA
ENTRADA DE DATOS
Dirección General del Catastro
Ciudadanos
PROVEEDORES CLIENTES y empresas
Titulares
catastrales
EELL
EELL
D. G. CATASTRO Administración
del Estado
Notarios y
Registradores
Notarios y
Registradores
AA..PP.
Juzgados Y
Tribunales
MINISTERIO
DE HACIENDA
ENTRADA DE DATOS
Dirección General del Catastro
– En el futuro … XML
MINISTERIO
DE HACIENDA
ENTRADA DE DATOS
Dirección General del Catastro
MINISTERIO
DE HACIENDA
ENTRADA DE DATOS
Dirección General del Catastro
DATOS PROCEDENTES DE :
Ö REVISIONES Ö RENOVACIONES
(URBANA) (RÚSTICA)
MINISTERIO
DE HACIENDA
ACTUALIZACIÓ
ACTUALIZACIÓN DE LA OVC
Dirección General del Catastro
BDNC
MINISTERIO
DE HACIENDA
SISTEMA DE ACTUALIZACIÓ
ACTUALIZACIÓN
Dirección General del Catastro
MINISTERIO
DE HACIENDA
SISTEMA DE ACTUALIZACIÓ
ACTUALIZACIÓN
Dirección General del Catastro
MINISTERIO
DE HACIENDA
OFICINA VIRTUAL DEL CATASTRO
Dirección General del Catastro
http://ovc.catastro.meh.es/
MINISTERIO OVC
DE HACIENDA
Dirección General del Catastro
Ö REQUISITOS ACCESO
– Servicios que requieran acreditación de la identidad
del usuario y la seguridad
MINISTERIO OVC
DE HACIENDA
Dirección General del Catastro
MINISTERIO
DE HACIENDA
SERVICIOS DE USUARIO
Dirección General del Catastro
MINISTERIO
DE HACIENDA
ACCESO A UN BIEN CATASTRAL
Dirección General del Catastro
MINISTERIO
DE HACIENDA
REPRESENTACIÓ
REPRESENTACIÓN SEGÚ
SEGÚN ESCALA
Dirección General del Catastro
MINISTERIO
DE HACIENDA
PIC
Dirección General del Catastro
MINISTERIO OVC
DE HACIENDA
Dirección General del Catastro
PIC
Resumen: La Dirección General del Catastro suministra como WMS (Web Map Service), y siguiendo las directrices y
normativa del OGC (Open Geoespatial Consortium) la información de la cartografía catastral que dispone en sus
bases de datos espaciales, en el ámbito territorial de su competencia, como un mapa continuo, con información
cartográfica catastral de zonas urbanas a escalas de captura 1:500 o 1:1.000 y cartografía catastral rústica a escalas
1:2.000 o 1:5.000. Como característica principal de este servicio es la continua actualización de los datos, que se
produce diariamente desde las distintas gerencias territoriales. Debido al volumen de información espacial y de detalle
y la agilidad de la actualización de los datos, este WMS se convierte en una base fundamental para un IDE
(Infraestructura de Datos Espaciales) que dé servicio a cualquier sector que necesite una base cartográfica nacional a
estas escalas.
INTRODUCCIÓN
El WMS es un servicio de publicación de la cartografía a través de Internet, sigue las directrices y normativa de OGC y
puede ser visualizada de forma libre y gratis por cualquier usuario que disponga de un visualizador que se ajuste a estos
estándares. Existen decenas de páginas Web que permiten consultar la cartografía de uno o varios servidores WMS o se
puede tener mayor funcionalidad descargando software SIG (Sistemas de Información Geográfica) de propósito general
que permite añadir los servidores WMS como una capa más de trabajo.
El servidor WMS del Catastro surge como consecuencia del desarrollo previo que se ha hecho para la OVC (Oficina
Virtual del Catastro) en la que se proporciona un visualizador de la cartografía catastral (Figura 1), basado en los
mismos principios que los estándares definidos en el OGC, suministrar una imagen en función de un ámbito de
coordenadas. Con esta experiencia el poder dar un servicio web que pueda ser explotado por distintas aplicaciones y
usuarios, solo requería estandarizarlo con las directrices OGC.
No hay que olvidar que la base fundamental de este servicio son los datos que se disponen de la cartografía catastral,
datos que se están incorporando y actualizando en formatos digitales desde finales de los años 80. Otro pilar
fundamental para poder suministrar este volumen tan importante de datos y su constante actualización, es el trabajo de
varios centenares de técnicos de las distintas gerencias territoriales que están actualizando diariamente la cartografía,
además de las distintas contrataciones externas de cartografía y los convenios con ayuntamientos, registradores y otros
organismos públicos. Toda la gestión catastral está soportada por la aplicación SIGCA2 (Sistema de Información
Geográfica Catastral), este SIG permite de forma muy rápida y sencilla realizar el mantenimiento diario dependiendo
de las distintas fuentes de datos: carga en formato FICC (Formato de Intercambio de Cartografía Catastral),
actualización masiva CU1 (Croquis de Urbana de plantas significativas) , cargas parciales, edición en línea,
digitalización, etc.(Figura 2).
El ámbito territorial sobre el que tiene competencias la Dirección General del Catastro es el de toda España,
exceptuando Navarra y el País Vasco que poseen su propio sistema catastral (Figura 3).
Las gerencias y subgerencias del catastro son las encargadas de realizar el trabajo de captura y mantenimiento de la
cartografía, son los responsables del dato, y en los Servicios Centrales diariamente se hace replica de todos los
movimientos y actualizaciones que se han producido en cada gerencia. Esta base de datos gráfica que está centralizada
en Madrid es la que sirve para publicar la cartografía, tanto en la Oficina Virtual del Catastro (OVC) como en el WMS.
Para poder apreciar el volumen de información que estamos tratando, a nivel puramente catastral , disponemos de más
de 41,7 millones de parcelas rústicas y 12,5 millones de parcelas urbanas, si a esto añadimos el resto de información
cartográfica asociado al grado de detalle de las escalas tanto a nivel de: atributos, toponimia, elementos lineales de
infraestructuras, mobiliario urbano, elementos puntuales, etc.
No solo a nivel de volumen de información sino también a nivel de actuaciones de mantenimiento y hablando en el
terreno catastral, por ejemplo en este último año se han actualizado en la cartografía más de 2 millones de parcelas.
Podemos considerar que en función del volumen de información y del grado de actualización que suministramos en este
WMS, es uno de los más importantes no solo a nivel nacional sino incluso a nivel internacional.
Las características específicas de los dos tipos de cartografía que estamos manejando están diferenciados básicamente
en la escala de captura y la tipología de cada elemento que se quiere representar.
Podemos diferenciar entre elementos cartográficos puramente catastrales y el resto de los elementos cartográficos
relativos a la información que debe aparecer a estas escalas (Figura 4).
La cartografía catastral rústica no llega al grado de detalle que la cartografía urbana debido a la escala de captura
utilizada. Además de las características propias de la cartografía rústica hay que incluir los elementos cartográficos de
parcelas y construcciones de urbana para el caso de los diseminados, que son parcelas de urbana enclavadas en suelo de
naturaleza rústica (Figura 5).
Es un único servicio de acceso libre y gratuito que proporciona en forma de mapa continuo toda la cartografía catastral
de la Dirección General del Catastro que se tiene en cada momento de forma actualizada en nuestras bases de datos
espaciales.
http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx
La simbología utilizada depende de la propiedad “transparent”, si está activa elimina el relleno de los elementos
catastrales que tienen una simbología de color en su máximo detalle a nivel de subparcelas o de construcciones urbanas
(Figura 6).
Solo se suministra una capa de información (layer), dependiendo del grado de detalle que se quiera representar (escala),
la información se jerarquiza para evitar el exceso de información en el ámbito de coordenadas solicitado (Figura 7). El
mayor grado de detalle e información que se llega a representar es cuando en la zona urbana alcanzamos la escala
1:1.000, en la cual reflejamos la información de los elementos lineales del mobiliario urbano. Los elementos puramente
catastrales se empiezan a representar en los siguientes rangos:
Cartografía rústica:
Polígonos < 1:50.000
Parcelas < 1:7.500
Subparcelas < 1:7.500
Cartografía urbana:
Manzanas < 1:15.000 y rótulos de manzana < 1: 5.000
Parcelas < 1:7.500 y rótulos de parcela < 1:2.500
Construcciones < 1:2.000 y rótulos de construcciones < 1:1.500
El request GETFEATUREINFO del servicio WMS proporciona información sobre la Referencia Catastral de la parcela
que se identifica. Este servicio devuelve un fichero html con la siguiente información:
La referencia catastral es un hipervínculo a la página de acceso libre de la Oficina Virtual del Catastro (Figura 8) en la
cual se muestran los bienes de una referencia catastral, a su vez esta página encamina a otras en las cuales podemos
obtener la impresión de croquis y datos o la navegación sobre la cartografía oficial de un mapa del municipio
seleccionado.
Otra de las características más notables de este servicio es la continua actualización de la información aportada.
Diariamente se recogen las modificaciones que se han realizado por los técnicos en cada gerencia, bien por la edición
en línea o por la carga. Esto representa una frescura de los datos que hace que el servicio proporcione un valor añadido
en una nueva dimensión, el tiempo. Este parámetro tiempo se incorpora como parámetro en el servicio y permite la
visualización de la cartografía a una fecha determinada (Figura 9), de esta forma podemos tener tantos servicios como
fechas (Figura 10) y ver la evolución de la cartografía catastral en: nuevas edificaciones, ensanches, infraestructuras,
paso de suelo rústico a urbano, etc.
Admite el parámetro:
Time=yyyy-mm-dd
INTEGRACIÓN EN IDE
Este servicio WMS que proporciona la Dirección General del Catastro entra a formar parte de otras iniciativas IDE a
nivel nacional. Por su volumen de datos, por su ámbito territorial, por su frescura en la actualización y por su nivel de
detalle (escala), puede servir de gran ayuda a multitud de sectores relacionados con los temas cartográficos que
demandan cartografías de detalle como las que podemos suministrar.
Para muchas utilidades evitaremos tener que hacer descargas de la cartografía y ploteados para cesiones o ventas, ya
que la información queda obsoleta en el momento que se suministra, un servicio en línea con los datos continuamente
actualizados es más que suficiente para muchas necesidades e imprescindible para otras donde necesitemos una
cartografía actualizada.
CONCLUSIONES
La Dirección General del Catastro con este servicio libre y gratuito se suma a las iniciativas IDEE siguiendo las
directrices internacionales de estandarización dentro de OGC.
La incorporación a estas iniciativas repercute en un mejor servicio al ciudadano, apoyándose en las nuevas tecnologías
de la información: Internet y servicios web.
El WMS del catastro proporciona como ventajas:
• Cartografía básica y catastral a grandes escalas desde 1:500 a 1:5.000
• Cartografía continua y homogénea de urbana y rústica
• Actualización diaria
• Servicio de Cartografía histórica
• Ahorro de descargas y ploteados
El apostar por iniciativas de este tipo en que se siguen estándares, se implican distintos organismos públicos y privados
y de distinta y variada temática, ayuda a evitar duplicidades de información, a la homogeneización de los datos y a
mejorar la calidad de los mismos.
REFERENCIAS
35
Newsletter IDE Iberoamérica Sesión 2
Alvarez, Mabel 1
Gonzalez, María Ester2
Universidad Nacional de la Patagonia San Juan Bosco (Argentina), mablop@speedy.com.ar 1,
Universidad Nacional de la Patagonia San Juan Bosco (Argentina), geoester@yahoo.com.ar2
Resumen: Las Infraestructuras de Datos Espaciales (IDEs) se están desarrollando con distinto alcance según las
posibilidades y oportunidades de cada región. La Asociación denominada Infraestructura Global de Datos Espaciales
(GSDI) con el objeto de promover y apoyar el desarrollo de las IDEs, otorgó 10 Grants en el año 2004
correspondiendo los mismos a 10 proyectos, seleccionados entre 70 propuestas presentadas.
El presente trabajo refiere a uno de los proyectos del Grant 2004, cuyo objetivo es producir y distribuir un Newsletter
sobre IDEs en español. Aquí se describen:
- Los objetivos que movilizaron a una red humana proveniente de instituciones de Argentina y de España, a proponer
la producción y distribución de un Newsletter sobre IDEs en español;
- las acciones realizadas por miembros de las instituciones participantes para la producción del Boletín denominado:
IDE Iberoamérica;
- el modo en que se instrumenta la distribución del Newsletter y las apreciaciones que emergen a partir de suscriptores
del mismo.
Por último se presenta el modo en que se pretende continuar con el Newsletter IDE Iberoamérica, a partir de la semilla
inicial sembrada a través del Grant concedido.
Iberoamérica comprende a los países que nacieron a partir de España y Portugal como así también las respectivas
naciones de origen. En consecuencia Iberoamérica está integrada por: Argentina, Bolivia, Brasil, Colombia, Costa Rica,
Cuba, Chile, Ecuador, El Salvador, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, República
Dominicana, Uruguay, Venezuela, Puerto Rico, España y Portugal
A los países de Iberoamérica los une una herencia cultural que se manifiesta en múltiples órdenes de la vida.
Las lenguas de Iberoamérica son el español de castilla y el portugués, las cuales guardan la similitud suficiente para que
dos personas hablando cada uno su lengua puedan comunicarse básicamente. El mayor número de países de
Iberoamérica habla castellano, pero son significativas las diferencias de vocablos, expresiones idiomáticas y
significados entre unos y otros. Hay notorias diferencias en el habla castellana, lo que sin duda se refleja en las IDEs. El
contexto antes descrito es indicativo de la necesidad de construir definiciones comunes en materia de Información
Geográfica para la implementación de las IDEs.
De las experiencias que se van realizando para la construcción de las IDEs dentro de algunos países de Iberoamérica,
puede apreciarse que la construcción de definiciones comunes requiere un laborioso proceso de análisis y consenso.
Ahora bien los resultados de este consenso y la difusión de sus resultados van generando los avances del caso para el
desarrollo de futuros tesauros.
La amplia producción de material sobre IDEs en inglés y la dificultad real que aún muchas personas tienen con este
idioma, hacen que todos los esfuerzos que se realicen en traducción de materiales a la lengua castellana y la difusión y
comunicación que de los mismos se haga, constituyen mecanismos simples para contribuir al desarrollo de las IDEs.
A modo de ejemplo, el esfuerzo que realiza actualmente la Infraestructura de Datos Espaciales de España (IDEE) con
relación a las normas ISO, la disponibilidad del núcleo español de metadatos y la convocatoria a personas interesadas
para contribuir a la traducción al castellano de las normas ISO, son acciones que posibilitan la interacción directa entre
personas en materia de IDEs en Iberoamérica.
Ahora bien, las Tecnologías de la Información y las Comunicaciones (TICs) no están aún disponibles para muchos
sectores, que podrían estar contribuyendo al mundo de las IDEs. Asimismo muchas personas que se desenvuelven en
torno a la Información Geográfica no tienen acceso a Internet, ni en su lugar de trabajo ni en su casa.
Las limitaciones actuales respecto al acceso a las TICs, vistas en consonancia con los objetivos de la Sociedad de la
Información, indican una tendencia de superación progresiva de la brecha digital y cada vez mayores posibilidades de
acceso a estas tecnologías, lo que facilitará la comunicación.
Los aspectos previamente descritos en este título han sido parte de las motivaciones para impulsar un Newletter sobre
IDEs para Iberoamérica.
Las principales actividades realizadas para la concreción del Newsletter consistieron en:
Preparación de un Proyecto para ser presentado a la Convocatoria de subvenciones 2004 de Global Spatial Data
Infrastructure (GSDI) [1] entre instituciones de Argentina y España, entre las que cuales cabe mencionar a la
Universidad Nacional de la Patagonia San Juan Bosco (UNPSJB) [2] de Argentina y a la Universidad Politécnica de
Madrid (UPM) [3] de España, siendo la institución de contacto el Consejo Federal del Catastro de Argentina.
Una vez comunicada la selección del proyecto, se realizaron las acciones que se describen en los títulos:
A este fin se tomaron en consideración referentes de instituciones académicas, del sector público, de instituciones no
gubernamentales, del sector privado y ciudadanos en general, a quienes se los conoce o se tiene referencia respecto al
interés en la temática IDEs.
Asimismo, se estableció contacto con administradores de Listas de Distribución, Responsables de Departamentos de
Universidades y de Asociaciones Profesionales, quienes se comprometieron a la distribución del Newsletter a través de
sus propias listas internas u otros medios.
En Latinoamérica se estableció comunicación con referentes conocidos, en su mayoría a través del Comité Permanente
para la Infraestructura de Datos Espaciales de las Américas (CP IDEA) [4].
Una vez definida la lista inicial de contactos, para la distribución del Newsletter, la misma se fue incrementando mes a
mes por diversas vías, principalmente a través de solicitudes directas de interesados realizadas al correo de contacto del
Newsletter.
A continuación se detalla el formato del Newsletter explicando bajo cada uno de sus títulos el alcance de los mismos:
Se destacan bajo este título: El origen del Newsletter, a través de una subvención otorgada por la Asociación “Global
Spatial Data Infrastructure (GSDI)”, las características de la publicación y la convocatoria a interesados en la recepción
de la publicación y en el envío de anuncios y comentarios, como así también la forma de contacto con el editor, de
modo de establecer un camino sencillo para introducir mejoras en la publicación a partir de las sugerencias de los
lectores. A continuación se transcriben estos aspectos tal como aparecen en el Newsletter.
BB
El Newsletter: Infraestructura de Datos Espaciales IDE- Si desea enviar información, anuncios, o comentarios
Iberoamérica forma parte de las actividades de un Proyecto relacionados a Infraestructura de Datos Espaciales (IDE),
presentado al “GSDI Small Grants Program 2004” ante Sistemas de Información Territorial, teledetección, SIG y
“Global Spatial Data Infrastructure (GSDI) Association”. gestión del territorio, para su publicación en el Newsletter,
por favor remítalas a cfc-catastro@speedy.com.ar o
Es una publicación electrónica mensual de libre distribución mablop@speedy.com.ar
para personas interesadas en las Infraestructuras de Datos
Espaciales y temas afines. Si considera que este Newsletter puede ser de utilidad a
otras personas, reenvíelo y sugiera que los interesados se
Las opiniones contenidas en el Newsletter constituyen suscriban para recibirlo mensualmente.
responsabilidad exclusiva de sus autores.
Si no desea recibir este Newsletter envíe un mensaje a
cfc-catastro@speedy.com.ar o mablop@speedy.com.ar
con el asunto remover.
C
Colaboradores en este número
Se detallan aquí los colaboradores directos en cada número del Newsletter y su procedencia institucional. Por ejemplo:
“Colaboraron en este número: la Agrim. Patricia Villafañe del Consejo Federal del Catastro de Argentina, el Dr. Diego Erba del
Lincoln Institute of Land Policy de los Estados Unidos y la Lic. María Ester González de la Universidad Nacional de la Patagonia
San Juan Bosco (Argentina)”.
Bajo este título se tratan aspectos tales como: breves artículos que provee el organizador de un evento previo a la
ejecución del mismo. Reseña de las conclusiones de un evento que tuvo lugar recientemente, enviado por algún
miembro de la coordinación o participante del mismo.
Se trata asimismo de generar relaciones entre instituciones y personas, de diferentes procedencias, estableciendo los
correspondientes vínculos. Asimismo se transcriben noticias de interés para el ámbito multidisciplinar de las IDEs.
Capacitación, otros
Conferencias, Eventos
Febrero 2006
7 -9 Febrero 2006 New Delhi, India Map India 2005 -
http://www.mapindia.org/2005/
15 Febrero 2006 Cartagena, XII SIMPOSIO INTERNACIONAL SELPER: SIG y Percepción Remota
Colombia aplicados a “Riesgos Naturales y Gestión del Territorio”
Contacto: info@selper.org.co
27 Febrero 2006 The Netherlands GIS Tech 2005 –Rotterdam
http://www.gistech.nl/
Abril 2006
23-26 Abril 2006 Tampa, La conferencia anual y la exposición de GITA. Tecnologías de información
La Florida geospatial.
E.E.U.U. Teléfono: 303-337-0513 fax: 303-337-1001
Contacto: info@gita.org
Mayo 2006
1-5 Mayo 2006 Reno, Nevada Prospección para la integración de la información de Geospatial
www.asprs.org/reno2006
Contacto: akinerney@asprs.org
Junio 2006
Junio 2006 Buenos Aires, Tercer Congreso de la Ciencia Cartográfica y X semana Nacional de la
Argentina Cartografía
Septiembre 2006
19 - 22 Septiembre La Habana, II Simposio Internacional sobre Transferencias Tecnológicas Tecnotransfer
2006 Cuba 2006
24 - 29 Septiembre Cartagena, El XII Simposio Internacional SELPER: SIG y Percepción Remota aplicados
2006 Colombia. a “Riesgos Naturales y Gestión del Territorio”
Contacto: info@selper.org.co
Octubre 2006
9-13 Octubre 2006 Santiago, Chile 9 Conferencia Internacional de Infraestructura Global de Datos
Geoespaciales, organizado por GSDI (Global Spatial Data Infrastructure) e
Instituto Geográfico Militar de Chile.
Contacto gsdi9@igm.cl
15-20 Octubre 2006 Munich, FIG Congress http://www.fig2006.de
Alemania
EXPERIENCIAS RECOGIDAS
Se han editado durante el año 2005 10 boletines. Mensualmente se reciben pedidos de nuevos interesados que requieren
que se les envíe el Newsletter a su correo. Los solicitantes provienen de diversos ámbitos destacándose el sector
académico, entes no gubernamentales (tales como colegios, consejos y asociaciones profesionales), sector público y
ciudadanos.
Con cierta frecuencia se reciben opiniones, destacando la iniciativa del Newsletter y lo que la misma contribuye.
Para muchos las IDEs siguen siendo un concepto un tanto abstracto que no lo vinculan directamente a sus profesiones ni
a sus ámbitos directos de acción. Es decir, si bien la Información Geográfica es parte central de su quehacer profesional,
al no estar en sus planes poner en operación una IDE, esta temática es considerada como un aspecto fuera de su interés
y competencia.
A través de los sucesivos números del Newsletter y, como si fuese una envolvente, se ha tratado de ir abarcando durante
2005 diversas temáticas interdisciplinares de Información Geográfica, nucleándolas bajo el gran paraguas de las IDEsS,
de modo de responder a posibles intereses de una amplia comunidad de personas.
En diciembre 2005 concluye la subvención de GSDI, por lo tanto se han considerado a lo largo del presente año
alternativas para la dar continuidad al Newsletter, concluyéndose que a partir de enero 2006, el Newsletter IDE
Iberoamérica continuará su edición a través de una acción colaborativa entre algunas de las Instituciones que formaron
parte de su primer año de existencia.
La figura precedente, enuncia de izquierda a derecha a las dos Universidades que contribuirán esencialmente a la
edición del Newsletter, siendo las mismas la Universidad Politécnica de Madrid y la Universidad Nacional de la
Patagonia San Juan Bosco; la primera participará a través del Laboratorio de Tecnologías de la Información Geográfica,
adscrito a la Escuela Técnica Superior de Ingeniería en Topografía, Geodesia y Cartografía y la Universidad Nacional
de la Patagonia San Juan Bosco, lo hará a través de la Facultad de Humanidades y Ciencias Sociales y del Instituto de
Investigaciones Geográficas de la Patagonia (IGEOPAT). Asimismo se contará con la colaboración del Consejo Federal
del Catastro de Argentina.
Cabe destacar que entre las dos Universidades citadas existen los siguientes proyectos de colaboración en curso,
vinculados estrechamente al campo de las IDEs:
• Proyecto de Programa de Doctorado: “Geoinformación para el gobierno y la sociedad”, financiado por la
Agencia Española de Cooperación Internacional. Uno de los objetivos de dicho proyecto contempla fomentar
la cooperación universitaria entre las Universidades de la Patagonia y Politécnica de Madrid, en cuestiones
relacionadas con la Información Geográfica para usos gubernamentales y sociales. En el contexto de dicho
objetivo la continuidad del Newsletter es una acción concreta.
• El proyecto titulado: “Ayuda a la dotación de una infraestructura para impartir el Curso de Doctorado
“Geoinformación para el gobierno y la sociedad” a través de VideoConferencia” financiado por la
Universidad Politécnica de Madrid.
La continuidad de la edición del Newsletter será posible a través de las acciones que se ejecutan en el Laboratorio de
Tecnologías de la Información Geográfica de la Universidad Politécnica de Madrid, creado por medio de un Convenio
de Colaboración con el Instituto Geográfico Nacional (IGN) [5] de España, el 12 de noviembre de 2004.
En la exposición de motivos que dio lugar al Convenio las partes expresaron: “Que este acuerdo será positivo tanto
para el desarrollo de las actividades propias de las instituciones firmantes como para el acercamiento a la sociedad y a
otras instituciones (de ámbito local, autonómico, nacional e internacional) que en la actualidad están desarrollando o
van a desarrollar actividades relacionadas con las Tecnologías de la Información Geográfica”.
Asimismo sus cláusulas primera y segunda expresan:
Cláusula primera: “El objeto es colaborar estrechamente en proyectos de investigación y desarrollo, formación y
difusión de conocimientos en el campo de las Tecnologías de las Información Geográfica (TIG) y otros afines”.
A modo de una breve síntesis sobre la región puede decirse que: Iberoamérica, vista como un conjunto, está logrando
progresivos avances en materia de IDEs en los últimos años; no obstante hay diferencias significativas de un lugar a
otro.
Los avances que se esperan en materia de TICs a través de la reducción de la brecha digital, a través del compromiso de
los gobiernos en el desarrollo de la Sociedad de la Información, sin duda facilitarán los medios para que cada vez más
personas puedan acercarse al mundo de las IDEs y a sus beneficios.
La herencia cultural y la existencia de tan sólo dos lenguas en Iberoamérica es una notable ventaja. No obstante las
diferencias dentro de la misma lengua, entre países y aún dentro de un mismo país, son aspectos necesarios de atender
para construir progresivamente los pasos necesarios para las IDEs.
La experiencia recogida durante la edición del Newsletter y la factibilidad de dar continuar a su edición, han sido
motivo de reflexión respecto a las principales características de la publicación para la nueva etapa:
Las mismas pueden resumirse en:
• Complementariedad entre los boletines IDE Iberoamérica e IDE –LAC (Latinoamérica y Caribe) que edita el
Instituto Panamericano de Geografía e Historia (IPGH) [6] a través del trabajo coordinado entre los editores de
ambos boletines.
• Dado que entre dos universidades se asumirá en gran medida el liderazgo del Newsletter, los temas
relacionados a la Información Geográfica y a las IDEs serán tomados en consideración por ambas partes.
Puesto que el proyecto de Programa de Doctorado: “Geoinformación para el gobierno y la sociedad” es una
acción conjunta de ambas universidades, y que el mismo se plantea bajo la modalidad de e-learning, los
aspectos de educación vinculados a los procesos de enseñanza –aprendizaje a través de la Web y tecnologías
asociadas, serán temas a incluir en la nueva etapa.
• Los programas de grado de Ingeniero Técnico en Topografía y de Ingeniero en Geodesia y Cartografía y el
Doctorado en Ingeniería Geográfica, que se imparten actualmente en la UPM, como asimismo los aspectos
tecnológicos de las IDEs respecto a los cuales se, investigación, desarrollo, docencia y transferencia de
tecnología, serán motivo de consideración a través del Newsletter.
• Las carreras de grado de: Licenciatura en Geografía, Profesorado en Geografía y Tecnicatura en Sistemas de
Información Geográfica y Teledetección, que actualmente se dictan en la Universidad Nacional de la
Patagonia San Juan Bosco, constituyen asimismo objetivos a atender a través del Newsletter.
• Los Aspectos concernientes al Catastro, Administración de Tierras, Ordenamiento Territorial, de amplia
repercusión actual en Iberoamérica, serán asimismo objeto de consideración en el Newsletter, máxime siendo
el Consejo Federal del Catastro de Argentina colaborador de esta iniciativa.
CONSIDERACIONES FINALES
1 Agradecimientos:
• A GSDI, por haber hecho posible la existencia del Newsletter IDE Iberoamérica.
• A los colaboradores que mes a mes han generado sus aportaciones en pro de las IDEs, a través de sus
contribuciones al Newsletter.
• A las instituciones que, mediante acciones colaborativas, harán posible que el Newsletter continúe su edición.
La edición del Newsletter ha permitido llegar desde enero de 2005 a una considerable comunidad de interesados,
abordando diversos temas vinculados a las IDEs de orden interdisciplinar; la recepción de apreciaciones positivas por
parte de lectores ha contribuido a la búsqueda de medios para continuar la edición.
La continuidad del Newsletter a partir de 2006, se realizará a través de la acción conjunta del Laboratorio de
Tecnologías de la Información Geográfica de la Universidad Politécnica de Madrid y de la Universidad Nacional de la
Patagonia San Juan Bosco, esta última a través de la Facultad de Humanidades y Ciencias Sociales y del Instituto de
Investigaciones Geográficas de la Patagonia, contando asimismo con la colaboración del Consejo Federal del Catastro
de Argentina.
• Atención a las temáticas relacionadas a IDEs, vinculadas a los programas de grado y posgrado de las
Universidades que liderarán la iniciativa, como así también a sus acciones conjuntas.
• Inclusión de temas de educación vinculados a las IDEs y a los procesos de enseñanza –aprendizaje a través de
la Web y tecnologías asociadas, potenciando la educación a distancia en materia de IDEs y disciplinas afines,
para Iberoamérica.
• Atención de temas, relativos a los objetivos emergentes del Convenio de Colaboración con el IGN, en el caso
particular del Laboratorio de Tecnologías de la Información Geográfica de la UPM.
REFERENCIAS
Reumen: El nuevo paradigma IDE supone una nueva forma de trabajar en el campo de la IG, radicalmente distinta,
basada en la interoperabilidad de sistemas, el compartir recursos y la globalización que supone la utilización de
clientes ligeros que consumen pocos recursos para explotar las posibilidades de esta tecnología. La nueva galaxia de
ideas que ello implica, nos exige un fuerte cambio de mentalidad y punto de vista y nos plantea un conjunto de
posibilidades y escenarios antes impensables. Ante esta situación es necesario plantear cuál es el rol apropiado para
cada uno de los actores relacionados con la IG: cartógrafos, productores de software, empresa privada en general,
universidad, administración, etcétera. Todo ello como consecuencia de los cambios que supone el impacto de la
globalización en todos los sectores y aspectos de nuestra sociedad.
INTRODUCCIÓN
Después del devastador paso del huracán Katrina por el mar Caribe, Méjico, Cuba y Estados Unidos, y muy
especialmente por Nueva Orleáns, con sus terribles consecuencias, han aparecido una serie de fenómenos en la Red,
también asombrosos y espectaculares aunque, afortunadamente, no tan dañinos y desoladores. Google Earth nos ofrecía
acceso visual a una gran cantidad de imágenes de la superficie de la Tierra, imágenes que simulaban cubrir toda su
superficie, permitía un sobrevuelo espectacular sobre la manzana de nuestra casa y, lo que es más importante, ofrecía
toda esa información para la implementación de servicios y utilidades de valor añadido, si bien desoyendo todos los
estándares al uso, permitiendo la aparición de un servicio electrónico con el que un ciudadano de Nueva Orleáns podía
averiguar si su casa estaba cubierta o no por el agua.
Las consecuencias tecnológicas de la revolución que ha supuesto la aparición de Internet, de la mano de Tim Berners-
Lee en 1991, y de la consecuente globalización, con la aparición de la Infosfera, parecen haber llegado por fin, dejando
sentir sus consecuencias con toda fuerza, al mundo de la Información Geográfica. Un sector de actividad al que arriban
todas las revoluciones tecnológicas con notable retraso (la normalización, la calidad, la documentación, las
ontologías,…) debido probablemente a la inercia que suponen los largos procesos de producción inherentes a la
cartografía y a las enormes masas de datos implicadas.
Está empezando a ser posible buscar, localizar, visualizar y combinar en la Red recursos relacionados con la
Información Geográfica (IG) con una facilidad y potencia nunca vistas hasta ahora, ofreciendo funcionalidades y
abriendo posibilidades tales, que han transformado nuestro sector de actividad y nuestra manera de trabajar hasta
hacerlos irreconocibles. El gabinete del cartógrafo nunca volverá a ser lo que era antes.
UN NUEVO PARADIGMA
Tras las revoluciones conceptuales que supusieron la aparición del mapa, pensado para ser leído e interpretado por el
ojo humano, y el advenimiento de los Sistemas de Información Geográfica (SIG), concebidos para ser consultados a
través de un terminal, llega el mundo de las Infraestructuras de Datos Espaciales (IDE) como consecuencia del impacto
conceptual generado por la aparición de Internet, gracias al impulso que supuso la Orden Ejecutiva del presidente Bill
Clinton (USA) en 1994 para implementar la IDE nacional de aquel país, y como aplicación de las especificaciones de
interoperabilidad de sistemas definidas por Open Geospatial Consortium (OGC).
Una IDE no es nada más, y nada menos, que un SIG implementado sobre la Red, con todo lo que ello conlleva y
significa. No se trata, por lo tanto, de que el usuario pueda realizar una mera conexión a un SIG a través de Internet para
explotar en remoto el mismo sistema que puede tener disponible en una estación de trabajo. Más bien se trata de que el
usuario pueda mediante un simple navegador, un cliente ligero, buscar qué datos geográficos y qué servicios hay
disponibles en la Red, seleccionar cuales son de su interés, visualizar los datos seleccionados e invocar el servicio o
servicios necesarios (de visualización, de acceso a objetos, de nomenclátor, de transformación de coordenadas,…) para
satisfacer sus necesidades de información y obtener las respuestas deseadas, de modo transparente y sin preocuparse de
en qué nodo reside cada componente. Todo ello con unos conocimientos tecnológicos mínimos y con una inversión de
recursos francamente moderada, lo que supone una ampliación muy notable del universo de usuarios potenciales de la
IG.
Esta dinámica de trabajo parece haber hecho que tanto el mapa como los SIG queden obsoletos como tecnologías. Si
bien se van a seguir utilizando, y en muchas situaciones el mapa o el SIG serán probablemente la solución más
adecuada, en general creemos que puede decirse que para resolver cualquier problema de demanda de IG, es necesario
hoy en día sopesar la solución IDE junto a las anteriores, y desde luego es la solución más avanzada.
Opinamos que la revolución que suponen las IDE constituye un cambio de paradigma en el sentido de Thomas S. Khun
(1), porque introduce un conjunto de conceptos, ideas, supuestos básicos y reglas de juego completamente nuevos, y
porque es necesario olvidar los anteriores para poder trabajar con eficacia de un modo diferente. Efectivamente ahora
los recursos se publican y comparten en Internet; el concepto básico alrededor del que se estructuran los sistemas es el
de servicio; la interoperabilidad de sistemas es la base sobre la que se opera; el actor IDE ha de plantearse qué puedo
ofrecer en lugar de qué puedo obtener, la demanda social es más significativa que la demanda del individuo, hemos
pasado del SIG para nosotros a la IDE para todos; y , lo que nos parece más importante, la mera transferencia de datos,
con todos los problemas técnicos y legales que supone, ha perdido mucho sentido, cuando lo realmente útil es disponer
de acceso a la información y a las funcionalidades requeridas, obtener las respuestas finales y no datos geográficos
intermedios.
Lo realmente novedoso es, en suma, la posibilidad de acceder a un sistema virtual integrado por el conjunto de servicios
IDE disponibles en la Red, para satisfacer una demanda de información visualizando, superponiendo y analizando los
datos geográficos accesibles. El que ese acceso pueda realizarlo una aplicación que cumpla unos requisitos y protocolos
simples, o un usuario con un cliente ligero, completan el panorama de actuación.
UN MUNDO DE POSIBILIDADES
Como ya hemos dicho, una IDE es un SIG implementado sobre la Red, es decir basado en la interoperabilidad de
múltiples recursos y servicios públicos, accesibles en Internet, con todas las consecuencias que implica desplazar la
plataforma sobre la que se asienta el sistema hasta la Infosfera. Esta nueva situación soluciona o, al menos alivia,
muchos de los problemas que presentaban los componentes de un proyecto SIG: los datos geográficos se pueden
compartir, el software es menos costoso y presenta interfaces más amigables, y los servicios son utilizables por usuarios
sin necesidad de formación previa. Más concretamente, un amplio abanico de posibilidades técnicas y de negocio se
abre ante nosotros.
Saber ver
No hay que menospreciar las posibilidades que ofrece la especificación OGC más sencilla, y también la más utilizada
hasta ahora, el Web Map Service (WMS) o Servicio de Mapas en la Red (2), que permite visualizar ficheros vectoriales
y ráster y construir clientes de visualización capaces de superponer y visualizar conjuntamente datos geográficos de
distinta procedencia, formato y sistema de coordenadas. La simple visualización pone delante de nuestros ojos,
poderoso instrumento de análisis, la Información Geográfica y nos permite el análisis y percepción de multitud de
aspectos y relaciones entre los fenómenos, extendiendo el antiguo proceso de lectura de mapas a una lectura en pantalla
de vectores, mapas, ortofotos y ficheros de todo tipo, que pueden ofrecer la posibilidad de comprender y relacionar
multitud de conceptos. No en vano el lema del genial Leonardo era “saber ver” y la mirada inteligente extrae
rápidamente información significativa de enormes volúmenes de datos.
Por otro lado la superposición de conjuntos de datos geográficos, permite compararlos visual y métricamente, lo que
hace posible el efectuar controles de calidad y determinar algunos parámetros como la exactitud posicional, la
compleción o la exactitud semántica de manera muy ágil.
Como ya hemos dicho, las reglas del juego han cambiado, y el primer problema a la hora de implementar un SIG,
conseguir importar los datos e integrarlos en el modelo y el sistema del usuario, ha desaparecido, o por lo menos se ha
transformado radicalmente. Todos los problemas de adquisición de datos externos, licencias de uso, cambios de
formato, mapeo de modelos, etcétera, pueden desaparecer en muchos casos si el usuario localiza un servicio WFS (Web
Feature Service o Servicio de Fenómenos en la Red) si desea datos vectoriales (3) o un servicio WCS (Web Coverage
Service o Servicio de Coberturas en la Red) si necesita datos ráster (4). Un servicio estable y continuo en el tiempo, que
le permita acceder a todos los atributos de los fenómenos que necesita analizar, e implementar servicios de consulta y
análisis espacial sobre WFS y WCS para satisfacer sus necesidades.
De tal modo, en principio no tiene porqué ser siempre necesario conseguir los datos y uno de los puntos débiles de los
SIG, la escasez y pobre usabilidad de la IG, puede disolverse como por ensalmo, y como consecuencia, quizás la IG
comience realmente a reutilizarse. En lugar de meter los datos en nuestro SIG, la solución a muchos problemas puede
ser abrir el sistema a todos los datos que hay en la Red.
Por otro lado, si los servicios de análisis desarrollados por el usuario, quizás un Rutómetro o tal vez una utilidad de
Solape (overlay) o de generación de Orlas (buffers), cumplen además algunos estándares, en particular la futura
especificación OGC Web Processing Service (WPS) (5) e ISO 19119 sobre Servicios (6), se convierten a su vez en
servicios interoperables, que pueden ser invocados y encadenados con otros servicios para implementar nuevas
funcionalidades. Como explica la misma norma: ”Esta Norma Internacional proporciona a los desarrolladores un marco
de referencia para generar software que permita a los usuarios acceder y procesar IG de una amplia variedad de fuentes
a través de una interfaz genérica y dentro de un entorno tecnológico de sistemas abiertos.” (Traducción libre).
En suma ambos componentes de un SIG, datos y aplicaciones (servicios), pueden comenzar real y efectivamente a
reutilizarse, lo que abriría nuevos horizontes de actuación y crearía una excitante atmósfera de cooperación y sinergia.
En el mundo IDE, hay dos posibilidades para disponer de funcionalidad de análisis SIG aprovechando los servicios de
acceso y consulta públicos y disponibles, disponer de un cliente SIG pesado y utilizar un cliente ligero.
El cliente pesado sería una aplicación que correría en el ordenador del usuario para proporcionar las funcionalidades de
consulta y análisis SIG habituales, accediendo a datos remotos a través de WFS y WCS. Tiene muchas ventajas: mayor
integración de las distintas funcionalidades en un mismo entorno; la interfaz puede ser más eficaz; es posible optimizar
el rendimiento; se puede incluir un entorno de desarrollo cómodo y potente. El único inconveniente es que es necesario
instalar un software en el ordenador cliente, o lo que es lo mismo, que se globalizan los datos pero no tanto las
aplicaciones y que las utilidades de consulta y análisis del sistema no se convierten en servicios públicos que se ofrecen
y se reutilizan libremente en la Red. Es necesario instalar la aplicación SIG en cuestión para acceder a la funcionalidad
deseada.
La alternativa es mantener al máximo la filosofía del cliente ligero, el que sólo sea necesario un navegador, un simple
browser para buscar, localizar y utilizar los datos y los servicios públicos que el usuario precisa en cada momento, y si
el usuario necesita una funcionalidad nueva o mejorada, puede implementarla a su vez en forma de servicio estándar,
público y disponible para que otros lo utilicen. Llevando esta filosofía al extremo, sería necesario disponer de un
entorno de trabajo, disponible en un geoportal público, que permitiera buscar servicios e integrarlos en una interfaz
común de trabajo, definir una configuración de utilización de servicios concreta, lo que se denomina un cliente
integrado, y guardar los parámetros de esa configuración para sesiones posteriores. De esta manera sería más cómodo,
más eficiente y usable, la integración de datos y servicios públicos en un sistema virtual.
Ambas opciones son válidas y dependiendo de cada situación, capacidad de desarrollo, posibilidades de crecimiento
rápido del sistema, recursos disponibles, y sobre todo del desarrollo de las tecnologías IDE, actualmente todavía
incipientes, una u otra pueden resultar preferibles. En cualquier caso, creemos que ambas posibilidades no constituyen
alternativas excluyentes ni en competición, sino aproximaciones que se complementan y que a menudo, será necesario
implementar en sistemas mixtos, clientes semipesados.
Por supuesto, en cualquiera de las dos situaciones, se podrían también analizar datos almacenados localmente, y sería
posible además combinarlos con datos remotos para visualizarlos conjuntamente o realizar análisis combinados.
Generación de hipertextos
El Servicio de Nomenclátor (Gazetteer) (7), ofrece la posibilidad de buscar un topónimo, con las opciones que ya nos
son familiares de nombre exacto, comenzando por, etcétera, y encontrar unas coordenadas de situación. Ésta es la
manera más natural para el usuario final de entrada a la IG, la forma más eficaz de indexación, porque no siempre se
conoce el número de hoja de una cartografía o el nombre del Municipio dónde se encuentran los datos que se desea ver
o analizar. Este servicio tendría otras utilidades añadidas, como corregir los nombres geográficos almacenados en un
sistema por comparación con un Gazetteer de mayor fiabilidad, determinar la exactitud semántica de los topónimos
almacenados en un SIG o en una tabla, normalizar los nombre utilizados en una aplicación utilizando un Nomenclátor
de referencia, etcétera.
Pero en el campo de los topónimos, la tecnología IDE ofrece otras posibilidades muy interesantes. Una de ellas es la de
Geoparser (8), algo así como servicio de escaneado geográfico de textos, que permite recorrer un texto digital palabra a
palabra, compararlo con los nombres geográficos almacenados en un Nomenclátor especificado por el usuario, y
obtener un vínculo entre cada nombre geográfico que aparece en el texto y la entrada correspondiente en el
Nomenclátor utilizado; con lo cual toda la información ligada a ese fenómeno geográfico queda vinculada y es accesible
desde la palabra encontrada en el texto. Sería posible entonces, con un servicio de este tipo y dado un Nomenclátor
suficientemente rico y fiable, la creación automática de hipertextos geográficos.
WFS Transaccional
El Servicio de Fenómenos en la Red (WFS) no sólo permite consultar qué atributos tiene un fenómeno, efectuar análisis
en función de esos atributos y descargar los datos que estamos consultando, sino que además ofrece una variedad muy
interesante, el Servicio Transaccional de Fenómenos en Red (WFS-T), cuya razón de ser es permitir que el usuario
modifique los atributos de los fenómenos y consolide sus resultados en los datos originales; en suma: la actualización
en remoto. Esta funcionalidad ofrece posibilidades muy interesantes para la implementación de flujos de trabajo
(workflow) en Intranet abaratando costes, y para la actualización de datos desde oficinas, puestos distribuidos
espacialmente o en tiempo real durante trabajos de campo si se dispone de un PDA.
La especificación OGC de Servicio de Acceso a Datos Geoenlazados (Geolinked Data Access Service, GDAS) (9) pone
a disposición del usuario el acceso estandarizado a datos tabulares de atributos alfanuméricos geolinkados, es decir con
un atributo de enlace que sirve de referencia espacial, típicamente el código INE para municipios o provincias, lo que
puede utilizarse, junto con un WFS que acceda a una capa de polígonos que describa las áreas referenciadas por el
geoenlace, por ejemplo una capa vectorial de municipios que identifique cada uno con el código INE, para construir una
aplicación cliente que permita al usuario elegir qué atributo de la tabla desea representar, y mediante una asignación de
colores apropiada, formar un mapa temático al vuelo (on-the-fly) que pueda ser visto en pantalla mediante un WMS.
Tendríamos así la funcionalidad de construir en el momento mapas temáticos a la carta combinando las tablas de
atributos y las áreas geográficas de referencia disponibles en la Red, mapas que luego podríamos o bien imprimir o bien
guardar para su inserción en un documento.
Sensores en la Red
Sensor Web Enablement (SWE), algo así como Disposición de Sensores en la Red (10), es una especificación en
preparación en OGC, pensada para poder acceder en tiempo real a datos tomados por sensores, tales como estaciones de
aforo, estaciones pluviométricas, puntos de medida del tráfico por carretera, sensores meteorológicos, webcam,...de
manera estandarizada, es decir, según reglas y protocolos establecidos que permitan el acceso a los datos a través de la
red, desde cualquier aplicación diseñada para ello. Esto hará posible no sólo el análisis de datos geográficos remotos a
través de Internet, sino además la explotación y combinación en tiempo real de datos registrados en la naturaleza. Será
cómo dotar de organos sensoriales a las IDEs y permitir a los usuarios explorar el entorno y percibir cierta información.
El Cliente Integrado para Servicios Múltiples, Integrated Client for Multiple Services (IntClient), todavía es sólo un
primer documento que estudia la cuestión para abrir su discusión (11). Está pensado para construir clientes integrados,
que accedan a través de una interfaz común y amigable a un conjunto de servicios (básicamente WMS, WFS, WCS y
WSE) con una configuración concreta y guardarla de modo permanente mediante un lenguaje concreto. Es decir
permite definir y guardar clientes integrados de análisis y visualización de la IG, paso necesario como ya hemos dicho
para que los la amplia variedad de servicios OGC disponibles puedan ser utilizados y combinados desde un cliente
ligero de manera efectiva.
Tal mecánica de trabajo abriría la posibilidad de almacenar también de modo permanente un encadenamiento concreto
de servicios con una serie de parámetros y selecciones específicas, lo que supondría disponer de un lenguaje de
encadenamiento de servicios, y el regreso del concepto de lenguaje de macros, en la Red, y del concepto de Toolbox.
Esta última especificación, en caso de que llegue a definir, abriría enormes posibilidades para integrar servicios
disponibles en la red en la lógica de nuestras propias aplicaciones, que si están definidas como servicios públicos,
podrán ser a su vez integradas en otras aplicaciones...hasta constituir una suerte de palimpsesto digital.
Nuevas actividades
Nuevas posibilidades implican nuevas actividades, nuevas oportunidades de negocio. En primer lugar, el abaratamiento
del software, tanto de lo que es un cliente ligero como una aplicación que proporcione un servidor WMS, acompañado
de las posibilidades del software libre, hacen que el mercado de usuarios potenciales de tecnologías IDE sea muy
grande. En ese nuevo mercado hay un gran número de actividades por cubrir:
- Integración de servicios y componentes IDE, junto con el desarrollo de Geoportales y páginas web, para la
apertura de portales temáticos que puedan ofrecer tecnología IDE.
- Consultoría, implantación de soluciones “llave en mano”, formación y mantenimiento, para que usuarios no
expertos en informática puedan hacer uso de tecnologías IDE.
- Desarrollo y mantenimiento a la medida de servicios de análisis sobre WFS, WCS y SWE.
- Desarrollo de Clientes Integrados adaptados a los requerimientos de grupos de usuarios con intereses comunes.
- Desarrollo de clientes SIG pesados adaptados a un sector de aplicación específico.
- Análisis, diseño, desarrollo e implantación de workflow (flujo de trabajo) interno en un organismo productor o
gestor de IG.
- Extensión de software SIG pesado con utilidades de conexión a WMS, WCS,…
- Creación de Catálogos de datos y servicios, carga de metadatos y alojamiento (hosting) de catálogos externos.
- Desarrollo de servicios complejos de geoprocesamiento: simbolización de ficheros, conflación, emplazamiento
de textos, edición para mapa, filtrado, generalización asistida, determinación semiautomática de algunos
parámetros de calidad, georreferenciación de ficheros.
- Desarrollo de clientes de los servicios OGC para plataformas portables, como PDA, agendas e incluso
teléfonos móviles. Este equipamiento ofrece grandes posibilidades junto con un receptor GPS para realizar
trabajos de campo de captura de datos, actualización o corrección.
- Reingeniería y armonización de datos geográficos.
- Mapeos semánticos de Modelos Conceptuales diferentes.
- Construcción de ontologías para su utilización en una Web Semántica definida sobre un Geoportal IDE.
- Complementación de sistemas SIG ya en funcionamiento, con una versión IDE de visualización, consulta y
análisis de la IG.
y un largo etcétera, que surge de la ampliación de usuarios y beneficiarios de la explotación de la IG, de la variedad de
soluciones intermedias que van desde el SIG centralizado y monolítico, hasta una IDE completamente distribuida y
flexible, en dónde sea posible utilizar clientes ligeros y pesados.
La transición de los SIG a las IDE se enmarca dentro de toda una tendencia global que comprende un conjunto de
cambios y transformaciones mucho más amplias y generales, que apuntan en la dirección de las soluciones
cooperativas, abiertas y comunitarias, en lugar de las soluciones egoístas, cerradas e individuales, que introducen
dinámicas de intercambio en las que el precio no es imprescindible, y las antiguas reglas del mercado libre se ven
modificadas, como Peka Himanen ha planteado con lucidez en su imprescindible “La ética hacker y el espíritu de la era
de la información” (12), en dónde construye una réplica coherente al clásico “La ética protestante y el espíritu del
capitalismo” de Max Weber.
Soluciones cooperativas
Los avances ocurridos en los últimos años en el campo de las comunicaciones, las tecnologías de la información y su
aplicación masiva, simbolizados en la aparición de Internet, la Red con mayúsculas y por antonomasia, han propiciado
la utilización de soluciones cooperativas en gran número de campos de actividad.
John F. Nash, el genial matemático estadounidense, demostró en los años 50 que en muchas situaciones la mejor
solución para un conjunto de individuos no es la que produce el libre egoísmo de cada uno. No es la resultante de las
soluciones que buscan la mejor solución para cada individuo, en contra de la idea de libre competencia de actores en el
mercado libre de Adam Smith. Sino que la solución óptima para el conjunto es la que produce el que cada individuo
busque lo más beneficioso para el conjunto, lo que parece lógico por otra parte, y se conoce, bajo ciertas condiciones,
como solución de Nash (13). La importancia de las aplicaciones económicas de su teoría le supuso el premio Nobel de
Economía en 1994, y desde entonces varias veces este galardón ha sido concedido por contribuciones extraídas de la
teoría de juegos.
Han aparecido en Internet varios proyectos de creación de obras artísticas basadas en la integración de contribuciones
de un conjunto de autores voluntarios: La Fura dels Baus compuso la música de una de sus operas mediante un
programa que integraba y armonizaba las aportaciones musicales de internautas voluntarios; varias obras de narrativa se
han construido sumando propuestas de un modo parecido, una de ellas sobre un texto inicial de Gabriel García
Márquez.
La más extensa, utilizada y multilingüe enciclopedia de la actualidad es la Wikipedia (14), un proyecto colectivo que en
sólo 5 años ha crecido hasta disponer de más de 60.000 entradas, disponer de versiones en más de 100 idiomas y tener
más de 200 millones de palabras. Todo ello gracias a la colaboración de un buen número de autores, 450 para la versión
española, que consolidan sus aportaciones por consenso mediante un protocolo bien establecido. Consultar la Wikipedia
a través de Internet es gratis y libre, y contribuir con definiciones y texto también, por lo que constituye una de las obras
más complejas y refinadas de autoría colectiva.
Y como fenómeno de autoría colectiva, tenemos el deslumbrante ejemplo del Software Libre, cuyo proceso de
producción se basa en la libre interacción y sinergia de un colectivo de programadores y usuarios que testean y depuran
cada nueva versión.
Las Infraestructuras de Datos Espaciales participan de alguna manera de las características más esenciales de este tipo
de proyectos: son realizaciones colectivas basadas en la sinergia de muchos actores y ofrecen funcionalidades públicas
en la Red. Parafraseando a Jimmy Wales, creador de la Wikipedia, la vocación de las IDEs es proporcionarle un SIG
gratis y libre a cada usuario del planeta.
En los últimos años, ha aparecido el ya mencionado Software Libre, como fenómeno basado en cuatro libertades (15):
la libertad de usar el programa para cualquier propósito; la libertad de estudiar cómo funciona el programa y poder
adaptarlo; la libertad de distribuir copias del programa; y la libertad de mejorar el programa y hacer públicas las
mejoras. Preferimos hablar de Software Libre, bien definido por la Free Software Foundation, que desde luego no es
exactamente lo mismo que Software gratis, y que tampoco es sinónimo de software abierto, que parece aludir nada más
a la posibilidad de leer el código fuente. Eric S. Raymond sostiene, en sendas argumentaciones muy fundamentadas y
sensatas, que lo fundamental es el modelo de producción del Software Libre, que resulta ser de mayor calidad que el
software cerrado, al ser una creación de autoría colectiva (16), y más sostenible económicamente, al basarse en la
facturación por servicios y no por un producto final (17).
Existe una interesante variedad de aplicaciones SIG e IDE en forma de Software Libre y en ocasiones se plantea una
falsa polémica sobre la disyuntiva Software Libre versus software propietario, contempladas ambas opciones como
excluyentes y antagónicas, cuando lo cierto es que pueden ser vistas como complementarias y cada una tiene su campo
de actuación. Lo más inteligente es aprovechar las ventajas que presentan los dos modelos de producción de programas
y utilizar en cada caso la aproximación más eficaz. Desde el punto de vista del software clásico podríamos peguntar
¿quién teme al software libre feroz? Más que una competencia peligrosa, representa una alternativa interesante.
En contra de la primera opinión general, tal y como ha explicado Fernando Trías (18), varios ejemplos reales están
demostrando que la oferta de productos gratis o a un precio muy bajo puede acabar beneficiando en algunos casos a los
que compiten en ese mercado en lugar de perjudicarlos. Parece que si se trata de mercados con un gran número de
clientes potenciales todavía por despertar, tales productos actúan como iniciadores captando un buen número de nuevos
usuarios, de los que un cierto porcentaje a la larga queda insatisfecho y se redirige hacia los productos de pago. Así, el
porcentaje de lectores de periódicos de pago, venía disminuyendo todos los años… hasta la aparición de los periódicos
gratuitos; y la ya mencionada Wikipedia, enciclopedia de consulta gratuita en Internet, ha hecho que se vendan más
enciclopedias. Algún productor de datos geográficos español aseguraba que el primer año que permitía descargas
gratuitas de sus productos cartográficos, fue el año de mayor facturación por las licencias de uso de los mismos
productos.
Responsabilidad social
La Responsabilidad Social Empresarial (RSE), también llamada Responsabilidad Social Corporativa (RSC), es una de
las ideas más sorprendente y llamativa que ha aparecido recientemente en la gestión de empresas públicas y privadas.
Frente a la concepción clásica de la empresa como una organización orientada al lucro y a la optimización obsesiva del
beneficio empresarial, la RSE se basa en la idea de que las empresas, como personas jurídicas que son, tienen los
mismos deberes, ni más ni menos, que todas las personas físicas, es decir, los ciudadanos. Deberes de comportamiento
ético, de cuidado y protección del medio ambiente, de ayuda a los débiles, de defensa de la dignidad, de fomento de la
justicia. También los particulares trabajan para su propio interés, como las empresas, pero no pueden pensar que su
responsabilidad ética se termina pagando impuestos. Por lo tanto, se espera también un comportamiento ético
empresarial como consecuencia de sus responsabilidades sociales, y aparecen las iniciativas de comercio justo, de
protección del medio amiente, de programas de acción social, etcétera.
Todo ello con el objetivo de mejorar la imagen corporativa y la salud de la empresa enraizándola fuertemente en la
comunidad para aprovechar las fuerzas sociales en su beneficio.
Esta tendencia general ha dado lugar a fenómenos tan curiosos como el de Starbuck Coffee, una compañía que se ha
convertido en emporio transnacional aplicando el triple principio de beneficiar a sus proveedores, favorecer a sus
trabajadores y cuidar de sus clientes, y cuyo presidente y fundador, Howard Schultz, mantiene un discurso de una
filantropía exultante cuando declara (19): “Queremos tener beneficios, pero también queremos darlos.”
El último escalón de esta novedosa forma de ver la actividad empresarial, lo constituyen la posibilidad de que las
empresas actúen como agentes sociales que contribuyen al desarrollo, al progreso y a los avances tecnológicos. El
filósofo José Antonio Marina opina que las empresas son, además de una gran concentración de poder, una
concentración de talento, y deberían convertirse en líderes sociales. Por su parte, el actual Secretario de Naciones
Unidas, Kofi Annan, ha expresado públicamente que, desde su punto de vista, “necesitamos empresarios que
contribuyan a movilizar la ciencia y la tecnología...”
En nuestra opinión, este aspecto de la responsabilidad social, que es el contribuir al desarrollo tecnológico, puede ser
extendido a todos los actores que participan en un sector de actividad concreto e implica, entre otras muchas cosas, una
responsabilidad de difundir todo lo posible y apostar por una nueva tecnología, para desarrollarla al máximo y lo más
rápidamente posible, y poder así optimizar los beneficios sociales que reporta. En caso contrario se corre el riesgo de
que el paradigma no se amortice, que no se exploten sus beneficios suficientemente.
De todo lo dicho, se desprende que estamos asistiendo a un cambio de paradigma tecnológico en el campo de la IG,
preñado de nuevas posibilidades técnicas y estratégicas, enmarcado en una tendencia general de soluciones
cooperativas, basadas en el compartir, la solidaridad y una nueva manera de entender la responsabilidad social. El
impacto de las nuevas tendencias en nuestra actividad cotidiana es y será considerable y la mejor opción disponible
parece ser tratar de absorber tal impacto y aprovechar las ventajas y oportunidades que suponen las nuevas situaciones.
Creemos que ha llegado la hora de que los distintos actores que intervienen de una u otra manea en una IDE elijan el rol
que van a desempeñar, ya que siempre es preferible hacer la revolución que sufrirla, pilotar el cambio situándose en la
posición más favorable. Por intentar esbozar algunos ejemplos:
- Los productores de datos geográficos, pueden desempeñar el papel de líderes en la transición tecnológica en la que
estamos inmersos, adaptando su política de actuación a la nueva situación, fomentando la aplicación de soluciones IDE,
proporcionando cada vez más servicios de visualización, consulta y análisis de los datos geográficos que producen y
mantienen, y colaborando en la implantación de IDEs en su ámbito de actuación y en su integración en otros proyectos
IDE.
- La Administración a todos los niveles y en su conjunto, aprovechando y aplicando la filosofía, ideas y principios de la
Directiva PSI (20), la convención de Aarhus (21) y la Propuesta de Directiva INSPIRE (22). Las tres utilidades,
beneficios o motivaciones que pueden intervenir podrían ser: compartir y analizar los datos geográficos entre los
distintos organismos que la componen para mejorar la gestión; producir un beneficio social llevando progresivamente a
la realidad la administración electrónica; aumentar la transparencia administrativa, mejorar su imagen corporativa y
atender el derecho de los ciudadanos poniendo a su disposición la IG que se considere útil y apropiada para otros fines
que para los que fue generada.
- Los cartógrafos, en un sentido amplio de la palabra, como profesionales herederos del saber hacer en cuanto a
representación visual de la información, tienen un papel central que desempeñar cuando se trata de representar en una
pantalla de ordenador la información geográfica de la manera más legible y efectiva. Ellos son quienes deben resolver
los problemas derivados de los aspectos visuales de la interfaz hombre-máquina a través de pantalla: diseño de menús y
opciones, representación de fenómenos puntuales, lineales y superficiales, selección de colores, simbolización,
emplazamiento de textos en pantalla, etcétera, adaptando su experiencia cartográfica al nuevo entorno de
representación.
- La Universidad dispone de nuevas líneas de investigación poderosas y muy interesantes: integración de servicios,
armonización de datos, Web Semántica y Ontologías aplicadas a la IG, gestión avanzada y semiautomática de
Metadatos, calidad de datos,…Por otro lado tiene la oportunidad de contribuir directamente al desarrollo y definición de
especificaciones de interoperabilidad, toda vez que Open Geospatial Consortium es una organización abierta y
accesible, y la participación activa es posible. El considerable número de Facultades y Escuelas de Informática
existentes y el gran número de Escuelas Superiores de Ingeniería en Topografía y Geomática de reciente creación,
constituyen una oportunidad inmejorable para progresar en esta dirección. Por último, la oportunidad de incorporar las
tecnologías IDE a los programas de estudio redundaría en una mejora indispensable en la preparación de los nuevos
licenciados e ingenieros.
- Los productores de software necesitan un cambio en la concepción que les permita aprovechar el cambio tecnológico.
Si los sistemas están migrando hacia una arquitectura orientada a servicios ¿no debería migrar el sector hacia negocios
orientados a servicios? La producción de soluciones mixtas SIG-IDE, la expansión hacia nuevos mercados en sectores
hasta ahora prácticamente vírgenes (Universidad, enseñanza, pequeños y medianos organismos, guiado de coches,
etcétera), la consultoría, formación, desarrollo de soluciones llave en mano hechas a la medida,…aparecen como las
primeras oportunidades que despuntan en el horizonte.
- El sector privado en general, tiene en las tecnologías IDE un mecanismo de comunicación de información espacial
privilegiado, de gran potencia y efectividad, que por un lado, les brinda la oportunidad de informar a sus clientes de
dónde están sus oficinas de atención al público, sus tiendas, centros de distribución, … y por otro lado les permite
organizar, planificar y coordinar los aspectos espaciales de sus actividades internas a un coste muy reducido. El sector
privado también puede facilitar toda o parte de la información geográfica de que dispone, siempre que no sea
información sensible, publicándola e integrándola en IDEs públicas; y por último las IDEs facilitan enormemente la
colaboración entre empresas privadas que estén interesadas en el mismo tipo de datos geográficos, por ejemplo el
tendido de redes de infraestructuras de servicios existente en las grandes ciudades (gas, agua, electricidad, teléfono).
En suma, todas las actividades y aplicaciones que hasta ahora podrían gestionarse, planificarse o estudiarse con la ayuda
de un SIG, admiten ahora la utilización de las tecnologías IDE, con un notable abaratamiento de los recursos a invertir y
con grandes posibilidades de compartir datos, aplicaciones y todo tipo de recursos.
Todos los actores están en la tesitura de dar un giro a su política de actuación para tener en cuenta los cambios que se
están produciendo y los que se avecinan, y también para contribuir a que se produzcan. Creemos que es necesario que
los distintos actores se adapten a la nueva situación que supone el paradigma IDE, que elijan el papel que quieren
desempeñar en los nuevos escenarios que se están conformando, y que se decidan a crear las condiciones necesarias
para mejorar su actuación, en la medida de lo posible, desde una actitud activa ante el nuevo orden de cosas.
CONCLUSIONES
Un nuevo paradigma se está abriendo paso en el campo de la Información Geográfica, una revolución que nos llevará
desde los SIGs como espacio tecnológico a las IDE. Un cambio que va a implicar nuevas concepciones, reciclaje
tecnológico, un esfuerzo de reconversión de políticas, proyectos, métodos de trabajo... y también una valentía y un
arrojo considerables para realizar inversiones en innovación que no se van a recuperar a corto plazo, pero que van a
estimular una transición inevitable y deseable. En suma, se puede decir que en estos momentos “la IDE es el nuevo
queso”, por utilizar el lenguaje del best-seller de Spencer Jhonson sobre la gestión empresarial y nuestra actitud general
ante los cambios (23).
Cada uno de los actores implicados hasta ahora de un modo u otro en la gestión de IG, está obligado por las
circunstancias tecnológicas a replantearse el papel que juega en el concierto IDE, a redefinir sus actividades
aprovechando las ventajas que la interoperabilidad le ofrece y a adaptarse al nuevo paradigma si desea sobrevivir en las
mejores condiciones posibles. Las organizaciones obsoletas e inadaptadas se condenan a sí mismas a mantener una mala
salud o a una muerte lenta e imparable.
Igual que ocurre en un proyecto SIG, de acuerdo a Levinson y Huxhold (24), el factor que resulta ser decisivo para el
éxito o el fracaso de un proyecto IDE es una interacción efectiva y fructífera entre los factores técnicos y los
organizativos del proyecto, lo que coloca a los aspectos organizativos en primer lugar en cuanto a importancia en la
gestión de proyectos.
La comunidad SIG, puede extenderse hasta sectores de actividad y colectivos sociales ahora bastante lejanos a la
gestión digital de la cartografía, si se transmuta en sociedad IDE y aprovecha bien sus oportunidades: centros de
enseñanza, la investigación universitaria, las grandes corporaciones empresariales, los centros de decisión, los órganos
de la administración, la ingeniería,…pueden beneficiarse en algún modo de las tecnologías IDE mediante inversiones
ciertamente reducidas.
Por otro lado y en relación con la implementación de servicios de información orientados para satisfacer las necesidades
del ciudadano, más allá de lo que se ha dado en llamar Administración electrónica (e-government), entendiendo la
filosofía de la Convención de Aarhus de un modo amplio, y siguiendo la Directiva Europea 2003/98 sobre la
Reutilización de la Información de las AA.PP. (Directiva PSI), lo que supone reconocer el derecho del ciudadano a
acceder a la información, y en particular a la Información Geográfica, que custodian las administraciones, las
Infraestructuras de Datos Espaciales, constituyen la piedra angular que permite fijar la información al territorio y
ponerla a disposición del ciudadanos.
Por último, una IDE es siempre algo esencialmente emergente, que tiene propiedades surgidas de la libre y espontánea
sinergia de los organismos participantes y depende en gran parte de la competencia e iniciativa de los actores que la
integran. Una de las características que hacen de las IDEs proyectos de gran belleza e interés, es que su éxito no
depende de un único organismo o instancia, sino del desarrollo, la integración constructiva y la armoniosa colaboración
de todos los agentes participantes. Son realizaciones de autoría colectiva, en las que muchos cooperan, que benefician
también a muchos, y que se basan en la confianza mutua y en el compartir. Nadie lo ha sintetizado mejor que Fernando
Trías y Alex Rovira (25): “Si compartes, siempre ganas más”.
REFERENCIAS
1. Kuhn, Thomas S. (1979): La estructura de las revoluciones científicas. Fondo de Cultura Iberoamericana. Méjico.
2. Open Geospatial Consortium (2004): Web Map Service 1.3. http://www.opengeospatial.org
3. Open Geospatial Consortium (2005): Web Feature Service1.1. . http://www.opengeospatial.org
4. Open Geospatial Consortium (2003): Web Coverage Service 1.0. http://www.opengeospatial.org
5 Open Geospatial Consortium (2005): Web Processing Service 0.4. http://www.opengeospatial.org
6. ISO/TC211: ISO 19119:2003 “Geographic Information – Services”
7. Open Geospatial Consortium (2002): Gazetteer 0.0.9. http://www.opengeospatial.org
8. Open Geospatial Consortium (2001): Geoparser 0.7.1. http://www.opengeospatial.org
9. Open Geospatial Consortium (2004): Geolinked Data Access Service 0.9.1. http://www.opengeospatial.org
10. Open Geospatial Consortium (2004): Sensor Web Enablement http://www.opengeospatial.org
11. Open Geospatial Consortium (2003): Integrated Client for Multiple Services 0.1.18. http://www.opengeospatial.org
12. Himanen, Peka (2001): La ética hacker y el espíritu de la era de la información. Editorial Destino.
13. Poundstone, William (1995): El dilema del prisionero. Editorial Alianza.
14. Wikipedia website: http://www.wikipedia.org (último acceso: Noviembre, 2005).
15. Free Software Foundation website: http://www.gnu.org (último acceso: Noviembre, 2005).
16. Raymond, Eric S. (1998): La catedral y el bazar, http://sindominio.net/biblioweb/telematica/catedral.html .
17. Raymond, Eric S. (2000): El caldero mágico, http://atlanta.info/MagicCaudron.html
18. Trías de Bes, Fernando (2005): Productos gratis…o casi. En EPS (El País Semanal) 2005-11-06.
19. Schultz, Howard y Yang, Dori Jones (1997): Pour Your Heart into It. Hyperion Books.
20. Unión Europea (2003): Directiva PSI:http://europa.eu.int/information_society/ policy/psi/docs/pdfs/directive/psi_directive_es.pdf
(último acceso Noviembre 2005).
21. Unión Europea (1998): Convención de Aarhus: http://europa.eu.int/comm/environment/aarhus (último acceso Noviembre 2005)
22. Unión Europea (2004): Propuesta de Directiva INSPIRE: http://www.ec-gis.org/inspire/proposal/ES.pdf (último acceso
Noviembre 2005)
23. Jhonson, Spencer (2000): ¿Quién se ha llevado mi queso?. Ediciones Urano. Empresa Activa.
24. Huxhold, W.E. y Levinson, A.G. (1995): Managing Geographic Information System Projects. Oxford University Press.
25. Trías de Bes, Fernando y Rovira, Alex (2004): La buena suerte. Ediciones Urano. Empresa Activa.
Resumen: Se han identificado progresos y retrocesos en el desarrollo de las IDE, pero no se ha prestado la debida
atención a la sustentabilidad de estas actividades cuando no existe financiación holgada de parte de los estados. En
este trabajo se comentan algunos de los problemas técnicos que pueden limitar la participación del sector privado, o
incluso del sector público en aquellos países en que el retorno por venta de datos o servicios es parte relevante de su
actual Modelo de Negocios. Se destaca entre todos los posibles los problemas de piratería, de la disparidad
geométrica en la base cartográfica y el de la autenticación o integridad de datos. El primero afecta directamente la
facturación por venta de datos. El segundo retrasa o incluso inhibe la concreción de servicios/proyectos al no poder
contar con las capas apropiadas de información a niveles comparables de exactitud planimétrica. El tercero es
pertinente en aplicaciones sensibles desde el punto de vista de seguridad, como la emisión de certificados con valor
legal a partir de una base digital. Si bien desde un punto de vista técnico estos problemas han sido poco abordados en
el pasado a nivel académico, se describen las líneas exploradas y algunas soluciones actualmente disponibles a nivel
comercial.
Introducción
Las IDEs en general no se crean en el vacío; entre sus objetivos está el de facilitar el descubrimiento e intercambio de
información geográfica previamente existente con el objetivo de disminuir costos a los usuarios y evitar duplicación de
esfuerzos a nivel nacional. Entre los objetivos secundarios que ocasionalmente se plantean está el de viabilizar la
operativa de una geo-industria, que permita la generación de nuevos servicios y productos para el mercado local o
incluso para el extranjero. Entre otras, podrían citarse servicios de validación de direcciones postales, localización de
móviles, juegos en red con teléfonos móviles, etc. todos los cuales comparten la inviabilidad del servicio o producto en
ausencia de información geográfica con características adecuadas. Si esa información crítica no existe, la IDE viabiliza
la participación de proveedores creando una vitrina donde exhibir sus productos y/o un ámbito donde se identifiquen
oportunidades de negocio.
En América Latina, Europa y otras regiones es corriente que las organizaciones estatales que producen información
espacial (del tipo de un Instituto Cartográfico Nacional; ICN) financien una parte de su presupuesto con fondos que
provee el estado. Dependiendo de los casos, en las últimas décadas estos fondos o han declinado, o se han mantenido en
niveles históricos sin tener en cuenta los cambios técnicos y sociales que han ocurrido. Por ejemplo, algunos de ellos
conservan en su plantilla un número proporcionalmente grande de funcionarios con poca calificación técnica, que se
justificaban ciertamente en tiempos en que el trabajo de campo se hacía con instrumental tal que requería campañas más
o menos largas en terrenos quizá inhóspitos. La aparición durante el siglo XX de sucesivas técnicas de observación
remota, y la invención posterior del GPS ha bajado drásticamente las necesidades de ese tipo de personal de apoyo lo
que no necesariamente se ha reflejado en la conformación de los cuadros del personal disponible, rígidamente
estructurado en torno al presupuesto del estado.
Por otra parte, la progresiva informatización de los procesos ha obligado a realizar inversiones en áreas no tan
tradicionales, y con equipos que tienen una vida útil bastante menor que los antiguos instrumentos utilizados. El proceso
burocrático para adquirir, renovar y mantener ese equipamiento es (en algunos países) lento y dificultoso. Los gastos
que no se pueden solventar (por su monto o por restricciones en los procesos de compras) con fondos del presupuesto
estatal se deben financiar con ingresos por venta de productos o servicios. En definitiva estas tendencias han ido
afectando lentamente el Modelo de Negocios tradicional: ahora conseguir dinero extra (por fuera del presupuesto) es
crucial.
A nivel internacional pueden identificarse otras alternativas. Por ejemplo, en los EEUU los datos recolectados por el
gobierno federal en general, y en particular los geográficos, están alcanzados por disposiciones constitucionales que
obligan a ponerlos al alcance del público al costo nominal de su diseminación. Ello no rige a nivel estatal. Por lo tanto,
los organismos productores de datos a nivel federal deben ser íntegramente financiados con el presupuesto ya que no
hay posibilidad legal de cobrar por los datos. Adicionalmente, ellos manejan razones estratégicas y de seguridad
nacional para recoger en forma amplia información geográfica con satélites y otros equipos tecnológicamente
avanzados, sin tener para nada en cuenta un Modelo de Negocios comercial que considere ingresos y egresos. En
opinión del autor, esta parte de la realidad es frecuentemente ignorada por la comunidad de usuarios fuera de los EEUU
al plantear que los datos deben ser distribuidos gratuitamente urbi et orbi.
El modelo en boga en la mayoría de los países europeos y sudamericanos es que los datos deben venderse a un costo
sensiblemente superior al establecido por sus contrapartes norteamericanas. Hay sin embargo variadas situaciones en lo
que respecta a la incidencia financiera que en la práctica tiene esta política. Hay países en que el ICN tiene más del 80%
de su presupuesto cubierto con fondos estatales. Hay otros en los que prácticamente toda la inversión en equipos
nuevos, software, etc. debe ser financiada con recursos extrapresupuestales, independientemente de la naturaleza
pública o privada del comprador de los datos. Estas diferencias sustanciales en el origen de los fondos operativos obliga
a valorar en forma diferente una oportunidad de negocios dada por demandas insatisfechas. Si los fondos son
abundantes y la obligación legal es vaga, entonces el interés por atender las demandas insatisfechas puede verse
disminuido. Si los fondos presupuestales son escasos, hay en principio una motivación en atender esa demanda; resta
considerar las amenazas específicas a emprendimientos de este tipo (que también lo son para el sector privado) lo que
será el objeto de esta ponencia.
Las IDEs exitosas proveerán un escalón importante en la cadena de valor, facilitando a los usuarios la identificación y
localización de los datos que necesitan. Simultáneamente operarán como escaparate virtual para los datos y servicios
que se ofrezcan. En relación a los datos necesarios podrían darse las siguientes situaciones:
a) el dato requerido no ha sido recogido, o está desactualizado
b) el dato existe, pero 1) no está armonizado con otros relevantes o 2) carece de la exactitud planimétrica
requerida para su uso
c) el dato existe, pero sus características deben ser garantizadas
Para la situación a) es posible que el sector privado tenga un rol a cumplir (si no hay impedimentos legales), invirtiendo
en la recolección o actualización del dato pero siempre aspirando a recuperar la inversión mediante la venta a varios
clientes. Nótese que no se está considerando el caso de una empresa que necesite ella misma los datos para un proyecto
o actividad; en ese caso deberá recogerlos sin perjuicio de intentar una recuperación de la inversión. El foco en este
trabajo está orientado a las empresas que tengan como giro la generación de juegos de datos con fines de lucro a través
de su venta a más de un cliente. La amenaza al Modelo de Negocio está dada por la piratería, a lo que se dedicará el
primer apartado.
A diferencia de la anterior, las situaciones mencionadas en b) describen un problema que, en teoría, se resuelve en un
único acto. Mediante la aplicación de una transformación matemática (que en principio existe) es teóricamente posible
transformar una o varias coberturas con una base cartográfica dada para hacerla(s) coherente(s) con otra(s). El problema
matemático así planteado es de interpolación, porque hay un conjunto de puntos de control en la base cartográfica dada
a los cuales se les puede asignar con toda precisión las coordenadas en la nueva base. Este problema será desarrollado
en el segundo apartado.
Para algunas aplicaciones críticas (despacho de ambulancias, emisión de certificados, etc.) es necesario que los datos
intercambiados tengan algo equivalente a un sello de autenticidad, de forma que puedan asignarse responsabilidades por
errores u omisiones. Esto es especialmente crítico en casos en que la vida está en riesgo, pero también lo es cuando hay
bienes o actividades de subido valor involucrados. Hasta donde el autor conoce la industrias de seguros no han
incorporado pólizas específicas a la Calidad de datos, si bien existen antecedentes de juicios exitosos que podrían servir
de antecedente. Como se verá, en alguna medida este problema está emparentado con el de la piratería, y será analizado
en el último apartado.
En términos coloquiales debe interpretarse como piratería a cualquier violación de los derechos de propiedad intelectual
u otros afines. Nótese que pueden distinguirse dos problemas diferentes (López, 2002). Históricamente, el más relevante
fue el de Piratería de Autoría; en el cual (por ejemplo) una imprenta tomaba un mapa existente y lo utilizaba total o
parcialmente para producir otro ignorando la mención a la fuente original (y el pago de derechos…). En ese caso, el
pirata estaba bien identificado y por su acción obtenía ingresos de clientes en principio honrados. La segunda modalidad
corresponde a la Piratería de Propiedad: el pirata realiza copias ilegales de un original y las distribuye (contra pago o
no) a una comunidad de usuarios que en principio no podría ignorar su origen ilegítimo. La autoría no está en discusión:
es más, quizá se publicita junto con los datos. Esta variante pasa a ser viable cuando el costo marginal de la copia y
diseminación es prácticamente nulo, como ocurre con los medios electrónicos. Si bien ambas modalidades son
perjudiciales para el productor de datos, debe señalarse que la que más preocupa hoy en día es la última de ellas, ya que
es mucho más difícil de perseguir legalmente a un universo grande de usuarios pequeños. Hay sin embargo casos
recientes de Piratería de Autoría que han terminado en arreglos muy voluminosos (OS GB vs. Centrica, 2001) y es
probable que ello siga ocurriendo.
En este trabajo se está enfatizando la protección del productor frente a sus clientes; sin embargo como se señala en
(Memon and Wong, 1998; Lintian and Nahrstedt, 1998) también es necesario prever que el cliente puede ser
injustamente acusado. Esto afecta fundamentalmente al protocolo, e indirectamente a la solución técnica.
El esquema de Piratería de Propiedad está basado implícitamente en una impunidad técnica; si todos los ejemplares
legítimos son idénticos, dado un ejemplar ilegítimo no es posible identificar a quien cedió su original para realizar la
primer copia. El tema de la Piratería de Propiedad es de difícil solución; requiere de la existencia simultánea de
soluciones legales, técnicas, y de protocolo.
Es claro que si la parte legal falta o falla no será posible perseguir al pirata aunque esté plenamente identificado con
soluciones técnicas. En muchos países es legalmente posible hacer copias de un original para ciertos usos (fair use) sin
pagar por ello. En otros ni siquiera está claro cuál es el marco legal que protege al productor; por ejemplo, en Argentina
hay que demostrar en cada juicio que un mapa es análogo a una obra artística y por tanto debe ser considerado bajo el
cuerpo legal de Derechos de Autor. Cabe señalar que en general la mera compilación de información no da el carácter
de artístico, y por lo tanto el contenido de (por ejemplo) un directorio telefónico no puede ampararse bajo el Derecho de
Autor. En Europa hay un cuerpo legal específico para estos casos, pero en la mayoría de los países no.
A falta de un respaldo legal genérico, si el infractor no ha firmado un contrato con el propietario de la información (cosa
usual; los piratas son bastante informales), entonces no se contará con protección legal para hacerle un juicio a él. En
cambio, el comprador legítimo original sí ha firmado contratos y por lo tanto puede ser objeto de un juicio… ¡si es que
puede identificársele!.
Lo que la tecnología podría hacer para controlar la piratería varía en un rango amplio; en un extremo serían soluciones
que inhibieran la copia de los datos. Una posible forma de operar sería entregar los datos en un CD o similar, que sólo
pudiera ser visible para el usuario en la presencia de una llave (dongle) extremadamente difícil de duplicar. En muchos
contextos, y las aplicaciones de SIG en particular, esta solución para el caso de los datos mismos no parece tener
mucho potencial; es más popular para proteger al software. El mejor ejemplo ha sido el del DVD (Cox and Miller,
2002), originalmente concebido con control de lectura y uso mediante la participación activa del hardware; el esquema
de seguridad fue roto con gran rapidez en 1999. Lo mismo ocurrió con una propuesta posterior de SONY (Knight,
2002).
En el caso de datos en general, y de datos de SIG en particular, se requeriría además la participación activa de los
productores de software de forma que sus productos sólo acepten abrir archivos “válidos”, emulando en alguna forma la
concepción de los DVD. Incluso si ese acuerdo se lograra algún día, restaría resolver cómo inhibir la exportación de
datos del SIG a formatos más antiguos, no encriptados, o incluso a archivos de trazador, que mediante una
manipulación laboriosa pero posible podrían recrear el dato original. La falta de soluciones exitosas al presente para
impedir la copia no inhibe que sigan apareciendo otras en el futuro, siguiendo un juego del gato y el ratón con los
piratas profesionales.
Es posible encontrar otra solución para este problema basada en un principio diferente. La misma se basa en el uso de
Marcas de Agua indelebles e invisibles. Para ilustrar la operativa supóngase que es posible insertar en un mapa digital u
otro juego de datos un número de serie invisible e indeleble. Si se encontrase en el futuro una copia del archivo en
manos de un usuario no autorizado, podría rastrearse el comprador original mediante el número de serie y penalizarlo de
acuerdo a lo convenido en el contrato de entrega de la información. Estos contratos típicamente inhiben la copia o el uso
de datos para otras actividades fuera de las convenidas, y constituyen una base legal sólida (independiente de la
legislación de derechos de autor) para iniciar una demanda. Un aspecto clave del proceso es que el número de serie sea
a la vez invisible e indeleble; si fuera visible, el atacante podría manipular los datos haciendo pequeños cambios hasta
lograr que el número de serie desaparezca o tome valores imposibles, comprobando visualmente su éxito. Al ser
invisible, el atacante nunca sabe si ha logrado su objetivo. Obviamente debe existir algún procedimiento decodificador
secreto para que el número de serie pueda ser extraído cuando el juez lo demande. En este contexto, el adjetivo
indeleble debe interpretarse como “difícil de borrar sin hacer un daño sensible a los datos”; existen marcas de agua que
se borran o afectan aún con pequeñas modificaciones al archivo original, propiedad que se usa con fines de
autenticación (lo que se tratará en el tercer apartado).
El esquema completo funciona basado en la pérdida de impunidad del dueño legitimo: si sabe que todos los ejemplares
vendidos son idénticos al suyo, ¿cómo podrían identificarlo a él en particular como propietario de un ejemplar
ilegítimo? ¿y aunque le identifiquen, cómo podrían probarlo?. Si en cambio sabe (porque se le ha informado en el
contrato) que existen esos medios de seguimiento, tomará todas las precauciones para no ser eventualmente objeto de
un litigio que podría perder. Nótese además que, en la mayoría de los casos, estas copias ilegales se hacen sin fines de
lucro.
Por último resta comentar la parte del protocolo. El término protocolo debe aquí interpretarse como “secuencia de
procesos que garantizan la validez de una prueba” (Gopalakrishnan et al., 2001). Si el protocolo no es adecuado no
importará la tecnología ni la defensa legal. Un ejemplo simple de protocolo inadecuado es aquel en que el productor del
dato es asimismo quien inserta la marca de agua invisible e indeleble. Por lo tanto será el quien provea la prueba en el
juicio contra el ahora identificado pirata; le será fácil al abogado de este último señalar que no se puede ser juez y parte
y por lo tanto se caerá todo el juicio (López, 2004). El protocolo es en gran medida independiente de la solución técnica
en concreto; distintos métodos de insertar marcas de agua pueden compartir el mismo protocolo.
Si bien el protocolo puede ser el mismo, la tecnología no sólo puede sino que debe diferir dependiendo del tipo de dato
a proteger. La forma de insertar un número de serie en una imagen raster no es la misma que para hacerlo en una Base
de Datos de texto, un certificado o un mapa vectorial.
La investigación en protección por marcas de agua ha sido muy intensa en la última década, pero el dato más popular ha
sido el de la imagen raster. En Uruguay se ha desarrollado tecnología propia específica para el caso de mapas
vectoriales, sobre la que se han realizado ensayos con éxito (Bacci and López (2003)). En López (2004) se describe un
protocolo viable para la aplicación de marcas de agua bajo la forma de un servicio externo. Se remite al lector
interesado a la bibliografía citada.
Entre los principios de INSPIRE descritos por Smits (2003) se señala “…debería ser posible combinar sin
inconvenientes datos espaciales de diferentes orígenes y compartirlos entre muchos usuarios y aplicaciones…”. A este
servicio (aún por desarrollar) se le denomina Geospatial Data Fusion Service, aunque en la literatura consultada
también se suele usar el término Conflación (del inglés Conflation).
El problema planteado es la existencia del dato A y el dato B, recogidos independientemente y representados sobre una
base cartográfica diferente. Por ejemplo, podría suponerse que el atributo de A es de alta calidad, actualizado, etc. pero
la cartografía utilizada como base tiene un error medio cuadrático (EMC) de 100 mts, mientras que el dato B está
representado sobre una cartografía con EMC de 10 mts. El problema es hacer coincidir los objetos representados en A
con los equivalentes existentes en B, y arrastrar los atributos correspondientes, y todo ello en forma automática.
Esta formulación contempla casos potencialmente problemáticos; alguien podría querer transformar información
recogida a escala 1:500.000 con otra recogida a 1:5.000 para manipularla conjuntamente, lo que normalmente sería
objetable. Los SIG del futuro deberían emitir un mensaje de alerta en estos casos, pero éste no es el tema de esta
ponencia.
Volviendo al problema de partida, el usuario indicará un conjunto de puntos homólogos entre el conjunto A y B, y el
problema es transformar todos los puntos de A de forma de lograr que los homólogos coincidan (o se aproximen
mucho) y aquellos a los que no se le ha señalado homólogo se modifiquen en forma razonable. Si bien con estos
requerimientos existen múltiples formas de lograr una función de interpolación apropiada, no todas ellas son igualmente
útiles. Las conocidas genéricamente como rubbersheeting suelen tener comportamientos extraños en zonas con
concentración de puntos de control. De hecho este fenómeno se agrava al aumentar el número de puntos de control,
aspecto contra intuitivo que ha desalentado su uso si hay otras alternativas.
Una alternativa matemática es abandonar la interpolación y pasar a la formulación de un problema de aproximación. En
este caso, las nuevas coordenadas de los puntos de control no son estrictamente honradas, sino que son globalmente
aproximadas reconociendo que las nuevas coordenadas pueden tener ellas mismas cierta incertidumbre. Dependiendo
de la forma en que se seleccione la función aproximante, ella podría en el límite ajustar a la función de transformación
verdadera cuando se incrementa el número de puntos de control.
Hay otros problemas que pueden resolverse con la misma formulación matemática; por ejemplo, la existencia de un
mapa que tiene error planimétrico excesivo para aplicaciones de GPS. En Uruguay se han realizado experimentos con
un algoritmo propio, trabajando con cartografía a escala 1:50.000. En el experimento se disponía de puntos de apoyo
(datos) tomados de una carta del SGM, y de los correspondientes medidos con GPS submétrico. Se subdividió el
conjunto de puntos homólogos en dos grupos: el primer grupo participaría en el cálculo, mientras que el segundo sería
ignorado y sólo se le utilizaría para evaluar la mejora obtenida.
El experimento consistió en tomar un subconjunto de los puntos de control disponible, aplicar el algoritmo bajo análisis,
y calcular las nuevas coordenadas de todos los puntos de control. El EMC se evalúa sobre los puntos de control que no
participaron en la primera etapa del proceso. Para el mapa utilizado, los resultados numéricos pueden resumirse de la
siguiente manera:
• Utilizando sólo 16 puntos de entre los 66 disponibles, se logró bajar la desviación estándar del EMC original
de 103m a 38m. Se usaron 50 puntos testigo para evaluarla.
• Utilizando ahora 33 puntos de entre los disponibles, logró bajar la desviación estándar del error EMC original
de 103m a 32m. Se usaron ahora 33 puntos testigo para cuantificarla.
Estos resultados sólo son válidos para este mapa particular; no es posible ni legítimo extraer conclusiones generales.
Para este caso se ve que el estimador de error se reduce significativamente (al 30% del valor original) con la
metodología desarrollada. Este número debe complementarse con un análisis cualitativo del mapa resultante, el cual
debe ser validado por un analista humano. De esa forma, sería posible localizar errores aislados que pueden explicar las
diferencias entre la desviación tradicional y la robusta. Ellos típicamente tienen orígenes diferentes a los demás, y
pueden en muchos casos corregirse si son señalados.
Esta mejora de 1/3 en el EMC es teóricamente equivalente a la que se obtendría con un mapa de costo
( )
3 − 1 *100 = 73% mayor. Nótese que este “aumento del valor” teórico puede no reflejarse en el precio: en muchos
casos el precio del mapa se fija administrativamente, por lo que no hay una fórmula que vincule una mejora del error
geométrico con un precio de venta diferente. En otros casos el productor percibe una mejora mucho mayor: hay
aplicaciones para las que el mapa será útil si tiene un error menor a uno especificado, y no servirá en lo absoluto en otro
caso. Así, la mejora en la precisión implica que la transacción se realizará, y en otro caso no se haría. Nótese también
que agregar más puntos de control mejora en algo el error, pero no dramáticamente.
Actualmente se está trabajando en darle forma de servicio comercial a la tecnología citada.
Paralelamente, hay una demanda insatisfecha para degradar a voluntad la precisión geométrica de una cartografía
existente. Este aspecto se puede ilustrar con una guía telefónica. La cartografía allí incluída no tiene (normalmente)
pretensiones de precisión geométrica; no interesa medir distancias sobre ella y ni siquiera que tenga coordenadas. Lo
que se espera de ella es que refleje correctamente la topología (la calle A se corta con la B, la C y luego la D, y en ese
orden, etc.). Los clientes con necesidades de este tipo en muchas ocasiones no están dispuestos a pagar por una
precisión geométrica que no requieren. La tecnología bajo estudio permitiría degradar a voluntad la misma, bajando así
el valor (en el sentido de utilidad) del producto, y por lo tanto, su precio de mercado. Con un precio menor se capta un
segmento numeroso, sin necesidad de crear una nueva cartografía.
Este tema es poco desarrollado a pesar de estar explícitamente mencionado en los documentos citados de INSPIRE. En
los mismos se alude a puntos de contacto con las aplicaciones de autenticación corrientes en el comercio electrónico.
Desafortunadamente, las mismas no son directamente transportables al área geográfica, y se explicará porqué. En el
caso más corriente, se debe incluir una firma digital para un archivo completo de forma que se pueda demostrar (con
algún rigor matemático) que es improbable que el archivo haya sido modificado por un ataque malicioso. En el caso de
las aplicaciones geográficas esa seguridad es insuficiente, porque el archivo no suele ser manipulado como una unidad
indivisa. En cambio, son los objetos geográficos mismos los que deben tener algún certificado de integridad. Otras
aplicaciones técnicamente relacionadas (aunque no mencionadas en estas iniciativas) incluyen el de poner alguna fecha
de actualización o similar al nivel de objeto y no del juego de datos como un todo. Ello simplifica detectar los cambios
que ocurrieron entre diferentes versiones de un mismo juego de dato, con el fin de valorar su incidencia en las
aplicaciones en uso.
Este problema puede ser encarado con algunas de las tecnologías aludidas para la inserción de marcas de agua. La idea
aquí es insertar información a nivel del objeto sin que sea afectada su capacidad de usarlo pero permitiendo corroborar
en alguna medida la autenticidad del mismo. Nótese que la tecnología de marcas de agua a ser utilizada para estos
propósitos puede ser sustancialmente diferente de la utilizada para el control de piratería. En aquel caso, la marca debía
ser al menos resistente a manipulaciones legítimas, y por lo tanto debería sobrevivir incluso si el objeto original era
alterado. Para las aplicaciones de autenticidad las demandas son otras: cualquier manipulación debería destruir la marca,
por lo que se deberán utilizar variantes específicas. Para el caso de los datos geográficos, nuevamente el tipo más
estudiado es el de las imágenes raster en el que ya existen soluciones comerciales.
La tecnología desarrollada para la inserción de la marca de agua mencionada anteriormente podría ser capaz de proveer
una solución en este aspecto, aunque las investigaciones no han culminado.
Conclusiones
La implementación de las IDEs tiene objetivos de corto, mediano y largo plazo. Entre los últimos podría señalarse la
creación de una infraestructura para el desarrollo de una geo-industria, capaz de satisfacer las necesidades nacionales
pero también de desarrollar, probar y validar soluciones para nuevos problemas quizá hoy no evidentes. La construcción
de una IDE se enfrenta a una multitud de problemas (legales, sociales, técnicos, etc.) bien analizados en estas Jornadas,
pero el objeto de este trabajo ha sido poner sobre la mesa algunos de los problemas técnicos que amenazan
específicamente la sustentabilidad de Modelos de Negocios basados en la IDE. Se identificaron tres problemas.
Coincidiendo con directivas de INSPIRE, se ha señalado la necesidad de encontrar mecanismos técnicos para armonizar
datos con base planimétrica diferente, o lo que es lo mismo mejorar el Error Medio Cuadrático (EMC) de un mapa
existente utilizando puntos de control. Los primeros ensayos realizados muestran que es posible reducir
significativamente (a 30% del valor original) este estadístico, ilustrando una posible línea de acción basada en
algoritmos novedosos.
Otro problema identificado es el de piratería, problema relevante para empresas u organismos productores de datos y
que tienen un Modelo de Negocios basado en recuperación de inversiones mediante facturación por ventas. La solución
ofrecida y ensayada se basa en el uso de Marcas de Agua, que esencialmente inserta un número de serie invisible e
indeleble a cada instancia de un mapa vectorial entregado bajo contrato a un comprador legítimo. La solución frena la
piratería indirectamente, bajo la amenaza de poder identificar al comprador legítimo que cedió un ejemplar para ser
copiado ilegítimamente. El sistema ya está en uso en Uruguay.
El último problema señalado es el de la certificación de autenticidad de datos. A diferencia de la solución matemática
en boga en el comercio electrónico en que sólo se autentican archivos completos, aquí se desea autenticar los objetos
geográficos individuales. Ello permitiría en un caso extremo detectar fraudes, pero también podría usarse para objetivos
menos críticos como asignar una fecha de última actualización a cada objeto.
La buena salud de la IDE vista como un sistema dependerá de mitigar los riesgos e impedimentos que afecten a los
actores a cumplir sus roles. Un sector público, sólidamente financiado por el presupuesto ordinario, puede estar
blindado a algunos problemas y podrá continuar con su Modelo tradicional de Negocios aunque la IDE se haya
incorporado al entorno. En cambio, el sector privado (y el sector público cuando basa su operación en la recuperación
de inversiones por facturación) están o estarán evaluando nuevos Modelos de Negocios en el marco de las IDEs. En
opinión del autor es importante visualizar los riesgos asociados e investigar en la solución de los mismos ya desde
etapas tempranas de instalación de las IDEs, responsabilidad que le cabe a los investigadores.
REFERENCIAS
1. Anon. (2001): Centrica and Ordnance Survey settle Automobile Association copyright case.
http://www.ordsvy.gov.uk/media/newsreleases/2001/march/agreement.htm (último acceso: setiembre 2005)
2. Bacci, A. and López, C. (2003): Evaluation tests performed over a proposed anti-piracy system for digital vector datasets.
Cambridge Conference, Cambridge, UK, 21-25th july.
http://www.thedigitalmap.com/en/docs/EvaluationTestsPerformed.htm (último acceso: setiembre 2005)
3. Cox, I. J. and Miller, M. L. (2002): The First 50 Years of Electronic Watermarking. EURASIP J. of Applied Signal
Processing, 2002, 2, 126-132
4. Gopalakrishnan,K.; Memon, N. and Vora, P.L. (2001): Protocols for Watermark Verification. IEEE Multimedia, 2-9,
Oct-Dec 2001
5. Knight, K. (2002): Sony's latest CD copy protection comes unstuck. http://www.newscientist.com/article.ns?id=dn2294
(último acceso: setiembre 2005)
6. Lintian, Q. and Nahrstedt, K. (1998): Watermarking Schemes and Protocols for Protecting Rightful Ownership and
Customer’s Rights. Journal of Visual Communication and Image Representation, 9, 194-210.
7. López, C. (2002): Watermarking of Digital Geospatial datasets: a review of Technical, Legal and Copyright issues.
International Journal of Geographic Information Science, 16, 6, 589-607.
8. López, C. (2004): Un protocolo para protección contra piratería de mapas digitales utilizando marcas de agua. VIII
Congreso Nacional de Topografía y Cartografía TOPCART 2004, Madrid, España.
http://www.thedigitalmap.com/~carlos/papers/rep04_1/TopCart2004.pdf (último acceso: setiembre 2005)
9. López, C. (2005): Curso de Protección de Propiedad Intelectual mediante Marcas de Agua
http://www.thedigitalmap.com/watermark/curso/propiedadIntelectual.pps (último acceso: setiembre 2005)
10. Memon, N. and Wong, P. W. (1998): A buyer-seller watermarking protocol. IEEE Signal Processing Society 1998
Workshop on Multimedia Signal Processing December 7-9, 1998, Los Angeles, California, USA
11. Smits, Paul (2003): INSPIRE Architecture and Standards Position Paper. Architecture And Standards Working Group.
Edited by Paul Smits. 64pp. http://www.ec-gis.org/inspire (último acceso: setiembre 2005)
61
Los SIG y el control de las operaciones de recogida de información... Sesión 3
Resumen: En el contexto de una futura operación exhaustiva tipo estadística de población y utilizando herramientas
Open Source (JUMP y PostGIS) se ha desarrollado un prototipo para la monitorización de la cobertura y calidad de la
información que se va recogiendo. Para ello se utilizan , entre otra , información del Institut Cartogràfic de Catalunya
(ICC), catastro urbano y el registro de población como directorios base sobre los que realizar una simulación. En
relación al control de calidad de la información recogida, se han implementado utilidades de análisis como cálculos de
índices de autocorrelación espacial, localización de outliers espaciales, así como clustering y análisis de componentes
principales. Finalmente se proponen evoluciones del prototipo en cuanto a arquitectura y funcionalidades.
INTRODUCCIÓN.
La obtención de información en las operaciones exhaustivas tipo estadística de población implican, generalmente, la
entrevista del ciudadano por parte del personal de la oficina estadística con el fin de cumplimentar un cuestionario
previamente diseñado.
La captura y posterior tratamiento de los datos reseñados en el cuestionario serán el resultado final de esta costosa
operación que sólo puede abordarse desde la táctica de descomposición en problemas más pequeños, es decir,
compartimentando el territorio de tal manera que a un encuestador se le asigna una parte sobre el que tendrá que obtener
los datos de forma exhaustiva (sección censal), apoyándose para ello, en unos directorios iniciales (registro de
población o padrón).
Este encuestador está supervisado por un responsable de grupo que tiene asignada una parte mayor del territorio (un
conjunto de secciones censales y por ende un conjunto de encuestadores). A su vez el responsable de grupo está
supervisado, formando, todo esto, una estructura jerárquica asociada al territorio.
Es obvio que un sistema de información geográfico pueda desempeñar un papel fundamental en todo el proceso de
control ya que
El punto más importante, el que determinaría la potencialidad real de estas herramientas en este contexto, es el de poder
situar un cuestionario en el espacio, al nivel más detallado posible desde el punto de vista cartográfico.
Los directorios de personas (padrón o registro de población), de viviendas (padrón catastral), el resto de datos
cartográficos y la información sobre los estados sucesivos de los cuestionarios constituyen las estructuras de datos
necesarias para poder realizar un control minucioso de la operación de campo, respetando escrupulosamente, en todo
momento, la salvaguarda del secreto estadístico.
En IDESCAT hemos desarrollado un prototipo, basándonos en conocidos proyectos Open Source (JUMP[1] y
PostGIS[2]), con la finalidad de evaluar las posibilidades reales de un sistema de esta naturaleza, dotándolo de
utilidades orientadas al análisis descriptivo de datos espaciales así como de clásicos métodos de análisis descriptivo
multivariante.
CONTROL DE COBERTURA.
1
Distrito (*) Callejero INE Estados
1 N 1 N N M
1 N
Municipio (*) Hogares Cuestionario
1 N 1, 0 1
Personas
Comarca (*) 1 N
Agente N 1 N
entrevistador
1 Masa (*)
1 Callejero catastro
1 N
N 1
Mapa (*)
Sección censal (*)
1
Figura 1: Esquema simplificado entidad-relación. Las entidades marcadas con un asterisco tinenen atributos geométricos y
conforman las diferentes capas en el SIG.
En esta estructura de datos cabe destacar las relaciones entre las entidades Hogares - Padrón catastral y Sección censal –
Parcela ya que provienen del tratamiento de las direcciones postales. La entidad cuestionario, mediante su relación con
las entidades personas y estados representa la evolución de la operación de campo.
Los estados por los que puede pasar un cuestionario dependen del nivel de detalle que queramos tener de la operación,
por ejemplo la sucesión de estados:
Enviado
Recogido
Grabado
Imputado
Tiempo
Figura 2: Una posible sucesión de estados. Cada cambio implica la modificación de las entidades correspondientes en la B.D.
obligaría a realizar las operaciones de modificación en la base de datos en los diferentes estadios lo cual puede
representar un trabajo extra muy costoso (en la anterior sucesión podríamos eliminar el estado recogido ya que el estado
grabado lo implica necesariamente; no obstante ante la pérdida de cuestionarios no sabríamos si han sido recogidos o no
o si por el contrario no han sido grabados accidentalmente).
El control del desarrollo de la operación de campo puede realizarse con la ayuda del SIG mediante la observación de
mapas temáticos de los porcentajes de cuestionarios que están en cada uno de los estados anteriormente referidos,
asociándolos al nivel territorial de interés de un usuario: así un encuestador estará interesado en la observación de los
porcentajes de cuestionarios recogidos, grabados, etc., a nivel parcela dentro de una sección censal. A un encargado de
grupo posiblemente le interesará observar los mapas a niveles superiores para poder realizar la supervisión de la que es
responsable.
La aplicación que hemos desarrollado tiene actualmente una arquitectura en dos capas. El back-end corresponde a una
base de datos postGIS sobre la que se han implementado las estructuras descritas en el apartado anterior. Las tablas que
disponen de columnas de tipo “geometría” han sido indexadas via R-tree [4], esquema de indexación espacial soportado
por postGIS. De esta manera la obtención de las capas catastrales para una sección censal dada puede realizarse a través
de un query geo-espacial del estilo:
select asText(a.geom)
Cliente java, from
basado en Driver parcelas as a,
JUMP JDBC secciones as b
where
b.secciones=‘0830702007’ B.D: postGIS
and a.geom && b.geom
and contains(b.geom,a.geom);
Figura 3: Arquitectura actual de la aplicación y un query geo-espacial ejemplo en postGIS. Nótese que no es necesario que la capa
parcela tenga asignados códigos de sección
Por otro lado, el cliente java está basado en el conocido proyecto JUMP utilizando el mecanismo que proporciona su
arquitectura para realizar las extensiones pertinentes. Este mecanismo se basa en el desarrollo de clases que
implementan unas interfícies conocidas:
com.vividsolutions.jump.workbench.plugin.PlugIn
Tanto en los miembros initialize como execute se pasan referencias a instancias de la clase PlugInContext que a su vez
contiene referencias a los objetos que la aplicación está manipulando como ventanas, capas etc. El miembro execute se
dispara como acción de un elemento del menú que es adaptable a las necesidades de una aplicación concreta.
Para la realización del control de la operación de campo, se han desarrollado los plug-Ins para la obtención de los mapas
correspondientes a las secciones censales, parcelas, masas etc, como resultado de la entrada de un código de sección
censal. Además, gracias a que JUMP dispone de un cliente WMS, es posible obtener ortofotos y otras capas de los
servidores públicos del Institut Cartogràfic de Catalunya (ICC) [5] permitiendo así un mejor conocimiento del área
asignada a un encuestador
Figura 5: Mapa correspondiente a las parcelas de una sección censal de Vilanova i la Geltrú. De fondo la capa generada por el
servidor WMS del ICC.
Al ejecutar este plugin no solamente obtenemos de la base de datos la información asociada a las capas sinó que se
evaluan los siguientes datos:
• Número de hogares
• Número de personas
• % de cuestionarios enviados
• % de cuestionarios recogidos
• % de cuestionarios grabados
• % de cuestionarios imputados
agregados al nivel más bajo que corresponda (en este caso a nivel de parcela catastral), y que representa el estado de la
operación de campo en ese momento.
La representación de mapas temáticos de esas variables proporcionan una fotografía del estado de la operación de
campo en esa área de interés:
Figura 6: Distribución (simulada) del porcentaje de cuestionarios grabados en una sección censal de Vilanova i la Geltrú.
Nótese que el agente encuestador puede conocer en que lugar se descubre la falta de cuestionarios grabados. Se ha omitido la capa
ortofoto proporcionada por el WMS del ICC.
Al seleccionar una parcela se puede obtener información detallada de los hogares y estado de los cuestionarios:
Otros casos de usos implementados son el acceso a los datos del cuestionario (simulado) para un hogar determinado.
Esta opción abre la puerta a poder editar los datos del cuestionario directamente desde la aplicación, caso especialmente
útil para encuestas no exhaustivas en las que el agente disponga de un portátil y para el que se le prepararía una
aplicación local de este estilo.
Esta aplicación ha sido desarrollada con una arquitectura en dos capas, acceso a postGIS via drivers java de tipo IV
(thin drivers) y su despliegue se realiza con Java WebStart. La migración a arquitecturas más escalables de tres capas
son viables gracias a las implementaciones de referencia de CachedRowSet [6] con el concurso de un servidor http i un
motor de servlets con una máquina virtual nivel 1.5
Una vez grabada la información se procede a su análisis para verificar su calidad, nivel de respuesta etc. Normalmente
este análisis se realiza observando la distribución de valores así como los resultados obtenidos de un conjunto de
tabulaciones cruzadas. Otra forma de verificar la bondad de los resultados es observar como son las distribuciones en
relación al espacio. Para ello, la aplicación de control implementa la generación de los típicos mapas temáticos, con las
siguientes opciones:
• Intérvalos iguales
• Mapas asociados a percentiles
• Dos intérvalos por encima /debajo de la media
• Tres intérvalos. Central una desviación o central dos desviaciones
• Cluster mediante KMeans
• Por encima/debajo de cero, si hay cambio de signo
Para datos referentes al Censo de población 2001 para la comarca del Barcelonés y para el porcentaje de Licenciados y
doctores a nivel de sección censal obtendríamos :
Como puede observarse existe una fuerte autocorrelación espacial (las zonas de elevado % de licenciados y doctores
son compactas) tal como indica el índice de autocorrelación de Moran [8] definido por:
∑∑ w ( y − y )(y − y)
n n
ij i j
n i =1 j =1
I= n n n
∑∑ w ∑ (y − y)
2
ij i
i =1 j =1 i =1
donde
n es el número de áreas
yi es el valor observado en el elemento i -ésimo
wij es la distancia entre los elementos i-esimo y j-ésimo
y es el valor medio de la variable
Este índice, cuyos valores están comprendidos entre -1 y +1, mide la autocorrelación espacial de una variable, siendo el
valor 0 indicativo de ausencia de autocorrelación. El elemento wij representa la distancia entre i y j siendo su valor
dependiente del esquema de medición de distancias empleado. En nuestro caso, por razones de eficiencia,
y se evalúa mediante el api JTS [1], utilizado internamente por JUMP, gracias a que cumple con las especificaciones
SFSQL de la OGC del lado cliente.
La simple observación de valores de la distribución, o la información del grado de autocorrelación espacial indicarían
de forma global la bondad de los datos (por ejemplo, una elevada autocorrelación espacial para la edad sería muy
sospechoso).
No obstante para nuestros objetivos es más importante la detección de outliers espaciales, es decir zonas con valores
anómalos en relación a sus vecinos (que no serían fácilmente detectables con los mapas anteriores o con las
tabulaciones pertinentes). La representación simultánea de los valores observados frente al promedio ponderado del de
sus vecinos (gráfico de Moran) facilita la detección tanto de outliers como de outliers espaciales.
En la implementación realizada para este gráfico se presentan la nube de puntos, la recta cuya pendiente coincide con el
índice de autocorrelación global de Moran, un área gris que corresponde a valores dentro del intervalo central de la
distribución de distancias entre el valor observado y los promedios espaciales, así como dos líneas marcadas en magenta
que señalan los valores centrales de la distribución.
Los valores que quedan fuera de las líneas de color magenta pueden considerarse outliers en el sentido clásico de
término. Los valores que quedan fuera del área gris pueden considerarse outliers espaciales, siendo los situados en la
zona superior los valores que son más bajos que los de su entorno y los de la zona inferior valores superiores a su
entorno.
El usuario, gracias a que esta ventana se ha registrado como un listener de la ventana de representación de los mapas,
puede seleccionar una geometría (en este caso sección censal) y observar ese punto en el diagrama de Moran y al
contrario, puede seleccionar una área en el diagrama y observar a que partes del territorio les corresponde :
Figura 9: La selección desde el gráfico de Moran produce la selección en el mapa y al contrario. Obsérvese que los puntos
seleccionados pueden considerarse tanto outliers como outliers espaciales.
Finalmente, para poder analizar mejor los datos desde una perspectiva multivariante, se ha implementado el análisis de
componentes principales (ACP) utilizando para ello el api de tratamiento de matrices Jama [9]. El ACP es una técnica
multivariante que trata de obtener un conjunto reducido de factores ortogonales, combinación lineal de las variables
originales, de tal manera que no exista una pérdida elevada de información. Puede ser útil en el contexto del control de
calidad ya que ilustra con claridad las interrelaciones entre variables y permite localizar outliers (espaciales y no
espaciales) desde una perspectiva multivariante. Para ilustrar el análisis se presentan los resultados utilizando los
valores correspondientes al censo de población 2001 de las variables:
% Licenciados y doctores
Tasa de paro
% Técnicos, profesionales y científicos
% Trabajadores cualificados de la industria y construcción
% Trabajadores no cualificados
Vemos que con solo dos factores explicamos el 89% de la varianza total. La interpretación de los factores pasa por
observar las contribuciones de las variables originales: el segundo factor va en la dirección de la tasa de paro, mientras
que el primero es una combinación lineal de todas las variables pero que sitúa en direcciones contrarias los trabajos más
técnicos de los manuales siendo los valores bajos en el factor, altos en el % de técnicos, profesionales y científicos. Los
puntos situados en valores altos del primer y segundo factor se corresponderán a valores altos de tasa de paro.
En el gráfico de los factores del ACP pueden representarse tanto los individuos (en este caso secciones censales) como
las direcciones de las variables originales en relación a los factores. De nuevo en la ventana del gráfico es posible
seleccionar puntos y localizar en el mapa a qué elementos corresponden y al contrario :
Figura 11: Gráfico del ACP. Los elementos seleccionados están en la dirección de Tasa de paro y % de Trabajadores no cualificados.
Se corresponden con valores bajos de % de Licenciados y doctores.
Véase además que la tasa de paro, contribución importante al segundo factor, es casi ortogonal con el primero, aunque
está más en la dirección del % de trabajadores no cualificados. Estos resultados, que podríamos considerar obvios a
nivel global, indican que nuestros datos tienen (globalmente) una calidad aceptable.
Sobre las coordenadas en esos factores de los individuos es posible calcular el índice de autocorrelación espacial de
Moran y construir el gráfico para poder situar outliers espaciales y no espaciales en el espacio de factores del ACP,
análogamente a los cálculos realizados sobre una variable.
Un índice de autocorrelación de Moran próximo a la unidad indicara que hay zonas compactas relativas a los valores del
factor considerado. La localización de outliers espaciales en relación a los factores del ACP puede revelar anomalías en
relación al conjunto de variables que determinan ese factor. En la siguiente figura se presenta el gráfico de Moran
relativo al primer factor del ACP :
Obsérvese, en la fig. 12, que los elementos seleccionados son outliers espaciales situados en valores bajos del primer
factor que pueden interpretarse como elevado % de Licenciados, elevado % de técnicos, profesionales y científicos y
bajo % de trabajadores no cualificados. Nuestro conocimiento de los datos y el territorio nos indica que estos outliers
espaciales no lo son por una mala calidad de los datos, no obstante los métodos implementados permiten localizarlos
fácilmente.
FUTUROS DESARROLLOS
En cuanto a la arquitectura de la aplicación tenemos previsto migrar de una arquitectura en dos capas a tres, utilizando
un servidor http intermedio y las implementaciones de referencia de CachedRowSet del Api java 1.5. Se implementarán
utilidades como la generación de informes del estado de la operación y se derivará una versión específica para el
análisis de datos espaciales. Se implementará el análisis de correspondencias simples para poder analizar tablas de
contingencia de forma equivalente al ACP, con la finalidad observar la relación entre las categorías columnas
(variables) y filas (espacio) y realizar los cálculos de coeficientes de autocorrelación en relación a los ejes factoriales
obtenidos.
REFERENCIAS
1. Vivids solutions website. http://www.vividsolutions.com/
2. PostGIS website. http://postgis.refractions.net/
3. Dirección General del Catastro website. http://www.catastro.minhac.es/
4. Guttman, A., 1984, R-trees: A dynamic index structure for spatial searching. Procedings of the ACM SIGMOD International
Conference on Management of Data.
5. Institut Catogràfic de Catalunya ICC website. http://www.icc.es/
6. Java Technology website. http://java.sun.com/
7. Weka : Data Mining Software in Java website. http://www.cs.waikato.ac.nz/ml/weka/
8. Anselin, L. (1994). "Local indicators of spatial association - LISA", Techn. Rep. 9331. Regional Research Institute, West Virginia
University, Morgantown WV 26506-6825 USA.
9. JAMA : A Java Matrix Package website. http://math.nist.gov/javanumerics/jama/
Resumen: Este artículo pretende abordar los pasos a seguir, así como los problemas surgidos al resolver un ejemplo
típico de análisis espacial vectorial utilizando las bases de datos espaciales PostGIS y Oracle Spatial, siguiendo en lo
posible la especificación Simple Features for SQL (SFS) del OGC. La mayoría de trabajos realizados en la actualidad
que soportan alguna de estas bases de datos espaciales utilizan el sistema únicamente para almacenar objetos
geográficos sin aprovechar las capacidades de análisis vectorial. Se estudia también algunos problemas de
rendimiento en ciertas operaciones de análisis, todo ello con el objetivo de iniciar una debate sobre el estado actual y
la posible evolución de la especificación SFS del OGC, de forma que mediante su utilización se pueda incorporar en
una IDE un motor de análisis espacial de forma sencilla y estándar, delegando el cliente esta funcionalidad en el
servidor e incorporando en la IDE características de un software SIG de escritorio.
1.- INTRODUCCIÓN
Tradicionalmente las operaciones de análisis espacial tanto raster como vectorial se han efectuado de forma local
utilizando un software SIG de escritorio. Hace ya algunos años que las bases de datos más importantes del mercado han
incorporado extensiones espaciales, sobre todo con el impulso de la organización Open GeoSpatial Consortium (OGC)
apoyándose en la especificación ‘Simple Features for SQL’ [5]. Profundizando en esta especificación, nos abordan una
serie de preguntas que este artículo junto con su presentación oral tratará de resolver y plantear algunas de ellas para un
posible debate:
• ¿Se podría delegar en el sistema gestor de bases de datos, la capacidad de realizar el análisis espacial que
necesita un Sistema de Información Geográfica?
• Pero, ¿aporta algún beneficio que el cliente delegue el análisis vectorial en el servidor?
• ¿La especificación SFS define de forma suficientemente amplia las capacidades que debe implementar un
SGBD para poder efectuar un análisis espacial vectorial completo?
• ¿Los paquetes informáticos actuales de SIG utilizan estas capacidades?
• ¿Hacia donde debe evolucionar la especificación SFS? ¿Existe alguna normativa o alternativa más actual?
Este artículo trata de describir las herramientas más importantes que existen actualmente en el mercado, que
capacidades tienen y cómo se deben utilizar para realizar un análisis espacial vectorial. Para ello, se han seleccionado
dos bases de datos espaciales, una comercial y otra libre. PostGIS [2] (basado en PostgreSQL) es la alternativa de
software libre más avanzada, por otro lado se ha utilizado el software comercial Oracle Spatial [1] que en su versión
10.2 incorpora un amplio abanico de funcionalidades.
En la primera parte del artículo se describe brevemente un análisis vectorial sencillo y la cartografía que se necesita. A
continuación se resuelve el análisis utilizando estos dos SGBD. En una segunda parte se remarcan los puntos y
características más importantes a tener en cuenta para realizar el análisis, así como la fidelidad de estos software con la
especificación SFS. El artículo finaliza con unas conclusiones que tratan de responder a las cuestiones enunciadas
anteriormente.
El objetivo de este análisis espacial es mostrar de una forma práctica cómo se realiza el mismo utilizando dos
programas diferentes y si es posible realizar este análisis siguiendo de forma rigurosa la especificación SFS. En ningún
caso se ha querido realizar cálculos de eficacia de los algoritmos utilizados. Por lo tanto, todas las capas cartográficas
utilizadas son muy pequeñas y tienen menos de un centenar de entidades geométricas.
2.2.- Cartografía
Capa ‘suelos’ (Figura 1). Capa de polígonos formada por 43 entidades describiendo los tipos de suelos.
Esquema: (shape: polygon, tsuelo: short int {0,1,2,3})
Capa ‘usos’ (Figura 2). Capa de polígonos formada por 76 entidades describiendo los tipos de usos de suelo.
Esquema: (shape: polygon, tuso: short int {100,200,300,400,500,600,700})
Capa ‘rios’ (Figura 3). Capa de líneas formada por 106 entidades describiendo los ríos existentes. Esquema
(shape: line, trio: short int {1,2})
Capa ‘alcanta’ (Figura 4). Capa de líneas formada por 6 entidades describiendo la red de alcantarillado.
Esquema: (shape: line, id: short int {0}).
Figura 1: Capa de suelos Figura 2: Capa de usos Figura 3: Capa de ríos Figura 4: Capa de alcantarillado
Esta cartografía está depurada para que no existan vértices repetidos, polígonos con solape, vértices más próximos que
la tolerancia establecida en el análisis con Oracle Spatial, o elementos no válidos según el OGC.
En el siguiente listado aparece las sentencias SQL del análisis, en negrita aparecen aquellas sentencias no consideradas
en la especificación SFS y que son necesarias para realizar el análisis. Para simplificar el código del ejemplo, se ha
sustituido las expresiones de creación de tablas de geometría por la sentencia ‘crearTabla (tipo, nombre)’.
La importación de la cartografía se puede realizar utilizando el comando ‘shp2sdo’, que viene en el paquete de
utilidades espaciales de Oracle Spatial.
En el siguiente listado aparecen las sentencias SQL del análisis. Para simplificar el código del ejemplo, se ha sustituido
las expresiones de creación de tablas de geometría por la sentencia ‘crearTabla (nombre)’.
crearTabla (tmp1) =
CREATE TABLE TMP1 (
GID NUMBER PRIMARY KEY,
GEOM MDSYS.SDO_GEOMETRY);
Área de influencia de ‘alcanta’ 10: insert into inter (gid, tsuelo, tuso, geom)
select u.gid*1000+s.gid, s.tsuelo, u.tuso,
crearTabla (tmp1) sdo_geom.sdo_intersection (u.geom,s.geom, 0.000001)
from usos u, suelos s where
1: insert into tmp1 (gid,geom) select a.gid, SDO_FILTER(u.geom,s.geom) = 'TRUE' and
SDO_GEOM.SDO_ARC_DENSIFY (sdo_geom.sdo_buffer (sdo_geom.relate(u.geom,
(a.geom,300,0.000001),0.000001, 'OVERLAPBDYINTERSECT',s.geom,0.000001) =
'arc_tolerance=1') from alcanta a; 'OVERLAPBDYINTERSECT' or
sdo_geom.relate(u.geom,'INSIDE', s.geom,0.000001) =
crearTabla (alcantabuf) 'INSIDE');
2: insert into alcantabuf (gid,geom) select 11: create view vinter as select i.gid gid, i.geom
1, SDO_AGGR_UNION( geom from inter i where i.tuso = 300 and i.tsuelo >
SDOAGGRTYPE(a.geom, 0.000001)) from tmp1 a; 0;
Ambos sistemas disponen de un comando para la importación de ficheros en formato shape (shp2pgsql en PostGIS y
shp2sdo en Oracle), estos comandos se invocan desde la consola del sistema e importan tanto los datos espaciales como
los temáticos asociados (.dbf).
PostGIS
El comando de importación crea un único fichero .sql donde se incluyen las sentencias SQL necesarias para la creación
de la tabla y la carga (con las correspondientes sentencias ‘insert’) de cada uno de los registros.
Oracle
El comando de importación crea dos ficheros; un fichero .sql con las sentencias SQL necesarias para la creación de la
tabla y un fichero .ctl (fichero en formato de texto) con los datos de la tabla para su importación con la utilidad
sqlloader de Oracle. En los parámetros del comando shp2sdo además se debe especificar ciertos parámetros como la
extensión y la tolerancia de cada una de las dimensiones de las geometrías, información que se utiliza en la definición
de la creación de la tabla.
Aunque en la documentación de ambos productos se asegura que siguen la especificación SFS del OGC (pasando con
éxito el test de comprobación del OGC ‘Conformance Test Guidelines for OpenGIS Simple Features Specification for
SQL’ [4]), hay que realizar importantes matizaciones en este aspecto:
• Oracle Spatial efectivamente sigue la especificación pero utiliza mucho más la relajación (cambios permitidos
por el OGC) del test mencionado anteriormente, es decir, los métodos definidos en SFS (constructores de
geometría, operadores y predicados espaciales,…) tienen su correspondencia en métodos de Oracle Spatial
pero éstos tienen diferente nombre, número o tipo de argumentos. Esto es una gran limitación ya que se
necesita traducir el código SQL de Oracle si se quiere exportar a otros sistemas, incluso aunque éstos soporten
de una manera estricta la especificación del OGC.
• PostGIS sigue de una manera mucho más fiel la especificación SFS, respetando los nombres de los métodos
(salvo alguna excepción) y el número de argumentos. PostGIS almacena también la información de metadatos
de las columnas de geometría de las tablas (GEOMETRY_COLUMNS) y de los sistemas de referencia
espacial siguiendo el estándar SFS (SPATIAL_REFERENCE_SYSTEMS).
• Ambos sistemas incorporan métodos no definidos por el OGC en su especificación, pero necesarios si se
quieren realizar análisis complejos o procedimientos almacenados que incrementen la funcionalidad del
sistema. Como se verá mas adelante en el caso de PostGIS, algunos de estos métodos (que no siguen el
estándar) son necesarios para realizar incluso el análisis vectorial más sencillo.
En los enunciados previos a los listados 2 y 4 correspondientes a los análisis espaciales, se muestra la diferente forma
que tienen estos dos sistemas de crear una tabla de geometría:
PostGIS utiliza el método ‘addGeometryColumn’ (método propuesto en la SFS), que se encarga de añadir el
campo de geometría del tipo seleccionado a una determinada tabla, actualizar la información de los metadatos
contenidos en la tabla GEOMETRY_COLUMNS, y añadir la restricción de tabla, del tipo de geometría en el
campo correspondiente.
Por el contrario Oracle no implementa el método ‘addGeometryColumn’, es decir, define la tabla directamente
(cambiando además el nombre de la misma propuesto por el OGC).
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('TMP1','GEOM', MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', 0.000000000, 10000.000000000, 0.000001000),
MDSYS.SDO_DIM_ELEMENT('Y', 0.000000000, 10000.000000000, 0.000001000)), NULL);
PostGIS limita el tipo de geometrías almacenadas en una tabla (restricción de tabla sobre la columna de geometría,
fijando el tipo de ésta), aunque esta forma de trabajar (una capa agrupa entidades geométricas con el mismo tipo de
geometrías) está mas acorde con la forma tradicional, presenta ciertos problemas (problemas que Oracle Spatial no tiene
ya que no establece este tipo de restricciones en las tablas). Por ejemplo, si en una tabla de Polígonos se intenta
almacenar un Multipolígono (o al revés), el sistema dará un error de violación de una retricción de tabla. Esto puede
ocasionar como se verá más adelante la imposibilidad de realizar ciertas operaciones de análisis siempre y cuando el
usuario no se ayude de métodos no definidos en el SFS y que pueden en cierta manera solucionar este problema.
En cuanto a las incompatiblidades de métodos que no siguen la norma SFS, podemos establecer dos grupos según la
importancia de la incompatibilidad. Un primer grupo consistiría en aquellos métodos que aunque están definidos en la
especificación SFS no coinciden en nombre, número o tipo de argumentos admitidos o devueltos (aunque la relajación
del test del OGC permite cambiar el nombre a los métodos/tablas/vistas). Un segundo grupo estaría formado por
métodos del SGBD que ofrecen una funcionalidad que no existen en la norma SFS. En este segundo grupo la
incompatibildad se produce irremediablemente cuando alguno de estos métodos es indispensable para realizar una
análisis espacial común, de forma que es necesario utilizarlo y de esta manera el código SQL generado no es compatible
con la norma SFS.
4.4.1.- PostGIS
Según el Listado 2:
En el primer grupo tendríamos las sentencias que invocan a los métodos ‘BUFFER (the_geom,300,32)’ y ‘GEOMUNION
(the_geom)’. La incompatibilidad en el primer método se debe al tercer argumento (número de segmentos de los
elementos curvilíneos) no considerado en la norma SFS, mientras que el segundo tiene como nombre original en la
norma SFS union y no geomunion (PostGIS lo renombra para no coincidir con la palabra clave union de SQL).
PostGIS tiene cerca de 100 métodos que ofrecen una funcionalidad espacial extra, pero es por ejemplo el método
‘multi’, MULTI (intersection (u.the_geom,s.the_geom)), el que resulta necesario utilizar en un análisis espacial
común para solucionar el problema que se introduce a continuación:
Muchos de las soluciones libres que utilizan análisis espacial se basan en la biblioteca JTS [6]. Este es el caso de
PostGIS que se basa en la librería GEOS, que es un wrapper de JTS en C++. Para realizar el test se ha utilizado el
software JTS Test Builder [5]. En este ejemplo se va utilizar únicamente el operador espacial ‘intersection(A, B)’, este
operador devuelve la intersección entre las geometrías A y B. Para simplificar el caso vamos a considerar que A y B son
de tipo POLYGON. Como se puede apreciar en las figuras, la intersección de dos polígonos puede producir un
multipolígono (Figura 5) o una colección de geometrías (Figura 6) formada por puntos, líneas y polígonos.
Figura 5: JTS Test Builder Software. Ejemplo 1 Figura 6: JTS Test Builder Software. Ejemplo 2
Al utilizar el operador espacial de intersección (entre polígonos) se deberá tener en cuenta las siguientes características:
Estas características pueden ocasionar una violación en las restricciones de tabla de PostGIS [3], ya que PostGIS no
puede almacenar en una tabla diferentes tipos de geometrías (restricción de la norma SFS). Evidentemente se puede
aplicar una cláusula WHERE en la correspondiente sentencia SQL para filtrar el tipo de retorno de las intersecciones,
pero esto producirá una perdida de elementos que pueden ser válidos en el resultado final. La única posible solución es
utilizar el método ‘multi’ de PostGIS, para convertir las entidades devueltas en la intersección a entidades de tipo multi
(MULTIPOLYGON, MULTIPOINT o MULTILINESTRING), y almacenarlas en una capa de tipo multipolígono por
ejemplo. Aún así si se tuviera un caso como el de la figura 6, el problema no se podría resolver a menos que se realizará
un programa en algún lenguaje de servidor como pgplsql y se utilizarán aún más métodos no considerados en la
especificación SFS.
Como se puede observar en el Listado 4, todos los métodos prácticamente de Oracle Spatial se encontrarían
encuadrados dentro de lo que hemos denominado primer grupo de incompatibilidad. Por ejemplo, además de renombrar
los métodos, muchos de ellos utilizan un argumento adicional para la tolerancia de las coordenadas:
SDO_GEOM.SDO_BUFFER (r.geom,d.dist, 0.000001), y otros utilizan tipos definidos por el sistema: SDO_AGGR_UNION
(SDOAGGRTYPE(a.geom, 0.000001).
En cambio no nos encontramos con uno de los problemas que impedía a PostGIS seguir la norma SFS (orden multi). En
efecto, si nos fijamos en cómo se define una tabla de geometría en Oracle nos damos cuenta que no se especifica el tipo
de geometría y en una tabla de polígonos se pueden almacenar también multipolígonos, lo que elimina el problema que
tenía PostGIS.
Como se puede ver en los listados de código SQL de los análisis espaciales, las áreas de influencia se realizan en dos
pasos:
Estas dos operaciones normalmente en un SIG de escritorio se realizan de forma transparente en un solo paso para el
usuario, pero en realidad el procedimiento es similar.
Si las áreas de influencias se realizan con sistemas que no tengan topología explícita (al contrario que por ejemplo la
famosa estructura Arco-Nodo implementada en el formato cobertura de ArcInfo Workstation), la disolución de los
límites entre los polígonos será una operación muy costosa para el sistema. Esto es especialmente significativo si se
utilizan agregados SQL como es el caso de los sistemas estudiados que van acumulando tantas uniones de elementos
como entidades existen en la capa. En efecto, la creación de las áreas de influencia sobre capas con varios miles de
elementos colapsa a estos sistemas y a otros paquetes SIG tan conocidos como por ejemplo ArcGIS de ESRI.
Además al utilizar un agregado el resultado consiste en un único macropolígono, con lo cual se pierde todo el beneficio
de la indexación espacial en operaciones posteriores.
Soluciones parciales pasarían por realizar buffers segmentados lo cual incrementaría la eficacia del sistema (Listado 5),
o realizar procedimientos almacenados que calcularan las áreas de influencia únicamente de polígonos disjuntos, o con
un número máximo de polígonos. Estas dos últimas soluciones aumentan enormemente la eficiencia de estos algoritmos
(aunque no pueden en ningún caso igualar a sistemas con topología explícita) haciendo posible el cálculo de áreas de
influencia de otra forma inviable en capas con un alto número de elementos geométricos. Pero otra vez el coste pagado
sería el apartarse de la especificación SFS.
5.- CONCLUSIONES
En cuanto a la compatibilidad de los dos SGBD espaciales estudiados con la especificación SFS del OGC, PostGIS
sigue mucho más fielmente la especificación que Oracle Spatial, pero este último es más fácil de manejar al no tener
que comprobar constantemente los tipos de las geometrías devueltas para evitar errores de violación de las restricciones
de tabla. De esta forma, para realizar un análisis espacial común y sencillo se necesita utilizar funcionalidades extra no
recogidas en la especificación SFS como el método ‘multi’ de PostGIS o directamente no seguir las especificaciones en
la definición de las tablas como hace Oracle.
Aún queda pues trabajo por realizar para poder delegar la funcionalidad de análisis espacial en el servidor, por lo menos
si se quiere seguir la especificación SFS. Aunque existen opiniones a favor del sistema tradicional de efectuar el análisis
en local (en el cliente), personalmente nosotros pensamos que el futuro pasa por implementar de forma óptima esta
funcionalidad en el servidor, lo cual aportaría muchas ventajas como: mantenimiento de equipos, coste de licencias,
incremento en la separación lógica de la estructura cliente-servidor en un SIG, partir de una base común más amplia en
la elaboración de SIG de escritorio, etc. Todo esto repercutiría en dotar de servicios de análisis espacial a un cliente
SIG, y en acercar la posibilidad de crear un Web SIG totalmente operativo utilizando protocolos estándar. La aplicación
quizás más espectacular consiste en dotar a una IDE de un completo análisis espacial y uno de los objetivos finales es
quizás obtener un SIG profesional a través de la Web.
Pero todo esto aún no es realidad ya que como se ha comentado anteriormente queda trabajo por hacer (sobre todo si
hablamos de protocolos estándar y software libre). En efecto, actualmente los software SIG no utilizan estas
capacidades de análisis espacial en la parte del servidor (a excepción de unos pocos productos comerciales, de muy alto
costo, y bajo sistemas no compatibles con OGC), como mucho, son capaces de leer directamente de PostGIS (otros solo
se limitan a importar o exportar la información a PostGIS) y realizar operaciones de análisis vectorial en el cliente
(convirtiendo los datos a un formato interno o al formato de las bibliotecas que utilicen como las JTS).
Existen ciertas funcionalidades espaciales que se pueden beneficiar de un modelo de topología explícito si están
correctamente implementadas, como las áreas de influencia. La topología explícita debe ser obligatoria ya que además
de evitar redundancia de datos y añadir conectividad, acelera enormemente ciertas operaciones de análisis espacial
vectorial que de otra forma podrían llegar a ser inviables. Actualmente no existen bibliotecas libres que implementen un
modelo de topología explícito aunque ya se está trabajando en bibliotecas como GeoTools. En cuanto a PostGIS,
actualmente se está implementando un modelo de topología basado en la norma ISO 13249 (SQL/MM parte 3). Aunque
una base de datos espacial con un modelo de topología explícito beneficia en gran medida las operaciones de análisis
espacial, puede perjudicar de forma también apreciable la lectura de un gran número de elementos cartográficos
(operación común en el renderizado de los servidores de cartografía) ya que las entidades se deben formar a partir de las
topologías integrantes cada vez que se solicita un elemento. En estas operaciones intervienen relaciones transversales
entre elementos que se deben implementar bajo un gestor de bases de datos objeto-relacional (SQL3) que implemente
de forma eficaz estas características.
REFERENCIAS
Reumen: En la DUOT se viene trabajando con información territorial desde 1999. En el 2001 se inició una
perspectiva integradora de intercambio de información y análisis que coordine la información territorial y
cartográfica, para mejorar la recogida, difusión de datos e intercambio entre organismos administrativos generadores
de información.
• El diseño de un modelo de datos, estructura organizativa de la información territorial que la clarifica, agrupa
y ayuda a su exploración y visualización.
• El catálogo de información, para conocer y centralizar la información acerca de la información (metadatos)
que reside en el sistema actual
• El protocolo de carga para mantenimiento, explotación y actualización de dicha información, integrada en
una plataforma SIG.
El sistema se ha ido ajustando en diseño y estructura teniendo en cuenta los estándares de metadatos definidos en el
ámbito europeo.
La Dirección con competencia en Urbanismo y Ordenación del Territorio de la Junta de Extremadura, ha ido
desarrollando durante la última década, diversos trabajos tendentes a optimiza sus bases de datos de Cartografía,
Urbanismo y Territorio con objeto de prestar un mejor servicio a los ciudadanos y facilitar la planificación territorial.
Entre ellos cabe destacar el diseño e implantación de un Sistema de Información Geográfica que permitiera la captura,
mantenimiento, análisis y exportación de la información geográfica y alfanumérica.
Los primeros pasos se dirigen a la producción de cartografía regional y la definición de su estructura, como base del
resto de atribución de competencias de la Dirección General. En paralelo se va desarrollando el planeamiento
urbanístico con toda la labor administrativa que arrastra con la CUOTEX (Comisión Regional de Urbanismo
Arquitectura y Ordenación del Territorio de Extremadura). El subsistema de territorio aunque se concibe desde el
principio, como tercer pilar del sistema, se entiende como un subsitema receptor de información que permite la
superposición de capas de información para interrelaciones entre diferentes variables.
El Sistema de Información Geográfica, Cartografía y Análisis Territorial (SIGCAT) se asienta sobre tres módulos
temáticos fundamentales: Cartografía, Urbanismo y Territorio.
No se trata de compartimentos estancos, sino de módulos que interactúan entre sí pudiendo explotar la información de
cada uno de ellos de forma integrada, de forma que puedan obtener valores añadidos al inicial de cada uno de ellos. Hay
que señalar que en varios casos y en todas las áreas temáticas, se han producido procesos de ida y vuelta. Una vez
iniciado un camino, se ha dado marcha atrás, al no conseguir el resultado esperado, o por que los condicionantes de
partida cambiaron por innovaciones tecnológicas, por nuevos condicionantes externos o por intentar conseguir mayores
prestaciones en los resultados a obtener.
Durante los primeros años, en el módulo de territorio los objetivos fueron la carga de datos procedentes de diferentes
estudios territoriales encargados a distintas Asistencias Técnicas que elaboraban metodologías y procesos diferentes. Se
trataba de cargas heterogéneas y desestructuradas que nos hacía difícil la gestión interna de los datos.
El reto de este subsistema era la integración de datos de diferente naturaleza y gestionar toda la información procedente
de la totalidad de base de datos del sistema. La dificultad de la unificación de toda la información es la heterogeneidad
de los datos que se pretenden manipular. Se vio la necesidad de documentar los datos, y las inconsistencias entre ellos
para ver los criterios que se van a seguir y la calidad de los datos. Necesitábamos, normalizar la información y poseer
una estructura mínima de contenidos.
El modelo de datos de Smalworld era cerrado y no permitía el mantenimiento de información, la carga de datos
mediante código necesitaba operadores de alto conocimiento informático. Era preciso pasar a un modelo abierto, dotado
de herramientas de carga de información gestionadas por personal de la Dirección para automatizar la recolección y
manejo de numerosos datos georreferenciados.
La incorporación al sistema nuevas herramientas de análisis, hizo patente la necesidad de ver procedimientos con los
que se han elaborado los datos y en especial aquellos que incluían la variable temporal.
Para el intercambio de información, se prioriza a nivel regional, el apoyo a la cooperación (mediante acuerdos de
colaboración) entre organismos para el uso SIG (administración regional, instituciones de investigación, empresas etc..)
y. con aquellas Direcciones Generales e Instituciones más relacionadas con la generación de datos de gestión territorial
o aquellas a las que por atribución de competencias esté vinculada a temas específicos considerados de interés regional.
Por otra parte, los distintos proyectos transfronterizos que se están desarrollando en esta Dirección General nos plantea
coordinar y plantear métodos y propuestas de trabajo para la disponibilidad de datos comparables, cuantificados y
georreferenciados. Así se llega a la coordinación de nomenclaturas y compartir un modelo de datos y un sistema de
indicadores.
TIPO DE HERRAMIENTA
CARTOGRAFIA CODIFICACION
PROPIA
CARGADOR
ORTOFOTOS
CARTOGRAFIA TRADUCTOR
CARTOGRA
CATASTRAL CATASTRAL FIA BASE
PLANEAMIENT MODELO DE
DATOS SEGUIMIENTO O GENERAL DATOS DEL
ADMINISTRATIVOS PLANEAMIENTO TERRITORIO
PLANEAMIENT VISUALIZADOR
PLANEAMIENT
O RASTER O DE
PLANEAMIENTO HERRAMIENTA
DE DISEÑO
Figura DESARROLLO ESTUDIOS
TERRITORIAL
DIGITAL
1: TRAMITACIÓN ES
ADMINISTRATI
CONEXIÓN BASES
BASES EXTERNAS
EXTERNAS
VA
PLANIFICACI
ESTUDIOS CODIFICACIÓN Y ON
TERRITORIALES TRADUCTOR
FACILIDAD DE CONSULTA
Con las diversas aplicaciones desarrolladas hasta el momento el actual sistema se caracteriza por cumplir los requisitos
y prestaciones
• Se concibe como un sistema abierto para lo cual era fundamental la compatibilidad de los datos y la
interoperabilidad con otros sistemas existentes en las instituciones regionales. Se intenta garantizar la
conectividad del SIGCAT mediante la implementación de mecanismos y formatos de intercambio de datos con
suministradores y usuarios de interés, previa la sistematización y normalización de la información.
• Dinámico. Ajustándose a las necesidades cambiantes. La herramienta de trabajo Smallworld, que resulta ser
algo compleja, por tener un carácter “abierto”Gracias a esta característica tenemos la posibilidad de desarrollar
funcionalidades especificas de forma gradual y adaptadas a nuestras necesidades concretas, no limitándonos a
las aplicaciones generalizadas que proporcionan otras herramientas pero si permitir la operabilidad de estas
con el SIGCAT CORE mediante importadores, exportadores y transformadores, como en el caso de la
utilización de Base de Datos externas realizadas en Access, la importación de SHAPES, DXF y la utilización
del sistema ERDAS Imagine para las operaciones de análisis sobre información raster.
• Integrador de la información Territorial, Por un doble motivo
o integra la información elaborada por distintos productores regionales
o mediante la homogenización de los procedimientos y nomenclatura del sistema.
• Con referencias geográficas normalizadas, gracias a la normalización del modelo de datos de cartografía,
consiguiendo la unificación y estandarización de la cartografía regional.
• Instrumento técnico de la Administración Extremeña. para el conocimiento, diagnóstico y la ordenación del
medio físico y social de la Comunidad. Herramienta de Planeamiento.
• Gestor de la información territorial. Herramientas de análisis, a partir de las cuales fundamentar la intervención
en el territorio con datos comparables, cuantificados y georreferenciados.
• Difundido Con el deseo de facilitar al ciudadano, administraciones y empresas el acceso a la información
geoespacial.
o mediante el catálogo de datos. Facilitando a los usuarios la localización y el conocimiento acerca de la
disponibilidad de la información existente en la AEVUOT (agencia Extremeña de la Vivienda, el
Urbanismo y el Territorio).
o Espacio Web de trabajo común. Con el fin de facilitar la comunicación y la colaboración entre los
distintos actores que se relacionan con la AEVUOT
El Sistema de Información Territorial de la Dirección de Urbanismo y Ordenación del Territorio (DUOT) persigue la
normalización de la información, estructurada en un modelo de datos jerarquizado en dominios, temas, variables y
tablas, con una amplitud temática en relación con una nomenclatura inicial diseñada desde la propia DUOT a partir de
la estructura de la información procedente de los estudios territoriales existentes y por cotejo con las experiencias
disponibles sobre modelos de datos de otros sistemas generadores de información territorial; se siguen, además, las
orientaciones sobre contenidos temáticos básicos de la información derivada de los criterios de clasificación territorial e
indicadores recogidos en la ETE1.
Es un sistema de información concebido como abierto y flexible, tanto por la propia estructura del modelo como por la
propia dinámica de revisión, actualización y accesibilidad de la información en la actualidad
En esta fase es posible distinguir distintos objetivos que se suman a los ya indicados:
1 La Estrategia Territorial Europea nace de la inquietud de los estados miembros de alcanzar el objetivo de un desarrollo armonioso y
equilibrado para Europa conservando una visión global del conjunto que ayude por tanto a la toma de decisiones que afectan al
ámbito local"Se considera esencial establecer la tipología de las distintas subregiones de Europa con arreglo a criterios que puedan
transponerse de una realidad nacional (o regional a otra). A partir de ahí las entidades soberanas en su territorio pueden comparar sus
tipologías, las políticas e instrumentos que ya aplican y, finalmente, iniciar nuevas gestiones... "pág. 44 y continúa "Se debería
elaborar una serie de indicadores que permitan seguir y evaluar los efectos positivos de la difusión del conocimiento y la innovación
"pág.46 Dictamen del Comité de las Regiones sobre la Perspectiva Europea de Ordenación del Territorio (1999/c93/07).
El modelo de información intenta catalizar y nutrirse de la producción informativa generada por la propia DUOT y la de
otros organismos de la Administración, especialmente la autonómica pero también se mantienen contactos con otros
organismos y centros administrativos de índole estatal (Centro Meteorológico Zonal de Extremadura, Confederaciones
Hidrográficas, MMA, etc.), regional (Gerencia Territorial de Catastro) e incluso local (Diputaciones provinciales de
Badajoz y Cáceres).
Una vez recopilada la información se realiza una revisión de la misma para depurarla y adaptarla a los contenidos del
modelo, es decir, “filtrada” para definir categorías o valores determinados en relación con las necesidades y criterios
propios de la DUOT –y su definición regional-. Dicho filtro se acompaña de un proceso descriptivo (que entronca con
la elaboración de metadatos): con una ficha general de contenidos y una ficha descriptiva de los contenidos
informativos seleccionados para el modelo.
En términos temáticos, la normalización de la información sobre territorio diseña las líneas básicas de la estructura de la
información territorial, como contenidos mínimos de base para los estudios, instrumentos y herramientas de
planificación territorial con validez para todo el territorio regional, destinada a la agilización y automatización de las
tareas de generación, carga y comunicación de la información. En este sentido, está muy avanzado el diseño y
elaboración de una herramienta específica que facilita las tareas de carga y sistemática de contenidos de la información
y normativa incluida en distintos instrumentos de planeamiento (desde la escala local –HDPU, Herramienta de Diseño
de Planeamiento Urbanístico- a la territorial). Esto permitirá la integración de información a distintas escalas: regional
(base regional de referencia), supramunicipal (a medida que se vayan realizando Planes Territoriales con ese ámbito) y
local (a partir del planeamiento urbanístico municipal –desde la mencionada HDPU-)
• La localización de la información, que necesita del contacto y el intercambio entre distintas administraciones y
sus escalas. Desde la DUOT se plantea siempre el intercambio con alguno de los productos específicos de la
misma (especialmente la cartografía digital 1:10.000).
• Los distintos criterios con que desde estos ámbitos administrativos orientan la información, a partir de sus
necesidades concretas; aunque, en general, suele partirse de unos modelos descriptivos generales de ámbito
regional, como modelos de base, si bien a veces entrañan diferencias conceptuales, terminológicas y, también
ocasionalmente, duplicidades.
• No menos importante es la cuestión de la calidad de la información; en buena medida ha ido en consonancia
con la propia difusión de la tecnologías de la información, con requerimientos específicos de formatos y
precisiones más detalladas per se, tanto en la fase de adquisición de información como en su tratamiento.
• Otra cuestión es el formato en que se presenta la información, habitualmente poco problemático porque, en
general, está bastante estandarizado y difundido el uso de shape o E00) (aunque nuestro sistema requiera un
proceso de calibrado y ajuste específico – protocolo-).
Para automatizar los procesos de entrada y salida de información de Territorio en el Sistema de Información
Territorial, se ha dotado de una serie de herramientas de importación/exportación cartografía digital y bases de
datos.
Se trata de una herramienta para la carga de cartografía digital en formato DGN con información alfanumérica
asociada a una base de datos Access (MDB), así como la importación de cartografía catastral procedente de la
Gerencia Territorial de Catastro. Como complemento a estas herramientas de importación y con el propósito de
garantizar la calidad de la información importada, esta herramienta que valida dicha cartografía y permite
identificar aquellos errores geométricos, topológicos existentes en los ficheros cartográficos proporcionados tanto
por las empresas subcontratadas como por Catastro y asegura la correcta estructura de los datos proporcionados.
Desde el punto de vista funcional la aplicación presenta las siguientes funcionalidades:
• Importación de cartografía en formato DGN con la base de datos asociada, como en formatos SHP.
• Exportación de los errores encontrados en un fichero de cartografía en formato adecuado al fichero que se esté
validando (DGN o SHP).
Todas las bases de datos en un formato digital cualquiera deben adaptarse al modelo de datos oficial del SIGCAT.
Como requisito básico para la integración de los datos alfanuméricos hay que construir una fuente de datos FDI
almacenada en un fichero Access información.dat. En esta base de datos existen cuatro tablas prefijadas, tres de las
cuales contendrán información fija cargada desde un principio con información relativa a la estructura jerárquica en la
cual está dividida la información territorial y que corresponde con la estructura existente en el SIGCAT (Dominio,
Tema Variable, Tabla). Tan sólo la tabla será actualizada con un registro nuevo por cada una de las fichas informativas
nuevas que se introduzcan en el sistema., deberá existir un registro por cada tabla creada y la correspondencia de
códigos para su correcta creación en la lista de elementos de territorio.
Existen tres campos fijos que deben existir en todas las tablas que se creen. Estos campos son
Identificador _FINF, el cual será de tipo Autonomérico, descripción de tipo texto y observaciones de
tipo Memo.
A continuación se insertan los parámetros para esa ficha del siguiente modo:
i. Si el valor del campo es un texto largo, se introduce un campo de tipo Memo con el
nombre de dicho campo.
ii. Si el valor es un texto corto, se introduce un campo de tipo Text con el nombre de dicho
campo.
iii. Si el valor del campo es numérico se introduce un campo de tipo Numérico , otro campo
con el mismo nombre junto con la cadena_”Medida” de tipo Texto y por último se
introduce un campo para observaciones de tipo Memo.
III) Intersección del registro de tabla. Consta los siguientes campos:
Identificador_Padre: Código concatenado de Domino, Variable y Tema (separado por puntos) al que
pertenece la tabla.
Nombre: se trata del nombre de la tabla (que coincide con el nombre_tabla introducido en el paso
anterior).
IV) Intersección de la ficha guía (opcional). Copia del fichero HTML con la ficha guía en el directorio
documentación/ayuda.
Se añade un formulario principal para las fichas de metadatos con información referente a la procedencia
de los datos de las fichas de información.
Para el control de contenido se elaboran fichas guía de información que se insertan en la herramienta de diseño de
planeamiento vinculadas a los elementos geográficos y se acuerda un modelo de metadatos para la carga, de modo que
se puedan realizar comparaciones rápidamente.
El usuario manipula el DBF para que se corresponda con los datos del ámbito y de la ficha, realizando un mapeo entre
lo que se lee del DBF y lo que se puede almacenar en el SIGCAT. Los parámetros dbf que no sean mapeados se
interpretan como campos de parámetros y para la correcta interpretación de los mismos es necesario que el usuario
transforme la base de datos de manera que cumpla lo siguiente:
• Añadir a los parámetros de tipo texto, además un campo que contiene el valor, deberá existir otro con igual
nombre pero con sufijo_”obs”
• En cuanto a los parámetros de tipo numérico además del campo que contiene el valor, deberá existir otro con
igual nombre pero con sufijo _”med” y otro con sufijo _”Obs”.
Como conclusión al trabajo de normalización y al desarrollo del protocolo de captura y carga de información , y en
relación con los Instrumentos de Paneamiento Territorial se está diseñando una herramienta en soporte informático que
haga posible la introducción de datos y el control normativo que será facilitada a los equipos que acometan la redacción
de Planes Territoriales. Sobre esta herramienta que incorpora el modelo de datos descrito se irá volcando la información
territorial. Permite a los equipos redactores registrar la información de los planes territoriales en un formato y estructura
único.
D.U.O.T
EQUIPOS
REDACTORES
PLANEAMIENTO
CD-ROM
HERRAMIENTA DISEÑO
DE PLANEAMIENTO
HERRAMIENTA DE DISEÑO DE
PLANEAMIENTO HDPU
PLANOS Y NORMATIVA
MEMORIA
CARTOGRAFÍA INFORMACION
BASE TERRITORIAL
CD-ROM
CARGADOR
PLANEMIENT
PLANEAMIENT
PLANEAMEINTO O DIGITAL PLANEMIENT
O
HDPU
BD SIGCAT CARGADOR
TERRITORIO
La exportación de cartografía de territorio se lleva a cabo mediante el uso de una herramienta específica que genera
ficheros de intercambio en formato Shape que se ajustan al modelo de datos definido.
CATÁLOGO DE DATOS
En el 2001 se abrió un nuevo eje de acción, con vinculación a la medida FEDER de Sociedad de la Información
que ejecuta la DG mediante fondos Estructurales (2000-2006). Se pretende que el Sistema asuma una nueva
función integradora de intercambio de información y análisis que coordine la información territorial y cartográfica
en el ámbito local, regional, nacional y europeo, como instrumento básico que permita mejorar la recogida y
difusión de datos, así como la incorporación de nuevos datos y en la difusión de los mismos al mayor número de
usuarios externos.
Los objetivos de la medida nos llevan a la creación de un nuevo servicio para la administración pública como
Observatorio Territorial cuyo cometido sería la prestación de información por medios electrónicos como canal de
distribución para los consumidores (información alfanumérica cartográfica y geográfica) y la explotación de
Internet e intranet para el desarrollo del intercambio electrónico de datos.
Con todos estos frentes abiertos se aborda la definición de una herramienta fundamental, el catálogo de
información de SIGCAT, para conocer y centralizar la información acerca de la información (metadatos) que reside
en el sistema actual, que facilita:
Los últimos años las contrataciones de los trabajos necesarios para continuar con el desarrollo y la difusión del
sistema de información geográfica han priorizado: el estudio de las posibilidades de desarrollar e y la consolidación
de un régimen permanente de intercambio de información y análisis que permita la transferencia de información
territorial con la implantación en la web de un espacio de trabajo común entre distintos organismos. Se está
procediendo a la difusión mediante internet del uso de funcionalidades del SIGCAT y de las bases documentales
disponibles en la dirección. y los estudios territoriales contratados hasta la fecha.
La Dirección de Urbanismo y Ordenación del territorio trabaja sobre una línea de actuación para establecer una
infraestructura espacial de datos con la intención de coordinar la formación de la infraestructura de datos regional.
La iniciativa parte de efectuar en paralelo una recopilación de los datos geográficos regionales disponibles con la
generación de metadatos de sus propios productos (Mapa topográfico de Extremadura, Ortofotos, Modelos
Digitales del Terreno, Imágenes Satélite, Fotografía Aérea y Digital, Plantes Territoriales y urbanísticos,
Calificación Urbanística y Aáreas Temáticas y Estudios Territoriales) .
En un primer momento se integran los metadatos directamente en nuestro sistema, se guardan como ficheros xml
de modo que se puede capsular de un mismo objeto un fichero y la ficha de metadatos, ofreciendo cada fichero con
su descripción.
Hasta el momento la elaboración de los metadatos se reducía a la trazabilidad de los datos para la carga del
modelo de territorio y a la generación de planes territoriales y urbanísticos. Se utiliza como una herramienta de
escritorio para documentar los datos y facilitar la gestión de los mismos a nivel interno en caso de detectar un
problema en los datos generados o cuando surgen dudas de interpretación de alguno de los datos o productos. El
intercambio de información al resto de instituciones, equipos redactores y usuarios de Información Geográfica se
producía sin su difusión electrónica.
La herramienta no estaba preparada desde el punto de vista de las búsquedas, facilitando la localización y
recuperación de información. Las nuevas necesidades detectadas plantea un proyecto de mejoras para dar de alta
los metadatos de la Información Geográfica de la Dirección de Ordenación del territorio en el catálogo de datos del
que disponemos; catálogo de metadatos con buscador y visualizador de los mismos.
Para metadatar nuestros productos se va a optar por una aplicación de metadatos orientada a internet basada en
estándares abiertos que permitirá a la Agencia una mejora en el intercambio de sus datos cartográficos y asegurará
los pasos hacia una Infraestructura de datos Extremeña por extensión a la catalogación de información geográfica
regional.
Para la catalogación de información geoespacial que procede de otros productores regionales, se utilizará un gestor
de metadatos externo. Se ha elaborado una hoja de cálculo EXCEL que contiene el esquema y modelo de datos
conforme al estándar de metadatos. A los ítems recomendados por el NEM, sumamos un subconjunto elementos de
la norma ISO 19115 para cubrir las funciones de distribuidor de cartografía regional (los ítems de distribución,
formato y opciones de transferencia) y recoge otros elementos que se han propuestos en el Plan Nacional de
Ortofotografía Aérea (exigidos en el pliego de prescripciones técnicas) que cubren las carencias localizadas para
los productos raster. La plantilla Excel se ha dividido en hojas según las secciones de identificación general
referente al metadato, calidad y atributos de los datos (contenido, localización, representación…). Se asegura la
incorporación a la administración del catálogo con la exportación al formato xml.
Desde la sección de Ordenación del Territorio se define la plantilla de metadatos de las distintas fuentes de
información cargadas en el SIGCAT y se va a contactar con los organismos de los datos de su competencia para
que nos faciliten todo tipo de información que ayude a cumplimentar los ítems contenidos en el perfil de la IDE
regional. Se opta por la centralización del trabajo en un primer momento para acostumbrar a las administraciones y
empresas a la generación de los metadatos y familiarizar a los responsables con el sistema y el catálogo de datos
que está en funcionamiento en el SIGCAT en el que se ha normalizado la información territorial regional. Una vez
completada la hoja de cálculo se reenviará a los productores para su validación y posterior difusión en web.
En el futuro, los actores encargados del mantenimiento de los datos, serán los que actualicen los metadatos. Para lo
cual se marcarán en los protocolos de intercambio de información como uno de los requisitos mínimos, suministrar
la información de metadatos ajustándose a la jerarquización de la hoja Excel enviada, además de matizar el tipo de
datos suministrados, la periodicidad con la que se suministra la información, los canales, medios y formas para
transmitir información.
No se descarta la utilización del software recomendado por el NEM para la captura y validación de Metadatos
(CatMdedit) una vez que se solucionen los fallos de programación, los problemas de huso detectados y la
importación/exportación a formato xml.
El objetivo final será ampliar nuestro geoportal con un conjunto mínimo de servicios IDE catálogo, nomenclátor,
WMS que presente la Infraestructura de Datos Extremeña siguiendo las especificaciones definidas por el OGC y
aumentar el catálogo de metadatos que en la actualidad presenta la IDEE.
Figura 3: En el portal de la DUOT existe una aplicación SIG (Sistema de Información Geográfica) con posibilidad de consultar
cartografía de Extremadura. Herramientas de zoom, selección, desplazamiento, activación, desactivación de capas y
localización.Visualización de Imágenes Satélite, con posibilidad de imprimirlas, enviar por correo electrónico, medir, elegir la escala
y mapa de situación interactivo.
Resumen: Actualmente la documentación de la base no hace uso directo de los estándares internacionales. Se están
reelaborando las especificaciones para incorporar los estándares de la serie ISO19100 en su descripción. Se ha
desarrollado un modelo UML (basado en ISO19109) con las características básicas de los fenómenos de la base y se
ha concretado un esquema XML (base para un catalogo de fenómenos). Se han usado transformaciones XSL para
obtener diversas visualizaciones. Paralelamente se ha realizado un esquema de aplicación GML (ISO19136) basado en
el catálogo de tipos de fenómeno que permite exportar las instancias de la base a documentos GML para intercambio
de información. Esta comunicación describe como se han llevado a la práctica todos estos estándares de manera
integrada exponiendo como se han realizado ampliaciones como la capacidad de cumplimentar la documentación en
diversos idiomas, característica esencial en el contexto de una infraestructura de datos española.
MODELO PREVIO
Las especificaciones de la Base topográfica 1:5000 de Catalunya v2.0 (BT-5M) son un indicador de la calidad del
producto en la medida que muestran sus características de forma que el usuario disponga de la información suficiente
para saber hasta que punto satisface sus necesidades. El conjunto de documentos que configuran las especificaciones de
la BT-5M son:
• Las especificaciones técnicas: Describe las características técnicas generales de la base: marco de referencia,
modelo de datos, contenido, fuentes de información y método de captura, organización física de los datos,
distribución, calidad y metadatos [1].
• El diccionario de datos: Describe de manera detallada los tipos de objeto que modelan los entes topográficos
del mundo real: nombre, código, definición, atributos, método de obtención, criterios de clasificación, criterios
de selección aplicados, combinaciones previstas de atributos y relaciones establecidas entre ellos [2].
• Las especificaciones de formato: Describen las características técnicas de la implementación del modelo de
datos y de la codificación, organización y distribución de los datos según el formato en el que se entregan.
Estos documentos describen con precisión la base topográfica, pero no hacen uso extensivo de los recientes estándares
internacionales. Los tres documentos se distribuyen en catalán y castellano y el primero también en inglés. Esta
comunicación describe como se han replanteado estas especificaciones para incorporar en su descripción los estándares
19109, 19110 y 19136 tanto a nivel conceptual como práctico.
La terminología utilizada en las especificaciones de la base, cuya versión inicial es de 1999, no coincide siempre con la
que establece la versión española de las normas ISO 19100 que están en proceso de traducción. Por consistencia con la
documentación actual de la base, el artículo utiliza la terminología actual de la base: “objeto” en lugar de “fenómeno”,
“diccionario de datos” en lugar de “catálogo de fenómenos”y “modelo de datos” en lugar de “modelo de aplicación”.
Especificaciones Técnicas
Modelo de datos
La representación de los entes topográficos del mundo real se realiza a través de objetos (fenómenos) a los que se les
asocia una representación geométrica. Un mismo tipo de objeto se puede representar con más de un tipo de
representación geométrica, por ejemplo en función de sus dimensiones o del valor que toman los atributos.
Cada objeto tiene un nombre, unos atributos que lo caracterizan (atributos calificadores) y unos atributos que aportan
otras informaciones del objeto (atributos complementarios) pero que no lo calificaron desde el punto de vista de la base.
Cada una de las diferentes combinaciones de atributos calificativos se denomina ‘caso’.
El modelo de datos contempla la existencia de objetos, llamados complejos, formados por otros objetos de la base,
entre los que puede estar el propio objeto, por ejemplo líneas compuestas o polígonos formados por líneas de borde.
La definición de la base fija la estructura espacial de los datos, que se refleja en las relaciones de conexión y prioridad
establecidas y especificadas en el Diccionario de Datos. Se consideran dos tipos de conexiones: conexión 3D y 2D,
según si se garantiza la coincidencia de las coordenadas X, Y y Z o sólo X e Y. Por otro lado la definición de la base
establece que no puede haber líneas duplicadas o líneas compartidas entre objetos. En su lugar se definen relaciones de
prioridad que determinan el objeto y caso a que se asignan cuando pertenecen a más de un objeto. Dicho de otro modo,
una línea común a más de una ocurrencia de objeto nunca se duplica, tan sólo existe una vez en el objeto y caso que
indican las prioridades.
Diccionario de datos
El Diccionario de Datos describe de manera detallada los tipos de objetos que modelan los entes topográficos del
mundo real en la BT-5M v2.0. La definición de la base establece un nombre y un código para cada tipo de objeto.
También establece los atributos que lo caracterizan, su nombre, el conjunto de valores posibles, así como los casos y
sus códigos. Para cada tipo de objeto se proporciona además su definición, el método de captura y clasificación, los
criterios de selección aplicados y las relaciones que se establecen entre distintos objetos o casos. En la tabla 1 se
muestra el contenido y formato de las fichas descriptivas de cada objeto presentes en el Diccionario de Datos.
Los valores posibles para la Geometría son punto, línea y polígono. Un mismo tipo de objeto se puede representar por
más de un tipo de representación geométrica. Un objeto con representación geométrica de tipo polígono es siempre un
objeto complejo, el contorno del cual está compuesto por otros objetos con representación geométrica de tipo línea.
Generalmente, y como objeto lineal, él mismo forma parte de este contorno.
Tabla 1: Contenido y formato de las fichas descriptivas de los objetos descritos en el Diccionario de Datos
Para cada atributo se detalla su nombre y descripción. Para los de dominio fijo, además, se describen los valores
posibles, los códigos asociados a estos valores y su descripción. Para los de dominio variable, además, se describe la
variable que se mide, la tipología del campo y la descripción de la variable. Las relaciones establecidas para el objeto (o
distintos casos del objeto) pueden ser: conexión 3D, no conexión 3D, conexión 2D, prioridad, INV (prioridad). La
Tabla 1 muestra el contenido y formato de las fichas descriptivas de los tipos de objeto descritos en el Diccionario de
Datos. Este documento también incorpora algunos diccionarios usados para la codificación de los grupos y códigos de
los topónimos.
ANTECEDENTES
La mayoría de los ejemplos que hemos encontrado de trabajos similares se centran en la generación de un esquema de
aplicación y en la distribución de datos. En ninguno de los casos estudiados se genera un modelo completo de
distribución de datos de manera integrada, esto es, todo el proceso desde la generación de los modelos UML de los
datos y la descripción de los tipos de objeto que posteriormente se reutilice o se vincule a los esquemas de aplicación y
de los documentos XML de distribución de los datos.
OS MasterMap es un mapa digital inteligente diseñado por Ordnance Survey (la agencia cartográfica de Gran Bretaña)
para el uso con sistemas de información geográfica (GIS) y bases de datos. Incluye información topográfica en todos los
fenómenos de paisaje - edificios, carreteras, cabinas de teléfono, buzones, hitos - y representa una evolución
significativa de la cartografía tradicional. OS MasterMap describe el mundo real digitalmente y presenta esta
información completa, avanzada en una serie de capas, cada una con millones de fenómenos. Ordnance Survey utiliza
GML para codificar las capas de datos vectoriales de OS MasterMap [3].
Este proyecto se desarrolla por The United Kingdom Hydrographic Office (UKHO) en asociación con Galdos Systems
Inc. y ha producido una versión inicial de esquemas GML para las cartas electrónicas de navegación (Electronic
Navigational Charts, ENCs). La intención es la de favorecer la adopción del estándar GML en el campo de la
hidrografía y la navegación para ayudar a la interoperabilidad entre datos producidos por diferentes organismos [4].
The International Hydrographic Organization (IHO) es una organización intergubernamental técnica y consultiva que
se creó en 1921 para asegurar la seguridad en la navegación y la protección del medio marino. Este organismo generó
un formato de transferencia para la distribución de datos hidrográficos digitales. La versión 3.1 es la actualmente
vigente, aprobada en noviembre de 2005. Se está preparando la versión 4.0 (se espera que sea aprobada a finales del
2006) que considera la distribución de datos en formato GML. Este trabajo es todavía preliminar y no hemos tenido
acceso a los esquemas de aplicación [5]. A pesar de la similitud en los nombres ambas iniciativas no están relacionadas.
OBJETIVOS
Nuestro objetivo principal es el de elaborar una versión de las especificaciones de la Base topográfica 1:5000 de
Catalunya y desarrollar un prototipo para la distribución de datos en GML en base a las normas o borradores
ISO19107, ISO19109, ISO19110 y ISO19136.
Se pretende generar no tan sólo los esquemas de aplicación para la distribución de datos en formato GML sino también
la generación de un modelo UML de esta base topográfica, integrado con estos esquemas, que permita:
• Describir las características generales del tipo de objeto de la base topográfica, contenidas en el documento de
las “Especificaciones Técnicas”
• Describir detalladamente cada uno de los tipos de objeto concretos que existen en la base topográfica,
equivalente a anterior documento “Diccionario de Datos”
• Elaborar una descripción concreta de los tipos de objeto GML (plasmado en un esquema de aplicación GML),
equivalente a los anteriores documentos de especificaciones de formato
• Distribuir datos en formato GML como alternativa a los anteriores formatos de distribución de los datos
Los puntos anteriores permiten formalizar documentos XML que posibilitan la relación maquina-maquina, es decir la
interoperabilidad entre servidores. Para facilitar la relación hombre-máquina se han utilizado hojas de estilo XSL para
generar visualizaciones HTML fácilmente interpretables por los usuarios del producto.
Debido a que los usuarios están habituados a un determinado estilo de presentación de esta información una de las
visualizaciones producidas presenta un aspecto similar al Diccionario de Datos (el cambio interno de estructura no tiene
porque afectar al usuario final). Sin embargo futuros usuarios preferirán un catálogo de datos basado en el estándar ISO
19110, objetivo de la segunda de las visualizaciones preparadas.
Puesto que hay documentos originales en tres idiomas, se requiere que la estructura de los documentos finalmente
generados permite su distribución de forma multi-idiomática.
Debido a la fuerte consolidación del estándar GML, y a la falta de especificaciones de implementación de los estándares
ISO19109 y 19110 se ha decidido utilizar los esquemas XSD de GML 3.1.1 como base para la implementación de todo
el proyecto. Por este motivo todos los elementos descritos llevan asociado un gmd:id que no permite realizar referencias
entre los diferentes niveles de descripción mencionados anteriormente.
MODELO UML
Se ha desarrollado un modelo UML [6] basado en el estándar ISO19109 Rules for application schema (General Feature
Model [7]) que describe las características básicas de la clase “fenómeno” (feature type) de la base topográfica. Este
modelo se muestra en la Figura 1.
El modelo UML contempla todos los elementos necesarios para describir el Diccionario de Datos además de aquellos
necesarios para poder realizar una exportación estándar ISO19110 [8] (y que no estaban presentes en la descripción
anterior del Diccionario de Datos). Los elementos que estaban presentes en el Diccionario de datos se han comentado
brevemente anteriormente, y se presentan de forma exhaustiva en la Tabla 1. Los elementos adicionales necesarios para
la conformidad con ISO19110 son básicamente aquellos relacionados con la versión y el productor del catálogo.
El modelo UML presenta diferentes tipos de datos que permiten almacenar toda la información necesaria. Los tipos
básicos se basan en el tipo abstracto de GML (definido en el estándar ISO19136 [9]): AbstractGMLType, y heredan de
éste diferentes atributos, entre ellos el gml:id, que nos será útil para realizar referencias entre objetos. El primer tipo
básico es el que será usado para generar el elemento XML del catálogo (AbstractFeatureCatalogICCType), el segundo
es el tipo para generar el elemento XML de cada objeto del catálogo (AbstractFeatureICCType) y el tercero el tipo para
las constricciones (o descripción de los casos de objeto). Además se generan otros tipos de datos, basados en los tipos
de datos generales, para contener la información del resto de elementos necesarios, por ejemplo la geometría del objeto
(GeometriaCollectionType), el conjunto de atributos del mismo (PropertyCollectionType) o los gráficos
complementarios a los objetos (GraficsCollectionType).
La intención inicial era integrar el modelo UML con los esquemas de aplicación XML, de manera que estos esquemas
se generaran de manera automática en base al modelo UML. Ninguno de los programas generalmente usados para la
generación de esquemas UML (MSVisio, ArgoUML y Altova UModel) nos permitía generar la representación
automática en XML, paso previo para generar de manera automática unos esquemas XML útiles. Aunque existen
diversos trabajos sobre la trasformación automática entre diseños UML y esquemas XML [10 y 11] los resultados de
éstos solo son aplicables a modelos de datos mucho más simples que el caso que nos ocupa. Por ese motivo, se generó
un modelo UML independiente que se ha trasformado manualmente a esquemas XML.
La mayoría de las características de los objetos (features) descritos en el Diccionario de Datos son propiedades
constantes para cada feature type. Sólo los valores de los atributos (y por lo tanto el código de caso) y la geometría se
pueden considerar específicos de cada feature instance.
Un documento GML está dirigido a documentar, en formato XML, las propiedades variables de una feature:
esencialmente sus atributos temáticos y geométricos. Así un esquema de aplicación recoge los nombres de estas
posibilidades y los acota o eventualmente propone una lista de valores. Las propiedades constantes para todas las
instancias de un objeto (la descripción, código de objeto, método de clasificación,…) se pueden resolver de diversas
maneras:
• Elementos de texto con valor fijado (fixed): tiene el inconveniente que cada objeto debe tener la propiedad repetida
con su valor ‘fixed’ correspondiente, y que no es posible evitar que una propiedad ‘fixed’ quede en blanco en el
documento definitivo
• Anotaciones en el esquema de aplicación: práctica habitual (que se encuentra por ejemplo en [12], p.27) en la que en
las anotaciones del XML schema se describen las características fijas del objeto. El problema es que estas
descripciones se encuentran mal caracterizadas y no aparecen en los documentos XML ni se pueden referenciar desde
las instancias del objeto.
• Objetos descriptivos relacionados: se basa en la característica que cada elemento GML derivado de
AbstractGMLType (y sustitutivo de gml:_GML) tiene un atributo gml:id que se puede utilizar para asociar o
relacionar objetos entre sí. Así, un objeto geográfico descrito en GML contendrá sólo las propiedades variables del
objeto, será descrito a partir de una extensión del tipo AbstractFeatureType (y sustitutivo de gml:_Feature) y tendrá
un vínculo a un objeto de otro documento XML que contiene las descripciones constantes de este tipo de objeto. Esta
aproximación es consistente con los niveles de abstracción descritos en el documento ISO19109 (ver Fig. 2).
Los documentos necesarios son en primer lugar un XSD que describe el tipo del tipo de objeto y un XML que
describe las propiedades constantes del tipo de objeto así como las posibilidades de las propiedades variables (en
verde en la Fig. 2). En segundo lugar otro XSD describe los tipos de objeto concentrándose tan sólo sus propiedades
variables que se definen en el documento XML basado en este XSD (en rosa en la Fig. 2). La descripción del objeto
deriva y usa (en rojo en la Fig. 2) el documento XML genérico.
• Diccionarios: Una aproximación muy similar a la anterior es la que se usa en los diccionarios GML. Así, un concepto
puede ser descrito por un objeto derivado de gml:DefinitionType en un fichero que describe un conjunto de términos
(diccionario, de tipo gml:Dictionary).
Se optó por la tercera aproximación, es decir generar por un lado un esquema XML (XSD) y un fichero XML para la
descripción del catálogo de objetos (en verde en la Fig. 2) y por otro un esquema GML de aplicación y un fichero XML
(o GML) para la distribución de los datos (en rosa en la Fig. 2). Ambos conjuntos de ficheros se relacionan a través de
un vínculo para cada objeto desde el esquema de aplicación hacia la descripción de este tipo de objeto en el catálogo.
Esta aproximación presenta la ventaja práctica adicional que permite la presentación como documento XML del
catálogo de objetos sobre el que se pueden aplicar transformaciones XSL a otros formatos XML o a visualizaciones
HTML. Aunque podría parecer que un esquema de aplicación podría considerarse parcialmente un catálogo de tipos de
objeto des de un punto de vista teórico, al ser archivo XSD no permite la aplicación de transformaciones XSL.
DICCIONARIO DE DATOS
Se han generado diversos esquemas y ficheros XML que conforman la versión estandarizada del Diccionario de Datos.
• FeatureCatalogICC.xsd: esquema que define los tipos que se usan en el Diccionario de Datos (fichero XML de igual
nombre). El objeto principal del catálogo es el elemento AbstractFeatureCatalogICC que deriva de
gml:AbstractGMLType y que es la raíz del documento XML. Contiene la descripción del catálogo y un conjunto de
elementos ‘Objeto’. El elemento ‘Objeto’ también deriva de gml:AbstractGMLType.
Todos los tipos que derivan de gml:AbstractGMLType heredan de él diversos elementos y atributos, por ejemplo el
atributo ya comentado gml:id. También heredan un elemento gml:description y uno gml:name. Estos elementos se
podrían utilizar para describir el nombre y la descripción del catálogo y de los objetos, pero tienen el problema que no
son elementos multi-idiomáticos. Por este motivo se generan elementos multi-idiomáticos ‘nombre’ y ‘descripción’, y
se rellenan los elementos gml:name y gml:description con el idioma ‘por defecto’, para que las aplicaciones más
simplistas sean capaces de recuperar, como mínimo, este texto.
• TipusBasicsICC.xsd: este esquema define los tipos básicos que se usan en los diferentes esquemas del modelo (ver
Fig. 3). Por ejemplo el tipo CadenesIdiomatiques que es un conjunto de 1 a N elementos de tipo CadenaIdiomatica,
es decir, un texto con un atributo obligatorio que indica el lenguaje de la cadena (a escoger de una enumeración
predefinida, ampliable en cualquier momento)
<!-- CADENAS IDIOMÁTICAS: un o mes 'textos' cada uno de tipo 'Cadena idiomática' -->
<xs:complexType name="CadenesIdiomatiques">
<xs:sequence>
<xs:element name="text" type="CatICC:CadenaIdiomatica" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- CADENA IDIOMÁTICA: elemento de tipo texto, con un atributo obligatorio que indica el idioma -->
<xs:complexType name="CadenaIdiomatica">
<xs:simpleContent>
<xs:extension base="CatICC:CadenaNoBuida">
<xs:attribute name="lang" type="CatICC:LangICCType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- IDIOMA: tipo que es una restricción de xs:language para que hi existan unos valores definidos -->
<xs:simpleType name="LangICCType">
<xs:restriction base="xs:language">
<xs:enumeration value="ca"/>
<xs:enumeration value="sp"/>
<xs:enumeration value="en"/>
</xs:restriction>
</xs:simpleType>
Figura 3: Fragmento del esquema XML TipusBasics.xsd donde se muestra el tipo de cadena multi-idiomática actualmente limitada a
3 idiomas pero fácilmente ampliable a todos los idiomas del estado o a la lista completa de idiomas de ISO si se desea.
Además de los ficheros comentados se generan tres Diccionarios basados en el esquema GML dictionary.xsd que se
usan para describir conjuntos de términos de manera idiomática. En todos los casos se generan tipos propios basados en
gml:DefinitionType:
• DiccGeom.xml/.xsd: incluye la descripción idiomática del tipo de geometría definida para cada objeto, es decir la
descripción idiomática de los valores de la enumeración GeometriaType (ver Figura 1, modelo UML)
• DiccTopo.xml/.xsd: incluye la descripción idiomática de los grupos y códigos de topónimos. El objeto topónimo de la
base topográfica tiene dos atributos complementarios que asocian el texto del topónimo a un código y grupo de
topónimos. La información que se distribuye informa del código de topónimo y este diccionario muestra la
descripción de cada uno de los códigos además la relación entre ambos (ver Fig. 4).
• DiccCodisISO.xml/.xsd: incluye la descripción multidiomática de los CodeList del estándar ISO 19115 [13]. De
momento tan sólo se ha implementado el CI_RoleCode ya que era el necesario actualmente (ver Fig. 5).
<gml:dictionaryEntry>
<CatICC:GrupTopo gml:id="GT1">
<gml:name>Elevacions del terreny en general <gml:dictionaryEntry>
(massís, serra, turó, muntanya, cim...)</gml:name> <CatICC:CI_RoleCode gml:id="coordinator">
<CTInclosos>501xx ; 502xx</CTInclosos> <gml:name>Coordinador</gml:name>
</CatICC:GrupTopo> <Descripcio>
</gml:dictionaryEntry> <text lang="ca">Coordinador</text>
<gml:dictionaryEntry> <text lang="sp">Coordinador</text>
<CatICC:CodiTopo gml:id="CT00001"> <text lang="en">Coordinator</text>
<gml:name>Municipi</gml:name> </Descripcio>
<GrupTop xlink:href="#GT17"/> </CatICC:CI_RoleCode>
</CatICC:CodiTopo> </gml:dictionaryEntry>
</gml:dictionaryEntry>
Figura 4: Fragmento del diccionario de Figura 5: Fragmento del diccionario de Listas de Códigos
Códigos y Grupos de Topónimos (CodeLists) usadas en la BT-5M
Se han generado dos hojas de estilo para la visualización de los datos del diccionario de forma más agradable. Estas
visualizaciones se han preparado con sendas hojas de estilo (fichero XSL, XML Stylesheet). El fichero XML se vincula
a la hoja de estilo deseada y al abrirlo con el explorador se visualiza en HTML.
La primera hoja de estilo pretende generar un formato similar al del anterior documento del Diccionario de Datos.
Algunas de las informaciones presentes en e documento XML no se muestran en la visualización ya que son
aportaciones del nuevo modelo, no presentes en el Diccionario de Datos.
Esta visualización genera una primera página con la lista de tipos de objetos que se incluyen el catálogo. Para cada tipo
de objeto se presenta su código y descripción. Después aparece una ficha con para cada uno de los objetos. Estas fichas
tienen la misma estructura y aspecto que el de la Tabla 1, pero con el contenido referente a cada objeto. En la Figura 6
se muestra una porción del documento XML del Diccionario de datos y en la Figura 7 la visualización del mismo
fragmento, ambos correspondientes al tipo de objeto “Parcela de urbanización”.
<Objecte gml:id="PAU">
<NomObjecte>
<text lang="ca">PARCEL·LA D’URBANITZACIÓ</text>
<text lang="sp">PARCELA DE URBANIZACIÓN</text>
</NomObjecte>
<CodiObjecte>PAU</CodiObjecte>
<DefinicioObjecte>
<text lang="ca">Línia divisòria de parcel·les de zones d’urbanització o industrials</text>
<text lang="sp">Línea divisoria de parcelas de zonas de urbanización o industriales</text>
</DefinicioObjecte>
<Geometria>
<Tipus>Linia</Tipus>
</Geometria>
<ClassificacioMetodeObtencioObjecte>
<text lang="ca">És recollida sobre el terreny</text>
<text lang="sp">Se recoge sobre el terreno</text>
</ClassificacioMetodeObtencioObjecte>
<Seleccio>
<text lang="ca">Només s’han recollit les línies divisòries que coincideixen amb murs, tanques de vegetació i filats en
zones d’urbanització o industrials, exceptuant les que delimiten les parcel·les en edificació continua. En zones industrials o
d'urbanitzacions amb moltes parcel·les de superfície inferior a 625 metres quadrats, les divisions de parcel·les s’han generalitzat
seleccionant les divisions de més longitud i les que ajuden a donar una idea de parcel·lació de la zona.</text>
<text lang="sp">Sólo se han recogido las líneas divisorias que coinciden con muros, vallas de vegetación y alambradas
en zonas de urbanización o industriales, excepto las que delimitan parcelas en edificación continua. En zonas industriales o de
urbanizaciones con muchas parcelas de superficie inferior a 625 metros cuadrados, las divisiones de parcelas se ha generalizado
seleccionado las divisiones de más longitud y las que ayudan a dar una idea de la parcelación de la zona.</text>
</Seleccio>
<Casos>
<Cas gml:id="PAU01">
<CodiCas>01</CodiCas>
<Relacions>
<connexio2D xlink:href="#EDI"/>
<connexio2D xlink:href="#MUR01"/>
<connexio3D xlink:href="#ILL01"/>
<connexio3D xlink:href="#PAU01"/>
<prioritat xlink:href="#TAN"/>
</Relacions>
</Cas>
</Casos>
<Grafics>
<Grafic>
<PathGrafic>Img\PAU01.gif</PathGrafic>
<TitolGrafic>
<text lang="ca">Parcel·la d’urbanització</text>
<text lang="sp">Parcela de urbanización</text>
</TitolGrafic>
</Grafic>
</Grafics>
</Objecte>
Figura 6: Fragmento del Diccionario de datos (FeatureCatalogICC.xml) correspondiente al tipo de objeto “Parcela de urbanización”
La segunda hoja de estilo pretende generar un formato similar al propuesto en los ejemplos del documento ISO 19110.
Esta visualización genera una primera página con la descripción del catálogo, y luego una página nueva para cada tipo
de objeto. Casi toda la información del Diccionario de Datos sobre los tipos de objeto se muestra en esta visualización,
pero estructurada según las pautas del Catálogo de objetos de ISO19110. La geometría no se muestra porque como el
estándar indica “ISO19110 excluye la referenciación espacial […] que está especificada en ISO19107”. El apartado
sobre la “Clasificación y método de obtención” se convierte en Restricciones del objeto o del atributo. También se
convierten en restricciones del objeto los apartados de “Selección”, “Combinaciones previstas de atributos (casos)”,
“Componentes del objeto complejo” (en el caso de polígonos), “Relaciones” (ya que son reglas que se cumplen en el
momento de generación de la base) y “Notas”.
Los atributos de los tipos de objeto se muestran, según sea necesario, como atributos con listas de valores (para
atributos complementarios y calificativos fijos) o atributos con tipo de valor y unidades de medida (para atributos de
tipo complementario variable o definido en diccionario).
La composición de elementos complejos de tipo línea se codifica como una asociación entre objetos puesto que
realmente la línea compleja se genera seleccionado las instancias de las líneas simples necesarias. Así pues la última
página de la visualización explica esta asociación, que puede tener dos ‘papeles en la asociación’: “compuesto por” y
“es componente de”. Para las líneas complejas se indica la asociación “compuesto por”, que vincula con el tipo de
objeto que las puede formar (ver Figura 8).
Figura 7: Visualización del tipo de objeto “Parcela de Figura 8: Visualización del tipo de objeto “Línea de costa detallada”
urbanización” con el estilo del Diccionario de Datos (línea compleja) con el estilo ISO19110
El esquema de aplicación se basa en la versión 3.1.1 de GML [14] aunque ha sido necesario modificar los esquemas
distribuidos por OGC ya que presentan un problema de validación al incluir por error algunos ficheros de la versión
3.1.0 (provocando redefiniciones). Los esquemas de aplicación fueron redactados con la versión 2005 release 3 de
Altova XMLSpy (anteriores releases de la misma versión dan problemas ficticios de validación de los esquemas GML).
Se ha procedido respetando al máximo las reglas de generación de documentos GML y recomendaciones recogidas en
[15] y en la “Guía de desarrollo de esquemas GML” de Galdos System Inc. [12].
En nuestro caso, no ha sido necesario establecer los tipos de fenómeno dado que esto estaba perfectamente definido en
los documentos originales del producto y perfectamente formalizado en los pasos anteriores. Así, solamente ha sido
necesario extender la clase gml:AbstractFeatureType tantas veces como tipos de objeto deben describirse generando un
nuevo tipo XML para cada tipo de objeto a describir, siempre tomando como referencia el catálogo de objetos
previamente elaborado. Se han generado sendos elementos globales y sustitutivos de gml:_Feature de manera que
pueden ser usados en las colecciones de objetos (FeatureCollection) de GML.
Algunos aspectos han sido tratados de manera especial respecto a su uso en los ejemplos clásicos y se comentan en los
siguientes apartados.
Se genera un elemento global “Topografico”, sustitutivo de gml:_FeatureCollection de manera que se puede usar como
raíz en los documentos GML.
En general las colecciones de objetos (FeatureCollection) pueden contener una lista de objetos (FeatureMember)
descritos uno a uno o bien agrupados en un grupo que los contiene (FeatureMembers). Utilizamos esta doble
posibilidad para permitir que una misma colección de objetos “Topografico” pueda contener por un lado todos los
objetos de una hoja agrupados (en un grupo: FeatureMembers) o bien diversos objetos de la misma o diferentes hojas
sin agrupar (varios FeatureMember). Para ello se define el elemento global “HojaTopografico” sustitutivo de
gml:featureMembers y el elemento global “Fenomeno” sustitutivo de gml:featureMember (ver Figura 9).
<BT5M_ICC:Cota gml:id="T1">
Subconjunto BT5M 0 1 Hoja BT5M 0 * Fenómeno <TipoObjeto xlink:href="FeatureCatalogICC.xml#COT"/>
(FeatureCollection) (FeatureMembers) (FeatureMember) <CodigoCaso>COT02</CodigoCaso>
0 <Z>23.54</Z>
<BT5M_ICC:GeometriaPunto>
* <gml:Point>
<gml:pos>1 3</gml:pos>
Fenómeno
(FeatureMember)
</gml:Point>
</BT5M_ICC:GeometriaPunto>
</BT5M_ICC:Cota>
Figura 9: Esquema de elementos GML generados y su uso para Figura 10: Ejemplo de la definición de un objeto de tipo “Cota
representar Hojas y Fenómenos de la Base topográfica altimétrica” en el fichero GML de distribución de datos
Las propiedades geométricas de los objetos son una elección entre las diversas posibilidades geométricas que
disponibles para ese objeto. Las posibilidades geométricas son: punto (gml:PointPropertyType), punto orientado y
escalado (extensión de gml:Point que contiene también la orientación, sus unidades, y una escala), texto (es un conjunto
de varios puntos, cada uno de ellos orientado), línea (gml:LineStringPropertyType), línea orientada (basada en el
elemento gml:OrientableCurve y con el grupo de atributos gml:AssociationAttributeGroup para poder definirla por
referencia en caso de que sea necesario), línea compleja (gml:CompositeCurveType), polígono
(gml:PolygonPropertyType).
Otra peculiaridad de esta implementación es que la mayoría de objetos presentan una única propiedad temática (el
código de caso). Esta propiedad conlleva un conjunto de valores determinados para los atributos calificativos de este
objeto, que se describe de manera detallada en el catálogo de objetos. En caso de que el objeto tenga algunos atributos
complementarios estos también se especificarán en el esquema de aplicación. Un ejemplo de este tipo de atributo es la
altitud (Z) para el tipo de objeto ‘Cota altimétrica’ (ver Figura 11).
Sistema de referencia
Para evitar la definición del sistema de referencia para todos y cada uno de estos objetos, este se ha definido a nivel de
toda la colección al indicarlo como atributo del envolvente (gml:Envelope) que define el àmbito que ocupa la colección
de objetos (gml:boundedBy). Esto es posible gracias a la herencia implícita de esta propiedad según indica el apartado
9.1.11 de [16].
Según [17] el atributo srsName de los objetos gml puede ser usado para indicar el identificador de un sistema de
referencia bien conocido (“well-known”), o bien para indicar un vínculo hacia un diccionario de sistemas de referencia,
por ejemplo hacia http://crs.opengis.org/crsportal [18]. Desgraciadamente en este artículo no queda bien explicado
como se debe hacer esta referencia y el hecho de existir múltiples versiones en este y otros artículos ([15], [17] y [19]),
nos ha hecho dudar de la opción a implementar. Finalmente decidimos implementar la opción escogida en el documento
[12] puesto que pretende ser una “Guía de buenas prácticas”. Esta descripción del sistema de referencia usa la base de
datos del European Petroleum Survey Group [20], siguiendo la recomendación del Núcleo Español de Metadatos
(NEM) [21]: <gml:Envelope srsName="urn:epsg:v6.1:coordinateRefereceSystem:23031">.
CONCLUSIONES
El uso de XSLT ha resultado razonablemente satisfactorio permitiendo realizar casi todo lo que se ha planteado no sin
un grado de esfuerzo significativo. En nuestra opinión las versiones actualmente soportadas por los navegadores son
excesivamente pobres; resulta un lenguaje aparentemente potente al principio pero limitante cuando se demandan
funcionalidades parecidas pero fuera de los ejemplos clásicos.
REFERENCIAS
1. Institut Cartogràfic de Catalunya (2001): Especificacions tècniques ICC: 1:5000 : BT-5M v2.0. Generalitat de Catalunya. Institut Cartogràfic de
Catalunya, Barcelona.
2. Institut Cartogràfic de Catalunya (2001): Diccionari de Dades de la Base topogràfica 1:5 000 v2.0 (BT-5M). Generalitat de Catalunya. Institut
Cartogràfic de Catalunya, Barcelona.
3. OS MasterMap. http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/index.html. (último acceso: noviembre, 2005)
4. UKHO Business to business website: New GML Schema for S57 ENC data. http://www.ukho.gov.uk/b2b_gml_home.asp (último acceso:
noviembre, 2005)
5. International Hydrographic Organization (2005): IHO S-57 Edition 4.0 The Next Edition of IHO S-57 (4.0) Version 1.1, March 2005.
http://www.iho.shom.fr/ECDIS/S-57_Ed4_Information_Paper_ver1.1.pdf
6. G. Booch, Rumbaugh, J., Jacobson, I. (1999): The Unified Modeling Language User Guide. Addison-Wesley, Boston, MA 482pp.
7. International Organization for Standardization: International Standard: Geographic information – Rules for application schema. ISO 19109:2005.
Technical Committee 211 (2005)
8. International Organization for Standardization: International Standard: Geographic information – Methodology for feature cataloguing. ISO
19110:2005. Technical Committee 211 (2005)
9. International Organization for Standardization: Draft International Standard: Geographic information – Geography Markup Language. ISO/DIS
19136. Technical Committee 211 (2005)
10. C. Portele (2003): Mapping UML to GML Application Schemas. Guidelines and Encoding Rules. V.0.1-b. http://www.interactive-
instruments.de/ugas/UGAS-Guidelines-and-Encoding-Rules.pdf
11. C. Portele (2004): Mapping UML to GML Application Schemas. ShapeChange - Architecture and Description. V.0.2. http://www.interactive-
instruments.de/ugas/ShapeChange.pdf
12. Galdos System Inc (2003): Developing and Managing GML Application Schemas. A Best Practice Guide prepared by Galdos System Inc.
TR2003-232-01. Editor: David S. Burggraf, 2003-05-15.
13. International Organization for Standardization: International Standard: Geographic information – Metadata. ISO 19115:2003. Technical
Committee 211 (2003)
14. GML 3.1.1 Schema Package (2005). http://schemas.opengis.net/gml/3.1.1/ . Esta versión de los esquemas se puso en la página web el 11 de
agosto de 2005 (último acceso: noviembre, 2005)
15. Ron Lake, David Burggraf, Milan Trninic, Laurie Rae (2004): Geography Mark-Up Language: Foundation for the Geo-Web. Ed. John Wiley &
Sons Ltd. 406pp.
16. R. Lake (2005): The application of geography markup language (GML) to the geological sciences. Computers & Geosciences, Vol. 31, pp. 1135-
1150.
17. Cox, S.A., Daisey P., Lake R., Portele C., Whiteside A., 2003. OpenGIS Geography Markup Language (GML) Implementation Specification.
OGC Document Number 03-105r1. http://www.opengeospatial.org/specs/?page=specs.
18. Galdos Systems Inc: Coordinate Reference System Registry . http://crs.opengis.org/crsportal/index.html (último acceso: noviembre, 2005)
19. M. Sen & T. Duffy (2005): GeoSciML: Development of a generic GeoScience Markup Language. Computers & Geosciences, Vol. 31, pp. 1095-
1103.
20. European Petroleum Survey Group (2005). Geodetic Parameter Dataset. http://www.epsg.org/ (último acceso: noviembre, 2005)
21. Subgrupo de Trabajo del Núcleo Español de Metadatos (2005): Núcleo Español de Metadatos (NEM v1.0). SGTNEM200501.
Resumen: En este artículo se propone un álgebra para la gestión de coberturas geográficas y su integración en el
lenguaje XQuery de consulta de documentos XML. Se formaliza el concepto de cobertura geográfica como un conjunto
de funciones, llamadas atributos o bandas. Cada banda de una cobertura asocia a cada localización de un espacio
discreto, finito y bidimensional un valor de un determinado dominio convencional (reales, enteros, cadenas de
caracteres, etc.). Las operaciones del álgebra propuesta permiten la combinación de las bandas de dos coberturas, y el
cómputo de bandas derivadas de las bandas ya existentes en una cobertura. La incorporación de estas operaciones en
XQuery, lo dotan de capacidades de análisis espacial, convirtiéndolo así en un lenguaje adecuado para la gestión de
fuentes de datos en Geography Markup Language (GML). Estas operaciones se ilustran mediante ejemplos
representativos de su funcionalidad y mediante un ejemplo de aplicación realista.
INTRODUCCIÓN
Tradicionalmente, los datos geográficos se clasifican en dos grandes categorías: objetos y coberturas. Un objeto
geográfico (una ciudad, una carretera o un municipio), además de poder poseer un conjunto de propiedades de tipo
alfanumérico (población de la ciudad, gestor de la carretera o nombre del municipio), incluye una o varias propiedades
de algún tipo geométrico, que definen su posición y forma en el espacio geográfico (superficie terrestre). Dichos tipos
geométricos incluyen los bien conocidos puntos, líneas y superficies. Una cobertura geográfica asocia a cada punto de
un determinado subconjunto del espacio geográfico, un conjunto de propiedades de tipo alfanumérico. El tipo de cada
propiedad puede ser tanto discreto como continuo. Ejemplos de propiedades discretas son el tipo de suelo (planeamiento
urbanístico) y tipo de vegetación. Ejemplos de propiedades continuas son la temperatura y la altitud sobre el nivel del
mar.
Los primeros sistemas de información dedicados a la gestión de información geográfica (Sistemas de Información
Geográfica, SIG), se diseñaban para ámbitos de aplicación específicos y almacenaban tanto las propiedades de los
objetos geográficos como las coberturas en el sistema de archivos del sistema operativo. Por lo tanto, las bien conocidas
ventajas del uso de Sistemas Gestores de Bases de Datos (SGBD) no se aprovechaban en estos sistemas. Una primera
evolución de estos sistemas se produce con el desarrollo de herramientas SIG de propósito general. Estas primeras
herramientas mantenían el uso de archivos, y la gestión de datos geográficos se realizaba mediante la ejecución de
grandes listas de comandos, que en el caso de la gestión de coberturas estaban basados en el álgebra de Tomlin [8].
Si nos restringimos a la gestión de objetos geográficos, las herramientas SIG pronto empezaron a utilizar un SGBD
convencional para almacenar las propiedades alfanuméricas, y en algunos casos también las geométricas. Este SGBD
convencional ya proporciona funcionalidad genérica de control de concurrencia, back-up, gestión de transacciones,
seguridad, etc. Sin embargo, la ausencia de un lenguaje de consulta para datos geométricos hace que su gestión tenga
que hacerse en una capa software fuera del gestor, disminuyendo así la eficiencia del sistema. Para solucionar estos
problemas, se investiga en la extensión de los SGBD con funcionalidad de consulta espacial, alcanzando como
resultado las actuales extensiones espaciales de los SGBDs más populares (Oracle, DB2, PostgreSQL, etc.). Es
importante resaltar que no existe una solución satisfactoria para la gestión de coberturas geográficas desde dentro de un
SGBD.
La gran importancia de Internet en la nueva sociedad de la información hace que el uso de Servicios Web en SIG sea
actualmente la tendencia dominante. En este sentido, el Open Geospatial Consortium (OGC) proporciona
especificaciones estándar para Servicios Web de acceso a datos. Ejemplos reseñables son el Web Feature Service
(WFS), para acceso a datos de objetos geográficos, el Web Coverage Service (WCS) para acceso a datos de coberturas
geográficas, y el Geography Markup Language (GML), lenguaje XML de transferencia de datos geográficos (objetos y
coberturas) entre los servicios web. Ninguno de los dos servicios anteriores proporciona una capacidad de análisis
espacial similar a la que proporciona un SGBD espacial para objetos geométricos.
En este artículo se presenta un álgebra que permite el análisis espacial de datos obtenidos de coberturas geográficas y se
muestra la forma en la que este álgebra se integra en el lenguaje XQuery. Más en concreto, la contribución del presente
trabajo puede resumirse en los siguientes puntos:
• Se formaliza el concepto de cobertura geográfica como un conjunto de funciones, llamadas atributos o bandas,
que asocian a cada localización de un espacio discreto de dimensión 2 un valor de un dominio convencional
(enteros, reales, cadenas de caracteres, etc.)
• Se da una descripción informal de las dos operaciones que permiten la combinación de las bandas de dos
coberturas y el cómputo de nuevas bandas derivadas de las ya existentes. Estas operaciones se ilustran
mediante algunos ejemplos representativos, que permiten alcanzar la funcionalidad de una operación de cada
uno de los tipos descritos por Tomlin en [8].
• Se muestra también la forma en la que el álgebra propuesta se integra en el lenguaje de consulta sobre XML
XQuery. Dicha integración permite el uso de XQuery para la consulta de fuentes de datos de coberturas
geográficas en GML [6].
Los tres puntos anteriores marcan el contenido de las tres secciones siguientes de este artículo. Además, el artículo
incluye dos secciones más, una en la que se presenta un ejemplo de aplicación realista para el álgebra propuesta y otra
en la que se resumen las conclusiones y las líneas de trabajo futuro.
COBERTURAS GEOGRÁFICAS
Una cobertura geográfica se define como un conjunto de funciones, cada una de las cuales asocia un valor de un
determinado dominio alfanumérico (enteros, reales, cadenas de caracteres, etc.) a cada punto de una determinada
superficie del espacio geográfico. En esta sección se formaliza e ilustra mediante ejemplos el concepto de cobertura
geográfica.
Sean R y Z los conjuntos de los números reales y enteros, respectivamente, y sea n un número entero mayor que cero
cualquiera. El conjunto de puntos del espacio geográfico se representa mediante el conjunto infinito
En el presente modelo, por lo tanto, el espacio geográfico es un rectángulo cerrado en sus lados inferior e izquierdo y
abierto en sus lados superior y derecho. Si i, j son dos números enteros tal que -n ≤ i, j ≤ n, entonces una localización zi,j
del espacio geográfico se define como el subconjunto de R2n
Una localización es por lo tanto un subconjunto infinito de puntos del espacio geográfico, con forma cuadrangular y con
dos lados cerrados (izquierdo e inferior) y dos lados abiertos (superior y derecho). Se dice que (i, j) son las coordenadas
discretas de la localización zi,j. Se dice que el conjunto finito de localizaciones Z2n = {zi,j | i, j ∈ Z ∧ -n ≤ i, j ≤ n}es una
representación discreta (finita) del espacio geográfico. Claramente, Z2n una partición del espacio geográfico, por lo
tanto, cada punto del espacio geográfico pertenece a una y sólo una localización de Z2n. La Figura 1(a) ilustra los
conceptos anteriores para n = 2.
Un dominio geográfico es un subconjunto S del espacio geográfico (S ⊆ R2n) que se puede expresar como la unión de
un conjunto finito de localizaciones, es decir,
S = Ui p i , pi ∈ Z2n.
Sea S un dominio geográfico, A1, A2, ..., Am nombres distintos y D1, D2, ..., Dm nombres de dominios convencionales,
no necesariamente distintos. Una cobertura geográfica C con esquema C[S](A1 | D1, A2 | D2, ..., Am | Dm) se define
como un conjunto de funciones
Cada función Ai se denomina atributo o banda, y asocia a cada localización p contenida en S un valor de un dominio
convencional (real, entero, cadena de caracteres, etc.) o el valor especial undefined (Ai no está definida en p). En las
Figuras 1(b), 1(c) y 1(d) se muestran las representaciones gráficas de tres coberturas. La primera, con esquema
METEO[S1](temperatura | real, humedad | real), asocia un valor de temperatura y otro de humedad, medidos por una
estación meteorológica, a la localización de dicha estación. La segunda, MUNICI[S2](nombre | string) asocia a cada
localización de su dominio el nombre del municipio al que pertenece. La tercera, ELEV[S2](elevacion | real) almacena
la elevación sobre el nivel del mar en cada localización de su dominio. En lo que queda de artículo, A y B posiblemente
con un subíndice se utilizan para denotar bandas cuyo tipo es irrelevante.
En esta sección se muestran las operaciones de combinación de coberturas y de cómputo de bandas, que incluye la
presente álgebra de gestión de coberturas geográficas. No se pretende la formalización de estas operaciones, sino la
ilustración de su funcionalidad mediante ejemplos representativos. En concreto, se muestran ejemplos de como podrían
expresarse operaciones entre coberturas de cada uno de los tipos propuestos en [8], que son la base de la mayoría de
sistemas de gestión de coberturas comerciales [3, 4, 5] y de libre distribución [1, 7] disponibles en la actualidad.
Combinación de coberturas
Operación Combine: Sean C1 y C2 dos coberturas geográficas con esquemas respectivos, C1[S1](A1, A2, ..., An),
C2[S2](B1, B2, ..., Bm), donde no existe el mismo nombre de banda en C1 y C2. La operación
C = Combine(C1, C2)
devuelve una nueva cobertura C, con esquema C[S1∪S2](A1, A2, ..., An, B1, B2, ..., Bm), donde para cada localización
p⊆ S1∪S2
Claramente, la cobertura resultado C tendrá los valores originales de C1 y C2 para sus bandas Ai y Bj en las
localizaciones en las que tanto C1 como C2 están definidas, es decir, en S1∩S2. En las localizaciones donde C1 está
definida pero C2 no lo está, las bandas Ai tendrán el valor original de C1 y las bandas Bj tendrán valor nulo. Finalmente,
en las localizaciones donde C1 no está definida pero C2 sí lo está, las bandas Ai tendrán valor nulo y las bandas Bj
tendrán el valor original de C2.
Cómputo de bandas
Para obtener nuevas bandas a partir de las ya existentes en una cobertura, se utilizan sentencias de cómputo. No es
objetivo de esta subsección el dar una definición exhaustiva de todas las posibles sentencias de cómputo soportadas en
la presente álgebra, sino la ilustración mediante ejemplos representativos de la funcionalidad que puede alcanzarse.
Data una cobertura geográfica con esquema C1[S1](A1, A2, ..., An), una sentencia de cómputo tiene la siguiente
estructura:
<loc1>, <loc2> (<loc2> es opcional) son nombres de variables que iteran de forma independiente sobre el conjunto de
localizaciones contenidas en S1. La cláusula “WHERE <condition>” es opcional y se evalúa para cada combinación de
las anteriores variables, seleccionando sólo aquellas combinaciones de localizaciones para las que <condition> devuelve
un valor verdadero. Finalmente, el resultado de la evaluación de cada expresión ej (j=1, 2, ..., m) para cada combinación
de localizaciones obtenidas del paso anterior, será el valor asociado a la localización referenciada por <loc1> en la
nueva banda Bj(j=1, 2, ..., m) de la cobertura resultado.
Teniendo en cuenta la descripción anterior de las sentencias de cómputo, la siguiente operación permite la evaluación
de una sentencia de cómputo sobre una cobertura.
Operación Evaluate: Sea C1 una cobertura geográfica con esquema C1[S1](A1, A2, ..., An) y fwc una sentencia de
cómputo válida. La operación
C = Evaluate[fwc](C1)
devuelve una nueva cobertura C resultado de la evaluación de la sentencia fwc sobre la cobertura C1.
En esta subsección muestra como puede expresarse con el álgebra propuesta, una operación entre coberturas de cada
uno de los tipos propuestos en [8].
0 0 0 0 0 17 18 18 17 17
0 5 0 6 0 18 24 19 25 18
0 0 0 0 0 17 18 20 18 17
0 3 4 0 0 16 20 21 17 16
0 0 0 0 0 14 15 16 16 16
Operaciones locales: Dadas un conjunto de bandas de entrada, la banda resultante de una operación local asigna a cada
localización p un valor que se obtiene a partir de los valores asociados a esa misma localización p en las bandas de
entrada. Así por ejemplo, si ELEV es la cobertura de elevaciones del terreno de la Figura 1(d) y
EDIFICIOS[S2](elev_edif | real) es la cobertura de elevaciones de edificios mostrada en la Figura 2(a), la elevación total
en cada localización se obtiene mediante la suma de las dos anteriores. Este es el resultado que devuelve la siguiente
secuencia de operaciones del álgebra propuesta.
C = Combine(ELEV, EDIFICIOS)
}
17.3 17.3 17.3 18 18 z-2,-2 z-1,-2 z-2,-2 z-1,-2 z-1,-2 z-2,-2 16.1 113
z-2,-2 z0,-2 z-2,-2 z0,-2 z0,-2 ... ... ...
191 191 191 126 126
17.3 16.1 18 18 18 z-2,-2 z1,-2 WHERE z-2,-2 z-2,-1 z-2,-1
avg(elevacion(p1))
sum(elevacion(p1))
z-2,-2
191 113 126 126 126 z-2,-2 z2,-2 z-2,-2 z-1,-1 z-1,-1
16.1 16.1 16.1 17.3 17.3 z-2,-2 z-2,-1 z-2,-2 z0,-1 z0,-1
113 113 113 191 191 ... ... z-2,-2 z-1,0 z-1,0
16.1 16.1 16.1 17.3 17.3 z-2,-2 z2,2 ... ... ... ...
113 113 113 191 191 ... ...
Figura 3: Ilustración de media y suma zonales de elevaciones (Figura 1(d) en cada municipio (Figura 1(c)).
Operaciones zonales: Una zona en una banda de una cobertura la componen todas las localizaciones que tienen
asignado el mismo valor. Teniendo esto en cuenta, dadas dos bandas de entrada A y B, una operación zonal devuelve
para cada localización p un valor que se obtiene a partir de los valores que asigna la banda A a todas las localizaciones
que están en la zona de p en la banda B. Por ejemplo, si MUNICI y ELEV son las coberturas mostradas en las Figuras
1(c) y 1(d), operaciones zonales podrían obtener para cada localización p la media y la suma de las elevaciones del
municipio que contiene a p. Este resultado se obtiene mediante las operaciones siguientes.
C = Combine(MUNICI, ELEV)
Operaciones focales: Dada una banda de entrada, el valor de la banda resultante de una operación focal para una
localización p se obtiene de los valores de la banda de entrada en un vecindario de p. Este vecindario puede estar
compuesto por ejemplo por todas las localizaciones situadas a una distancia de p menor que un determinado umbral. Un
ejemplo típico de operación focal es la interpolación. Si METEO y MUNICI son las coberturas mostradas en las Figuras
1(b) y 1(c) respectivamente, el método de interpolación IDW (Inverse Distance Weighted) obtiene el valor de
temperatura en cada localización de cada municipio a partir de los valores de las localizaciones vecinas, situadas a
menos de d unidades de distancia. En concreto, para cada localización p de cada municipio, el valor T de la temperatura
en p se obtiene mediante la formula
donde ti es el valor de temperatura que asocia la cobertura METEO a la localización pi, y di es la distancia entre p y pi.
Las siguientes operaciones aplican el método IDW a las coberturas METEO y MUNICI, para una distancia d = 2.
C = Combine(METEO, MUNICI)
5
10
8 temperatura(Z0,0) = (8/1.41 + 10/1.41 + 8/1.41) / (1/1.41 + 1/1.41 + 1/1.41) = 8.6
2 15
z0,0
8 10 humedad(Z0,0) = (15/1.41 + 22/1.41 + 18/1.41) / (1/1.41 + 1/1.41 + 1/1.41) = 18.3
18 22
Figura 4: Ilustración de la interpolación IDW de la temperatura y humedad (Figura 1(b)) para la localización z0,0.
Para cada localización p, la condición de la cláusula WHERE obtiene todas las localizaciones p1 situadas a una
distancia menor que 2 y cuyo valor de temperatura está definido. Para esto se utiliza una función espacial distance, que
calcula la distancia Euclidiana entre dos localizaciones, y el predicado IS DEFINED, que devuelve el valor booleano
verdadero cuando se aplica a un valor distinto del valor especial undefined. La expresión de la cláusula COMPUTE
aplica la formula del método IDW sobre el conjunto de localizaciones p1 obtenido tras la evaluación de la cláusula
WHERE. La Figura 4 ilustra el cálculo de las bandas temperatura y humedad de la cobertura METEO2 para p = z0,0.
19 19 19
18 20 18 y = 17 + 2*17 + 17 - 19 - 2*19 - 19 = -8
17 17 17 pendiente = atan ( 2
(x/8) + (y/8)
2
) = 0.78
x = 19 + 2*18 + 17 - 19 - 2*18 - 17 = 0
Figura 5: Ilustración del cómputo de la pendiente a partir de la elevación (Figura 1(d)) para la localización z0,0.
Operaciones incrementales: Dada una banda de entrada, el resultado de una operación incremental asigna a cada
localización p un valor obtenido a partir de los valores de las localizaciones adyacentes a p. Consideremos por ejemplo
la cobertura de elevaciones del terreno ELEV de la Figura 1(d). La siguiente secuencia de operaciones obtiene una
aproximación de la pendiente en cada localización, siguiendo la aproximación propuesta en [2].
C1 = Evaluate[FOR EACH p
WHERE elevation(north(west(p))) IS DEFINED and elevation(north(p)) IS DEFINED
and elevation(north(east(p))) IS DEFINED and elevation(east(p)) IS DEFINED
and elevation(south(west(p))) IS DEFINED and elevation(west(p)) IS DEFINED
and elevation(south(east(p))) IS DEFINED and elevation(south(p)) IS DEFINED
COMPUTE x = elevation(north(west(p))) + 2*elevation(west(p)) + elevation(south(west(p))) −
elevation(north(east(p))) − 2*elevation(east(p)) − elevation(south(east(p))),
y = elevation(south(west(p))) + 2*elevation(south(p)) + elevation(south(east(p))) −
elevation(north(west(p))) − 2*elevation(north(p)) − elevation(north(east(p)))
](ELEV)
Dada una localización p con coordenadas (i, j), las funciones espaciales north(p), south(p), east(p) y west(p), devuelven,
respectivamente, las localizaciones con coordenadas (i, j+1), (i, j−1), (i+1, j) y (i−1, j). Las funciones convencionales
sqrt y atan calculan, respectivamente la raíz cuadrada y el arcotangente de un número real. Finalmente, la operación
r^e, devuelve el resultado de elevar el número real r a la potencia e. La Figura 5 ilustra el cómputo de la pendiente para
p = z0,0.
En esta sección se ilustra mediante un ejemplo representativo la integración de las operaciones del álgebra de la sección
anterior en el lenguaje de consulta XQuery, dotándolo así de funcionalidad de análisis espacial que lo habilita para la
consulta de fuentes de datos de coberturas en GML.
En su última versión 3.1, el lenguaje GML [6] del OGC permite la representación de coberturas geográficas. GML
soporta varios tipos de coberturas. Para el propósito del presente artículo, nos restringimos a sólo tres tipos: coberturas
multipunto, coberturas multisuperficie y coberturas de grid rectificado. Una cobertura de tipo multipunto asocia a cada
punto (representado con un par de coordenadas vectoriales) de su dominio geográfico, una tupla de valores de tipo
convencional, un valor para cada banda de la cobertura. Así, por ejemplo, el siguiente trozo de código representa la
cobertura METEO de la Figura 1(b) mediante una cobertura multipunto de GML.
<METEO xmlns="http://labsis.usc.es/coberturas">
<gml:domainSet>
<gml:MultiPoint>
<gml:pointMember><gml:Point><gml:pos>-1 -1</gml:pos></gml:Point></gml:pointMember>
<gml:pointMember><gml:Point><gml:pos> 1 -1</gml:pos></gml:Point></gml:pointMember>
<gml:pointMember><gml:Point><gml:pos> 1 1</gml:pos></gml:Point></gml:pointMember>
<gml:pointMember><gml:Point><gml:pos>-1 2</gml:pos></gml:Point></gml:pointMember>
</gml:MultiPoint>
</gml:domainSet>
<gml:rangeSet>
<gml:DataBlock>
<gml:rangeParameters><gml:CompositeValue><gml:valueComponents>
<Temperatura uom="gradosC"> template </Temperature>
<Humedad uom="porcentaje"> template </Humidity>
</gml:valueComponents></gml:CompositeValue></gml:rangeParameters>
<gml:tupleList>8 18 10 22 8 15 5 10</gml:tupleList>
</gml:DataBlock>
</gml:rangeSet>
</METEO>
El tag <gml:domainSet> se utiliza para describir el dominio geográfico de la cobertura, es decir, los puntos con
coordenadas (-1, -1), (1, -1), (1, 1) y (-1, 2). El tag <gml:rangeSet> define las bandas de la cobertura, así como los
valores convencionales asociados a cada punto del dominio. Así, en el ejemplo el punto (-1, -1) tiene asociado el valor 8
de temperatura y el valor 18 de humedad. La cobertura MUNICI de la Figura 1(c) se podría representar mediante un
GML similar al anterior, en este caso de tipo multisuperficie, reemplazando los cuatro puntos por cuatro polígonos
vectoriales y reemplazando los valores de temperatura y humedad por una lista de nombres de municipios. La cobertura
ELEV de la Figura 1(d) se puede representar mediante la siguiente cobertura GML de tipo grid rectificado.
<ELEV xmlns="http://labsis.usc.es/coberturas">
<gml:rectifiedGridDomain>
<gml:RectifiedGrid dimension="2">
<gml:limits>
<gml:GridEnvelope>
<gml:low>0 0</gml:low><gml:high>4 4</gml:high>
</gml:GridEnvelope>
</gml:limits>
<gml:axisName>x</gml:axisName><gml:axisName>y</gml:axisName>
<gml:origin><gml:Point><gml:pos>-2 -2</gml:pos></gml:Point></gml:origin>
<gml:offsetVector>1 0</gml:offsetVector>
<gml:offsetVector>0 1</gml:offsetVector>
</gml:RectifiedGrid>
</gml:rectifiedGridDomain>
<gml:rangeSet>
<gml:DataBlock>
<gml:rangeParameters><gml:CompositeValue><gml:valueComponents>
<Elevacion uom="metros"> template </Elevacion>
</gml:valueComponents></gml:CompositeValue></gml:rangeParameters>
<gml:tupleList>
14 15 16 16 16
16 17 17 17 16
17 18 20 18 17
18 19 19 19 18
17 18 18 17 17
</gml:tupleList>
</gml:DataBlock>
</gml:rangeSet>
</ELEV>
Como puede verse en el ejemplo, el domino se representa ahora mediante un tag <gml:rectifiedGridDomain>, en el que
se especifica el origen del grid (punto con coordenadas (-2, -2)), dos vectores de desplazamiento <gml:offsetVector>
con valores (1, 0) y (0, 1) que proporcionan una resolución y una orientación, y un número de celdas raster
<gml:limits>.
El siguiente trozo de código XQuery, aplica el método de interpolación IDW sobre la banda de temperatura de la
cobertura METEO de la sección anterior.
En primer lugar, la cobertura METEO se recupera del archivo ‘meteo.gml’. Después en la variable $cadena se
almacena la cadena de caracteres de la sentencia de cómputo que define la operación de interpolación que se pretende
aplicar (ver la sección de ilustración de funcionalidad avanzada para más detalles sobre esta expresión). A continuación,
se utiliza la función Evaluate para aplicar la sentencia de cómputo sobre la cobertura $meteo, obteniendo como
resultado una nueva cobertura, $temperatura. La incorporación de esta función Evaluate permite la aplicación de
la respectiva operación del álgebra definida en este articulo sobre variables de tipo cobertura. Finalmente, la última
instrucción devuelve la cobertura calculada. Además de la función Evaluate, se incluye en XQuery una función
Combine, que permite aplicar la operación del mismo nombre sobre dos variables de tipo cobertura.
EJEMPLO DE APLICACIÓN
En esta sección se ilustra un ejemplo realista de aplicación del XQuery anterior. En concreto, se dispone de tres
coberturas de entrada distintas. Una cobertura que almacena para cada localización una elevación sobre el nivel del mar
(ver Figura 6). Una cobertura que asocia a la posición de cinco estaciones meteorológicas un valor medido de
temperatura y otro valor de humedad. Las posiciones de estas estaciones se muestran en la Figura 7. Por último se
dispone de una cobertura que asocia a cada localización un valor de un modelo de combustible, obtenido del tipo de
vegetación (ver Figura 8). A partir de estas coberturas, se pretende estimar un índice de riesgo de propagación de
incendios aplicando las operaciones definidas en este artículo.
En primer lugar, se calcula la pendiente (ver Figura 9) a partir de la elevación. Este cómputo ya se ilustró en una
sección anterior. En segundo lugar se calculan dos coberturas, una de temperatura (Figura 10) y otra de humedad
(Figura 11) a partir de la cobertura de estaciones meteorológicas de la Figura 7. Para esto se utiliza el método de
interpolación IDW ya descrito en secciones anteriores.
La cobertura que asocia un valor del índice de propagación de incendios a cada localización se obtiene mediante una
suma ponderada de las coberturas pendiente, modelos de combustible, humedad y temperatura. Esta suma ponderada no
es más que una operación local en el álgebra descrita en este artículo
En este artículo se ha ilustrado mediante ejemplos representativos la funcionalidad de las operaciones de un álgebra
propuesta para la gestión de coberturas geográficas. La incorporación de estas operaciones al lenguaje de consulta
XQuery, lo dotan de capacidades de análisis espacial, haciéndolo apropiado para la consulta de almacenes de datos
GML de coberturas. Algunas de las ventajas más relevantes de la aproximación propuesta en este artículo, respecto a
los sistemas actuales de gestión de coberturas geográficas son las siguientes.
• A diferencia de los sistemas disponibles en el mercado, las operaciones del álgebra propuesta son de carácter
genérico. Así, por ejemplo, no se proporcionan dos operaciones distintas para el cálculo de la pendiente y el
aspecto a partir de una cobertura de elevaciones, sino que se proporciona una herramienta (un lenguaje) que
permite expresar estas operaciones y muchas otras más, mediante sentencias de cómputos de bandas.
• En el artículo se muestra una forma de integración del álgebra en XQuery. Sin embargo, la integración del
álgebra en otros lenguajes de consulta también es posible. En concreto, la integración en el lenguaje SQL
permitiría la gestión de coberturas desde dentro de un SGBD, característica no presente en ningún gestor
comercial (a nuestro leal saber y entender).
• La combinación de las capacidades de consulta del lenguaje anfitrión (XQuery, SQL, etc.) con las capacidades
de gestión de coberturas del álgebra propuesta permiten incrementar aún más la funcionalidad alcanzada. Así,
por ejemplo, sería posible la utilización de operaciones del álgebra dentro de funciones recursivas de XQuery o
dentro de consultas recursivas del nuevo SQL:2003.
• Las sentencias de cómputo de bandas proporcionan un lenguaje declarativo que permite expresar operaciones
de cómputo sin la necesidad de programar la forma eficiente en que esas operaciones deberían ser
implementadas. Esto permite, al igual que ocurre con los SGBD, la separación entre un nivel lógico en el que
el usuario trabaja con conceptos más abstractos y sencillos (coberturas y sentencias de cómputo de bandas), y
un nivel físico en el que el sistema utiliza complejas estructuras de datos y algoritmos para conseguir una
implementación eficiente. Se permite por lo tanto al sistema la optimización de las sentencias expresadas por el
usuario. Esta separación entre nivel lógico y físico, permite también al usuario el trabajar con coberturas
discretas implementadas con un modelo vectorial (por ejemplo, las coberturas METEO y MUNICI de la Figura
1) y coberturas continuas implementadas con un modelo raster (por ejemplo la cobertura ELEV de la Figura 1)
de una forma uniforme, sin preocuparse en ningún momento de qué modelo de representación interna
(vectorial o raster) se utiliza para cada cobertura.
• La definición de nuevas operaciones entre coberturas geográficas y objetos geográficos, y la combinación con
operaciones de álgebras de objetos geográficos ya existentes, permite la gestión uniforme de todo tipo de datos
geográficos en un álgebra combinada de tipo heterogéneo (many-sorted).
REFERENCIAS
1. Geographic Resources Analysis Support System Homepage. (2005). http://grass.baylor.edu/. (último acceso: Noviembre 2005)
2. Horn, B.K.P. (1981). Hill Shading and the Reflectance Map, Proceedings of the IEEE 69(1):14-47.
3. Keigan Systems. (2005) MFWorks On Line. http://www.keigansystems.com/software/mfworks/index.html (último acceso:
Noviembre 2005).
4. Lorup, E.J. (2000) IDRISI Tutorial online. http://www.sbg.ac.at/geo/idrisi/wwwtutor/tuthome.htm (último acceso: Noviembre
2005)
5. McCoy, J. and Johnston, K. (2001) Using ArcGis Spatial Analyst. Environmental Systems Research Institute, CA.
6. OGC-GML, 2004. OpenGIS Geographic Markup Language (GML) Encoding Specification. Open Geoespatial Consortium. OGC
03-105r1. Version 3.1.1.
7. Red Hen Systems Inc. (2001) MapCalc User´s Guide.
8. Tomlin CD (1990) Geographic Information Systems and Cartographic Modeling, Prentice Hall, Englewood Cliffs, NJ.
9. Viqueira J.R.R., Álvarez, P., Varela, J., Saco, P. (2005) Architecture of a natural disasters management framework and its
application to risk assesment. Proc. 8th Conference on Geographic Information Science (AGILE 2005), 26-28 Mayo, Estoril,
Portugal.
METADATOS
111
Denición de Perles y creación de cheros XML de metadatos para... Sesión 4
Resumen: El objetivo de la presentación es mostrar los pasos seguidos en el Servicio de Teledetección del INTA para
incorporar ficheros XML de metadatos a las imágenes de teledetección, respetando la normativa ISO y las
recomendaciones del Nucleo Español de Metadatos (N.E.M.).
Utilizando la aplicación IME (ISO Metadata Editor) desarrollada en el INTA, se ha creado y depurado un perfil de
metadatos que resulte aplicable a los datos de las imágenes hiperespectrales. Para ello se ha seguido la norma
ISO19115 completándolo con las recomendaciones del NEM, así como con extensiones de aplicación específica a
imágenes adquiridas con sensores aeroportados.
Esta herramienta también permite conocer y entender la jerarquía de metadatos que se define en la ISO19115:2003,
por lo que resulta interesante mostrar sus posibilidades para los usuarios que necesiten acceder a esta información.
Una vez definido el perfil, se ha trabajado con las posibilidades de edición de metadatos que permite el software IME
para generar plantillas (en inglés y castellano) que servirán como referencia para futuros proyectos.
Como ultima fase de esta metodología se han generado ficheros XML según los requerimientos del último borrador de
la especificación ISO19139. Estos ficheros de metadatos han sido distribuidos a los usuarios para documentar las
últimas campañas de vuelo realizadas (Doñana, Belgica, Albacete y Rosarito).
INTRODUCCIÓN
La directiva europea INSPIRE que pretende regular y armonizar la distribución de Información Geográfica en Europa,
ha dado lugar a la creación de las Infraestructuras de datos Espaciales (IDE) en los distintos países de la Unión Europea.
En el Servicio de Teledetección del INTA, como productor de datos de Teledetección tanto espacial como aeroportada,
se ha querido, desde el primer momento, incorporar la nueva normativa sobre distribución de Información Geográfica,
para lo cual se ha desarrollado un perfil de metadatos lo más estandarizado posible para los productos distribuidos.
El objetivo ha sido generar un perfil que sea de utilidad para proporcionar información a los usuarios de nuestros datos,
tanto de aquellos proporcionados por CREPAD (Centro de REcepción, Proceso, Archivo y Distribución de datos de
observación de la Tierra, situado en la Estación Espacial de Maspalomas) como de los datos aeroportados producidos en
el Servicio de Teledetección (LABTEL). Además, este perfil tiene que cumplir los requisitos exigidos por la ISO19115,
en cuanto a contenido, y de la ISO19139 en cuanto a estructura.
METODOLOGÍA
Para mantener la coherencia con otros organismos y con la IDEE (Infraestructura de Datos Espaciales de España) que
lidera el IGN (Instituto Geográfico Nacional), se utilizó como punto de partida la norma internacional ISO19115 y se
completó el perfil con la primera versión del NEM. Concretamente los pasos seguidos fueron:
Como apoyo a todo este proceso se diseñó una herramienta de trabajo que, al mismo tiempo que facilitaba la
comprensión de una norma tan compleja como la ISO19115, permitía ajustar y modificar el perfil del Servicio de
Teledetección y obtener una salida en formato XML de los metadatos ya completados.
El software, denominado IME (ISO Metadata Editor) es propiedad del INTA y se distribuye gratuitamente a cualquier
usuario que lo solicite o lo desee descargar desde el enlace: http://www.crepad.rcanaria.es/info/metadatos/index.htm
Esta herramienta servirá para mostrar, en esta presentación, los pasos seguidos.
Para confeccionar el perfil INTA se han seleccionado aquellas clases y elementos enumerados en la ISO19115 que
tienen interés para describir el contenido de las imágenes aeroportadas producidas en el Servicio de Teledetección, así
como las imágenes y productos de satélite proporcionados a través de CREPAD.
MD_Metadata->dataQualityInfo que incluye información sobre la precisión, así como sobre la fuente original de los
datos y la descripción de cada uno de los procesos seguidos hasta llegar al nivel actual.
Además se han incluido aquellos elementos de la entidad MD_Metadata que permitían proporcionar información sobre
los propios metadatos (nombre del fichero, versión de la norma, responsable de los metadatos, etc.).
Debido a la complejidad de la normativa ISO, se decidió crear una herramienta propia que facilitara el trabajo con un
gran número de metadatos y permitiera mantener la jerarquía que define la norma. El objetivo fundamental era poder
gestionar perfiles de metadatos sin necesidad de conocer todas las asociaciones y dependencias entre ellos que define la
norma ISO19115.
El diseño del software IME se realizó con la intención de facilitar a cualquier usuario la incorporación de
modificaciones a la definición de los metadatos y de la salida en XML sin necesidad de modificar y recompilar el
código fuente.
El software cuenta con ficheros editables de configuración que permiten realizar los siguientes cambios:
Figura 3: Iconos para identificación de Tipo de Dato Figura 4: Path desde el elemento raiz hasta un metadato
Además de las entidades de metadatos enumeradas anteriormente, fue necesario incluir otras que podían ser de interés
para los usuarios de los datos aeroportados producidos en el Servicio de Teledetección. Se creó una nueva entidad
siguiendo la metodología proporcionada por la ISO para la extensión de perfiles de metadatos.
Como se puede observar en la figura 6, se generó una nueva entidad denominada acquisitionInformation constituida, a
su vez, por: platformId, para proporcionar información sobre la plataforma de adquisición; instrumenId, para describir
información útil sobre el instrumento de adquisición de las imágenes; y flightInfo, que incluye datos sobre altura,
dirección y velocidad de vuelo. Tanto los nombres de estas clases como las características de los metadatos se han
basado en borradores de especificaciones ISO (19115-2, 19130, etc.) para facilitar su posterior adaptación a estas
normas.
En el Servicio de Teledetección se empezó a desarrollar un perfil aplicado exclusivamente a teledetección a finales del
2004. La posterior aparición del NEM resultó muy útil para comprobar que el perfil que se había desarrollado seguía las
pautas correctas y para ampliar aspectos de los metadatos que no se habían considerado, tales como la información
sobre el dataset agregado. También sirvió para entender el significado de algunas de las clases y elegir la que más se
adaptaba a nuestros datos.
Debido a que el NEM ha sido pensado para datos de distinta naturaleza a la de las imágenes de teledetección,
encontramos diferencias en varias entidades. Las más importantes se describen a continuación.
La entidad MD_SpatialRepresentation (fig.7) incorpora la información sobre la representación espacial de los datos.
Dentro de las cuatro entidades que ofrece spatialRepresentation, se ha elegido la clase específica
MD_GridSpatialRepresentation porque es la que más se adapta de manera general a todas las imágenes y productos que
proporcionamos. La información fundamental aquí, se refiere a la descripción de los ejes, que se denominan
dimensiones. El número de dimensiones espaciales (numberOfDimensions) en las imágenes es 2, correspondientes a
filas y columnas, y las propiedades asociadas a estas dimensiones serían nombre (dimensionName) y tamaño o número
de unidades (dimensionSize). Lo más correcto sería elegir MD_GridSpatialRepresentation para las imágenes raw;
MD_Georectified para las imágenes corregidas y MD_Georeferenceable para las imágenes que se acompañan de
ficheros para su georreferenciación. Sin embargo, esto supondría crear tres perfiles en lugar de uno para los datos
aeroportados, lo que se traduciría también en tres plantillas. En la versión actual del perfil se decidió poner 0-No, en
transformationParameterAvailability , para indicar que la imagen no es georeferrenciable ni está georreferenciada, y 1-
Yes, para indicar que la imagen es georreferenciable o está georreferenciada. Además, para indicar que está
georreferenciada existe un elemento en referenceSystemInfo donde se indica la proyección de la imagen. Por último,
existe la clase MD_AggregateInfo donde se puede incluir información sobre los ficheros auxiliares de
georreferenciación, en caso de que existan.
Figura 7: MD_SpatialRepresentation
En el caso de MD_ContentInformation (figura 8) se proporciona información sobre el contenido de los datos. Contiene
una sola clase abstracta que a su vez puede ser sustituida por cuatro clases específicas, siendo la más interesante la
denominada MD_ImageDescription que permite incluir información sobre las bandas del sensor (MD_Band), cobertura
nubosa (cloudCoverPercentage) y nivel de proceso (processingLevelCode).
Figura 8: MD_ContentInformation
Figura 9: DQ_DataQuality
Por último, como ya se ha mostrado en la figura 6, ha sido necesario añadir una extensión a los metadatos de la
ISO19115 .
Una vez definido el perfil, se utilizó el editor de metadatos de la herramienta IME para la introducción de los valores y
creación de las plantillas. Esta utilidad permite la edición de texto libre en cualquier metadato editable y la visualización
de las opciones disponibles en los "codelists" que, para otros metadatos, definen los únicos valores posibles (ver figuras
11 y 12).
También se incluyeron algunas utilidades para facilitar el duplicado de metadatos (con verificación previa de la norma),
borrado y copiado de nodos entre varias sesiones de IME abiertas simultáneamente (ver figura 10).
Figura 11: Edición de metadatos con texto libre Figura 12: Selección de opciones en codelists
Al mismo tiempo se definió un formato de fichero (plantilla de texto, figura 13) en el que se incluyera toda la
información del perfil y que fuera fácilmente editable. De este modo un usuario puede incluir la información
manualmente y puede acceder a ella desde otra aplicación para automatizar el proceso del relleno de los datos.
A la espera de la publicación definitiva de la norma ISO19139, se ha buscado una aproximación lo más fidedigna
posible al último borrador disponible siguiendo la estructura del esquema XSD (Schema Definition Language)
propuesto. Esta ha sido una tarea ardua ya que el esquema no sigue la estructura exacta de la ISO19115 en cuanto a
distribución de las entidades y de los elementos dentro de ellas.
Las imágenes adquiridas por los sensores aerportados del Servicio de Teledetección (AHS, AMDC y ATM) son
procesadas de acuerdo a un flujo de trabajo desarrollado e implementado en el INTA. Estos datos se caracterizan por un
nivel de proceso geométrico y radiométrico que da lugar a una serie de productos bien definidos.
Desde que el perfil fue completado, los productos imagen generados para cada proyecto se acompañan de ficheros
XML de metadatos que son proporcionados a los usuarios. Actualmente se utilizan una serie de rutinas que permiten
obtener, de forma automática, parte de la información contenida en la cabecera de nuestras imágenes y productos e
incorporarla a los ficheros XML.
En la siguiente tabla se muestra un resumen de los proyectos en los que la entrega de imágenes hiperespectrales se ha
completado con ficheros de metadatos adjuntos. Estas campañas se han realizado durante el año 2005 para diferentes
usuarios.
De momento no se ha recibido ninguna apreciación por parte de los usuarios sobre la facilidad o dificultad de acceder a
estos datos entregados en formato XML. En nuestra opinión, es pronto aún para que realicen valoraciones sobre los
metadatos proporcionados porque la interoperabilidad entre las aplicaciones no será efectiva mientras no se publique la
recomendación definitiva de la ISO19139 . No obstante, sí han mostrado interés en el uso del software IME y en el
conocimiento de la normativa.
REFERENCIAS
1. INSPIRE. Propuesta de DIRECTIVA DEL PARLAMENTO EUROPEO Y DEL CONSEJO por la que se establece una infraestructura de
información espacial en la Comunidad (INSPIRE).(http://inspire.jrc.it/proposal/ES.pdf)
2. IDEE. Portal de Infraestructura de Datos Espaciales de España. (www.idee.es)
3. ISO/TC211 (Cómite Técnico 211 de la ISO)
4. ISO19115. Geographic Information-Metadata (edición 2003-05-01)
5. ISO1939. Geographic Information-Metadata-Implementation Specification (2004-06-30 estado actual: " CDstudy/ballot initiated")
6. XML. Extensible Markup Language 1.0 (Third Edition. Recommendation 04-02-2004) http://www.w3.org/XML
7. XML Schema Definition v.1.1 (http://www.w3.org/XML/Schema)
8. Web Software IME v.2.0. (Documentacion y Descarga) www.crepad.rcanaria.es/info/metadatos/index.htm
INTRODUCCIÓN
Hasta hace unos pocos años, el término “metadato” no formaba parte del conjunto de palabras técnicas que toda
persona relacionada con el mundo de la Información Geográfica estaba acostumbrada a oír. Durante un buen número de
años, los Sistemas de Información Geográfica, grandes colosos formados por datos, medios y actividades, eran los
únicos sistemas capaces de gestionar y tratar información espacial, convirtiéndose en potentes herramientas de análisis
que permitían identificar y establecer relaciones espaciales entre los diferentes objetos cartográficos. Durante ese
tiempo no se conocía el término “metadato” con la familiaridad con que hoy en día se utiliza.
Fue con el nacimiento de las Infraestructuras de Datos Espaciales (IDEs) cuando los metadatos empiezan a tomar
protagonismo pasando de ser un actor de segunda o incluso que no aparecía en escena a ocupar el papel protagonista en
los proyectos relacionados con el tratamiento de Información Geográfica.
Una IDE es un sistema distribuido de información geográfica a través de Internet que nos va a permitir visualizar y
consultar información de tipo geográfico (datos de referencia y temáticos) de diferentes instituciones u organismos y
que puede estar ubicada en diferentes servidores localizados en distintos lugares.
Uno de los pilares fundamentales en el que una IDE se sustenta es el Servicio de Catálogo. Este Servicio permite a los
usuarios la búsqueda, localización, y selección de los datos geográficos almacenados en los diferentes servidores,
gracias a que gestiona los metadatos de cada uno de los datos objeto de las búsquedas. Para que los catálogos que
proceden de diferentes instituciones puedan ser interoperables y admitir búsquedas distribuidas, principios básicos de
una IDE, es necesario crear los metadatos de acuerdo a normas y criterios comunes. En la actualidad la Norma ISO
19115:2003 ”Geographic Information -Metadata” es la Norma Internacional de metadatos. Esta Norma presenta una
serie de inconvenientes que nos han hecho reflexionar dentro del seno de Consejo Supeior Geográfico, órgano superior
consultivo en materia de cartografía perteneciente al Ministerio de Fomento y formado por representantes relacionados
con el mundo de la cartografía de todos los niveles de la Administración, sobre la necesidad de elaborar un perfil propio
de metadatos recomendado para España.
En este documento se van a describir las principales características de este perfil de metadatos: el ”Núcleo Español de
Metadatos” (NEM), que ha surgido muy recientemente en el ámbito del Grupo de Trabajop para la Infraestructura de
Datos de España, como resultado de un trabajo consensuado entre expertos de diferentes organizaciones cartográficas
de España y que ha sido aprobado como una recomendación de metadatos por el Consejo Superior Geográfico.
ANTECEDENTES
• Dublín Core Iniciative: La iniciativa de metadatos Dublín Core ha sido creada por una comunidad de
individuos de diferentes procedencias y disciplinas, de organizaciones de todo el mundo que incluyen tanto al
sector público como al privado. Se caracteriza porque define 15 elementos básicos y generales para describir
un recurso (un programa, una página Web, un mapa,. ..). Dicha iniciativa ha adquirido ya el rango de norma
ISO (ISO 15836) y se está convirtiendo en una norma de facto para documentar todo tipo de recursos.
A la hora de confeccionar el Catálogo de Datos de una IDE cada organización debe confeccionar sus propios metadatos
para cada uno de los recursos (series o unidades cartográficas, ortofotos, Modelos Digitales del Terreno,..) que produce,
según alguna Norma o iniciativa común que garantice la posterior interoperabilidad de los metadatos procedentes de
diferentes organizaciones.
Cada una de las Normas anteriormente enunciadas presentan una serie de inconvenientes a la hora de ser utilizadas para
crear metadatos de datos geográficos, ya sean de referencia o temáticos: Por un lado la Norma Internacional ISO
19115:2003 es muy amplia (409 elementos), voluminosa (140 páginas), compleja y general, de modo que es difícil
implementarla directamente sin definir un perfil. Por otro lado la Iniciativa Dublín Core resulta excesivamente pobre
para crear metadatos relacionados con la información geográfica.
Por ello surge la necesidad de definir un nuevo perfil de metadatos, el Núcleo Español de Metadatos (NEM),
entendido como un conjunto mínimo de metadatos recomendados para la descripción de recursos relacionados con la
Información Geográfica dentro de España.
NEM, acrónimo de Núcleo Español de Metadatos, nace gracias a las opiniones, comentarios y aportaciones de un grupo
abierto de expertos en metadatos pertenecientes a diferentes organizaciones e instituciones en el ámbito nacional,
autonómico y local.
Es una recomendación de metadatos aprobada por el Consejo Superior Geográfico, a través de su Comisión de
Geomática. NEM se define como un conjunto mínimo de metadatos entendidos como un perfil de ISO 19115:2003 de
acuerdo con el concepto de perfil definido en la Norma ISO 19106 “Geographic Information-Profiles” , es decir, es un
modo particular y concreto de aplicar y utilizar una Norma, seleccionando un conjunto de items y un conjunto de
parámetros opcionales. Para ello este perfil va a tener en cuenta otras iniciativas y acciones relevantes que en la
actualidad se están desarrollando en materia de metadatos.
Este perfil constituye por lo tanto un núcleo “Core”, conjunto de metadatos “mínimo” aconsejable por su utilidad y
relevancia que va a permitir realizar (búsquedas, comparaciones,..) 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.
No es, por lo tanto, un perfil normativo o restrictivo, no se pretende que se implemente directamente sino que se
aconseja su utilización, cada institución u organismo debe estudiar cuales son los metadatos que considera adecuados
para satisfacer sus necesidades, y una vez establecidos se recomienda incluir al menos los ítems que establece el perfil
NEM, garantizando así la compatibilidad con el resto de iniciativas.
Por último decir que es una recomendación estable, aunque no inmutable, porque aunque surjan nuevas iniciativas,
proyectos y planteamientos de metadatos en España o en otro ámbito, el núcleo mínimo recomendable de metadatos que
debe ser común a todos los sistemas no debe variar significativamente.
En Noviembre del año 2002 el Consejo Superior Geográfico, órgano superior y consultivo de planificación del Estado
en el ámbito de la Cartografía que depende del Ministerio de Fomento y en el que están representados los productores
de datos geográficos digitales de referencia (en el sentido INSPIRE) de ámbito nacional, autonómico y local (Instituto
Geográfico Nacional, Servicios Cartográficos del Ejército, Mº de Medio Ambiente, Mº de Agricultura, Institutos
Cartográficos y Servicios de Cartografía de las Comunidades Autónomas,…) cuya presidencia ejecutiva y secretaría
desempeña el Instituto Geográfico Nacional, definió un Grupo de Trabajo para la definición y establecimiento de la
Infraestructura de Datos Espaciales de España (IDEE). En dicho Grupo de Trabajo los organismos mencionados
intercambian experiencias y llegan a los consensos necesarios para la implementación de una IDE en España, de
acuerdo con las directrices marcadas por INSPIRE y siguiendo las especificaciones de interoperabilidad de Open
Geospatial Consortium (OGC) y las Normas Internacionales ISO 19100 para la información geográfica.
Dentro de este Grupo de Trabajo se creó un Subgrupo de Trabajo para los metadatos ”SGT2” encargado entre otras
funciones de realizar un inventario de los metadatos que cada una de las organizaciones productoras de datos
generaban.Como resultado se vió la gran deficiencia que en esta matería existía en nuestro país, tanto en la falta de
conocimiento de los datos existentes como en el grado de desarrollo en el tema de metadatos de las organizaciones
productoras. Pensando en la necesidad de garantizar la interoperabilidad entre los datos que proceden de diferentes
organizaciones y en consecuencia poder crear Catálogos de datos interoperables, uno de los tres pilares fundamental en
la IDEE, en Noviembre de 2004 y coincidiendo con la primeras Jornadas sobre la Infraestructura de Datos de España
celebradas en Zaragoza nacío el Subgrupo de Trabajo del Núcleo Español de Metadatos ”SGT NEM”.
SGT NEM tiene como misión principal establecer,definir y mantener el Núcleo Español de Metadatos.Para ello es
necesario:
• Realizar una descripción detallada de cada uno de los elementos que forman NEM.
• Crear un documento de metadatos para NEM, que sea lo más entendible y manejable posible, de tal manera
que facilite la dura taréa de la creación de metadatos.
• Mantener su descripción, es decir, completando y actualizando la documentación que describe NEM y que
sirve de apoyo para su utilización, y eventualmente efectuar alguna modificación menor en sus contenido.
EL PERFIL NEM
El Núcleo Español de Metadatos está constituido principalmente por el perfil “ISO 19115:2005 – Core Metadata for
Geographic Datasets”, que define un conjunto básico de 22 elementos, junto con otros elementos que pertenecen a
otros estándares de catalogación y a perfiles de metadatos elaborados en distintas recomendaciones europeas, como:
• El estándar de Metadatos Dublín Core: existen elementos básicos que aparecen ene esta iniciativa y no en el
Core de ISO 19115 y que se recomienda se tengan en cuenta.
• La propuesta de perfil espacial de metadatos elaborada por el Comité Técnico de Normalización Europeo
(CEN) [ZNF 03b].
• La propuesta de Directiva INSPIRE (Infrastructure for Spatial Information in Europe) y la Guía sobre
Sistemas de Información Geográfica de la Directiva Marco del Agua (DMA) insisten en la importancia de
describir la calidad en la información Geográfica.
Teniendo en cuenta las iniciativas arriba mencionadas el perfil NEM está formado por los siguientes elementos:
La Norma Internacional ISO 19115 define un extenso conjunto de elementos de metadatos, sin embargo es esencial
establecer un mínimo básico de esos elementos que sirvan para definir un conjunto de datos con el propósito de su
catalogación, así se define el ”Core” de esta Norma, formado por elementos clasificados en obligatorios (O),
opcionales(Op) y Condicionales (C). A continuación se muestran dichos elementos en una tabla junto con su ruta dentro
de la Norma ISO 19115:2003:
CI_Citation.title) Type)
(MD_Metadata>MD_Identification.citation>CI_Citation.date) (MD_Metadata>MD_ReferenceSystem)
Parte responsable del Conjunto de Datos (Op) Linaje (Op)
(MD_Metadata>MD_Identification.pointOfContact>
(MD_Metadata>DQ_DataQuality.lineage>LI_Lineage)
CI_ResponsibleParty)
Localización Geográfica del Conjunto de Datos (por 4 coordenadas o Recurso en línea (Op)
por identificador geográfico) (C) (MD_Metadata> MD_Distribution >
(MD_Metadata>MD_DataIdentification.extent>EX_Extent>
MD_DigitalTranferOption.online>
EX_GeographicExtent>EX_GeographicBoundingBox or
CI_OnlineResource)
EX_GeographicDescription)
Idioma del Conjunto de Datos (O) Identificador del Archivo de Metadatos(Op)
(MD_Metadata>MD_DataIdentification.language) (MD_Metadata.fielIdentifier)
Conjunto de Caracteres del Conjunto de Datos(C) Nombre de la Norma de Metadatos(Op)
(MD_Metadata>MD_DataIdentification.CharacterSet) (MD_Metadata.metadataStandardName)
Categoría del Tema del Conjunto de datos(O) Versión de la Norma de Metadatos (Op)
(MD_Metadata>MD_DataIdentification.TopicCategory) (MD_Metadata.metadataStandardVersion)
Resolución espacial del Conjunto de datos (Op) Idioma de los Metadatos (C )
(MD_Metadata>MD_DataIdentification.spatialResolution> (MD_Metadata.language)
MD_Resolution.equivalentScale o MD_Resolution.distance)
Resumen Descriptivo del Conjunto de los datos (O) Conjunto de Caracteres de los Metadatos ( C)
(MD_Metadata>MD_Identification.abstract) (MD_Metadata.characterSet)
Formato de Distribución (Op) Punto de contacto para los Metadatos (O)
(MD_Metadata>MD_Distribution>MD_Format.name y (MD_Metadata.contact>CI_ResponsibleParty)
MD_Format.version)
Información adicional de la extensión del Conjunto de Datos (vertical Fecha Creación de los Metadatos(O)
y temporal) (Op)
(MD_Metadata>MD_DataIdentification.extent>EX_Extent>
(MD_Metadata.dateStamp)
EX_TemporalExtent o EX_VerticalExtent)
Las definiciones para cada uno de estos items de acuerdo a NEM son:
• Título del Conjunto de datos (Title): nombre por el que se conoce al recurso.
• Fecha de Referencia del conjunto de datos (Date): fecha de referencia para el recurso mencionado. No es
fácil definir con precisión que fecha es la más significativa para situar en el tiempo un conjunto de datos. Por
ello es necesario dirigirse a la Norma ISO19108 “Temporal Schema” que define el tiempo válido como aquel
momento en que algo representado en un conjunto de datos es fiel reflejo de la realidad, es decir, este metadato
se corresponde con la fecha de captura, después de la cual no se añade información relevante al contenido del
conjunto de datos. Es la fecha en la que se sabe positivamente que el conjunto de datos refleja la realidad.
• Idioma del Conjunto de datos (Language): idioma usado para documentar el conjunto de datos.
• Categoría del tema del Conjunto de datos (TopicCategory): Tema (s) principal(es) del conjunto de datos.
• Resumen Descriptivo del Conjunto de datos (Abstract): Breve resumen descriptivo del contenido del
recurso.
• Punto de contacto para los metadatos (CI_ResponsableParty): Equipo responsable de la información de los
metadatos.
• Fecha de creación de los metadatos (dateStamp): Fecha en que se crearon los metadatos.
• Parte Responsable del conjunto de datos (CI_ResponsableParty): Equipo con el que se puede contactar para
informarse sobre el recurso o cómo adquirirlo.
• Resolución espacial del conjunto de datos (Distance): Factor que da una idea sobre la densidad de los datos
espaciales en el conjunto de datos.
• Sistema de Referencia (ReferenceSystem): Información sobre el sistema de referencia del conjunto de datos.
• Linaje (Lineage): Información sobre eventos o fuentes usados en la construcción de los datos especificados en
el ámbito que se especifique.
• Recurso en línea (OnLine): Información en línea que puede ser usada para contactar con la organización o
persona responsable de los datos.
• Identificador del archivo de metadatos (Fileldentifier): Identificador único para el archivo de metadatos.
• Formato de distribución (Format): Proporciona información sobre el formato usado para la distribución.
• Idioma de los metadatos (Language): Idioma usado para documentar los metadatos.
La iniciativa Dublin Core proporciona 3 elementos al perfil NEM.Estos elementos no pertenecen a los recogidos en el
Core de ISO 19115 pero sí tienen correspondencia con 3 elementos que aparecene en el resto de los elementos que
forman la norma.
Los elementos que proporciona en Dublin Core al perfil son:
NEM se ha sido definido gracias a la colaboración de un grupo de expertos relacionados con el mundo de los metadatos
y pertenecientes a diferentes organismos relacionados con la información geográfica de ámbito nacional, regional y
local.
Los miembros de SGT NEM decidieron que era importante incluir 3 metadatos en el perfil NEM que no pertenecen a
Dublín Core ni al Core de ISO pero que por sus experiencias y necesidades a la hora de crear metadatos consideraban
importantes. Estos son:
• Palabras clave (DescriptiveKeywords): Proporciona la palabra/s usadas para describir el tema o lugar
correspondiente al conjunto de datos y hace referencia de la fuente de la que proceden.
( MD_Metadata.identificationInfo> MD_DataIdentification.descriptiveKeywords).
• Nivel Jerárquico (level): Indica el nivel de detalle con que se está describiendo el conjunto de datos. Nos
permite distinguir el tipo de recurso (dataset, series, hojas, etc) que se está catalogando.( DQ_Scope.level).
• Forma de Presentación (PresentationForm): permite distinguir las posibilidades de presentación de los datos,
de tal modo que vamos a poder distinguir si los datos están en formato impreso, digital o ambos.
(MD_Metadata.identificationInfo> MD_DataIdentification.citation>CI_Citation.presentationForm).
La Directiva 2000/60/EC del Parlamento Europeo y del Consejo, de 23 de octubre de 2000, por la que se establece un
marco comunitario de actuación en el ámbito de la política de aguas [Diario Oficial L 327 de 22.12.2000] tiene como
objetivo establecer un marco comunitario para la protección de las aguas superficiales continentales, de transición,
costeras y subterráneas, para prevenir o reducir su contaminación, promover su uso sostenible, proteger el medio
ambiente, mejorar el estado de los ecosistemas acuáticos y atenuar los efectos de las inundaciones y las sequías.
Los países miembros de la Unión Europea y la Comisión Europea han desarrollado una estrategia común para apoyar la
implementación de la Directiva 2000/60/EC, uno de los aspectos a considerar por esta directiva es el desarrollo de unas
especificaciones técnicas para implementar un Sistema de Información Geográfico por ello en Septiembre de 2001 se
creó un Working Group (Grupo de Trabajo), formado por representantes de países miembros , de la Comisión, de
Eurostat, de la European Environment Agency (EEA) y del Joint Research Center (JRC), siendo este último el
encargado de coordinarlo y dirigirlo.
Este grupo de trabajo estableció unos metadatos para catalogar la información relativa al sector del agua, los miembros
del SGT NEM partiendo de la idea de que NEM iba a ser un perfil abierto a nuevas iniciativas que en materia de
metadatos fueran surgiendo, estudiaron esta nueva directiva y los metadatos que habían aplicado a sus datos y
decidieron incluir dos metadatos nuevos al NEM que hasta ahora no habían sido considerados:
• Uso específico (SpecificUsage): breve descripción del uso del recurso y/o de las series del recurso. Es muy
ilustrativo describir algunos usos específicos que se le han dado al recurso del que se crean sus metadatos, para
orientar a usuarios potenciales sobre sus posibilidades.
El Núcleo Español de Metadatos además de contener metadatos asociados a datos geográficos contiene metadatos que
permiten describir la calidad de los datos y pertenecen a la propia Norma ISO 19115:2003. En el Perfil NEM vamos a
definir la calidad como obligatoria, y en caso de no poder o no tener medidas realizadas de ella, la organización u
organismo encargado de crear los metadatos, podrá incluir las expresiones: no disponible, no aplicable.
Primeramente, se recomienda definir el ámbito específico o campo de aplicación de la descripción de la calidad, que no
tiene porqué que coincidir con el ámbito general al que se refieren el resto de metadatos. Para describir el ámbito los
metadatos a usar son:
• Nivel Jerárquico (DQ_ScopeLevel): se trata de un código que indica el nivel de detalle con que se está
describiendo la información de calidad. Se coge el código de la lista controlada MD_ScopeCode.
• Extensión (DQ_Scope.Extent): describe la extensión de la cuál se ha realizado un estudio de calidad.
• Descripción Detallada (DQ_Scope.levelDescription): es la descripción del conjunto de datos objeto del
estudio en cuestión.
Una vez establecido el ámbito de estudio de la calidad, vamos a definir metadatos para describir las componentes
cualitativas y metadatos para las componentes cuantitativas:
Componentes cualitativas:
• Declaración (Statement): es una explicación general del proceso productivo dado por el productor de los
datos. Se recomienda rellenar este ítem con una descripción lo más detallada posible.
• Paso del proceso (ProcessStep): corresponde a la información sobre un evento en el proceso de creación de
los datos. Se recomienda documentar cada uno de los pasos del proceso de producción del modo más
exhaustivo y detallado posible.
• Fuente (Source): es la información sobre la fuente de datos usada para la creación de los datos. Se
recomienda describir la fuente o fuentes de información utilizadas de modo que se puedan identificar
claramente.
Componentes cuantitativas:
Se han establecido un número de metadatos para determinar la componente cuantitativa de la calidad para nuestros
datos, para cada uno de ellos se propone incluir tres items:
• Nombre de la Medida (NameOfMeasure): nombre de la medida hecha sobre los datos para determinar el
elemento de calidad que estamos estudiando. Se recomienda que el nombre de la medida sea único dentro de
cada elemento de calidad referido a un conjunto de datos.
• Descripción de la Medida (MeasureDescription): consiste en describir literalmente las pruebas hechas sobre
los datos. Es un texto libre que se recomienda documentar.
• Resultado (Result): valor obtenido de la medida de calidad realizada. Se recomienda utilizar dos items para
describirlo:
o Unidad de Valor (ValueUnit): se introduce la unidad de la medida realizada, se recomienda utilizar
las abreviaturas definidas en el SI de unidades para unidades dimensiónales.
o Valor (Value): valor obtenido de la medida de la calidad.
A continuación se describen cada uno de los elementos cuantitativos que forman parte del NEM:
• Compleción (DQ_Commpleteness): es la parte de la calidad de los datos que nos va a indicar en que medida el
modelo es fiel a la realidad. Se divide en:
o Compleción por Comisión (DQ_CompletenessCommission): es la medida en exceso entre los ítems
presentes en el conjunto de datos y los ítems existentes en la realidad.
o Compleción por Omisión (DQ_CompletenessOmission): es la medida del defecto entre los ítems
presentes en el conjunto de datos y los ítems existentes en la realidad.
• Consistencia Lógica (DQ_LogicalConsistency): grado de conformidad a las reglas lógicas de las estructuras
de datos, atributos, relaciones. Se divide en:
o Consistencia Topológica (DQ_TopologicalConsistency): grado de adherencia a las características
topológicas de los objetos espaciales que pueden ser: puntos, líneas y polígonos.
o Consistencia Conceptual (DQ_ConceptualConsistency): estudio de la conformidad de acuerdo al
modelo conceptual.
• Exactitud Posicional (DQ_PositionalAccuracy): es la exactitud en posición de las entidades. Se divide en:
o Exactitud Posicional Externa Absoluta (DQ_AbsoluteExternalPositionalAccuracy):
correspondencia en proximidad entre los valores de las coordenadas dadas y los valores de los
mismos sobre el terreno.
• Exactitud Temporal (DQ_TemporalAccuracy): exactitud de los atributos temporales y de las relaciones
temporales entre entidades, se divide en:
En la actualidad existe una herramienta, “CatMDEdit v 3.6.1”, para la creación de metadatos de acuerdo al Núcleo
Español de Metadatos. Dicha herramienta ha sido creada por el Departamento de Informática e Ingeniería de Sistemas
de la Universidad de Zaragoza a través del convenio de colaboración establecido entre el Instituto Geográfico Nacional
y dicha Universidad para el establecimiento y creación del portal de la Infraestructura de Datos Espaciales de España
(IDEE).
• Está desarrollada como un proyecto OpenSource (código abierto), de tal manera que cualquiera puede
descargarse su código fuente y personalizarla en función de sus necesidades. Tanto para la descarga de la
herramienta, como la de su código o la del manual se hace a través de la página:
http://sourceforge.net/projects/catmdedit/
• Presenta dos Interfaces para la edición: una detallada cumpliendo la Norma ISO 19115 y otra ajustándose a
NEM.
• Es compatible con otros estándares y Normas de metadatos: CSDGM del FGDC, Dublín Core, etc.
• Uso de Tesauros para facilitar la edición de palabras clave, ejemplos de tesauros que se incluyen son: GEMET,
AGROVAC, EUROVOS, UNESCO, ISO 3166,...
CONCLUSIONES
El Núcleo Español de Metadatos, es una recomendación definida por el Consejo Superior Geográfico que establece el
mínimo número de metadatos a implementar para describir un recurso (serie o producto completo, hojas o unidades,
etc). Constituye un perfil de metadatos para España según el concepto de perfil definido por la Norma ISO 19106
“Geographic Information-Profiles”, es decir, es un modo particular y concreto de aplicar y utilizar una Norma,
concretamente la Norma Internacional ISO 19115:2003 “Geographic Information-Metadata”.
NEM está formado por un subconjunto de elementos y opciones de elementos de metadatos definidos en otras Normas
esenciales que en la actualidad existen en materia de metadatos: ISO 19115:2003 y Dublin Core Initiative,
Para facilitar la creación de metadatos conforme a NEM se ha creado la herramienta”CatMDEdit”, que está desarrollada
como proyecto Open Source (código abierto), multilingüe, multiplataforma y compatible con otros estándares o Normas
de metadatos.
Aunque hace muy poco que NEM “ha nacido”, ya existen Infraestructuras de Datos Espaciales en el ámbito regional
que están utilizando dicho perfil como base para la definición del suyo propio. Hay varios ejemplos de IDEs regionales
que definen su perfil de metadatos como la suma del NEM más otros elementos que consideran necesarios según sus
propias necesidades. Con esto se pone de manifiesto la usabilidad de dicho perfil, y permite identificarlo como una
“herramienta” aconsejable a utilizar en la creación de metadatos para los catálogos en cada una de las IDEs que están
surgiendo y que van a ir surgiendo en el futuro en nuestro país.
NEM es un perfil que nace con la finalidad de conseguir una futura interoperabilidad entre todos los catálogos de datos
que se creen en España, cumpliendo con los objetivos marcados por INSPIRE, y buscando satisfacer al máximo las
futuras exigencias marcadas por los usuarios.
REFERENCIAS
Resumen: El Editor de Metadatos del Núcleo Español de Metadatos (a partir de ahora NEM) consiste en una
herramienta totalmente integrada con la aplicación ArcCatalog de ArcGIS Desktop, capaz de generar un Metadato que
cumpla el estándar del ISO 19115 y el NEM v 1.0 e integrado en la barra de herramientas de Metadatos de ArcCatalog
implementando las herramientas de Edit Metadata, Metadata Properties, permite añadir Enclosures (ficheros Adjuntos),
Create/Update Metadata, Import Metadata y Export Metadata.
El Metadato generado con nuestro Editor seguirá integrado con la funcionalidad de búsqueda de metadatos de
ArcCatalog, para los casos de Metadatos almacenados en ArcSDE (Catalog), Sistema de Archivos (File System),
Servicio de Metadatos de ArcIMS.
El editor de Metadatos para ArcGIS siguiendo la NEM v1.0 incorpora un fichero de configuración en XML, un editor
de metadatos integrado en la interfaz de ArcGIS, una plantilla para la visualización del metadatos desde ArcCatalog y
unos ficheros de exportación e importación de los metadatos.
La implementación del Editor de Metadatos sobre tecnología ArcGIS permite aprovechar todas las ventajas que ofrece
la herramienta: búsqueda del metadato, la generación automática de ciertos campos del metadato (extensión, sistema de
referencia, etc) y el mantenimiento dinámico de ciertos campos del metadato a la edición del dato.
El editor de metadatos será similar al Wizar de la ISO de ArcCatalog, con una zona a la izquierda donde se definen las
secciones, y una zona a la derecha donde se muestran los campos de cada sección. Se remarcarán las secciones y los
campos obligatorios para una rápida localización de los elementos obligatorios.
Exportación de Metadatos
La exportación de Metadatos consiste en exportar el contenido del nodo iso19115.
Importación de Metadatos
Desde ArcGIS podremos importar un metadato que siga ISO 19115 y añadir todo el contenido definido en el metadato
importado.
SERVICIOS WEB I
137
Arqueología y Servidores de Mapas en Red. Proyecto LIFE Valle de... Sesión 5
Daniela Ballari
Miguel A. Manso Callejo
Miguel A. Bernabé Poveda
Grupo de Investigación Mercator.
Departamento de Ingeniería Topográfica y Cartografía. Universidad Politécnica de Madrid.
daniela@topografia.upm.es; m.manso@upm.es; ma.bernabe@upm.es
Resumen: El presente artículo trata sobre la aplicación de las tecnologías de Servidores de Mapas en Red, en el
ámbito de la Arqueología. Con motivo de la concesión del Proyecto LIFE: “Valle del Tiermes – Caracena” se decide
administrar e interoperar la información a generar en el proyecto, que en su mayoría posee una componente espacial,
a partir de los Geoservicios que provee una Infraestructura de Datos Espaciales, principalmente Servidores de Mapas
en Red (OGC). El principal problema encontrado fue la total falta de interoperabilidad entre la información
arqueológica, por encontrarse en archivos de diseño gráfico no georreferenciados y por la existencia de bases de datos
sin componente espacial, aunque podrían poseerla sin ningún inconveniente. El artículo expone la metodología
aplicada a los datos con el objetivo de lograr su interoperabilidad e inclusión en un Servidor de Mapas en Red para su
visualización, navegación y consulta. Dicha metodología se centra especialmente en la transformación de archivos no
georreferenciados a georreferenciados para su posterior inclusión en el Servidor de Mapas.
INTRODUCCIÓN
El Proyecto LIFE Tiermes [1] se aprueba en septiembre de 2003 dentro del Programa LIFE de la Comisión Europea de
la Dirección General XI de Medio Ambiente [2]. Este proyecto tiene como objetivo la promoción del área suroeste de la
Provincia de Soria, situada en la Comunidad Autónoma de Castilla y León. El proyecto se desarrolla en el marco
geoeconómico de los municipios de Montejo de Tiermes, Retortillo de Soria, Liceras y Caracena (Figura 1), basándose
en las potencialidades de sus valores ambientales, su riqueza patrimonial histórica y arqueológica y sus oportunidades
turísticas, principalmente del Yacimiento arqueológico de Tiermes [3]. Se pretende que dentro de unos criterios de
desarrollo sostenible, se invierta la actual tendencia a la despoblación, el abandono de tierras y la desertización.
El turismo es una de las actividades que se contempla como “potencialmente” generadora de riqueza [4], [5], dentro del
proceso de diversificación económica que se está concibiendo para los espacios rurales. El sector sur occidental se
destaca dentro de la provincia de Soria por su riqueza histórico-artística y la presencia en el interior o en sus
proximidades, de parajes naturales privilegiados. El Yacimiento Arqueológico de Tiermes figura entre los recursos
turísticos más importantes; complementado por el hecho de que patrimonio y paisaje forman un tándem sobre el que
apoyar el atractivo turístico. No obstante, actualmente faltan recursos básicos capaces de atraer y retener a la población,
La Asociación de Amigos del Museo de Tiermes, beneficiario del Proyecto LIFE Tiermes, planteó una serie de
actuaciones que permiten avanzar hacia una nueva situación de estabilización del área y crecimiento sostenible. Las
actuaciones abarcan, entre otras, los aspectos de:
1. Evaluación, protección y aprovechamiento del medio natural.
2. Evaluación protección y aprovechamiento del patrimonio histórico, arqueológico, cultural y social.
3. Promoción del conocimiento medioambiental y cultural del área.
4. Proyección de las potencialidades turísticas del área dentro las nuevas corrientes europeas de turismo
cultural y ambiental, de carácter no exclusivamente estacional.
El objetivo global del proyecto es: “…promover un sistema innovador de gestión coordinada entre los diferentes
actores para conseguir la protección del ecosistema, la ordenación del territorio y la valorización y desarrollo
sostenible del complejo histórico-natural de Tiermes”. [1]
Durante el transcurso del Proyecto (2003-2006) se generará gran cantidad de información de naturaleza muy variada:
información medioambiental de zonas protegidas, oferta turística, cultural, etnológica, arqueológica, etc. La mayor parte
de ella tendrá una componente espacial importante. Para administrar el gran volumen y diversidad de información
generada se utilizará la Tecnología de los Geoservicios que provee una Infraestructura de Datos Espaciales [6], como
ser Servidores de Mapas (Web Map Server) [7] y Servidores de Fenómenos en Red (Web Features Server) [8].
Se eligió esta alternativa frente a otras, tales como los Sistemas de Información Geográficos tradicionales, porque al
mismo tiempo que permite la administración y visualización de la información, es posible publicitar la información del
yacimiento arqueológico de Tiermes y de la comarca, a través de Internet.
De este modo usuarios no especializados podrán visualizar y consultar la Información Geográfica a través de una página
Web (Cliente ligero), de forma intuitiva y opaca para ellos, sin ser necesaria la instalación de algún software. Mientras
que los usuarios mas especializados podrán hacerlo mediante “clientes pesados” para visualizar, realizar consultas más
complejas y transacciones, como son las actualizaciones, borrado e inserciones de registros.
La capacidad de consulta de los Servidores de Mapas se extenderá a través de las interfases de Web Feature Server [8],
incluyendo consultas específicas construidas a partir de la semántica de codificación de consultas [9] del Open
Geospatial Consortium [10].
Con esta alternativa también se converge con otra iniciativa de la Unión Europea: la Iniciativa INSPIRE (The
INfrastructure for SPatial InfoRmation in Europe initiative) [11], que ha sido desarrollada con el propósito de hacer
disponible información geográfica relevante, concertada y de calidad, de forma que se permita la formulación, la
implementación, la monitorización y la evaluación de las políticas de impacto o de dimensión territorial, de la
Comunidad Europea. INSPIRE es una iniciativa legal que establecerá estándares y protocolos de tipo técnico, aspectos
organizativos y de coordinación, políticas sobre la información que incluye el acceso a los datos y la creación y
mantenimiento de información espacial. Es el primer paso de una amplia iniciativa multilateral que inicialmente dirigirá
su interés sobre la información espacial necesaria para políticas medioambientales y que estará disponible para
satisfacer las necesidades prácticas de otras áreas, tales como la agricultura y el transporte [12].
Gran parte de la información geográfica generada en el proyecto LIFE-TIERMES será del tipo medioambiental, de allí
la importancia de converger con la iniciativa INSPIRE.
El Servidor de Mapas y Fenómenos en Red permitirán la visualización y consulta de la información generada por el
proyecto, que admita ser georreferenciada. La extensión geográfica del servicio será la Comarca de Tiermes
(Municipios de Montejo de Tiermes, Retortillo de Soria, Caracena y Liceras) y contendrá capas tales como:
• Información Geográfica básica: Límites administrativos (provinciales, municipales, núcleos urbanos), curvas
de nivel, carreteras, ríos, ciudades y poblados, catastro, ortofotos, cartografía oficial en formato papel
escaneada a escalas 1:100.000, 1:50.000 y 1:25.000, Modelo digital del terreno (resolución de 25m por píxel).
• Información generada por el Proyecto LIFE Tiermes: información medioambiental, demanda turística, oferta
turística, cultural, etnológica, arqueológica, etc.
• Información del Yacimiento arqueológico de Tiermes: información generada durante las campañas de
excavación: planimetría de estructuras, unidades estratigráficas, fotografías, etc.
Para poner en marcha el Web Map Server se utilizó el software MapServer [13], desarrollo Open Source [14], iniciado
por la Universidad de Minnesota [15], en conjunto con la NASA. El principal actor en el desarrollo del proyecto
actualmente es el Grupo DM Solutions [16], quien mantiene e incrementa su funcionalidad. Actualmente implementa
las siguientes especificaciones del OGC [21]: Servidores de WMS, WFS y WCS [17]; Clientes WMS y WFS; Acepta
SLD [18], Filter, GML [19] y WMContext [20].
Para poner en marcha el Web Feature Server, se utilizó el software Geoserver [22]. Se trata de un proyecto Open Source
cuyo desarrollo ha sido y está siendo financiado por distintas iniciativas privadas y gubernamentales con el objeto de
alcanzar un conjunto de objetivos de interés para las organizaciones. Geoserver implementa las especificaciones WFS
transaccional y WMS del OGC. Puede utilizar distintas fuentes de información entre las que se encuentran: Oracle,
ArcSDE, PostGis y Shapefile. La cualidad que diferencia el proyecto del resto es que la gestión de los Servicios está
integrada en una interfaz Web. [21]
El presente artículo trata sobre la puesta en marcha de un Servidor de Mapas correspondiente al primer y tercer tipo de
información antes nombrado: Información Geográfica Básica e Información del Yacimiento Arqueológico de Tiermes.
La inclusión de las capas de información propias del proyecto LIFE-TIERMES (segundo tipo) se realizará cuando la
fase de recolección y producción de dicha información se halle finalizada según el cronograma del proyecto.
El principal inconveniente encontrado fue que los datos arqueológicos en bruto disponibles para construir el Servidor
de Mapas, eran no interoperables. Por este motivo fue necesario encontrar una metodología que posibilitara la
interoperabilidad, visualización y consulta de dicha información, a través de la Web.
A continuación se expone la situación original para cada tipo de información. En segundo lugar la metodología
desarrollada para conseguir su interoperabilidad e inclusión en un Servicio Web Map Server. En tercer término se
presenta la situación final lograda a través de la visualización y consulta de la Información en un cliente ligero. Por
ultimo se muestran las conclusiones, los agradecimientos y las referencias.
Tras finalizar la campaña arqueológica del año 2004 en el yacimiento arqueológico de Tiermes se disponía de la
siguiente información:
- Dibujos de planimetrías en formato FreeHand [23]
- Base de Datos no espacial de unidades estratigráficas.
2.1.- Dibujos de planimetrías realizados a mano por los arqueólogos (Figura 2), escaneados y digitalizados en FreeHand
(Figura 3), que contienen:
• las estructuras arqueológicas para cada nivel de avance de la excavación (Unidades Estratigráficas),
• el tipo de material del terreno y muros (ejemplo: caliza, arenisca, toba, etc),
• los puntos acotados,
• la identificación numérica de Unidades Estratigráficas.
Otras características de estos archivos son:
• Escala: 1:50,
• Formato: fh8, formato propietario de FreeHand ,
• Sistema de referencia: Como casi todos los entornos de Diseño Gráfico, FreeHand, no soporta la
georreferenciación de sus archivos.
Así pues los problemas para su inclusión como capas en servidores WMS son:
o Archivos sin georreferenciación
o Dibujos fragmentados limitados por la utilización de folios tamaño A4 a escala 1:50.
Figura 2. Dibujo de planimetría realizado a mano en campo Figura 3. Dibujo de planimetría escaneado y editado en FeeHand.
2.2.- Base de datos no espacial Access (Figuras 4 y 5). Esta base de datos contiene la información que define a las
unidades estratigráficas (extensión superficial de análisis arqueológico en un momento determinado de la excavación),
como son:
• consistencia,
• color,
• descripción,
• cotas máximas y mínimas,
• unidades estratigráficas a las que corta o adosa,
• materiales, etc.
Otras características de estos archivos son:
• Formato: mdb (bases de datos de Microsoft Access),
• Sistema de referencia: La base de datos no tiene asignada geometría.
Así pues el problema para su inclusión como atributos asociados a geometrías en servidor WMS:
o No posee geometría asignada, aunque es susceptible de ser incluida.
Figura 4. Base de Datos Access. Visualización de Formulario Figura 5. Base de Datos Access. Visualización de Tabla
Para superar la falta de interoperabilidad y la carencia del “vínculo automático” se desarrolló la siguiente metodología:
El objetivo consiste en unir todos los fragmentos de planimetrías (en nuestro caso más de 100 archivos generados
durante la campaña arqueológica del año 2004), georreferenciarlos e incluirlos en el Servidor de Mapas.
La metodología es la siguiente:
3.A.1.- Primero se debe georreferenciar cada dibujo. Pero para ello se necesita disponer de puntos con referencia
espacial (coordenadas) del yacimiento que sean identificables en los dibujos de planimetrías. Para alcanzar este
objetivo se realizó un Plano topográfico (Figura 6) mediante topografía clásica, con las siguientes características:
• Tipo de información que contiene: estructuras arqueológicas del Foro Romano y Acueducto y puntos acotados.
• Escala: 1:200
• Formato: DXF
• Sistema de referencia: EPSG 23030 [24] (UTM - European Datum 1950 – Zona 30). Altitudes referidas al
nivel medio del mar en Alicante.
Figura 6: Plano topográfico con zonas de intervención de Figura 7: Fotografía del Yacimiento
campaña julio-diciembre de 2004
3.A.4.- Georreferenciación: La información obtenida del paso anterior se inserta como bloque en el Plano Topográfico
de AutoCAD, que contiene las estructuras arqueológicas topografiadas.
Con la ayuda del comando “ALIGN” se identifican dos puntos del dibujo de planimetría que se correspondan con el
plano topográfico. El dibujo se traslada, rota y escala de forma que los puntos coincidan (Figura 11), ajustándose la
planimetría al plano topográfico. Otras herramientas, producen la deformación de los dibujos obligándolos a ajustarse a
un elevado número de puntos seleccionados. Puesto que los arqueólogos tienen más precisión en el dibujo de las formas
pequeñas que en el dibujo de varias estructuras arqueológicas en conjunto, se prefirió renunciar a una exacta ubicación
antes que introducir una distorsión de las formas. Además dado que las planimetrías sobre las que se aplicaría el
algoritmo son de pequeño tamaño (alrededor de los 100 m2) y no tienen influencia otras circunstancias geodésicas del
terreno se consideró adecuada la traslación, rotación, y escalado, en lugar de otros métodos polinómicos mas complejos.
Una vez que el dibujo se encuentra georreferenciado se guarda como DXF nuevamente.
3.A.7.- Inserción de la Capa Planimetría en el Servidor de Mapas: Para construir un Servidor de Mapas con
MapServer, debe definirse en el archivo de configuración “*.map”(mapfile) [27] las capas de información que
contendrá el servicio. Para cada una deberá indicarse:
• si se trata de una capa del tipo Puntos, Línea, Polígono, Anotación o Raster,
• el directorio donde se almacenan los datos o el URL de los servidores remotos que se deseen incluir,
• el sistema de referencia y
• un estilo de visualización para cada capa.
En nuestro caso se define una capa de información para cada tipo de geometría: polígonos, líneas y puntos.
La capa de polígonos contiene como atributos los tipos de materiales de los muros y del terreno. A partir de estos
atributos, se construyen filtros para asignar un estilo de visualización a cada material.
La capa de líneas contiene la línea exterior de las estructuras y rebajes en las rocas.
La capa de puntos se utiliza para colocar los textos de las unidades estratigráficas y las cotas (capas del tipo anotación),
que son atributos en el archivo Shp.
A continuación se compara el aspecto de una planimetría en FreeHand (Figura 12) con el aspecto obtenido en el
Servidor de Mapas (Figura 13). Debe destacarse que no sólo el aspecto es idéntico, sino también contiene exactamente
la misma información, esto quiere decir que no se ha perdido información con la metodología aplicada.
Figura 12. Visualización de estilo del archivo original en Figura 13. Visualización obtenida en el Cliente WMS.
FreeHand http://mapas.topografia.upm.es/tiermes
La base de datos de información de las unidades estratigráficas es del tipo no espacial, ya que no contiene geometría, ni
referencia espacial alguna.
La única posible vinculación de la base de datos con la planimetría (ahora ya en shp) es a través del atributo de las
“unidades estratigráficas” (UE) puesto que:
• La base datos Access posee un campo llamado “UE” que contiene el identificador de la misma.
• El shp de puntos generado en el punto A.5, contiene un campo llamado “LAYER” que contiene dos tipos de
atributos: “COTAS” y “UE”. Además de otro campo llamado “TEXTSTRING” que contiene los valores
numéricos de las cotas y las unidades estratigráficas correspondiente a cada punto (Figura 15).
El problema es simple y radica en unir ambas bases de datos según los elementos comunes, que son las “UE”. Para ello
se aplica la siguiente metodología:
3.B.1.- Exportación de la base de datos Access a SQL [28] e inserción de la misma en PostgreSQL + PostGIS [29] [30]
3.B.2.- Transformación del shp de puntos a SQL con la herramienta shp2pgsql.exe de PostGis. Inserción del SQL en
PostGis. El SQL contiene geometría puntual correspondiendo al punto de inserción del texto de unidades estratigráficas.
3.B.3.-Teniendo las dos tablas cargadas en PostgreSQL (Fichas UE y puntos de planimetría) se ejecuta una consulta
SQL que genera una nueva tabla que contenga la unión de las dos tablas anteriores. Es decir, la nueva tabla que
contendrá la información de cada unidad estratigráfica asociada a una geometría.
Las Unidades Estratigráficas siempre se refieren a una extensión superficial, esto es un área o polígono. Pero en este
caso debido a la falta de homogeneidad e integridad de la información proporcionada, fue imposible asignarle tal
geometría, pudiendo generase solamente una geometría puntual. Como consecuencia toda unidad estratigráfica queda
referenciada por medio de un texto asociado a un punto sin que tengamos constancia de su extensión.
Se incluye en el archivo de configuración mapfile del servidor de mapas la tabla de la base de datos espacial PostGis,
generada en el párrafo anterior, como una capa del tipo puntual. La visualización se realizará a través del punto de
inserción del texto para cada unidad estratigráfica. Este punto permitirá vincular la visualización con la consulta. Para
ello al realizar un chic en modo de consulta, sobre la etiqueta de UE en el cliente WMS, se abrirá una ventana del
explorador con la información correspondiente a dicha UE (Figura 16).
El servidor de Mapas también incluye Cartografía Básica de la Comarca de Tiermes-Caracena. Contiene capas tales
como: Cartografía Regular a escalas 1:10.000, 1:50.000 y 1:25.000 escaneadas, georreferenciadas y recortadas; límites
administrativos, provinciales, comarcales y municipales; catastro y ortofotos.
La inclusión en el Servidor de Mapas de estas capas no presentó mayores inconvenientes.
.
Figura 17. Visualización de la información geográfica básica de Figura 18. Visualización conjunta de las capas Ortofoto y
la comarca de Tiermes-Caracena. Catastro de una región del municipio de Retortillo de Soria.
5- CONCLUSIONES
6- Agradecimientos
La realización de este trabajo ha sido posible gracias a la financiación del Proyecto LIFE TIERMES: VALLE DEL
TIERMES - CARACENA (TIERMES-CARACENA VALLEY LIFE 03 ENV/E/000161)
REFERENCIAS
[1]2003. Proyecto LIFE TIERMES: VALLE DEL TIERMES - CARACENA (TIERMES-CARACENA VALLEY LIFE 03
ENV/E/000161) http://lifetiermes.net
[2] http://europa.eu.int/comm/environment/life/home.htm
[3] Yacimiento Arqueológico de Tiermes http://tiermes.net
[4] http://www.estema.es/serviciosalumnos/Publicaciones/RevistaNT/especial.asp?seccion_especial=2&especial=1
[5] El turismo como generador de riqueza: la comunidad valenciana como modelo del siglo XXI.
http://www.estema.es:1080/Actividades/turismo/
[6] 2005. D. Ballari, R. Hernandez. “Las Infraestructuras de Datos Espaciales y sus principales componentes tecnológicos” El
Agrimensor Chubutense. Volumen: nº 12, Página 3-11. Fecha:
[7] 2004. OGC “OGC Web Map Service Interface”; Version: 1.3. Open GIS Consortium Inc; Date: 2004-08-02; Reference
number of this OpenGIS® project document: OGC 04-024. http://www.opengeospatial.org/specs/?page=specs
[8] 2002. OGC “Web Feature Service Implementation Specification”; Version: 1.0.0;Open GIS Consortium Inc.;Date: 19-
September-2002;Reference number of this OpenGIS® project document: OGC 02-058.
http://www.opengeospatial.org/specs/?page=specs
[9] 2005. OGC “Filter Encoding Implementation Specification”; Version: 1.1.0;Open GIS Consortium Inc.;Date: 3-May-
2005;Reference number of this OpenGIS® project document: OGC 04-094. http://www.opengeospatial.org/specs/?page=specs
[10 Open Geospatial Consortium (OGC). http://opengeostapatial.org
[11] Infraestructura for Spatial Information in Europe. http://www.ec-gis.org/inspire/
[12] http://www.idee.es/show.do?to=pideep_INSPIRE.ES
[13] MapServer. http://mapserver.gis.umn.edu/
[14] Open Source. http://www.opensource.org/
[15] University of Minnesota. http://www.umn.edu
[16] DM Solutions Group. http://www.dmsolutions.ca/
[17] 2003. OGC “OpenGIS® Web Coverage Service (WCS) Implementation Specification” Version: 1.0. Open GIS Consortium
Inc.Date: 16-October-2003- Reference number of this OpenGIS® project document: OGC 03-065r6.
http://www.opengeospatial.org/specs/?page=specs
[18] 2004. OGC “OpenGIS® Styled Layer Descriptor (SLD) Implementation Specification ” Version: 1.0 Open GIS Consortium
Inc.Date: 19-Agosto-2002- Reference number of this OpenGIS® project document: OGC 02-070.
http://www.opengeospatial.org/specs/?page=specs
[19] 2004. OGC“OpenGIS® Geography Markup Language (GML) Encoding Specification” Version: 3.1.1. Open GIS
Consortium Inc.Date: 19-April-2004- Reference number of this OpenGIS® project document: OGC 03-105r.
http://www.opengeospatial.org/specs/?page=specs
[20] 2005. OGC “OpenGIS® Web Map Context Implementation Specification” Version: 1.1. Open GIS Consortium Inc.Date: 3-
May-2005- Reference number of this OpenGIS® project document: OGC 05-005 .
http://www.opengeospatial.org/specs/?page=specs
[21]2005. M.A. Manso, M.A. Bernabé . “Open Source componets for geospatial portal”. Congreso: International Cartographic
Conference (ICC 2005) http://www.icc2005.org/html/oralposters/schedule.pdf
[22] . Geoserver. GeoServer project. http://sourceforge.net/projects/geoserver
[23] Macromedia FreeHand. http://www.macromedia.com/software/freehand/
[24] European Petroleum Survey Group. http://www.epsg.org/
[25] shp. ShapeFile Format
[26] Feature Manipulation Engine Universal Translator. http://www.safe.com/
[27] MapFile Reference - MapServer 4.0”. http://mapserver.gis.umn.edu/doc40/mapfile-reference.html
[28] SQL.
[29] PostgreSQL. http://www.postgresql.org/
[30] PostGis. http://postgis.refractions.net/
Resumen: En el plano de los Usuarios, las Infraestructuras de Datos Espaciales (IDEs), se conciben como las piedras
angulares sobre las que realizar operaciones de visualización, análisis y toma de decisiones. La mayoría de los
usuarios de datos espaciales no tienen necesidades especiales de visualización. Por esta razón las organizaciones que
hacen pública dicha información utilizando las interfaces de Servicios de Mapas en la Web (WMS) definidas por el
Open Geospatial Consortium (OGC) definen un estilo de visualización por defecto para la Información Geográfica
(IG). Estos estilos de visualización definen los colores, los grosores, los patrones de línea, los rellenos, la tipografía del
texto, etc… de una forma genérica, en muchos casos bien cuidada y en la mayoría de los casos utilizan los estilos
tradicionales de la Cartografía Oficial. El resto de usuarios “avanzados” de la IG necesita controlar y gestionar la
forma en la que se visualiza dicha información de modo que se facilite la toma de decisiones, la legibilidad, etc… Para
este tipo de usuarios el OGC ha definido un conjunto de especificación que permite definir los estilos de visualización
de las geometrías y atributos entre las que están Style Layer Descriptior (SLD) y Filter Encoding (FE) que permite
definir filtros espaciales, lógicos y aritméticos. En este documento se presentan los avances realizados desde el puntos
de vista práctico de la implementación de una herramienta que permite a los usuarios interactuar con el servicio WMS
y en otros casos con el Servicio de Entidades-Objetos en la Web (WFS) para permitir que dichos usuarios avanzados
puedan definir las reglas de visualización que desean aplicar. El diseño e implementación de la herramienta ha sido
ideado para que sea portable y para que pueda interactuar con servicios Web conformes con las especificaciones del
OGC.
INTRODUCCIÓN
Mediante las Infraestructuras de Datos Espaciales (IDEs), cualquier usuario tiene a su disposición una importante
cantidad de geodatos o datos espaciales, posibilidad que alcanza también a la visualización de estos geodatos a través de
la red.
Para este fin surgen los Servicios de Mapas por Internet (Web Map Services)[3], que proporcionan un medio de gestión
y visualización de geodatos a través de la red. En la actualidad, estos servicios adolecen de una serie de limitaciones,
entre ellas la falta de herramientas automáticas de generación de mapas acorde a las necesidades o caprichos del
usuario. Más concretamente: Siguiendo unas especificaciones de estilo personalizadas.
Open Gis Consortium (OGC), en su objetivo de proporcionar interoperabilidad a los usuarios de las Infraestructuras de
Datos Espaciales, pretende solucionar este problema mediante la creación del lenguaje SLD (Style Layer Descriptor).
Este lenguaje permite al usuario definir la simbología deseada para la visualización de los datos geográficos.[1]
SLD es un documento en XML que describe detalladamente la simbolización para las capas de un servidor, contiene
todos los parámetros posibles de estilo dependiendo de la geometría de la capa.
Mediante el lenguaje SLD cualquier usuario puede comunicarse con el servidor para el tratamiento de los estilos de sus
capas. Dicha comunicación es en doble sentido:
- El servidor comunica al usuario la simbología empleada en cada capa: Mediante la petición GetStyles el
usuario recibe el documento XML con la definición del estilo por defecto que tiene la capa, estilo que aplica
por defecto ante peticiones de visualización con la petición GetMap [3].
- El usuario comunica al servidor el estilo con el que quiere visualizar las capas de geo-información mediante la
petición GetMap.
Esta especificación SLD, debido a su estructura en XML y su fundamento en otras especificaciones del OGC, puede
resultar compleja en varios aspectos:
- Para los usuarios que no tengan una serie de conocimientos de estos campos.
- Incluso para los usuarios experimentados y con altos conocimientos, la elaboración del documento SLD que
contenga sus especificaciones de estilo personalizados consume mucho tiempo comparado con la obtención
casi instantánea de un mapa de un WMS.
Teniendo en cuenta estos aspectos y el hecho de que la misión de los servidores es la de facilitar instantáneamente a
cualquier usuario un mapa de una manera sencilla y accesible, se ha decidido diseñar una herramienta que facilite la
creación de los documentos SLD que se ajusten a sus necesidades.
El objetivo primordial de esta herramienta es facilitar al usuario la obtención instantánea de documentos cartográficos
de una manera sencilla, asequible y ajustándose a las necesidades del usuario.
La funcionalidad básica de esta herramienta es la elaboración automática, en un proceso transparente al usuario, de los
documentos SLD según especificaciones de estilos personalizados que elige fácilmente el usuario mediante interfaces
de estilo. Una vez elaborados estos documentos, se comunica con el servidor para obtener y mostrar al usuario el mapa
resultante de aplicar estos estilos.
A esta herramienta se la podrían añadir multitud de funcionalidades cartográficas variadas: Aplicación de filtros,
herramientas de almacenamiento y recuperación, etc… El resultado obtenido de esta forma contendría las ventajas de
un software de sobremesa sin prescindir de las propias de un WMS como la disponibilidad de cualquier dato geográfico
que haya en red sin necesidad de tenerlo almacenado en local, lo que supone grandes beneficios de espacio de
almacenamiento, de tiempo, y consecuentemente económicos.
En definitiva, mediante el perfeccionamiento de esta herramienta se busca la explotación especializada de los WMS con
el objeto de obtener mapas con calidad cartográfica que permita el uso de símbolos variados y elegidos por el usuario en
función de distintas condiciones como pueden ser la naturaleza cualitativa o cuantitativa de la información a
representar, el tipo de símbolos a emplear, etc…, este hecho facilita la obtención de Cartografía Temática a través de un
servidor de mapas.
La justificación del desarrollo de esta herramienta induce a la justificación del uso de SLD para obtener mapas a través
de un WMS.
1
OBJETIVO 2 3
SOLUCIÓN DESENLACE
1. Objetivo
Si se logra la obtención de mapas según indicaciones de un usuario, a partir de un WMS, tendríamos la posibilidad de
construir símbolos variados en función de los valores de atributos de los datos a representar. Esto nos conduciría a la
producción casi instantánea de Cartografía Temática a través de Internet y sin necesidad de poseer en local los datos
geográficos a cartografiar.
• Layers: Mediante este parámetro, el usuario indica los datos geográficos del servidor que quiere visualizar.
• Bbox: Indica de que zona en concreto quiere la visualización de los datos deseados.
• SRS: En que sistema de referencia.
• Width & Height: Para expresar el tamaño del mapa deseado.
• Format: Que formato de la imagen del mapa es el requerido: GIF, JPG, SVG…
Se encuentra con que la geometría, el formato y los contenidos se corresponden con los deseados. Pero la simbolización
obtenida de estos datos, los estilos por defecto de las capas, puede no ser apropiada para el usuario, no adaptándose a
sus necesidades. Mediante la petición con estos parámetros básicos tampoco se puede obtener variación de simbología
dentro de la misma capa de datos, cerrando las puertas de un WMS a la producción de Cartografía Temática.
Para adecuar esta petición de forma que el usuario pueda elegir la simbología deseada habría que introducir un
parámetro más:
• SLD_BODY: Mediante el cual el usuario puede introducir los estilos de las capas indicadas en Layers.
2. Solución
Mediante la especificación Styled Layer Descriptor (SLD)[1] podemos obtener mapas personalizados a partir de los
datos ofrecidos en un servidor de información geográfica.
Fue creada por OGC para dar solución a esta necesidad de permitir al usuario definir su propia simbología, definiendo
un mecanismo para la determinación del estilo de cada capa.
Esta especificación define cinco tipos de simbolización, que depende de la geometría de la capa a la que se quiere
personalizar (lineal, poligonal, puntual, textual y ráster). Según esta geometría de capa, se podrán modificar unos
parámetros de estilo u otros: En la poligonal se podrá definir colores de línea y relleno, grosores…, en la textual serán
otros parámetros como fuente de texto, tamaño de letra…
SLD es un documento en XML que define el estilo de las capas: En este documento se introduce un estilo por cada una
de las capas a las que se quiere dar estilo tal como se muestra en el siguiente esquema:
DocumentoSLD.sld
<STYLEDLAYERDESCRIPTOR>
<NAMEDLAYER>
<NAME> Layer1</NAME>
<USERSTYLE>
Definición de estilo para la capa Layer1
.........
</USERSTYLE>
</NAMEDLAYER>
<NAMEDLAYER>
<NAME> Layer2</NAME>
<USERSTYLE>
......... Definición de estilo para la capa Layer2
</USERSTYLE>
</NAMEDLAYER>
</STYLEDLAYERDESCRIPTOR>
Para la obtención del mapa con el estilo definido dentro del documento SLD, se introduce este documento en la
petición GetMap mediante el parámetro Sld_Body. Para introducir este documento por la URL hay que hacer
previamente un preproceso de los caracteres especiales según el protocolo HTTP.
3. Desenlace
El hecho de introducir manualmente este documento SLD en la petición GetMap supone una serie de inconvenientes:
• Necesidad de conocer esta especificación y lenguaje XML por parte del usuario, que puede no estar al tanto de
estas tecnologías.
• Necesidad de conversión de los caracteres especiales para poder ser introducidos en la URL.
• Medio poco ergonómico a la hora de introducir parámetros de estilo: colores, grosores… (Especialmente el
color, que hay que introducirlo en formato hexadecimal)
• La creación del documento es complicada y laboriosa, especialmente cuando se quieren introducir filtros para
hacer más variada la simbología dentro de la misma capa. Este documento puede llegar a tener una gran
extensión si se da estilo a varias capas.
Todos estos inconvenientes hacen inviable la petición manual a través de la URL de un mapa personalizado mediante la
inclusión del documento SLD.
Esto nos lleva a pensar en el diseño de una herramienta interactiva de edición de estilos y visualización de contenidos a
través de un WMS.
Por ello se ha realizado una herramienta-cliente que genere automáticamente este documento y lo envíe en la petición.
Mediante esta herramienta se obtienen además ventajas propias de la utilización de clientes de WMS, como la
posibilidad de obtener un mapa con superposición de capas provenientes de distintos servidores. Esto aumenta
enormemente las posibilidades de alcanzar a todos los geodatos en red, pudiéndose obtener una gran cantidad y
variación de cartografía de todo el mundo.
El usuario interactúa con el servidor a través de la herramienta que crea el documento SLD en un proceso transparente
para el usuario. El usuario indica el estilo deseado a través de interfaces de elección de estilos y formas de
representación.
REQUISITOS DE LA HERRAMIENTA
El objetivo de esta herramienta es permitir visualizar interactivamente capas de un servidor de mapas (WMS) en las
cuales se está modificando dinámicamente el estilo de presentación. La definición de dichos estilos se basa en la
especificación SLD. De este modo se construirá de forma dinámica la petición (GetMap) sobre el WMS que posee la
capa de información geográfica de interés. Como resultado se presentará la capa con los estilos correctamente aplicados
que previamente se han definido a través de un interface de usuario.
A parte de este objetivo fundamental la herramienta debe de reunir una serie de funcionalidades:
• Ventana de selección de capas: En la cual se muestran las capas que contiene el servidor a partir de la petición
GetCapabilities. En esta ventana se eligen las capas a visualizar en el mapa.
• Interfaces de elección y edición de estilos según la geometría de cada capa: La finalidad es facilitar al usuario
la definición de sus estilos personalizados mediante interfaces ergonómicas en las cuales se pueda elegir los
parámetros en función de lo que admita cada geometría. También dar la posibilidad de editar o modificar estos
estilos en la misma sesión o en otras posteriores.
• Guardado y recuperación del documento SLD: Una vez definidos los estilos capas y el usuario está conforme
con la visualización del mapa resultante sujeto a estilos, se le debe dar la opción de guardar el documento SLD
creado para reutilizarlo otro día, en el mismo proyecto o en otros diferentes.
• Aplicación de filtros: Ofrecer al usuario interfaces que le permitan la posibilidad de clasificar las distintas
features mediante la adecuada aplicación de filtros (FE). Para poder aplicar distintos estilos de simbolización a
distintos tipos o clases de features dentro de una misma capa de información, existe un lenguaje de
codificación denominado Filter Encoding (FE)[2]. La aplicación de tales filtros de selección de objetos en base
a uno o varios de sus atributos almacenados (por ejemplo densidad de tráfico en una carretera, superficie de
términos municipales, etc.) se materializan de modo formal en reglas (rules) que se aplican para la consecución
de una simbología más compleja.
• Herramienta GetFeatureInfo: Mediante la cual podremos obtener el valor de los atributos de las features que
aparecen en el mapa para informar al usuario de estos valores e incluso para ayudarle a decidir a cuales le
gustaría aplicar filtros.
• Añadir varios servidores: Dar la posibilidad de poder superponer varias capas de servidores distintos. Para ello
las peticiones de mapa deben tener el mismo BBOX, SRS, y las capas deben ser transparentes.
• Zoom: Como en cualquier software de cartografía, se necesita una herramienta que gestione el encuadre de la
zona a repesentar. En el caso de los clientes de WMS, para seleccionar el Bbox de una manera cómoda.
• Formato del mapa: Dar la opción de elegir el tamaño y ancho del mapa resultante. Son los parámetros width y
height.
• Guardado / Impresión del mapa: Una vez que el usuario está conforme con el mapa resultante se le debe de
dar la opción de guardarlo e imprimirlo.
DISEÑO DE LA HERRAMIENTA
La funcionalidad de la herramienta es, básicamente, la adecuación de la petición GetMap con las especificaciones de
estilo del usuario, y posteriormente mostrar al usuario el mapa resultante.
1º 3º
Petición con Estilo por Defecto Petición con Estilo Personalizado
http://mapas.euitto.upm.es/cgi-bin/madrid? http://mapas.euitto.upm.es/cgi-bin/madrid?
SERVICE=WMS SERVICE=WMS
&Version=1.1.1 &Version=1.1.1
&Request=GetMap &Request=GetMap
&LAYERS=roads &LAYERS=roads
+ SLD_BODY=%3CStyledLayerDescriptor%3E
.................
%3C%2FStyledLayerDescriptor%3E
SLD_BODY=%3CStyledLayerDescriptor%3E
.................
%3C%2FStyledLayerDescriptor%3E
<StyledLayerDescriptor>
.................
</StyledLayerDescriptor>
De modo que la herramienta interactúa por un lado con el usuario y por otro con los servicios WMS y WFS (este último
solo aparece cuando se desea la implementación de filtros en la simbología) según el siguiente diagrama de actividad:
Inicia Aplicación
Muestra Capas
Seleccionar capa
GetStyle
Editar estilo
Geometría +
Estilo por defecto
UI de Estilo concreto
Seleccionar capa
Editar estilo con Filtro DescribeFeatureType
Atributos
Calcula valores MAX/MIN
*
Presenta Imagen
Guardar Estilo
Leyenda de Esquema
UI de Exploración y
Nombre de Archivo
SECTOR Acción
Petición Respuesta
Recuperar Estilo
UI de recuperación
de Estilo
* MapServer y GeoServer no soportan estas funciones
CONCLUSIONES
La aplicación de la especificación Styled Layer Descriptor abre la posibilidad de obtener de manera automática y rápida
un mapa de cualquier tipo según las particularidades de cada usuario, al igual que ocurre con las aplicaciones SIG de
sobremesa, pero con la ventaja de trabajar con datos geográficos remotos:
• Con este lenguaje se puede manipular la visualización de cualquier mapa obtenido a través de un WMS, WFS
o WCS.
• La herramienta desarrollada introduce mediante el parámetro CGI SLD_BODY el documento SLD sin
necesidad de que el usuario conozca el funcionamiento de los servidores de mapas.
• Mediante la cuidada y adecuada utilización de los filtros se puede adecuar notoriamente la simbología,
permitiendo que la misma dependa de los valores de los datos a representar. Esto hecho abre la posibilidad de
obtener Cartografía Temática personalizada al momento
• Por un lado que el servicio, y por tanto la operación GetMap, soporte el parámetro SLD_BODY. No todos los
Web Map Services soportan este parámetro.
• La petición GetStyles, necesaria para que la herramienta pueda obtener automáticamente la geometría de cada
capa. Esta petición no es obligatoria, por lo que muchos WMS no la implementan. Esto supone una deficiencia
a este respecto. Este problema se solucionaría añadiendo en el documento de Capabilities la geometría de cada
capa.
En cuanto a la superposición de las capas de información procedentes de distintos servidores, es imprescindible que las
capas (o formatos gráficos soportados) admitan transparencia, hecho que no siempre ocurre.
Desde el punto de vista de la interoperabilidad y de la usabilidad es deseable que almenos a nivel nacional se
estandarize el nombre de las capas.
Además mediante la especificación de FE (Filter Encoding) se pueden definir reglas de simbolización que afectan de
manera individual a cada feature, lo que permite la elaboración de mapas temáticos con simbologías complejas. Para
ello se necesita en la mayoría de los casos conocer los valores máximos y mínimos de los atributos que se quieren
clasificar. Esto se obtendría mediante el elemento ”Function” de FE, aunque actualmente la mayoría de los servidores
WFS no lo implementan.
Desde el punto de vista de la automatización de los procesos de definición de estilos de visualización de IG procedente
de distintos ámbitos geográficos sería deseable que el nombre de los atributos comunes estubiera consensuado o
estandarizado.
Tanto en sistemas de sobremesa como en sistemas remotos, es el propio usuario final el que se responsabiliza del
proceso cartográfico de composición del mapa. Esto no significa que tenga los conocimientos cartográficos necesarios
para crear un documento simbólico adecuado. Se va a tender a definir asistentes de ayuda para la creación de estilos de
visualización apropiados a la naturaleza de la información a representar, pero siempre usando estándares abiertos e
internacionales que posibiliten la interoperabilidad. Estos asistentes deben garantizar lo mejor posible que el documento
final tenga una semiología gráfica correcta, independientemente de la pericia del usuario. Otra posible perspectiva de
trabajo está relacionada con la implementaciín de esta misma funcionalidad en el proyecto Geoserver.
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
3. Open Geospatial Consortium Inc.(2002): Web Map Service. Reference number of this OGC™ project document: OGC 04-024.
Version: 1.3
Resumen: Los últimos desarrollos en SIG muestran una clara tendencia evolutiva en base a dos requerimientos
básicos: el acceso web a la información geoespacial y la adopción de estándares que faciliten la interoperabilidad
entre los diferentes sistemas de almacenamiento, servicios y aplicaciones SIG existentes y futuras. Prueba de ello es la
aparición de iniciativas como el Open Geospatial Consortium (OGC). Por otro lado, se aprecia una necesidad cada
vez mayor de visualizar escenas 3D a partir de información geoespacial, en especial en áreas como la planificación
urbanística y territorial, navegación y telecomunicaciones, gestión de desastres naturales, turismo y aplicaciones
militares. En este trabajo presentamos un nuevo servicio de visualización 3D de datos espaciales diseñado en base a
las siguientes premisas: desplegarse en un entorno web e implementar interfaces estándares que faciliten la
interoperabilidad en un entorno de servicios distribuido.
1. INTRODUCCIÓN
Con objeto de facilitar el acceso a la información geoespacial disponible, las administraciones públicas están
impulsando la creación de Infraestructuras de Datos Espaciales (IDE). Desde la Comisión Europea se ha promovido una
inciativa, INSPIRE (INfraestructure for SPatial InfoRmation in Europe), en un intento de establecer mecanismos
adecuados para el acceso, creación y mantenimiento de la información espacial (INSPIRE proposal, 2004). Estas
nuevas infraestructuras son posibles gracias a los continuos avances en el desarrollo de los Sistemas de Información
Geográfica (SIG). Siendo uno de los objetivos primordiales el facilitar el acceso público a los datos espaciales, es
evidente que las tecnologías web se muestran como un elemento de especial relevancia. Por otro lado, el diseño de la
arquitectura software de estas nuevas infraestructuras se basa en la distribución de las funcionalidades sobre diferentes
servicios interoperables (INSPIRE architecture, 2002).
En este artículo presentamos el desarrollo de un nuevo servicio web de visualización de escenas 3D generadas a partir
de datos espaciales, el Web 3D Scene Service (W3DSS). Está diseñado para integrarse en un entorno distribuido de
componentes web de datos y visualización, acorde a las recomendaciones del OGC, donde diferentes servicios tales
como WMS, WFS y WCS actuarían como fuentes de datos. Aunque se basa en la especificación de interfaz y
arquitectura propuesta en el W3DS del OGC, presenta como novedad la adopción de un nuevo lenguaje de definición de
estilos, el SLD3D, similar al SLD del WMS, que facilita al cliente del servicio un control total del proceso de
generación y visualización de la escena.
2. INTEROPERABILIDAD
La interoperatividad entre servicios, basada en la adopción de estándares para la representación de datos espaciales y
para la especificación de interfaces de comunicación, proporciona numerosas ventajas en el ámbito de su aplicación a
los entornos SIG. A diferencia de las soluciones software tradicionales, por lo general monolíticas y propietarias, las
nuevas arquitecturas para la construcción de IDEs establecen un modelo distribuido basado en servicios interoperables.
Estos servicios, organizados en diferentes niveles de responsabilidad, actuarán de forma encadenada para proporcionar
los resultados deseados en cada momento. Por ejemplo, un mapa de riesgo potencial de incendios mostrado por un
servicio genérico de visualización podría haber sido generado por un servicio de análisis que implementaría la lógica
necesaria para el cálculo de los índices de riesgo y que, a su vez, obtendría los datos de campo a partir de diferentes
servicios de gestión y almacenamiento de datos espaciales. Esta distribución de responsabilidades, unida al empleo de
estándares comunes, facilita la integración de diferentes componentes software, tanto libres como propietarios, en un
mismo entorno de producción. Además de esta independencia del fabricante, se aprecian otros beneficios sustanciales.
El hecho de emplear servicios de datos estándar permite a los servicios de visualización acceder a toda una amplia gama
de datos espaciales, con independencia de su ubicación física y de la entidad encargada de gestionarlos. Esto permite el
acceso homogéneo de las aplicaciones SIG a diferentes conjuntos de datos georeferenciados. Asimismo, independiza la
presentación de los datos de las tareas de captura, análisis, almacenamiento y mantenimiento de los datos espaciales.
Las agencias gubernamentales estadounidenses encargadas de la gestión de los recursos naturales y la defensa, pioneras
en el empleo de las herramientas SIG, promovieron el desarrollo de diversas iniciativas de software libre. Entre ellas
destacan dos proyectos: MOSS (Map Overlay and Statistical System), un SIG vectorial, y GRASS (Geographic
Resources Analysis Support System), un SIG raster que se convirtió en uno de los primeros proyectos a escala mundial
de software libre. A medida que estas y otras aplicaciones SIG se fueron introduciendo en diferentes entornos
productivos, se fue haciendo patente la necesidad de que los diferentes sistemas empleados mostraran cierto nivel de
compatibilidad y capacidad de interoperabilidad con objeto de hacer un uso más eficiente de la información geoespacial
existente. Así, del seno de la comunidad de usuarios, desarrolladores y empresas de soporte que surgieron en torno a
GRASS, con la participación de los desarrolladores de MOSS, nació el OpenGIS Project, que precedió al lanzamiento
formal del Open Geospatial Consortium, Inc. (OGC) en 1994. El OpenGIS Project definió una visión de diversos
sistemas de geoprocesamiento comunicándose directamente sobre la red gracias a un conjunto de interfaces abiertos
basados en la Open Geodata Interoperability Specification (OGIS). Actualmente, el OGC es una organización
internacional que agrupa a cerca de 300 empresas, agencias gubernamentales y universidades en un intento de
proporcionar una serie de interfaces estandarizadas y especificaciones de codificación que faciliten el acceso y la
compartición de la información geoespacial.
El OGC ha especificado varios servicios web (OWS) para el trabajo con datos espaciales. Estos servicios presentan
interfaces bien definidas que, junto con el empleo de formatos de datos estandarizados, facilitan la interoperabilidad en
entornos web distribuidos. Están agrupados en varias categorías: servicios de datos, de visualización, de transformación
y de registro, lo cual permite, entre otras cosas, dimensionar de forma adecuada el entorno operativo en función de las
necesidades, y distribuir responsabilidades y funciones entre los departamentos y organizaciones que integran una IDE.
Entre los diferentes servicios web definidos por el OGC, son de especial interés para el desarrollo del presente trabajo
los siguientes:
• El Web Map Service (WMS) (OGC-WMS, 2004) es un servicio de visualización que filtra y procesa datos
espaciales de diferentes fuentes integrándolos en una imagen 2D estática. La especificación de la interfaz del
WMS define tres operaciones: GetCapabilities, GetMap y GetFeatureInfo. De entre ellas, GetMap permite
combinar diferentes capas de datos sobre las que se aplican estilos de presentación y generar una imagen
bidimensional en algún formato gráfico estándar (figura 1a). Con objeto de mantener un completo control de la
representación visual que el WMS genera a partir de los datos espaciales, el OGC definió un lenguaje XML, el
Styled Layer Descriptor (SLD) (OGC-SLD, 2002), que permite al usuario del servicio establecer las fuentes de
datos, estilos de visualización, formatos y, en definitiva, cualquier aspecto relativo a cómo el WMS obtiene e
integra los datos para construir un mapa.
• El Web Feature Service (WFS) (OGC-WFS, 2005) es un servicio de datos que permite el acceso a objetos o
entidades geoespaciales discretas. La especificación de interfaz del WFS define un método, el GetFeature, a
través del cual se establecen las condiciones de selección o filtros de las entidades de datos. La respuesta
obtenida no es una imagen como en el caso del WMS, sino un documento que describe los objetos espaciales
mediante el Geographic Markup Language (GML) (OGC-GML, 2004). Este lenguaje XML, una contribución
más del OGC, facilita el intercambio de datos espaciales entre sistemas. Si bien en su especificación preliminar
recogía los tipos geométricos básicos (puntos, líneas, polígonos) para la representación de datos vectoriales, la
versión 3.0 actual permite la descripción tanto de entidades 2D como 3D, topologías, y otros elementos
interesantes desde el punto de vista de la visualización 3D como pueden ser las Triangulated Irregular Networks
(TINs) y datos raster 2,5D.
• El Web Coverage Service (WCS) (OGC-WCS, 2003) es un servicio de datos especializado en datos raster, que
proporciona acceso a conjuntos de información geoespacial susceptibles de ser integrados en todo tipo de
clientes, desde sistemas de simulación de modelos científicos hasta sistemas de generación de mapas. La
especificación de interfaz del WCS define una operación, GetCoverage, a través de la cual se accede a las
coberturas que gestiona, permitiendo establecer entre otros parámetros, la fuente de datos, el área de interés, el
formato de salida y la resolución de las muestras de la cobertura generada.
Una característica de las interfaces de los servicios propuestos por el OGC es la incorporación de la operación
GetCapabilities, de especial importancia en el contexto de la interoperabilidad, pues a través de ella se accede a las
capacidades particulares de cada servicio: fuentes datos accesibles, áreas geográficas cubiertas, formatos de datos y
sistemas de referencia espaciales soportados, etc.
Respecto a la generación y/o visualización de escenarios tridimensionales, los trabajos del OGC se encuentran en un
estado incipiente. Existen actualmente dos propuestas de especificación, en una fase preliminar, de sendos servicios de
visualización de escenas 3D. La primera de ellas se denominó Web Terrain Server (WTS) (OGC-WTS). Este servicio se
plantea como una extensión del WMS con la capacidad añadida de mostrar una vista estática del mapa desde cualquier
posición arbitraria en un espacio tridimensional (figura 1b). La operación GetView del WTS incluye los parámetros
necesarios para la definición de la localización y orientación de la cámara. A diferencia del WMS, donde obtenemos
una vista perpendicular sobre el mapa, el WTS nos permite establecer cualquier perspectiva de visualización de la
escena.
Con objeto generar un verdadero escenario 3D virtual que posibilite la navegación sobre el mismo, se planteó una nueva
propuesta de especificación, el Web 3D Service (W3DS) (OGC-W3DS, 2005). Si bien el W3DS en su estado actual
muestra una arquitectura y una interfaz, heredada del WTS, suficientemente elaborada y en consonancia con las
recomendaciones del OGC, presenta grandes limitaciones en la especificación de los orígenes de datos a partir de los
cuales se construye la escena virtual, pues sólo permite la selección de capas predefinidas que agrupan diferentes
elementos 3D. El usuario no puede establecer orígenes de datos arbitrarios ni definir estilos de visualización particulares
más allá de lo preconfigurado en el propio servicio.
Figura 1a: Vista de la ciudad de Bonn (WMS) Figura 1b: Vista 3D en perspectiva de Bonn (WTS)
El OGC ha definido un modelo que define el proceso de generación de un mapa desde las fuentes de datos hasta su
visualización (OGC, 2003). Este modelo describe la visualización como un proceso multinivel de cuatro etapas (figura
2). El proceso se inicia con la selección de los datos espaciales almacenados en algún repositorio. En la siguiente etapa
se aplicarán estilos de visualización sobre los datos espaciales obtenidos con objeto de generar determinadas entidades
gráficas. Posteriormente se realiza el renderizado o generación de una imagen a partir de los elementos gráficos previos
y, por último, se presentará dicha imagen en algún tipo de sistema de visualización.
Desde el punto de vista de la implementación, la definición de estas cuatro fases, permite establecer diferentes
balanceos de responsabilidades en una arquitectura cliente-servidor. Estando asociada la selección de los datos al
servidor, y la visualización al cliente, distinguiremos tres modelos de aplicación en base al reparto del resto de
funcionalidades (Figura 3). En el contexto del diseño de un servicio web de visualización 3D de información
geográfica, cada una de las propuestas de arquitectura anteriores presenta sus ventajas e inconvenientes. El cliente
ligero sólo tiene que implementar la lógica necesaria para la visualización de imágenes obtenidas desde Internet. Esta
funcionalidad la recoge cualquier navegador web actual sin necesidad de la instalación de ningún plug-in o software
complementario. Como contrapartida, debido a que las imágenes son estáticas, no es un modelo adecuado para facilitar
la navegación e interacción en un escenario 3D. Es el esquema seguido por servicios tales como el WMS y el WTS,
donde todo el proceso de generación de las imágenes recae del lado del servidor.
En el otro extremo, los clientes pesados implementan toda la lógica necesaria para la generación de los elementos
gráficos y su renderizado posterior, encargándose únicamente el servidor de proporcionar los datos espaciales
necesarios (WFS, WCS). Este es el esquema tradicional de los SIG 3D (ej. Nebiker, 2003), pues permite un control más
fino del proceso de construcción de la escena, facilitando al cliente la aplicación de complejos algoritmos para la
gestión eficiente de los elementos gráficos y la interacción con el usuario. Como contrapartida, en un entorno web,
obliga al usuario a la descarga e instalación en los navegadores de plug-ins no estandarizados que implementen dichos
esquemas. Un tercer modelo es el de los clientes medios. En él, el servidor genera los elementos gráficos que serán
enviados al cliente para su renderizado. Sigue siendo necesario un plug-in pero, a diferencia del cliente pesado, la
utilización de formatos estándar para la publicación web de escenas 3D permite la utilización de plug-ins estándar
existentes. Este es el modelo adoptado por Web 3D Service del OGC. Actualmente se dispone de diversas alternativas
estandarizadas para la publicación de contenidos 3D en la web: el Virtual Reality Modeling Language (VRML)
(VRML97, 1997), el GeoVRML (GeoVRML, 2992), que incorpora determinadas extensiones para la representación de
datos espaciales y el Extensible 3D (X3D) (X3D, 2004), que es una revisión del estándar VRML97 con objeto de
incorporar los últimos avances en cuanto a arquitecturas modulares y capacidades del hardware gráfico.
La adopción de un modelo de cliente concreto dependerá de cada escenario de aplicación particular. El balance entre
requerimientos tales como: interoperabilidad con otros servicios existentes o futuros, requisitos de navegación e
interacción del usuario, despliegue en entornos web públicos o entornos acotados, navegación en tiempo real sobre
extensos conjuntos de datos, etc... van a determinar la solución más adecuada a cada caso concreto.
El Web 3D Scene Service está concebido como un servicio web capaz de interoperar con otros servicios en un entorno
distribuido para acceder a diversa información geográfica y generar a partir de ella un escenario tridimensional
navegable (figura 4). El alto grado de interacción con el usuario requerido descarta una arquitectura basada en clientes
ligeros. Por otro lado, el modelo de cliente medio basado en la adopción de estándares extendidos para la definición de
escenas tridimensionales facilita el acceso web de los usuarios al tiempo que los plug-ins existentes proporcionan
adecuados niveles de interacción. Asimismo, el empleo de formatos de salida estándar, posibilitaría la integración de las
escenas generadas por distintos servicios remotos en un mismo escenario.
Para la construcción de las escenas 3D, el W3DSS, deberá acceder a diferentes fuentes de datos espaciales, tanto raster
(modelos digitales del terreno, fotos aéreas y de satélite,...) como vectoriales (mapas vectoriales de carreteras, ríos,
localizaciones puntuales de especial interés,... ). El escenario contemplado se basa en la interacción con servicios de
datos OGC a través de los cuales se publicaría la información geográfica. A partir de estos datos se construirán una serie
de elementos gráficos tridimensionales que se integrarán en una única escena con independencia de su origen raster o
vectorial. Para hacer posible la construcción de tales elementos gráficos, es preciso definir las opciones de
representación 3D para los datos espaciales. Teniendo en cuenta que la mayor parte de la información geográfica
disponible es 2D, se han establecido las siguientes opciones de visualización en base al tipo de dato:
• Raster. Las capas raster pueden transformarse en superficies 3D estableciendo como valor de elevación el valor
asociado a cada uno de sus puntos.
• Puntos. Los puntos no se representan como tales. Simplemente definen localizaciones en el espacio
tridimensional en las que se visualizará algún tipo de objeto 3D arbitrario definido por el usuario o la aplicación.
En caso de ser puntos 2D, es preciso disponer de una fuente de datos adicional que permita establecer un valor
de elevación (p.e., un modelo digital del terreno).
• Líneas. En el caso de las líneas existen dos opciones de representación. Una de ellas es aplicar un determinado
trazo o patrón de repetición a lo largo de la línea. Una opción diferente consiste en indicar una superficie 2D que
se extrudirá a lo largo de la línea. Como en el caso de los puntos, si la línea es 2D, la elevación se podrá obtener
de una fuente de datos adicional.
• Polígonos. La representación 3D a partir de polígonos se consigue extrudiendo el propio polígono a lo largo de
un eje arbitrario.
Operaciones soportadas
La definición de la interfaz web del servicio se ajusta a la especificación actual del Web 3D Service del OGC. Esta
especificación define dos operaciones: GetCapabilities y GetScene. En consonancia con el resto de servicios del OGC,
la implementación de dicha interfaz debe soportar la invocación de tales operaciones en un entorno de computación
distribuido basado en el estándar Hypertext Transfer Protocol (HTTP).
GetScene
A través de esta operación el cliente obtiene una escena 3D. El servidor generará dicha escena en base a los a los datos
suministrados por el cliente a través de los parámetros correspondientes. De todos los parámetros disponibles (OGC-
W3DS, 2005) los más reseñables son los siguientes:
• BBOX (Bounding Box). Permite delimitar un área geográfica que se utilizará como filtro para la selección de los
datos espaciales. Define un rectángulo bidimensional mediante la especificación de dos pares de coordenadas
(xmin, ymin, xmax, ymax) pertenecientes a algún sistema de referencia particular.
• MINHEIGHT, MAXHEIGHT. Parámetros opcionales que, junto con BBOX, permiten definir un volumen de
selección tridimensional al establecer los valores mínimo y máximo de la elevación.
• SRS (Spatial Reference System). Establece el sistema de referencia espacial en base al cual se especificarán las
coordenadas de los diferentes parámetros.
• LAYERS, STYLES. Al igual que en la especificación WMS, permite seleccionar los conjuntos de objetos 3D de
entre los disponibles y los estilos de visualización que se les aplicarán.
• POI (Point Of Interest), POC (Point Of Camera), Yaw, Pitch, Roll, Distance, AOV (Angle Of View). Esta serie
de parámetros permite establecer la localización y orientación de la cámara a través de la cual se visualiza la
escena (Figura 5).
• FORMAT. Permite seleccionar el formato de salida del servicio.
GetCapabilities
Obligatoria para todos los servicios web del OGC. Su propósito general es obtener metadatos o información operativa
del servicio: descripción de los datos espaciales disponibles, operaciones soportadas, valores válidos de parámetros de
ejecución, formatos de salida de la escena soportados,... A partir de esta información el cliente podrá construir
peticiones válidas de otras operaciones del servicio.
Una de las características más reseñables de la especificación WMS del OGC es la incorporación del Styled Layer
Descriptor (SLD). En la especificación original del WMS, el proveedor del servicio podía definir opciones de estilo
básicas para diferentes conjuntos de datos. El usuario del servicio podía seleccionar cualquiera de los estilos particulares
predefinidos para cada uno de los conjunto de datos publicados. Este modelo es el que sigue la propuesta de
especificación actual de W3DS del OGC. La posterior introducción de este lenguaje proporcionó a los clientes del
servicio un control mucho más fino de la representación gráfica de los datos. Ya no es el sólo el servicio el que
“propone” qué datos están disponibles y cómo se representan, sino que el usuario pueden establecer los orígenes o
fuentes datos, así como los estilos gráficos que se aplicarán sobre los mismos. Esta misma filosofía es la que aplicamos
en nuestro servicio de visualización 3D para datos espaciales al definir el SLD3D. Este lenguaje permite describir en un
documento XML todos y cada uno de los aspectos de la escena que debe generar el W3DSS. En dicho documento no
sólo se especifican qué datos y de dónde los tiene que obtener el servicio, sino cómo deben ser representados en la
escena. Es decir, una capa raster obtenida de un WCS podría representarse como una superficie tridimensional o bien
ser aplicada como textura sobre alguna otra superficie. Aparte del control sobre los datos espaciales, SLD3D permite la
especificación de otros parámetros de la escena como la definición de diversas cámaras con sus parámetros propios de
posicionamiento y orientación, definición de materiales, inclusión de diferentes tipos y fuentes de iluminación, etc...
Con objeto de poder acceder a estas funcionalidades, se ha incorporado en la especificación de la operación GetScene el
parámetro SLD de la operación GetView del WMS. Este parámetro se utiliza para indicarle al servicio la URL del
documento SLD3D a partir del cual se generará la escena.
SLD3D se basa en la especificación SLD de OGC. De hecho puede considerarse como una extensión del mismo. Se ha
incorporado la definición de nuevos elementos necesarios para la construcción de escenas tridimensionales, pero
manteniendo la estructura básica del esquema XML del SLD. Un documento SLD3D es básicamente una colección de
elementos UserLayer. Este elemento nos permite establecer el origen de los datos espaciales, tanto raster como
vectorial, así como los diferentes criterios de filtrado. Una vez seleccionados los datos espaciales a incorporar en la
escena, a través del elemento UserStyle se establecerán las diferentes reglas de estilo que determinarán la representación
final de la información geográfica. Para ello, SLD dispone de una serie de elementos denominados genéricamente
Symbolizers. Así, nos encontramos con los elementos PointSymbolizer, LineSymbolizer, PolygonSymbolizer,
TextSymbolizer y RasterSymbolizer que establecen la apariencia final sobre el mapa de los datos espaciales del tipo
correspondiente. En el caso de la construcción de escenas tridimensionales, es necesario añadir nuevos Symbolizers que
nos permitan definir cómo transformar los datos espaciales para obtener objetos 3D. Por ejemplo, el nuevo elemento
3DElevationGridSymbolizer se emplea para la construcción de una superficie tridimensional a partir de una fuente
raster. Los Symbolizers para visualización 3D permiten establecer los valores de los diferentes parámetros necesarios
para obtener las transformaciones de datos referidas en el punto 4.
SLD3D dispone de elementos del lenguaje que facilitan el control de ciertos aspectos relativos a la visualización de la
escena. El uso de SceneCamera permite la definición de la localización y orientación de las distintas cámaras a través
de las que se navega por la escena. AmbientLight, DirectionalLight, PointLight y SpotLight permiten establecer las
propiedades de diferentes fuentes de iluminación.
SLD3D se puede ir extendiendo en la medida en que se vayan añadiendo nuevas funcionalidades al servicio.
6. PROTOTIPO
Actualmente se encuentra en fase de desarrollo un prototipo para la evaluación del servicio. El prototipo está dividido
en dos componentes principales, la implementación del servicio W3DSS y la implementación de un cliente web. El
servicio W3DSS, en su estado actual, cubre la funcionalidad asociada a fuentes de datos raster. Procesa documentos
SLD3D para la construcción de escenas a partir de datos publicados por servicios WCS y WMS, con la inclusión de
elementos de iluminación y definición de cámaras móviles que posibiliten la navegación por el entorno virtual. Para la
visualización de dichas escenas, debido a que actualmente el servicio las exporta en un formato binario no estándar, se
ha implementado un plug-in para el navegador web Mozilla que implementa la lógica necesaria para el renderizado de
la escena y la interacción con el usuario.
A continuación se muestra un ejemplo de documento SLD3D para la creación de una escena 3D que recrea las Islas
Cíes, situadas en el Parque Natural de las Islas Atlánticas.
En dicho documento se distinguen varias partes. En la primera, se establecen los parámetros de iluminación (foco de luz
omnidireccional) y la ubicación y orientación de las diferentes cámaras. A continuación, aparecen los elementos
UserLayer que establecen los orígenes de los datos a partir de los cuales se construirán las geometrías en base a los
estilos de visualización correspondientes. En este caso, se obtendrá un mapa de elevaciones desde un servicio WCS
(figura 6a). A partir de este conjunto de datos, se solicita la construcción de una malla 3D, con una resolución de 20m
en los ejes X e Y, utilizando como dato de elevación el primer canal de la imagen obtenida del WCS. A esta superficie
se le aplica un material que determinará su apariencia final. Se establece un color y se define una textura. Como textura
se utiliza una mapa de cartas náuticas (figura 6b) que el servicio obtendrá de un WMS a través de la URL especificada.
La construcción de la geometría 3D es independiente de la textura aplicada. Con la simple modificación del elemento
ImageTexture del documento SLD3D, se podría sustituir dicha textura por una foto satélite obtenida desde un WCS
(figura 6c).
Figura 6a: capa elevaciones (WCS) Figura 6b: carta náutica (WMS) Figura 6c: fotografía satélite (WCS)
Las siguientes instantáneas (Figura 7) muestran la visualización de la escena desde el cliente web. En 7b y 7c se ha
modificado el documento SLD3D para aplicar como textura una foto satélite obtenida de un servicio WCS. En la
petición HTTP realizada por el cliente se indican la operación solicitada (GetScene) así como los valores de los
parámetros requeridos: versión del servicio (VERSION), área solicitada (BBOX), sistema de referencia espacial
utilizado (SRS) y URL del documento SLD3D (SLD). Una vez descargada la escena, el usuario puede navegar por la
misma con cualquiera de las cámaras definidas.
http://tierra.labsis.usc/cgi-bin/azor?version=0.1.0&request=GetScene&bbox=506415.41,4669964.16,509490.67,4678267.31&srs=
EPSG:23029&SLD=http://gispc12.labsis.usc.es/sld/IslasCies.xml
Figura 7a: visualización de escena W3DSS Figura 7b: texturado con foto aérea Figura 7c: detalle de la superficie grid 3D
7. TRABAJO FUTURO
El prototipo, en su estado actual, nos ha permitido hacer una primera aproximación a lo que debe ser el servicio final en
términos de interoperabilidad, visualización e interacción con el usuario. Los objetivos a corto plazo pasan por
incorporar la representación de fuentes de datos vectoriales y la adecuación de la salida del servicio a algún formato
estándar para escenas 3D (VRML, X3D). La finalización de un prototipo que abarque toda la funcionalidad prevista
permitirá una evaluación más detallada.
Por otro lado, están definidas las líneas maestras que guiarán el trabajo futuro a medio o largo plazo sobre la base del
presente proyecto. Algunos de estos objetivos son: el desarrollo de un servicio orientado a conexión y la incorporación
de técnicas de almacenamiento que posibiliten la navegación ininterrumpida sobre áreas extensas, la introducción de
caminos predefinidos para la animación tanto de cámaras como de otros elementos de la escena, establecer mecanismos
de interoperabilidad con sensores web y, finalmente, la representación de diferentes condiciones meteorológicas que,
junto con la incorporación de la coordenada temporal, permitirá construir entornos tridimensionales que reconstruyan o
simulen las condiciones pasadas o futuras de cualquier zona geográfica. Por último, el servicio debe ser evaluado en
algún entorno operativo real. Está prevista su integración como servicio de visualización en un sistema de gestión de
riesgos medioambientales aplicado a incendios forestales.
8. REFERENCIAS
1. INSPIRE proposal (2004): Proposal for a directive of the European Parliament and of the Council establishing an infraestructure
for spatial information in the Community. Ref COM(2004)0516-2004/0175(COD). Commision of the European Communities.
2. INSPIRE architecture (2002): INSPIRE Architecture and Standars Position Paper.Architecture And Standards Working Group.
Commision of the European Communities.
3. Altmaier A., Kolbe T., 2003: Applications and Solutions for Interoperable 3d Geo-Visualization. Proceedings of the
Photogrammetric Week 2003. Stuttgart, Germany.
4. Held G., Abdul-Rahman A., Zlatanova S., 2004: Web 3D GIS for Urban Environments. Proceedings of the International
Symposium and Exhibition on Geoinformation 2004. Kuala Lumpur, Malaysia.
5. Nebiker S., 2003. Support for visualisation and animation in a scalable 3D GIS environment: motivation, concepts and
implementation. ISPRS Workshop on Visualisation and Animation of Reality-based 3D Models. Engadin, Switzerland.
6. OGC-WMS, 2004. OpenGIS Web Map Service (WMS) Implementation Specification. Open Geoespatial Consortium. OGC 04-
024. Version 1.3.
7. OGC-SLD, 2002. OpenGIS Styled Layer Descriptor (SLD) Implementation Specification. Open Geoespatial Consortium. OGC
02-070. Version 1.0.
8. OGC-WFS, 2005. OpenGIS Web Feature Service (WFS) Implementation Specification. Open Geoespatial Consortium. OGC 04-
094. Version 1.1.
10. OGC-GML, 2004. OpenGIS Geographic Markup Language (GML) Encoding Specification. Open Geoespatial Consortium.
OGC 03-105r1. Version 3.1.1.
11. OGC-WCS, 2003. OpenGIS Web Coverage Service (WCS) Implementation Specification. Open Geoespatial Consortium. OGC
03-065r6. Version 1.0.
12. OGC-WTS, 2001. Web Terrain Server. Open Geospatial Consortium. Discussion paper OGC 01-061. Version 0.3.2.
13. OGC-W3DS, 2005. Web 3D Service. Open Geospatial Consortium. Discussion paper OGC 05-019. Version 0.3.0.
14. OGC, 2003. OpenGIS Reference Model. Open Geospatial Consortium. OGC 03-040. Version 0.1.2.
15. VRML97, 1997. VRML97 Functional specification. International Standard ISO/IEC 14772-1.
16. GeoVRML, 2002. GeoVRML Specification. GeoVRML Working Group. Web3D Consortium. Version 1.1.
17. X3D, 2004. Extensible 3D (X3D). Part 1: Architecture and base components. ISO/IEC 19775-1:2004. Part 2: Scene Access
Interface (SAI).
Resumen: La Comisión de Geomática del Consejo Superior Geográfico acordó que el conjunto mínimo de servicios
recomendados que una IDE debe ofrecer para formar parte de la IDEE son el Servicio de Catálogo, el Servicio de
Mapas (WMS) y el Servicio de Nomenclátor. Para la aplicabilidad del Servicio de Nomenclátor como servicio web, es
necesario disponer de un modelo de datos con un núcleo común en el que se apoyen los nomenclátores nacionales.
Con el Modelo de Nomenclátor de España (MNE) v.1.0 definido como una estructura de datos para el almacenamiento
y gestión de los nombres geográficos o topónimos, cuya primera versión se estableció en Julio del 2005, se esta
desarrollando un estudio para su aplicabilidad en otros Nomenclátores nacionales. Destacando el Nomenclátor
Geográfico Conciso de España, desarrollado por el Instituto Geográfico Nacional, con la colaboración de la Comisión
de Nombres Geográficos del Consejo Superior Geográfico, que será uno de los primeros que será incorporado en el
servicio de Nomenclátor de la IDEE.
Se pretende mostrar la compatibilidad de la mayoría de los Nomenclátores Geográficos de España existentes con el
MNE.
El Modelo de Nomenclátor de España (MNE) se define como una Estructura de Datos diseñado para soportar algunas
de las aplicaciones relacionadas con Nomenclátores: Servicios de Nomenclátores (OGC), Sistemas de Referencia
basados en Identificadores Geográficos (ISO 19112) y Nomenclátores Estandarizados según las resoluciones de la
UNESCO y guías de trabajo.
Su finalidad es el almacenamiento y gestión de los nombres geográficos y las correspondientes entidades, estableciendo
una estructura, basada en un conjunto de atributos fundamentales para caracterizar un topónimo y un conjunto de
atributos opcionales que enriquecen la descripción de un topónimo pero que no son esenciales para la implementación
del modelo.
La finalidad de esta iniciativa es llegar a consensuar un Modelo común de Nomenclátor en España que facilite el
intercambio de datos, la interpretación de la información, la descentralización de la gestión y la actualización de un
posible Nomenclátor distribuido y la implementación de búsquedas en cascada en los Nomenclátores integrados en la
IDE de España.
Referencias
El MNE ha nacido como fruto de la experiencia adquirida durante más de 10 años del Servicio de Nomenclátor y del
Gabinete de Toponimia del IGN y es compatible con los modelos más relevantes, normas, estándares e iniciativas
conocidas sobre el tema. Los siguientes modelos han sido considerados para definir la estructura del MNE que refleja
sus ideas, concepto y filosofía:
Alexandria Digital Library Gazetteer Content Standard (CGS versión 3.2) http://www.alexandria.ucsb.edu
La Norma ISO 19112: 2003 “Geographic Information- Spatial referencing by Geographic Identifiers”
Borrador de especificación del Open Geospatial Consortium “Gazetteer Service Profile of the Web Feature
Service Implementation Specification 0.0.9” http://www.opengeospatial.org
Metadata Dublín Core, (CWA 13874: 2000, ISO ) http://dublincore.org/
Nomenclátor Geográfico Conciso de España. Instituto Geográfico Nacional. 2004
Nomenclàtor Oficial de Toponimia Major de Catalunya. Generalitat de Catalunya. 2004
Toponimia de Navarra. Criterios de Normalización Lingüística y Nomenclátor de Localidades. Gobierno de
Navarra. 2000
Toponimia y Cartografía de Navarra. Gobierno de Navarra. 1995
Base de Datos de Topónimos Georreferenciados, IGN, versión 11, 2004
Cada una de las entradas que se realicen en el MNE corresponderá a una entidad geográfica, entendiendo como tal, un
fenómeno del mundo real que tiene asociada una localización ligada a la Tierra. Ejemplos de instancias de entidades
geográficas serían el río Ebro, el puerto de Málaga o Los Pirineos.
El criterio básico para determinar si dos entidades geográficas son diferentes o no, es considerar si soportan o no dos
conjuntos de atributos distintos y, en particular, el tener una localización y extensión espacial diferente es el criterio
básico para distinguir entidades.
Campos Obligatorios
A continuación se muestra el esquema del modelo MNE conteniendo solamente los campos obligatorios recomendados
para un nomenclátor en España.
3. TipoEntidad
- Tipo: Nombre del tipo del topónimo (río, cordillera, capital de municipio, ..)
- CatálogoEntidades en el que se clasifican jerárquicamente los tipos de las entidades utilizados.
4. PosicionEspacial
- Geometría: Se indica si la entidad es un punto (mínimo), una línea o una superficie.
- Coordenadas necesarias para georreferenciar la entidad.
- SistemaReferencia
5. EntidadLocal
- Provincia o provincias donde se encuentre la entidad.
6. AtributoEntidad
- ValorAtributo en el MNE y aqui llamado Población, se refiere al numero de habitantes de una
población.
Además, existen otros campos opcionales, como por ejemplo, la representación de la entidad mediante una codificación
(código INE, código postal,..), el nombre y número de la serie cartográfica de la entidad, indicar el nivel de detalle de la
entidad en comparación con otras entidades, la dirección física de la entidad si la tuviese, la relación con otras entidades
indicando el tipo de relación y con que entidad, datos relacionados con la entidad como por ejemplo el nº de habitantes,
la fecha de alta, baja o actualización de la entidad en el nomenclátor y por último un campo de observaciones.
Otras consideraciones
Por otro lado, dado que un Nomenclátor es, al fin y al cabo, un conjunto de datos geográficos, se tiene que tener en
cuenta la aplicación a los Nomenclátores de las normas ISO 19100 relativas a calidad (ISO19113 “Principios de
Calidad” e ISO19114 “Métodos de Evaluación de la Calidad”) y a la descripción de datos geográficos mediante
metadatos (ISO19115 “Metadatos”). Por lo que el MNE define también las siguientes recomendaciones:
Descripción de un Nomenclátor:
A un nomenclátor es necesario incluirle una documentación lo más exhaustiva y completa a ser posible y así poder
garantizar su correcto uso y hacer su contenido comparable con el de otros nomenclátores.
Por ejemplo, se recomienda documentar al menos un nomenclátor mencionando los siguientes aspectos: nombre del
nomenclátor, tema del que se ocupa (toponimia mayor, menor, de entidades de población, de ríos, toponimia en
general,…), territorio que abarca, institución u organismo que ha compilado los datos y que es responsable de su
mantenimiento, finalidad, escala o escalas de recopilación de los topónimos, descripción del catálogo de entidades que
utiliza, etc.
Por tanto se recomienda proporcionar metadatos del propio nomenclátor utilizando el Núcleo Español de Metadatos
(NEM) (conforme a ISO19115) para que la información básica sea recogida.
Es aconsejable describir la calidad de los datos incluidos en un nomenclátor, aunque debido a la escasez de
nomenclátores existentes, hasta ahora no se han tenido en cuenta suficientemente los aspectos relacionados con la
determinación y descripción de su calidad.
Un Nomenclátor al ser un conjunto de datos geográficos, con un conjunto de características y propiedades específicas, y
como tal conjunto de datos es objeto de aplicación de la normativa internacional relativa a la calidad de datos
geográficos.
Para más información sobre el Núcleo Español de Metadatos v.1.0 consultar la siguiente dirección:
http://www.idee.es/resources/recomendacionesCSG/Propuesta_MNE_v1.0.pdf
3
SERVICIO DE NOMENCLÁTOR
El Servicio de Nomenclátor, según el GT IDEE del Consejo Superior Geográfico, es uno de los tres mínimos servicios
(Catálogo, Mapas y Nomenclátor) que una Infraestructura de Datos Espaciales en España debe tener.
Este grupo de trabajo también recomienda como criterios de búsqueda obligatoria para un Servicio de Nomenclátor el
nombre, el tipo y la localización de la entidad.
Además de estas búsquedas se pueden añadir otros campos de selección sobre los datos almacenados en el MNE.
Actualmente el Servicio de Nomenclátor del portal de la IDEE no es estándar debido a que la especificación OGC sobre
el Servicio de Nomenclátor no esta del todo definida pero uno de los objetivos primordiales a corto plazo en el
desarrollo de la IDEE es el desarrollo de un Servicio de Nomenclátor estándar.
El Instituto Geográfico Nacional con la colaboración de la Comisión de Nombres Geográficos del Consejo Superior
Geográfico, esta desarrollando el Nomenclátor Geográfico Conciso de España que contiene la toponimia del mapa de
la Península Ibérica, Baleares y Canarias de escala 1:1 000 000 y que es corregida por las autoridades competentes en
nombres geográficos de las CCAA y de los organismos correspondientes del Estado.
A continuación se muestra un gráfico del modelo de datos del MNE completo (campos obligatorios y campos
opcionales) para almacenar un nomenclátor en una Base de Datos:
T_Municipio
PK Codigo
T_Idioma
Municipio T_Atributo T_NombreEntidad
PK Idioma
T_EATIM PK TipoAtributo PK Nombre
PK ValorAtributo PK,FK2 Idioma TipoIdioma
PK IdEATIM PK,FK1 IdEntidad PK,FK1 IdEntidad
T_EntidadLocal
TipoEATIM UnidadAtributo Etimología
PK IdEntidadLocal
NombreEATIM CalidadAtributo Pronunciacion
T_Entidad_EntidadLocal T_ClaseNombre
FK1 Provincia NotaAtributo FK3 ClaseNombre
FK2 Municipio PK,FK2 IdEntidad FechaAtributo Oficial PK ClaseNombre
Isla PK,FK1 IdEntidadLocal Normalizado
T_Provincia Comarca Identifier
PK Codigo FK3 EATIM
Nombre
T_Codigo
PK Codigo T_Entidad
PK,FK1 IdEntidad T_Entidad_TipoEntidad T_TipoEntidad
PK IdEntidad
SistemaCodificacion PK,FK1 IdEntidad PK IdTipoEntidad
Nivel
PK,FK2 IdTipoEntidad
Observaciones Tipo
NombreDireccion CatalogoEntidades
T_Entidad_Mapa Localidad
T_Mapa CodigoPostal
PK,FK2 IdEntidad
PK Serie PK,FK1 Serie
PK Hoja PK,FK1 Hoja
La toponimia resultante del Nomenclátor Conciso está incorporada en una base datos de trabajo, en formato ACCESS,
conteniendo unos 3 600 topónimos en una sola tabla y su aplicabilidad al MNE ha necesitado convertir el fichero
original en 8 tablas. La siguiente figura se corresponde al modelo de datos del MNE ajustado a las necesidades del
Nomenclátor Conciso, en cual, como se puede observar ha sufrido una gran simplificación del modelo original:
CONCLUSIONES
El propósito del desarrollo del MNE junto con el desarrollo de un Servicio de Nomenclátor es facilitar el intercambio de
datos, la interpretación de la información, la descentralización de la gestión y la actualización de un posible
Nomenclátor distribuido y la implementación de búsquedas en cascada en los Nomenclátores integrados en la IDE de
España.
Para realizar esta propuesta ha sido necesario su análisis y modificación por los diferentes responsables de los
nomenclátores y para cumplir sus objetivos será necesario su adaptación y adopción definitiva para los diferentes
instituciones productoras de nomenclátores a todos los niveles de la administración. Esto permitirá a los ciudadanos
disponer de una estructura única de información toponímica integrada desde diferentes productores de forma
coordinada y transparente. Obviamente, sin perder la diversidad de los datos almacenados y los procedimientos y
metodologías que cualquier institución puede considerar apropiada al desarrollar los nomenclátores.
Por tanto, aspectos como la diversidad territorial, adaptabilidad cultural y lingüística, tesauros temáticos y el
multilingüismo han sido considerados como prioritarios y objetivos fundamentales a la hora de definir el MNE.
El Nomenclátor Conciso ha sido el primer Nomenclátor que se ha adaptado al modelo del MNE y partiendo que no es
un Nomenclátor complicado y que consta de unos 3600 topónimos aproximadamente, la experiencia de adaptar el
Nomenclátor Conciso al MNE no ha supuesto un gran esfuerzo y las ventajas que se obtienen de su aplicabilidad son
numerosas.
REFERENCIAS
173
Sistema para la Gestión y Divulgación de Información Cartográca del... Sesión 6
Resumen: Se presenta el proyecto que en estos momentos el Instituto Cartográfico Valenciano (ICV) está
desarrollando, cuya principal finalidad es la creación de un nuevo geoportal que permita el acceso a la información
geográfica disponible en la Comunidad Valenciana. Permitirá la visualización, navegación, la realización de
búsquedas a través consultas y la adquisición de cualquier producto cartográfico, considerando para todo ello las
nuevas tecnologías en las que se basan las Infraestructuras de Datos Espaciales.
INTRODUCCIÓN
El Instituto Cartográfico Valenciano (ICV) es una entidad de derecho público, adscrita a la Conselleria de Justicia,
Interior y Administraciones Públicas, cuyo objetivo prioritario es el impulso, coordinación y fomento de las tareas de
desarrollo cartográfico, fotogramétrico, geodésico, topográfico y de cualquier otra tecnología geográfica en el ámbito de
las competencias de la Generalitat Valenciana. (Ley 9/1997, de 9 de diciembre, de la Generalitat Valenciana).
En aras de ofrecer unos mejores servicios y de cumplir los objetivos para los que fue creado, el ICV se plantea el
desarrollo de un nuevo sistema que facilite el acceso a la información del territorio de la Comunidad Valenciana. Este
proceso se inicia desde el ICV, ya que es el principal organismo productor de cartografía oficial a nivel autonómico, por
lo que resulta una prioridad el reto planteado.
En el seno de la Sociedad de la Información en la que nos hayamos inmersos resulta obvia la influencia que Internet
supone en la divulgación de todo tipo de información. Entendiendo que la información cartográfica no es sino un tipo
particular de información, cuyo valor esencial es que se encuentra ligada a un territorio y que éste ha de ser conocido
por cualquier ciudadano, parece suficientemente justificado que será Internet el medio de divulgación elegido.
Se aborda el desarrollo de un nuevo portal web que permita acercar el territorio al ciudadano mediante el acceso a la
información geográfica. Para ello, la fórmula elegida será a través de servidores de cartografía para mostrar la
Comunidad Valenciana y permitiendo la realización de búsquedas de información, cartográfica en este caso,
atendiendo a criterios que pueden ser tanto espaciales como alfanuméricos.
Las posibilidades que existen para desarrollar el proyecto son básicamente dos, una dirigida a la aplicación de una
solución propia, basada en una tecnología cualquiera y otra línea de trabajo, mucho más acertada, que es la que
considera las nuevas tecnologías en las que se basan las Infraestructura de Datos Espaciales, contribuyendo a la
creación de la misma en nuestro ámbito territorial.
OBJETIVOS
Todo este proyecto implica unas mejoras en dos ámbitos diferentes. En el ámbito interno del Instituto, supondrá una
optimización de los recursos existentes para lo que habrá que trabajar intensamente para mejorar el flujo de trabajo
entre la Unidad Técnica de Producción y la Unidad de Distribución o Cartoteca. En el ámbito que supone las relaciones
del Instituto con el mundo exterior, supondrá una ayuda a la divulgación a toda la información disponible en el mismo.
COMPONENTES
El elemento fundamental, base del sistema, estará integrado por las distintas bases de información geoespacial, que en
constante evolución, se realizan en el Instituto Cartográfico Valenciano.
Los núcleos que serán definidos en este proyecto serán básicamente tres. En primer lugar, un Servidor de Cartografía
que permita la visualización, navegación y otras operaciones que posterior se tratarán con mayor detalle.
Será desarrollado según las especificaciones de interoperabilidad del Open Geospatial Consortium (OGC) y permitirá
el acceso a otros servidores que contemplen estas especificaciones con carácter bidireccional. En segundo lugar, un
Catálogo de Metadatos que permitirá el acceso a la geoinformación catalogada según los estándares establecidos. Y por
último, un Módulo Comercial que facilitará la adquisición de cualquier producto mediante distintas opciones. Aunque
se trata de módulos definidos, no son independientes sino que estarán directamente relacionados y vinculados entre sí,
permitiendo el acceso de uno a otro.
CATALOGACIÓN DE LA INFORMACIÓN
El primer paso para afrontar este proyecto será el análisis de la información disponible, presentándose algunos
problemas de multiplicidad, fundamentalmente entre las unidades de producción y distribución, de diversidad en cuanto
a estructuración, uso y aprovechamiento, ya que por ejemplo información generada para una determinada aplicación no
era reutilizada para otras posibles finalidades distintas a la original. A ello se le suma el volumen creciente de
información que en periodos de tiempo relativamente cortos supone la producción cartográfica.
Estos inconvenientes son fácilmente superables planteando la necesidad de la unificación de la información en un único
almacén de datos centralizado y de acceso general, en el que se ha definido una estructuración que permita la inclusión
continua de nueva información. Otro punto clave pasa por establecer una estandarización en la nomenclatura de los
ficheros y, por supuesto, todo ello ayudado con una catalogación de la información almacenada.
En los últimos tiempos se ha implantando con energía el concepto de “metadato”, como si fuera un concepto de reciente
creación, pero esto no es totalmente cierto, ya que si nos centramos en el concepto independientemente de su
materialización, un metadato hace referencia a información acerca de una determinada información. Y precisamente en
el mundo en el que habitamos, si por algo se caracteriza, es porque nos encontramos en la denominada Sociedad de la
Información, donde los metadatos nos rodean constantemente, por ejemplo, cuando vemos un cartel de cine o el trailer
de una película, inmediatamente nos da una idea acerca del contenido de esa película en cuestión: tema tratado, director,
productor, protagonistas, año de producción, algunas escenas, etc. En el campo de la información geoespacial, cualquier
proyecto fotogramétrico o cartográfico lleva asociada mucha información, no sólo los productos cartográficos obtenidos
como resultado definitivo, sino pliegos de prescripciones técnicas, metodologías de trabajo, productos en cada una de
las fases intermedias, y todo ello condiciona sustancialmente el producto definitivo y forma parte del mismo.
Los metadatos de la información geográfica han de ofrecer información acerca del contenido, estructuración, finalidad,
origen de los datos, proceso de creación, calidad y demás características que lo definen y lo distinguen. Han de
responder a preguntas como ¿qué es?, ¿cuál es su contenido?, ¿por qué fue creado?, ¿dónde está?, ¿cuándo fue creado,
editado o publicado? ¿quién ha creado los datos?, ¿quién los mantiene? o ¿quién los distribuye?, ¿cómo se han
obtenido?, ¿qué calidad tienen?,...
En definitiva, los metadatos pueden ser los parámetros necesarios para realizar un proceso de catalogación adecuado. Es
un proceso fundamental, aunque tedioso, para el conocimiento de la información, la rápida localización y para su
compresión, que suponen unas ventajas incondicionales, tanto para el usuario como para el organismo productor de
información.
La forma práctica de materializar los metadatos es atender a los estándares definidos. En primera instancia, la
catalogación se plantea analizando el modelo de datos desarrollado por la ISO 19115, relativa a metadatos de la
Información Geográfica. Esta norma se caracteriza por su extensión, complejidad e inconcreción, como es lógico por
otro lado, ya que ha de poderse catalogar cualquier tipo de información ligada al territorio.
No obstante, la concepción es clara, acerca de algunos de los ámbitos que hemos de tratar:
En primer lugar información que permita la identificación del recurso geográfico, aportando una cita para referenciarlo
y una descripción que incluya un resumen descriptivo del contenido, clasificación temática, propósito que describa la
finalidad de los datos, estado en el que se encuentran, otro dato fundamental será establecer la fecha de creación,
edición, publicación de los datos,...
Dado que en todo momento se trata información geoespacial, será necesario para su localización incluir información
fidedigna, acerca de su ubicación o extensión espacial, siendo de vital importancia el sistema de referencia en el que se
encuentra la información original.
Otro ámbito a definir será la información acerca de la calidad, estableciendo el linaje o procedencia de los datos, los
pasos que se han establecido en el proceso de producción, así como, descripciones o indicadores de los controles de
calidad efectuados, ya sean ligados a la exactitud posicional, temática, compleción o consistencia lógica.
Además se habrá de incluir información acerca del proceso de distribución, lugar o lugares de distribución, forma,
opciones de transferencia, instrucciones para la petición, ofreciendo información acerca de las restricciones de uso,
legales y de seguridad.
En cada uno de estos ámbitos se indicará la entidad responsable de su realización, responsable de la creación de los
datos, de su distribución, mantenimiento, control de calidad,..
Asimismo, se establece un bloque de información relativa a los propios metadatos acerca de su estructuración, estándar,
versión, fecha,…
Conjuntos de Datos.
La primera labor será establecer, en función de la información generada en el ICV y atendiendo a esta norma, cuál será
la estructuración y la metodología más adecuada para la generación de metadatos.
En lo relativo a la estructuración parece lógico preguntarse qué unidad de catalogación se elegirá, si será necesaria la
definición de conjuntos de datos, series y en definitiva, qué jerarquía vamos a utilizar.
La ISO19115 plantea la posibilidad de asignar metadatos a varios niveles de detalle, estableciendo diferentes niveles de
jerarquía. De este modo, parece razonable agrupar la información en base a característica técnicas comunes para realizar
una asociación directa de las propiedades intrínsecas del producto. Tendremos que considerar la materialización de una
estructura adecuada, con vistas además a la posterior explotación y comprensión de esos metadatos, una vez efectuada
una determinada consulta sobre los mismos. Por este motivo vamos a profundizar un poco en el análisis de estas
características comunes que nos permitirán la definición de unos conjuntos homogéneos de información.
En el campo de actuación del ICV, las áreas definidas desde un punto de vista de productos cartográficos
fundamentalmente son:
• cartografía topográfica
• cartografía temática
• ortofotos
• ortoimágenes de satélite
• modelos digitales del terreno
• vuelos fotogramétricos
• imágenes de satélite,...
Dentro de cada una de estas áreas pueden existir series o conjuntos de datos de características más homogéneas. Así por
ejemplo, en cartografía topográfica podríamos encontrar las siguientes series 1:5.000 (CV05), 1:10.000 (CV10),
1:300.000 (CV300), en ortofoto la serie 1:5.000 (ODCV05) o la serie 1:25.000 (MOCV25) y así sucesivamente.
Conocida una determinada serie, que espacialmente cubre el territorio, podríamos descender en el siguiente nivel de
detalle al de hoja cartográfica, pero resulta que un factor a tener en consideración es que, normalmente la elaboración de
una determinada serie cartográfica se efectúa en diferentes fases. No se cubre todo el territorio en una única campaña,
sino que es proyecto que se dilata en el tiempo. Es por ello que, contrario a lo que en muchas ocasiones se piensa, la
discontinuidad de una serie cartográfica no se debe a que se trabaje en hojas cartográficas, sino a la imposibilidad
material que supone la confección, a determinadas escalas, de obtener una cobertura continua del territorio en una
misma fecha. Obviamente, un organismo cartográfico utiliza como unidad, en la delimitación de las zonas a realizar en
cada proyecto, las denominadas cuadrículas geográficas, pero esta metodología no es sino una forma de organización
estandarizada. Por todo ello, queda de manifiesto que las discontinuidades en una serie cartográficas vienen definidas
por un factor temporal, más que por el factor espacial al que se haya ligado.
Si se visualiza, por ejemplo, la serie de Ortofoto Digital de la Comunidad Valenciana (ODCV05) (Figura 1) se puede
ver claramente la situación planteada.
Otro factor a tener en consideración sería el sistema de referencia utilizado. Actualmente nos encontramos inmersos en
un momento en el que se ha planteado la migración del sistema ED50 a un sistema de referencia europeo denominado
ETRS89, de hecho los nuevos proyectos cartográficos ya se han iniciado en este nuevo sistema. Mientras, los antiguos
es necesario migralos a este nuevo sistema. Llegará un momento en el sólo se utilice el nuevo sistema, pero en este
período de transición parece lógico ofrecer los productos en ambos sistemas. Por tanto, el sistema de referencia también
será uno de los parámetros seleccionados para definir un conjunto de datos homogéneo.
Manifiestas estas puntualizaciones, la generación automatizada de metadatos pasará por diseñar una herramienta que
permita definir las siguientes operaciones:
De esta forma se generarán, sin demasiado esfuerzo, conjuntos de datos con características homogéneas. Tarea que será
necesario incorporar en el flujo de trabajo convencional que conlleva todo proyecto cartográfico.
Posteriormente se tratará con mayor detalle el tema del servidor de cartografía, pero en este momento de la exposición
se hace necesario plantear una nueva situación que afecta a la catalogación de los datos y que está relacionada con la
implantación de servidores de cartografía.
Con anterioridad, se ponía de manifiesto el hecho de la discontinuidad que el factor “tiempo” supone en la generación
cartográfica. No obstante, es factible la necesidad, que plantea un usuario cualquiera, de acercarse a la totalidad del
territorio, mediante una continuidad palpable. Por ello, parece lógico ofrecer una cobertura de información continua
actualizada de toda la Comunidad. De esto modo, siempre se podrá disponer la información más actual de cada
localización espacial, que por otro lado, obviamente, es la más demandada. No obstante, se encontrará vinculada con la
información aportada por los conjuntos de metadatos establecidos por fechas, tal y como se mencionaba en el apartado
anterior.
En cartografía topográfica se procederá de igual forma, pero se definirán tantas capas como sean necesarias, en función
de la escala tratada. No obstante, para mayor claridad, se agruparán por temáticas, por ejemplo las más características
serían:
• Comunicaciones
• Hidrografía
• Orografía
• Edificaciones/Poblaciones
• Límites Administrativos
• Redes Geodésicas
• Cuadrículas Geográficas
• …
ESTRUCTURA
Este proyecto se está desarrollando utilizando librerías, componentes y lenguajes de programación basados en software
libre.
El modelo de datos para almacenar los productos cartográficos vectoriales del ICV, así como el catálogo de productos y
metadatos asociados al mismo, se implementa sobre el gestor de base de datos PostgreSQL que incorpora el módulo
espacial PostGIS que permite almacenar y gestionar geometría en la base de datos. PostgreSQL
(http://www.postgresql.org) es un Sistema de Gestión de Base de Datos Relacional (SGBDR) de licencia GNU.
Para la elaboración de los mapas en tiempo real y los servicios de mapping interactivo se utiliza el servidor de mapas
MapServer (http://mapserver.gis.umn.edu/), que es compatible con los estándares OGC (WMS, WFS no transaccional,
WCS, GML). Inicialmente soportará el protocolo WMS y en futuro próximo se implementarán más servicios.
El servidor de aplicaciones web utilizado es Apache y la tecnología JAVA para el desarrollo de las funcionalidades. el
sistema operativo GNU/Linux.
El diseño gráfico se ajusta a lo establecido en las normas generales de integración de webs publicadas por la Generalitat
Valenciana.
SERVIDOR DE CARTOGRAFÍA
El visor cartográfico muestra la información cartográfica, vectorial o raster, en forma de capas continuas que se
distribuyen en un árbol de capas convenientemente agrupadas por temáticas. Una forma de navegar por la información
espacial será configurar el servidor para que, sin necesidad de la intervención del usuario, el servidor permita una
visualización de unas determinadas capas que sea coherentes con la escala de visualización. No se ha de olvidar que en
todo momento, se está trabajando con información cartográfica, lo que supone que ha sido confeccionada con unos
requisitos técnicos, definidos en función de las precisiones que caracterizan al producto final. Y si bien, parece que la
escala cartográfica es un parámetro ligado únicamente al soporte papel y se pierde cuando se transforma a soporte
digital, esto no es cierto, siempre existirá una relación de dependencia . Sí es verdad, que digitalmente se puede
modificar la escala, pero no hemos de olvidar que ésta hace referencia a la visualización y que aunque una determinada
cartografía permita rangos de visualización variables, éstos no son ilimitados. Por este motivo, inicialmente se
establecerán unos rangos adecuados para la visualización cartográfica, sin perjuicio de que el usuario pueda activar
otras capas si lo considerase oportuno. En todo momento, en la parte inferior del mapa se podrá visualizar la escala,
coordenadas y el sistema de referencia coordenado.
Se dispondrá de la cartografía más actualizada de carácter ráster y vectorial. Además, se podrán visualizar capas de
imagen con un carácter histórico. Para facilitar la observación de cambios en el territorio se ha incorporado una
herramienta que permite la modificación de la transparencia entre capas, que también será útil para visualizar el modelo
digital del terreno, ya que aportará la sensación de relieve.
Los avances tecnológicos están posibilitando que el mundo de la cartografía sea una realidad al servicio de cualquiera.
No obstante, en el diseño del interfaz se ha de considerar que el destinatario final no tiene porqué estar familiarizado
con las técnicas y herramientas cartográficas. Por esta razón, se han de desarrollar herramientas que permitan la
aproximación al territorio, de una forma ágil y sencilla.
Las herramientas básicas para la navegación son: zoom de aproximación a través de ventana, zoom para alejarse, zoom
a la extensión del mapa, botón de desplazamiento,..; otro grupo de herramientas sencillas es el de información de un
elemento, se abrirá una ventana flotante con la información asociada, por ejemplo en el caso de que se seleccione un
vértice geodésico se abre la reseña del vértice seleccionado, en formato pdf, de manera que el usuario se puede
descargar este fichero. Otra sencilla operación será medir una superficie o medir una distancia entre dos puntos, el
resultado de la realización de estas mediciones se mostrará en la zona de información situada en la parte inferior.
Para facilitar la localización espacial rápida, la búsqueda según un nomenclátor puede ser fundamental. Inicialmente se
han incorporado unas búsquedas sencillas, que permitirán la localización de cualquier municipio o población en
castellano y valenciano, para ayudar se desplegará un listado de posibilidades. Otra posible localización es
introduciendo directamente las coordenadas UTM.
A partir del servidor de cartografía se podrán seleccionar espacialmente el área de interés, para extraer los productos
físicos directamente. Las herramientas de recorte de la cartografía se muestran en la siguiente paleta, el usuario debe
seleccionar la zona que quiere recortar. Esta selección se puede realizar mediante un rectángulo o mediante un polígono
cualquiera, el siguiente botón permitirá limpiar la selección realizada.
Después de seleccionar la zona a recortar, se presionará el último botón que realizará la operación de recorte que
mostrará una ventana con el listado de capas de información a recortar, para confirmar la petición, solicitará el formato
de salida y confirmará el sistema de referencia coordenado. El producto se añadirá al carrito de la compra.
Si la zona de interés fuera muy extensa se puede realizar una selección por hojas cartográficas, únicamente habrá que
definir la serie y se activará la cuadrícula geográfica oportuna.
Se podrá imprimir la zona visualizada de forma directa, la aplicación generará una maquetación automática en función
de las opciones de impresión definidas.
La adquisición de cualquier producto, a través de las distintas opciones disponibles, incorporará una información
asociada procedente de los metadatos.
Dado que el servidor está desarrollado según las especificaciones del Open Geospatial Consortium (OGC), se incorpora
una herramienta que permita añadir Servidores Externos, pudiendo de este modo, incorporar nuevas capas que
provengan de servidores de mapas WMS externos. Se configurará para facilitar el acceso a otros servidores de la
Comunidad Valenciana, de la IDE nacional o de otras comuninades limítrofes. Del mismo modo, este servidor será
accesible desde servidores externos. Se deberá establecer una estructura adecuada en cuanto a servidores y capas de
información disponibles tanto a nivel nacional, regional o local.
CATÁLOGO DE METADATOS
El catálogo de metadatos permite localizar la información geográfica a través de un interfaz donde se combinan las
búsquedas espaciales y alfanuméricas no excluyentes entre sí. Los interfaces estándares más extendidos se distribuyen
atendiendo a las preguntas clave: ¿qué?,¿dónde?,¿cuándo?,¿quién? y accediendo directamente a campos establecidos
según la ISO19115 con las listas de valores incluidos en la misma, como pueden ser: categoría, palabras clave, etc.
Para facilitar la interpretación de los parámetros de búsqueda se plantea un diseño de interfaz que, si bien, responderá a
las preguntas clave intentará facilitar la tarea de búsqueda a un usuario no familiarizado, a través de listas desplegables
donde se visualicen los posibles valores en función de la información disponible, que posteriomente el sistema
interpretará en función de los estándares establecidos.
Una zona del interfaz hará referencia a la Localización espacial (¿dónde?), presentará un mapa guía sobre el que se
pueda navegar con las típicas herramientas de visualización. Además, se podrá localizar una zona estableciendo una
posición geográfica por coordenadas o a través de un nomenclátor.
Otra área permitirá la localización del producto (¿qué?), agrupará el tipo de producto, escala cartográfica, hoja según el
identificador geográfico y la temática buscada.
El tipo de producto apuntará a las grandes áreas previamente definidas: cartografía topográfica, cartografía temática,
ortofotos, ortoimágenes de satélite, modelos digitales del terreno, vuelos fotogramétricos, imágenes de satélite,.. y la
temática a las capas de información de la cartografía topográfica: comunicaciones, hidrografía, orografía, edificaciones,
límites,... Se podrá introducir como parámetro, la fecha de la creación de los datos geoespaciales. Un posible diseño
sería el que se muestra en la siguiente figura.
En principio, se incorporan todos los productos del Instituto Cartográfico Valenciano y se plantea la posibilidad de que
otros organismos de la Comunidad incorporen los suyos, por lo que se incluirá una pestaña con el nombre del
organismo.
Los resultados de la búsqueda ofrecerán un listado con aquellos productos que cumplan los requisitos previamente
determinados. La presentación de resultados se realizará de forma ordenada de acuerdo a los niveles jerárquicos
establecidos. Se permitirá el acceso a la información incorporada en los metadatos de forma resumida o extendida y se
podrá visualizar el producto en el servidor de cartografía y si no es posible, de forma independiente. Si no es un
producto de descarga gratuita se podrá incorporar al carrito de la compra.
MÓDULO COMERCIAL
Este portal incorpora un modulo comercial que permitirá la compra por Internet de los productos seleccionados. Cada
operación realizada sobre los anteriores módulos generará una serie de archivos con la información física seleccionada
que se van añadiendo al carrito de la compra.
Tras introducir los datos de identificación necesarios, el usuario indicará la forma de pago y el modo de envío de la
información. Las distintas opciones se muestran en la figura 6.
El personal de Cartoteca tendrá privilegios y diferentes opciones que faciliten su labor, por ejemplo podrá acceder a un
gestor de pedidos que facilite las tramitaciones pertinentes.
OTRAS UTILIDADES
En el geoportal se integrará la información existente en estos momentos en la web http://www.icv.gva.es/, acerca del
ICV como organismo, normativa, incluyendo una sección de novedades sobre proyectos, concursos,..; catálogo de
productos; zona de descarga;.. Un punto de acceso que permite la realización de un vuelo virtual sobre la Comunidad
Valenciana. Otra zona dedicada a la red de estaciones de referencia, Red Erva. Además se habilitará un punto de acceso
exclusivo para facilitar la localización de vuelos fotogramétricos a partir de selecciones espaciales.
El proyecto planteado se caracteriza por su escalabilidad por lo que pretende crecer en un periodo relativamente corto
de tiempo, integrando nuevos servidores: WFS, WCS y nuevas funcionalidades.
Resumen: La puesta en marcha de la Infraestructura de Datos Espaciales de Galicia es una iniciativa encuadrada
dentro del Programa I+D de la Xunta de Galicia, “Aplicación de las Tecnologías de la Información y Comunicación a
la Cartografía de Galicia”, con la que se pone a disposición de los usuarios de Internet la cartografía almacenada en
la Xunta de Galicia. Su nodo de acceso SITGA-IDEG está basado en los estándares internacionales en lo referente a
Infraestructura de Datos Espaciales, cuenta con los servicios básicos OGC, así como otras funcionalidades entre las
que se incluyen la elaboración de mapas temáticos, medición de superficies, perímetros y longitudes sobre los mapas,
consulta de datos socioeconómicos e impresión de mapas o imágenes.
Este nodo de acceso, operativo desde el pasado mes de abril, utiliza SVG para la presentación de gráficos y está
disponible en la dirección http://sitga.xunta.es
Galicia es un territorio con una geografía que define un paisaje singular con una organización territorial propia y una
distribución espacial de su población que obedecen a un proceso histórico único.
A lo largo del tiempo la representación cartográfica de Galicia, ha adolecido de graves carencias por una falta de
actualización adecuada y por la ausencia de escalas útiles para cualquier trabajo de actuación sobre el territorio gallego.
En nuestra Comunidad Autónoma siguen existiendo importantes deficiencias en la documentación cartográfica
disponible por las distintas instituciones y organismo públicos, ante la reducida información sobre la localización de
recursos humanos y materiales existentes en el territorio. Esto limita y dificulta la utilización de la cartografía, y obliga
a que algunos organismos generen su propia cartografía ocasionando, muchas veces, la duplicidad de esfuerzos, el
elevado coste de los productos cartográficos y la escasa rentabilidad e infrautilización de los mismos.
También ha experimentado un considerable aumento la demanda privada de información cartográfica, pues las
actuaciones sobre el territorio día a día tienen mayor relevancia y afectan de manera muy directa a la población.
Actualmente la información cartográfica es fundamental para el desarrollo de una buena gestión y utilización de los
recursos disponibles.
En Galicia se dieron pasos significativos como la creación del SITGA y la formación de una Comisión de Coordinación
de Sistemas de Información Geográfica y Cartografía de la Xunta de Galicia que nos conducirá a la búsqueda de
soluciones mediante la elaboración de un Plan Gallego de Cartografía que permita soportar una producción cartográfica
planificada racionalmente.
PROYECTO I+D
Para solventar los problemas de acceso a la información, el SITGA en el año 2002 solicitó un proyecto de Investigación
y Desarrollo Tecnológico para poner las bases de lo que podría ser la futura Infraestructura de Datos Espaciales de
Galicia (IDEG).
El Proyecto “Aplicación de las TIC a la cartografía de Galicia” fue presentado como un proyecto de I+D+IT por la
Sociedade Anónima para o Desenvolvemento Comarcal de Galicia, a la que pertenece el SITGA, en el marco de la
convocatoria de ayudas correspondientes al Programa de Ciencias Sociales (Programa de la Sociedad de la
Información), convocadas en el Anexo II de la Orden del 29 de abril de 2002 (DOG de 13 de mayo de 2002). Por
resolución de la entonces Consellería de Presidencia, Relacións Institucionais e Administración Pública del 27 de
septiembre de 2002 (DOG del 7 de octubre de 2002), a esta empresa le fue concedida una subvención total de
307.292,00 € distribuidos en cuatro anualidades.
Con este proyecto se pretendía poner las bases para el desarrollo de todos los componentes tecnológicos de la IDEG. El
aspecto fundamental de la coordinación y la política de datos, se dejaba a la anteriormente citada Comisión de
Coordinación de Sistemas de Información Geográfica y Cartografía, que es la encargada de poner en marcha la IDEG.
Por tanto, en este proyecto hemos trabajado en los siguientes apartados:
• Datos: adquisición, inventariación y adecuación de formatos
• Metadatos: catalogación y metodología.
• Tecnología: preparación y puesta en marcha del geoportal.
• Estándares: información y aplicación..
• Servicios: dentro del geoportal se han creado los servicios mínimos recomendados y alguno más de interés
para el SITGA.
• Divulgación: se ha realizado el proceso de difusión de los trabajos y la necesidad de contar con las IDE’s.
EL GEOPORTAL SITGA-IDEG
Una de las iniciativas más destacables dentro de este proyecto, consistió en poner en marcha un punto de acceso
principal a la cartografía existente en el SITGA a través de Internet.
Funcionalidades:
Arquitectura de SITGA-IDEG:
Actualmente se están utilizando dos servidores a modo de almacenes, uno de ellos de base de datos y el otro de
imágenes, ambos se enlazan a través de un Switch Catalyst 4506 con tres servidores Web en balanceo de carga
(Radware Balancing Web Server). La salida a Internet se realiza a través de un Router Xpedition XP2400.
Para publicar los datos se ha utilizado Geomedia Webmap Professional/Web Publisher de Intergraph. Estos datos son
almacenados en Oracle 9i y en SmartStore, mientras que las imágenes se gestionan con TerraShare. Los metadatos se
almacenan en Oracle y son gestionados a través de SMMS de Intergraph.
Descripción de contenidos:
Cartografía básica
Muestra la cartografía básica de Galicia con información sobre límites administrativos, vías de comunicación,
ferrocarril, hidrografía, población, toponimia, vegetación, líneas eléctricas, relieve y edificaciones, dependiendo del
zoom de visualización muestra información de diferentes escalas, entre 1:1.000.000 hasta 1:5.000 , proveniente de
diversas fuentes y bases cartográficas.
En ciertas capas aparecen etiquetas interactivas con informaciones de la base de datos, es el caso de las matrículas de las
carreteras, nombres de concello, etc., también es posible obtener información de determinados elementos al
seleccionarlos. Dentro de este apartado se dispone de herramientas de visualización, búsqueda de elementos, activación
de capas de información y medida de elementos sobre la cartografía básica de Galicia.
Temáticos predefinidos
En este apartado se muestra cartografía temática en la que, para facilitar su visualización, se han seleccionado
previamente sus capas y sus simbologías para que aparezcan por defecto. Entre los mapas mostrados destacan el mapa
de usos de suelo (1:25.000), Litológico e hidrogeológico (derivados de la cartografía geológica 1:50.000), hidrográfico
(1:25.000), administrativo (1:25.000), comunicaciones (1:25.000) y el correspondiente a los caminos de Santiago
(1:100.000).
Permite la realización de mapas temáticos de coropletas según diversas variables socioeconómicas relacionadas con los
límites territoriales, provincias, comarcas, municipios y parroquias. El proceso de confección del mapa permite
seleccionar el número, rango y simbología de los intervalos.
Almacén de mapas
En este apartado se han incluido las 4070 hojas de la cartografía básica de Galicia 1:5.000 en formato pdf. Se ha
seleccionado este formato por su amplia distribución, accesibilidad y bajo coste así como la posibilidad de trabajar con
niveles y realizar búsquedas de topónimos.
El acceso a las hojas se realiza haciendo clic en el marco de la hoja correspondiente, éste marco aparece una vez
alcanzada su escala de visualización.
Almacén de imágenes
Permite la visualización de vuelos fotogramétricos, ortofotos y imágenes de satélite de un lugar determinado. Para ello
basta con hacer clic en un lugar del mapa para visualizar su listado de imágenes accesibles, una serie de herramientas
básicas permiten la visualización de la imagen en una ventana emergente.
Servicios de interoperabilidad propios de una infraestructura de datos espaciales. Todos ellos están basados en los
estándares internacionales en la materia.
Catálogo
Muestra información sobre las entidades incluidas en la cartografía, así como datos sobre fechas de captura,
calidad, tipo de dato, etc. Permite realizar consultas mediante la utilización de palabras clave, extensión
geográfica y fecha.
Servicio de Nomenclátor
Permite la localización geográfica de cualquier entidad incluida en el Nomenclátor de Galicia. Una vez
seleccionado la entidad que se pretende localizar, comarca, municipio, parroquia o entidad singular se muestra
una ventana de mapa centrada sobre la posición que ocupa dicha entidad en el territorio. También se accede a
la toponimia de los elementos que definen la orografía de Galicia.
WMS
Expone la dirección del servidor WMS del la IDEG y las instrucciones para el acceso a él. También desarrolla
todo lo relativo a este servicio. http://sitga.xunta.es/w msgalicia/request.asp
WFS
Se detalla el acceso a las entidades gráficas que proporciona el servicio WFS. Permite añadir desde cualquier
aplicación GIS, con el componente Data Server correspondiente, la información que proviene de nuestro
servidor y tratarla como una conexión más. http://sitga.xunta.es/w fsgalicia/request.asp
Cartografía publicada
Utilidades
Libro de visitas
Espacio reservado para realizar comentarios sobre el servidor y sus funcionalidades.
Sugerencias
Zona destinada para el envío de sugerencias a los administradores del servidor.
Contacto
Se detalla la dirección postal y de correo electrónico del SITGA.
Ayuda
Ayuda para la utilización del servidor.
Resumen: Se presentan los objetivos del Geoportal de la Infraestructura de Datos Espaciales de España (IDEE),
abierto desde Junio del 2004, así como su principales características, funcionalidades y posibilidades. El Geoportal de
la IDEE pretende ser el punto de acceso principal en España a la arena dónde es posible buscar, acceder, invocar y
encadenar todo tipo de servicios relativos a Información Geográfica. Hasta ahora está estructurado en torno a tres
servicios básicos (Catálogo, Nomenclátor y Visualización) y a la interoperación de más de 15 servidores en los ámbitos
nacional, regional y local. Pero más allá de esta primera aproximación existen otras posibilidades relacionadas con
WCS, WFS y la integración de datos y metadatos del sector privado.
INTRODUCCIÓN
Un portal es un sitio web que actúa como puerta de entrada, proporcionando un punto de acceso único a
múltiples recursos. También se puede definir como un entorno web que permite a una organización o a una comunidad
de usuarios y proveedores agregar y compartir información.
Un geoportal es un punto de contacto que ofrece a los ciudadanos un conjunto de recursos vinculados con
información geográfica. Los recursos pueden ser de varios tipos, conjuntos de datos, series, aplicaciones,
documentación, servicios, etc.
En España, existen unas quince organizaciones, tanto a nivel nacional, como a nivel autonómico y local que
están desarrollando proyectos directamente relacionados con las Infraestructuras de Datos Espaciales. Algunas de ellas
han desarrollado geoportales que permiten un acceso rápido y cómodo a los recursos de información geográfica del
ámbito de la organización correspondiente.
La principal función del geoportal IDEE es actuar como punto de acceso a los recursos ofrecidos a través de la
IDEE. De este modo, los ciudadanos pueden buscar y localizar servicios y conjuntos de datos basados en información
geográfica de España e incluso descargar o invocar estos recursos.
El geoportal IDEE además de acceder a los recursos del nodo IGN, accede a los servicios proporcionados por
otras organizaciones cartográficas, sin perjuicio de que estas organizaciones utilicen sus propios geoportales para la
explotación de estos recursos. De hecho, la utilización de información procedente de diversas fuentes es uno de los
aspectos claves del geoportal IDEE, ya que proporciona nuevos servicios a través de la integración de datos
heterogéneos y dispersos.
El geoportal IDEE está disponible en Internet, siendo accesibles todas sus secciones sin ningún tipo de
restricción (no existen secciones para usuarios registrados, ni ningún tipo de licencia, o tasa para explotar alguno de los
servicios ofrecidos). Por tanto, cualquiera (ciudadanos, universidades, organizaciones del sector público y privado, etc.)
puede explotar los servicios directamente e incluso crear nuevos servicios mediante composición o agregación de
servicios que den valor añadido a los servicios básicos de la IDEE.
El geoportal IDEE usa tecnología Java (Apache Web Server, Tomcat Aplication Server, JSPs) y JavaScript,
como herramientas de desarrollo. Además, no es necesario instalar en la máquina cliente, ningún tipo de software
(como plugins, cookies o applets). De este modo se consiguen que el portal sea independiente de la plataforma cliente,
no tiene requisitos hardware, ni sistema operativos, se ejecuta en diferentes navegadores y versiones (Internet Explorer,
Netscape, Mozilla, Opera,…). Obviamente, esta tecnología abierta implica algunas desventajas, en ocasiones
dificultando el desarrollo de algunas funcionalidades y en otras afectando al rendimiento.
Una de las nuevas características del geoportal IDEE es su nueva imagen. El Ministerio de Administraciones
Públicas ha publicado una “Guía para la edición y publicación de las páginas web de la Administración del Estado” que
debe ser seguida por todas las páginas web de la AGE y Organismos Públicos vinculados o dependientes de ella. Los
principios que debe seguir un portal de la AGE deben ser:
- Orientación al usuario
- Proyectar imagen del gobierno
- Servicios accesibles
- Facilidad de uso
- Coherencia
- Interactividad
- Ordenación de la información
- Seguridad
- Evaluación y mejora
- Gestión adecuada
En la siguiente imagen se puede observar la antigua imagen del portal de la IDEE y la nueva imagen tras las
modificaciones pertinentes:
Además, de los cambios de imagen, se ha dotado al portal de mayor accesibilidad, consistiendo ésta en
garantizar el acceso a la información y a los servicios de sus páginas sin limitación ni restricción alguna por razón de
discapacidad de cualquier carácter o condicionantes técnicos, debiendo tener en cuenta que muchas personas que
acceden a la información incluida en páginas web lo hacen desde diferentes dispositivos y contextos.
Con el fin de ayudar y facilitar el acceso a la información, las páginas web deben cumplir una serie de pautas y
recomendaciones indicadas por el grupo de trabajo WAI (http://www.w3.org/WAI/), que forma parte del consorcio de
W3C (http://w3.org). Tales pautas conforman un estándar de hecho en materia de accesibilidad a las páginas web.
Sin duda, y a pesar de los esfuerzos realizados en el tema de la accesibilidad y de las dificultades que la
información geográfica tiene intrínseca (información visual, información por colores, procesamientos complejos), es
necesario realizar un segundo esfuerzo para lograr un geoportal más útil para todo tipo de usuarios
Aprovechando el cambio de imagen se ha realizado una reestructuración de los contenidos del portal, para una
mejor distribución de temas e incluyendo información y documentación más útil, nombres de secciones más claros y
una subdivisión más lógica. En la nueva versión las secciones son:
1. La IDEE de España
o El proyecto IDEE
o El Grupo de Trabajo IDEE
o IDEs y SIGs en España
2. Contribuir a la IDEE
o Cómo contribuir
3. Servicios del Portal
o Búsqueda de datos y servicios
o Visualización de mapas
o Búsqueda de Nombres Geográficos
o Descarga de datos
4. Recursos
o Creación de Metadatos
o Calculadora Geodésica
o Sistemas de Referencia Espacial
5. El mundo IDE
o Información sobre IDEs
o INSPIRE
o Organizaciones
6. Noticias y Eventos
La división de un producto en un conjunto de capas, cada una de las cuales almacena información sobre una
temática determinada (hidrografía, relieve, vías de comunicación, etc.), permite la observación del producto desde
diferentes vistas sectoriales y permiten al cliente adaptar la visualización de la información a sus intereses sectoriales.
La especificación OGC WMS v1.3 está orientada hacia la visión de un producto como un conjunto de capas y
subcapas. Por lo tanto, si se persigue el objetivo de relacionar un WMS con su conjunto de datos, es necesaria la
utilización de metadatos a nivel de capa temática.
A partir de esta nueva versión los productos del IGN que son accedidos a través de un servicio de mapas
(Bases Cartográficas Numéricas, Cuadrículas Geográficas, Redes Geodésicas), tendrán asociados un conjunto de
metadatos que describen cada una de sus capas temáticas y estos metadatos serán accesibles a través del visualizador
del geoportal IDEE.
Una vez que los servicios web de mapas del Nodo IGN, ya han alcanzado una cierta madurez (servicio con una
alta disponibilidad, unos tiempos de respuesta mínimamente aceptables y una información de referencia amplia), es
necesario dar un paso más. En esta nueva versión del Nodo IGN se han desarrollado e implementado una serie de
servicios web de entidades que facilitarán el posterior desarrollo de aplicaciones clientes que los exploten.
Se ha creado un cliente para la explotación del servicio web de entidades del proyecto CORINE LAND
COVER. Este cliente nos permite:
- Entrar eligiendo una unidad administrativa o por área geográfica (de momento, en caso de área geográfica
se pasa directamente al visualizador del Corine). Para entrar por unidad administrativa hay que seleccionar
CCAA, Provincia y Municipio.
- Posibilidad de elegir el año del Corine que se quiere visualizar, el nivel de detalle, y el estilo (opaco o
semitransparente), teniendo en cuenta que las capas del corine se muestran aproximadamente a partir de la
escala 1:300000 o mayor.
- Posibilidad de visualizar las diferencias entre los años 90-2000.
- Con el botón Mostrar leyenda se muestra la leyenda del nivel del Corine que se está visualizando en ese
momento. En esta leyenda, podemos seleccionar las clases que queremos visualizar, por ejemplo, ver solo
los Bosques de Ribera.
- Consultar desde la leyenda la superficie ocupada por las clases que estén seleccionadas.
- El usuario puede consultar los datos asociados al punto que marque sobre el mapa utilizando el botón i de
la barra de herramientas.
TRABAJOS FUTUROS
Si cuando se mira hacia atrás, es posible apreciar la cantidad de trabajo realizado por todos los agentes
implicados en la construcción de la IDEE, cuando se mira hacia delante se contempla un abanico inmenso de
posibilidades, funcionalidades, servicios, aplicaciones que exploten los servicios, encadenamientos de servicios, etc. A
corto plazo, los siguientes objetivos son:
- Servicio web de mapas para el acceso a las ortofotos e imágenes de satélite del Instituto Geográfico
Nacional.
- Aplicación cliente para la explotación del servidor mencionado en el punto anterior.
- Desarrollo de un servicio web de coberturas utilizando como información de base el Modelo Digital del
Terreno.
- Nuevas funcionalidades del visualizador (descarga, impresión, creación de informes, etc.)
REFERENCIAS
1. Ministerio Administraciones Públicas, “Guía para la edición y publicación de las páginas web de la Administración
del Estado”, MAP, Madrid, 2005
2. Louis C. Rose, “Geospatial Portal Reference Architecture”, Open Geospatial Consortium, Lisbon, 2004.
3. Williamson I., Rajabifard A. and Feeney M.F. “Developing Spatial Data Infrastructures, From Concept to Reality”
University of Melbourne, Australia, 2003.
4. Groot R., McLaughlin J. “Geospatial Data Infrastructure, Concepts, cases and good practice”. Oxford University
Press, 2000.
5. Peng Z., Tsou Z. “Internet GIS: Distributed Geographic Information Services for the Internet and Wireless
Networks” Wiley & Sons, 2003.
7. Barry, Douglas K. “Web services and service-oriented architectures” Morgan Kaufmann, 2003.
10. ISO15836:2003 “Information and Documentation. The Dublin Core metadata elements set”
Abstract: SDIGER is a pilot project on the implementation of the Infrastructure for Spatial Information in Europe
(INSPIRE), funded by the Statistical Office of The European Communities (EUROSTAT), which aims at demonstrating
the feasibility and advantages of the solutions for sharing spatial data and services proposed by the INSPIRE position
papers and to estimate the costs and to find the problems and obstacles of implementing interoperability-based
solutions on the basis of real cases. SDIGER consists in the development of a Spatial Data Infrastructure (SDI) to
support access to geographic information resources concerned with the Water Framework Directive (WFD) within an
inter-administration and cross-border scenario that involves: two countries, France and Spain; and, the two main river
basin districts at both sides of the border, the Adour-Garonne basin district and the Ebro river basin district. The
objective of this paper is to present the project and its objectives, making special emphasis on the feedback provided by
the development of this project and the problems associated with the creation of a transnational Spatial Data
Infrastructure.
INTRODUCTION
SDIGER is a pilot project on the implementation of the Infrastructure for Spatial Information in Europe (INSPIRE) [1].
This project has been funded by the European Commission through the Statistical Office of the European Communities
(Eurostat), contract number “2004 742 00004” for the supply of informatics services in the various domains of the
Community Statistical Programme. The objectives fixed by Eurostat for this project are three fold. Firstly, it will serve
to test and demonstrate the feasibility and advantages of solutions for sharing spatial data and services, observing the
principles and standards proposed by the INSPIRE position papers in 2002 and their interoperability-based approach.
Secondly, it is useful to acquire experience in implementing interoperable solutions and develop processes able to be
reused when INSPIRE is put into operation. And thirdly, it can help to estimate the costs of implementing
interoperability-based solutions on the basis of real cases, together with the problems, obstacles which might be
encountered during the subsequent large-scale implementation of INSPIRE.
The “call for tender” for this project required the cross-border application to be focused on an environmental subject.
The SDIGER project that was then proposed consists in the development of a Spatial Data Infrastructure (SDI) to
support access to geographic information resources concerned with the Water Framework Directive (WFD) [2] within
an inter-administration and cross-border scenario that involves: two countries, France and Spain; and, the two main
river basin districts at both sides of the border, the Adour-Garonne basin district, managed by the Water Agency for the
Adour-Garonne River Basins (L’Agence de l’Eau Adour-Garonne) and the Ebro river basin district, managed by the
Ebro River Basin Authority (Confederación Hidrográfica del Ebro).
This project is being developed by a consortium consisting of the following entities: IGN France International (Institut
Géographique National France International), the National Geographic Institute of France (Institut Géographique
National), the National Centre for Geographic Information of Spain (Centro Nacional de Información Geográfica), and
the University of Zaragoza (Universidad de Zaragoza), together with experts from University Jaume I. Additionally,
this consortium counts on the help of the following collaboration entities: the National Geographic Institute of Spain
(Instituto Geográfico Nacional), the Water Agency of Adour-Garonne (Agence de l’Eau Adour-Garonne), the Ebro
River Basin Authority (Confederación Hidrográfica del Ebro), the Regional Direction of the Ministry of Environment
for the Midi-Pyrenees region, and the GIS-ECOBAG association. As it can be observed, these entities (most of them
public institutions) are the main providers of the topographic and hydrographic data in the cross-border area.
The paper is structured as follows. Next section provides a more detailed explanation of the objectives of the pilot
project, organized by activities. Then, the following section explains the problems found in the development of the
different activities. These problems are classified in 5 subsections: problems found in the definition of a useful
application scenario, problems found in metadata related activities, problems related with data specifications, problems
related with the set-up of services, problems found in the definition of the geoportal, and general management
problems. Finally, current state of the project and the next steps to be taken are defined in the Conclusions section.
SDIGER is a two-year project, divided by Eurostat in the “call for tender” in a set of activities orientated to face the
problems that may arise in the large-scale implementation of INSPIRE. The following subsections detail these
activities. All of them, except for the last one, correspond to the first year of the project.
The SDIGER project consists in the development of a Spatial Data Infrastructure (SDI) (see figure 1) to support access
to geographic information resources concerned with the Water Framework Directive (WFD) within an inter-
administration and cross-border scenario that involves: two countries, France and Spain; and, the two main river basin
districts at both sides of the border, the Adour-Garonne basin district, managed by the Water Agency for the Adour-
Garonne River Basins (L’Agence de l’Eau Adour-Garonne) and the Ebro river basin district, managed by the Ebro
River Basin Authority (Confederación Hidrográfica del Ebro).
Ex pert
R e fe ren c e
T h em atic
Pres s ure s
•P oin t s o u rce po ll.
•D iffu se s o urc e p oll.
S u rfa ce W B G ro u n d W B M o nito rin g •W at e r a b s tra c tio ns
•M or p ho . a lte r atio n s
Ba ck gro u n d
SW 1: D is trict
SW 2: B a sins
D G -E N V
•Tr a nsitio nal
•C o astal
J R C IN S P IR E
P U B L IC
ACCESS
JR C W FD
IN F O
<<F RA N C E >> < < S P A IN > > < < F R A N C E , S P A IN > >
E N V IR O N M E N T E N V IR O N M E N T S D IG E R
M IN IS T R Y M IN IS T R Y P U B L IC
P U B L IC ACCESS
ACCESS IN F O
IN F O
<<F RA NC E >> < < S P A IN > >
S u rfac e W B G ro u n d W B P ro te c te d A rea s
IG N -F R A N C E IG N -S P A IN S W 4b : E c o. s tatus
P U B L IC P U B L IC S W 4c : E c o. pote ntia l
ACCESS ACCESS
IN F O S W 4d : S y nth . po ll.
IN F O
<< A D O U R -G A R O N N E R B D > > S W 4e : C hem . s ta tus
<<E BR O R B D >>
L ’A g e n c e
CHE
d e l’e a u P U B L IC
P U B L IC ACCESS
ACCESS IN F O
IN F O
Details of both applications can be found at the “Application Scenario” document available at the SDIGER portal
(http://sdiger.unizar.es).
In this area we can distinguish three main tasks: the definition of metadata profiles customized to the type of resources
to be described in the project, the development of a metadata edition tool, and the own task of creating metadata
contents.
Within the SDIGER project, three metadata profiles have been developed: a metadata profile for geographical data
mining, a generic metadata profile for INSPIRE for assessing and using geographical data and a metadata profile for the
Water Framework Directive. The standards ISO19115 [3] and Dublin Core [4] have been the basis for the development
of these profiles. In general, a metadata application profile should have in their objectives to facilitate the metadata
creation process by: providing an specification of the subset of the metadata standard terms (choosing the ones that are
more relevant for a specific domain); offering guidelines for filling in the fields of the metadata according with the
specific domain; and providing specific keyword controlled lists, thesaurus and ontologies for the context where the
application profile is used. For the development of these metadata profiles, several standards and initiatives in the
context of spatial data infrastructures have been taken into account additionally:
• The proposal for the INSPIRE (Infrastructure for SPatial Information in Europe) [1]. Chapter II of the proposal
makes explicit references to the information that metadata should contain to describe spatial resources.
• The Draft Technical Report on “Geographic Information – Metadata – European core metadata set” developed
by the Working Group 5 (Spatial Data Infrastructures) of CEN/TC287 [5].
• The draft spatial application profile of Dublin Core proposed by the European Standardization Committee
(CEN) [6].
• The guidelines for metadata included within the document “Guidance Document on Implementing the GIS
Elements of the Water Framework Directive” [7]. The first application domain tackled by the INSPIRE
proposal is environmental data and WFD data is directly related with environmental aspects. Additionally, the
WFD metadata profile should observe and take into consideration this guidance document.
• The core metadata recommendations for the Spanish Spatial Data Infrastructure [8].
From a conceptual point of view, the metadata profiles should be organised hierarchically putting Dublin Core in the
top level because it is the most general metadata standard. This metadata could be specialised with the application
profile that has been proposed within the scope of this project for geographical data mining. More details should be
included in the INSPIRE application profile (it ought to take into account the effect of the multicultural and multilingual
heterogeneities in the creation of metadata and provide guidelines to avoid this heterogeneity) and this one should be
refined with the WFD application profile (specialised in water resources).
The “Dublin Core Metadata Application Profile for geographical data mining” is based mainly in the Dublin Core
Spatial Application Profile [6], though several modifications have been done, such as including new elements
(provenance and rightsholder), new refinements (distance and equivalentScale.denominator to the element
spatialResolution) and changes in the encoding scheme (drop of TGN and inclusion of EUROVOC, AGROVOC and
INSPIRE_SpatialThemes). The “Generic metadata profile for INSPIRE for assessing and using geographical data” is
based on an application profile of ISO19115 [3] with the objective of describing the spatial resources in accordance
with the proposal for the INSPIRE directive, focusing on the Chapter II, which makes explicit references to the
information that metadata should contain to describe spatial resources. Finally, the “Metadata profile for the Water
Framework Directive” is an ISO19115 profile mainly based on the guidelines for metadata included within the
document “Guidance Document on Implementing the GIS Elements of the Water Framework Directive” [7], making
special emphasis on the description of data quality.
Within the SDIGER project, an open source metadata management tool with support to the aforementioned metadata
profiles has been provided. This application is based in the CatMDEdit tool [9] that was previously developed by the
authors. This tool, multiplatform and multilingual (Spanish, English, French, Polish and Czech) , includes as main
functionalities:
• Support for edition and visualisation of metadata entries according to different ISO19115 and Dublin Core
profiles.
• A thesaurus management tool, allowing the management of thesauri supported by a thesauri database. The
main functions of this tool are: creation/deletion/modification of thesauri; edition/visualisation of terms in a
hierarchical and alphabetical structure; and import/export from/to text files in different formats. For the
SDIGER project, and new multilingual thesauri support (in Spanish, French and English) has been included:
UNESCO (about 5.000 terms), AGROVOC (about 11.600 terms), EUROVOC (about 7.200 terms) and
GEMET.
• An XML Import/Export tool, enabling the exchange of metadata records in XML format conforming to
different standards such as CSDGM, ISO19115 and Dublin Core. Besides, the tool also facilitates more
readable presentations of metadata records in HTML format. The import process has two possibilities: it can
either create a new metadata record, or update the content of a metadata record previously selected from the
metadata repository.
• A Metadata Generation tool, enabling the semi-automatic generation of metadata for several types of
resources. For instance, this tool is able to obtain descriptive information from ESRI shapefiles. Additionally,
the tool can also extract metadata corresponding to the relational structure of tabular sources (e.g. Excel,
Access, Oracle…).
• A Contact Management Tool, allowing reusing contact information (e.g. name, address, telephone…), which is
needed in several metadata fields. Thanks to this tool, the contact information about a person is only inserted
once and used whenever it is required.
Metadata creation
The metadata catalogue was performed for core topographic data provided by National Mapping Agencies, thematic
data provided by Water Agencies and some of the European data provided by EuroGeographics, JRC and Eurostat.
Behind providing the metadata to be integrated into the geoportal for description of the data, this procedure served to
test and provide the comments concerning both the profiles and the CatMDEdit tool. The results of this survey will be
present in the study report to be provided to the Eurostat by the end of this year and the metadata records (see table
below) are actually available on the geoportal of the project.
The Geoportal of the SDIGER project is already accessible at http://sdiger.unizar.es and providing access to data and
services produced and served by the institutions being partner or collaborator of the SDIGER consortium. This portal is
structured in four main sections:
• General information about the project. This section provides details about the project (objectives, partners,
results …), useful links and any other kind of information that could be interesting for the project audience.
• Generic services. This sections offers access to the three basic services considered: geodata catalog search
application, gazetteer application and geographic information visualization application.
• Use case applications. This section provides the applications which implement the two use cases described in
the application scenario deliverable.
• Private area. This section provides access (with login and password) to a restricted area where the documents
and the deliverables are stored.
Additionally, this portal offers these capabilities with no language restrictions (Spanish, French and English). In order to
develop such a multilingual portal, two issues must be solved: the GUI internationalization and a cross-language
information retrieval model. With respect to the first issue, the GUI components (labels, buttons, value lists, …) must be
displayed in the language specified by the user. For these requirements, Java internationalization techniques and XML
technologies (including XSLT) have been used to dynamically internationalize the software components, load web
pages contents stored as XML documents, and apply the appropriate style sheets to display the required portal style and
with the appropriate language for text labels. And as regards the second issue, a cross-language information retrieval
model will be proposed. There are a lot of geographic information resources that are catalogued using only one
language, but users that make their queries in one language may be interested in existent resources that have been
described in another language. The user is more interested in the resource (map, image or multimedia resource in
general) rather than in the metadata describing it. Thus, catalogs must provide users with the mechanisms facilitating
the multilingual search without forcing cataloguing organizations to describe their resources in all the possible
languages. Next activity explains the multilingual resources used to facilitate this cross-language retrieval.
French and Spanish are the official languages of the two countries directly involved in the project. Besides offering data
and services in these two languages, an English version of the geoportal will be also available to facilitate accessibility
to users not familiar with these other two languages. Therefore, multilingual resources like multilingual thesauri
(GEMET [10], UNESCO [11], EUROVOC1 and AGROVOC2) and multilingual gazetteers will be used to facilitate the
creation of metadata and the development of ergonomic search interfaces for data and service catalogs [12].
Additionally, although the multilingual thesauri facilitate the cross-language information retrieval, it is also important to
help the user understand the content of metadata records that may have been written in a language different from the
user query language. In that case, it would be desirable to translate on-line the records obtained as a result of the query
by means of a machine translation service. For that purpose, SYSTRANLinks from SystranSoft
(http://www.systransoft.com) has been selected as the machine translation service used in this project.
Creation of a common object-oriented data model for the data used in the application
As the SDIGER project is especially focused on thematic water data, this activity has given priority to the
harmonisation of data models related with the water resources, in particular the ones required by the WFD.
As a common schema for interoperable access to national data was required for the application scenario use cases, the
national layers in both countries have been analysed for modelling harmonisation. That is the reason why it was decided
to make the data model for the thematic data concerned by the application scenario, then add other core data also
involved into the application and make a study concerning task for harmonisation of the all the data, which are
integrated into the geoportal.
User client browser
Local WFS
Local Models
Local coordinate systems
Configuration of servers
This activity consists in the configuration of the servers for accessing the data and services covered by the application
according to the ISO and Open Geospatial Consortium standards. The types of services that are offered are basically
three: discovery of geographic data through the use of geographic data catalogs; map on-line visualization on the web
1
http://europa.eu.int/celex/eurovoc
2
http://www.fao.org/agrovoc
by means of the use of Web Map Servers (WMS); and a selected access to data through Web Feature Servers (WFS),
mainly for the web application described in the next activity.
Internet application
This activity, nowadays in progress, consists in the development of web applications fulfilling the use cases proposed
by the first activity and making profit of data and services established in the previous activities.
This activity, still under development, will produce a report based on the previous activities will be written to provide
elements to identify problems, solutions and the costs of using configurations commensurate with the European scale of
INSPIRE. Thanks to the analysis of costs, problems and successful experiences in the development of previous
activities, we will be able to define an accurate SDI reference model, which will include solutions to problems found at
the pilot project and fit to the features of INSPIRE objectives at the European level. We will provide a business plan
making special emphasis on the estimation of costs, which will be classified as follows:
• Creation of the data model. Based on the costs of developing the models developed within this pilot project
(mostly focused on water reference data and hydrological resources), we will estimate the extension of these
models to other application domains.
• Configuration of the catalogue. We will estimate the costs involved in the configuration of a catalog services
server for prototypical institution that decides to form part of INSPIRE network of nodes.
• Configuration of a server according to OGC standards. Apart from a catalog services server, we will also make
an estimation of the costs for installing the main services to provide on-line visualization and access to data,
i.e. the cost of set-up of a WMS, WFS, WCS and a gazetteer service.
• Costs of multilingualism management. We will include the costs of acquiring and integrating multilingual
resources to facilitate multilingual capabilities of geoportals and services.
• Costs of developing the application excluding the aforementioned costs. Here, we will estimate the budget of
developing customized applications built upon integrated access to the data and services offered by an SDI.
• Costs of re-engineering the data if necessary. Given the experience of harmonizing the data provided by the
institutions involved in this project, we will estimate the average cost that must be addressed to adapt data to
INSPIRE standards and common models.
• Costs of licences for software and data; cost of hardware. The costs due to software licenses and hardware
needed for this project will be similar to the costs needed for the configuration of servers in a node
participating in the European SDI aimed by INSPIRE.
• Costs for maintaining servers and availability of services on the Internet. Given the experience of this project
and previous projects developed by the partners of the SDIGER consortium, maintenance costs and issues
concerned with 24/7 availability will be estimated.
• Other costs not covered by the above list. Thanks to the experience of developing this pilot project, new
aspects and problems not included initially in the tender specification will be taken into account.
The main goal of the second year project will be the assurance of the services and applications functionality, ensuring
that average up-time of all servers allows a correct use of the infrastructure. In order to fulfil this, it will be necessary to
plan security mechanisms and to design contingency plans. The work will be focused in four main areas: version control
in each node, specification of a contingency plan, definition of backup procedures, and to establishment of a personal
plan to guarantee response time. The node version control should take into account and to inventory: the characteristics
of the hardware that supports each node services (processor, memory, hard disks,…), operating system version, base
software versions (database management system, web server, application server,…), application software versions and
instances (web applications, portals, services) and data. Additionally, it should be necessary to have a dependency map
between data, services and applications and to have an installation map that shows the distribution of the whole
contents. The main objective of the node version control is to provide the information necessary to “clone” a node from
the backups as soon as possible.
PROBLEMS FOUND
This section provides details of the problems found during the development of the SDIGER project. Identifying these
problems is one of the main objectives of this project. In some cases, it could be possible to provide solutions to be
exported to other contexts. In most cases, solutions implemented are just “ad hoc” solutions that should be redefined
over new rules and recommendations provided by the INSPIRE initiative. The problems found have been classified into
five sections: problems found in the definition of a useful application scenario, problems found in metadata related
activities, problems related with data specifications, problems related with the set-up of services, problems found in the
definition of the geoportal, and general management problems.
The first task of this project has been the specification of an application scenario. Maybe the most relevant problem has
been to find a useful use-case. The status of most SDIs is that they have just created just geoportals with quite attractive
map viewers and a search service for data holdings based on metadata. However, project supervisors realize that this is
only a very first step that did not fulfil their expectations. It is needed to prove that SDIs solve real problems in an easier
way than developing stand-alone applications from the scratch. Our first intention was to set-up a set of servers able to
display and make searches on data required for the Water Framework Directive. However, this was not enough.
European Commission wanted to verify that forcing member states to create WFD data, real useful applications could
be derived. That is the reason why we finally proposed the “water abstraction use case” that, on the one hand, solves a
real need and improves an administrative process, and on the other hand makes profit of the data required by the WFD.
In addition, the “WFD reporting use case” will show how to combine two new requests to the member states imposed
by the European Commission: reporting described in articles 3 and 5 of the WFD and INSPIRE requirements.
The project will provide the three specific application profiles detailed previously and a tool that will be able to
facilitate the creation of metadata according with these profiles. We would like to detail two of the difficulties found in
the definition of the metadata profiles:
• ISO19115 is a complex metadata standard. Although trying to define simple and customised profiles for
INSPIRE and WFD force you to create also complex profiles.
• Although establishing the correspondence between ISO19115 and Dublin Core, these standard are still quite
far from each other. We have proposed a Dublin Core Application Profile for Geographical Data Mining as a
first step for description of resources. But we need also to define a complex crosswalk to transform this first
step Dublin Core metadata into ISO19115 for full description.
As a consequence of these difficulties, the use of the metadata management tool has shown two main problems:
• Creation of guidelines must be defined. Despite that the understanding of the semantics of a metadata element
is sill quite subjective.
• Automatic metadata creation tools are needed as metadata creation is usually done after data creation.
Once the tools for creating and maintaining metadata are available, next step is to create them. This process produces a
very interesting and complex to solve subset of problems. Maybe the most relevant could be the following:
• There is still no culture about metadata creation. Metadata creation is still a project-driven approach in public
institutions. That is to say, metadata is created only when public institutions commit themselves to an SDI-like
project. Quite the opposite, they should encourage metadata creation as another task performed together with
data creation.
• The detail of metadata is quite heterogeneous in different institutions, together with the contents of the items
filled. It is necessary to provide standard ontologies to be used by the creators in order to be able to use the
same concepts in the metadata creation processes.
• The metadata creator does not usually take into account that this metadata will be later searched through a
catalog. Examples like errors in the name of data providers may derive in the fact that you can not found.
At the beginning, the tender of the project was too ambitious as it was aiming data harmonization for too many layers:
all national and European layers were liable to be harmonized. Several European projects have been created for that
purpose and most of them have not been very successful. Finally, the scope was narrowed to the layers related with
hydrology and the Water Framework Directive. However, although narrowing the scope, this directive does not provide
a common model suitable for every Competent Authority and several aspects related to the WFD are not present (such
as pressure and impact data). Thus, each Water Agency or member state defines its own model based on the WFD GIS
Working Group recommendations. Additionally, these national and local models are not fully stable as the WFD is just
in the initial phase of implementation. On the other hand, several problems have been found in the harmonization of
data models. Maybe the most relevant are:
• The techniques for data harmonization are not mature enough.
• When appropriate metadata about the data is not available, the understanding of the data semantics of data
sources to be harmonised is very difficult and suggestions for harmonization can be erroneous, particularly
with thematic data (where some expertise is needed for their understanding) and data in different languages
(where some knowledge of the languages involved is needed).
• Where data has not been created following a predefined model (such as pressure data for the WFD),
differences among datasets to be harmonised are so big that the harmonisation is hard and can only be
performed at a very high level.
• Conversion of data on the fly is not very efficient.
During the development of this project, it has been necessary to install and put on line several Web Mapping Services.
In addition, these ones and another ones provided by the project partners have been include in the possibilities offered
by WMS clients. The most important problems found during this work could be the next ones:
• Existence of security restrictions (firewalls). It has been necessary to develop and install WMS-Proxies in
order to allow the access to services provided by some public institutions that have not their WMS available at
Internet level. In addition, it will be necessary to access to all the WMS using a relay system in order to be able
to control the use of them (server systems offered by third parties can not be configured for proving log
information).
• Different Spatial Reference Systems (SRS): Multiple WMS can only interoperate if they share at least one SRS
as a common denominator. Lack of support of specific or common projection systems may prevent the
visualisation of more than one WMS at a time.
• Multilingualism: How to treat multilingualism, e.g. in legends derived from different WMS or in the textual
information given on a selected feature in response to a GetFeatureInfo request.
• Coherent use of scale hints: The WMS specification gives a general rule but no explicit reference on how to
treat different scales. There is no provision of information concerning the scale of a specific dataset and this,
may result in unpredictable results. Thus maps of very different scales may be combined in senseless ways or,
on the contrary, it may not be possible to combine maps with almost similar scales.
• Consistent principles of cartographic styling: As most of the current WMS do not fully support the Styled
Layer Descriptor specifications, a user defined cartographic styling of the advertised map layers is not yet
feasible, thus leading to colourful patchworks of adjacent map layers served from different WMS or resulting
in visually hardly to interpret overlays composed out of the selected layers coming from various WMS.
The initial objective of the project was to be able to access to the catalogs provided by the partners of the project (IGN
Spain, IGN France, CHE and AEAG) within their SDIs. The solutions could be to accessing them in an on-line
distributed catalog manner, or by using harvesting technologies. Finally, the project provides only one own catalog
where the metadata provided by the four institutions have been loaded. The reason for choosing this alternative is based
in the following problems:
• Only one of the four institutions had its catalog on-line. The others had some metadata created, or even no
metadata.
• The definition of distributed catalog that not has matured specifications. There are two work lines in this area:
the real on-line distributed catalog, and the use of harvesting techniques. In both cases, there are many
technical problems that mast to be solved.
• In addition, there is a lack of real implementations compliant with well-established specifications. To be able
to develop systems with the capacity for connecting with on-line catalogs that satisfy current standards is a
hard work. OGC has provided a good job trying to accord a standard for catalogs. Nonetheless, and even
though great progress has been achieved due to these initiatives, the fact is that at present there are far too
many catalogue services’ implementation profiles and standards available, even just inside OGC: Z39.50,
CORBA-IIOP, SRW or CSW (SOAP, XML-Post and KVP).
The situation at the beginning of the project was the following: IGN Spain provided the gazetteer that could be adapted
to the OGC recommendations (but with an extra effort), and the inventory in France has shown that there is no real
gazetteer (but there is a toponyms database suitable to be transformed into one). This work was performed by IGN
France staff especially for the SDIGER project. The resulting gazetteer containing more than 94,000 items for French
Midi-Pyrénées region and complaint with specifications provided by Spanish partners is integrated into the geoportal.
The following table shows the number of geographic names accessible through the Gazetteer service.
Institution Content Nr
- geographic names
IGN -Spain - administrative names
- hydronyms 361581
CHE Ebro - water points 52902
- hydronyms
- populated places
IGN-France - non-populated places
- oronyms
- other 94107
Total 508590
We have distinguished two main kind of problems related with the development of the GeoPortal. The first one is
related with the web application that will be provided. These problems can be separated into the ones related with it
specification (see problems with the application scenario) and the problems of performance. In this way, it is necessary
to mention the use of Web Feature Servers. They seem to be the appropriate specification for the exchange of feature
data on the fly, but in practices they result to be quite inefficient.
The other main set of problems is related with the multilingualism of the portal. This set is integrated with the
following main difficulties:
• Difficulties for the development of Web portal infrastructure with capabilities for internationalization.
• Difficulties for the translation of contents of the projects in 3 different languages.
• Difficulties for the internationalization of legends in Web Mapping viewers. The Web Mapping Service does
not take into account the management of names of layers in different languages.
• Difficulties in the presentation of metadata into the 3 different languages. Metadata has been created using one
specific language but should be able to be presented in the rest of languages used for the project. An automatic
translation tool has been used (Systran) but we are not sure about the results provided by this tool.
• Difficulties in the data modelling and harmonization, in particular with thematic terms and data.
General problems
In addition, a set of important difficulties related with the conception and nature of the project have been found during
its development. They have been classified into the following three main sets.
The initial planning of SDIGER as an SDI built upon existing SDIs is still a dream. We have faced that the SDIs
developed by the public institutions involved in the project are still in a very initial state, and in many cases with a no
clear future and/or objectives. Several basic services have been created specifically for this project.
This project involves a big set of institutions and administrations. The nature of the contractor (EUROSTAT from the
European Commission) and the importance and the repercussion of the results of this project should give them an
incentive to get involved with extreme effort and interest. Unfortunately, the development of this project is suffering
difficulties to have real contribution from collaborator entities not really engaged in it. In addition, many problems
related with the communication among the partners involved in the project have been identified.
Data policies
Finally, another set of problems identified are the ones related with the policies of the institutions. This kind of
problems is especially relevant in the case of data policies. Some partner institutions are not allowed to provide public
access to their data, not even for display. This has force the development of special services and the use of restricted
areas.
CONCLUSIONS
This paper has presented SDIGER, a two-year pilot project on the implementation of INSPIRE, funded by Eurostat, that
aims to test, estimate the costs and identify the problems of applying the solutions for sharing spatial data and services
proposed by the INSPIRE position papers in 2002. The base for achieving these objectives is by developing a SDI to
support access to geographic information resources concerned with the WFD in a cross-border scenario that involves
the Adour-Garonne and Ebro river basin districts. The work done till now has shown a set of problems that have been
classified into five categories: problems found in the definition of a useful application scenario, problems found in
metadata related activities, problems related with data specifications, problems related with the set-up of services,
problems found in the definition of the geoportal, and general management problems. At the end of the year 2005, the
SDI with the additional applications will be available after solving these problems. However, the main objective of this
project, as has been mentioned before, is not to have this functionality available. The objective is identify areas that
should be clarified by the INSPIRE recommendations and rules, and to provide a useful tool for future project
development in order to be able to provide better plans for them.
ACKNOWLEDGMENTS
This work is funded by the European Commission through the Statistical Office of the European Communities
(Eurostat), contract number “2004 742 00004” for the supply of informatics services in the various domains of the
Community Statistical Programme. Additionally, this work has been partially supported by the Spanish Ministry of
Education and Science through the project TIC2003-09365-C02-01 from the National Plan for Scientific Research,
Development and Technology Innovation.
BIBLIOGRAPHY
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. Oficial 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)
3. Geographic information - Metadata. ISO 19115:2003, International Organization for Standardization, 2003.
4. Information and documentation - The Dublin Core metadata element set. ISO 15836:2003, International Organization for
Standardization, 2003.
5. Draft Technical Report on “Geographic Information – Metadata – European core metadata set”. Document TC 287 WI 00287XXX
, WG5, 2005.
6. Zarazaga-Soria, F. J., Nogueras-Iso, J., Ford, M. “Dublin Core Spatial Application Profile”. CWA 14858, CEN/ISSS Workshop -
Metadata for Multimedia Information - Dublin Core, September 2003. Accesible at:
http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/cwa14858.asp
7. Vogt, J. (ed.), 2002. “Guidance Document on Implementing the GIS Elements of the Water Framework Directive”, European
Communities.
8. “SGTNEM_2005_01: Núcleo Español de Metadatos”. Infraestructura de Datos Espaciales Española, Consejo Superior Geográfico
(Ministerio de Fomento), 2005.
9. Zarazaga-Soria, F.J., Lacasta, J., Nogueras-Iso, J., Torres, M.P., Muro-Medrano, P.R., (2003). A Java Tool for Creating
ISO/FGDC Geographic Metadata, Geodaten- und Geodienste-Infrastrukturen – von der Forschung zur praktischen, pp. 105-118.
10. European Environment Agency (EEA), 2001. GEneral Multilingual Environmental Thesaurus (GEMET), version 2.0. European
Topic Centre on Catalogue of Data Sources (ETC/CDS), http://www.mu.niedersachsen.de/cds/.
11. UNESCO, 1995. UNESCO Thesaurus: A Structured List of Descriptors for Indexing and Retrieving Literature in the Fields of
Education, Science, Social and Human Science, Culture, Communication and Information. United Nations Educational, Scientific
and Cultural Organization (UNESCO) Publishing, Paris. http://www.ulcc.ac.uk/unesco/.
12. Nogueras-Iso, J., Zarazaga-Soria, F.J., Lacasta, J., Tolosana, R., Muro-Medrano, P.R., 2004. Improving multilingual catalog
search services by means of multilingual thesaurus disambiguation. In 10th European Commission GI&GIS Workshop, ESDI: The
State of the Art, Warsaw, Poland.
SERVICIOS WEB II
209
La IDEE como Herramienta de Ayuda a la Elaboración del Inventario... Sesión 7
Reumen: La industrialización constituye un verdadero hito en la evolución de nuestra sociedad. El progreso de los
avances técnicos y las nuevas actividades ha provocado cambios en nuestro panorama social. Las fábricas, minas o la
vivienda obrera han enriquecido nuestro patrimonio cultural, constituyendo la categoría denominada “Patrimonio
Industrial”. El patrimonio industrial engloba tanto los elementos susceptibles de ser objeto de estudio, como es la
arquitectura industrial o la maquinaria, como los entornos o el patrimonio inmaterial referente a las actividades
productivas de cada lugar. En los momentos actuales, el patrimonio industrial atraviesa una situación que se puede
calificar como paradójica. Por un lado, se asiste a una pérdida rápida y silenciosa de buena parte del mismo; por otra,
se observa una revalorización de la arquitectura industrial que se traduce en rehabilitaciones llevadas a cabo por
destacados arquitectos del momento.
La presencia de un catálogo como instrumento de trabajo se ha convertido en algo imprescindible ya que permite:
conocer lo que todavía se conserva en la totalidad del territorio y determinar las tipologías implantadas y los
elementos singulares que existen en función de diversos parámetros entre los que se pueden citar: la elección como
representante de una tipología; la singularidad dentro de las tipologías; la carga histórica que aquel resto material
conlleva para su comunidad; su valor estético. La importancia que demos a estos parámetros dependerá de si el bien se
quiere considerar de interés local, regional o nacional. A partir de la realización de este catálogo se logra una
reacción en cadena que, desde el conocimiento primero de la existencia de los bienes, deriva de forma lógica en otros
aspectos relevantes que culminan finalmente en la incorporación del patrimonio industrial dentro de los circuitos
culturales.
Desde hace unos años, Aragón ha empezado a mostrar una preocupación por el conocimiento de su patrimonio
industrial, siguiendo la dinámica iniciada, hace ya unas décadas, en el resto del país. Esto se ha traducido en la
publicación de estudios parciales relacionados con las diversas facetas del patrimonio industrial aragonés y, lo que es
más destacado, en la elaboración del catálogo del patrimonio industrial aragonés y de la obra pública. En el año
2004, el Gobierno de Aragón se implicó en el conocimiento del Patrimonio Industrial y de la Obra Pública de Aragón.
Para ello, encargó la realización del proyecto titulado: Catalogación del Patrimonio Industrial y de la Obra Pública
de Aragón. Este artículo presenta cómo se esta llevando a cabo la realización de este proyecto con la ayuda de las
herramientas suministradas por las Infraestructuras de Datos Espaciales (con especial relevancia del uso de los
recursos de la Infraestructura de Datos Espaciales de España), y como se prevé que los resultados de este proyecto
reviertan en las propias IDEs.
PATRIMONIO INDUSTRIAL
La industrialización constituye un verdadero hito en la evolución de nuestra sociedad. El progreso de los avances
técnicos y las nuevas actividades ha provocado cambios en nuestro panorama social. Las fábricas, minas o la vivienda
obrera han enriquecido nuestro patrimonio cultural, constituyendo la categoría denominada “patrimonio industrial”.
El concepto de patrimonio industrial ha ido evolucionando y ampliándose en las últimas décadas al igual que lo hace su
bibliografía. A nivel nacional cabe destacar obras como Arquitectura Industrial. Concepto, métodos y fuentes de
Inmaculada Aguilar Civera o Arquitectura Industrial en España 1930-1990 de Julián Sobrino Simal. En Aragón los
estudios sobre el patrimonio industrial son menores aunque, en los últimos años, están experimentando un gran
aumento, paralelo al creciente interés social, lo que se refleja en tesis doctorales como Arqueología industrial en
Aragón, Arte, Industria y Sociedad (1850-1939) de Francisco Javier Jiménez Zorzo o Zaragoza y la industrialización:
la arquitectura industrial en la capital aragonesa entre 1875 y 1936 de María Pilar Biel Ibáñez.
Resulta complicado definir el patrimonio industrial ya que engloba tanto los elementos susceptibles de ser objeto de
estudio, como es la arquitectura industrial o la maquinaria, como los entornos o el patrimonio inmaterial referente a las
actividades productivas de cada lugar. A todo, añadir que la disciplina tiene como finalidad el estudio directo de estos
elementos, a lo que ha venido a denominarse arqueología industrial. De esta manera el patrimonio industrial comprende
el objeto y la disciplina que lo estudia, y cada uno de ellos, conforme a su particular naturaleza, se define por separado.
Arqueología Industrial
La arqueología industrial es la disciplina que se encarga del estudio de dicho patrimonio industrial con una metodología
concreta. El término comienza a utilizarse a fines del s. XIX, acuñado por historiadores franceses e ingleses, y se
concreta en los años cincuenta del siglo siguiente. Las primeras definiciones que se aportaron se las debemos a
Kenneth Hudson [1] y Angus Buchanan [2] para quienes la finalidad de la arqueología industrial es el descubrimiento,
catalogación, análisis y preservación de los restos físicos de la revolución industrial, con un marco cronológico distinto
en cada país, pero con unas características comunes tales como una nueva organización de la producción, una
complejidad tecnológica creciente, nuevos tipos edilicios, nuevas formas de pensamiento y un nuevo paisaje industrial
La arqueología industrial se sustenta en un sistemático trabajo de campo para el estudio organizado de los restos
físicos legados por la revolución industrial, en la consulta exhaustiva de los archivos conservados y en los testimonios
de aquellos que fueron sus protagonistas.
La arquitectura industrial es una parte del objeto de estudio de esta disciplina y, siguiendo la definición dada por
Inmaculada Aguilar Civera, podemos señalar que es aquella que tiene una finalidad explotativa e industrial y que es la
viva expresión del comercio, fundamentada en unas necesidades socio-económicas. Engloba la producción de todo tipo
de industria (textil, química, metalúrgica, alimentaria, agrícola, papelera, tabacalera, naval… así como todo lo referido a
la extracción de materias primas). A su vez, la arquitectura industrial no es sólo la arquitectura de edificios de uso
genuinamente industrial, sino también la de aquellos edificios relacionados con la aparición en el mercado de nuevos
materiales preparados por la propia industria como el hierro, el acero o el hormigón armado y con la aparición de
nuevas tipologías arquitectónicas que surgieron como resultado de las nuevas necesidades de la sociedad industrial
(mercados, mataderos, almacenes…). Así como la infraestructura en general desarrollada a raíz de la industrialización,
por lo tanto, la llamada Obra Pública y la vivienda obrera, con el componente sociológico que ello conlleva.
A través de esta definición podemos acotar la cronología de los elementos que componen este patrimonio, las tipologías
que lo engrosan y las actividades productivas, distributivas o de consumo, que a él están íntimamente unidas. De esta
forma queda patente la amplitud y variedad de aspectos que engloba el patrimonio industrial y su importancia al estar
directamente ligado al desarrollo de las sociedades. Por todo ello la necesidad de su estudio.
El patrimonio industrial forma parte de la herencia cultural más reciente, aquella que nos ha legado la industrialziación,
Éste, como cualquier otro legado cultural de siglos pasados y contemporáneos, merece un tratamiento similar al que se
otorga al patrimonio histórico-artístico. Es necesario, por lo tanto, realizar una reflexión a cerca de su interés y su valor
para, a partir de su conocimiento, propiciar una adecuada transmisión a las generaciones venideras.
Sin embargo, hasta poder afirmar la pertenencia del patrimonio industrial al conjunto del patrimonio cultural se ha
recorrido un largo camino. Europa vivió a lo largo de los años setenta un proceso de desindustrialización vinculado al
desarrollo de las nuevas tecnologías. Entre otras consecuencias de este proceso, las regiones con una trayectoria
industrial más antigua vivieron un proceso de reconversión industrial que, en el ámbito de la trama urbana, se expresó
en el abandono de los espacios industriales tradicionales, ya que la nueva industria se trasladó hacia los espacios
periurbanos. Esto supuso la aparición de las ruinas industriales y la conversión de estos terrenos en un factor
desestruturante de la ciudad lo que implicaba una desvalorización y pérdida de atractivo de la zona en la que se
encontraban insertos.
A lo largo de la década de los años ochenta, la política local y nacional no se planteo un tratamiento de la ruina
industrial como un fin en si mismo sino como un recurso al servicio de la política de reconversión industrial1. Esta
situación da un giro en la década de los noventa, momento en el que se cambió la idea de suprimir la ruina por la de
conservarla y protegerla. Este cambio de posición está asentado en una serie de razones: “por su condición de vestigios
del pasado con valor testimonial o elementos de la arqueología industrial; por tratarse de un recurso con atractivos per
se, susceptible de actuar como reclamo cultural y, por lo tanto, de convertiste en producto turístico; y por actuar como
un factor de revitalización socioeconómica y recuperación de la identidad para los territorios en crisis”2.
1
.- Tal y como señala Paz Benito del Pozo este planteamiento se concretó en acciones tales como el Polo Europeo de Desarrollo
(1985) y Zonas de Urgente Reindustrialización (desarrollado por el Gobierno español en el año 1985). Ver [4]
2 .- En [4] pp. 217-218.
En los momentos actuales, el patrimonio industrial atraviesa una situación que se puede calificar como paradójica. Por
un lado, se asiste a una pérdida rápida y silenciosa de buena parte del mismo; por otra, se observa una revalorización de
la arquitectura industrial que se traduce en rehabilitaciones llevadas a cabo por destacados arquitectos del momento.
El patrimonio industrial corre un mayor peligro de desaparición que otro tipo de patrimonio debido a un cúmulo de
circunstancias que pasamos enumerar. En el caso de la arquitectura, los edificios industriales suelen estar ubicados en lo
que antaño eran los arrabales de las grandes ciudades, que a día de hoy han sido ocupados por el crecimiento,
generalmente especulativo, de la trama urbana. A lo que hay que sumar, el hecho de que este conjunto de edificios
todavía no es apreciado como edificio histórico por una parte importante de la sociedad, debido a su uso más
relacionado con el sufrimiento cotidiano del trabajo que con la complacencia de la contemplación estética. Hay una
falta de identificación por parte de la sociedad con este patrimonio. A todo ello se debe añadir: el gran número de
elementos a conservar; son bienes sujetos a una continua transformación; su tendencia a la obsolescencia y, por tanto, a
una inmediata ausencia de rentabilidad económica para sus propietarios; con frecuencia, ocupan grandes superficies de
suelo que son de un único propietario; las ruinas industriales se encuentran en una absoluta desprotección legal; hay
elevadas dificultades para una recuperación integral de todos sus elementos originarios y la carencia y/o la disparidad de
criterios en torno a su conservación o su destrucción o derribo
En el caso del patrimonio mueble la situación de perdida irreparable es todavía mayor. En el momento actual, la
renovación tecnológica de las empresas es un elemento que garantiza su productividad y por lo tanto, el reciclaje
tecnológico es continuo y, en ocasiones, vertiginoso. Esta circunstancia obliga al desguace de la vieja maquinaria y a su
sustitución por otra nueva, ya que su almacenaje es prácticamente imposible ante la dimensión de la misma. Está en
manos del coleccionismo privado o de la actuación de los museos industriales salvar del vertedero piezas que
funcionando han sido sustituidas por otras más actuales.
Finalmente, recordar que los archivos de empresa [5][6] pasan por unas circunstancias parecidas a las descritas
anteriormente para el patrimonio mueble. Este conjunto de documentos producidos por las propias empresas en el
desarrollo de su actividad económica desaparecen con una gran facilidad ante el cierre, la fusión o la quiebra de la
empresa o ante los altos costos que para la misma supone su conservación y organización. Y, sin embargo, como señala
Olga Gállego, “los archivos de empresa constituyen una categoría muy importante dentro de los archivos privados,
pues la historia económica y social de la Edad Contemporánea no se puede hacer sin su conocimiento”3.
Sin embargo, desde hace algún tiempo, los viejos edificios industriales se han convertido en noticia reseñable de
periódicos y revistas al ser objeto de intervenciones realizadas por los más renombrados arquitectos del momento,
entrando a formar parte de la arquitectura espectáculo tan querida por la posmodernidad. Así, entre los más famosos por
su repercusión en los medios de comunicación, destacan la reutilización de una antigua fabrica de Milán como sede de
la firma de Giorgio Armani llevada a cabo por Tadao Ando; los gasómetros de Viena transformados en viviendas por
Nouvel, o la reconversión de la antigua central eléctrica del Bankside en la nueva sede de la Tate Modern ejecutada por
Herzog y De Meuron.
Nos encontramos en un momento en el que la arquitectura industrial es objeto de reconocimiento desde diversos
sectores sociales, que van desde los políticos hasta los colectivos profesionales como los arquitectos. Sin duda, esta
situación ha sido posible gracias al trabajo iniciado décadas antes (los años 60) por la arqueología industrial. Su
desarrollo ha supuesto, por un lado, que los restos industriales se consideren como bienes culturales con lo que deben
tener un reconocimiento jurídico, una estructura administrativa y una política de protección[7][8]. Por otro, que gran
parte de países industrializados desarrolle acciones para salvaguardar las huellas físicas de su pasado industrial. Al
unísono, y a nivel internacional, se lanzaron una serie de iniciativas para organizar la protección de estos restos,
creándose, en 1978, el comité internacional para la conservación del patrimonio industrial, “The International
Committee for the Conservation of the Industrial Heritage” (TICCIH). Este organismo tuvo su origen en los congresos
sobre conservación del patrimonio industrial que, desde 1973, organizaba el Museo de Ironbrige. Dicho comité
internacional fijó como objetivo primordial el desarrollo de la cooperación internacional para la salvaguarda del
patrimonio industrial y la promoción de iniciativas nacionales para dicho fin.
A lo largo de las dos décadas siguientes, los años ochenta y noventa, las iniciativas internacionales se han sucedido
dentro del seno del Consejo de Europa y de organismos como la UNESCO. Así, este último en colaboración con la
TICCIH elaboró, en 1988, un listado con los principales monumentos del patrimonio industrial de la humanidad y,
desde 1995, ha declarado (Un análisis de la actuación de este organismo en [9]) Patrimonio de la Humanidad algunos
conjuntos y ejemplos de arquitectura industrial, como por ejemplo la Siderurgia de Völklingen (Alemania) o la línea de
ferrocarril de Semmering (Austria)4.
La Europa comunitaria puso en marcha, en el año 1983, el plan de Apoyo a proyectos piloto comunitarios en materia de
conservación del patrimonio arquitectónico[10][11][12] dentro de cuyo marco de actuación se beneficiaron una serie de
proyectos, hasta un total de quince, relacionados con la conservación y rehabilitación de espacios industriales europeos.
3 .- En [5] p. 48.
4 .- El País, 6 diciembre 1998, pág. 39.
Finalmente, reseñar para el caso concreto de España, el trabajo llevado a cabo desde el DOCOMOMO (Grupo para la
Documentación y Conservación del Movimiento Moderno), Sección Ibérico. Este organismo privado ha realizado una
labor de investigación y documentación de la arquitectura ligada a la industria que ha quedado plasmada en una
publicación [13]5 en la que se recogen 160 obras de las más de 300 catalogadas por este organismo internacional. Con
el citado libro, DOCOMOMO Ibérico pretende presentar y difundir el legado arquitectónico de la industrial así como
reflexionar sobre las aportaciones de la misma al desarrollo del Movimiento Moderno.
Mientras que, por parte de la adminsitración española destaca la reciente puesta en marcha, en el año 2000, el Plan
Nacional de Patrimonio Industrial [14] que tiene como finalidad convertrirse en un instrumento para la conservación y
estudio del patrimonio industrial español.
Desde la Dirección General de Bellas Artes y Bienes Culturales, a través del Instituto de Patrimonio Histórico Español,
pone en marcha el Plan Nacional de Patrimonio Industrial, que nace con el propósito de articular las bases que
concreten la protección, conservación y recuperación de este patrimonio.
En abril de 2001 se presenta el documento definitivo elaborado por tres expertos en patrimonio industrial, cuatro
técnicos del Instituto de Patrimonio Histórico Español y siete representantes de Comunidades Autónomas (Andalucía,
Asturias, Castilla-La Mancha, Castilla y León, Madrid, Murcia y Valencia), quedando abierto en junio de este mismo
año el plazo a la Comunidades Autónomas para que elaboren y presenten el catálogo de bienes del patrimonio industrial
ubicados en su territorio y susceptibles de ser integrados en el Plan a partir del año 2002.
Se desprende de la primera fase una serie de conjuntos seleccionado a partir de las propuestas de las diferentes
comunidades autónomas, en la que Aragón tiene una presencia limitada basada en el patrimonio preindustrial. Ejemplo
de los bienes seleccionados son las Minas de Ríotinto (Huelva), el Pozo de Santa Bárbara situado en La Rebaldana
(Valle del Turón, Asturias), el Conjunto de la Cuenca Minera de Sabero (León), la zona minera de Puertollano (Ciudad
Real), o el paisaje minero de La Unión y Cartagena (Murcia).
Aragón tuvo una industrialización tardía si consideramos el conjunto del territorio español y en este proceso, Zaragoza
protagonizó el proceso industrial de Aragón condicionando el carácter agroalimentario de la misma al tiempo que inició
el desarrollo de otros sectores como el metalúrgico o el textil. A la capital, le siguieron un conjunto de núcleos rurales
que basó su desarrollo en el cultivo de la remolacha. El resto del territorio se industrializó lentamente siguiendo las
tradiciones económicas que definían a cada comarca aragonesa.
En estos momentos, cabe preguntarse ¿qué edificios quedan de esta realidad económica que vivió Aragón a lo largo del
siglo XX?, ¿ En que estado se conservan?, ¿Cuáles son dignos de ser intervenidos para su conservación?, ¿Cuál es el
grado de protección legislativa que presentan?. En el momento actual en el que nos encontramos tenemos que decir que
es imposible contestar a una gran parte de estas preguntas porque la Comunidad Aragonesa desconoce la situación en la
que se encuentra esta parte de su pasado cultural, lo que ha llevado a una situación en la que:
5 .- Paralelamente a las labores de Registro, Fundación DOCOMOMO Ibérico realiza congresos bienales con el objetivo de
profundizar en los temas más relevantes del Movimiento Moderno en España y Portugal. Uno de estos congresos, el segundo, se
centró en la industria y tuvo lugar en Sevilla en el año 1999, bajo el lema “ARQUITECTURA E INDUSTRIA MODERNAS.
1900-1965” estando la coordinación científica a cargo de Celestino García Braña, Manuel Mendes y Antonio Pizza. En él, se
debatió en torno a la arquitectura industrial y su reutilización. Arquitectura e industria modernas, 1900-1925, Actas Segundo
Seminario DOCOMOMO Ibérico, Fundació Mies van der Rohe/DOCOMOMO Ibérico, Barcelona, 2000.
tecnológico aragonés que, en algunos casos, ha sido frenada gracias a la actuación del coleccionismo privado.
La conservación de este patrimonio es especialmente compleja ya que para su arreglo y mantenimiento es
necesario un conocimiento técnico específico que se ha ido perdiendo ante los cambios operados en la
industria y en los oficios que la misma demanda. Del mismo modo, cada vez es más complicado obtener piezas
de recambio para máquinas u objetos que la nueva industria ya ha dejado obsoletos.
La presencia de un catálogo como instrumento de trabajo se ha convertido en algo imprescindible ya que permite:
conocer lo que todavía se conserva en la totalidad del territorio y determinar las tipologías implantadas y los elementos
singulares que existen en función de diversos parámetros entre los que se pueden citar: la elección como representante
de una tipología; la singularidad dentro de las tipologías; la carga histórica que aquel resto material conlleva para su
comunidad; su valor estético. La importancia que demos a estos parámetros dependerá de si el bien se quiere considerar
de interés local, regional o nacional. A partir de la realización de este catálogo se logra una reacción en cadena que,
desde el conocimiento primero de la existencia de los bienes, deriva de forma lógica en otros aspectos relevantes que
culminan finalmente en la incorporación del patrimonio industrial dentro de los circuitos culturales de Aragón.
Los aspectos que parten de este inventario, comunes a cualquier inventario, conforman una cadena, que se inicia en el
eslabón del conocimiento de los bienes industriales existentes en cada comarca. Al tomar conciencia de estos
elementos, se da paso a su estudio y pormenorizada valoración crítica por parte de los respectivos grupos de trabajo.
Cada elemento se analiza individualmente y de forma protocolaria en cada uno de los casos, desde su datación,
ubicación, descripción, propietarios o datos históricos entre otros. Uno de estos puntos imprescindibles es el estudio del
estado de conservación, instrumento que sirve para valorar las carencias y posibles actuaciones a llevar a cabo para su
preservación, incluso, en último término, si fuese necesario una restauración del elemento en cuestión.
El elemento ya conocido, estudiado y estable en su estado de conservación, debe darse a conocer a la sociedad actual.
Su difusión pasa por ser primordial en el proceso de concienciación y sensibilización hacia el patrimonio industrial,
como instrumento para comprender y reflexionar sobre el desarrollo de nuestras comunidades. Estos elementos sirven
como testimonio del pasado y constituyen una huella histórica que refleja las formas de vida y desarrollo acontecidas,
confluyendo en lo que hoy en día somos. Esta situación evidencia la necesidad de algún tipo de protección legal que
salvaguarde los elementos. Así, con el bien amparado por las normativas y la concienciación social, se contribuye a
emprender actuaciones orientadas a crear recursos de desarrollo y dinamización que den oportunidades de todo tipo a la
zona (económicas, sociales…).
Desde hace unos años, Aragón ha empezado a mostrar una preocupación por el conocimiento de su patrimonio
industrial, siguiendo la dinámica iniciada, hace ya unas décadas, en el resto del país. Esto se ha traducido en la
publicación de estudios parciales relacionados con las diversas facetas del patrimonio industrial aragonés y, lo que es
más destacado, en la elaboración del catálogo del patrimonio industrial aragonés y de la obra pública. En el año 2004,
el Gobierno de Aragón se implicó en el conocimiento del Patrimonio Industrial y de la Obra Pública de Aragón. Para
ello, encargó a la doctora Mª Pilar Biel Ibáñez, como especialista en arqueología industrial aragonesa y miembro del
Departamento de Historia del Arte, la redacción del Proyecto titulado: Catalogación del Patrimonio Industrial y de la
Obra Pública de Aragón.
El equipo de investigación, que finalmente asumió este trabajo, está organizado en torno a tres grupos de trabajo,
dedicado cada uno de ellos a las respectivas provincias aragonesas. Cada grupo está integrado por dos historiadores del
arte de Tercer Ciclo especializados que llevan a cabo las labores de trabajo de campo, el inventario y catalogación de
los bienes industriales, muebles e inmuebles y de obra pública; y a su vez, cada grupo está supervisado por un
coordinador con el cual se tratan los diferentes temas abordados en periódicas reuniones.
El acometer este proyecto desde la disciplina de la Historia del Arte se fundamenta en la diversa formación que se
adquiere durante la licenciatura. Desde el estudio de la Historia de la Arquitectura y la estética, que permite la precisa
descripción y valoración de los elementos; la preparación en el uso de las diversas fuentes a las que acudir para ampliar
la identificación, información y contextualización de los bienes; los conocimientos en la elaboración de catálogos e
inventarios; y finalmente, la disponibilidad de recursos para la gestión y difusión del patrimonio cultural.
El proyecto tiene como objetivo fundamental el inventario del patrimonio industrial aragonés y de la obra pública.
Dentro del patrimonio industrial, se incluyen tanto los bienes inmuebles –fábricas, molinos, lavaderos o minas– como
los bienes muebles, es decir cualquier elemento que pueda moverse, como en el caso de la maquinaria. A su vez, un
segundo bloque lo engrosaría la obra pública, compuesta por los ferrocarriles, puentes e infraestructura industrial en
general.
La contextualización cronológica de los elementos se sitúa hasta mediados de los años setenta del siglo XX –con
excepciones respecto a elementos de gran relevancia social–, sin partir de una fecha concreta de inicio debido a la
multitud de tipologías y actividades que nuestro territorio abarca.
El Gobierno de Aragón, en concreto la Dirección General de Patrimonio Cultural, es quien toma la iniciativa y financia
esta investigación. Aunque tanto desde la dirección política del proyecto como desde la científica, se considera que en
el mismo se debe implicar a las comarcas y Diputaciones Provinciales, con el fin de lograr un proyecto común a toda la
comunidad autónoma, que aúne intereses y criterios científicos para lograr un resultado de alto nivel accesible a toda la
sociedad. A su vez, se cuenta con ayudas por parte de la Universidad de Zaragoza para la compra de material y
tecnología (ordenadores portátiles, cámaras fotográficas digitales y sistemas localizadores satelitales-GPS-) que
facilitan y perfeccionan el trabajo, pudiéndose lograr así un resultado a la altura que exige cualquier estudio de primer
nivel.
Se ha definido un esquema general de trabajo que se apoya en los recursos aportados por las Infraestructuras de Datos
Espaciales. Este esquema general necesita de una adaptación al contexto específico de aplicación, que en este caso es la
elaboración del Inventario del Patrimonio Industrial y Obra Pública de Aragón. Este esquema general se estructura en
tres fases: etapa previa, aplicación del proceso, y cierre del proyecto.
Etapa previa
Con anterioridad a la ejecución de las labores de campo propiamente dichas, es necesario abordar una etapa previa que
trate de identificar las necesidades concretas del proyecto que se está planteando. Para ello, se proponen cuatro sub-
actividades:
• Definición y objetivos del trabajo a realizar. Dentro de un proyecto específico es necesario definir los objetivos
globales del proyecto (con el fin de ayudar a contextualizar todo el trabajo que se realice), así como los
objetivos específicos del trabajo en el marco de las IDEs. Tal y como se ha indicado, el proyecto “Catálogo-
inventario del Patrimonio Industrial y Obra Pública en Aragón” tiene como objetivo fundamental el inventario
del patrimonio industrial aragonés y de la obra pública. Dentro del patrimonio industrial, se incluyen tanto los
bienes inmuebles –fábricas, molinos, lavaderos o minas– como los bienes muebles, es decir cualquier elemento
que pueda moverse, como en el caso de la maquinaria. A su vez, un segundo bloque lo engrosaría la obra
pública, compuesta por los ferrocarriles, puentes e infraestructura industrial en general. Dentro de este
proyecto, el trabajo que nos preocupa tiene dos objetivos. De una parte se trata de facilitar la labor sobre el
terreno de los especialistas en Patrimonio con el fin de agilizar el trabajo de localización de los bienes a
inventariar. Por otro lado, se trata de volcar la información recopilada sobre un sistema de información que se
ajuste a los modelos y parámetros fijados para las Infraestructuras de Datos Espaciales.
• Ajuste del proceso al proyecto. Dentro de un proyecto en concreto, será necesario proceder a ajustes
específicos vinculados a las características especiales del trabajo a realizar. Para ello será necesario revisar la
documentación existente relativa al proyecto y su adecuación al problema específico a resolver, y determinar
las herramientas a usar y si es necesario dotarse de alguna nueva. En el caso del proyecto que nos ocupa, el
factor determinante de los ajustes lo ha constituido la estructuración comarcal del trabajo. Este hecho ha
marcado las pautas a seguir dentro del necesario acoplamiento del proceso.
• Creación de una infraestructura soporte para el trabajo a realizar. Es necesario establecer toda una serie de
infraestructuras técnicas que sean capaces de dar soporte al trabajo que se va a llevar a cabo. Esto incluye
directorios, copias de seguridad, almacenes de datos, gestión de configuraciones, política de nombrado, etc.
• Formación. Resulta imprescindible estudiar el perfil del personal que va a operar con las herramientas que se
han identificado como necesarias. A partir de este estudio, se establece un plan de formación en herramientas y
procesos. Este plan se implementa mediante la explicación con manuales de las herramientas a utilizar y
realización de ejercicios prácticos. En la medida de lo posible estos ejercicios se llevarán a cabo sobre
contextos conocidos. Por ejemplo, a la hora de familiarizarse con el visualizador y el nomenclátor se trabajará
sobre una comarca ya inventariada, a la hora de practicar con el GPS se realizará sobre una zona geográfica
conocida y cercana.
Esta sección recoge el esquema de las actividades a realizar por parte del personal encargado de llevar a cabo el trabajo
de campo. Se trata de implementar los ajustes al proceso presentados en la etapa anterior. Para el caso del Inventario del
Patrimonio Industrial el esquema es el siguiente:
• Preparación del trabajo de campo. El objetivo de las tareas a realizar aquí es preparar el material e
informaciones que ayuden a una eficiente realización del trabajo de campo. Actividades a realizar:
o Ubicación de la zona de campo. Esta actividad tiene como finalidad recopilar información y
herramientas que faciliten la logística y el trabajo en la zona de campo. Se trataría de dotarse de
mapas de situación, mapas de recursos (hoteles, restaurantes, servicios médicos, etc) y planos guía. El
El proceso que aquí se presenta debe evolucionar al objeto de recopilar las experiencias en su aplicación. Es por ello,
que el mismo proceso propone una labor de realimentación al cierre del proyecto con los siguientes objetivos: Estudio
de los resultados y análisis crítico, Identificación de problemas surgidos durante el trabajo de campo para realimentar el
proceso de trabajo, y Propuesta de mejoras
Un elemento novedoso que se está tratando de poner en práctica en este proyecto es la caracterización de la información
recopilada en la realización del inventario de acuerdo a las pautas y estrategias típicas en una IDE. Como primer paso se
ha considerado imprescindible la incorporación del sesgo eminentemente geográfico a toda la información que se
recopila. En este sentido, se han tomado una serie de medidas:
• Estructuración del trabajo de recopilación de la información sobre la jerarquía de unidades administrativas
determinada por Provincia (un equipo por provincia), Comarca y Municipio.
• Cada elemento del patrimonio que se incluye en el inventario se referencia a la unidad administrativa más
cercana, utilizando para ello los códigos INE.
• Como complemento a lo anterior, se ha dotado a los equipos encargados de realizar el trabajo de campo de
receptores GPS con el fin de posibilitar una mejor ubicación de los elementos patrimoniales.
• Cuando los elementos patrimoniales se encuentran fuera de un casco urbano, se hace uso del GPS para trazar la
ruta seguida que permite llegar a los mismos. El cruce de esta ruta con la información geográfica con la que se
dispone (Base Cartográfica Nacional y fotografía aérea) permite la realización de croquis de acceso a los
elementos patrimoniales.
La segunda gran medida adoptada ha sido la estructuración de la información a recopilar como un perfil de aplicación
del estándar Dublín Core espacial siguiendo el modelo presentado en [15]. Concretamente, se ha partido del “Dublin
Core Metadata Application Profile for geographical data mining” desarrollado en el marco del proyecto SDIGER
[16][17] y que se encuentra accesible a través del portal de este proyecto (http://sdiger.unizar.es). Esta información será
posteriormente volcada en sistemas de almacenamiento análogos a los utilizados para los metadatos de datos y servicios
geográficos. De este modo, la explotación de esta información podrá basarse en componentes tecnológicos muy
similares a los que ahora se están utilizando en las IDEs y, por supuesto, compatibles con estos.
A lo largo de la vida de este proyecto se han utilizado o se prevé utilizar todo un conjunto de recursos propios de una
Infraestructura de Datos Espaciales. Concretamente, se están ya utilizando los siguientes recursos:
• Servidores de mapas. Para la preparación del trabajo de campo se han utilizado los servidores de mapas que se
encuentran integrados dentro de la IDEE con el fin de tener acceso a la Base Cartográfica Nacional del IGN a
diversas escalas. Adicionalmente, se está utilizando un servidor de mapas que en estos momentos se encuentra
operativo en las instalaciones del Grupo IAAA de la Universidad de Zaragoza y que está previsto que forme
parte de la Infraestructura de Datos Espaciales de la Confederación Hidrográfica del Ebro. Este servidor
facilita el acceso a la ortoimágen en blanco y negro de 1 metro de resolución espacial que corresponde con la
primera cobertura de ortofotografía digital del SIG Oleícola Español (entregada por el Ministerio de Medio
Ambiente a la Confederación Hidrográfica del Ebro).
• Cliente de visualización. También con el fin de preparar el trabajo de campo se está utilizando el cliente de
visualización que equipa el portal de la IDEE. Sobre este cliente se cargan los datos provenientes del IGN y del
servidor de mapas de la CHE. Una vez acotadas las zonas de interés, se vuelcan los datos a ficheros de
imágenes mediante el mecanismo de captura de pantallas.
• Servicio de nomenclator el IGN. Adicionalmente se accede al servicio de nomenclator que ofrece la IDEE con
el fin de realizar búsquedas de posibles elementos susceptibles de ser inventariados y que se encuentran ya
recopilados por este servicio (minas, puentes, embalses, …).
• Aplicación de creción de metadatos (CatMDEdit). Tal y como se ha indicado en el apartado anterior, la base de
la recopilación de la información se base en el concepto de metadatos, y en la creación de perfiles de
aplicación a partir del estándar Dublín Core. Una de las características de la aplicación CatMDEdit es su
versatilidad para editar este tipo de perfiles. Es por ello que está es la herramienta que se ha convertido en la
aplicación de creación de contenidos de este proyecto.
De igual modo, se baraja la posibilidad de hacer uso de los siguientes recursos con el fin que se detalla.
• Servidor de mapas. La información recopilada puede vincularse a puntos específicos del terreno. Esto permite
la elaboración de coberturas de información que pueden ser cargadas en un servidor de mapas al objeto de ser
visualizadas en conjunción con otras y posiblemente dentro del contexto de un nodo temático dentro de la
IDEE.
• Servidor de features. Los propios elementos del patrimonio pueden caracterizarse como features a partir de la
información que los describe y ser ofrecidos mediante un servidor específico. El acceso a la descarga de esta
información posibilitaría la realización de trabajos de análisis de la información utilizando criterios
geográficos, e incluso mediante el uso de SIG complejos capaces de cruzar variables de muy distinta
naturaleza.
• Servicio de nomenclator. Partiendo de los datos recopilados en el servidor de features anterior, sería posible su
adaptación al Modelo de Nomenclator Español con el fin de permitir su oferta a través del Nomenclator
Nacional de España.
• Servicio de búsqueda en catálogos. Finalmente, y dentro de la perspectiva de crear un nodo temático, seria
posible hacer uso de la actual tecnología con la que se cuenta para la búsqueda de metadatos de datos y
servicios geográficos para facilitar la localización de los elementos del patrimonio, sus fotografías y las rutas y
croquis de acceso a los mismos.
CONCLUSIONES
Este trabajo ha tratado de mostrar un doble punto de vista en la realización de un trabajo como el Inventario del
Patrimonio Industrial de Aragón desde la perspectiva de las Infraestructuras de Datos Espaciales. De una parte se ha
presentado el uso de herramientas proporcionadas por las IDEs para facilitar el trabajo de inventariado. En este sentido
la experiencia ha resultado muy positiva. La primera Comarca sobre la que trabajó cada uno de los equipo fue
inventariada sin al ayuda de las herramientas mencionadas. Frente a esta experiencia, el trabajo sobre el resto de
comarcas ha resultado claramente más eficaz y eficiente. De hecho, las herramientas de las IDEs han permitido
complementar el trabajo sobre la primera Comarca con el fin de dar un mayor nivel de calidad y detalle a la información
recopilada, al margen de permitir descubrir algún elemento que no había sido identificado.
La segunda aportación de este trabajo ha consistido en mostrar las vías para la estructuración de información sobre la
base de una perspectiva IDE y las posibilidades que este planteamiento ofrece. Una información organizada y
gestionada con este planteamiento posibilita no solo las labores clásicas de análisis de la misma, sino que abre la puerta
a nuevas perspectivas de utilización como puede ser el desarrollo de nodos temáticos de una IDE y la oferta de recursos
de estos nodos a ámbitos variados como pueden ser turismo, cultura en general o, incluso, administración electrónica
(estos elementos patrimoniales pueden estar sujetos a figuras de protección que deban ser tenida en cuanta a la hora de
llevar a cabo obras que afecten a los mismos, o incluso, a la recepción de ayudas públicas para su conservación).
AGRADECIMIENTOS
La tecnología de base de este proyecto ha estado parcialmente financiada 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. Hudson, K, Industrial Archaelogy. A new introduction. Londres, John Baker, 1976 Citado en LOPEZ GARCIA, Mercedes, MZA
Historia de sus estaciones. (col. Ciencias, Humanidades e Ingeniería, 22), Madrid, Ed. Turner, 1984.
2. Buchanan, Angus, The definition of industrial archeology. París, 1985. En FORNER MUÑOZ, Salvador, “Arqueología y
patrimonio industrial.” Rev. Canelobre, 1989, nº 16, Alicante, Instituto de Cultura Juan Gil Albert, 1989, p. 26.
3. Aguilar Civera, Inmaculada, Arquitectura industrial. Concepto, método y fuentes (col. Arqueología industrial, 1), Valencia,
Diputación, 1998.
4. Benito Del Pozo, Paz, “Patrimonio industrial y cultura del territorio”, Boletín de la A.G.E., nº 34, 2002, pp. 213-227.
5. Gállego Domínguez, Olga, “Los archivos de empresa”, Rev. Abaco, nº 1, 1992, pp. 29-56.
6. Cruz Mundet, José Ramón, “Archivo y empresa: más allá de la historia”, Rev. de Historia. Transportes, servicios y
telecomunicaciones, nº 1, pp.187-206.
7. Alonso Ibáñez, María del Rosario, “El régimen jurídico de la arqueología industrial”, Rev. Abvaco, nº 1, 1992, pp. 67-70;
8. Alonso Ibáñez, María del Rosario, “Aspectos normativos del patrimonio industrial”, en VV.AA:, Patrimonio industrial: lugares de
la memoria, Gijón, Incuna, 2002, pp. 109-127.
9. Bardón Agnès, “Una memoria oxidada”, Rev. Fuentes, nº 131, UNESCO, 2001, (www.fuentesunesco,org).
10. Santacreu Soler, J.M., “Una visión global de la arqueología industrial en Europa. Casos concretos en regiones concretas”, Rev.
Ábaco, nº 1, 1992, pp. 13-28
11. Benito, Carmen, “Los vestigios industriales: estudio, conservación y uso”, Estudios Humanísticos, nº León, 1996, pp. 275-289
12. Benito Del Pozo, Paz, “Patrimonio industrial y cultura del territorio”, Boletín de la A.G.E., nº 34, 2002, p. 220.
13. García Braña. Celestino, Landrove Susana, Tostoes, Ana, (dir.), La arquitectura de la industria. Registro DOCOMOMO Ibérico,
1925-1965, Fundación DOCOMOMO Ibérico, Barcelona 2004.
14. Linajeros y otros, “El plan nacional de patrimonio industrial” en VV.AA., Patrimonio industrial: lugares de la memoria, Gijón,
Incuna, 2002, pp. 43-51.
15. Portolés-Rodríguez D, Tolosana-Calasanz R, Nogueras-Iso J, Rioja R, Muro-Medrano PR, Zarazaga-Soria FJ. “A hierarchical
one-to-one mapping solution for semantic interoperability”. Proceedings of the International Conference on Dublin Core and
Metadata Applications, Madrid, Spain. October 2.005
16. Nogueras-Iso J, Latre M.A., Béjar R., Muro-Medrano P.R., Zarazaga-Soria F.J.. “SDIGER: Experiencias e Identificación de
Problemas en la Creación de una IDE Transnacional” Actas de Jornadas Técnicas de la Infraestructura de Datos Espaciales de
España (JIDEE’05). Madrid, Spain, 24-25 Noviembre 2005
17. Latre M.A., Zarazaga-Soria F.J., Nogueras-Iso J., Béjar R., Muro-Medrano P.R. “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. pp 5 – 7. Alghero, Sardinia (Italia), Junio 2005
Carlos Granell
Michael Gould
Departamento de Lenguajes y Sistemas Informáticos, Universitat Jaume I (Castellón), {carlos.granell, gould}@uji.es
Resumen: Presentamos una metodología para la creación de servicios integrados de información espacial mediante el
encadenamiento de servicios web, asegurándonos que en todo momento nuestra propuesta es conforme a la
recomendación europea INSPIRE en términos de interoperabilidad e integración. El modelo propuesto de
encadenamiento de servicios gira en torno al concepto de componente integrado, visto como una pieza básica de
reutilización, y en una metodología para la creación, composición, reutilización y transformación de tales componentes
integrados en procesos ejecutables para las aplicaciones de usuario. Finalmente, demostramos la viabilidad del
modelo propuesto en un escenario real relacionado con la creación de sistemas ad hoc de información geoespacial en
caso de situaciones de emergencia.
INTRODUCCIÓN
Las Infraestructuras de Datos Espaciales (IDE) engloban políticas, acuerdos institucionales, bases datos espaciales,
servicios sobre estos datos, y tecnologías que facilitan la disponibilidad y el acceso a los servicios y a los datos [7]. Esta
definición está ampliamente aceptada pero todavía está centrada en el intercambio y acceso a los datos y servicios de
tipo geoespacial y los que siguen ciertas especificaciones OGC. Avanzando un paso más allá, en [2] los autores se
preguntan cuales serán los siguientes retos relativos a la investigación de IDEs. Existen diversos problemas aún por
resolver (como por ejemplo la interoperabilidad semántica) pero nosotros nos centraremos en cómo es posible la
encadenación de diferentes servicios de información geográfica que soporten tareas complejas y específicas, con otros
servicios relacionados pero no servicios OGC per se. De cara al usuario, la encadenación de servicios resulta interesante
porque no solo permite acceder a los datos geoespaciales disponibles por los servicios primarios (geoportales) sino que
permite la encadenación ad hoc de servicios simples disponibles para formar nuevos servicios compuestos. De esta
forma, la clásica definición de IDE como facilitador de datos geoespaciales se convierte en una visión mucho más
amplia, proporcionando geo-servicios (o servicios en general) que envuelven explícita o implícitamente datos
geoespaciales [1]. Esta nueva visión implica que las IDEs necesitan apoyarse mucho más en la funcionalidad de los
servicios que en los propios datos geoespaciales, ya que la clave reside en la combinación de funcionalidades ofrecidas
por diferentes servicios que acceden a su vez a sus respectivos datos geoespaciales.
Recientemente se está prestando mucha atención a la iniciativa europea para el desarrollo de una Infraestructura de
Datos Espaciales en Europa (INSPIRE) [6], debido en gran parte a su adopción (en primera instancia) por parte del
Parlamento Europeo en junio del 2005. El objetivo que persigue INSPIRE es crear una directiva marco que guía y
instruye a los estados miembros sobre la creación de infraestructuras de información espacial a nivel nacional y local
que proporcione a usuarios finales (ya sea administración, empresas, otras organizaciones, así como a ciudadanos)
servicios integrados de información geoespacial. Es interesante destacar este último concepto de servicios integrados
que aparece en los borradores de INSPIRE. Los usuarios finales buscan servicios que se adapten a sus requisitos.
Normalmente, no existe un único servicio que satisface completamente sus demandas, sino que servicios individuales
satisfacen distintos aspectos de los requisitos del usuario. La idea, pues, consiste en proporcionar al usuario una cadena
de servicios formada por la composición de otros servicios más simples o genéricos. Solo que dicha cadena de servicios
debe ser finalmente entregada al usuario con la apariencia de un solo servicio integrado de información geoespacial (un
servicio opaco según la terminología de la norma ISO 19119). Podríamos equiparar entonces la cadena de servicios
resultante por la composición de servicios geoespaciales con el servicio integrado de información espacial propuesto
por la recomendación de INSPIRE.
Ya existen diversos trabajos en el área de los servicios web aplicados al contexto geográfico que revelan la importancia
de este campo en el desarrollo y evolución de las IDEs. El Open Geospatial Consortium (OGC) ha dedicado varias
iniciativas consecutivas para abordar y promover la especificación de los clásicos servicios OpenGIS (WMS, WFS,
WCS, etc.) según la arquitectura de servicios web (www.w3.org/2002/ws/arch/). La iniciativa más reciente, OGC Web
Services Phase 3 (OWS-3, www.opengeospatial.org/initiatives/?iid=162), está encargada de la definición de una
arquitectura que permita la integración e interoperabilidad de diferentes servicios OGC (sensores, LBS) descritos o
expuestos como servicios web. También el OGC está impulsando diversos experimentos en el marco de los servicios de
geo-procesamiento como el experimento Web Process Service Interoperability Experiment (WPS IE,
www.opengeospatial.org/initiatives/?iid=148), llevado a cabo para testear la viabilidad de las especificaciones de
interfaces OWS para permitir servicios de geo-procesamiento a través de Internet.
Por otra parte, en el área de encadenación de servicios, la Agencia Espacial Europea (ESA, www.esa.int) está
desarrollando un ambicioso proyecto denominado Service Support Environment [3] que proporciona una arquitectura
para la integración de servicios tanto de la Observación de la Tierra como de SIG proporcionados por diferentes
partners distribuidos en nueve países europeos. Las composiciones de servicios resultantes son transformadas en
procesos WS-BPEL [10]. En el OGC también se han finalizado recientemente los primeros experimentos encadenando
diversos WCS mediante el uso de los lenguajes WSDL y WS-BPEL (véase el documento OGC 04-078, OWS 2 Image
Handling for Decision Support: Service Chaining with BPEL 1.0). Parece lógico pensar que uno de los pilares básicos
para el avance de las IDEs y, en definitiva, de INSPIRE, resida en la capacidad de ofrecer nuevos servicios
encadenando otros ya existentes.
En este artículo presentamos un modelo para la creación de servicios integrados de información espacial mediante el
encadenamiento de servicios web, asegurándonos que en todo momento nuestra propuesta es conforme a la
recomendación europea INSPIRE [6], por lo menos a los borradores disponibles hasta el momento. Para eso, antes de
introducirnos en nuestro modelo, en la siguiente sección definimos el papel de nuestro modelo (y en general la
encadenación de servicios) dentro del contexto de INSPIRE. El resto del artículo presenta nuestro modelo de
encadenamiento de servicios basado principalmente en el concepto de componentes integrados y en una metodología
para gestionar dichos componentes integrados. Luego mostraremos cómo encadenar servicios mediante componentes
integrados en un escenario de gestión de emergencias, demostrando que la salida de nuestra propuesta se ajusta
perfectamente al servicio integrado de información espacial enunciado por INSPIRE. Finalmente, terminaremos con
conclusiones acerca de la composición de servicios para el desarrollo de una IDE junto con nuestro plan de trabajo para
el futuro inmediato.
Uno de los principales retos de INSPIRE se centra en la interoperabilidad de servicios para la documentación,
publicación, descubrimiento y consumición de información geográfica tanto a nivel europeo, nacional, regional y local.
La Figura 1 muestra la arquitectura de referencia (conceptual) de INSPIRE para permitir la interoperabilidad entre estos
servicios [8]. Básicamente, esta arquitectura está compuesta de cuatro componentes bien diferenciados. Las
aplicaciones de usuario (o cliente) que consumen tanto datos como servicios geográficos. Típicamente, los datos
geográficos están almacenados en repositorios cuyos metadatos son publicados en catálogos para que puedan ser
buscados tanto por las aplicaciones de usuario como por los servicios. La pieza central de la Figura 1 que une
aplicaciones de usuario, catálogos y repositorios representan los servicios (middleware, de trasformaciones, de
geoprocesamiento, etc.). Los servicios permiten, por ejemplo, que las aplicaciones de usuario accedan a servicios de
búsqueda de catálogo o bien que los datos contenidos en los repositorios sean procesados antes de ser consumidos por la
aplicación usuario.
Sin embargo, los catálogos no mantienen únicamente metadatos de los datos geoespaciales sino también de los servicios
disponibles. De esta forma, ante peticiones complejas de las aplicaciones de usuario, los servicios de búsqueda
recuperan otros servicios más simples que, encadenados, ofrecen los requisitos demandados. Nuestro trabajo se centra
justo en el aspecto de la encadenación de servicios, operación ya contemplada en la Figura 1, en la sección de
middleware. La idea consiste en ofrecer un modelo para componer servicios existentes basados en los principios de
simplicidad, reutilización y flexibilidad. La reutilización es un objetivo prioritario en nuestro modelo y, en cierta
manera, se corresponde con la flecha “metadata update” que aparece en la Figura 1. Por ejemplo, a existencia de
servicios A y B será documentada en los metadatos de un registro o catálogo de servicios, pero en caso de crear un
macro-servicio C, resultado de encadenar a A y B, también los metadatos del nuevo servicio serán enviados al catalogo.
Nuevos servicios compuestos quedan almacenados en el catálogo para que sean reutilizadas en peticiones posteriores.
En definitiva, como presentamos en la siguiente sección, nuestro modelo genera cadenas de servicios reutilizando otras
ya existentes. Como se comentaba en la introducción, la reutilización de servicios es esencial ya que permite tanto la
encadenación de servicios sin tener que empezar desde servicios básicos cada vez, así como también disponer de
conocimiento previo sobre cadenas de servicios existentes aplicadas a problemas similares.
El objetivo en esta sección es introducir nuestro modelo basado en componentes integrados que soporta la reutilización
y composición de servicios. En primer lugar daremos una visión general de la arquitectura del modelo, sus principales
componentes y las entradas y salidas, para luego describir el concepto de componente integrado y la metodología de
composición propuesta.
Arquitectura
El modelo propuesto hereda directamente ciertas características de la ingeniería del software basada en componentes
según la definición de Syzperski [9]. Este tipo de sistemas se caracteriza por tener bien definido un modelo de
componente y una metodología de composición. El modelo de componente define cómo deben ser descritos los
componentes para mejorar su reutilización. La metodología de composición describe los mecanismos utilizados para
combinar tales componentes. Así pues, en nuestro modelo, el modelo de componente se corresponde con el concepto de
componente integrado y la metodología de composición con la metodología de composición de servicios.
La Figura 2 muestra las relaciones entre la metodología propuesta y los componentes integrados con respecto a las
entradas y salidas de nuestro modelo. Los servicios web existentes y las ontologías de dominio forman las entradas de
nuestro modelo. En este momento vale la pena comentar ciertas restricciones asumidas en este trabajo respecto a las
ontologías. Nos basamos en ontologías dominio, generalmente definidas por expertos, en el contexto geográfico con el
objetivo de anotar semánticamente ciertos aspectos de un componente integrado. La idea es experimentar el uso de la
semántica en la descripción y composición de servicios de un modo gradual, proporcionando una herramienta
complementaria que ayude al usuario en el proceso de composición. En este trabajo, la semántica es un aspecto
minoritario ya que el proceso de composición expuesto en las siguientes secciones sigue siendo dirigido
fundamentalmente por la “semántica” del usuario. Pues bien, volviendo a la Figura 2, los componentes integrados son
creados y combinados por medio de los diferentes procesos que forman la metodología de composición de servicios.
Así, el primer proceso consiste en crear componentes integrados a partir de los servicios web y las ontologías. Estos
componentes integrados son almacenados en un catálogo para su posterior reutilización. El modo de crear servicios de
cierta complejidad es combinando dichos componentes integrados produciendo gradualmente otros nuevos. Los nuevos
componentes integrados resultado de la composición son igualmente registrados en el repositorio para su futuro uso.
Finalmente, cuando se desea disponer de un proceso ejecutable el correspondiente componente integrado es
transformado en un documento WS-BPEL [10], la salida de nuestro modelo, listo para ser ejecutados por un motor de
ejecución de procesos WS-BPEL.
Componentes integrados
Un componente integrado se define como un servicio que adopta algunos atributos y aspectos de la tecnología de
componentes, proporcionando una pieza autónoma de código, reutilizable e independiente, junto con la utilización de
los patrones de workflow que indican cómo deben combinarse los componentes integrados contenidos en cierta
composición. El resultado de combinar componentes integrados se considera un nuevo componente integrado. Para
conseguir este comportamiento es necesario que los componentes integrados sean unidades independientes, reutilizables
y ofreciendo cierta encapsulación sobre detalles de su estructura. Nuestra estrategia consiste en capturar mediante
descripciones abstractas todos los aspectos relevantes que definen a un componente integrado. Por lo tanto, en el diseño
de un componente integrado consideramos los siguientes aspectos clave que nos ayudarán a perfilar la estructura de un
componente integrado:
Estos aspectos son encapsulados en un componente integrado combinado mediante dos interfaces funcionales. La
interfaz pública expresa al mundo exterior los aspectos descriptivos y funcionales del servicio. La interfaz privada
representa una vista interna del componente integrado encapsulando las características estructurales como el flujo de
control y de datos así como las transformaciones necesarias para los aspectos de enlaces. De esta forma, el acceso a un
componente integrado es controlado por la interfaz pública, proporcionando la necesaria encapsulación para permitir
componentes integrados reutilizables e independientes de la composición en la que están contenidos.
La creación, composición y transformación de componentes integrados es realizada por los tres procesos que integran la
metodología de composición de servicios. El Proceso de Abstracción de Servicios (PAS) está encargado de la creación
de componentes integrados; el Proceso de Composición de Servicios (PCS) combina (y reutiliza) componentes
integrados existentes para crear otros nuevos con la funcionalidad requerida; el Proceso de Transformación de Servicios
(PTS) transforma las descripciones de los componentes integrados en procesos ejecutables. La Figura 3 ilustra el ciclo
de vida de los componentes integrados, descrito en más detalle en las siguientes secciones. La descripción completa de
los tres procesos que componen la metodología de composición de servicios puede encontrarse en [4, 5].
El proceso PAS (parte izquierda de la Figura 3) consiste en crear componentes integrados a partir de servicios web ya
existentes en el catálogo. Para este proceso suponemos que no existe ya un componente integrado con la funcionalidad
requerida por el usuario. Si no es así, evidentemente, se debe reutilizar dicho componente integrado en cuestión. La
Figura 3 muestra los dos pasos (1-2) necesarios para la creación de componentes integrados.
El proceso de abstracción, marcado como 1 en la Figura 3, permite especificar los aspectos que describen a un
componente integrado: descriptivos, funcionales, estructurales y de enlace. En este momento se describe la
funcionalidad del componente (aspectos funcionales) y los patrones de selección1 utilizados (aspectos estructurales).
Una vez definido el nuevo componente integrado, el siguiente paso (2, Figura 3) actualiza el catálogo para que el nuevo
componente éste disponible para ser reutilizado. Aunque se trate de un paso sencillo, es de vital importancia para
maximizar la reutilización del modelo. Volviendo a la arquitectura de referencia mostrada en la Figura 1, el registro del
componente integrado se corresponde con la acción de “metadata update”, ilustrando como los propios servicios
actualizan el catálogo con sus metadatos. En nuestro caso, ya que los componentes integrados tienen realmente la
interfaz de un servicio web, la descripción WSDL del componente integrado (que se corresponde con su interfaz
pública) son los metadatos que se publican en el catálogo de servicios.
El PCS, representado por el ciclo 3-4-5 en la Figura 3, es el encargado de construir aplicaciones complejas como
componentes integrados, resultado de gradualmente agregar y reutilizar otros componentes integrados ya disponibles en
el repositorio. Esto nos proporciona un nivel añadido de simplicidad, independencia y reutilización durante el proceso
de composición necesario con el fin de obtener una respuesta favorable a la pregunta: ¿es posible maximizar el nivel de
reutilización de composiciones de servicios ya existentes?.
Al igual que el proceso de abstracción (1, Figura 3), el proceso de composición (4, Figura 3) crea nuevos componentes
integrados a partir de otros ya existentes definiendo sus aspectos básicos (descriptivos, funcionales, estructurales, y de
enlace). Esta vez, los componentes integrados que van a formar parte de la composición son recuperados del catálogo
(3, Figura 3), siendo reutilizados en la nueva composición. Como antes, el nuevo componente integrado es publicado en
el catálogo como un nuevo componente listo para ser reutilizado (5, Figura 3).
Una vez creado el componente integrado siguiendo los dos procesos anteriores, utilizamos el proceso PTS para
transformar la descripción de dicho componente integrado en un lenguaje de procesos ejecutable. Concretamente, en
nuestro modelo hemos optado por el lenguaje WS-BPEL [10] por disponer de múltiples motores de ejecución.
El proceso de transformación se corresponde con los pasos 6-7-8 de la Figura 3. En primer lugar, el componente
integrado que va a ser ejecutado es seleccionado del catálogo (6, Figura 3). Una vez seleccionado, se lleva a cabo el
proceso de transformación propiamente dicho. Todos los componentes integrados que forman parte de la composición
seleccionada son transformados a un único proceso WS-BPEL, que finalmente puede ser ejecutado por el motor de
ejecución correspondiente (8, Figura 3).
1
En [5] se analiza la distinción entre patrones de selección y de composición dentro de nuestro modelo. Básicamente, los patrones de
selección son utilizados durante el proceso PAS mientras que los de composición durante el proceso PCS.
La demostración de nuestro modelo consiste en un escenario relacionado con la mitigación de desastres frente a
situaciones de emergencia. Con este escenario ya estamos familiarizados ya que se trata de uno de los pilotos
desarrollados durante el proyecto europeo ACE-GIS (www.acegis.net). Suponemos pues, que se produce un escape de
gas tóxico en una planta química en los alrededores de un área poblada. Es evidente que los responsables de gestionar la
seguridad ciudadana activen planes de emergencias para evacuar dicha área si fuera necesario, con el fin de ofrecer una
respuesta lo más rápida posible al desastre ocurrido.
Antes de dar luz verde al plan de evacuación, los responsables de la seguridad deben cerciorarse si, definitivamente, la
nube de gas tóxica se dirige hacia la zona urbana. Deciden entonces monitorizar la nube de gas tóxica cada cierto
tiempo para verificar su tamaño y localización exacta. Tras una breve discusión, se propone poner en marcha un
servicio compuesto que monitorice la nube de gas tóxica, servicio de monitorización, el cual tomará como entrada el
nombre de la planta química y devolverá un mapa del área afectada mostrando la situación y tamaño actual de la nube
de gas tóxica. La cadena de servicios que forma el servicio de monitorización es la siguiente. En primer lugar utilizan
un servicio de gazetteer que toma como entrada un topónimo o nombre de lugar (como el nombre de nuestra planta
química) y devuelve sus coordenadas geográficas (latitud/longitud). El siguiente paso consiste en recuperar las
condiciones meteorológicas en dicha localización. Tanto la dirección como velocidad del viento son parámetros
necesarios para el cálculo de la nube de gas tóxica. Como es habitual, no se encuentran estaciones meteorológicas en
cada localización terrestre y deciden entonces utilizar un servicio de proximidad para localizar el aeropuerto más
cercano a la planta química (todos los aeropuertos disponen de estación meteorológica). Así, el servicio aeropuerto más
cercano devuelve el código de dicho aeropuerto dada una determinada localización, en nuestro caso la localización de
la planta química. Con el código de aeropuerto ya pueden interrogar el servicio meteorológico para obtener los
parámetros de viento necesarios. El equipo de responsables ya tiene todos los datos necesarios (localización, dirección y
velocidad del viento, y la densidad del gas) para invocar el servicio calcula dispersión nube de gas que devuelve un
polígono representando la nube de gas tóxico (de hecho este servicio envuelve a un WFS). El último paso consiste en
superponer el polígono sobre un mapa centrado en el área del desastre utilizando para ello un WMS. En la figura 4
aparece representada la descripción lógica de la cadena de servicios que forma el servicio monitorización mediante las
flechas discontinuas en negro que unen los componentes integrados del nivel inferior (CI gazetteer, CI proximidad, CI
meteorológico, CI calcula dispersión nube de gas, y CI visualiza mapa).
Pues bien, ¿cómo se diseña el servicio de monitorización mediante el modelo de componente integrados?. El primer
paso consiste en la creación de los correspondientes componentes integrados a partir de los servicios web disponibles en
el catálogo. Este paso consiste en aplicar el Proceso de Abstracción de Servicios (PAS). La parte inferior de la Figura 4
muestra los servicios web disponibles. Por ejemplo, para crear el correspondiente gazetteer como componente integrado
podemos hacer uso de dos servicios ya disponibles como el ADL gazetteer (Alexandria Digital Library gazetteer,
www.alexandria.ucsb.edu/gazetteer/) y el servicio Place Finder proporcionado por ESRI
(arcweb.esri.com/arcwebonline/). En este momento vale la pena señalar que aunque nuestro objetivo es potenciar la
integración de servicios OGC dentro de una IDE, el servicio OGC gazetteer (véase el documento OGC 05-035
Gazetteer Profile of the Web Feature Service Implementation Specification) todavía se encuentra en discusión y, hasta
nuestro conocimiento, no conocemos de ninguna implementación realmente funcionando2. Tanto ADL gazetteer como
Place Finder no son servicios OGC. Sin embargo este hecho demuestra que nuestro modelo es independiente del
contexto, siendo lo bastante general para ser aplicado a distintos contextos.
Volviendo a nuestro escenario, el componente integrado gazetteer consiste de hecho en dos servicios modelados
mediante el patrón de selección AND-DISC [5]: ADL gazetteer y Place Finder. Tal como se ha comentado
anteriormente, durante el proceso de abstracción y composición se utilizan patrones de selección y composición para
definir los atributos estructurales de un componente integrado. El patrón de selección AND-DISC es uno de los
patrones disponibles. La utilización del patrón de selección AND-DISC para el componente integrado gazetteer, que
contiene dos servicios concretos (ADL gazetteer y Place Finder), no significa que en tiempo de ejecución los resultados
de ambos gazetteer serán considerados, sino que el primer resultado obtenido será tenido en cuenta en el flujo de datos
de la cadena. Por ejemplo, si ADL gazetteer responde antes que Place Finder, los resultados de éste último son
ignorados por el motor de ejecución. Los patrones de selección aportan gran flexibilidad al modelo ya que un
componente integrado no está ligado en tiempo de diseño a un determinado servicio web sino a un conjunto de servicios
web candidatos. El resto de componentes integrados del mismo nivel son creados del mismo modo.
El siguiente paso es componer y reutilizar, si es posible, componentes integrados. Como ilustra la figura 4, el nuevo
componente integrado Sensor de viento es una composición de los tres componentes integrados justo debajo. Los
componentes integrados gazetteer, proximidad, y meteorológico son combinados mediante el patrón de composición
secuencia (SEQ en la Figura 4). De hecho, tales componentes integrados son realmente reutilizados porque ya están
disponibles en el catálogo desde el momento en que son creados. De la misma forma, tanto sensor de viento como
superposición nube de gas son incluidos en el catálogo para que puedan ser reutilizados de nuevo, creando de este
modo el componente integrado monitorización buscado por los responsables de la seguridad en nuestro escenario. Tan
sólo queda transformar el componente integrado monitorización en un proceso WS-BPEL ejecutable mediante el
proceso PTS, para que sea finalmente interpretado y ejecutado por un motor de ejecución compatible.
CONCLUSIONES
En este artículo hemos presentado un modelo para el desarrollo de aplicaciones web para la composición y reutilización
de servicios centrado alrededor del concepto de componente integrado. El componente integrado se convierte en la
pieza básica y modelo de reutilización en otras composiciones. Para manejar y gestionar componentes integrados,
hemos presentado una metodología de composición basada en tres procesos: el Proceso de Abstracción de Servicios
para la creación de componentes integrados; el Proceso de Composición de Servicios para reutilizar componentes
integrados existentes en nuevas composiciones; y el Proceso de Traducción de Servicios para convertir las
descripciones de los componentes integrados en procesos WS-BPEL ejecutables.
Sin embargo, creemos que todavía queda un largo camino para alcanzar un nivel maduro en la encadenación de
servicios personalizados en el marco de la IDE. Varios autores [1, 2] ya han identifican la necesidad de desplazar la
visión actual de la IDE centrada en los datos a un visión mucho más amplia que abarque además servicios distribuidos
geográficamente a diferentes niveles (nacional, local, etc.) y, como último fin, la visión de un infraestructura espacial
dirigida completamente por servicios. Por lo tanto, el continuo desarrollo de soluciones innovadores para la
encadenación de servicios en el marco de la IDE e INSPIRE, acercará cada vez más la visión de una infraestructura de
servicios espaciales.
Nuestro trabajo más inmediato está siendo el testeo de nuestro modelo de componentes integrado en otros contextos
como el reciente proyecto europeo AWARE (www.aware-eu.info), aplicando nuestro modelo en el encadenamiento de
servicios para proporcionar mapas sobre previsiones de recursos hídricos en entornos de alta montaña. Además, otra de
nuestras líneas futuras sigue siendo la integración de nuestro modelo en IDEs [4] con el fin de contribuir un poco más al
desarrollo y evolución de las infraestructuras de datos y servicios espaciales en su faceta más tecnológica.
2
Existe un OGC gazetteer en http://ogc.compusult.nf.ca/OGC/gaz_get_search.html, aunque no se trata de una versión estable.
REFERENCIAS
1. Bernard, Lars; Craglia, Max (2005): SDI - From Spatial Data Infrastructure to Service Driven Infrastructure. En Proceedings of
the First Research Workshop on Cross-learning on Spatial Data Infrastructures and Information Infrastructures, Enschede (The
Netherlands). http://gi-gis.jrc.it/ws/crosslearning/papers/PP Lars Bernard - Max Craglia.pdf (último acceso: Octubre 2005)
2. Bernard, Lars; Craglia, Max; Gould, Michael; Kuhn, Werner (2005): Towards an SDI Research Agenda. Proceedings of the 11th
EC-GIS Workshop, Sardinia. http://www.ec-gis.org/Workshops/11ec-gis/presentations/07kuhn.pdf (último acceso: Octubre 2005)
3. D’Elia, Sergio; Marchetti, Pier G. (2005): Service Support Environment – Web-Services based ESA Infrastructure for Geospatial
Services. En Proceedings of the IGARSS 2005 Conference. Seoul, Korea.
4. Granell, Carlos; Gould, Michael; Ramos, Francisco (2005): Service Composition for SDIs: integrated components creation. En
Proceedings of the DEXA Workshops 2005, Copenhague (Dinamarca). IEEE CS Press, 475-479
5. Granell, Carlos; Gould, Michael; Grønmo, Roy; Skogan, David (2005): Improving Reuse of Web Service Composition. En
Proceedings of the EC-Web 2005, Copenhague (Dinamarca). Springer LNCS 3590, 358-367
6. INSPIRE Initiative. http://inspire.jrc.it (último acceso: Septiembre 2005)
7. Nebert, Doug (ed.) (2004): Developing Spatial Data Infrastructures: The SDI Cookbook. GSDI Cookbook, version 2, GSDI.
http://www.gsdi.org/docs2004/Cookbook/cookbookV2.0.pdf (último acceso: Octubre 2005)
8. Smits, Paul 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 (último acceso: Octubre 2005)
9. Szyperski, Clemens (1988): Component Software. Beyond Object-Oriented Programming. Addison-Wesley
10. WS-BPEL (2005): OASIS Web Services Business Process Execution Language 2.0 – 1 septiembre 2005, http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wspel (último acceso: Octubre 2005)
Resumen: Presentamos los primeros resultados obtenidos de una evaluación de implementaciones basadas en software
libre de los componentes IDE, centrando nuestro análisis en los servicios de visualización de mapas (Web Map
Service), de acceso y manipulación de objetos geográficos (Web Feature Service) y repositorios de información
geográfica (bases de datos e información vectorial). El objetivo es valorar de forma objetiva el estado de madurez de
algunas de las soluciones abiertas más comunes, revelando sus fortalezas y deficiencias bajo una variedad de
condiciones de número de usuarios, carga de datos, sistema operativo, licencias de uso, portabilidad, tiempos de
respuesta, etc. Estas pruebas benchmark una vez completadas se publicarán enteras como una contribución más a una
IDEE abierta y heterogénea respecto a su implementación, sin que este estudio pretenda menoscabar las soluciones
propietarias ya existentes en el mercado.
INTRODUCCIÓN
El objetivo de este trabajo es valorar de forma objetiva el estado de madurez de las soluciones open source que
implementan los distintos componentes que conforman la arquitectura de las IDEs [3], revelando sus fortalezas y
deficiencias bajo una variedad de condiciones como el número de usuarios, la carga de datos, el sistema operativo,
licencias de uso, portabilidad, tiempos de respuesta, lenguaje de programación utilizado para su implementación, etc.
Hasta la formación del Open Geospatial Consortium, debido a la limitada funcionalidad proporcionada por los SIG
tradicionales y para conseguir un nivel básico en la compatibilidad de los datos disponibles, las organizaciones con
información espacial en múltiples sistemas y formatos tenían que crear aplicaciones contra APIs propietarias. Esto
requería de un conocimiento profundo de los sistemas computacionales subyacentes, llegando al caso de tener que
desarrollar n aplicaciones para acceder y/o manipular n formatos distintos de datos. Los datos se replicaban y
transformaban continuamente según las necesidades del momento, socavando la calidad e integridad de las fuentes de
datos espaciales. Como consecuencia de todo esto, la utilización de los sistemas propietarios cerrados se habían
convertido en la forma habitual de trabajo, ocurriendo que el software desarrollado por una empresa podía o no
funcionar con otros productos propios de su línea, pero con certeza no lo haría con otra solución propietaria distinta si
no existía una relación explícita entre ambos que lo posibilitara.
A través de las Especificaciones de Implementación OpenGIS, especialmente las del conjunto OGC Web Services
(OWS) [7], y junto con el modelo de referencia de la arquitectura de las IDEs definido según la NASA [8], FGDC [9] e
INSPIRE [2], las distintas empresas y administraciones pueden dar acceso tanto a nivel global como local de forma
transparente al usuario final (ya sea administración, empresas y organizaciones tanto a nivel europeo, nacional o local,
así como a ciudadanos individuales) a servicios integrados de información espacial [1]. Esto permite la aparición de
nuevas aplicaciones interoperables con ellos a través de estas interfaces estándar, posibilitando la eliminación de la
redundancia o duplicación de datos geoespaciales y los conflictos que se dan entre las múltiples soluciones SIG
existentes en el mercado, el acceso a través de la Web a los recursos espaciales, el e-comercio y el acceso seguro a
estos. Además, en la práctica, la implementación de una especificación significa que los productos que son
conformantes a ella pueden “comunicarse inteligentemente” con otros que también lo son, lo que permite cambiar en un
momento dado uno de los componentes por otro de similares características, ya sea por motivos económicos (pago de
licencias), de funcionalidad o rendimiento.
Dentro del modelo de referencia de la arquitectura de las IDEs pueden distinguirse cuatro grupos de componentes:
aplicaciones de usuario (ej. visualización de diferentes capas de información geográfica provenientes de diferentes
fuentes o recursos de información), servicios de geo-procesamiento (ej. análisis temporal y espacial, planificación, etc.;
o el resultado de la encadenación de varios de estos servicios de geo-procesamiento [10]), servicios de catálogos (ej.
publicación y/o descubrimiento de servicios o datos geoespaciales) y repositorios de información geográfica.
La comunidad de usuarios y desarrolladores de estos componentes no se ha mostrado ajena a la corriente del software
libre, también común en otros ámbitos, y en los últimos años ha sido muy activa, desarrollando sus propias
implementaciones para conseguir la independencia tecnológica frente a las soluciones propietarias ya existentes de estos
componentes, bien sea por la necesidad de una solución de bajo coste o porque las ya existentes no se adaptan a sus
necesidades.
En este trabajo se presentan los primeros resultados obtenidos de una evaluación de implementaciones de los
componentes IDE basadas en software libre, centrando el análisis en los servicios de visualización de mapas (Web Map
Service), de acceso y manipulación de objetos geográficos (Web Feature Service) y repositorios de información
geográfica (bases de datos espaciales e información vectorial). Los resultados obtenidos a partir de este análisis
pretenden comparar cuantitativa y cualitativamente algunas de las soluciones abiertas más comunes. Estas pruebas
benchmark una vez completadas se publicarán enteras como una contribución más a una IDEE abierta y heterogénea
respecto a su implementación, sin que este estudio pretenda menoscabar las soluciones propietarias ya existentes en el
mercado.
A lo largo de la historia de la informática, el uso de pruebas en detalle o benchmarks ha sido algo muy común, de forma
que los resultados obtenidos de forma objetiva en las distintas arquitecturas mediante estas pruebas podían ser
comparados (ej. BRL-CAD, LINPACK, 3DMark, SPEC CPU2000, SPEC WEB99, etc.). En general, la realización de
pruebas comparativas no suele ser una tarea fácil y requiere de sesiones repetitivas para llegar a conclusiones útiles,
siendo también difícil la interpretación de los resultados de las pruebas. Un factor a tener en cuenta durante la
realización de las pruebas es que los vendedores suelen afinar sus productos específicamente para los benchmarks más
comúnmente utilizados en su sector, por lo que hay que tener especial precaución a la hora de interpretar los resultados.
Además, los benchmarks generalmente, a parte de las mediciones cuantitativas del rendimiento de un sistema, no suelen
tener en cuenta ninguna medición cualitativa a cerca del servicio como pueden ser la seguridad, la disponibilidad, la
confiabilidad, la escalabilidad, o el grado de conformidad con las especificaciones, las cuales son tan o más importantes
que las anteriores (ej. pruebas de conformidad de servicios WMS y WFS desarrolladas por OCCAMLAB [4] y el
proyecto ACE-GIS [5]).
Dentro del amplio espectro de pruebas de benchmarking que existen para evaluar el rendimiento de casi cualquier
componente software o hardware, hay dos campos que son de especial relevancia para el caso que nos ocupa en este
trabajo: las bases de datos y los servicios web. Dentro de los objetivos de este trabajo no se encuentra el hacer un
estudio en profundidad del rendimiento de los distintos gestores de bases de datos, ya sean libre distribución como
MySQL y PostgreSQL o propietarias como Oracle Server y Microsoft SQL Server. Pero es interesante hacer mención
de la existencia de multitud benchmarks orientados a la evaluación de estos, ya que las bases de datos, y en concreto
aquellas que disponen de extensión espacial, son comúnmente utilizadas como repositorios para el manejo y acceso a la
información geoespacial, bien sea de forma directa a través de clientes o indirectamente por medio de servicios web de
geo-procesamiento como es el caso de los Web Map Services o los Web Feature Services.
Algunos de los benchmarks más utilizados para la evaluación de gestores de bases de datos son:
• TPC Benchmark™ C (TPC-C), benchmark propietario utilizado para el procesamiento online de
transacciones (en inglés, OLTP). Es considerado como el estándar de facto para OLTP en cuanto a benchmarks
para gestores de bases de datos, principalmente porque intenta simular el procesamiento de transacciones
online que se dan en el mundo real. http://www.tpc.org
• eWeek’s Nile benchmark, diseñado para comparar los resultados de varios gestores de bases de datos (entre
otros MySQL, Microsoft SQL Server, IBM DB2, Oracle y Sybase) en aplicaciones de comercio electrónico en
el “mundo real”. http://www.eweek.com/article2/0,4149,293,00.asp
• SysBench, benchmark open-source, modular, multi-plataforma y multi-hilo diseñado para evaluar los
parámetros de los sistemas operativos que son importantes para un sistema que esté utilizando un gestor de
bases de datos bajo una carga intensiva. http://sysbench.sourceforge.net
• Otros: MySQL Benchmark Suite (http://dev.mysql.com/doc/mysql/en/mysql-benchmarks.html), The Open
Source Database Benchmark (OSDB, http://osdb.sourceforge.net), BenchW (http://benchw.sourceforge.net)
y Open Source Development Labs’ (ODSL) Database Test Suite (DBT)
(http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite).
Por otro lado, los servicios web se están convirtiendo en una de las principales tecnologías para la comunicación entre
las aplicaciones de distintas empresas, permitiendo a los clientes software intercambiar información con estas de una
forma transparente mediante estándares y protocolos de transporte abiertos basados en XML. Dada la rápida
implantación de los servicios web como estándar de facto para la transmisión y almacenamiento de información, es
necesario evaluar las características y rendimiento de las implementaciones de esta tecnología en los productos que lo
ofrezcan. Algunos de los programas más utilizados para la evaluación de servicios web son:
• ApacheBench (ab), herramienta de libre distribución diseñada para evaluar servidores HTTP de Apache. En
particular muestra cuantas peticiones por Segundo es capaz de servir (viene incluida con el servidor Apache).
http://httpd.apache.org/docs/2.0/programs/ab.html
• Microsoft Web Application Stress Tool (WAST), herramienta gratuita diseñada para simular de forma
realista múltiples navegadores pidiendo páginas de un servidor web, permitiendo recopilar información a cerca
del rendimiento y estabilidad de la aplicación web.
http://www.microsoft.com/downloads/details.aspx?FamilyID=E2C0585A-062A-439E-A67D-
75A89AA36495&displaylang=en
• LoadRunner, herramienta de pago para la evaluación del comportamiento y rendimiento de aplicaciones web.
Puede simular miles de usuarios y utiliza monitores de rendimiento para identificar y aislar problemas.
Evaluación de servidores de aplicaciones web, servidores de streaming, gestores de bases de datos,
aplicaciones Java y ERP. http://www-svca.mercuryinteractive.com/products/loadrunner
• Apache Jmeter, aplicación de libre distribución desarrollada completamente en Java. Inicialmente diseñada
para medir el rendimiento de aplicaciones web, se extendió a otras funciones como servidores FTP,
aplicaciones Java, SOAP/XML-RPC y JDBC. http://jakarta.apache.org/jmeter/index.html
• TPC Benchmark™ W (TPC-W), benchmark transaccional para servicios web. La carga de trabajo se realiza
en un ambiente de comercio electrónico controlado que simula las actividades de un negocio orientado a
servidores web transaccionales (es decir, e-comercio). http://www.tpc.org/tpcw/default.asp
• Otros: httperf (http://www.hpl.hp.com/research/linux/httperf), Webstone
(http://www.mindcraft.com/benchmarks/webstone), y Flood (http://httpd.apache.org/test/flood).
METODOLOGÍA DE EVALUACIÓN
El objetivo de esta sección es presentar la metodología utilizada en los análisis de los servicios de visualización de
mapas (Web Map Service), de acceso y manipulación de objetos geográficos (Web Feature Service) y repositorios de
información geográfica (bases de datos e información vectorial), sí como las soluciones open source y parámetros
elegidos para el estudio.
Una vez concluido este trabajo, los resultados obtenidos también han de servir como orientación a la Consellería de
Infraestructuras y Transportes (CIT) para tomar decisiones referentes a qué implementaciones de los distintos
componentes utilizar en su IDE basada en tecnologías de software libre.
Los Web Map Service proveen al cliente software de una forma estándar de acceder a través de la Web a mapas geo-
referenciados en un formato de imagen, y permite a los proveedores ofrecer un catálogo de sus productos disponibles.
Estos servicios proveen únicamente del nivel más básico de web mapping. Sus principales características son la
construcción dinámica de un mapa como una imagen, como una serie de elementos gráficos o como un conjunto
empaquetado de elementos geográficos; responder a consultas sencillas sobre el contenido del mapa; e informar a otros
programas a cerca de los mapas que puede generar y a cuales de aquellos se les pueden hacer consultas sobre su
contenido. Por otro lado, en el caso de los Web Feature Service, el servicio básico (No-Transaccional) da únicamente
acceso de lectura a datos vectoriales utilizando GML (codificación XML para el transporte y almacenamiento de
información geográfica, incluyendo tanto propiedades espaciales como no espaciales de los elementos geográficos)
como el protocolo subyacente para realizar consultas espaciales, recuperar los resultados y manipular la geometría. El
servicio Transaccional añade funcionalidades de bloqueo y actualización de los elementos geográficos al servidor para
crear una nueva instancia geográfica, borrar y/o actualizar una instancia ya existente, y obtener o consultar elementos
geográficos basados en restricciones espaciales y no espaciales.
Las soluciones elegidas para ser objeto de la evaluación son Minnesota MapServer (http://mapserver.gis.umn.edu, con
licencia que permite que sea distribuido y modificado con total libertad) y Geoserver (http://geoserver.sourceforge.net,
distribuido bajo licencia GPL). Ambas soluciones integran en una única aplicación los servicios de WMS y WFS, y
pueden ser instaladas en servidores con sistemas operativos Windows y UNIX/Linux. La primera ha sido desarrollada
en C++, mientras que la segunda en Java, contando las dos con una amplia comunidad de usuarios y desarrolladores.
En los entornos que se describen a continuación, a parte del gestor de bases de datos elegido para el almacenamiento y
consulta de la información geoespacial, también se ha optado por incluir en cada uno de los servidores una copia local
de los ficheros vectoriales para poder evaluar el rendimiento de repositorios heterogéneos de información geoespacial
El sistema distribuido de geo-servicios utilizado para evaluar las prestaciones de las soluciones Web Feature Service
implementadas se encuentra alojado en el Departamento de Lenguajes y Sistemas Informáticos de la Universidad Jaume
I. Este sistema consiste en 4 nodos que actúan como servidores y 1 nodo desde el cual se realizarán las pruebas. Uno de
los servidores aloja el gestor de la base de datos geoespacial y los tres servidores restantes alojan los servicios de geo-
procesamiento.
El servidor del gestor de la base de datos (servidor 1) es un Intel Pentium IV XEON Dual a 1.5 GHz con 1 GB de
memoria RAM, dos discos SCSI (17 GB + 37 GB) y sistema operativo Suse Linux 9.2 Professional. Funcionando sobre
este está el gestor de base de datos PostgreSQL/PostGIS. Las versiones del software utilizado para la base de datos
espacial son PostgreSQL 8.0.3 y PostGIS 1.0.4, incluyendo las librerías necesarias para el manejo de geometría y
proyecciones Geos 2.1.4 y Proj 4.4.9 respectivamente.
Los servidores que alojan el geo-servicio son un Intel Pentium IV XEON a 2.4 GHz con 512 MB de memoria RAM,
disco duro IDE de 80GB y sistema operativo Windows XP Professional (Service Pack 2); un Intel Pentium IV a 1.8
GHz con 512 MB de memoria RAM, disco duro IDE de 80GB y sistema operativo Suse Linux 9.2 Professional; y un
Intel Pentium IV XEON Dual a 3.0 GHz con 2 GB de memoria RAM, dos discos SCSI de 136 GB y sistema operativo
Suse Linux 9.2 Professional. Todos los servidores llevan instalada la máquina virtual de Java (JDK 1.4.2_08) y el
contenedor de servlets Apache Tomcat (versión 5.0.28) y las implementaciones open source de los Web Feature
Service, Geoserver (versión 1.3.0-beta3) y el Minnesota Mapserver (versión 4.6.1) El servidor Windows utiliza el
paquete MS4W (http://www.maptools.org/ms4w/index.phtml, versión 1.2.1) que incluye el Minnesota Mapserver ya
compilado para este sistema operativo. Este paquete incluye además el servidor web Apache (versión 2.0.54), y las
librerías necesarias para el manejo de proyecciones (proj, versión 4.4.6 y formatos vectoriales y acceso a PostGIS
(GDAL/OGR, versión 1.2.6). Por otro lado, los servidores Linux utilizan el servidor web Apache (versión 2.0.50) y el
Minnesota Mapserver ha sido compilado a partir del código fuente, junto con todas las librerías necesarias (proj4
versión 4.4.9, GDAL/OGR versión 1.2.6, geos versión 2.1.1 y PostGIS versión 1.04).
Estos servidores los llamaremos servidor 2, 3 y 4 respectivamente para que puedan ser referenciados posteriormente
cuando hablemos de los resultados.
El nodo desde el cual se lanzan las pruebas es un Intel Pentium IV a 3.0 GHz con 1 GB de memoria RAM, dos discos
duros SERIAL ATA de 120 GB y sistema operativo Windows XP Professional (Service Pack 2).
Todos los nodos del sistema disponen de una tarjeta de red ethernet 100MB/s y están conectados a la red local por
medio de un switch con puertos de velocidad 10, 100 y 1000 MB/s.
El sistema distribuido de geo-servicios utilizado para evaluar las prestaciones de las soluciones Web Map Service
implementadas se encuentra alojado en la Consellería de Infraestructuras y Transportes de la Generalitat Valenciana.
Este sistema consiste en 2 nodos que actúan como servidores y 1 nodo desde el cual se realizarán las pruebas. Ambos
servidores alojan los distintos repositorios de información geoespacial (gestor de base de datos y ficheros vectoriales) y
los servicios de visualización.
Los servidores son un Intel Pentium IV a 2.8 GHz con 512 MB de memoria RAM, disco duro IDE de 80GB y sistemas
operativos Windows XP Professional y Suse Linux 9.0 Professional; y un Intel Pentium IV Cuádruple a 3.0 GHz con 4
GB de memoria RAM, cinco discos SCSI de 136 GB y sistema operativo Suse Linux Enterprise. Ambos servidores han
sido configurados con el mismo software. Las versiones del software utilizado para la base de datos espacial son
PostgreSQL 8.0.4 y PostGIS 1.0.4, incluyendo las librerías necesarias para el manejo de geometría y proyecciones Geos
2.1.4 y Proj 4.4.9 respectivamente. La versión de la máquina virtual de Java utilizada es JDK 1.5_05, el contenedor de
servlets es Apache Tomcat (versión 5.5.12) y el servidor web es Apache (versión 2.0.54). Las implementaciones open
source de los Web Map Service son Geoserver (versión 1.2.4) y el Minnesota Mapserver (versión 4.6.1), este último con
todas las librerías necesarias para acceder a los repositorios raster y vectoriales (proj4 versión 4.4.9, GDAL/OGR
versión 1.3.0, geos versión 2.1.1 y PostGIS versión 1.04).
El nodo desde el cual se lanzan las pruebas es un ordenador portátil Intel Pentium M a 2.0 GHz con 1 GB de memoria
RAM y sistema operativo Suse Linux 9.2 Professional.
Todos los nodos del sistema disponen de una tarjeta de red ethernet 100MB/s y están conectados a la red local por
medio de un switch con puertos de velocidad 10, 100 y 1000 MB/s.
Para la realización de las pruebas se han utilizado tres conjuntos de datos espaciales de gran tamaño obtenidos de la
Consellería de Infraestructuras y Transportes de la Generalitat Valenciana: Usos del suelo (capa con geometría
poligonal, escala 1:25000), Red de comunicaciones (capa con geometría lineal, 1:10000) y una capa con geometría
puntual a escala1:25000 obtenida a partir de la capa de polígonos. Este conjunto de datos ha sido manipulado para tener
un cierto control sobre el número de elementos geográficos que contiene cada capa. Para cada tipo de geometría simple
(punto, línea y polígono) se han obtenido tres capas de distintos tamaños (puntos_p, puntos_m, puntos_g, lineas_p,
lineas_m, lineas_g, poligon_p, poligon_m y poligon_g). El tamaño de estos datos es de aproximadamente 289 KB, 2.79
MB y 27.9 MB para los puntos; 464 KB, 10.6 MB y 140 MB para las líneas; y de 2.78 MB, 16.7 MB y 134 MB para los
polígonos en el formato comprimido Shapefile de ESRI. Una vez importados a la base de datos PostgreSQL, el número
de registros es de 200, 2000 y 20000 en el caso de los puntos; 2500, 25000 y 250000 en el caso de las líneas; y 5000,
50000 y 500000 en el caso de los polígonos. Las tablas de la base de datos hacen uso de índices espaciales para acelerar
las consultas.
Figura 1: Capa de puntos original Figura 2: Capa de líneas original Figura 3: Capa de polígonos original
Métrica utilizada
Aunque se pretende evaluar geo-servicios que ofrecen funcionalidades distintas (WMS y WFS), hay una serie de
cuestiones de carácter que general que son aplicables a ambos, como qué operaciones de la especificaciones de
implementación definida por OGC han sido implementadas en cada una de las soluciones, cuál es el tiempo de
respuesta de cada una de las soluciones ante las peticiones recibidas, qué sistema operativo es el adecuado, cuál es el
efecto del hardware en las prestaciones en las distintas soluciones, cómo se comportan las distintas soluciones a medida
que se incrementa la carga de usuarios o qué impacto tiene el uso de las distintas fuentes de información geoespacial
(base de datos versus ficheros locales) en el rendimiento. Por el contrario, otras cuestiones son específicas del geo-
servicio en cuestión.
En el caso del Web Map Service es interesante plantearse con qué formatos raster trabaja más eficientemente cada
servidor o cómo afectan al rendimiento de estos la utilización de estilos (Ej., leyendas, simbología, etc.) o
reproyecciones de las capas; mientras que en el caso de los Web Feature Services sería interesante ver cómo afectaría al
rendimiento y al tiempo de respuesta si se aplicasen métodos de compresión al mensaje de respuesta. Si bien muchos de
estos parámetros tienen una respuesta numérica como el tiempo de respuesta en segundos, el porcentaje de peticiones
fallidas, o el numero de respuestas por segundo; otros como pueden ser el grado de conformidad con las
especificaciones requieren de una respuesta cualitativa.
En las soluciones que implementan el Web Feature Service, se aplicarán sobre cada una de las capas que ofrece el
servidor cuatro operaciones típicas definidas en la especificación [6], GetFeature sin filtros (se obtiene todos los
elementos geográficos de la capa), GetFeature con filtro espacial DWithin (radio de búsqueda de 100km), GetFeature
con filtro espacial BBOX y GetFeature con filtro espacial Intersects, (el área utilizada en las dos últimas operaciones es
de 36.77 millones de km2).
En las soluciones que implementan el Web Map Service, se aplicará sobre cada una de las capas que ofrece el
servidor la operación GetMap definida en la especificación [11].
La herramienta utilizada para la realización de las pruebas es JMeter. Para simular una carga de 1, 5 ó 10 usuarios en
cada servidor se lanzará simultáneamente la misma operación a las distintas capas de puntos, líneas y polígonos
configuradas en los servidores tantas veces como usuarios se quiera simular dejando un intervalo de 2 segundos entre
cada petición, repitiendo este proceso 30 veces para sacar un tiempo medio de respuesta. Además, también se han
tenido en cuenta dos tiempos para la realización de las pruebas, un time out de 30 segundos por cada petición lanzada,
el cual una vez transcurrido sin una respuesta por parte del servidor se considera que esa petición ha fallado y un tiempo
máximo de 120 segundos para que el servidor mande el mensaje completo de respuesta.
Figura 4: BoundingBox utilizada en operación espacial BBOX Figura 5: Radio de búsqueda utilizado en la operación espacial
sobre la capa poligon_g (WFS) DWithin sobre la capa lineas_g (WFS)
RESULTADOS PRELIMINARES
Antes de iniciar las pruebas sobre las soluciones escogidas, se realizó un estudio preliminar de las capacidades ofrecidas
por cada una de ellas. Como se ha comentado anteriormente, Mapserver y Geoserver disponen de una amplia
comunidad de usuarios que informan de los errores hallados, lo cual hace de ellas unas soluciones muy probadas y
confiables. Mapserver utiliza C++ como lenguaje para su implementación y Geoserver el lenguaje Java, previendo en
una primera aproximación que la primera solución será la más rápida. Por contra, Geoserver es multiplataforma y puede
ser utilizado de forma inmediata en cualquier sistema sin que se requiera de grandes conocimientos informáticos por
parte del usuario, mientras que Mapserver y las librerías que utiliza necesitan ser compilados específicamente para la
arquitectura del sistema en el que vayan a ser utilizados, convirtiéndose en una tarea de elevada complejidad para los
usuarios noveles.
Mapserver implementa únicamente las operaciones no transaccionales definidas en la especificación 1.0.0 del Web
Feature Service, siendo estas GetCapabilities, DescribeFeatureType, GetFeature y las operaciones con filtros lógicos
simples, aritméticos, de comparación (a excepción de NullCheck) y un conjunto reducido de los operadores espaciales
(Dwithin, Intersects y BBOX), mientras que Geoserver, además de implementar todas operaciones no transaccionales,
también implementa las operaciones transaccionales GetFeatureWithLock, Query, Insert, Delete, Update y Lock. Por
otro lado, Mapserver implementa las versiones 1.0.0, 1.1.0 y 1.1.1 de la especificación del Web Map Service,
soportando las operaciones básicas GetCapabilities, GetMap y GetFeatureInfo; y las operaciones con SLDs
DescribeLayer, GetLegendGraphic, GetStyles (en la parte del servidor) y PutStyles (en la parte del cliente). Geoserver
por su parte, en las versiones 1.0.0, 1.1.0 y 1.1.1, únicamente implementa las operaciones básicas.
140,00
120,00 servidor4-geoserver
100,00 servidor4-mapserver
80,00 servidor3-geoserver
60,00 servidor3-mapserver
40,00 servidor2-geoserver
20,00 servidor2-mapserver
0,00
puntos_p puntos_m puntos_g lineas_p lineas_m lineas_g poligon_p poligon_m poligon_g
capas locales del servidor con disitntos tamaños
Figura 6: Comparativa de la operación espacial BBOX realizada sobre WFS con datos locales en los distintos nodos.
Como muestran las figuras 6 y 7, Mapserver ofrece tiempos de respuesta muy inferiores a los de Geoserver ante las
peticiones realizadas a los Web Feature Services y Web Map Services. También se observa que para una misma
solución, el componente hardware es un elemento clave en el tiempo de respuesta, siendo menos relevante el sistema
operativo elegido. Por otro parte, en la figura 9 se puede observar como el incremento de usuarios pidiendo la misma
capa de forma simultánea reduce considerablemente el número de peticiones por segundo que es capaz de responder el
servicio. Además, también puede verse que la utilización de la base de datos como fuente de datos (figura 8) supone un
impacto negativo en la eficiencia del servicio.
30,00
Tiempo de repuesta (en segundos)
25,00
20,00
geoserver
15,00
mapserver
10,00
5,00
0,00
_p
_g
_m
_p
_g
_m
g
m
s_
s_
s_
on
on
os
os
on
os
ea
ea
ea
lig
lig
nt
nt
lig
nt
lin
lin
pu
pu
lin
po
po
pu
po
capas
Figura 7: Comparativa de la operación GetMap realizada sobre WMS con datos locales en los distintos nodos.
En general, para los dos geo-servicios evaluados se ha observado que Mapserver ofrece un rendimiento muy superior al
obtenido por Geoserver en todas las pruebas realizadas, independientemente del hardware, sistema operativo, fuente de
datos o carga de usuarios utilizado. Esta superioridad de Mapserver es debida principalmente al hecho de que
Mapserver haya sido programado con C++, lo que le permite un acceso más eficiente a los recursos hardware del
sistema. El acceso simultáneo por parte de varios usuarios a una misma capa supone una pérdida de prestaciones,
especialmente cuando el volumen de información es grande, llegándose a producir una situación la que el servidor ya no
puede atender más peticiones. Esta situación degenera más rápidamente cuando se utiliza la base de datos debido al
tiempo extra necesario para que el geo-servicio conecte con esta, se autentique, el gestor de la base de datos realice la
consulta, se reciban los resultados provenientes de la base de datos y posteriormente sean transformados del formato
nativo de PostGIS al formato interno de cada solución.
_m
_p
_g
m
p
g
_m
_p
_g
s_
s_
s_
on
on
os
os
on
os
ea
ea
ea
lig
lig
nt
nt
l ig
nt
lin
lin
li n
pu
pu
po
po
pu
po
capas
Figura 8: Comparativa de la operación GetMap realizada sobre WMS con datos de PostGIS.
También se ha observado en el caso de los Web Feature Services que una fracción importante del tiempo necesario para
satisfacer las peticiones depende de la velocidad con la que los datos pueden ser transformados en GML. El ancho de
banda de la red también juega un papel importante, por lo que la transmisión de varios cientos de megabytes a través de
redes con conexiones lentas como el ADSL se convierte en el cuello de botella.
La especificación de implementación de los Web Feature Services, en su versión 1.0.0 y 1.1.1 [6] permite que se
utilicen otros formatos de salida a parte de GML. Esto abre las puertas para que el WFS pueda enviar la respuesta en un
formato comprimido. Los experimentos realizados con los servidores Linux y la herramienta de compresión gzip
(simulando un único usuario) muestran que utilizando el nivel más bajo de compresión es posible reducir entre una
quinta y una décima parte el mensaje original, siendo el tiempo necesario para su compresión varios ordenes de
magnitud menor que el tiempo necesario para la transmisión del mensaje original. Sin embargo, la reducción del tiempo
total de transferencia y ancho de banda consumidos se hace a costa de una mayor sobrecarga del servidor y una menor
interoperabilidad, ya que el receptor ha de saber de antemano qué tipo de mensaje está recibiendo.
70,00
Tiempo de respuesta (en
60,00
50,00
segundos)
40,00
poligon_m
30,00
20,00
10,00
0,00
geoserver mapserver
solución
Figura 9: Comparativa de la operación GetMap realizada sobre WMS con datos locales y 10 usuarios simultaneos solicitando la capa
poligon_m.
CONCLUSIONES
En este artículo hemos presentado los primeros resultados de un estudio que pretende valorar de forma objetiva el
estado de madurez de las soluciones open source implementadas de los distintos componentes que conforman la
arquitectura de las IDEs. Estas soluciones han sido probadas bajo una variedad de condiciones distintas como son el
número de usuarios en el sistema, la carga de datos, el sistema operativo, las licencias de uso, portabilidad, tiempos de
respuesta y lenguaje de programación utilizado para su implementación.
Los resultados preliminares obtenidos apuntan en términos generales a que tanto en el caso de los Web Feature Services
como de los Web Map Services, Mapserver es siempre más eficiente que Geoserver, tanto en el uso de datos
almacenados localmente como de la base de datos espacial, viéndose con mayor claridad cuanto mayor es la carga de
usuarios o el volumen de información solicitada. También se ha visto en ambos casos (WMS y WFS), que la utilización
de la base de datos supone para todas las soluciones una fuerte penalización en el tiempo total de respuesta y que el
sistema operativo elegido no supone una gran diferencia en los resultados obtenidos. En el aspecto cualitativo,
Mapserver es la solución que implementa la mayor parte de las especificaciones de los Web Map Services, mientras que
es Geoserver el que en el caso de los Web Feature Services el que implementa en su totalidad las especificaciones.
El trabajo donde se enmarca este artículo fue concebido pensando en un conjunto reducido de variables a probar. Sin
embargo, el número de permutaciones posibles que se pueden dar al combinar los distintos valores de estas variables
(ej. incrementar la cantidad de memoria RAM en el servidor, considerar otras soluciones existentes o utilizar distintas
cargas de usuarios) han hecho de esta tarea un proceso arduo de llevar a cabo.
En un futuro se incluirán más comparativas referentes a los geo-servicios tratados en este artículo, como el uso de las
reproyecciones, de distintos formatos raster, de SLDs o el consumo de memoria por parte de los geo-servicios; así como
la inclusión de otras soluciones no contempladas como Deegree (http://deegree.sourceforge.net); y comparativas con
otras soluciones existentes para el resto de los componentes que conforman la arquitectura de las IDEs (clientes
pesados, servicios de catálogos y repositorios de información geoespacial).
Por último, en un plazo relativamente corto, se pretende publicar un informe que abarque de forma más extensa los
resultados aquí presentados. Esta será una contribución más a una IDEE abierta y heterogénea respecto a su
implementación, sin que este estudio pretenda menoscabar las soluciones propietarias ya existentes en el mercado.
REFERENCIAS
1. Harrison, J., (2002): "OGC Web Services - Geoprocessing and the New Web Computing Paradigm". Geoinformatics, 5: 18-21
2. INSPIRE Initiative. http://inspire.jrc.it (último acceso: Noviembre 2005)
3. Smits, Paul 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 (último acceso: Noviembre 2005).
4. OCCAMLAB. http://www.occamlab.com/conan/index.jsp (último acceso: Junio 204).
5. Proyecto ACE-GIS. http://www.acegis.net (último acceso: Junio 2005).
6. Vretanos, Panagiotis A. (2002): OpenGIS® Web Feature Service (WFS) Implementation Specification.
https://portal.opengeospatial.org/files/?artifact_id=8339 (último acceso: Noviembre 2005)
7. Whiteside, Arliss (2005): OpenGIS® Web Service Common Implementation Specification.
https://portal.opengeospatial.org/files/?artifact_id=8798 (último acceso: Noviembre 2005).
8. Geospatial Interoperability Reference Model (GIRM). http://gai.fgdc.gov/girm (último acceso: Noviembre 2005)
9. Federal Geographic Data Comité (FGDC): http://www.fgdc.gov (último acceso: Noviembre 2005)
10. Alameh, Nadine (2003): "Chaining Geographic Information Web Services," IEEE Internet Computing, vol. 07, no. 5, pp. 22-29.
11. de La Beaujardiere , Jeff (2004): OpenGIS® Web Map Service (WMS) Implementation Specification.
http://portal.opengeospatial.org/files/?artifact_id=5316 (ultimo acceso: Noviembre 2005).
D. Portolés-Rodríguez1, R. Martínez-Cebolla2
Aragonesa de Servicios Telemáticos - Gobierno de Aragón (España), dportoles@aragon.es 1, rmartinezce@aragon.es 2
Resumen:
El desarrollo de toda Infraestructura de Datos Espaciales (IDE) está caracterizado por la estructura y relaciones
institucionales existentes entre los distintos actores participantes. Dotar a esta infraestructura de un marco de trabajo
que permita una gestión eficiente y acorde con las necesidades requeridas por estos agentes, se convierte en una
necesidad fundamental para el éxito de la puesta en marcha de la IDE.
En el presente artículo, basándose en su experiencia como participantes en el desarrollo de IDEs en todos los ámbitos
institucionales, los autores presentan las líneas maestras que han guiado la construcción de un entorno con estas
características para una IDE regional. Por un lado, se detallan las posibles alternativas existentes, la solución final
alcanzada, así como una valoración crítica del grado de adecuación de dicho modelo con las necesidades impuestas. Y,
por otro lado, se describe en profundidad la relación entre el componente gente y los demás componentes nucleares de
una IDE ya sea nacional, regional, comarcal, local o corporativa.
Palabras clave: infraestructuras de datos espaciales, usuario, perfiles, unidad de trabajo, actores de una IDE
INTRODUCCIÓN
El concepto de Infraestructura de Datos Espaciales (IDE) es una iniciativa que pretende crear un entorno que permita a
una amplia variedad de usuarios, dentro de un determinado ámbito cubierto por dicha IDE, poder acceder y recuperar
datos completos y consistentes de una forma fácil y segura [1]. A pesar de no ser considerado en algunas ocasiones
como uno de los componentes nucleares de una IDE [2], otros análisis dotan de una mayor relevancia al “componente
gente” formado por usuarios, proveedores de datos y demás actores participantes de una IDE [1] [4] [5]. Por tanto, una
gestión y regulación adecuada de todo lo relativo a los distintos agentes involucrados en la IDE constituye una de las
piezas importantes que conforman dicha infraestructura.
Establecer una definición universal que describa el "componente gente" de una IDE es una tarea complicada debido,
principalmente, a que son muchos los factores que intervienen en las relaciones entre los actores. Entre ellos, cabe
destacar al menos los siguientes: el ámbito de la IDE, el número de instituciones implicadas y responsables en el
desarrollo y mantenimiento de la IDE así como su estructura orgánica y sus relaciones internas y externas, el número y
tipo de actores involucrados y las necesidades demandadas por éstos y, por último, la existencia de restricciones
impuestas por el contexto tecnológico existente en las instituciones afectadas con el que la IDE debe integrarse. Sin
embargo, pese a la aparente divergencia inicial entre los diversos casos concretos de IDE, es posible extraer
determinadas características comunes que subyacen en todos ellos.
De entre estos factores ya mencionados, cabe destacar por su relevancia las necesidades de los participantes, ya que
determinan en gran parte, el éxito o fracaso de la IDE. En este punto, la casuística que puede encontrarse también puede
resultar muy variada, desde perspectivas inequívocamente orientadas hacia una IDE tales como almacenamiento
centralizado y controlado de su información, la posterior publicación de dicha información o la integración de otros
sistemas y servicios mediante estándares, hasta perspectivas más alejadas con el concepto IDE como por ejemplo, la
participación en la misma sin ninguna convicción o los motivados únicamente por el obligado cumplimiento del
ordenamiento jurídico vigente. Sin embargo, pese a esta gran variedad, la experiencia demuestra que la mayoría de
actores suelen demandar requerimientos similares que pueden ser organizados y clasificados atendiendo a su tipo de
participación en la IDE.
El presente artículo describe en profundidad los conceptos señalados previamente y presenta las líneas maestras que han
guiado la construcción de un entorno de gestión de usuarios para una IDE regional. Por un lado, se detallan las posibles
alternativas existentes, la solución final alcanzada, así como una valoración crítica del grado de adecuación de dicho
modelo con las necesidades impuestas. Y, por otro lado, se hace especial hincapié en las diferencias de la gestión de
usuarios en función del ámbito de la IDE, ya sea nacional, regional, comarcal, local o corporativa.
Tradicionalmente, los actores de una IDE se han clasificado según su tipo de participación en los siguientes grupos:
actores encargados del mantenimiento de los datos, usuarios finales, participantes, y socios de negocio [3].
Sin perjuicio de lo anterior, es posible establecer clasificaciones más detalladas basándose en diferentes puntos de vista,
como puede ser, por ejemplo, desde una perspectiva acorde a criterios funcionales (perfiles) o conforme a la estructura
organizativa de las instituciones implicadas (unidades de trabajo).
La primera de las clasificaciones permite organizar a los usuarios en función de su participación respecto a distintos
elementos de la IDE como puede ser su relación con un determinado tipo de servicio, una aplicación o servicio
concreto, un subconjunto de datos según la temática, un tipo de trabajo específico, etcétera. Esta relación puede recibir
el nombre de perfil de usuario.
• Usuario básico: utiliza determinadas aplicaciones finales, generalmente a través de la web, que posibilitan el
acceso a servicios básicos, como por ejemplo, un visualizador de mapas o un buscador de metadatos.
• Usuario avanzado: requiere utilizar herramientas y aplicaciones específicas no disponibles para el público en
general, ya sean a través de la web o aplicaciones locales.
• Usuario de negocio: accede a datos espaciales desde aplicaciones externas a la IDE para combinarlos con
otros datos temáticos y realizar procesos de negocio, tales como gestión de expedientes o tramitación de
diferentes procedimientos administrativos.
• Usuario consultor: está autorizado para acceder a datos restringidos de una temática específica, como puede
ser el acceso a datos medioambientales, infraestructuras viarias, etcétera.
• Usuario editor: está encargado de mantener un subconjunto de datos espaciales existentes en la propia
infraestructura.
• Usuario gestor: gestiona determinados servicios existentes en la IDE, como puede ser todos los servicios de
metadatos o un servicio de mapas temático concreto.
• Administrador: es el responsable final de mantener toda la administración de la infraestructura y proporcionar
un soporte técnico al resto de usuarios de la IDE.
Habitualmente, el número de usuarios que pertenecen a cada uno de los perfiles previamente señalados suele
distribuirse de forma decreciente desde la primera (usuario básico) hasta la última de las categorías (administrador).
Debido a esta característica, puede definirse una estructura jerárquica de perfiles de usuario como la representada en la
Figura 1.
A modo de ejemplo comparativo, pese a no ser una IDE, puede tomarse como referencia la categorización y
cuantificación de usuarios existente en la ciudad de Calgary (Canadá) en su iniciativa de creación de un sistema de
información geográfica corporativo [6] que tienen correspondencia casi directa con la clasificación antes definida. Los
datos son presentados en la Figura 2:
Figura 2: Porcentaje de usuarios según perfil del GIS corporativo de Calgary (Canadá)
Se entiende por unidad de trabajo a una delimitación del contexto asociado a la IDE conforme a un determinado
criterio como puede ser, un ámbito de trabajo ya sea específico ya sea territorial o un cargo institucional. La unidad de
trabajo se caracteriza por ser:
• Independiente y estable frente a las posibles modificaciones de la estructura orgánica de una institución a lo
largo del tiempo. Esta característica es fundamental debido a que la mayoría de las iniciativas de IDE, en
Estados con sistemas democráticos, son desarrolladas por Administraciones Públicas, cuyo organigrama y
distribución competencial se va modificando de forma periódica como consecuencia de los distintos procesos
electorales.
• Flexible y autónoma para que sirva como fórmula general y se amolde a las diversas estructuras que puedan
existir.
• Escalable a futuras incorporaciones de nuevas unidades de trabajo
• Funcionalmente apropiada para satisfacer las necesidades que se demanden por parte de los usuarios.
La unidad de trabajo se compone de los siguiente elementos: un administrador responsable de la gestión de la propia
unidad, un conjunto de roles predefinidos comunes a todas las unidades de trabajo, otro conjunto de roles específicos de
la propia unidad, y, finalmente, un repositorio donde almacenar la información que utilice. Todas estas unidades de
trabajo, quedan enmarcadas dentro de un contexto más amplio formado por un superadministrador y un conjunto de
usuarios finales, los cuales serán descritos en el siguiente apartado.
El administrador de la unidad de trabajo tiene dos funciones principales. Por un lado, es el responsable de gestionar la
unidad: decide qué elementos (datos, servicios o aplicaciones) se incorporan a la unidad, crea nuevos roles específicos
de la unidad y, por último, asigna o revoca los roles a los usuarios finales o a otros roles existentes. Y, por otro lado,
asume el papel de representación de la unidad respecto al superadministrador y al resto de administradores de unidades
de trabajo.
Con el objetivo de simplificar la puesta en marcha de esta aproximación, se otorga a todas las unidades de trabajo un
conjunto mínimo de roles por defecto, suficientes para las necesidades demandadas por la mayoría de dichas unidades.
Un ejemplo de este conjunto de roles podría ser el siguiente: rol de acceso a todos los usuarios finales del sistema, rol de
acceso en modo lectura a todos los elementos de la unidad de trabajo y rol de acceso en modo lectura y escritura a todos
los elementos de la unidad de trabajo. Sin embargo, siempre debe quedar abierta la posibilidad de definir otros nuevos
roles específicos, a criterio del administrador de la unidad de trabajo, en función de las necesidades particulares que
demande la propia unidad.
Por último, cada unidad de trabajo dispone de un repositorio propio para almacenar la información que estime
oportuno. Como ya se ha comentado anteriormente, el trabajo de gestionar el repositorio corresponde al administrador
de la unidad correspondiente.
El conjunto de todas las unidades de trabajo se encuadran en un marco general donde existen, además, un
superadministrador, unos usuarios finales y un repositorio centralizado y compartido de la información existente. La
suma de todos ellos conformará el entorno de trabajo global del sistema. La Figura 3 muestra de forma gráfica el
planteamiento comentado.
La solución planteada apuesta por la descentralización en unidades de trabajo autónomas e independientes, por lo que el
superadministrador tiende a convertirse, en la mayoría de los casos, en un mero supervisor del entorno de trabajo, si
bien conserva siempre la responsabilidad decisoria última.
Por otra parte, existen también un gran conjunto de usuarios finales, que son los encargados de realizar las tareas de
negocio en función de los roles otorgados por uno o más administradores de unidades de trabajo. Por tanto, se establece
una jerarquía de usuarios que tiene como base a los usuarios finales, en la zona intermedia a los administradores de las
unidades de trabajo y, en la cúspide al superadministrador.
Además, el repositorio centralizado y compartido de información es la unión de cada uno de los repositorios de las
respectivas unidades de trabajo y está gestionado en última instancia por el superadministrador del entorno. En función
de las distintas implementaciones, existen tres posibilidades:
• Repositorio centralizado: dispone de un único repositorio físico y los repositorios de las unidades de trabajo
son una parte del mismo (repositorios virtuales)
• Repositorio distribuido: existe un repositorio físico para cada una de las unidades de trabajo y es el repositorio
compartido el que tiene carácter virtual.
• Repositorio híbrido: corresponde con una solución intermedia entre las planteadas anteriormente.
Finalmente, asociado a este entorno global, cabría incluir un conjunto de políticas, directivas y criterios internos que
garanticen que la información del sistema sea de calidad, homogénea e interoperable entre sí. Algunos de estos criterios
pueden ser: catalogación obligatoria de la información existente, definición de las políticas de actualización y
mantenimiento de la misma o el establecimiento de criterios generales de homogenización tales como la utilización de
sistemas de referencia espacial común o la normalización de productos comerciales de manipulación de los datos.
Una vez analizadas las dos propuestas, en el presente apartado se incide en las ventajas e inconvenientes de cada una de
ellas a modo de comparación.
La alternativa basada en perfiles de usuario tiene como principales ventajas su sencillez y el hecho de ser un
planteamiento muy extendido en otros sistemas similares, lo cual facilita posteriores integraciones entre ellos. Pero, por
el contrario, adolece de ser una solución cerrada y estática frente a posibles cambios que puedan ocurrir a lo largo del
tiempo. Estos cambios, inevitables por la concepción de una IDE como un ente vivo, pueden provocar futuros
problemas que cuestionen la idoneidad de la adopción de esta solución.
Sin embargo, en determinados casos de IDE de pequeña envergadura que no planteen requisitos complejos, puede ser
una solución válida en términos prácticos. Por contra, para el resto de IDEs, será indispensable adoptar la basada en el
concepto de unidad de trabajo.
En virtud de algunos estudios realizados, la mayoría de los usuarios sólo utiliza un porcentaje mínimo de las
funcionalidades que por defecto son instaladas en un Sistema de Información Geográfica Corporativo, teniendo el
administrador que instalar y mantener obligatoriamente un sistema completo, que en general será infrautilizado [7]. A
este respecto, el modelo basado en unidades de trabajo se concibe como una solución independiente, autónoma y
flexible. Esto le permite satisfacer en mayor grado las necesidades de los participantes de la IDE, haciendo que las
unidades de trabajo dispongan únicamente de las funcionalidades que le sean necesarias, ahorrando recursos y
simplificando la gestión del sistema corporativo. Además, su gran capacidad de adaptación a cualesquiera sean las
estructuras iniciales de las entidades responsables en la IDE, así como a la propia evolución de las mismas, le confiere
una mayor estabilidad en el tiempo.
No obstante, conviene advertir que esta solución plantea varios inconvenientes. En primer lugar, existe un alto coste de
puesta en marcha inicial que debe ser tenido en cuenta. En segundo lugar, la falta de experiencia previa en soluciones
similares es un factor de riesgo importante. Y, por último, la apuesta por la descentralización en unidades de trabajo con
un alto grado de autonomía, puede complicar la gestión global del entorno si se deriva en una proliferación
descontrolada de elementos. Será necesario por tanto considerar el grado de madurez y sensibilización de los
administradores de cada una de las unidades de trabajo para decidir el nivel de autonomía que les concede el
superadministrador.
A la vista de las ventajas e inconvenientes expuestos previamente queda patente, salvo que se necesite una solución
simple y rápida, que el modelo basado en unidades de trabajo es el más apropiado e idóneo para abordar la gestión de
los actores de una IDE.
Como ya se ha comentado en la introducción, uno de los factores decisivos en las políticas de gestión de los actores de
una IDE es el ámbito de la misma. A continuación, se va a realizar una comparativa entre las distintas posibilidades
existentes:
• IDE transnacional (supranacional): las IDEs transnacionales se encargan principalmente de aglutinar las
IDEs asociadas en el nivel inferior de la jerarquía, es decir, las IDEs nacionales correspondientes. Debido a
este carácter aglutinador, las políticas de gestión de usuarios están centradas fundamentalmente en el nivel de
servicios, siendo menos habitual el que se necesiten requerimientos más elaborados para el nivel de datos o de
aplicaciones. En la mayoría de los casos, los usuarios son tenidos en consideración única y exclusivamente
para discriminar los servicios accesibles en las aplicaciones, criterio típicamente establecido en función de una
cierta relación de pertenencia por parte del usuario a una o varias de las IDEs que lo conforman.
• IDE nacional: en este nivel, la casuística existente es muy variada dependiendo sobre todo de la envergadura
del país correspondiente y de su estructura político-administrativa. En general, las IDEs nacionales de países
de un cierto tamaño, o bien en aquellas en las que el quantum de descentralización sea elevado, adoptan el
papel aglutinador ya especificado para una IDE transnacional, considerándose como IDEs miembros de la
unidad global, a cada una de las distintas IDEs regionales que estén asociadas a dicho país. Por contra, si el
país considerado es de un tamaño reducido o bien está fuertemente centralizado, este tipo de IDE se comporta
como el siguiente tipo, la IDE regional.
• IDE regional: este es el tipo de IDE que suele aportar mayor complejidad conceptual. En general, se considera
una IDE de estas características asociada a entidades político-administrativas con un cierto nivel de autonomía
y que, por tanto, llevan asociada una o varias instituciones administrativas de una envergadura respetable,
consideradas responsables de la creación y mantenimiento de la IDE.
Lo normal es que dichas instituciones estén vertebradas en torno a una compleja estructura orgánica, formada
por un conjunto de departamentos o secciones, la mayoría de ellos con ciertas responsabilidades y
competencias en relación directa o indirecta con datos espaciales. Además, la posición intermedia entre las
administraciones locales y nacionales hace que la cooperación entre las IDEs de dichos niveles sea inevitable y
crucial. Por lo tanto, la necesidad de poder gestionar estas cooperaciones entre niveles para que se produzcan
del modo más fluido posible, plantea muchas de las necesidades detalladas en los apartados previos.
En concreto, la gestión de los potenciales usuarios participantes en la IDE abarca todo el espectro de
elementos: desde las aplicaciones, pasando por los servicios hasta llegar a los datos. Las aplicaciones
necesitarán desde simples validaciones que comprueban si un determinado usuario puede o no acceder a la
aplicación, hasta personalizaciones de la misma más elaboradas tales como la activación de determinadas
funcionalidades o la disponibilidad de acceso a unos u otros servicios. Estos mismos usuarios presentan
demandas similares en el nivel de servicios, variando únicamente en los distintos perfiles que se puedan definir
para cada uno de los tipos de servicios, ya sea de mapas, ya sea de metadatos, etcétera, o bien para uno de estos
servicios en concreto. Por último, determinados usuarios responsables de las tareas de creación y
mantenimiento de datos, también demandarán poder acceder a este nivel como un repositorio centralizado de
datos espaciales propios y del resto de las unidades de trabajo de las instituciones existentes en la IDE.
• IDE comarcal (provincial): las provincias o comarcas, en función de la política de ordenación del territorio
establecida, representan típicamente un nivel intermedio como los detallados anteriormente, aunque con
determinados matices. Pese a que en algunas ocasiones puede servir como una posible alternativa aglutinadora
de ciertas IDEs de nivel inferior donde no se puede abordar el esfuerzo de desarrollar una IDE, es habitual que
las comarcas tampoco dispongan de los recursos necesarios para hacer frente a este tipo de desarrollos. En
suma, las IDEs comarcales pueden enfocarse con mucha mayor precisión como uno más de los actores
participantes en una IDE regional, en lugar de interpretarla como una aglutinación de IDEs locales.
• IDE local: al igual que en las IDEs nacionales, las posibilidades son muy variadas en función de la
envergadura de la entidad política asociada. Para la gran mayoría de casos quedarán encuadradas como
usuarios de niveles superiores en la jerarquía hasta que se encuentre el apropiado para disponer de una IDE
propia. Sin embargo, las localidades relevantes que afronten el reto de desarrollar una IDE también requerirán
de una política de control de usuarios acorde con sus necesidades. El comportamiento de estas últimas será
similar a las IDEs regionales con la particularidad siguiente: en general, la estuctura orgánica de sus
instituciones administrativas suelen ser más simples, sus departamentos o secciones suelen ser menos
independientes entre sí y sus responsabilidades competenciales también son menores por lo que,
presumiblemente, necesitarán de una gestión de usuarios más simple.
• IDE corporativa: en este nivel pueden encontrarse todas las posibilidades anteriores, según el tipo, tamaño y
organigrama de la entidad en cuestión. De cualquier modo hay que matizar que, independientemente del grado
de autonomía de las secciones en las que se subdividan, dichas secciones suelen estar más obligadas a cooperar
entre sí que en los distintos ámbitos político-administrativos, en los que suelen ser más independientes y en
donde, en determinadas ocasiones puede existir una cierta competencia entre ellas. Esta característica de
solidaridad se hace especialmente patente en los casos de las empresas comerciales u otras entidades con
ánimo de lucro, y determina de forma decisiva el planteamiento de las políticas de gestión de usuarios,
primando los beneficios económicos y la transparencia sobre la privacidad u otros aspectos menos materiales.
Aragón es una Comunidad Autónoma de España que coincide con la región histórica del mismo nombre. Localizada en
el cuadrante nordeste de la Península Ibérica, cuenta con una superficie de 47.645 Km2, en la que se asientan, según los
últimos datos del Censo de Población de 2005, 1.270.036 habitantes distribuidos de forma desigual en 3 provincias, 33
comarcas y 730 municipios.
La necesidad de cartografía en Aragón viene dada por tres variables fundamentales: la economía, la población y el
territorio. La primera, como factor de conocimiento del desarrollo de la propia Comunidad. La segunda, en cuanto a
usuarios directos de la información que se proporciona para desarrollar actividades administrativas, urbanísticas,
medioambientales, etcétera. Y, la tercera, por la magnitud que pueda tener el territorio, su influencia a la hora de
vertebrar al mismo y la facilidad para manejar la información que proporciona la cartografía [8].
El Gobierno de Aragón, una vez recibidas las competencias en materia de ordenación del territorio, creó el Centro de
Documentación e Información Territorial de Aragón (CDITA), en virtud de la Ley 11/1992, de 24 de noviembre de
Ordenación del Territorio. El artículo octavo de la citada Ley atribuye al CDITA el objetivo de “reunir, sistematizar,
ordenar, sintetizar e investigar documentación c información sobre el territorio de Aragón, preparando los medios
adecuados para que esta información esté actualizada y disponible para los usos necesarios en el análisis, investigación,
planeamiento y gestión territorial, y para la promoción y coordinación de otros centros comarcales de documentación
territorial de Aragón” [9].
Con el objetivo de poder resolver sus tareas de una forma más eficaz, el CDITA planteó hace unos años la necesidad de
construir una solución integral corporativa que centralizase toda la información geográfica existente. Pese a ser
diseñado inicialmente desde una perspectiva de sistema de información territorial, paulatinamente va reorientando el
enfoque hacia la construcción de la IDE regional que le corresponde por su posición administrativa. Además de resolver
toda la problemática habitual asociada al desarrollo de una IDE, uno de los puntos donde se ha intentado hacer especial
hincapié, es en la construcción de un entorno de gestión de usuarios acorde a sus necesidades. En concreto, se ha
desarrollado un entorno basado en unidades de trabajo similar al descrito anteriormente.
Por un lado, se ha hecho un esfuerzo en localizar y clasificar las unidades de trabajo existentes en aquellas temáticas
que demandaban mayores necesidades de información geográfica o en aquellas que su grado de utilidad inmediata era
mayor, esperando poder ampliar posteriormente a la totalidad de temas susceptibles de ser incluidos. Como se ha
mencionado en los apartados anteriores, desde un primer momento se ha "ignorado" la estructura orgánica, formada por
Departamentos y Direcciones Generales, y se han establecido subconjuntos de un tamaño mucho más reducido, con el
objetivo de ser flexibles y tener una cierta capacidad de adaptación ante posibles futuros repartos competenciales entre
Departamentos. Por el momento se han obtenido las siguientes unidades de trabajo: cartografía de referencia,
cartografía básica, espacios naturales protegidos, terrenos cinegéticos, minas, ortofotos para distintos años, cartografía
catastral proporcionada por la Dirección General del Catastro y cartografía procedente del SIGPAC.
Por otro lado, en este entorno se ha dado cabida a una entidad administrativa clave en la actualidad política regional
aragonesa: las comarcas. Proveer a las comarcas de una infraestructura común en la que poder desarrollar sus
necesidades de IDE está suponiendo grandes ventajas y beneficios debido, principalmente, a que la mayoría de estas
comarcas no disponen del potencial suficiente como para poder encargarse del desarrollo de una IDE comarcal. Por
tanto, se ha incluido una unidad de trabajo específica para cada una de las 33 comarcas que componen Aragón con el
objetivo de que cada una de ellas pueda utilizarla para almacenar los datos que estime oportuno y que sean de su
competencia, así como para que puedan desarrollar servicios y aplicaciones especializados sobre ellos.
Conceptualmente, no hay diferencias entre una "unidad de trabajo temática" o una "unidad de trabajo comarca": todas
son responsables de crear y mantener los datos que les competen.
Además de estas unidades de trabajo, existen en el sistema los usuarios finales. Cada uno de estos usuarios finales están
relacionados unívocamente a una persona física que, en función de su posición en la Administración, tendrá otorgados
unos determinados privilegios para poder interactuar con el sistema. Cabe destacar que estos privilegios están
concebidos como algo dinámico, es decir, que pueden ir variando en función de la evolución de dicha persona dentro
del organigrama del Gobierno de Aragón. Por tanto, no existe vinculación estática entre unidad de trabajo y persona
física, sino que los responsables de cada una de las unidades de trabajo van concediéndole privilegios o revocándoselos,
en función de las necesidades diarias.
Para tratar de facilitar la gestión de todos estos usuarios finales, se ha diseñado una solución basada en la integración de
los mismos con el sistema de gestión central de usuarios del Gobierno de Aragón. El objetivo es tratar de evitar la
aparición de múltiples usuarios y contraseñas para una misma persona física en cada uno de los sistemas tecnológicos
que utilice, así como un control unificado y centralizado de los mismos. En este sentido, está en desarrollo la adopción
de una solución single sign-on, basada en LDAP, para toda la Administración del Gobierno de Aragón, en la que el
sistema desarrollado quedaría incluido completamente. Soluciones de este tipo también están planteadas en otras
iniciativas similares [4].
Conviene detallar que el entorno de trabajo se ha dividido en tres aproximaciones según el componente de la IDE al que
estén referidos: aplicación, servicios y datos. De entre ellos, destaca principalmente el último de ellos por su
complejidad, ya que tanto aplicación como servicios se limitan generalmente a una simple validación de usuarios, es
decir, a dilucidar si el usuario puede o no acceder a dicho servicio o aplicación. Sin embargo, los datos permiten
relaciones más complejas y elaboradas entre distintas unidades de trabajo, ya que posiblemente estas unidades desearán
que parte de sus datos sean públicos, parte sean públicos para un determinado número de usuarios, parte sean exclusivos
de unos pocos usuarios, etcétera. Para ello, se han otorgado un conjunto de roles por defecto a todas y cada una de las
unidades de trabajo que serán suficientes para la gran mayoría dejando siempre abierta la posibilidad de definir otros
roles más específicos a voluntad del administrador de la unidad de trabajo. En concreto, los roles por defecto son:
Por último, cabe destacar que con el objetivo de garantizar que la información almacenada sea de calidad, homogénea e
interoperable, se pretende definir a corto plazo los criterios mínimos exigibles a las unidades de trabajo en el caso de
que quieran hacer pública su información. Previsiblemente, estos criterios serán:
• Toda información incluida debe estar debidamente catalogada mediante sus correspondientes metadatos según
estándares de normalización. Con casi toda probabilidad, el estándar elegido será el establecido por el Núcleo
Español de Metadatos [10].
• Definición de la política de actualización y mantenimiento que pretende seguirse.
• Utilización de un sistema de referencia espacial común. Está previsto que el sistema utilizado sea UTM Zona
30N con European Datum 1950 como Datum de Referencia.
• Normalización de productos comerciales de manipulación de los datos.
CONCLUSIONES
A lo largo del presente artículo, los autores han profundizado en el análisis del componente gente de las IDEs, un
elemento que sin duda ha sido tenido en cuenta por casi todos los organismos que apoyan la iniciativa de creación de
este tipo de infraestructuras pero que, sin embargo, se ha desarrollado de forma somera o casi inexistente.
Asimismo, se han detallado dos modelos distintos para dos tipos de IDEs; el primero, los perfiles de usuario, acorde con
IDEs de pequeña envergadura y el segundo, las unidades de trabajo, como solución más efectiva para IDEs cuya
estructura es más compleja. Desde estas líneas, se quiere recalcar la oportunidad que ofrece la alternativa de unidades
de trabajo para todos aquellos usuarios que quieren tener una gestión organizada de su trabajo y que desean cooperar
entre sí. Facilitar la tarea diaria que realizan estos usuarios, implicará que la involucración de éstos en la infraestructura
sea mayor y, por lo tanto, se conviertan en auténticos actores de la IDE.
Por otro lado, es necesario incidir en la importancia de poder enfocar a los usuarios desde una perspectiva integrada,
teniéndolos en consideración para todos los niveles de la infraestructura, ya sea en aplicaciones, en servicios o en datos.
Como demostración, se ha llevado a cabo la puesta en marcha de unidades de trabajo dentro de una IDE regional con el
fin de revisar y mejorar el planteamiento teórico inicial. En este sentido, el modelo se ha integrado de forma
satisfactoria con otras soluciones tecnológicas existentes relativas a la gestión de usuarios.
Y, por último, se ha presentado al lector una comparativa entre los tipos de IDE según su ámbito.
En conclusión, las iniciativas de IDE son el comienzo inequívoco de crear un entorno organizado de la información,
pero previsiblemente, sin una política clara y concisa de gestión de usuarios, no serán útiles a medio o largo plazo. Por
tanto, se puede afirmar que el hecho de dotar a esta infraestructura de un marco de trabajo que permita una gestión
flexible, eficiente, eficaz y acorde con las necesidades requeridas por los agentes participantes, se convierte en una
factor clave para el éxito de la puesta en marcha y evolución posterior de la IDE.
REFERENCIAS
1. Rajabifard, A. et al. (2000): From Local to Global SDI Initiatives: a pyramid of building blocks, Presentado en 4th Global Spatial
Data Infrastructure Conference, Cape Town, South Africa.
2. Página web “Componentes de una IDE” de la Infraestructura de Datos Espaciales de España (IDEE).
http://www.idee.es/show.do?to=pideep_IDE_components.ES (último acceso: Septiembre, 2005).
3. Página web “Actores de una IDE” de la Infraestructura de Datos Espaciales de España (IDEE).
http://www.idee.es/show.do?to=pideep_actores_IDE.ES (último acceso: Septiembre, 2005).
4. Portolés-Rodríguez D. et al. (2005): IDEZar: an example of user needs, technological aspects and the institutional framework of a
local SDI, Presentado en 11th EC-GI & GIS Workshop, ESDI: Setting the Framework, Alghero, Sardinia, Italia.
5. Coleman, D. J. and McLaughlin J. (1998), Defining global geospatial data infrastructure (GGDI): components, stakeholders and
interfaces, Geomatics Journal, Canadian Institute of Geomatics, Vol. 52, No. 2, pp. 129-144
6. Eason, Robert G., The Enterprise GIS initiative at the City of Calgary, disponible a través de GISCafé.
7. Andrés Pazos, José Poveda, Michael Gould, (2004): Arquitectura abierta para un Sistema de Información Geográfica corporativo,
Presentado en Jornadas Técnicas de la IDE de España (JIDEE 2004), Zaragoza, España.
8. Juan Bueso, Rafael Clavería, Jorge Infante: El sistema de información geográfica de Aragón, Projecto “Coordenação de SIG e dos
IOT para o desenvolvimento dos espaços rurais de baixa densidade”.
9. Ley 11/1992, de 24 de noviembre, de Ordenación del Territorio, http://benasque.aragob.es:443/cgi-
bin/BRSCGI?CMD=VERDOC&BASE=BOLE&DOCR=14&SEC=LEYES&SORT=@OLEY,PUBL&SEPARADOR=&&RANG=
LEY&ALEY=1992
10. Núcleo Español de Metadatos (NEM v1.0) (2005), Infraestructura de Datos Espacial de España (IDEE), Consejo Superior
Geográfico.
247
Estableciendo bases organizacionales para una IDE local: aportaciones... Sesión 8
Resumen:
El establecimiento de una IDE corporativa requiere la consideración de múltiples aspectos organizacionales e
institucionales que pueden ralentizar, dificultar o imposibilitar la implementación efectiva de la misma. En el caso de
las administraciones locales, dichos aspectos están estrechamente relacionados con el carácter burocrático de las
mismas.
Metodológicamente, la creación e impulso de una Cooperativa de Datos Espaciales entre todos los actores de una IDE
puede constituir una acción clave que permita sentar las bases organizativas, culturales e institucionales
indispensables para la implantación exitosa de la IDE.
Con el establecimiento de la Cooperativa de Datos Espaciales del Ayuntamiento de Las Palmas de Gran Canaria se ha
conseguido dar un paso importante para el establecimiento de la IDE local, fomentando la cultura de compartición de
geoinformación, recursos y experiencias, mejorando las relaciones entre los participantes e induciendo una
modernización progresiva en el funcionamiento de los servicios municipales y demás organizaciones participantes.
1.- INTRODUCCIÓN
La aparición y extensión masiva de la red internet y el auge de la economía global hace que nos encontramos en un
nuevo contexto histórico que se ha venido a denominar “Sociedad en Red” [1]. En dicho contexto, surge la definición
de un nuevo paradigma socio-técnico en el que las Infraestructuras de Datos Espaciales (IDE) se presentan como un
elemento imprescindible para potenciar el acceso, compartición y uso de la Geoinformación (GI) a través de la red
internet, pero también como una “estrategia” desde la que contribuir al tránsito y adecuación de las organizaciones al
nuevo escenario global.
El concepto de IDE puede ser definido y descrito desde diferentes perspectivas en función del aspecto que se quiera
destacar de la misma [2], [3]. Williamson define una IDE bajo la perspectiva organizacional como una “iniciativa que
trata de responder a la necesidad de cooperación entre diferentes usuarios y productores de datos espaciales para
proporcionar los medios y el entorno que permita su compartición y desarrollo, teniendo como objetivo último
promover el desarrollo económico, estimular una mejor administración y fomentar la sostenibilidad ambiental“ [4]. En
esta definición se ponen de manifiesto el importante rol que juega el entorno organizativo y social, ya que en última
instancia son los que propician las actitudes de colaboración y cooperación entre las personas. La consideración de
dicho entorno hace necesario considerar los factores culturales, organizacionales e institucionales que intervienen en el
diseño y desarrollo de la IDE, y que suelen introducir barreras o dificultades, especialmente a la hora de acceder y
compartir datos y conocimiento (objetivo último de una IDE), o en el momento de aceptar y difundir la innovación que
supone una nueva tecnología o forma de trabajo. Ejemplos de dichos factores son cultura corporativa e informacional, el
tipo de estructura organizativa, la resistencia de las organizaciones al cambio, las relaciones de poder o los diferentes
roles de los participantes, entre otros [5], [6], [7].
La construcción de una IDE puede ser una “estrategia” que contribuya al impulso de la compartición de datos y
conocimiento, el aumento de la capacitación de las organizaciones y personas mediante el aprendizaje organizacional, el
fomento de la colaboración intra e interinstitucional y la difusión de la innovación, propiciando así la modernización y
adecuación al cambio de las organizaciones implicadas [8].
No considerar en su justa medida los anteriores factores puede limitar el éxito de la implementación de una IDE, cuando
no hacerla fracasar. Es por ello que es hace necesario establecer una estrategia global y acciones que permitan sentar las
bases para poder tratar o reconducir adecuadamente dichos factores organizacionales.
El desarrollo del concepto IDE y su aceptación por todos los gobiernos del mundo le ha dado especial significación a la
componente organizacional de los SIG, asumiendo el marco organizacional como una parte integral de los componentes
de una IDE [9]. En el ámbito de los SIG, el establecimiento de las denominadas “Cooperativas de Datos” (espacios
colaborativos y de interacción que facilitan la compartición de información y la comunicación) ha dado muy buenos
resultados en el fomento la compartición de datos espaciales entre organizaciones, y se vislumbran como la piedra
angular para el establecimiento de una IDE, ya que contribuye a salvar muchas de las barreras organizacionales e
institucionales con las que se encuentra en la creación de la misma [10], [11].
En este trabajo describiremos las bases conceptuales y marcos teóricos que han servido para crear la Cooperativa de
Datos SICAM (CoS), las características y experiencias con la misma y las bases organizacionales que puede aportar a la
futura IDE local del municipio de las Palmas de Gran Canaria.
Los SIG raramente han contribuido a la visión de “autopista” de la información que conecta diferentes productores de
GI y usuarios, tal y como se “visionó” en la definición de la National Spatial Data Infrastructure impulsada por la
administración Clinton [12]. A pesar del reconocimiento de las grandes ventajas que introduce una IDE (mayor
eficiencia, efectividad y todo tipo de beneficios entorno al uso de la GI), existe en general una gran dificultad y falta de
voluntad para compartir GI, así como bajos niveles de coordinación y colaboración.
Paradójicamente, aunque la naturaleza de la GI debiera propiciar su compartición, también dicha naturaleza conduce a
muchos impedimentos tecnológicos y organizacionales, siendo estos últimos los más complicados de superar [13].
Debido a que es un concepto relativamente reciente, no existe demasiada literatura que documente las causas de los
fracasos en la implantación de una IDE de tipo local, pero si atendemos la similitud conceptual existente entre los SIG
Corporativos y las IDE [2], [5], [14], las causas de dichos fracasos (además de los problemas de tipo tecnológico o
metodológicos -que se van superando con gran celeridad- o presupuestarios, y que no son objeto de este trabajo),
atienden básicamente a factores que podríamos denominar en su conjunto de tipo “organizacional” o institucional, entre
los que destacan [5], [6], [7], [9], [15], [16]:
- la falta de cultura informacional
- las relaciones de poder;
- falta de visiones globales y de objetivos comunes;
- las actitudes o posturas de rechazo de las personas de la organización hacia las nuevas tecnologías;
- las actitudes poco proactivas ante la colaboración y la compartición de datos y de conocimiento;
- la falta de implicación o interés de los usuarios en el desarrollo y/o posterior uso de la GI/IDE;
- la infravaloración de los aspectos culturales y organizacionales;
- la falta de coordinación y liderazgo
- el desconocimiento de las potencialidades de la GI dentro y fuera de las organizaciones
Asimismo, también son un obstáculo importante la falta de herramientas metodológicas para gestionar el cambio que
introducen las IDE en las organizaciones [17] o la puesta en funcionamiento de enfoques que se centren en los aspectos
relativos a la creación y gestión de conocimiento y a la difusión de la innovación en las organizaciones.
Los problemas organizacionales que pueden afectan un proyecto SIG corporativo o a una IDE son numerosos, y no
existe una fórmula establecida ni única para resolverlos. La cultura en una organización frecuentemente está
profundamente arraigada, las actitudes de rechazo ante las situaciones de cambio son algo habitual en las personas,
especialmente cuando el cambio afectará a la forma de trabajar y relacionarse y a las relaciones de poder. Los estudios
muestran que la mayor parte de dichas barreras tienen su origen, en última instancia, en la creencia que tienen las
personas de que colaborar y participar con diferentes secciones de la misma organización o con otras organizaciones les
pueden suponer una pérdida de poder, influencia o una limitación de oportunidades [5], [6]. Por otro lado, la estructura
organizativa y competencial de las administraciones locales en general no contribuye a establecer entornos de trabajo
que faciliten la colaboración con otras instituciones ni a facilitar cambios en sus estructuras sin reacciones traumáticas
[18], [19], por lo que este aspecto también ha de ser motivo de reflexión entre los responsables de poner en
funcionamiento la IDE
La superación de las barreras organizacionales e institucionales debe plantearse desde la óptica general de la necesidad
de modernización y mejora de los servicios públicos y en el contexto de una política o planificación integral de la
política de información de toda la organización, huyendo de soluciones sectoriales o “parcheos” que no conducen
demasiado lejos [20]. Asimismo, es necesario determinar previamente el grado de cambio radical que la organización
necesita y puede tolerar, y tener el convencimiento de que para poder realizar exitosamente cualquier tipo de cambio en
el ámbito de la cultura informacional se ha de contar con la voluntad de las personas, y no con su rechazo o indiferencia
[18].
Para sortear las dificultades organizacionales en el desarrollo de una IDE, como paso previo, y siguiendo los trabajos y
recomendaciones de la Red Europea de Información geográfica (GINIE), entre otros, las organizaciones participantes
deberán, principalmente, dotarse de una estrategia global e integrada que contemple recursos humanos capacitados, una
coordinación y un marco claro de acuerdos de todo tipo [20]. En dicha estrategia, se deberán atender especialmente los
siguientes aspectos:
- La forma de creación del conocimiento (valorando las oportunidades y riesgos de compartir conocimiento)
- Las relaciones entre grupos u organizaciones (de interdependencia o de influencia)
- La creación de capacidades individual y organizacional
- La potenciación del trabajo en red y en equipo
- La creación de oportunidades para compartir
El marco de coordinación será uno de los aspectos más importante en dicha estrategia tal y como indica la experiencia
de todos los países analizados.
El papel del organismo coordinador es múltiple e incluye aspectos tales como el liderazgo, la mediación en los
conflictos entre participantes, el mantenimiento del apoyo político, la “venta” de beneficios y visión a múltiples
audiencias, proporcionar asesoramiento técnico, reforzar la aplicación de normas comunes, aumentar el conocimiento y
difundir los resultados.
Además, la coordinación puede jugar un papel muy útil al identificar carencias o inconsistencias en el marco legal y
organizacional, y sugiriendo acciones de corrección al gobierno.
Sea cual sea el marco de coordinación adoptado en cada IDE particular, éste ha de facilitar la adaptación de su cultura
organizacional a la introducción de innovaciones y a la incorporación de los cambios necesarios para la adecuación de
sus estructuras, roles y funciones, contribuyendo a redefinir nuevas relaciones en el lugar de trabajo y en la forma de
comunicarse trabajar, aprender, generar conocimiento y compartirlo [20], [21], [22]. Asimismo, también resultará
esencial que la coordinación para la IDE se dote de los recursos y mecanismos organizativos y de coordinación
necesarios:
- aprovechar la potencialidad de la red internet como vehículo para la comunicación, coordinación y
aprendizaje, y creando una red de usuarios y prácticas,
- definir los términos de la coordinación y facilitando la cooperación, especialmente en relación a la
compartición de datos y recursos,
- impulsar y asesorar para alcanzar la capacitación técnica de organizaciones y personas
- difundir una visión global de la IDE entre las organizaciones y ayuda a definir unos objetivos e intereses
comunes entre las organizaciones participantes.
- Recabar los apoyos políticos e institucionales necesarios
3.1 Origen
El Servicio de Planeamiento del Área de Urbanismo del Ayuntamiento de Las Palmas de Gran Canaria, a través de su
Sección de Geosistemas, impulsa y coordina desde al año 2000 la denominada Iniciativa SICAM (en adelante, SICAM).
Dicha iniciativa se define como “el conjunto de políticas, estándares, proyectos, acciones, organizaciones y recursos
tecnológicos que faciliten la producción, compartición, acceso y uso de la información cartográfcia de ámbito
municipal”. SICAM tiene como principales objetivos:
1. Promover la generación, compartición, difusión y uso de la GI relativa al municipio de Las Palmas, en aras a
una mejora en la gestión de los recursos, en la eficiencia de los servicios y en la toma de decisiones.
2. Proveerse de los recursos técnicos, humanos, organizacionales y financieros necesarios para ello.
Con la consecución de dichos objetivos, SICAM está aumentando la capacitación de sus participantes a través del
aprendizaje individual y en grupo, conduciendo los cambios en el entorno para propiciar la innovación y la creación de
conocimiento. En definitiva, además de cumplir con sus objetivos específicos, se espera que finalmente contribuya a la
modernización y adecuación al cambio en las organizaciones participantes mediante el impulso de la virtualización
creciente, así como el establecimiento de servicios e infraestructuras para impulsar un modelo de administración
electrónica [24].
Dadas las características particulares de la geoinformación (GI) y de las tecnologías en las que se basa, los objetivos de
SICAM se han ido perfilando, definiendo y adaptando con el tiempo, y se ha incorporado a la iniciativa en forma de
diferentes “proyectos” y acciones sectoriales, departamentales, corporativos, de colaboración y cooperación de distinta
índole. Entre los proyectos de SICAM se encuentran diferentes trabajos y estudios preliminares que han de contribuir
finalmente al establecimiento de la IDE local [25], [26].
SICAM es una iniciativa que se basa en el principio de voluntariedad de participación de las organizaciones que operan
en el municipio de Las Palmas de Gran Canaria (Figura 2). SICAM potencia asimismo la proactividad en la
compartición de datos y experiencias; la compatibilidad de sistemas, la colaboración activa inter e intra-organizacional.
Actualmente, SICAM cuenta con bastante grado de consolidación, e integra muchos de sus proyectos y actividades bajo
un entorno web un Geoportal que hace las veces de nodo de acceso a lo que podríamos considerar la futura IDE de
ámbito local, siendo cada vez son más numerosos los participantes que desean utilizar SICAM a través de la intranet
municipal, incorporándolo en sus rutinas diarias de trabajo [24]. El Geoportal de SICAM, además de facilitar el acceso
a las diferentes aplicaciones y recursos de la iniciativa, hace las veces de entorno de trabajo colaborativo para todos los
socios (Figura 1).
Una de las principales características de SICAM y que le otorga especial solidez es que se trata de una iniciativa que
surgió bajo un enfoque “de abajo-arriba” y sin mandato oficial. Este enfoque ha dado excelentes resultados en
bastantes ocasiones ya que permite [17], [26]:
- a cada organización participante, retener la responsabilidad y propiedad sobre sus datos, elegir las herramientas
informáticas en función de sus necesidades particulares y progresar a su propio ritmo trabajando sobre
elementos ya existentes, pero buscando una armonización futura
- incrementar paulatinamente la capacitación de los participantes
- una implementación escalonada que contemple las diferencias culturales y las circunstancias institucionales
- las prácticas del consenso como método de acuerdo entre organizaciones
- la extensión progresiva de la visión global de la importancia de la GI y la IDE más allá del entorno más
próximo a las personas implicadas.
Por otro lado, este es un enfoque muy recomendado para la implementación de una política sobre GI si lo que se desea
es partir de lo que ya existe e ir integrándolo mediante actitudes pro-activas, esto es: ”no esperar a que ocurra....
¡hacer que las cosas sucedan!” .
PARTICIPANTES EN SICAM
El concepto de Cooperativa de Datos Espaciales (en adelante, Cooperativa) surge con la necesidad de tener que acabar
con los factores que prevenían a muchos actores en la compartición de datos en entornos SIG, y por extensión, dicho
concepto cada vez se está aplicando más para fomentar la compartición de datos bajo un entorno IDE.
Una Cooperativa se define como “una forma de organización más o menos formalizada que tiene como fin propiciar y
animar a las organizaciones la creación, compartición uso y mantenimiento de la GI al menos coste posible” [10]. En
la práctica, la Cooperativa se materializa en forma de geoportal que permite el acceso a GI y aplicaciones y servicios
sobre la misma, posibilitado por las nuevas tecnologías (la red Internet, entre otras) y las nuevas formas de organización
y gestión de la información y el conocimiento [27]. Los elementos clave que distinguen a la Cooperativa de otros tipos
de asociación u organización que puedan surgir entorno a la GI es la responsabilidad en la compartición y en el
mantenimiento de los datos, así como el establecimiento de una serie de reglas del juego que permitan asegurar las
contribuciones acordadas con los participantes, definir los roles y responsabilidades de cada uno de ellos y establecer
las reglas del juego en cuanto a liderazgo y coordinación [11], [21].
Los fundamentos y principios que subyacen en el concepto de Cooperativa pueden alinearse perfectamente con las
recomendaciones en relación a la GI formuladas por instancias de todo tipo en relación a el reuso de la información en
el sector público, la potenciación de la administración electrónica, así como con el objeto de formalizar estrategias
adecuadas para la adecuación al cambio e innovación en las organizaciones [28], [29], [30]. Asimismo, dicho concepto
encaja perfectamente con los marcos teóricos, paradigmas y recomendaciones establecidos desde los ámbitos de la
sociología de las organizaciones, las nuevas tendencias en la gestión de administraciones públicas y las propuestas para
la creación y gestión del conocimiento y difusión de la innovación [31], [32], [33], [34].
Si adoptamos un modelo socio-técnico de Organización en Red para la adecuación al cambio de una administración
local, vemos que la Cooperativa puede jugar un rol fundamental dentro de dicho modelo, tanto para dar soporte a la
nueva estructura de trabajo y crear una comunidad de prácticas entorno a la GI como para generar conocimiento,
compartir datos y experiencias e incrementar la cultura informacional en las organizaciones y en cada una de las
personas que las integran.
La Teoría de Interaccionismo Social se basa en el estudio de cómo las organizaciones operan en situaciones del “mundo
real”, y tratan de entender los aspectos de dicho mundo. Esta teoría contradice muchos de los principios de los marcos
teóricos pertenecientes al ámbito del determinismo económico y tecnológico o de la gestión racioanalista. Los estudios
realizados muestran que las innovaciones que se introducen únicamente en base a su potencial tecnológico raramente
tienen un efecto positivo en las organizaciones, y que los individuos no siempre actúan racionalmente o siguen las
estrategias de sus organizaciones. Esto significa que las innovaciones por sí solas no determinan el éxito de su
implementación. La teoría del interaccionismo social mantiene que las tecnologías no son algo aislado respecto del
contexto en el que se introducen, y que su adopción y efectiva utilización es el resultado de la interacción entre la
tecnología y los potenciales usuarios [35]. Esta teoría no niega la componente técnica de las innovaciones, pero pone
especial énfasis en las capacidades y necesidades de los usuarios y en su participación [9] reconociendo que el proceso
de implementación de una tecnología es además especialmente complejo y problemático debido a los factores
organizacionales, sociales y políticos.
Actualmente, se admite que el éxito de las tecnologías entorno a los SIG/IDE está influenciado por el contexto (sistema
social o sistema de actores), y no depende únicamente del desarrollo de herramientas técnicas perfectas. Por otro lado,
la introducción de una nueva tecnología en tales entornos afecta a la organización de forma que no puede ser anticipada,
pudiendo ahondar en los problemas ya existentes o crear otros nuevos [6], [36].
Desde la perspectiva del interaccionismo social se trata de abordar este problema, y se consideran tres factores críticos:
las estrategias de gestión de la información, los acuerdos y participación de los potenciales usuarios a todos los niveles
y la habilidad de las organizaciones para hacer frente a los cambios ocasionados por la tecnología.
Por definición, una IDE impulsada y coordinada desde la administración pública no puede existir sin la participación de
las diferentes organizaciones que participan en ella, pues su esencia está basada en el establecimiento de marcos de
colaboración y compartición de datos y recursos. Es por ello que los procesos entorno a las IDE se han de considerar en
su componente organizacional, y no únicamente como un factor tecnológico. El enfoque a adoptar en el desarrollo de
una IDE desde la perspectiva de interaccionismo social deberá pues considerar que las circunstancias humanas e
institucionales conducen a considerar múltiples soluciones o aproximaciones posibles (datos, tecnologías, software,
organización...) entre las que se puede elegir en función de factores tanto tecnológicos como financieros, políticos,
humanos u organizacionales. La perspectiva de interaccionismo social lo consideramos adecuado en nuestro caso ya
que está comprobado que las elecciones fundamentales entorno a la GI, la determinación de objetivos y prioridades se
traducen casi siempre en decisiones intuitivas, no formalizadas, implícitas y son ocultadas en el contexto de espacios de
poder entre personas, grupos y organizaciones [6], [32], [37].
Los SIG corporativos y más recientemente las IDE han demostrado que pueden poner en valor su capacidad
transformacional sobre toda la organización, potenciando la colaboración inter e intra-organizacional, cimentando la
modernización de los gobiernos e incrementando el acceso a la información del sector público. Es por ello que una IDE
puede convertirse en un potentísimo motor de cambio y adecuación para todas las organizaciones participantes, y
especialmente en el ámbito de una administración local [7], [29], [36], [37].
En una administración moderna, reformar consiste en gestionar el cambio; cambio en organizaciones y cambio en
las relaciones de trabajo entre las redes de organizaciones. Éstos cambios son muy complejos y difíciles de llevar a
cabo. De los trabajos realizados por Johson (GeoData Alliance) [38] entorno al desarrollo de inicitivas IDE, podemos
extraer las siguientes lecciones:
- Como en cualquier entorno altamente técnico, es necesario adaptar la tecnología con soluciones locales El
cambio tecnológico requiere de cambios en los procesos y en las estructuras organizacionales y
administrativas.
- La sensibilidad a una situación de cambio vertiginoso e incertidumbre conduce a la tendencia de muchas
organizaciones y personal a rechazarlo. Es crucial tratar todos los aspectos relacionados con las implicaciones
del cambio tecnológico y hacer concurrir las actividades con un realineamiento del personal y la organización.
- El estado de un proyecto necesita frecuentemente ser demostrado y comunicado a todos los participantes y
líderes. Las expectativas han de ser gestionadas a nivel operacional, de gestión y administrativo.
- Finalmente, se ha de alimentar la cultura de compartición y de adecuación al cambio.
La Gestión de Conocimiento (GC) es una disciplina que se basa en el estudio de la gestión de los nuevos recursos clave
(conocimiento y tiempo), en la potenciación de las nuevas habilidades, competencias y actitudes necesarias en los
profesionales y en la incorporación en las organizaciones de las nuevas formas y entornos de trabajo personal y de
grupo. El objetivo final de la GC es poner a disposición de cualquier persona toda la información y experiencia de su
organización, sin limitaciones de lugar o tiempo. Para conseguirlo, será imprescindible transmitir una “nueva visión”
dentro de la organización, de manera que se potencie la implantación de las bases de conocimiento e infraestructura
tecnológica necesaria que permita recopilar, elaborar, divulgar y reutilizar todo posible conocimiento [33], [39], [40].
El establecimiento de un modelo global basado en la aplicación de los conceptos y herramientas de la GC y que esté
orientado en general a la geomatización de una organización o al desarrollo de una IDE puede contribuir a gestionar el
cambio de una manera eficiente y superar las barreras organizacionales que surjan, aplicando para ello los principios y
herramientas de la GC a todas aquellas actividades y procesos que permitan generar, buscar, difundir, compartir, utilizar
y mantener el conocimiento espacial.
El modelo SURICATA (Proyecto TSI2004-o5949, cofinanciado por el Ministerio de Educación y Ciencia, y Fondos
Feder de la Unión Europea, en adelante, SURICATA) es un modelo socio-técnico de Organización en Red desarrollado
por el CICEI (Centro de Innovación para la Sociedad de la Información de la Universidad de Las Palmas de Gran
Canaria), y que se basa en los principios y herramientas de la GC [8], [33]. SURICATA tiene como objetivo global el
de “desarrollar métodos y herramientas de apoyo a los trabajadores del conocimiento, en su vertiente personal y
corporativa, que les permita aumentar su productividad y capacidad de innovación, en el contexto de una estrategia
global de gestión del conocimiento orientada a procesos”.
Este modelo surge ante la necesidad de dar respuesta ante un nuevo contexto en el que se exigen nuevas habilidades,
conocimientos y actitudes por parte del trabajador del conocimiento y la adopción de nuevas formas y entornos de
trabajo en el ámbito de nuevas formas organizacionales emergentes. SURICATA contempla el proceso de implantación
de una estrategia global de conocimiento para el ámbito de una organización que se caracterice por tener que
experimentar un proceso de virtualización creciente a lo largo del tiempo en el contexto de una nueva realidad (tránsito
hacia la economía del conocimiento), caracterizada por estar polarizada en las personas (relaciones interpersonales),
donde son de la mayor importancia las ideas, innovación, coordinación y la tecnología, y poniendo un énfasis sin
precedentes en el valor del aprendizaje.
Como conceptos y elementos más característicos del modelo SURICATA, podemos destacar: e-conocimiento;
ecosistema de gestión del conocimiento (personas, procesos, contenidos, tecnología); estándares; iniciativas abiertas
(‘open source’, ‘open contens’); interoperabilidad de sistemas, aplicaciones y contenidos; repositorio de e-contenidos;
comunidad de práctica; aprendizaje informal; gestor personal y corporativo de información y de conocimiento.
SICAM es una iniciativa que surgió de una manera informal y voluntaria, con el objeto de hacer frente a una serie de
retos relacionados con la GI. Al comienzo de su trayectoria se plantearon muchas incógnitas acerca de cuál era el mejor
modo de formalizar su estructura organizativa y de coordinación que le permitieran avanzar con paso firme y ordenado
hacia la consecución de sus fines. Como respuesta a ello, se formuló la necesidad de dotarse de un marco de trabajo
cuyo principal objetivo era el de propiciar la compartición de datos y conducir las tareas de coordinación de SICAM.
Para ello, tras el estudio de casos similares, se vió como adecuado la adopción de un modelo organizativo de tipo
“Cooperativa de Datos Espaciales”, ya que resultaba el más adecuado para el entorno de una administración local de las
características del ayuntamiento de LP y reunía todos los requisitos necesarios para actuar a modo de ”estrategia” para
la implantación exitosa de la futura IDE, con especial consideración de las barreras organizacionales que se preveen
encontrar.
La CoS se define como el marco organizativo que “contribuye a disponer de una capacidad integrada y
tecnológicamente avanzada para la adquisición, procesamiento, gestión y difusión de GI, apoya las necesidades de
coordinación, comunicación y desarrollo de la Iniciativa SICAM, y contempla las necesidades de sus usuarios para
desarrollar e implementar las funciones y servicios que les son propios”.
Y sobre todo, no perder de vista que quizás el aspecto más importante de la puesta en marcha y progreso de una
estrategia basada en el establecimiento de una Cooperativa es que los los procesos mentales y transformaciones
intangibles que desencadena son tanto o más importantes que los resultados o beneficios que genera [41].
La Cooperativa SICAM comenzó siendo la estructura adoptada para la facilitar la coordinación, compartición de datos y
recursos y la cooperación entre los integrantes del SIG Corporativo del Ayuntamiento de Las Palmas de Gran Canaria.
Con el transcurso del tiempo, su filosofía, principios y experiencia la muestran como un elemento clave en el desarrollo
de la futura IDE del municipio de Las Palmas, especialmente por sus contribuciones para sortear las mayores barreras
organizacionales existentes, tales como la poca disposición general para compartir datos y recursos, la inercia y rigidez
institucional y las fórmulas de trabajo poco adecuadas para la interacción, el trabajo en red, el aprendizaje individual y
en grupo y la difusión de la innovación.
Mientras que el argumento económico (ahorro de costes) es el que en principio induce a las organizaciones la
compartición de datos, las alianzas colaborativas entorno a la CoS han sido también motivadas por las necesidades
concretas de sus participantes y las capacidades de los mismos. Es por ello apelando a la profesionalidad y objetivos
comunes y propiciando la creación de sinergias se ha conseguido poco a poco que estas sean las razones no económicas
más importante que encuentrar sus participantes a la hora de compartir datos y experiencias y cooperar en la iniciativa.
Para alcanzar este grado de complicidad y cooperación de los participantes, desde la coordinación de SICAM se ha
intentado en todo momento plantear objetivos y metas comunes compatibles con los objetivos particulares de cada
organización, basándose siempre en el diálogo y el consenso, así como en las oportunidades que han surgido en cada
momento. Para ello, se han tomando las medidas necesarias para que los socios no vean en su participación una pérdida
de autonomía, evitando situaciones no deseadas y maximizando los beneficios para todos, de manera que a lo largo de
los últimos años se han ido forjando con los años redes interpersonales, interorganizativas y profesionales basadas en el
uso intensivo de las posibilidades de la red, establecimiento de grupos de trabajo, reuniones informativas, actividades
formativas y de divulgación y difusión, así como acuerdos internos y externos, no siempre formalizados, pero que en
conjunto han dado muy buen resultado a la hora de evitar conflictos de intereses, competenciales o de distribución de
poder.
Destacar asimismo que desde la CoS se está consiguiendo lo que en un principio parece ser la mayor barrera
institucional, que es el de la “redefinición” de procesos y tareas internos, cambiando el flujo de información y de trabajo
de los diferentes servicios municipales, sin que ello suponga ser percibido como una amenaza competencial o
profesional: los cambios son paulatinos, no traumáticos y son aceptados de muy buen grado, puesto que se asumen en
aras a una mayor eficiencia en el servicio público y como la contribución a la necesaria modernización y adecuación al
cambio de las organizaciones.
5.- CONCLUSIONES
No obstante, somos conscientes de que esta estrategia cuyo fin es el desarrollo de una IDE local necesariamente ha de
integrarse en el ámbito de una estrategia global de gestión del conocimiento, como respuesta de adecuación a nivel
organizacional. Para ello resulta muy adecuada la integración de la CoS en la propuesta del modelo socio-técnico global
SURICATA, el cual proporciona como elementos: a) visión conceptual, b) metodología de gestión del conocimiento
orientada a procesos, y c) entorno de gestión de conocimiento, a partir de una intranet colaborativa, contribuyendo con
ello de manera significativa a las estrategias para la modernización de todos los servicios municipales, especialmente en
lo que respecta a la completa y efectiva informatización de todos los servicios municipales y la progresiva
incorporación de las funciones de los mismos a prácticas de administración electrónica.
REFERENCIAS
[1]. Castells, M. (1997). La Era de la Información. Economía, Sociedad y Cultura.Vol. I. La Sociedad Red. Alianza, Madrid.
[2]. Chan, TO et al. (2001). Chan, T.O. et al. (2001). The Dynamic Nature of Spatial Data Infrastructures: A Method of Descriptive
Classification. Department of Natural Resources and Environment, Victoria, Australia. En:
http://www.sli.unimelb.edu.au/research/publication/IPW/4_01Chan.pdf
[3]. Grimshaw, DJ. (2000). Bringing Geographical Information Systems into Business. John Wiley & Sons. Nueva York, 2000.
[4]. Williamson, I. et al (2003). Developing Spatial Data Infrastructures: From concept to reality. Editado por Ian Williamson,
Abbas Rajabifard y Mary Ellen F. Fenney. Taylor & Francis. London, 2003
[5]. Rajabifard, A. (2002). Diffusion of Regional Spatial Data Infrastructures: with particular reference to Asia and the Pacific.
Tesis Doctoral. Department of Geomatics. The University of Melbourne. March, 2002
[6] Pornon, H. (1998). Systèmes d´Information Géographique, Pouvoir et Organizations. L´Harmatan. Paris, 1998.
[7]. Reeve, D. y Petch, J., 1999. GIS Organizations and People. A Socio-technical Approach. Taylor & Francis, London.
[8]. Morant, t. ET AL (2005). “Bases para el éxito del SIG Corporativo: aportaciones desde el ámbito de la gestión del
Conocimiento”. 6ª Semana Geomática Barcelona. Barcelona, Enero 2005. En: http://www.setmana-
geomatica.org/front/abstracts
[9]. Chan, T.E. y Williamson, I.P. (1997). Definition of GIS: the manager´s perspective. International Workshop on Dinamic and
Multidimensional GIS. Hong Kong, 1997. En http://www.geom.unimelb.edu.au/research/publications/IPW/DGISMP.htm
[10] Johnson, B. 1997. “The NYS GIS Data Sharing Cooperative. A Innovative New Model for Data Sharing and Partnerships”,
1997. En http://nysgis.state.ny.us/coop_gis.htm)
[11].Jonson, R. et al. (2001). Lessons from Practice. A Guidebook to Organizing and Sustaining Geodata Collaboratives. GeoData
Alliance. En www.geoall.net
[12].FDGC (1997). A Strategy for the NSDI. Federal Geographic Data Committe. Gobierno de los Estados Unidos, 1997. En:
http://www.fgdc.gov/nsdi/strategy/strategy.html
[13].Masser, I. y Campbell H. (1995). “Information Sharing: the effects of GIS on British Local Government”. En Sharing
Geographic Information. Editado por Onsrud HJ y Rushton, G. Center for Urban Policy Research. New Brunswick, New Jersey,
1995.
[14].Gould, M. (2005). Infraestructuras de Datos Espaciales (IDE). I Jornada gvSIG. En
http://www.gvsig.gva.es/espa/jornadas/Infraestructuras_de_Datos_Espaciales.pdf
[15].Wenh, U.(2003). Mapping the Determinants of Spatial Data Sharing. TNO Strategy, Technology and Policy. Delft,
Netherlands. En http://www.stb.tno.nl/index.php?pointer=1-2-1675-1676-1755-2350
[16].Harvey, F. y Tulloch, D (2003). Building the NSDI at the Base: Establishing Best Sharing and Coordination Practices among
Local Governments. Proyect Report. Federal Geographic Data Committee. Minneapolis, New Brunswick. Abril 2003. En:
http://www.tc.umn.edu/~fharvey/research/BestPrac4-03.pdf
[17].GINIE (2003). Infraestructuras de Datos Espaciales: Recomendaciones para entrar en acción. Geographic Information
Network in Europe. Informe realizado por la Universidad de Shefield, European Umbrella Organization for Geographic
Information (EUROGI), Joint Research Centre of the European Commission (JRC) y Open GIS Consortium Europe (OGCE).
En www.ec-gis.org/ginie
[18].Arbonies, AL. (2001). Cómo evitar la miopía en la Gestión del Conocimiento. Díaz de Santos. Madrid, 2001.
[19].Brugué, Q. et al. (1998). Gobiernos locales y políticas públicas. Bienestar social, promoción económica y territorio.
Coordinado por Quim Brugué y Ricard Gomá. Ariel S.A. Barcelona, 1998.
[20].GINIE (2002). Políticas de Información Geográfica en Europa: Recomendaciones para entrar en acción. GINIE (Geographic
Information Network in Europe). Informe realizado por la Universidad de Shefield, European Umbrella Organization for
Geographic Information (EUROGI), Joint Research Centre of the European Commission (JRC) y Open GIS Consortium Europe
(OGCE). En http://www.ec-gis.org/ginie
[21].Zorica, N-B. y Pinto, J.K. (1999). Interorganizational GIS: Issues and prospects. The Annals of Regional Science. Springer-
Verlag. (1999) 33:183-195
[22].Harvey, F. (2001). Constructing GIS: Actor Networks of Collaboration. URISA Journal. Vol.13, Nº1.
[23].Cerpa, JM y Carretero, I. (2000). El Plan General de Las Palmas de Gran Canaria y su Sistema de Información Geográfica. En
Ciudad y territorio. Estudios Territoriales. Minusterio de Fomento. Vol.XXXII. Tercera época. Nº 124, 2000.
[24].Carretero, I. (2004). Geoinformación de Las Palmas de Gran Canaria. Reunión de Usuarios de Intergraph. Madrid, 2004.
[25].Morant, T. et al. (2005) Propuesta de un marco de coordinación para el Proyecto SICAM (v.0). Iniciativa SICAM. Servicio de
Planeamiento. Ayuntamiento de Las Palmas de Gran Canaria. Las Palmas de Gran Canaria, 2005.
[26].Morant, T. et al. (2005) Propuesta para el establecimiento de un Modelo de Distribución de Geoinformación desde SICAM
(v.0). Iniciativa SICAM. Servicio de Planeamiento. Ayuntamiento de Las Palmas de Gran Canaria. Las Palmas de GC, 2005.
[27].Maguire, DJ. Y Longley, PA (2005). Geoportals. Computers, Environment and Urban Systems. Elsevier Science Direct. Vol.
29, Issue 1, pg 1-85. enero 2005.
[28].INSPIRE (2004). Iniciativa INSPIRE - Infrastructure for Spatial Information in Europe. Comisión XIII, Unión Europea. En
http://www.ec-gis.org/inspire/
[29].Craglia, M. (2003). GI in the wider Europe. En: www.ec-gis.org/ginie
[30].Geographic Information Network in Europe, GINIE. En: www.ec-gis.org/ginie
http://europa.eu.int/information_society/eeurope/2005/all_about/egovernment/index_en.htm
[31].Krieger, M. (2001). Sociología de las organizaciones. Una Introducción al comportamiento organizacional. Pearson Education
S.A. Buenos Aires, Argentina, 2001.
[32].Bacigalupo, A. et al. (2002). Problemas actuales de la Administración Local. Constitución y Leyes, S.A. Madrid, 2002.
[33].Rubio, E. (2004). Modelo Suricata. “Productividad Personal/corporative en entornos intensivos en INF y K: e-
KNOWELEDGE”. Seminario “Formación y Competitividad. Un enfoque basado en la Gestión del Conocimiento, el trabajo
Cooperativo y las Tecnologías de la Información”. Universidad Politécnica de Madrid. Madrid, 2004.
[34].Petrizzo, M. y Ramilo, M. (2004). “¿Hacia qué e-Administración nos dirigimos?”. II Congreso ONLINE de lÓbservatori pera a
la Cibersocetat. En: http://www.cibersociedad.net/congres2004/
[35].Manesha M.N. (1998). A Framework for multiparticipant GIS program. Master in Urban and Regional Planning. State
University of Virginia. Estados Unidos de América, 1998.
[36].Huxold W.E. y Levinson, A.G.(1995). Managing Geographic Information Systems Projects. Oxford University Press. Nueva
York.
[37].Chevallier, J-J y Caron, C. (2002). Dévelopment dínfrastructures géomatiques: déterminisme technologique ou approche
holistique. Symposium sur la théorie, les traitements et les applications des donnés Géospatiales. Otawa, Canadá, 2002.
[38].Johnson, R. y Nevodic-Budic, Z. (2002). Lessons from practice: organizational aspects of data sharing. Geodata Alliance. En
http://www.geoall.net/what_we_do.html
[39].Domingo, J. (2003) Conocimiento y gestión: La gestión del conocimiento para la mejora de las personas y las organizaciones.
Pearson Prentice Hall, Madrid
[40].Peluffo, M. y Catalán, E., 2002. Introducción a la gestión del conocimiento y su aplicación al sector público. Instituto
Latinoamericano y del Caribe de Planificación Económica y Social. Naciones Unidas. En http://unpan1.un.org
[41].Hendriks, P.H.J. (1998). Information strategies for Geographical Information Systems. International Journal for Geographical
Information Science. Taylor & Francis. 1998, Vol.12, nª 6, 621-639
[42].Carretero, I. (2002). “Publicación Digital del PG Municipal de Ordenación de LPGC”. Mapping, nº79. Julio, 2002. En:
http://www.mappinginteractivo.com/plantilla.asp?id_articulo=164&titulo=&autor=carretero&contenido=&tipo=avanzado
[43].Warnest, M. Et al. “Local and state-based collaboration: the key to unlocking the potential of SDI”. Spatial Sciences 2003
Conference, 22-26 September, Canberra, Australia. En
http://www.geom.unimelb.edu.au/research/publications/IPW_online_publ.html#spatial_infrastructures
[44].Rajabifard, A. et al (2002). The Cultural Aspects of Sharing and Dynamic Partnerships within an SDI Hierarchy. Centre for
Spatial Data Infrastructures and Local Administration, Department of Geomatics, University of Melbourne, Australia. En:
http://www.geom.unimelb.edu.au/research/SDI_research/
[45].Eglene, O. y Dawes, S. (1998). New Models of Collaboration GIS Coordination in New Cork State. Center for Technology in
Government. 1998. http://www.nygis.state.ny.us/collabor.htm.
[46].Nevodic-Budic Z. et al. (2004). Are SDIs serving the needs of local planning?. Case study of Victoria, Australia and Illinois,
USA: Computers, Environment and Urban Systems. Elsevier. 28 (2004) 329-351
[47].GINIE (2004). Informe Directivo Infraestructuras de Datos Espaciales: de lo Local a lo Global. Recomendaciones para entrar
en acción. Geographic Information Network in Europe. Informe realizado por la Universidad de Shefield, European Umbrella
Organization for Geographic Information (EUROGI), Joint Research Centre of the European Commission (JRC) y Open GIS
Consortium Europe (OGCE). En www.ec-gis.org/ginie
Resumen: Este artículo describe experiencias y lecciones aprendidas durante la implementación de una de las
primeras Infraestructuras de Datos Espaciales (IDE) locales en España. Este trabajo parte de un análisis que ha
revelado situaciones prototípicas de la administración pública local relacionadas con la situación de la información
geográfica. Durante su implementación se han determinado que existe una serie de componentes claves relacionados
con aspectos tecnológicos, políticos, humanos y de interrelación con otras IDEs que quedan determinados por las
características de la administración local. El resultado final se ha materializado en un geoportal que mejora el trabajo
de los técnicos del ayuntamiento y provee servicios a los ciudadanos sobre la base de información geográfica.
INTRODUCCIÓN
Desde hace pocos años, y en número creciente, organizaciones internacionales promueven políticas de inversión e
investigación en datos espaciales, en las infraestructuras que los producen y en su uso por instituciones públicas, grupos
sociales y ciudadanos individuales. La principal conclusión de este movimiento es la necesidad de crear una
infraestructura de datos, servicios, estándares y acuerdos entre los creadores de la información espacial, más conocida
como Infraestructura de Datos Espaciales (IDE), para optimizar la creación y explotación de la información espacial.
En Europa, este movimiento se ha visto reflejado su base en directivas comunitarias ya aprobadas o en desarrollo (por
citar las más importantes INSPIRE1 y la de ruido ambiental2) que requieren para su adecuado cumplimiento el
desarrollo de infraestructuras de información espacial en cada administración pública. Durante los próximos años todas
las administraciones deberán realizar pasos efectivos para implementar sus respectivas IDE e integrarlas con el resto de
IDEs locales, regionales y nacionales. De hecho en España ya existe una IDE nacional (IDEE, http://www.idee.es) y
han comenzado los pasos para crear IDEs a nivel regional (IDEC en Cataluña, http://www.geoportal-idec.net, o IDENA
en Navarra, http://idena.navarra.es).
Desde el punto de vista de la administración local el concepto de IDE se ve como algo lejano en el tiempo o incluso
extraño, más propio de niveles regionales o estatales con responsabilidad de organizar el territorio. Los políticos y
aquellos con responsabilidad en la toma de decisiones necesitan que se les demuestre cómo este tipo de infraestructuras
tiene beneficios económicos y medioambientales, por ejemplo reduciendo la duplicación y el gasto en recursos o
mejorando la gestión del entorno urbano. Implicar a las administraciones locales es esencial para el éxito de la jerarquía
de IDEs por ser los responsables principales de la creación de la mayor parte de la información espacial con relevancia
directa para el ciudadano (son soporte para servicios públicos dirigidos por la localización como aguas, basuras,
sanidad, educación, correos…)3.
Antes de 2004 la Concejalía de Ciencia y Tecnología del ayuntamiento de Zaragoza sospecha la necesidad de
reorganizar su información espacial mediante el establecimiento de una estrategia de común a todos los departamentos
del ayuntamiento que tuvieran algún tipo de relación con la información geográfica. La Infraestructura de Datos
Espaciales de Zaragoza (IDEZar, http://www.zaragoza.es/idezar) es la consecuencia del proceso que puso en marcha.
Este artículo se organiza como sigue. Inicialmente describe la aproximación del ayuntamiento de Zaragoza a las IDEs
así como el resultado de las primeras iniciativas. A continuación describe las acciones efectivas realizadas a nivel
tecnológico, institucional, de usuarios e interinstitucional. Estas acciones son sustentadas por componentes tecnológicos
que son analizados con más detalle. Finalmente se describen las conclusiones y futuros pasos.
A principios de 2004 la Concejalía de Ciencia y Tecnología decide dar los pasos necesarios para crear una IDE local.
Detectan que la complejidad del cambio requiere de apoyo tecnológico para diseñar e implementar un mecanismo que
permita compartir fácilmente información espacial no solo entre los departamentos, sino entre el ayuntamiento y los
ciudadanos, así como otras administraciones. Para tal fin firma en marzo del mismo año un convenio de colaboración
con la Universidad de Zaragoza. Los principales objetivos de este convenio son:
• la realización de un análisis en profundidad de los datos espaciales del Ayuntamiento y de sus usos;
• la elaboración de una propuesta tecnológica para el desarrollo de una IDE local;
• la creación de dos comités, uno a nivel político, para promover la implantación de la IDE, y otro a nivel
técnico, para aconsejar sobre aspectos técnicos de la misma a nivel de datos, modelos, procesos y estándares; y
• la definición de políticas para el acceso y la adquisición de datos espaciales dentro del Ayuntamiento.
Resultado final de todas estas acciones será facilitar y coordinar el intercambio y el uso compartido de datos espaciales
entre todos los actores del Ayuntamiento implicados e impulsar la construcción de un sistema de información Web
capaz de ofrecer un amplio rango de servicios a los ciudadanos.
La primera consecuencia del convenio es la realización de un análisis en profundidad de los productos espaciales y
sistemas de información geográfica (SIG) del Ayuntamiento. Resultado de este trabajo preliminar, la compleja situación
de la información espacial, como de los procesos y relaciones institucionales involucradas, se hace visible. Por ejemplo:
• falta de un inventario de datos; esta situación permite la existencia de datos espaciales obsoletos y “perdidos”
(se tardó meses en “descubrir” la existencia de algunos datos);
• falta de datos y recursos SIG esenciales, incluidos los recursos humanos;
• intercambio de información hacia el público solo en formatos no SIG (con especial predilección por el formato
Adobe PDF);
• aplicaciones cerradas con capacidades SIG que suministran información obsoleta hacia el público;
• no existen procesos definidos para la creación, mantenimiento y acceso a datos espaciales;
• cuellos de botella en los flujos de trabajo por la falta de personal cualificado; y
• diferentes estrategias departamentales SIG sin relación entre si en el Ayuntamiento.
Entre otras cosas, esta compleja situación confirma la necesidad de establecer una política común a todos los
departamentos del ayuntamiento en materia de información geográfica.
ACCIONES EFECTIVAS
Las conclusiones del estudio previo muestran la necesidad de un cambio institucional de calado para dar oportunidad al
desarrollo de una IDE. Las acciones encargadas de realizar el cambio se agrupan como sigue:
Nivel tecnológico
La arquitectura técnica de la IDE (figura 1) se organiza mediante dos criterios ortogonales: un criterio funcional (datos,
servicios, aplicaciones internas y externas) y un criterio departamental (siguiendo la estructura organizativa del
ayuntamiento).
Esta organización técnica nos permite organizar mejor la interoperabilidad. Podemos concebir la organización del
ayuntamiento como un serie de celdas temáticas en la que celda corresponde con un departamento. Cada una de ellas
posee datos y aplicaciones que sólo tienen sentido dentro de ese departamento. Además necesitan el respaldo de datos
que son de uso común por los departamentos del ayuntamiento o son producidos en exclusiva por otros departamentos.
Para evitar las particularidades de cada uno de los departamentos (ya sean en usos, ya sea en datos), la información se
intercambia utilizando exclusivamente el nivel de los servicios de acuerdo con el paradigma de Arquitectura Orientada
a Servicios4 (Service Oriented Architecture – SOA) y la Web Services Architecture5 (WSA) impulsada por Open
Geospatial Consortium (OGC).
Los servicios Web definidos son reutilizables y operan entre si mediante siguiendo estándares abiertos definidos sobre
protocolos y formatos Web ubicuos como HTTP, XML y SOAP. Esta elección facilita afrontar la inherente complejidad
de la interoperabilidad y permite la implementación de un amplio rango de aplicaciones y herramientas basadas en la
IDE para crear y mantener la información espacial existente.
Emergencias
Infraestructuras
Nivel aplicaciones
Application
Aplicación
Medio
Ambiente
OGC
OGC
WCS
WCS
OGC
OGC OGC
OGC OGC
OGC Nivel servicios
Servicios
Core WMS
WMS WFS Catalog
Catalog
Básicos
Services
Urban
Urbanismo
Management
Organización departamental
Cartografía Datos Metadatos Nivel datos
Como soporte de toda la organización hay un nodo de servicios básicos cuya misión es proporcionar las servicios
(cartografía básica, cartografía para referenciar datos, metadatos de la información geográficos disponible) que sirven la
información espacial utilizada en todos los departamentos y un conjunto de aplicaciones básicas de búsqueda y
georreferenciación. Anteriormente tanto la información y como las herramientas se replicaban en cada uno de los
departamentos con los consiguientes problemas de actualización, calidad, etc.
En esta primera etapa se han implementado dos nodos (otros nodos están actualmente en desarrollo):
Nivel institucional
Es necesario un impulso institucional de la IDE mediante un armazón institucional que tutele su desarrollo. Este
armazón tiene dos vertientes, una política y otra técnica, que se plasman en los respectivos comités.
El comité político traza las líneas estratégicas comunes en información geográfica además de realizar tareas de
sensibilización sobre la importancia de una estrategia única en esta materia dentro de la administración local. Para ello
ha iniciado el proceso que llevará a la definición de las responsabilidades, políticas y acuerdos administrativos en
materia de datos, procedimientos y pliegos de contratación. Otras de sus responsabilidades es el impulso de acuerdos de
intercambio con otras IDEs e iniciativas de datos espaciales. Por ejemplo, recientemente aprobó de la participación de
IDEZar en el proyecto GMES Urban Services (GUS, http://www.gmes-urbanservices.com/) de la Agencia Espacial
Europea. Este proyecto pretende consolidar una nueva cartera de productos y herramientas GIS que facilite a las
autoridades municipales orientar el planeamiento estratégico urbano teniendo en cuenta los temas medioambientales.
Un segundo ejemplo es el impulso del desarrollo una aplicación turística que ha de permitir a los usuarios de
dispositivos móviles con tecnología Wireless acceder a información basada en Web proporcionada por la IDE. Tras esta
propuesta hay un deseo de integrar en la IDE las plataformas de software y hardware basadas en dispositivos móviles,
sensibles a la localización y capaces de funcionar en tiempo real.
Por su parte, el comité técnico asesora al comité político en todos los aspectos tecnológicos sobre la base de las pautas
técnicas descritas en el nivel tecnológico. Ello obliga a detallar cómo deben ser los datos (formatos, precisión y
calidad), los procedimientos (creación de datos, adquisición, mantenimiento, intercambio, acceso y seguridad), los
estándares técnicos, y las tecnologías (hardware, software y plataformas ubicuas) así como qué servicios y aplicaciones
son prioritarias, siempre sin perder de vista la arquitectura WSA de OGC.
Nivel de usuarios
El desarrollo de una IDE tiene entre sus tareas fundamentales conocer a sus usuarios para descubrir sus necesidades y
proveer herramientas en la IDE orientadas a los mismos. Para ello hay que:
En relación con las necesidades de los usuarios, se ha encontrado un amplio rango de casos de uso y aplicaciones como
resultado del primer análisis. Se puede señalar:
• el acceso visual por parte de los ciudadanos a la cartografía e infraestructura urbana, con la visualización de
puntos de interés gestionados por el ayuntamiento como los centros municipales; este caso se puede extender
enlazando ciertas áreas o puntos con recursos electrónicos relacionados.
• el acceso por parte de usuarios técnicos a los datos cartográficos básicos de forma visual: cartografía a nivel
catastral y urbano, elementos urbanos, elementos de infraestructura y ortoimágenes;
• un callejero urbano sensible a la organización territorial del municipio; en el caso de este ayuntamiento, la
creación de vistas del callejero digital restringidas a juntas de distritos y juntas rurales;
• generación de información georreferenciada mediante aplicaciones Web;
• la búsqueda y consulta de información sobre los productos espaciales disponibles de un departamento;
• la difusión de información espacial relacionada con medio ambiente (zonas protegidas, parques eólicos); y
• la visualización de las posiciones de las redes de control de la contaminación ambiental.
A partir del estudio de los casos de uso solo se han caracterizado dos perfiles básicos de usuarios:
Esta clasificación será más compleja en un futuro próximo en función de las funcionalidades demandadas, el nivel de
responsabilidad en la toma de decisiones, las políticas de seguridad, el área de interés o criterios de organización. Por
ejemplo, la categoría de ciudadanos puede contener las subcategorías de ciudadanos de Zaragoza y turistas. Esta última
se puede volver a especializar en turistas españoles, turistas europeos, turistas con dominio del español. De otro lado, el
perfil de miembros de la administración local puede especializarse en técnicos, gestores, proveedores de datos y
servicios, responsable de departamentos, etc.
Finalmente, la experiencia de los usuarios, en función de su perfil, les califica como testadores de calidad, fuentes de
mejoras y de nuevos casos de uso. En este caso es muy importante tomar en cuenta los cuatro principios para mejorar la
usabilidad: eficiencia, eficacia, satisfacción y accesibilidad. Este último de relevancia dentro del contexto de la
administración local por el deber de hacer accesible los servicios electrónicos de la administración del estado6.
Nivel interinstitucional
La relación interinstitucional es la piedra de toque de las IDE7. La jerarquía crea un entorno en el cual los datos son
creados y mantenidos dentro del nivel y utilizados por otros niveles en función de temas, escalas, actualidad y cobertura
de la información necesitada.
En esta primera fase se ha planteado como objetivo suplir alguno de los datos cuya falta se ha detectado mediante el
acceso a servicios de IDEs regionales y nacionales. Por ejemplo, el análisis preliminar muestra la falta de datos urbanos
a escala media (1:20000) o fotografías aéreas que cubran la ciudad y su amplio término municipal. Por esta razón, una
de las acciones fue mejorar solicitar a iniciativas aragonesas de datos espaciales y a la IDEE aquellos datos que
faltaban. A nivel regional se integra fotografías aéreas de la ciudad de Zaragoza y datos medioambientales relacionados
con el término municipal (flora y fauna, aerogeneradores, espacios protegidos). A nivel nacional se integra datos
urbanos de media y gran escala (1:20000 – 1:200000). La propuesta tecnológica de interoperabilidad que sigue IDEZar
ha simplificado esta integración jerárquica (figura 2) dado que todas las IDEs accedidas siguen los mismos paradigmas
tecnológicos.
Nodos interorperables
(interfaces estándar)
Nivel nacional
IDEE
Nivel regional
iniciativa aragonesa IDEZar
de datos espaciales
Nivel local
SB
Estos son los primeros pasos en el esfuerzo de crear la malla de relaciones de coordinación y comunicación entre los
diferentes agentes, tanto hacia arriba en la jerarquía como hacia abajo, hacia las IDEs corporativas de empresas que
interactúan con el ayuntamiento.
Los primeros esfuerzos en componentes tecnológicos que implementan los criterios arquitecturales que se han descrito
en los apartados anteriores (arquitectura de orientada a servicios, estándares OGC, división funcional y por
departamentos, interoperabilidad) se plasman en una serie de esfuerzos en catalogación, transformación y creación de
datos, la implementación de servicios que los hacen accesible y en el diseño y construcción de portales y aplicaciones
accesibles por el ciudadano o por técnicos del ayuntamiento.
Datos y metadatos
El estudio previo había detectado que al no existir una política general del ayuntamiento sobre la creación y explotación
de datos geográficos no existía un catálogo o inventario de los datos existentes. Hay que señalar que el volumen de
información espacial dentro de un ayuntamiento es enorme. De un lado está la información urbanística y de
planeamiento. Por otro información sobre las infraestructuras que mantiene el ayuntamiento. Además, y esto es
relativamente reciente, un volumen cada vez mas creciente y variado de información medioambiental.
Para afrontar la situación se han seguido dos estrategias de incorporación de datos a la IDE:
La primera estrategia se aplica, considerando la situación detectada, sobre los datos de la cartografía básica y los
relacionados con las direcciones que formarán parte del nodo de servicios básicos. Además, con el fin de desarrollar un
nodo temático piloto, se decide incorporar también los datos del departamento de Medio Ambiente.
Una vez acotado el qué hacer, se elabora y se sigue una estrategia para acometer la tarea. Esta consiste en:
• mediante un trabajo de campo, recopilar datos espaciales e información contextual sobre ellos;
• puesta de los datos recopilados bajo control con el fin de organizar todo el trabajo de análisis, catalogación y
posibles transformaciones de los datos;
• análisis de alto nivel de cada uno de los datos para descubrir a que nodo debe realmente pertenecer, descubrir
potenciales usos de los datos, detectar potenciales procesos de transformación y ordenar la tarea en función de
las prioridades;
• creación de metadatos de cada uno de los datos relevantes (siguiendo el estándar Dublin Core8) para su
posterior incorporación en un catálogo de metadatos;
• creación de almacenes de datos organizados por formatos y temáticas;
• transformar datos relevantes de formatos no SIG (ficheros de texto, formatos CAD) a formatos SIG; y
• selección de aquellos datos que son susceptibles de incorporarse a servicios de mapas.
Durante la ejecución de esta primera estrategia aparece con fuerza el problema de falta de compatibilidad y
homogeneidad entre los datos obtenidos de los diversos departamentos del ayuntamiento y datos producidos por otras
administraciones. Esto provoca trabajo extra de limpieza, alineación y verificación. En muchos de los casos estos
problemas estaban relacionados con identificadores básicos de naturaleza espacial (calles, números de policía).
La problemática detectada impulsa el diseño de una segunda estrategia. Un modelo de datos urbanos que garantice la
normalización de identificadores básicos de naturaleza espacial. Los elementos básicos de este modelo serán tanto
elementos de localización urbana, identificadores catastrales y divisiones zonales del municipio. Cualquier elemento de
la trama urbana es susceptible de ser georreferenciado de forma única utilizando mediante estos. Este modelo se poblará
a partir de la información existente en los diferentes departamentos como de otras administraciones públicas tras un
adecuado proceso de normalización y verificación.
Servicios de acceso
Dentro del nodo básico se han implementado dos servicios de mapas OGC (WMS9). Uno de ellos permite acceder a la
cartografía básica del ayuntamiento (cartografía a escala catastral y urbana). El otro contiene todos aquellos datos que
puedan servir para referenciar información (por ejemplo, ortofotos). Considerados parte de este nodo desde el punto de
vista del resto de nodos del ayuntamiento están los servicios de las otras IDEs con las que hay algún tipo de acuerdo.
Además de servicios de mapas dentro se ha implementado un servicio de catálogo de datos, que contiene los metadatos
que han sido elaborados en el punto anterior, y un servicio de nomenclátor que es utilizado como base para la aplicación
de callejero.
Progresivamente se ha mejorado la capacidad respuesta de los servicios de acceso de nodo básico. Por ejemplo, para
garantizar una mejora en los servicios de mapas se han instalado múltiples servidores (arquitectura multirelay) con la
información cartográfica de base (la más utilizada por las aplicaciones). Esta mejora permite que aplicaciones críticas
que dependan de estos servicios (por ejemplo, el callejero digital) mejoren su eficiencia al poder atender
simultáneamente a varios usuarios y su fiabilidad.
El nodo piloto temático de Medio Ambiente solo ha requerido de un WMS que sirve para acceder a la información
elaborada por el departamento (puntos de control ambiental, zonas de protección en el término municipal, caminos
rurales). Sin embargo no se ha creado un servicio de catálogo de datos que contenga sólo los datos de Medio Ambiente.
Se desea aprovechar la existencia de un nodo básico para que aquella información que sea susceptible de ser utilizada
por toda la organización, y los metadatos lo son, tenga un único punto de acceso.
Geoportal
El geoportal desarrollado (figura 3) que no solo muestra mediante aplicaciones lo que es una IDE sino que sitúa al
ciudadano en contexto (información sobre el concepto IDE, iniciativas europeas, en especial INSPIRE, otras IDEs
nacionales.). Este aspecto es importante ya que el usuario común tiene experiencia en aplicaciones como callejeros
digitales o, más recientemente, herramientas populares como Google Earth pero que no tiene razones para ver más allá.
La colección de aplicaciones de cualquier geoportal puede encontrarse aquí (visualizadores interactivos, fotografía
aérea, servicios de nomenclátor). Destacamos dos aplicaciones: un planificador de rutas (figura 4 izquierda, ¿cómo
llegar a la Plaza del Pilar, Zaragoza desde…?) y el nuevo callejero digital (figura 4 derecha), que se aprovecha ahora de
la nueva arquitectura de los WMS. Adicionalmente, y considerando que Zaragoza ha sido escogida como sede de la
Exposición Internacional de 2008 (EXPO’08, http://www.zaragozaexpo2008.es/) se ha incluido un visualizador
interactivo que muestra los futuros planes y trabajos relacionados con la EXPO’08 ("Proyecto de Márgenes y Riberas
Urbanas del Río Ebro").
Aplicaciones de Intranet
Como se ha mencionado previamente, uno de los retos de IDEZar es facilitar y coordinar el intercambio de información
dentro del flujo de trabajo del ayuntamiento. En este contexto se han desarrollado una serie de aplicaciones orientadas al
trabajo diario realizado por los técnicos del ayuntamiento que van desde buscadores a visualizadores. Este conjunto de
aplicaciones se compone tanto de aplicaciones del geoportal que acceden a una mayor cantidad de información como de
aplicaciones que sólo tienen sentido para un usuario especializado. A destacar:
La herramienta de georreferenciación es un buen ejemplo de cómo aplicaciones y procedimientos van a la par en una
IDE. Esta aplicación accesible por Web simplifica la tarea de localizar y georreferenciar múltiples elementos (puntos,
líneas y polígonos) como escuelas, bibliotecas, líneas de autobús, etc. Se acompaña de un procedimiento de trabajo
definido y parcialmente automatizado. Este consiste en una serie de tareas simples, generación de una tabla con los
objetos geográficos, conversión a formato GIS (utilizando herramientas comerciales) e integración en los servicios
existentes (WMS, catálogo de metadatos, etc.), orientadas a facilitar el trabajo.
La estructura de esta aplicación (figura 5) consiste de un visualizador, que muestra una cartografía urbana típica (1:1000
a 1:5000), herramientas de interacción con el visualizador, herramientas de creación de geometrías simples (puntos,
líneas y polígonos), y un callejero para simplificar la localización (la dirección es una clave administrativa). Debemos
enfatizar que esta aplicación utiliza los servicios y aplicaciones de la propia IDEZar que hemos presentado antes
(servicios de mapas, callejero). Su fácil manejo ha resultado en una mejora de la productividad, así como su no
dependencia de licencias (como las de ESRI o Integraph) que ha permitido un uso ubicuo. Esta herramienta ha tenido el
efecto adicional de sensibilizar a los departamentos que la han usado sobre el concepto IDE. Esto ha sido posible al
permitir observar e interactuar con el aspecto espacial de los datos que habitualmente utilizan.
Como un ejemplo de las nuevas aplicaciones, se desarrolló una aplicación que busca sólo sobre metadatos relacionados
con temas ambientales (figura 6 izquierda). También se han desarrollado visualizadores temáticos para presentar áreas
protegidas dentro del término municipal de Zaragoza, como el galacho de Juslibol (figura 6 centro – mapa de
localización, figura 6 derecha – visualizador interactivo).
La experiencia de los primeros pasos de IDEZar ha mostrado distintos retos a los que se han de enfrentar los impulsores
de IDEs locales. En general, las administraciones locales deben mejorar los flujos de trabajo que utilizan información
espacial. Los motivos son claros: presión por parte de administraciones de nivel superior (regional, nacional,
comunitaria) para ser utilizadas en los mecanismo de decisión, su elevado coste de producción (recursos económicos,
recursos humanos) así como su rápida obsolescencia. Consideramos que una IDE es la mejor estrategia para lograrlo
pero se enfrenta contra los siguientes problemas de partida:
• La falta de unas estrategias generales en materia de información geográfica, lo que fomenta estrategias
heterogéneas en los departamentos con el riesgo de dar lugar a aplicaciones, servicios y datos no ínter
operables.
• La información disponible o se han elaborado en condiciones de ausencia de presupuesto (se ha creado por la
voluntad de algunos funcionarios) o como resultado de decisiones puntuales (producto cerrado con fuertes
cargas de mantenimiento solo para un departamento); esta situación se combina con la ausencia de meta
información.
• Los frentes de opinión, tanto pública como interno, que influyen en la estabilidad y continuidad del apoyo
político mas allá de los ciclos electorales; de un lado las acciones de la IDE han de tener impacto pero en la
IDE local es la única en la que se ha detectado el fenómeno de la participación social de forma rápida y directa,
en especial si no se hacen las cosas bien (por ejemplo, mediante quejas a los diarios locales); por otro hay que
convencer dentro de la administración local que la IDE es una herramienta más.
• Las soluciones que se establezcan deben ser razonables en coste. Solo soluciones abiertas (sin coste de
licencias, sin costes ocultos de mantenimiento) cuyo uso sea interdepartamental (mayor rendimiento de la
inversión, repetición de patrones de trabajo) tienen perspectiva de obtener ahora un apoyo político estable en
épocas de presupuestos limitados. En estas circunstancias la recuperación de esta inversión está garantizada
con una utilización adecuada de los datos espaciales en los procesos de la toma de decisiones y en los servicios
ofrecidos a los ciudadanos, además de los derivados de legislaciones nacionales y europeas.
Algunas de las estrategias que hemos utilizado para afrontar estas problemáticas son:
• Estabilizar y asegurar la calidad de los avances desde las primeras etapas de implementación. El know-how
que se va acumulando durante el proceso ha de asentarse, profundizarse y verificarse para poder aprovecharlo
adecuadamente en las siguientes etapas.
• Enfocar los esfuerzos en áreas problemáticas cuya mejora tenga un efecto de impacto. Por ejemplo, un área
problemática es la creación de nueva información espacial. Solo el hecho de definir pautas, procedimientos y
marcos de referencia para su elaboración así como políticas y criterios para su incorporación en la IDE
involucra y cambia la percepción que tiene de la IDE a mucho personal técnico.
• Buscar nuevas incorporaciones tanto a los comités como áreas dispuestas a colaborar mediante el
descubrimiento de nuevos usos potenciales. Esta búsqueda da pie a la implementación progresiva de nuevos
servicios y aplicaciones que pueden servir de base a nuevos usos potenciales.
Tras esta primera etapa el acuerdo entre el ayuntamiento y la Universidad de Zaragoza se ha renovado. Los retos que
ahora se plantean van en la línea de las estrategias apuntadas: descubrimiento de nuevos casos de uso (por ejemplo
integración con PDA), enfocar esfuerzos en áreas problemáticas (la creación de un repositorio de información
geográfica que resuelva los problemas de compatibilidad y homogeneidad detectados) así como estabilizar y asegurar
todo el know-how acumulado.
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. Commission of the European Communities, (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. Commission of the European Communities, (2002): Directive 2002/49/EC of the European Parliament and of the Council of 25
June 2002 relating to the assessment and management of environmental nose. L 189/12 Official Journal of the European
Communites.
3. Williamson, I., Rajabifard, A., Feeney, M.E., (2003): Developing Spatial Data Infrastructures. From concept to reality, Taylor and
Francis Publisher, 2003.
4. Graham, S., Simenov, S., Boubez, T., Davis, D., Daniels, G., Nakamura, Y., Neyama, R (2002): Building Web Services with Java
Making Sense of XML, SOAP, WSDL, and UDDI, SAMS Publishing, 2002.
5. Open Geospatial Consortium, (2003): OpenGIS Web Services Architecture, Reference number OGC 03-025, 2003.
6. Cortes Generales de España (2002): ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio
Electrónico. Nº166, 12 julio 2002, BOE
7. Rajabifard, A. (2001): SDI Hierarchy from Local to Global SDI Initiatives, Presentado en Open Seminar on SDI in Asia and the
Pacific Region, 7th PCGIAP meeting, Tsukuba, Japan.
8. International Organization for Standardization (2003): Information and documentation - The Dublin Core metadata element set.
ISO 15836:2003,
9. Open Geospatial Consortium, (2004): OpenGIS Web Map Service (WMS), Reference number OGC 04-024, 2004.
Reumen: La Empresa Pública Desarrollo Agrario y Pesquero, dependiente de la Consejería de Agricultura y Pesca de
la Junta de Andalucía, realiza encargos en los que el uso de datos geográficos es cada vez más frecuente. Estos
estudios requieren información geográfica primaria y secundaria fiable, que garantice la veracidad de los resultados.
Para lograr este objetivo, se ha constituido un grupo de trabajo en la Empresa, encargado de definir la información
convenientemente. Se ha diseñado una herramienta, tomando como modelo las iniciativas internacionales de
normalización de información geográfica (ISO 19115:2003), que está permitiendo organizar la información existente,
describirla y garantizar la confidencialidad de la misma.
Una vez registrados los datos, será necesario divulgarlos mediante un medio asequible y atractivo. Los geoportales
constituirán el mecanismo idóneo para mostrar a los usuarios de la Empresa un catálogo de información territorial
normalizada. Se diseñará un portal SIG con herramientas de búsqueda y visualización, que facilitará el acceso a los
datos y permitirá la canalización de solicitudes de información mediante un procedimiento sencillo.
INTRODUCCIÓN
La Empresa pública Desarrollo Agrario y Pesquero realiza proyectos agrícolas de temática muy diversa en los que la
información geográfica es básica para su desarrollo. Los productos que generan estos trabajos son demandados por la
Administración para su uso en estudios, medidas y programas que afectan al sector agrario andaluz.
Las líneas de actividad desarrolladas por los grupos de trabajo de la Empresa que utilizan y/o generan información
geográfica se enumeran a continuación: gestión de explotaciones agrarias, investigación y transferencia, regadíos e
infraestructuras, desarrollo rural, sanidad animal y vegetal, sistemas y tecnologías de la información, apoyo a la gestión,
y sociedad del conocimiento, entre otras.
Algunos de los trabajos enmarcados en estas líneas son los que siguen:
- Control de ayudas por superficie de la Política Agraria Comunitaria asistido por fotografía aérea.
- Elaboración del Sistema de Información Geográfica de Identificación de Parcelas Agrícola (SIGPAC).
- Integración del SIG oleícola en el SIGPAC andaluz.
- Creación del sistema de localización y seguimiento de la flota pesquera del voraz.
- Evaluación intermedia de la iniciativa Leader Plus (programas de Desarrollo Rural) de Andalucía 2005-2006.
- Obras hidráulicas realizadas a lo largo de todo el territorio andaluz.
- Estudios de los recursos pesqueros del Golfo de Cádiz.
- Gestión de explotaciones agrarias y propiedades públicas.
- Análisis prospectivos de los sistemas agrarios.
- Modernización y asesoramiento en riegos.
La información geográfica tiene cada vez más importancia en estos y otros proyectos abordados. A tal efecto, se han
generado herramientas propias tanto para dispositivos fijos de gabinete como móviles en campo, que procesan un
volumen de datos creciente cada año. Los datos y aplicaciones son utilizados a su vez por otras unidades técnicas
multidisciplinares de la Empresa, según sus necesidades, en los diferentes proyectos realizados.
Tomando como ejemplo los proyectos “Control de ayudas por superficie de la Política Agraria Comunitaria asistido por
fotografía aérea” y “SIGPAC”, se pueden contabilizar más de 500.000 parcelas catastrales controladas en gabinete, y
más de 80.000 recintos visitados, que han generado 156.000 fotografías a pie de campo con sus posiciones GPS
indicadas. Como paso previo a este trabajo se han realizado procesos de generación de información alfanumérica y
ortorrectificado de fotografías aéreas y de satélite, entre otros. En definitiva, se contabiliza un volumen de trabajo
medible en Terabytes.
Situación en la empresa
Si consideramos el tratamiento que la información geográfica recibe en la Empresa, se puede decir que la situación que
se observa es la siguiente:
• Existe un conocimiento trivial sobre el volumen, carácter, localización, posibilidades y condiciones de uso de
la información territorial que se utiliza.
• El seguimiento al que se someten las diferentes capas de información generadas o recibidas de otras fuentes, es
poco riguroso.No existe un registro protocolizado de los datos de la información geográfica que se manejan.La
atención de las demandas de información geográfica, no está centralizada. Esto provoca que, en ocasiones,
grupos de trabajo diferentes, atiendan la misma petición, con la pérdida de tiempo y dinero que esto supone.
• La comunicación entre los equipos que generan o consumen información geográfica, es escasa. Esto puede
deberse al carácter de la Empresa, en ella trabajan múltiples equipos implicados en distintas líneas, que están
ubicados, en muchas ocasiones, en diferentes provincias.
• La gestión sobre los flujos de información en los grupos de trabajo de la Empresa, y la gestión sobre las
demandas de datos recibidas, es mejorable.
Para paliar estas carencias, el Área de Gestión de Información Territorial, ha impulsado la elaboración de este proyecto,
que pretende, crear procedimientos que permitan una comunicación más fluida entre las unidades consumidoras y
productoras de datos geográficos, y desarrollar dinámicas comunes de trabajo que faciliten la gestión de la información
y de las demandas de datos.
En los apartados siguientes, se verán los antecedentes en los que se basa este proyecto, referidos a iniciativas
consolidadas en el ámbito de la definición e intercambio de información. Se analizarán los objetivos, las fases y la
metodología empleada, las acciones realizadas hasta el momento, y las conclusiones obtenidas. Por último, se
expondrán los trabajos aún no abordados.
ANTECEDENTES
En los últimos años ha aumentado considerablemente el interés de los profesionales SIG acerca de los problemas para
conocer dónde se encuentran los datos geográficos, qué características tienen, cuáles son sus posibilidades, sus
mecanismos de distribución, etc.
La creciente necesidad de información geográfica, ha llevado a plantear ciertas acciones que deberían concretarse en
posibilidades de acceso a la información. Estas actuaciones, consisten en aprovechar las posibilidades de comunicación
para proporcionar servicios de catálogo de información geográfica.
Estos servicios, apoyados por metadatos geográficos y servidores de mapas, posibilitan que los consumidores de
información territorial, puedan localizar de forma distribuida, datos geográficos con sus características, así como la
entidad que la suministra y sus condiciones.
Esta tecnología, está siendo estandarizada por diferentes organizaciones internacionales como: ISO (ISO/TC 211), OGC
(Open Geospatial Consortium), FGDC (Federal Geographic Data Commity) o CEN (Comité Europeo de
Normalización).
Siguiendo esta línea, se observa cómo en los últimos años y, a partir de la conferencia de las Naciones Unidas sobre
Medio Ambiente y Desarrollo de Río de Janeiro (1992), nace el término Infraestructura de Datos Espaciales (en
adelante IDE) que engloba bajo un único concepto, la importante acumulación de tecnologías, normas y planes
institucionales que facilitan la disponibilidad y el acceso a los datos territoriales.
Un ejemplo de este programa en España es el del IDEE. Otros ejemplos formales de IDE dirigidos por diferentes
gobiernos e instituciones son: la NDSI en EEUU, SNIG en Portugal, NSIF en Sudáfrica, ASDI en Australia y NaLIS en
Malasia.
El Instituto de Cartografía de Cataluña (ICC) ha creado el perfil IDEC, y ha desarrollado herramientas para la
generación y captura de metadatos (MetaD) que hemos analizado en profundidad, como modelo de registro
normalizado de información según el estándar ISO 19115.
El Instituto de Cartografía de Andalucía (ICA) es el responsable del desarrollo de la IDE de Andalucía (IDEA). El ICC
ha facilitado al ICA el programa abierto MetaD, para que sea adaptado a las necesidades específicas de la iniciativa
andaluza, y distribuido libremente a las organizaciones de Andalucía interesadas. El convenio también contempla la
instalación del software del Servidor de Catálogo IDEC en el entorno IDEA. Esto posibilitará la interconexión e
intercomunicación de ambos catálogos siguiendo las especificaciones del estándar OGC.
OBJETIVOS
Los objetivos propuestos por el proyecto se pueden clasificar en generales y específicos. Veamos a continuación cada
uno de ellos.
Objetivos generales:
Objetivos específicos:
• Creación del Registro de información territorial agrario y pesquero como herramienta para describir,
organizar y mantener actualizados los datos mediante una infraestructura de metadatos. Esta aplición facilitará
a los grupos que generan información geográfica el archivo y definición de los datos en un registro único para
toda la Empresa, y permitirá realizar la puesta en valor de la misma, es decir, conocer los datos disponibles y
sus características.
• Elaboración del Registro de entrada y salida de información territorial para canalizar y gestionar los flujos de
información entrante y saliente en la Empresa.
• Creación del Catálogo de información territorial para difundir la información geográfica, adecuadamente
caracterizada, a los usuarios de la Empresa y Administración. Este mecanismo facilitará las búsquedas de
datos, y permitirá al usuario elegir la información más adecuada para el trabajo a desempeñar.
• Incorporación de procedimientos de trabajo conjunto con otros organismos de la Administración que generan
información territorial, para facilitar el acceso a la misma.
• Elaboración del Registro de demandas de información territorial para gestionar la atención a solicitudes de
datos. La canalización, archivo y administración de las peticiones de datos de usuarios internos y externos a la
Empresa, permitirá atender las demandas de forma más eficiente.
• Creación de prototipos y herramientas preliminares para evaluar el alcance del proyecto, plasmar las
sugerencias de los usuarios, y acopiar los metadatos de la información geográfica más utilizada.Elaboración
de Herramientas definitivas y migración del sistema de gestión de información territorial a un entorno web.
• Difusión de los datos a través de un catálogo de metadatos geográficos por medio de un portal SIG, como
método que posibilita el acceso a la información, ya que organiza contenidos y servicios, y proporciona la
funcionalidad necesaria para realizar consultas al catálogo y servicios SIG.
• Implantación definitiva.
METODOLOGÍA
La metodología empleada en este trabajo va encaminada a resolver las necesidades de la Empresa expuestas en
apartados anteriores. Está basada en los procedimientos desarrollados por otros organismos que poseen las mismas
inquietudes que las presentadas en este trabajo.
La metodología se ha estructurado en los siguientes apartados: fase de revisión de iniciativas, fase de elaboración de
propuestas y fase de desarrollo. Veamos a continuación cada una de estas etapas:
Esta fase se ha dividido en los siguientes apartados: estándares de metadatos más frecuentes, aplicaciones normalizadas
para la captura e intercambio de metadatos y herramientas para la difusión de los datos y atributos geográficos.
Estándares de metadatos
Toda información debe ir acompañada de una serie de parámetros o metadatos que identifiquen de forma unívoca sus
características y que resulten comunes a todos los usuarios. Esto implica la creación de estándares de creación y
manipulación de metadatos, establecidos por consenso de un amplio grupo de profesionales, de forma que se recojan las
características definitorias de la información para su posterior tratamiento y utilización.
Para definir la información geográfica se ha efectuado el estudio de los estándares de metadatos más utilizados a
nivel internacional, europeo y nacional. Son los siguientes:
- Content Standard for Digital Geospatial Metadata (CSDGM 1998)
- Norma de Metadatos Geográficos ISO 19115:2003
- Norma de Metadatos Geográficos ISO 19139
- Conjunto de Metadatos Dublin Core
- Especificaciones del OpenGis Catalog Service de OGC
- Normas experimentales CEN
Ha sido necesario determinar qué características se desean capturar para que las capas de información utilizadas queden
perfectamente definidas. Seguidamente se han comparado los metadatos seleccionados con los recomendados por los
estándares, lo que ha permitido elegir el más adecuado para caracterizar el tipo de información manejada.
El documentar la información geográfica es una tarea ardua por la dedicación que exige, pero muy justificable porque
permite: mantener los datos actualizados, compartir información, mejorar las búsquedas de datos y evaluar la
información (al ayudar a los usuarios a utilizar correctamente los datos, ya que reflejan el propósito de los mismos, su
precisión temporal, espacial, etc).
La generación de metadatos requiere una aplicación que automatice y facilite esta labor, y que permita el intercambio de
metadatos con los consumidores de información geográfica. Se han analizado herramientas gratuitas, algunas de ellas de
código libre, elaboradas por organismos y empresas nacionales e internacionales como la FAO, el ICC y ESRI.
El ICA ha facilitado a la Empresa el programa MetaD, creado por el ICC para la creación y captura de metadatos, que
ha sido adaptado a las necesidades del ámbito andaluz. La desigualdad de criterios en la mecánica de generación de
metadatos de esta aplicación, unido a la inaccesibildad de su código, han conducido al grupo técnico responsable de este
proyecto a diseñar una herramienta propia que permita describir las capas de información territorial, conforme a sus
necesidades, y siguiendo los estándares.
El desconocimiento de la existencia del programa CatMedit (de código abierto), durante la fase de análisis del proyecto,
ha impedido considerar esta aplicación entre las propuestas elaboradas para la creación e intercambio de metadatos.
Una vez definidos los datos mediante los metadatos hay que estudiar y determinar cómo difundirlos a los consumidores
de información territorial. El catálogo de metadatos contiene datos no sólo de las capas de información, sino también de
dónde se encuentran los recursos, el estado en el que están, los niveles de acceso a los mismos, etc. Ofrecido por un
medio asequible al usuario, la web, permitirá a éste realizar búsquedas para localizar la información que satisfaga sus
necesidades.
En la documentación consultada en relación a este tema, el Open Geoespatial Consortium establece una serie de
recomendaciones y especificaciones para establecer un modelo común de datos y servicios que permitan la consulta de
información geográfica en escenarios distribuidos y heterogéneos.
Una vez realizada la fase de análisis, se ha elaborado la propuesta que recoge las siguientes acciones:
• Definir los datos geográficos conforme a la noma de metadatos geográficos ISO 19115:2003, utilizada por
múltiples organismos internacionales y europeos, y recomendada por la Infraestructura de Datos Espaciales
Española.
• Diseñar una herramienta propia de captura de metadatos, Registro de información territorial agrario y
pesquero, basada en las ya creadas, como prototipo de aplicación para la definición de la información.
• Registrar la información mediante herramientas preliminares y diseñar las herramientas definitivas a las que
serán migrados los datos.
• Realizar el intercambio de metadatos a través de formatos XML según las especificaciones de la ISO 19139.
Por el momento, y hasta que el editor de metadatos genere este formato estandarizado, se utilizarán los ficheros
PDF.
• Almacenar la información territorial en uno o varios servidores de la Empresa, y gestionar el acceso a los
mismos.
• Acceder a servidores externos mediante los convenios de colaboración que se estimen oportunos, con el fin de
extraer datos geográficos de interés para los proyectos a desarrollar.
• Seguir las especificaciones del Open Geoespatial Consortium en lo referente al diseño de los servicios de
catálogo de metadatos geográficos y herramientas de búsqueda, visualización y exportación de datos.
Fase de desarrollo
En esta fase se han incluido los apartados siguientes: perfil de metadatos y sistema de gestión (actores que intervienen
en el sistema y acciones desempeñadas por los gestores del sistema).
Perfil de metadatos
• El núcleo mínimo de metadatos recomendados por la ISO 19115 para definir adecuadamente los datos
(core).Se han incluido otros metadatos, especificados en el Perfil IDEC, pertenecientes a diversas secciones de
la norma (obligatorios, opcionales y complementarios).Se han añadido algunos metadatos de interés particular,
para definir convenientemente la información utilizada y generada en la Empresa: módulo de acopio de
información, módulo de gestión de proyectos y geodatabases, módulo de procedimiento de cesión de datos,
etc.
En la siguiente tabla (Cuadro 1) se muestra el núcleo principal de metadatos del estándar ISO 19115 (core), el cual es el
mínimo imprescindible para documentar los datos geográficos.
Cuadro 1: Metadatos del core, (Ob) son los Obligatorios, (Op) los Opcionales y (C) los Condicionales.
Las categorías establecidas por la ISO para la clasificación de la información, se han respetado en este trabajo, sin
embargo, ha sido necesario incluir el concepto de “grupo” y “subgrupo” para especificar clases no recogidas en la
norma, principalmente en lo referente a la información pesquera.
Sistema de gestión
La metodología empleada en este trabajo va encaminada a la creación de un sistema integrado con el que regular los
flujos de información en la Empresa.
• Actores que intervienen en el sistema
El registro único de información territorial recogerá los datos geográficos disponibles en la Empresa. Los productores
de información geográfica serán los encargados de nutrir este registro introduciendo en él sus datos y las características
básicas de los mismos, bajo la supervisión de los gestores del sistema, que validarán los metadatos definidos.
Los consumidores de información (internos o externos a la Empresa) podrán realizar búsqudas de datos y evaluarlos a
través del catálogo de metadatos, utilizando un geoportal como método para acceder a los mismos. Los accesos a los
datos estarán controlados por el sistema. El administrador, conforme a las políticas de acceso establecidas por la
dirección de la Empresa, gestionará los usuarios y la asignación de roles.
• Acciones
Las acciones realizadas y supervisadas por los gestores del sistema serán las siguientes: almacenamiento y acopio de los
datos, y gestión de la información.
Veamos a continuación cómo se realizará la gestión de los datos:
La información territorial se archivará y definirá mediante la aplicación del Registro de información territorial agrario y
pesquero. Los datos se mostrarán a los usuarios a través del Catálogo de información territorial, en el que la
información se presentará documentada y organizada, lo que permitirá hacer búsquedas satisfactorias y elegir la
información más adecuada según el uso al que va encaminada.
El canal centralizado de atención a solicitudes de información territorial gestionará las demandas de datos dirigidas a los
distintos grupos de trabajo de la Empresa. Las peticiones atendidas podrán ser de tres tipos:
- Información territorial existente en la Empresa, elaborada o no dentro de ella. Será necesario respetar el acceso
a los datos, solicitando los permisos oportunos a los creadores.
- Datos geográficos no existentes en la Empresa, elaborados por otros organismos. Serán demandados al
productor de la información especificando la finalidad de los datos y solicitando el permiso de uso de los
mismos.
- Información territorial no elaborada. Los gestores del sistema realizarán el encargo del trabajo al grupo técnico
de la Empresa competente en la materia solicitada.
Las demandas se archivarán en el Registro de demandas de información territorial, indicando los datos del solicitante, la
información solicitada, el plazo deseado de entrega de los mismos, el técnico responsable de atender la petición, la
respuesta emitida y la fecha de entrega de la misma.
Esta aplicación permitirá establecer un sistema de trazabilidad de las solicitudes y medir la calidad de la respuesta
mediante diversos indicadores. La herramienta está dotada de un “sistema de gestión de tiempos de las fases de
resolución” que garantiza la ejecución de la solicitud y el cumplimiento del plazo de entrega acordado entre el
responsable de la respuesta y el solicitante.
La respuesta se acompañará de un recibí, un test de satisfacción y una carta de compromiso, en un único documento,
que, una vez firmado por el solicitante, confirmará la recepción de la respuesta, la conformidad con el contenido de la
misma y el compromiso por parte del peticionario de no ceder los datos a terceros ni usarlos para un fin distinto al
indicado, preservando así la confidencialidad de los mismos y cumpliendo con la legislación vigente (LOPD y LPI).
En el Registro de entrada y salida de información territorial quedará constancia de los flujos de datos producidos en los
diferentes equipos de trabajo de la Empresa.
ESTADO ACTUAL
Este proyecto se encuentra en fase de desarrollo, sin embargo, algunos de los procedimientos definidos, ya están siendo
aplicados con resultados satisfactorios. El trabajo desarrollado hasta la fecha se recoge en los puntos siguientes:
Problemas encontrados
• Lentitud en la captura de los metadatos, por la escasa información existente sobre las características de datos
utilizados.
• Adecuación de las categorías establecidas por la normativa ISO 19115 a la información territorial utilizada, ya
que establece clases muy genéricas en las que es difícil enmarcar algunos datos.
• Dispersión en el almacenamiento de los datos geográficos, por no existir un procedimiento que establezca
dónde y cómo almacenarlos.Dificultad en la importación de los metadatos de la información externa recibida,
ya que sólo algunos de los datos entrantes los incorpora.Dificultad en el acceso a datos geográficos, ya que aún
son pocos los organismos españoles acogidos a la iniciativa de Infraestructura de Datos Espaciales.
CONCLUSIONES
Una vez expuesto este trabajo se pueden extraer las siguientes conclusiones:
• La información territorial se encuentra dispersa y poco definida, en las diversas áreas de la Empresa, lo que
dificulta el acceso a la misma y su evaluación.La gestión de la información geográfica va a permitir conocer
los flujos de datos entrantes y salientes, la cantidad y calidad de los datos, su ubicación y condiciones de
acceso y uso de ellos.
• Las normas de metadatos geográficos ISO 19115 e ISO 19139 se presentan como los estándares más
adecuados para caracterizar la información e intercambiar metadatos geográficos con otros organismos
nacionales e internacionales.
• La canalización de las demandas de información territorial en la Empresa, va a permitir la gestión adecuada de
las solicitudes de datos, mejorando el tiempo de respuesta y la calidad de la misma.
• El sistema integrado compuesto por las aplicaciones de registro de información, de entrada y salida de datos y
de control de solicitudes, constituye la solución inmediata para gestionar la información territorial de la
Empresa.
• Este proyecto se encuentra en fase de desarrolo, aún queda mucho trabajo por hacer basado en las
especificaciones del Open Geoespatial Consportium, estándar que establece cómo deben estructurarse e
implementarse los servicios de catalogación y de búsqueda de metadatos geospaciales.
• La implantación de este proyecto en la Empresa, supondrá una importante mejora en la calidad del trabajo
realizado en los diversos grupos que la componen, al proporcionar harramientas de gestión y de localización de
datos geográficos, que mejorarán los tiempos de respuesta, minimizando costes.
ACTUACIONES FUTURAS
• Protocolizar relaciones con organismos que generan información territorial, para intercambiar datos
geográficos y definir líneas de trabajo conjunto.
• Identificar centros generadores de información (universidades, centros de investigación, etc) para establecer
acuerdos de cesión de datos.
• Centralizar las demandas de información territorial a través de un portal SIG.
• Coordinar el proyecto con las iniciativas de INSPIRE, IDEE e IDEA.
• Analizar las especificación del OpenGis Catalog Service de OGC, estándar que establece cómo deben
estructurarse e implementarse los servicios de catalogación y búsqueda de metadatos geoespaciales,
estableciendo el subconjunto mínimo de metadatos que deben ser interrogables.
• Adecuar los sistemas informáticos existentes y futuros a la norma ISO 19139 que establece el modelo de datos
estándar para los ficheros planos de intercambio de información, XML.
• Evaluar la adopción, de forma directa o adaptada a nuestras necesidad, de software gratuito de código abierto
como CatMedit, gvSIG, etc, como herramientas que podría facilitar la gestión de información geográfica.
• Proponer la certificación de los procesos del proyecto conforme a la norma ISO 9000.
REFERENCIAS
1. Garrido Borrego, Mª Teresa (2003): La IDE Andalucía un compromiso de todos. Artículo229 de la revista Mapping
http://www.mappinginteractivo.com/plantilla-ante.asp?id_articulo=229 (acceso: 30 Marzo, 2005).
2. Bañares, J.A; Bernabé, M.A.; Gould, M.; Muro-Medrano, P.R.; Zaragoza, F.J.: Aspectos tecnológicos de la creación de una
Infraestructura Nacional de Información Geográfica. Internet: http://redgeomatica.rediris.es/metadatos/publica/articulo03.htm
(acceso: 20 Junio, 2005).
3. Paradell, Jordi Escriu (2004). Estudios de relación y conexión entre los elementos de metadatos de la norma ISO 19115 y Dublín
Core, e ISO 19115 y Marc21. Internet: http://idee.unizar.es/jidee. Procedente de las Jornadas de Infraestructura de Datos Espaciales
de España (JIDEE) 2004. Zaragoza, España.
4. Juliá, Nuria; Masó, Joan; Zabala, Alaitz; Vallés, Marina (2004). CAMM, catálogo de metadatos de MiraMon: implementación en
una corporación, el DMAH. Internet: http://idee.unizar.es/jidee. Procedente de las Jornadas de Infraestructura de Datos Espaciales de
España (JIDEE) 2004. Zaragoza, España.
5. Rodríguez, Antonio; Sánchez, Alejandra; Nogueras, Javier (2005). Núcleo español de metadatos (NEM v1.0). Internet:
http://idee.unizar.es. Procedente de la Reunión del grupo de trabajo IDEE 2005. Barcelona, España.
6. Infraestructura de Datos Espaciales de Catalunya. Internet: http://www.geoportal-idec.net (último acceso 30 Septiembre, 2005).
7. Dublín Core Metadata Iniciative. Internet: http://www.dublincore.org (último acceso: 30 Junio, 2005).
8. Infraestructure for Spatial Informaction in Europe (INSPIRE). Internet: http://inspire.jrc.it/home.html (último acceso: 28 Junio,
2005).
9. Ministerio de Fomento. Consejo Superior Geográfico. Infraestructura de Datos Espaciales de España (IDEE). Internet:
http://idee.unizar.es (último acceso: 15 Julio, 2005).
10. Perfil IDEC: Estándar ISO 19115. Información geográfica. Metadatos. Internet: http://www.geoportal-idec.net (acceso 2004).
11. Normalización en el campo de la información geográfica. Internet:
http://www.fomento.es/MFOM/LANG_CASTELLANO/direcciones_generales/instituto_geografico/ (acceso: 23 Junio, 2003).
12. ISO Technical Committee on Geographic Informaction / Geomatics 211, 2003. Inernational Standard: Geographic Information –
Metadata. ISO 19115.
13. Content Standard for Digital Geospatial Metadata (CSDGM). Internet: http://www.fgdc.gov/metadata/metadata.html (último
acceso: 16 Junio, 2004).
14. Open Geospatial Consortium Inc. Internet: http://www.opengeospatial.org (último acceso: 18 Julio, 2005).