Jidee05

Jornadas Técnicas de la IDE Española 2005

Madrid, 24 y 25 de noviembre de 2005

Índice general

3

Sesión 0

1. Catastro 71.1. Control de Calidad en el Área de Cartografía Informatizada de la D.G. del Catastro . . . 91.2. Sistema de entrada, actualización y publicación en la ovc . . . . . . . . . . . . . . . . . . . 191.3. WMS de la Dirección General del Catastro . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2. Educación, nuevos paradigmas y negocios 352.1. Newsletter IDE Iberoamérica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2. Nuevos roles en el nuevo paradigma IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.3. Algunos Requisitos Técnicos para lograr Modelos de Negocios sustentables en una IDE . . 54

3. SIG y Ordenación del Territorio 613.1. Los SIG y el control de las operaciones de recogida de información estadística . . . . . . . 633.2. Análisis vectorial en PostGIS y Oracle Spatial: estado actual y evolución de la especi�cación

Simple Features for SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.3. Integración de la Información Territorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.4. Modelo de datos UML y XML del catálogo de fenómenos de la Base topográ�ca 1:5000 de

Catalunya v2 basado en estándares ISO19100 . . . . . . . . . . . . . . . . . . . . . . . . . 903.5. Álgebra para la gestión de coberturas y su integración en XQuery . . . . . . . . . . . . . . 101

4. Metadatos 1114.1. De�nición de Per�les 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, per�l mínimo de metadatos recomendados para España 1224.3. Editor de Metadatos NEM V 1.0 para ArcGIS . . . . . . . . . . . . . . . . . . . . . . . . 133

5. Servicios Web I 1375.1. Arqueología y Servidores de Mapas en Red. Proyecto LIFE �Valle de Tiermes - Caracena� 1395.2. Diseño de una herramienta basada en la generación interactiva de estilos para la visuali-

zación de capas a través de un WMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495.3. Servicio web 3D parametrizable mediante un lenguaje de de�nición de escenas virtuales . 1575.4. Aplicabilidad del modelo de nomenclátor de España al nomenclátor conciso . . . . . . . . 167

6. IDEs Regional, Nacional, Transnacional 1736.1. Sistema para la Gestión y Divulgación de Información Cartográ�ca del Instituto Carto-

grá�co Valenciano. Proyecto cart@ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756.2. La Infraestructura de Datos Espaciales de Galicia (I.D.E.G.) . . . . . . . . . . . . . . . . 1846.3. Evolución del portal de la Infraestructura de Datos Espaciales de España y el Nodo IGN . 1926.4. SDIGER: Experiences and identi�cation of problems on the creation of a transnational SDI198

7. Servicios Web II 2097.1. La IDEE como Herramienta de Ayuda a la Elaboración del Inventario del Patrimonio

Industrial de Aragón . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2117.2. Encadenamiento de servicios web: Hacia IDEs basadas en servicios . . . . . . . . . . . . . 2207.3. Pruebas benchmark de soluciones cliente/servidor en software libre . . . . . . . . . . . . . 2287.4. La gestión de usuarios en una Infraestructura de Datos Espaciales . . . . . . . . . . . . . 238

8. IDEs Locales y Regionales 2478.1. Estableciendo bases organizacionales para una IDE local: aportaciones desde una Coope-

rativa de Datos Espaciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2498.2. IDEZar: un ejemplo de implantación de una IDE local . . . . . . . . . . . . . . . . . . . . 2598.3. Creación de un catálogo de información territorial normalizada y un canal de atención a

demandas de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Jornadas Técnicas de la IDE Española, Madrid 2005. 5

SESIÓN 1

CATASTRO

7

Control de Calidad en el Área de Cartografía Informatizada

de la D.G. del Catastro

Francisco García Cepeda Dirección General del Catastro

[email protected]

Resumen: Se pretenden explicar los procedimientos que se efectúan en el Área de Cartografía Informatizada de la D.G. del Catastro para conseguir que los datos que se introducen en la Base de Datos sean lo más homogéneos posibles. Al coexistir dos Bases de Datos dentro del Sistema de Información Catastral (S.I.C.) y con fuentes diferentes se producen inconsistencias que se tratan de corregir con los diferentes procedimientos puestos en práctica en lo que a Cartografía informatizada se refiere. Así por ejemplo en la introducción se detallarán las cifras más significativas de SIGCA, Sistema de Información Geográfico Catastral, a continuación se reseñaran los procedimientos y aplicaciones que se utilizan en el Área, detallando el origen, procesamiento y salida de los datos. Para terminar indicando las conclusiones más importantes. 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. Referente al contenido el artículo 3 dice: La descripción catastral de los bienes inmuebles comprenderá sus características físicas, económicas y jurídicas, entre las que se encontrarán la localización y la referencia catastral, la superficie, el uso o destino, la clase de cultivo o aprovechamiento, la calidad de las construcciones, la representación gráfica, el valor catastral y el titular catastral. A los solos efectos catastrales, y sin perjuicio del Registro de la Propiedad, cuyos pronunciamientos jurídicos prevalecerán, los datos contenidos en el Catastro Inmobiliario se presumen ciertos. 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.

Control de Calidad en el Área de Cartografía Informatizada de la D.G.... Sesión 1


5522 GGeerreenncciiaass TTeerrrriittoorriiaalleess

MMIINNIISSTTEERRIIOO DDEE EECCOONNOOMMÍÍAA YY HHAACCIIEENNDDAA

SSEECCRREETTAARRÍÍAA DDEE EESSTTAADDOO DDEE HHAACCIIEENNDDAA YY PPRREESSUUPPUUEESSTTOOSS

DDIIRREECCCCIIÓÓNN GGEENNEERRAALL DDEELL CCAATTAASSTTRROO

ÓÓRRGGAANNOOSS CCEENNTTRRAALLEESS

ÓÓRRGGAANNOOSS TTEERRRRIITTOORRIIAALLEESS

CCOONNSSEEJJOO SSUUPPEERRIIOORR DDEE LLAA

PPRROOPPIIEEDDAADD IINNMMOOBBIILLIIAARRIIAA

CCOOMMIISSIIOONNEESS SSUUPPEERRIIOORREESS DDEE CCOOOORRDDIINNAACCIIÓÓNN

IINNMMOOBBIILLIIAARRIIAA DDEE RRÚÚSSTTIICCAA YY UURRBBAANNAA

SSUUBBDDIIRREECCCCIIÓÓNN GGEENNEERRAALL DDEE

VVAALLOORRAACCIIÓÓNN EE IINNSSPPEECCCCIIÓÓNN

SSUUBBDDIIRREECCCCIIÓÓNN GGEENNEERRAALL DDEE EESSTTUUDDIIOOSS YY

SSIISSTTEEMMAASS DDEE IINNFFOORRMMAACCIIÓÓNN

SSEECCRREETTAARRÍÍAA GGEENNEERRAALL

GGEERREENNCCIIAASS RREEGGIIOONNAALLEESS

GGEERREENNCCIIAASS TTEERRRRIITTOORRIIAALLEESS

JJUUNNTTAASS TTÉÉCCNNIICCAASS TTEERRRRIITTOORRIIAALLEESS DDEE

CCOOOORRDDIINNAACCIIÓÓNN

CCOONNSSEEJJOOSS TTEERRRRIITTOORRIIAALLEESS DDEE

LLAA PPRROOPPIIEEDDAADD IINNMMOOBBIILLIIAARRIIAA

SSEECCRREETTAARRÍÍAA GGEENNEERRAALL DDEE HHAACCIIEENNDDAA

SSUUBBDDIIRREECCCCIIÓÓNN GGEENNEERRAALL DDEE

PPLLAANNIIFFIICCAACCIIÓÓNN YY AATTEENNCCIIÓÓNN AALL CCIIUUDDAADDAANNOO

Figura 1. Localización Gerencias Territoriales La siguiente figura es un esquema de la estructura de la D.G. del Catastro. Fig.2 Esquema de la estructura de la D. G. del Catastro El esquema conceptual de las funcionalidades de la Aplicación Sigca2 es el siguiente:

Sesión 1 Control de Calidad en el Área de Cartografía Informatizada de la D.G....

10 Jornadas Técnicas de la IDE Española, Madrid 2005.

SIGECASIGCA2

FICC

CARGA

CONSULTAS

TRAZADOS

CERTIFICACIONES

MANTENIMIENTO

CHEQUEO VALIDACIÓN

PONENCIAS

PLAN

SDE

ORACLE

CRUCE

Entorno Cliente

Entorno Administración

DESCARGA

Fig.3 Esquema conceptual de funciones de Sigca2 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:

TIPO Municipios Digitalizados

Nº parcelas estimadas

Nº parcelas digitalizadas

% Municipios

% Parcelas

RÚSTICA 6827 43000000 34000000 90,34 79,07 URBANA 6664 11000000 10000000 88,18 90,91

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 FICHERO DE ENTIDADES SUPERFICIALES: RELACION DETALLADA DE ERRORES ------- -- --------- -------------- -------- --------- -- ------- 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 FICHERO DE ENTIDADES SUPERFICIALES: RELACION DE REFERENCIAS CATASTRALES DE URBANA REPETIDAS ------- -- --------- -------------- -------- -- ----------- ----------- -- ------ --------- REF. CATASTRAL NUMERO DE REGISTRO -------------- ------------------------------------------------------------------------------------------------------------3458001 0005712 0005720 3458002 0005713 0005721 3458003 0005714 0005722 3458004 0005715 0005723 3458005 0005201 0005210 3551310 0003898 0003922 3552038 0001983 0001984 3552099 0001875 0002339 3571101 0010608 0010630 3571102 0010609 0010631 3571103 0010632 0011172 3571104 0010633 0011167 3571105 0010610 0010634 3642099 0001480 0001732 3663099 0008190 0008192 3671302 0011120 0011297 3766003 0009089 0009093 3771699 0011302 0011304 3861099 0006887 0006888 Interrumpido el listado de referencias catastrales repetidas. Existen 55 referencias mas diferentes FICHERO DE ENTIDADES SUPERFICIALES: RELACION DE UNIDADES DE CAPTURA REPETIDAS ------- -- --------- -------------- -------- -- -------- -- ------- --------- NO HAY UNIDADES DE CAPTURA REPETIDAS FICHERO DE ENTIDADES SUPERFICIALES: RELACION DE COORDENADAS REPETIDAS ------- -- --------- -------------- -------- -- ----------- --------- NO HAY COORDENADAS REPETIDAS

Fig.4 Errores de formato en el fichero de superficies 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. Fig.5 Duplicación de línea de suelo de naturaleza urbana 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,



Fig.6 Pantalla inicial de cruces

Fig.7 Salida de resultados del cruce 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.



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.

Delegación Total general % Parámetros considerados Del.

Total 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%

95483 70,33% Total Coincide RC, Dir y 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%












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

Fig. 9. Ejemplo de temático de cruces

Fig. 10. Simbologia del temático de cruces 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.

Figura 11. Diferencias de nombres 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.

Figura 12. Verificación geométrica 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.

Figura13. Fichero de salida V.Geométrica 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. Figura 14. Salida gráfica de verificación geométrica Por último un ejemplo compuesto de salida alfanumérica de información de parcelas con diferencias en dirección.



Figura 15. Composición de salidas alfanuméricas



1

MINISTERIODE HACIENDADirección General del Catastro

SISTEMA DE ENTRADA, SISTEMA DE ENTRADA, ACTUALIZACIACTUALIZACIÓÓN Y N Y

PUBLICACIPUBLICACIÓÓN EN LA OVCN EN LA OVC

Sub. Gral. Estudios y Sist. de la InformaciónDirecciDireccióón General del Catastron General del Catastro

Madrid. Noviembre 2005

[email protected]


INTRODUCCIINTRODUCCIÓÓNN

EL SISTEMA DE INFORMACIEL SISTEMA DE INFORMACIÓÓN CATASTRAL N CATASTRAL

ENTRADA DE DATOSENTRADA DE DATOS

SISTEMA DE ACTUALIZACISISTEMA DE ACTUALIZACIÓÓN:N:

–– SINCRONIZACISINCRONIZACIÓÓN ENTRE SERV. PERIFN ENTRE SERV. PERIFÉÉRICOS RICOS

Y SERV. CENTRALESY SERV. CENTRALES

SISTEMA DE PUBLICACISISTEMA DE PUBLICACIÓÓN EN LA OFICINA N EN LA OFICINA

VIRTUAL DE CATATRO (OVC)VIRTUAL DE CATATRO (OVC)

Sistema de entrada, actualización y publicación en la ovc Sesión 1


2


SICSIC

BDNC

SIGECA

SIGCA

65

BDTC

GERENCIAS TERRITORIALES SS.CC

OVCOVC

DistribuciDistribucióón geogrn geográáficafica


SIC: SUBSISTEMASSIC: SUBSISTEMAS

Gestión descentralizada

Usuarios Internos

Datos alfanuméricos

Gestión y Mantenimiento, Valoración, Certificación, Notificaciones, Informes

SIstema de GEstión CAtastral

SIGECA

SISTEMA DE INFORMACIÓN CATASTRAL

Sist. Inform. Geograf. CAtastral

SIGCA

BBDD Nacional de titulares Catastrales

BDNC

Oficina Virtual del Catastro

OVCGestión descentralizada

Usuarios Internos

Datos cartográficos

Gestión y Mantenimiento, Certificación Descriptiva y

Gráfica,

Gestión centralizada

Usuarios Internos

Datos cartográficos y alfanuméricos

Consolidación titulares con AEAT, Certificaciones

nacionales

Gestión centralizada

Ciudadanos, Usuarios Externos e Internos y

Administraciones

Datos cartográficos y alfanuméricos

Servicio Consulta y Certificación, PADECA, Visualizador cartografía, Intercambiador de datos (Notarios, Registradores,

Ayuntamientos. Etc)

Sesión 1 Sistema de entrada, actualización y publicación en la ovc


3



Diferentes agentes colaboradores:Diferentes agentes colaboradores:–– Institucionales (Entidades locales, CCAA, N+R, AEAT, Patrimonio)Institucionales (Entidades locales, CCAA, N+R, AEAT, Patrimonio)–– Empresas (Contratos)Empresas (Contratos)–– Ciudadanos (Interactiva en Gerencia o OVC, SICA)Ciudadanos (Interactiva en Gerencia o OVC, SICA)

¿Con quién intercambiamos información?

Titulares catastrales

EELL

AA..PP.

Notarios y Registradores

Juzgados Y Tribunales

EELL

Notarios y Registradores

Administración del Estado

Ciudadanos y empresas

D. G. CATASTRO

PROVEEDORES CLIENTES



Ficheros planos estructurados – Oficialmente aprobados. Refrendados por la FEMP

– En el futuro … XML

Acceso on-line a nuestros sistemas (Gerencia, OVC)

¿Cómo intercambiamos información?



4



Convenios. Delegación competenciaTramitación de alteraciones físicas y económicas producidas en los inmueblesEntrada y Salida mediante formatos: – VARPAD (titularidad)– FIN (catastro)

Convenios. Prestación de serviciosEntrada– VARPAD, FIN y FX-CU1



DATOS PROCEDENTES DE :DATOS PROCEDENTES DE :

REVISIONES REVISIONES (URBANA)(URBANA)

–– FINFIN–– FICCFICC–– FXCU1 FXCU1 -- CRCR

RENOVACIONES RENOVACIONES (R(RÚÚSTICA)STICA)

–– Cinta 150Cinta 150–– FICCFICC–– FXCU1 FXCU1 -- CRCR



5


ACTUALIZACIACTUALIZACIÓÓN DE LA OVCN DE LA OVC

BDNC

RRééplica diaria de la informaciplica diaria de la informacióón grn grááfica y fica y alfanumalfanuméérica para actualizar la Base de rica para actualizar la Base de Datos Nacional de titulares Catastrales Datos Nacional de titulares Catastrales

(BDNC).(BDNC).


SISTEMA DE ACTUALIZACISISTEMA DE ACTUALIZACIÓÓNN

LAYER MASALAYER MASA SDE02.MLOG$_MASALAYER PARCELA LAYER PARCELA SDE02.MLOG$_PARCELALAYER CONSTRU LAYER CONSTRU SDE02.MLOG$_CONSTRULAYER SUBPARCE LAYER SUBPARCE SDE02.MLOG$_SUBPARCELAYER ELEMLINLAYER ELEMLIN SDE02.MLOG$_ELEMLINLAYER ELEMTEXLAYER ELEMTEX SDE02.MLOG$_ELEMTEXLAYER LAYER ……....

CADA GERENCIA TERRITORIALCADA GERENCIA TERRITORIAL



6


SISTEMA DE ACTUALIZACISISTEMA DE ACTUALIZACIÓÓNN

BBDD Nacional de titulares Catastrales

BDNC

Oficina Virtual del Catastro

OVCSDE02.mlog$_masaSDE02.mlog$_parcelaSDE02.mlog$_construSDE02.mlog$_subparceSDE02.mlog$_elemlinSDE02.mlog$_..................

SDE02.masaSDE02.parcelaSDE02...................

SDE03.masaSDE03...................

SDE04.masaSDE04...................


Gerencia Territorial

SIGCA

SDE56.mlog$_masaSDE56.mlog$_parcelaSDE56.mlog$_..................

SDExx.mlog$_masaSDExx.mlog$_parcelaSDExx.mlog$_..................


SDE03.masaSDE03...................

SDE04.masaSDE04...................



OFICINA VIRTUAL DEL CATASTROOFICINA VIRTUAL DEL CATASTRO

http://ovc.catastro.meh.es/



7


OVCOVC

REQUISITOS ACCESOREQUISITOS ACCESO

–– Servicios que requieran acreditaciServicios que requieran acreditacióón de la identidad n de la identidad

del usuario y la seguridaddel usuario y la seguridad

=> certificado X509.3=> certificado X509.3

–– Consulta de datos catastrales no protegidosConsulta de datos catastrales no protegidos

=> acceso libre=> acceso libre

–– Las Administraciones e InstitucionesLas Administraciones e Instituciones

=> procedimiento de registro=> procedimiento de registro


OVCOVC

SERVICIOS DE CONSULTA Y CERTIFICACISERVICIOS DE CONSULTA Y CERTIFICACIÓÓNN

–– Consulta y CertificaciConsulta y Certificacióón de un bien inmueblen de un bien inmueble

–– Consulta y CertificaciConsulta y Certificacióón por titularn por titular

–– GestiGestióón de las Certificacionesn de las Certificaciones



8


SERVICIOS DE USUARIOSERVICIOS DE USUARIO


ACCESO A UN BIEN CATASTRALACCESO A UN BIEN CATASTRAL



9


REPRESENTACIREPRESENTACIÓÓN SEGN SEGÚÚN ESCALAN ESCALA

CaracterCaracteríísticas de la representacisticas de la representacióón cartogrn cartográáfica :fica :ÁÁmbito de representacimbito de representacióón:n:

CartografCartografíía catastral de urbana o de ra catastral de urbana o de rúústica por tstica por téérmino municipal.rmino municipal.Capas de informaciCapas de informacióón:n:

Dependiendo de la escala de representaciDependiendo de la escala de representacióón.n.


PICPIC



10


OVCOVC

JUSTIFICACIJUSTIFICACIÓÓN DE LOS PICN DE LOS PIC

–– Responder a la demanda creciente de la informaciResponder a la demanda creciente de la informacióón n

catastralcatastral

LA ENTIDAD QUE SOLICITA UN PIC hace papel LA ENTIDAD QUE SOLICITA UN PIC hace papel

de de intermediadorintermediador en el ejercicio del derecho en el en el ejercicio del derecho en el

acceso a la informaciacceso a la informacióón catastraln catastral

PICPIC



WMS de la Dirección General del Catastro

José Miguel Olivares García 1 Luis Ignacio Virgós Soriano 2

Dirección General del Catastro (España) [email protected], 1

Dirección General del Catastro (España), [email protected] 2

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

Figura 1: Oficina Virtual del Catastro Figura 2: SIGCA2

WMS de la Dirección General del Catastro Sesión 1


ORIGEN DE LOS DATOS 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).

Figura 3: Ámbito territorial y gerencias

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. La Cartografía Catastral tiene las siguientes características: Proyección: U.T.M. en los husos 27, 28, 29, 30 y 31 Sistema Geodésico: ED50 para península y Baleares (husos 29, 30 y 31) y WSG84 para Canarias (husos 27 y 28) . Ámbito de unidades de proceso: Término municipal, dividido en:

• Cartografía Catastral de Urbana: Escalas de captura 1:500 y 1:1.000

• Cartografía Catastral de Rústica: Escalas de captura 1:2.000 y 1:5.000 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.

Sesión 1 WMS de la Dirección General del Catastro


Figura 4: Cartografía Catastral de urbana Figura 5: Cartografía Catastral de rústica

Cartografía Catastral Urbana 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). Elementos cartográficos catastrales (recintos): MANZANAS: Conjunto continuo de parcelas rodeado de suelo público (calles). PARCELAS: Unidad básica catastral. CONSTRUCCIONES: Subdivisión de la volumetría de la parcela. Otros elementos cartográficos: HOJAS: Malla de hojas de la cartografía catastral. LIMITES: Líneas de límites administrativos y líneas de delimitación del suelo naturaleza urbana. EJES: Líneas de ejes de calles y de infraestructuras lineales. ELEMENTOS LINEALES: Elementos de mobiliario urbano (aceras, escaleras, monumentos, etc.), hidrografía, redes… ELEMENTOS PUNTUALES: Elementos puntuales de mobiliario urbano (farolas, registros, etc.) TEXTOS: Toponimia, calles, números de policía, edificios singulares, hidrografía, etc. Cartografía Catastral Rústica 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). Elementos cartográficos catastrales (recintos): POLÍGONOS: Conjunto de parcelas. PARCELAS: Unidad básica catastral. SUBPARCELA: Subdivisión de la parcela en función del cultivo o aprovechamiento Otros elementos cartográficos: LIMITES: Líneas de límites administrativos y líneas de delimitación del suelo naturaleza urbana. EJES: Líneas de ejes de infraestructuras lineales. TEXTOS: Toponimia, parajes, carreteras, hidrografía, etc. CARACTERISTICAS DEL WMS 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.



La dirección del servicio WMS del Catastro es:

http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx Admite las distintas versiones de WMS que están definidas en OGC: Versión 1.0.0 Versión 1.1.0 Versión 1.1.1 Admite los siguientes SRS:

Para coordenadas geográficas: EPSG:4230 ED50 EPSG:4326 WGS 84

Para coordenadas U.T.M.: EPSG:32627 WGS 84 / UTM zone 27N EPSG:32628 WGS 84 / UTM zone 28N EPSG:23029 ED50 / UTM zone 29N EPSG:23030 ED50 / UTM zone 30N EPSG:23031 ED50 / UTM zone 31N

Los formatos imagen admitidos son: image/png image/jpeg image/gif

image/bmp image/tif image/wmf

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

Figura 6: Simbología y transparencia

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



Figura 7: Información selectiva en función de la escala

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:

Referencia catastral de la parcela marcada: 6190010TF5369S

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.

Figura 8: Enlace con la Oficina Virtual del Catastro

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

Referencia catastral de la parcela marcada: 6190010TF5369S



Figuras 9 y 10: Imágenes de 2 fechas y fusión con transparencias

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 1. Página web de la Direccion General del Catastro. http://www.catastro.meh.es 2. Oficina Virtual del Catastro http://ovc.catastro.meh.es 3. Open Geoespatial Consortium,Inc (OGC) http://www.opengeospatial.org 4. Infraestructura de Datos Espaciales de España (IDEE) Consejo Superior Geográfico http://www.idee.es 5. Infraestructura de Datos Espaciales de Cataluña (IDEC): http://www.geoportal-idec.net 6. IDE Rioja: http://www.iderioja.org 7. Visor WMS de Intergraph: http://www.wmsviewer.com 8. Visor Wms de ESRI: http://www.esri.com/software/arcexplorer/about/arcexplorer-web.html 9. Geopista http://www.geopista.com 10. Visualizador GIS de la Generalitat Valenciana: http://www.gvsig.gva.es



SESIÓN 2

EDUCACIÓN, NUEVOS PARADIGMAS Y NEGOCIOS

35

Newsletter IDE Iberoamérica

Alvarez, Mabel 1 Gonzalez, María Ester2

Universidad Nacional de la Patagonia San Juan Bosco (Argentina), [email protected] 1, Universidad Nacional de la Patagonia San Juan Bosco (Argentina), [email protected]

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. ¿POR QUÉ UN NEWSLETTER IDE IBEROAMERICA? 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

Figura 1: Países de Europa que integran Iberoamérica

Newsletter IDE Iberoamérica Sesión 2


Figura 2: Países de América que integran Iberoamérica

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. ¿QUÉ ACCIONES SE REALIZARON PARA LA CONCRECIÓN DEL NEWSLETTER?

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.

Sesión 2 Newsletter IDE Iberoamérica


Una vez comunicada la selección del proyecto, se realizaron las acciones que se describen en los títulos: Definición de la lista inicial de contactos para la distribución del Newsletter: 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.

FORMATO Y CONTENIDO DEL NEWSLETTER

Para la definición del formato del Newsletter se tomó en consideración que el mismo se concretaba a través de la ayuda provista por GSDI, como tal se definió un formato parecido a los ya existentes de otras regiones y vinculados también a GSDI, pero con una base de color diferente y con un mapa esquemático representativo de los países que integran Iberoamérica.

A continuación se detalla el formato del Newsletter explicando bajo cada uno de sus títulos el alcance de los mismos:

Infraestructura de Datos espaciales(IDE) – Iberoamérica

Newsletter IDE Iberoamérica Septiembre 2005 Volumen 1 N°9 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-Iberoamérica forma parte de las actividades de un Proyecto presentado al “GSDI Small Grants Program 2004” ante “Global Spatial Data Infrastructure (GSDI) Association”. Es una publicación electrónica mensual de libre distribución para personas interesadas en las Infraestructuras de Datos

Si desea enviar información, anuncios, o comentarios relacionados a Infraestructura de Datos Espaciales (IDE), Sistemas de Información Territorial, teledetección, SIG y gestión del territorio, para su publicación en el Newsletter, por favor remítalas a [email protected] o [email protected]



Espaciales y temas afines. Las opiniones contenidas en el Newsletter constituyen responsabilidad exclusiva de sus autores.

Si considera que este Newsletter puede ser de utilidad a otras personas, reenvíelo y sugiera que los interesados se suscriban para recibirlo mensualmente. Si no desea recibir este Newsletter envíe un mensaje a [email protected] o [email protected] con el asunto remover. Los saluda cordialmente Prof. Agrim. Mabel Alvarez de López (Editor).

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)”. Presentaciones, Artículos, Vínculos y Noticias relacionadas a IDEs 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 Este título se complementa con el de Conferencias, Eventos. A diferencia del título Conferencias, Eventos que provee los datos para la localización de un Seminario, Congreso, etc., bajo este título se proporciona información más detallada de los mismos, además de las referencias de contacto. El propósito de dar información detallada se centra en lo siguiente: Parte del público receptor del Newsletter son estudiantes u otros interesados que acceden al mismo desde un cyber o locutorio, lo bajan y posteriormente lo leen. Por lo tanto debe contener información que permita una lectura completa, sin estar conectado a Internet. Conferencias, Eventos La información que se provee en este título cubre los siguientes aspectos: Período de los anuncios: Aproximadamente un año a partir de la fecha del Newsletter. Información Estructurada por mes: Con indicación de fecha, lugar, denominación del evento y formas de contacto. Indicación de la referencia NUEVO para los eventos que se incorporan, complementando los que provienen de un Newsletter anterior. Fecha Lugar Evento Diciembre 2005 12-14 Diciembre 2005

España Curso de ArcGIS Spatial Analyst http://www.esri-es.com/index.asp?pagina=322

12-16 Diciembre 2005

Buenos Aires, Argentina

Procesamiento e Interpretación Visual y Digital de Imágenes Satelitarias - Curso Intensivo - Contacto: [email protected]

Enero 2006 24-27 Enero 2006

Alicante España Simposio Internacional sobre el Uso Sostenible de las Aguas Subterráneas

ISGWAS)



Febrero 2006 7 -9 Febrero 2006

New Delhi, India Map India 2005 - http://www.mapindia.org/2005/

15 Febrero 2006

Cartagena, Colombia

XII SIMPOSIO INTERNACIONAL SELPER: SIG y Percepción Remota aplicados a “Riesgos Naturales y Gestión del Territorio” Contacto: [email protected]

27 Febrero 2006

The Netherlands GIS Tech 2005 –Rotterdam http://www.gistech.nl/

Abril 2006 23-26 Abril 2006

Tampa, La Florida E.E.U.U.

La conferencia anual y la exposición de GITA. Tecnologías de información geospatial. Teléfono: 303-337-0513 fax: 303-337-1001 Contacto: [email protected]

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: [email protected]

Junio 2006 Junio 2006 Buenos Aires,

Argentina Tercer Congreso de la Ciencia Cartográfica y X semana Nacional de la Cartografía

Septiembre 2006 19 - 22 Septiembre 2006

La Habana, Cuba II Simposio Internacional sobre Transferencias Tecnológicas Tecnotransfer

2006

24 - 29 Septiembre 2006

Cartagena, Colombia.

El XII Simposio Internacional SELPER: SIG y Percepción Remota aplicados a “Riesgos Naturales y Gestión del Territorio” Contacto: [email protected]

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 [email protected]

15-20 Octubre 2006

Munich, Alemania

FIG Congress http://www.fig2006.de

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. CONTINUIDAD DEL NEWSLETTER IDE IBEROAMÉRICA A PARTIR DE 2006 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.



Figura 3: Instituciones: UPM+ UNPSJB + Consejo Federal del Catastro. 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”. Cláusula Segunda: Campo de actividades en el marco de este Convenio

a) Formación especializada en TIG y tecnologías afines del personal de las instituciones participantes, de personal de otras instituciones españolas y de personal de otras instituciones extranjeras, principalmente iberoamericanas.

b) Investigación y desarrollo tecnológico en el campo de las TIG y otras afines. c) Difusión y transferencia de tecnología desarrollada durante la investigación.

En consecuencia, la participación del Laboratorio de Tecnologías de la Información Geográfica de la UPM en la edición del Newsletter contribuye al logro de los objetivos expuestos tanto en la exposición de motivos como de las cláusulas primera y segunda del Convenio entre la UPM y el IGN. Principales características del Newsletter a partir de 2006 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.

+ + Colaboración CFC - Argentina



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.

2. Valoración de la experiencia realizada: 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. 3. Consideraciones sobre el futuro del Newsletter: 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. El Newsletter se orientará desde 2006, principalmente a lo siguiente:

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



• Aspectos concernientes al Catastro, a la Administración de Tierras y al Ordenamiento Territorial, serán asimismo objetivos de consideración en el Newsletter.

• Complementariedad de los boletines IDE Iberoamérica e IDE – LAC que edita el Instituto Panamericano de Geografía e Historia (IPGH), a través de un trabajo coordinado entre sus editores.

REFERENCIAS 1. Global Spatial Data Infrastructure (GSDI) http://www.gsdi.org 2. Universidad Nacional de la Patagonia San Juan Bosco (UNPSJB) www.unpsjb.edu.ar 3. Universidad Politécnica de Madrid (UPM) www.upm.es 4. Comité Permanente para la Infraestructura de Datos Espaciales de las Américas (CP IDEA) www.cpidea.org. 5. Instituto Geográfico Nacional (IGN) www.mfom.es/ign 6. Instituto Panamericano de Geografía e Historia (IPGH) www.ipgh.org



Nuevos roles en el nuevo paradigma IDE

Rodríguez Pascual, Antonio F.1 López Romero, Emilio2 Abad Power, Paloma3

Sánchez Maganto, Alejandra4

Vilches Blázquez, Luis Manuel5 Instituto Geográfico Nacional (España), [email protected] 1, [email protected] 2,

[email protected] 3, [email protected] 4 , [email protected] 5

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.

“El ciberespacio. Una alucinación consensual experimentada diariamente por billones de legítimos operadores…Una representación gráfica de la información abstraída de los bancos de todos los ordenadores del sistema humano.”

Fragmento de Neuromante (1983), de William Gibson 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).

Nuevos roles en el nuevo paradigma IDE Sesión 2


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.

Sesión 2 Nuevos roles en el nuevo paradigma IDE


Análisis desde clientes ligeros 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. Clientes SIG pesados y ligeros 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. Mapas estadísticos y temáticos a la carta 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. Los clientes integrados 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. NUEVAS ACTITUDES, NUEVOS ROLES 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. ¿Todo tiene un precio? 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. El buen actor elige sus papeles 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.



Algunos Requisitos Técnicos para lograr Modelos de Negocios sustentables en una IDE

Carlos López Vázquez1

The Digital Map Ltda.(Uruguay), [email protected] 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

Sesión 2 Algunos Requisitos Técnicos para lograr Modelos de Negocios...


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. Piratería de datos geográficos 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.

Algunos Requisitos Técnicos para lograr Modelos de Negocios... Sesión 2


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. Disparidad en la base cartográfica 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. Autenticación o integridad de datos 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)



SESIÓN 3

SIG Y ORDENACIÓN DEL TERRITORIO

61

Los SIG y el control de las operaciones de recogida de información estadística

Eduard Suñé Luis Institut d’Estadística de Catalunya (IDESCAT) , [email protected]

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

• Identifica las secciones censales (delimitación del espacio y asignación de responsabilidades) • Puede asignar un cuestionario a zonas pequeñas (parcela catastral) mediante las direcciones postales, si los

datos cartográficos y alfanuméricos son disponibles y de calidad • Permiten la localización de anomalías de forma temprana a través de los datos de los cuestionarios, una vez

capturados y agregados ya sea a nivel de sección censal, superior o incluso inferior 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.

Los SIG y el control de las operaciones de recogida de información... Sesión 3


CONTROL DE COBERTURA. Las estructuras de datos del sistema pueden subdividirse en:

• Directorio de población inicial: hogares y personas. Cuestionarios iniciales. • Límites administrativos del territorio: comarca, municipio, distrito y sección censal. • Agentes de la oficina estadística: encuestadores, encargados de grupo, etc. • Cartografía correspondiente al catastro urbano[3]: masas, parcelas, elementos lineales, etc. • Información alfanumérica del catastro urbano (padrón catastral)

que en conjunto presentan el siguiente esquema entidad-relación simplificado:

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:

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

Enviado Recogido

GrabadoImputado

Tiempo

Agente entrevistador

Sección censal (*)

Distrito (*)

Municipio (*)

Comarca (*)

Hogares Cuestionario

Estados

Parcela (*)

Masa (*)

Padrón catastral (IBI)

Mapa (*) 1

1

1

1, 0

Callejero catastro

N

1

1

1 N

1 N

N

1

1

1

1

1

N

N

N N

N N M

Callejero INE

1 N

Personas N

1

Sesión 3 Los SIG y el control de las operaciones de recogida de información...


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:

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:

Figura 4: La especificacion JUMP relativa a plug-ins 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

B.D: postGIS

Cliente java, basado en JUMP

Driver JDBC

select asText(a.geom) from parcelas as a, secciones as b where b.secciones=‘0830702007’ and a.geom && b.geom and contains(b.geom,a.geom);

com.vividsolutions.jump.workbench.plugin.PlugIn public void initialize(PlugInContext context) throws Exception; public boolean execute(PlugInContext context) throws Exception; public String getName();

Un Plug-In implements



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:

Figura 7: Hogares en la parcela, número de personas 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 CONTROL DE CALIDAD DE LA INFORMACIÓN RECOGIDA. 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 :

Figura 8: Mapa temático del % de Licenciatura y doctorado. Comarca del Barcelonés



La representación en la fig. 8 se corresponde con el método de generación de clusters KMeans utilizando la implementación realizada en el proyecto Weka [7]. 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:

( )( )

( )∑

∑∑

∑∑=

= =

= =

−

−−= n

ii

n

i

n

jjiij

n

i

n

jij yy

yyyyw

w

nI

1

1 1

1 1

2

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, wij = 0 si los polígonos i y j no se tocan wij = 1 si los polígonos i y j se tocan 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 puntos en el gráfico quedan agrupados en cuatro cuadrantes :

• L-H valores bajos y vecinos con valores altos • H-H valores altos con vecinos con valores altos • H-L valores altos con vecinos de valores bajos • L-L valores bajos con vecinos de valores bajos

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

Figura 10: Resumen del ACP. Vectores y valores propios



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 :



Figura 12: Diagrama de Moran sobre el 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/



Análisis vectorial en PostGIS y Oracle Spatial: estado actual y evolución de la especificación Simple Features for SQL

Martínez Llario, José Carlos1 Coll Aliaga, Eloina2

Universidad Politécnica de Valencia (España), [email protected] 1, [email protected] 2

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. 2.- ANÁLISIS ESPACIAL PROPUESTO 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.

Análisis vectorial en PostGIS y Oracle Spatial: estado actual y... Sesión 3


2.1.- Criterios análisis espacial Localización de una determinada infraestructura bajo los siguientes criterios:

Criterio zonal (capa ‘suelos’: tsuelo = 300) Criterio zonal (capa ‘usos’: tuso > 0) Proximidad (capa ‘alcanta’: < 300 metros) Proximidad (capa ‘rios’: > 20 metros (trio = 1) > 40 metros (trio = 2)) Área final > 5 000 m2

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. 3.- ANÁLISIS ESPACIAL 3.1.- Importación de la cartografía con PostGIS La importación de la cartografía se puede realizar utilizando el comando ‘shp2pgsql’ de PostGIS: #!/bin/bash #Ficheros necesarios: #lwpostgis.sql #spatial_ref_sys.sql #rios.shp ,rios.dbf, rios.shx #suelos.shp, suelos.dbf, suelos.shx #usos.shp, usos.dbf, usos.shx #alcanta.shp, alcanta.dbf, alcanta.shx createdb test # nueva base de datos createlang plpgsql test # lenguaje plpgsql psql -f lwpostgis.sql -d test #PostGIS

psql -f spatial_ref_sys.sql -d test #EPSG #Conversión de las capas shape a PostGIS shp2pgsql rios.shp rios > rios.sql shp2pgsql suelos.shp suelos > suelos.sql shp2pgsql usos.shp usos > usos.sql shp2pgsql alcanta.shp alcanta > alcanta.sql #Carga de las capas psql -d test -f rios.sql psql -d test -f alcanta.sql psql -d test -f suelos.sql psql -d test -f usos.sql

Listado 1: Importación de datos espaciales en PostGIS

Sesión 3 Análisis vectorial en PostGIS y Oracle Spatial: estado actual y...


3.2.- Resolución con PostGIS 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)’.

crearTabla (POLYGON, tmp1) = create table tmp1 (gid serial); select addgeometrycolumn ('','tmp1','the_geom',-1,'POLYGON',2); alter table only tmp1 add constraint tmp1_pkey primary key (gid);

Área de influencia de ‘alcanta’ crearTabla (POLYGON, tmp1) 1: insert into tmp1(the_geom) select buffer(the_geom,300,32) from alcanta; crearTabla (POLYGON, alcantabuf) 2: insert into alcantabuf(the_geom) select geomunion(the_geom) from tmp1; Área de influencia de ‘rios’ 3: create table riodist (trio integer primary key,dist float); 4: insert into riodist values (1,40); 5: insert into riodist values (2,20); crearTabla (POLYGON, tmp2) 6: insert into tmp2(the_geom) select buffer(r.the_geom,d.dist,32) from rios as r, riodist as d where r.trio = d.trio; crearTabla (MULTIPOLYGON, riosbuf) 7: insert into riosbuf(the_geom) select geomunion (the_geom) from tmp2; Intersección de ‘suelos’ y ‘alcanta’ 8: create index suelos_the_geom_idx ON suelos USING GIST (the_geom GIST_GEOMETRY_OPS); 9: vacuum analyze suelos (the_geom); 10: create index usos_the_geom_idx ON usos USING GIST (the_geom GIST_GEOMETRY_OPS); 11: vacuum analyze usos (the_geom);

crearTabla (MULTIPOLYGON, inter) 12: insert into inter (tuso,tsuelo,the_geom) select u.tuso, s.tsuelo, multi(intersection (u.the_geom,s.the_geom)) from usos as u, suelos as s where u.the_geom && s.the_geom and intersects (u.the_geom,s.the_geom); 13: create view vinter as select i.gid as gid,i.the_geom as the_geom from inter as i where i.tuso = 300 and i.tsuelo > 0; Diferencia entre las áreas de influencia crearTabla (MULTIPOLYGON, difbuf) 14: insert into difbuf (the_geom) select multi(difference (c1.the_geom,c2.the_geom)) from alcantabuf as c1, riosbuf as c2 where intersects (c1.the_geom,c2.the_geom); crearTabla (MULTIPOLYGON, final) 15: create index inter_the_geom_idx on inter using gist (the_geom GIST_GEOMETRY_OPS); 16: vacuum analyze inter (the_geom); 17: create index difbuf_the_geom_idx on difbuf using gist (the_geom GIST_GEOMETRY_OPS); 18: vacuum analyze difbuf (the_geom); 19: insert into final (the_geom) select multi(intersection (v.the_geom,b.the_geom)) from vinter as v,difbuf as b where v.the_geom && b.the_geom and intersects (v.the_geom,b.the_geom); Resultado final 20: select gid, area(the_geom) as area from final order by area desc;

Listado 2: Sentencias del análisis espacial en PostGIS

3.3.- Importación de la cartografía con Oracle Spatial 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. #Conversión a formato sql espacial de Oracle shp2sdo suelos suelos –g Geom –d –x (0,10000) –y (0,10000) –t 0.000001 –v –i gid shp2sdo usos usos –g Geom –d –x (0,10000) –y (0,10000) –t 0.000001 –v –i gid shp2sdo rios rios –g Geom –d –x (0,10000) –y (0,10000) –t 0.000001 –v –i gid shp2sdo alcanta alcanta –g Geom –d –x (0,10000) –y (0,10000) –t 0.000001 –v –i gid #Creación del esquema de las tablas (ejecución dentro de isqlplus) start suelos.sql start usos.sql start rios.sql start alcanta.sql



#Carga sql utilizando sqlloader Sqlldr user/contraseña suelos Sqlldr user/contraseña suelos Sqlldr user/contraseña suelos Sqlldr user/contraseña suelos

Listado 3: Importación de datos espaciales en Oracle Spatial

3.4.- Resolución con 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); 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);

Área de influencia de ‘alcanta’ crearTabla (tmp1) 1: insert into tmp1 (gid,geom) select a.gid, SDO_GEOM.SDO_ARC_DENSIFY (sdo_geom.sdo_buffer (a.geom,300,0.000001),0.000001, 'arc_tolerance=1') from alcanta a; crearTabla (alcantabuf) 2: insert into alcantabuf (gid,geom) select 1, SDO_AGGR_UNION( SDOAGGRTYPE(a.geom, 0.000001)) from tmp1 a; Área de influencia de ‘rios’ 3: create table riodist (trio number(1) primary key,dist number(2)); 4: insert into riodist values (1,40); 5: insert into riodist values (2,20); crearTabla (tmp2) 6: insert into tmp2(gid,geom) select r.gid, SDO_GEOM.SDO_ARC_DENSIFY (sdo_geom.sdo_buffer(r.geom,d.dist, 0.000001),0.000001,'arc_tolerance=1') from rios r, riodist d where r.trio = d.trio; crearTabla (riosbuf) 7: insert into riosbuf (gid,geom) select 1, SDO_AGGR_UNION(SDOAGGRTYPE (a.geom, 0.000001)) from tmp2 a; Intersección de ‘suelos’ y ‘alcanta’ 8: CREATE INDEX suelos_idx ON suelos (geom)INDEXTYPE IS MDSYS.SPATIAL_INDEX; 9: CREATE INDEX usos_idx ON usos (geom)INDEXTYPE IS MDSYS.SPATIAL_INDEX; crearTabla (inter)

10: insert into inter (gid, tsuelo, tuso, geom) select u.gid*1000+s.gid, s.tsuelo, u.tuso, sdo_geom.sdo_intersection (u.geom,s.geom, 0.000001) from usos u, suelos s where SDO_FILTER(u.geom,s.geom) = 'TRUE' and (sdo_geom.relate(u.geom, 'OVERLAPBDYINTERSECT',s.geom,0.000001) = 'OVERLAPBDYINTERSECT' or sdo_geom.relate(u.geom,'INSIDE', s.geom,0.000001) = 'INSIDE'); 11: create view vinter as select i.gid gid, i.geom geom from inter i where i.tuso = 300 and i.tsuelo > 0; Diferencia entre las áreas de influencia crearTabla (difbuf) 12: insert into difbuf (gid, geom) select c1.gid, sdo_geom.sdo_difference (c1.geom,c2.geom,0.000001) from alcantabuf c1, riosbuf c2; crearTabla (final) 13: CREATE INDEX inter_idx ON inter (geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX; 14: CREATE INDEX difbuf_idx ON difbuf (geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX; 15: insert into final (gid, geom) select v.gid*1000+b.gid, sdo_geom.sdo_intersection (v.geom,b.geom, 0.000001) from vinter v, difbuf b where SDO_FILTER(v.geom,b.geom) = 'TRUE' and (sdo_geom.relate (v.geom, 'OVERLAPBDYINTERSECT', b.geom,0.000001) = 'OVERLAPBDYINTERSECT' or sdo_geom.relate (v.geom,'COVEREDBY', b.geom,0.000001) = 'COVEREDBY' or sdo_geom.relate (v.geom, 'INSIDE', b.geom,0.000001) = 'INSIDE'); Resultado final 16: select gid, sdo_geom.sdo_area (geom, 0.000001) area from final order by area desc;

Listado 4: Sentencias del análisis espacial en Oracle Spatial



4.- Funcionalidades de los sistemas 4.1.- Importación de datos espaciales 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. 4.2.- Especificación SFS 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.

4.3.- Tablas espaciales 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.

SELECT ADDGEOMETRYCOLUMN ('','tmp1','the_geom',-1,'POLYGON',2);

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. 4.4.- Incompatibilidad con la especificación SFS 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: Tipos de geometrías devueltas en una operación de intersección espacial en PostGIS 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:

Una intersección de dos polígonos devuelve una única geometría. Si esta geometría está formada por varios elementos de tipo POINT, LINESTRING o POLYGON será de tipo

‘multi’, es decir, MULTIPOINT, MULTILINESTRING o MULTIPOLYGON. Si el resultado es una geometría mixta de varios tipos sencillos, será de tipo GEOMETRYCOLLECTION.

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. 4.4.2.- Oracle Spatial 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. 4.5.- Problemas de eficiencia en las áreas de influencia

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:

1. Primero se realiza el buffer de cada una de las geometrías de la capa 2. Segundo se disuelven las fronteras adyacentes entre los polígonos creados por el buffer

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.



INSERT INTO alcantabuf (gid, geom) SELECT 1,sdo_aggr_union(mdsys.sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(mdsys.sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(mdsys.sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(mdsys.sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(mdsys.sdoaggrtype(geom,0.5)) aggr_geom FROM tmp1 GROUP BY mod(rownum,16)) GROUP BY mod (rownum, 8)) GROUP BY mod (rownum, 4)) GROUP BY mod (rownum, 2));

Listado 5. Segmentación en la creación de áreas de influencia 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 1. Manuales de Oracle Spatial 10g. http://www.oracle.com (último acceso: Octubre, 2005) 2. Manual de PostGIS. http://www.postgis.org/ (último acceso: Noviembre, 2005) 3. Martinez-Llario, J. C., Coll, E. (2005): Spatial Analysis using OpenGIS Specifications: ‘Simple Features for SQL’. WSEAS Transactions on Information Science and Applications. ISSN 1790-0832 4. Open GIS Consortium, Inc. (1998): Conformance Test Guidelines for OpenGIS Simple Features Specification for SQL, Rev. 1.0. 5. Open GIS Consortium, Inc. (1998): Simple Features Specification for SQL (SFS). Version 1.1. 6. Vivid Solutions. (2005): JTS Technical Specifications, Victoria, Canada.



Integración de la Información Territorial

Bernet Herguijuela, Remedios1 Mateos Marín, José Antonio2

Agencia Extremeña de la Vivienda Junta de Extremadura [email protected] 1, Agencia Extremeña de la Vivienda Junta de Extremadura, [email protected]

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. Con esas funciones se perfila la configuración de un Observatorio Territorial, en el cual se abordan:

• 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. PLANTEAMIENTO INICIAL Y EVOLUCIÓN DEL SISTEMA DE INFORMACIÓN TERRITORIAL 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

Integración de la Información Territorial Sesión 3


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. En el 2004 se reinicia la implantación del módulo de territorio con la generación.

• De un modelo de Datos lógico. Entidad-relación que normalice la información de territorio. Se trata de un Modelo de datos dinámico flexible, que da cabida a información no prevista en el diccionario de datos, permite ajustarse a los datos procedentes de las instituciones. Se ha desarrollado de forma dinámica y progresiva, adaptándonos a las nuevas posibilidades tecnológicas.

• El diseño de un modelo de datos, lo definiríamos como una estructura organizativa de la información territorial que la clarifica, agrupa y ayuda a su exploración y visualización

• Un protocolo de carga para mantenimiento, explotación y actualización de dicha información. • El catálogo de información • Herramientas de consulta y análisis adaptadas al nuevo modelo

Figura 1: Entrada de datos a los distintos módulos y finalidad.

PLANEAMIENTO DIGITAL

DATOS ADMINISTRATIVOS

PLANEAMIENTO RASTER

SEGUIMIENTO PLANEAMIENTO

VISUALIZADOR

HERRAMIENTA DE DISEÑO

BASES EXTERNAS

ESTUDIOS TERRITORIALES

CONEXIÓN BASES EXTERNAS

CODIFICACIÓN Y TRADUCTOR

OBJETIVOS

PLANIFICACION TERRITORIAL

HERRAMIENTA DE DISEÑO

SISTEMA DE INFORMACIÓN GEOGRAFICA DE LA D.U.O.T. DE LA JUNTA DE EXTREMADURA

TIPO DE HERRAMIENTA

CARTOGRAFIA PROPIA

CODIFICACION

CARTOGRAFIA CATASTRAL

TRADUCTOR CATASTRAL

CARTOGRA

FIA BASE

PLANEAMIENTO GENERAL

PLANEAMIENT

O DE DESARROLLO

TRAMITACIÓN ADMINISTRATI

VA

MODELO DE DATOS DEL TERRITORIO

ESTUDIOS TERRITORIAL

ES

PLANIFICACION

MANTENIMIENTO DEL ARCHIVO CARTOGRAFICO REGIONAL CREACIÓN DE LA CARTOGRAFIA INTELIGENTE DIFUSIÓN PUBLICA (VIA INTERNET ) COMERCIO ELECTRONICO

MANTENIMIENTO DEL ARCHIVO URBANISTICO REGIONAL AGILIZACION DE LA TRAMITACIÓN Y DE LA MODIFICACIÓN DEL PLANEAMIENTO FACILIDAD DE CONSULTA

CREACIÓN DE UNA BASE ACTUALIZADA DE DATOS DE TERRITORIO MANTENIMIENTO DEL ARCHIVO DE PLANEAMIENTO TERRITORIAL ANÁLISIS TERRITORIAL OBSERVATORIO TERRITORIAL FACILIDAD DE CONSULTA

ORTOFOTOS CARGADOR

ENTRADA DE

Figura 1:

Figura 1:

Sesión 3 Integración de la Información Territorial


Requisitos y prestaciones del sistema territorial extremeño 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

NORMALIZACIÓN DE LA INFORMACIÓN DE TERRITORIO. MODELO DE DATOS 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:

• Por un parte, responder a la modernización administrativa de un servicio público de claras implicaciones territoriales mediante recursos y tecnologías de información espacial (SIG).

• Valorar la disponibilidad actualizada de la información como soporte para toma de decisiones y su consideración indispensable en los instrumentos de ordenación territorial.

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-) De cara al intercambio y la integración de la información debemos valorar distintos aspectos:

• 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-).

REQUISITOS Y NORMAS PARA LA CARGA DE INFORMACIÓN TERRITORIAL

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.

Desarrollo de la herramienta de chequeo de cartografía a gran escala.

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



• Identificación de geometrías poligonales erróneas por no encontrarse cerradas. • Eliminación de geometrías duplicadas. • Validación de códigos de catastro. • Validación de la codificación de cartografía catastral.

Composición del formato de diseño de Información (FDI). 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. El modelo de datos de cada tabla será generada en cuatro pasos:

I) Creación de la tabla. Que consta de los siguientes caracteres: INF_D_T_V_ nombre_tabla. Donde D,T,V deben ser sustituidos por los valores del código del domini de la tabla, del tema y de la variable.

II) Inserción de los campos de la tabla. Se insertan los campos de la tabla dependiendo del modelo de la tabla origen según el siguiente criterio.

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. Importador Shape de Territorio. 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”.

Herramienta de diseño de planeamiento territorial

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.

Figura 2: Carga e intercambio de información territorial. Herramienta de planeamientno territorial.

Exportación de cartografía digital. 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.

D.U.O.T

CARTOGRAFÍA BASE

BD SIGCAT

HERRAMIENTA DE DISEÑO DE PLANEAMIENTO

CD-ROM

HDPU

CD-ROM

HDPU

HERRAMIENTA DISEÑO DE PLANEAMIENTO

PLANOS Y NORMATIVA

MEMORIA

PLANEAMIENTO DIGITAL

CARGADOR PLANEAMEINTO

INFORMACION TERRITORIAL

CARGADOR TERRITORIO

EQUIPOS REDACTORES

PLANEAMIENTO

PLANEMIENT

PLANEMIENTO



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: • A los usuarios la localización y el conocimiento de la disponibilidad de información existente en la agencia. • La información útil de cada conjunto de datos identificado, permitiéndole al usuario decidir si le es útil para el

uso que quiere hacer de estos datos. Aspectos como la calidad, precisión o el ámbito temporal de los datos son algunos de las informaciones que pueden ayudar al usuario a decidir.

• La comunicación e intercambio de información con otros actores con la construcción de un espacio cooperativo entre la Agencia, sus colaboradores, sus proveedores y parteners de proyectos e iniciativas comunitarias.

• Apoya el proceso de comercialización de la información • La publicación y mantenimiento de datos, aplicaciones, noticias, directorio y contactos. 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.

IMPLEMENTACIÓN DE METADATOS EN EL SIGCAT Y EN LAS HERRAMIENTAS DE PLANEAMIENTO

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. La puesta en marcha se ha impulsado basada en acuerdos de cooperación, convenios, protocolos de intercambio de información entre instituciones. 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. En próximas contrataciones la herramienta de administración del Catálogo, se modificará el diseño de la aplicación web incorporando la publicación de metadatos de nuestros productos y de los datos geográficos disponibles mediante un sistema de búsqueda estructurada de metadatos y con visualizador de mapas, siempre supervisado en el caso de información geográfica de otros productores, por el organismo correspondiente



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.



Modelo de datos UML y XML del catálogo de fenómenos de la Base topográfica 1:5000 de Catalunya v2 basado en estándares ISO19100

Zabala Torres, Alaitz1 Masó Pau, Joan2

Lleopart Grau, Anna3 Barrot Feixat, Dolors4

Dept. Geografia, Universitat Autònoma de Barcelona, [email protected] 1

Centre de Recerca Ecològica i Aplicacions Forestals, CREAF, [email protected] 2 Institut Cartogràfic de Catalunya, ICC, [email protected] 3, [email protected] 4

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.

Sesión 3 Modelo de datos UML y XML del catálogo de fenómenos de la Base...


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.

OBJETO nombre_objeto código_objeto Definición GEOMETRÍA Tipo de representación geométrica ATRIBUTOS a1 • v11 ... • v1m

c11 ... c1m

Descripción de l’atribut 1 descripción del significado del valor 1 ... descripción del significado del valor m

... ... ... An • vn1 ... • vnp

cn1 ...

cnp

Descripción de l’atribut n descripción del significado del valor 1 ... descripción del significado del valor p

CLASIFICACIÓN Y MÉTODO DE OBTENCIÓN Descripción de los criterios de clasificación y del método de captura

SELECCIÓN Descripción de los filtros de selección aplicados COMBINACIONES PREVISTAS DE ATRIBUTOS (CASOS) nombre_objeto: • /v1i /... /vnj

• ... • /v1k /... /vnl

código_caso_1 ...

código_caso_t

COMPONENTES DEL OBJETO COMPLEJO Se da el tipo de geometría del objeto complejo

nombre_objeto: /v1j /.../vnk • nombre_objeto_j: /v1p /... /vmq • ...

código_caso_i

RELACIONES • nombre_objeto: /v1j /.../vnj • ...

Relación • nombre_objeto_k: /v1r /.../vms • ...

NOTAS Otra información de interés GRÁFICOS Gráficos que ilustran aspectos relacionados con el método de captura y la clasificación del objeto

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

Modelo de datos UML y XML del catálogo de fenómenos de la Base... Sesión 3


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. Ordnance Survey - MasterMaP 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]. UKHO S-57/GML Project 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]. IHO S-57 Edition 4.0 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.

Figura 1: Modelo UML generado para el catálogo de fenómenos de la BT-5M 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. CONSIDERACIONES SOBRE LAS PROPIEDADES CONSTANTES 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.

Figura 2: Niveles de abstracción definidos en ISO19109

DICCIONARIO DE DATOS Se han generado diversos esquemas y ficheros XML que conforman la versión estandarizada del Diccionario de Datos. • FeatureCatalogICC.xml: descripción del catálogo de objetos. Incluye la información contenida en el antiguo

Diccionario de Datos, es decir, las propiedades constantes para cada tipo de objeto (ver Figura 6). • 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)



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

HOJAS DE ESTILO PARA EL DICCIONARIO DE DATOS 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.

<gml:dictionaryEntry> <CatICC:GrupTopo gml:id="GT1">

<gml:name>Elevacions del terreny en general (massís, serra, turó, muntanya, cim...)</gml:name> <CTInclosos>501xx ; 502xx</CTInclosos> </CatICC:GrupTopo> </gml:dictionaryEntry> <gml:dictionaryEntry> <CatICC:CodiTopo gml:id="CT00001"> <gml:name>Municipi</gml:name> <GrupTop xlink:href="#GT17"/> </CatICC:CodiTopo> </gml:dictionaryEntry>

<gml:dictionaryEntry> <CatICC:CI_RoleCode gml:id="coordinator"> <gml:name>Coordinador</gml:name> <Descripcio> <text lang="ca">Coordinador</text> <text lang="sp">Coordinador</text> <text lang="en">Coordinator</text> </Descripcio> </CatICC:CI_RoleCode> </gml:dictionaryEntry>

Figura 4: Fragmento del diccionario de

Códigos y Grupos de Topónimos

Figura 5: Fragmento del diccionario de Listas de Códigos

(CodeLists) usadas en la BT-5M

 <xs:complexType name="CadenesIdiomatiques"> <xs:sequence> <xs:element name="text" type="CatICC:CadenaIdiomatica" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <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>  <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>

Estilo “Diccionario de Datos” 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”.

Figura 6: Fragmento del Diccionario de datos (FeatureCatalogICC.xml) correspondiente al tipo de objeto “Parcela de urbanización”

Estilo “ISO 19110” 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

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



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

DISTRIBUCIÓN DE DATOS: ESQUEMA DE APLICACIÓN GML 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.

Figura 7: Visualización del tipo de objeto “Parcela de urbanización” con el estilo del Diccionario de Datos

Figura 8: Visualización del tipo de objeto “Línea de costa detallada”

(línea compleja) con el estilo ISO19110



Sustitución de FeatureCollection, FeatureMember y FeatureMembers 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).

Relación con el catálogo de objetos Los elementos descritos en los documentos de distribución de los datos están directamente vinculados con la descripción del tipo de objeto correspondiente en el catálogo (FeatureCatologICC.xml). Esto se realiza definiendo una propiedad “tipo de objeto” con valor fijo para cada elemento, que en el esquema de aplicación se define una sola vez para cada tipo de objeto. En la figura 11 se muestra como se define esta propiedad fija en el esquema de aplicación y en la figura 10 como se codifica en una instancia de este tipo de objeto. Geometría de los objetos 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). Atributos no geométricos de los objetos 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].

<BT5M_ICC:Cota gml:id="T1"> <TipoObjeto xlink:href="FeatureCatalogICC.xml#COT"/> <CodigoCaso>COT02</CodigoCaso> <Z>23.54</Z> <BT5M_ICC:GeometriaPunto> <gml:Point> <gml:pos>1 3</gml:pos> </gml:Point> </BT5M_ICC:GeometriaPunto> </BT5M_ICC:Cota>

Figura 9: Esquema de elementos GML generados y su uso para

representar Hojas y Fenómenos de la Base topográfica

Figura 10: Ejemplo de la definición de un objeto de tipo “Cota

altimétrica” en el fichero GML de distribución de datos

<xs:element name="TipoObjeto"> <xs:complexType> <xs:attribute ref="xlink:href" fixed="FeatureCatalogICC.xml#COT"/> </xs:complexType> </xs:element>

Figura 11: Definición de la propiedad fija “tipo de objeto” en el esquema de aplicación para el objeto de tipo “Cota altimétrica”

Subconjunto BT5M (FeatureCollection)

Hoja BT5M(FeatureMembers)

Fenómeno(FeatureMember)


0 1 0 *

0

*

Subconjunto BT5M (FeatureCollection)

Hoja BT5M(FeatureMembers)



0 10 1 0 *0 *

0

*



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 Actualmente no existe una especificación de implementación de los catálogos de objetos complementaria a la ISO19110. Este trabajo demuestra que es posible usar una notación basada en los objetos primarios GML para generar catálogos de tipos de objeto que pueden ser visualizados en diferentes estilos usando XSL. Al mismo tiempo estos catálogos pueden ser usados para generar esquemas XSD para la distribución de datos de la Base topográfica 1:5000 de Catalunya v2.0 (BT-5M) en formato GML. Cada uno de estos objetos conserva un vínculo a tipo de objeto del catalogo de objetos. La enorme flexibilidad de la especificación GML, permite adaptar los esquemas de aplicación a las necesidades de la base. Los diagramas UML resultan muy útiles durante el proceso de diseño pero, a día de hoy, la transformación automática a esquemas XSD solo es posible para aplicaciones simplistas que no han resultado aplicables en nuestro caso. 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.



Álgebra para la gestión de coberturas y su integración en XQuery

Diego Loureda Couceiro1 José Ramón Ríos Viqueira2

José Varela Pet3 Pedro Álvarez Pérez-Aradros4

Universidad de Santiago de Compostela (España) , [email protected], [email protected], [email protected] Universidad de Zaragoza (España), [email protected]

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

Álgebra para la gestión de coberturas y su integración en XQuery Sesión 3


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. Espacio geográfico y localizaciones 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

R2n ≡ {(x, y) | x, y ∈ R ∧ -n-0.5 ≤ x, y < n+0.5}.

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 R2

n

zi,j ≡ {(x, y) | x, y ∈ R ∧ i-0.5 ≤ x < i+0.5 ∧ j-0.5 ≤ y < j+0.5 }.

-2

-2.5

-1 0 1 2

-1.5 -0.5 0.5 1.5 2.5

z0,0

510

815

818

1022

A A A B B

A A A B B

A C B B B

C C C A A

C C C A A

20

19

17

16

18

18

19

17

15

18

17

18

16

14

17

18

19

17

16

17

17

18

16

16

17

(a) Espacio y Localizaciones (b) METEO (c) MUNICI (d) ELEV

Figura 1: Espacio, localizaciones y coberturas geográficas

Sesión 3 Álgebra para la gestión de coberturas y su integración en XQuery


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 Z2

n = {zi,j | i, j ∈ Z ∧ -n ≤ i, j ≤ n}es una representación discreta (finita) del espacio geográfico. Claramente, Z2

n 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 Z2

n. La Figura 1(a) ilustra los conceptos anteriores para n = 2. Dominios y coberturas geográficas Un dominio geográfico es un subconjunto S del espacio geográfico (S ⊆ R2

n) que se puede expresar como la unión de un conjunto finito de localizaciones, es decir,

Ui ip S= , 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

Ai: {p ∈ Z2n | p ⊆ S} → Di ∪ {undefined}, i = 1, 2, ..., m.

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. ÁLGEBRA DE COBERTURAS GEOGRÁFICAS 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

• Si p ⊆ S1∩S2 entonces C.Ai(p) ≡ C1.Ai(p), ∀ i = 1, 2, ..., n y C.Bj(p) ≡ C2Bj(p), ∀ j = 1, 2, ..., m. • Si p ⊆ S1−S2 entonces C.Ai(p) ≡ C1.Ai(p), ∀ i = 1, 2, ..., n y C.Bj(p) ≡ undefined, ∀ j = 1, 2, ..., m. • Si p ⊆ S2−S1 entonces C.Ai(p) ≡ undefined, ∀ i = 1, 2, ..., n y C.Bj(p) ≡ C2Bj(p), ∀ j = 1, 2, ..., m.

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:

FOR EACH <loc1>, <loc2> WHERE <condition> COMPUTE B1 = e1, B2 = e2, ..., Bm = em

<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. Ilustración de la funcionalidad alcanzada 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

5

(a) EDIFICIOS

20

19

21

16

18

18

24

20

15

18

17

18

16

14

17

18

25

17

16

17

17

18

16

16

17

(b) ELEV_TOTAL

0

3

0

0

0

0

0

0

0

0

0

4

0

0

6

0

0

0

0

0

0

0

0

Figura 2: Ilustración de la suma local de elevaciones (Figura 1(d)) y alturas de edificios. 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) ELEV_TOTAL = Evaluate[FOR EACH p COMPUTE elev_total(p) = elevacion(p) + elev_edif(p)](C)



El esquema de la cobertura resultante es ELEV_TOTAL[S2](elev_total | real), y su representación gráfica se muestra en la Figura 2(b). Es importante recordar en este punto que tanto elevacion como elev_edif son funciones que aplicadas a una localización devuelve un valor real. Para cada localización p de C el valor de elev_total(p) se obtiene de la evaluación de la expresión elevacion(p) + elev_edif(p). Las referencias explicitas a la primera variable de una sentencia de cómputo (p en este ejemplo) se pueden eliminar de todas las bandas. Así, la expresión anterior podría escribirse también como: elev_total = elevacion + elev_edif. Esta decisión de diseño tiene como objeto simplificar la sintaxis de las sentencias. Más adelante veremos que estas referencias no podrán eliminarse para las variables que no son la primera ni para funciones que no sean bandas.

(a)

18126

17.3191

18126

18126

18126

18126

18126

18126

17.3191

17.3191

17.319117.3191

17.3191

17.3191

17.319117.3191

17.3191

17.3191

16.1113

16.111316.1113

16.1113

16.1113

16.111316.1113

z-2,-2

z

z

z

z

z

z

-2,-2

-2,-2

-2,-2

-2,-2

-2,-2

-2,-2

. . .

. . .

z-2,-2

z

z

z

z

z

z

-1,-2

0,-2

1,-2

2,-2

-2,-1

2,2

. . .

. . .

p p1

(b)

z-2,-2

z

z

z

z

z

z

-2,-2

-2,-2

-2,-2

-2,-2

-2,-2

-2,-2

. . .

z-2,-2

z

z

z

z

z

z

-1,-2

0,-2

-2,-1

-1,-1

0,-1

-1,0

. . .

p p1

(c)

WHERE-2,-2z

. . .

z-2,-2

z

z

z

z

z

z

-1,-2

0,-2

-2,-1

-1,-1

0,-1

-1,0

. . .

p p1

(d)

-2,-2z. . .

16.1. . .

p elev_media

(e)

sum_elev

113. . .}

avg(e

levac

ion(p

1))

sum

(ele

vac

ion(p

1))

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) ELEV_MUNICIPAL = Evaluate[FOR EACH p, p1

WHERE nombre = nombre(p1) COMPUTE elev_media = avg(elevacion(p1)),

sum_elev = sum(elevacion(p1))](C) El esquema de la cobertura resultado es ELEV_MUNICIPAL [S2](elev_media | real, sum_elev | real) y su representación gráfica se muestra en la Figura 3(a). Para obtener este resultado, en primer lugar se obtienen todas las combinaciones (p, p1) de localizaciones en el dominio de C (ver Figura 3(b) para p = z-2,-2). Después la cláusula WHERE restringe esas combinaciones a aquéllas en las que el valor de la banda nombre en p es igual al valor de la banda nombre en p1, es decir, nombre(p) = nombre(p1) (ver Figura 3(c) para p = z-2,-2). En este caso la referencia a la variable p1 no puede eliminarse de la expresión. Implícitamente, antes del cómputo de las expresiones, las combinaciones (p, p1) resultantes se agrupan por p. Así, para cada grupo, es decir, para cada localización p, se obtiene la colección de localizaciones p1 que están en su misma zona para la banda nombre (ver Figura 3(d) para p = z-2,-2). Finalmente, el valor de la banda elev_media para cada p, se obtiene aplicando la función de agregado avg sobre las elevaciones en cada p1 de su grupo. De forma similar, la función de agregado sum permite calcular la suma de todas las elevaciones en cada grupo, es decir, en cada p (ver Figura 3(e) para p = z-2,-2). 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

d id ),i i1/d)/(i i/dit( T <∑∑=



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) METEO2 = Evaluate[FOR EACH p, p1

WHERE distance(p, p1) < 2 and temperatura(p1) IS DEFINED and humedad(p1) IS DEFINED COMPUTE

temperatura = sum(temperatura(p1)/distance(p, p1)) / sum(1/distance(p, p1)), humedad = sum(humedad(p1)/distance(p, p1)) / sum(1/distance(p, p1))](C1)

5

108

15

818

1022

z0,0

2

temperatura(Z ) = (8/1.41 + 10/1.41 + 8/1.41) / (1/1.41 + 1/1.41 + 1/1.41) = 8.60,0

humedad(Z ) = (15/1.41 + 22/1.41 + 18/1.41) / (1/1.41 + 1/1.41 + 1/1.41) = 18.30,0

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.

20

1919 19

18

17

18

17 17

x = 19 + 2*18 + 17 19� ��

y = 17 + 2*17 + 17 19� ��

pendiente = atan( )(x/8) + (y/8) = 0.782 2

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)



PENDIENTE = Evaluate[FOR EACH p COMPUTE pendiente = atan(sqrt((x / 8)^2 + (y / 8)^2))](C1)

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. GESTIÓN DE COBERTURAS EN GML 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. Representación 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>. Integración del álgebra de coberturas en XQuery 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. LET $meteo := doc(‘meteo.gml’) LET $cadena := string-join((“FOR EACH p, p1”, “WHERE distance(p, p1) < 2 and temperatura(p1) IS DEFINED”, “COMPUTE”, “temperatura = sum(temperatura(p1)/distance(p, p1))”, “/ sum(1/distance(p, p1))”), “ ”) LET $temperatura := Evaluate($cadena, $meteo) RETURN $temperatura 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



Figura 6: Elevación sobre el nivel del mar

Figura 7: Estaciones meteorológicas

Figura 8: Modelos de combustible

Figura 9: Pendiente

Figura 10: Temperatura

Figura 11: Humedad

Figura 12: Riesgo de propagación de incendios



CONCLUSIONES Y TRABAJO FUTURO 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).

Para terminar, las líneas de trabajo futuro incluyen:

• La formalización de la semántica de las sentencias de cómputo de bandas en un entorno formal de cálculo de predicados, así como la definición completa de la sintaxis del lenguaje.

• La implementación de un parser para el lenguaje anterior y el desarrollo de los algoritmos necesarios. • La investigación en técnicas de optimización de sentencias de cómputo. • La incorporación del lenguaje en un servicio de análisis de datos espaciales [9] que permita la consulta

uniforme de fuentes de datos OGC, es decir, WFS y WCS. 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.



SESIÓN 4

METADATOS

111

Definición de Perfiles y creación de ficheros XML de metadatos para imágenes de Teledetección, según la normativa ISO, utilizando la

aplicación IME (ISO Metadata Editor) desarrollada en el Servicio de Teledetección del INTA.

Amaro Cormenzana, Alberto1 Dominguez Barroso, Nines2

Prado Ortega, Elena3

Instituto Nacional de Técnica Aeroespacial (I.N.T.A.) (España) ,mailto:[email protected], mailto:[email protected], mailto:[email protected]

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:

1. Estudio de la ISO19115 y selección de los metadatos de interés. 2. Desarrollo de una aplicación de apoyo para la generación de perfiles de metadatos y ficheros XML de acuerdo

con las normas ISO19115 e ISO19139.

De�nición de Per�les y creación de �cheros XML de metadatos para... Sesión 4


3. Generación de un perfil de metadatos propio. 4. Comprobación de nuestro perfil con el NEM y generación del perfil definitivo. 5. Creación de plantillas. 6. Estudio de la ISO19139 y utilización del esquema XML propuesto hasta la fecha por dicha norma.

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.

Figura 1: Ventana principal software IME version 3.0

Selección de metadatos de la ISO19115 para el perfil de los datos de Teledetección 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. Para nuestro perfil se seleccionaron las siguientes entidades (figura 2): MD_Metadata->spatialRepresentationInfo para proporcionar información sobre el número de filas y columnas de las imágenes.

MD_Metadata->referenceSystemInfo para establecer los parámetros de la proyección cartográfica de las imágenes cuando están georreferenciadas.

MD_Metadata->identificationInfo donde se describen características de los datos y su uso.

MD_Metadata->contentInfo que contiene una clase específica para descripción de imágenes y que permite incluir información sobre el parámetro contenido por los píxeles, sobre las bandas de la imagen y también sobre las condiciones de adquisición y el nivel de proceso.

MD_Metadata->distributionInfo que permite informar sobre el formato de distribución.

Sesión 4 De�nición de Per�les y creación de �cheros XML de metadatos para...


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

Figura 2: Metadatos y Entidades seleccionados

Desarrollo de la herramienta IME para la aplicación de la normativa ISO 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. La herramienta IME fue diseñada con dos premisas fundamentales:

• Ser un reflejo de la norma ISO19115 para permitir crear perfiles de metadatos diferentes según las necesidades de cada usuario.

• Funcionar en un entorno de uso extendido y ser fácilmente adaptable a los cambios en la normativa. Entre las principales utilidades que ofrece se incluyen:

• Identificación del tipo de clase (especificada, abstracta, clase,…) mediante un icono (ver figura 3). • Identificación de metadatos definidos en otras normas relacionadas con la ISO19115 • Visualización del camino completo para localizar un metadato (ver figura 4). • Activación y desactivación de metadatos que forman el perfil (ver figura 5). • Búsqueda de metadatos. • Lectura y creación de ficheros de metadatos XML y plantillas de texto.

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:

• Incorporación de nuevas entidades y metadatos. • Modificación de las propiedades de los metadatos definidos. • Modificación de los metadatos que aparecen activados al iniciarse la aplicación. • Modificación de los espacios de nombres definidos en la ISO19139.



Figura 3: Iconos para identificación de Tipo de Dato

Figura 4: Path desde el elemento raiz hasta un metadato

Figura 5: Menú de selección de metadatos para configuración de un Perfil

Generación de un perfil propio para datos de Teledetección 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.

Figura 6: Extensión para datos de sensores aeroportados



Comparación del perfil de Teledetección con el NEM 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. El perfil del Servicio de Teledetección incluye las clases MD_SpatialRepresentation y MD_ContentInformation, no contempladas en el NEM, con el objetivo de describir los datos de teledetección correctamente. 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 Como breve referencia al resto de las entidades:

• En referenceSystemInfo sólo se incluye la descripción del sistema de referencia espacial mediante la entidad MD_CRS.

• Se utiliza identificationInfo, al igual que en el NEM, para incluir toda la información relativa a los datos en cuanto a restricciones, palabras clave, referencias de contacto, uso, extensión espacial y temporal, etc...

• En distributionInfo se proporciona información sobre la distribución de los datos, es decir, cómo y quién los distribuye. Sin embargo, dado que la mayor parte de esta información ya ha sido proporcionada en otras secciones del perfil, en este caso sólo se ha añadido información del formato.

• En dataQuality también se encuentran diferencias respecto al NEM, en la figura 9 se pueden ver los metadatos con los que se ha trabajado en este perfil:

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 . Creación de Plantillas y generación de ficheros XML 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 10: Submenú del editor de metadatos

Figura 11: Edición de metadatos con texto libre

Figura 12: Selección de opciones en codelists

Para completar la plantilla, se decidió:

• Escribir directamente en este Editor los valores que se mantienen constantes en diferentes campañas de vuelo. • Incluir comentarios que faciliten la localización de los metadatos que varían en cada campaña.

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.



Figura 13: Formato de plantilla de metadatos generada con IME El paso final fue la obtención de un fichero XML utilizando la misma aplicación. 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. Los principales problemas encontrados han sido:

• La norma ISO 19139 todavía está en desarrollo y aún no se ha podido contar con un esquema de implementación definitivo.

• Por otra parte se ha comprobado que en algunos casos el esquema actual disponible no se adecúa perfectamente a la norma ISO19115, por ejemplo en el orden que debe seguir una secuencia de metadatos o en el número de veces que puede aparecer un metadato.

RESULTADOS: DISTRIBUCIÓN DE LOS METADATOS DESDE EL SERVICIO DE TELEDETECCIÓN 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. ID Campaña Marco de

ejecución Productos entregados (*) Propósito Volumen

datos Comentarios

ROSARITO ---- Imágenes nivel L1a Imágenes nivel L1c

Análisis biofísicos sobre láminas de agua

12 ficheros ----

DOÑANA Convenio INTA-IGME 2005

Imágenes nivel L1a Imágenes nivel L1b

Análisis cuantitativos y cartografía temática multitemporal sobre humedales

90 ficheros

Se han realizado 3 campañas similares de adquisición de datos en diferentes fechas (2004-2005)

SEN2FLEX Campaña SEN2FLEX (financiada por

Imágenes nivel L1a Imágenes nivel L1b

Análisis biofísicos estudio de la

126 ficheros Datos adquiridos en diferentes campañas, el proyecto cuenta con



ESA a través de la Univ. Valencia)

fluorescencia de la vegetación

múltiples usuarios

VITO

Contrato INTA-VITO para la adquisición de imágenes, Plan Hiperespectral Belgica 2005

Imágenes nivel L1a Imágenes nivel L1b ---- 162 ficheros

Múltiples usuarios y zonas test con propósitos de investigación diferentes

HYPERVAL

Proyecto de investigación financiado por el Plan Nacional de I+D (AGL-FOR2002 04017 C03 C1)

Imágenes nivel L1a Imágenes nivel L1b Imágenes nivel L1c

Análisis biofísicos sobre vegetación

42 ficheros Varias campañas de adquisición sobre diferentes zonas test

GUADA Convenio INTA-INIA 2005 ----

Estudios cuantitativos y cartografía temática sobre un área afectada por un incendio forestal

21 ficheros. Imágenes en proceso

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



El Núcleo Español de Metadatos, perfil mínimo de metadatos recomendados para España

Sánchez Maganto, Alejandra1 Rodríguez Pascual, Antonio Federico2

Abad Power, Paloma3 López Romero, Emilio4

IGN, Subdirección de Aplicaciones Geográficas (Madrid), [email protected], [email protected] 2 ,[email protected] 3,[email protected] 4

Resumen: Actualmente la Norma Internacional ISO19115 “Geographic Information-Metadata”, es la referencia obligada a la hora de crear metadatos de datos geográficos, pero esta norma es muy amplia, voluminosa y compleja en general. Por ello surge la necesidad de definir un perfil de metadatos,”El Núcleo Español de Metadatos (NEM v1.0)”, conjunto mínimo de items para la descripción de recursos, que posibilita la interoperabilidad entre todos los catálogos de metadatos que se generan en España. En este artículo se van a definir las principales características de este perfil, entendido como una recomendación consensuada y abierta que ha tenido en cuenta para su formación otras iniciativas y acciones relevantes en el campo de los metadatos y que ha sido definido dentro del marco del Consejo Superior Geográfico. NEM es un perfil de metadatos ya consolidado que es interesante dar a conocer a todos los implicados en las Infraestructuras de Datos Espaciales. 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.

Sesión 4 El Núcleo Español de Metadatos, per�l mínimo de metadatos...


ANTECEDENTES En la actualidad existen varias iniciativas en materia de metadatos que es conveniente enumerar:

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

• ISO 19115:2003 “Geographic Information-Metadata”: Norma internacional de metadatos, ya mencionada,

perteneciente a la familia de normas Internacionales ISO 19100 para la Información Geográfica desarrollada por el Comité Técnico 211 (Geomatic/Geographic Information) dentro de la Organización de Estandarización Internacional (ISO). Define 409 elementos, proporcionando un modelo y estableciendo un conjunto común de terminología, definiciones y procedimientos de aplicación para los metadatos. Ha sido adoptada como Norma Europea por CEN/TC287 y como Norma Española por AEN/CTN148.

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. DEFINICIÓN DEL NÚCLEO ESPAÑOL DE METADATOS 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.

El Núcleo Español de Metadatos, per�l mínimo de metadatos... Sesión 4


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. CREACIÓN DEL PERFIL 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.

Figura 1: Documento NEM v1.0



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:

• 22 elementos de la Norma Internacional ISO 19115 pertenecientes a su núcleo (Core): o 7 elementos que son obligatorios y que se recomienda como mínimo incluir estos campos. o 15 elementos que se dividen en opcionales y condicionales.

• 3 elementos que se encuentran en el estándar Dublín Core. • 3 elementos adicionales pertenecientes a la Norma ISO 19115 propuestos a partir de sugerencias recibidas por

personas relacionadas con el mundo de los metadatos y aprobados por el Subgrupo de Trabajo del NEM. • 2 elementos pertenecientes a la Norma ISO 19115 y propuestos para ser incluidos en el NEM por su utilización

en la Directiva Europea Marco del Agua (WFD). • Otros elementos adicionales pertenecientes a la Norma ISO 19115 y que se ocupan de profundizar en el tema

de la calidad.

Figura 2: Componentes de NEM DESCRIPCIÓN DE LOS ELEMENTOS DEL PERFIL Core de ISO 19115:2003 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:

Título del conjunto de datos (O)

( Md_Metadata>MD_Identification.citation>

CI_Citation.title)

Tipo de Representación Espacial (Op) (MD_Metadata>MD_DataIdentificatin.spatialRepresentation

Type)

Fecha de Referencia del Conjunto de Datos (O) Sistema de Referencia (Op)



(MD_Metadata>MD_Identification.citation>CI_Citation.date) (MD_Metadata>MD_ReferenceSystem)

Parte responsable del Conjunto de Datos (Op) (MD_Metadata>MD_Identification.pointOfContact>

CI_ResponsibleParty)

Linaje (Op)

(MD_Metadata>DQ_DataQuality.lineage>LI_Lineage)

Localización Geográfica del Conjunto de Datos (por 4 coordenadas o por identificador geográfico) (C)

(MD_Metadata>MD_DataIdentification.extent>EX_Extent>

EX_GeographicExtent>EX_GeographicBoundingBox or

EX_GeographicDescription)

Recurso en línea (Op) (MD_Metadata> MD_Distribution >

MD_DigitalTranferOption.online>

CI_OnlineResource)

Idioma del Conjunto de Datos (O) (MD_Metadata>MD_DataIdentification.language)

Identificador del Archivo de Metadatos(Op) (MD_Metadata.fielIdentifier)

Conjunto de Caracteres del Conjunto de Datos(C)

(MD_Metadata>MD_DataIdentification.CharacterSet)

Nombre de la Norma de Metadatos(Op)

(MD_Metadata.metadataStandardName)

Categoría del Tema del Conjunto de datos(O) (MD_Metadata>MD_DataIdentification.TopicCategory)

Versión de la Norma de Metadatos (Op) (MD_Metadata.metadataStandardVersion)

Resolución espacial del Conjunto de datos (Op) (MD_Metadata>MD_DataIdentification.spatialResolution>

MD_Resolution.equivalentScale o MD_Resolution.distance)

Idioma de los Metadatos (C ) (MD_Metadata.language)

Resumen Descriptivo del Conjunto de los datos (O) (MD_Metadata>MD_Identification.abstract)

Conjunto de Caracteres de los Metadatos ( C) (MD_Metadata.characterSet)

Formato de Distribución (Op) (MD_Metadata>MD_Distribution>MD_Format.name y

MD_Format.version)

Punto de contacto para los Metadatos (O) (MD_Metadata.contact>CI_ResponsibleParty)

Información adicional de la extensión del Conjunto de Datos (vertical y temporal) (Op)

(MD_Metadata>MD_DataIdentification.extent>EX_Extent>

EX_TemporalExtent o EX_VerticalExtent)

Fecha Creación de los Metadatos(O)

(MD_Metadata.dateStamp)

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.



• Tipo de Representación Espacial (SpatialRepresentaionType): Método usado para la representación espacial de la información geográfica.

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

• Nombre de la norma de metadatos (MetadataStandardName): Nombre de la Norma de metadatos usada.

• Versión de la norma de metadatos (MetadataStandardVersion): Versión de la Norma de metadatos usada.

• Formato de distribución (Format): Proporciona información sobre el formato usado para la distribución.

• Información adicional de la extensión del conjunto de Datos (vertical y temporal) (EX_TemporalExtent o

EX_VerticalExtent): Proporciona la componente vertical y temporal del conjunto de datos.

• Localización geográfica del conjunto de datos (EX_GeographicExtent): Proporciona el componente geográfico de la extensión espacial del recurso considerado.

• Conjunto de caracteres del conjunto de datos (CharacterSet): Nombre de la norma de codificación de caracteres para el conjunto de datos.

• Idioma de los metadatos (Language): Idioma usado para documentar los metadatos.

• Conjunto de caracteres de los metadatos (CharacterSet): Nombre de la norma de codificación de caracteres

para los metadatos. Dublin Core Metadata 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:

• Información de Agregación (AggregationInfo): este elemento se corresponde con el elemento RELATION (referencia a un recurso relacionado) de Dublin Core [CEN CWA 14856]. Proporciona información sobre las agregaciones definidas a partir del conjunto de datos que se está describiendo. Por ejemplo, al describir una hoja, aquí se haría una referencia a la serie en la que se agrega dicha hoja. (MD_Metadata.identificationInfo>MD_DataIdentification.aggregationInfo)

• Créditos (Credit): este elemento se corresponde con el elemento CONTRIBUTOR (reconocimiento de

aquellas personas que han contribuido de una manera u otra en la creación o modificaión de los datos, aportando: medios económicos, trabajo, soporte,etc) de Dublin Core [CEN CWA 14856].Establece el reconocimiento de aquellos que han contribuido al recurso. (MD_Metadata.identificationInfo>MD_DataIdentification.credit)

• Constricciones (ResourceConstraints): este elemento se corresponde con el elemento RIGHTS (información

sobre los derechos del y sobre el recurso) de Dublin Core [CEN CWA 14856].Aparece también en el borrador Core de CEN. Este elemento de ISO contiene dos atributos: accessConstraints y useConstraints. El atributo accessConstraints encaja perfectamente con el refinamiento de Dublin Core RIGHTS:ACCESSRIGHTS. Y el atributo UseConstraints ha sido propuesto como nuevo refinamiento de RIGHTS para el perfil espacial de Dublin Core [CEN CWA 14858]. ( MD_Metadata.identificationInfo>MD_DataIdentification.resourceConstraints)



Elementos Propuestos por el SGT NEM 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).

Elementos de la Directiva Marco del Agua 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:

• Propósito (Purpose): resumen del propósito por el que se creó el recurso.

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

Elementos Relativos a la Calidad 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: Se corresponde con el metadato linaje” MD_Metadata>DQ_DataQuality.lineage>LI_Lineage” perteneciente al Core de ISO19115. El perfil NEM define como metadatos para describir el linaje:

• 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:



o Exactitud en la Medida del Tiempo ( DQ_AccuracyOfATimeMeasurement): describe el grado de realidad en la escala del tiempo de los elementos existentes en la base de datos y sus relaciones temporales con respecto de las especificaciones del producto.

• Exactitud Temática (DQ_ThematicAccuracy): se corresponde con la exactitud de los atributos, se divide en: o Corrección de la Clasificación Temática (DQ_ThematicAccuracy): comparación de las clases

asignadas a los objetos o de sus atributos, con relación al valor que toman en el mundo real. o Exactitud de los Atributos No Cuantitativos (DQ_NonQuantitativeAttributeAccuracy): tasa de

error en los atributos no cuantitativos de los objetos. o Exactitud de los Atributos Cuantitativos (DQ_QuantitativeAttributeAccuracy): tasa de error en los

atributos cuantitativos de los objetos. HERRAMIENTA DE METADATOS PARA EL PERFIL NEM 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). Las características principales de esta herramienta son:

• 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/

• Es multiplataforma, de tal modo que permite trabajar en Windows o en Uníx

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

• Multilingüe: actualmente disponible en 5 idiomas: español, inglés, francés, polaco y checo.

• Uso de Tesauros para facilitar la edición de palabras clave, ejemplos de tesauros que se incluyen son: GEMET, AGROVAC, EUROVOS, UNESCO, ISO 3166,...

Figura 3:Diferentes ventanas de la herramienta CatMDEdit v3.6.1



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, Se define como un perfil de metadatos para España:

• Consolidado: aprobado por el Consejo Superior Geográfico. • Consensuado: resultado de un amplio consenso, a partir de opiniones, comentarios y aportaciones de un grupo

abierto de expertos en la materia pertenecientes a diferentes organizaciones e instituciones en el ámbito nacional, autonómico y local.

• Estable : no va a ir incorporando nuevos ítems conforme vayan surgiendo iniciativas en el mundo de los metadatos, sino que se mantendrá razonablemente invariable.

• No restrictivo: no pretende que se implemente directamente tal y como se define, sino que cada organismo o institución en función de sus necesidades y la finalidad que persiga, establezca los metadatos que necesita y se recomienda que se incluya al menos los items definidos por NEM.

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 1. Documento del Núcleo Español de Metadatos. http://www.idee.es/ 2. [DCMI] Dublin Core Metadata Initiative. http://dublincore.org/ 3. [ISO 2003] Norma “ISO 19115:2003. Geographic information - Metadata”. International Organization for Standardization (ISO), 2003. 4. [CSG 2003] “SGT3_2003_05v2: Documento de Metadatos”. Infraestructura de Datos Espaciales Española, Consejo Superior Geográfico (Ministerio de Fomento). 5. Infraestructura de Datos Espaciales de Navarra (IDENA). http://idena.navarra.es/busquedas/



Editor de Metadatos NEM V 1.0 para ArcGIS

Sanchidrian Cano, Noemi Calle González, José Vicente1

Esri España Geosistemas (España) , [email protected]

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. EDITOR DE METADATOS DEL NEM V 1.0 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. El editor de Metadatos del NEM tiene las siguientes características:

• Integrado en una herramienta GIS, como ArcCatalog que permite la carga automática de una serie de campos y la sincronización automática en la edición del dato.

• Abierto y configurable sobre la base del fichero de configuración, XML para permitir la modificación por parte de los usuarios.

• Se podrán definir campos y secciones obligatorios. • Validación del Metadato que cumpla con campos obligatorios y tiene valores validos. • Se puede repetir las secciones definidas como 1..N, para permitir repetidos ciertos nodos, como por ejemplo

las keywords. • La interfaz de las pantallas se generará automáticamente en función de meta entradas dentro del fichero de

configuración que permitirá agrupar campos y mostrar mensajes aclaratorios. Ciertos tipos de datos como por ejemplo las fechas generarán automáticamente combos para introducir día, mes y año, etc.

• Valores por defecto, en base a fichero xml con la estructura NEM v1.0 con los valores que se quieren que aparezcan inicialmente.

• Posibilidad de guardar y recuperar datos de contactos. Cuando se tenga que rellenar información de un contacto, se dispondrán de las opciones:

o “Guardar Contacto”: Una vez rellenada completa o parcialmente la información de un contacto, se podrá guardar, asignando un nombre dicha información para poder reutilizarla en otro momento.

o “Recuperar Contacto”: Rellenará la información del contacto en base al contacto seleccionado de entre los guardados.

Editor de Metadatos en la interfaz de ArcCatalog 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.

Editor de Metadatos NEM V 1.0 para ArcGIS Sesión 4


Figura 1 : Editor de Metadatos

Configuración del Editor de metadatos Para permitir una fácil configuración del editor de metadatos, las secciones y el contenido de las secciones estará definido en ficheros de configuración. Dichos ficheros definirán Categoría, Secciones, campos y tipos o clasificaciones.

• Cada categoría definirá una serie de secciones. • Cada sección contendrá una serie de campos (indicando si contienen datos obligatorios) • Una sección se puede definir como de tipo 1..N, con lo que se podrán crear varias instancias del mismo tipo de

sección. • Cada campo se indicará si es obligatorio o no, y el tipo de datos, para los tipos enumerados, se hará referencia

a clasificaciones definidas en el fichero de configuración. Visualización de los metadatos ISO 19115 Se podrá elegir en ArcCatalog ver los metadatos según el formato ISO 19115, para ello se ha implementado un XSL específico.

Exportación de Metadatos La exportación de Metadatos consiste en exportar el contenido del nodo iso19115.

Sesión 4 Editor de Metadatos NEM V 1.0 para ArcGIS


Figura 2: Exportador de Metadatos

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.

Figura 3: Importador de Metadatos

Editor de Metadatos NEM V 1.0 para ArcGIS Sesión 4


SESIÓN 5

SERVICIOS WEB I

137

Arqueología y Servidores de Mapas en Red. Proyecto LIFE “Valle de Tiermes – Caracena”

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.

[email protected]; [email protected]; [email protected]

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.

Figura 1. Ubicación geográfica de la Comarca de Tíermes – Caracena

El Turismo como activador de la economía

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

Arqueología y Servidores de Mapas en Red. Proyecto LIFE �Valle de... Sesión 5


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]

1. GEOSERVICIOS OGC COMO GESTORES DE LA INFORMACIÓN

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.

Sesión 5 Arqueología y Servidores de Mapas en Red. Proyecto LIFE �Valle de...


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. 2. PRESENTACIÓN DE LOS DATOS EN BRUTO 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

3. METODOLOGIA PARA EL TRATAMIENTO DE LOS DATOS PARA CONSEGUIR SU INTEROPERABILIDAD

La primera barrera encontrada, como se mencionó anteriormente, es la de disponer de información no interoperable. La falta de interoperablidad queda patente al intentar visualizar de forma conjunta los datos procedentes del entorno de diseño gráfico FreeHand con la información alfanumérica almacenada en la base de datos MS-Access. Por el momento la única posibilidad de interoperar o trabajar conjuntamente con estas dos fuentes de información, es a través de la búsqueda visual del número de unidad estratigráfica en un dibujo de planimetría y, posteriormente, consultar la base de datos por la unidad estratigráfica deseada. Esta acción carece totalmente de un “vínculo automático” entre ambos tipos de información. Para superar la falta de interoperabilidad y la carencia del “vínculo automático” se desarrolló la siguiente metodología:



3.A.- DE FREEHAND A SHAPEFILE 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 campaña julio-diciembre de 2004

Figura 7: Fotografía del Yacimiento

Previo a la georreferenciación es necesario realizar los siguientes pasos: 3.A.2.- Homogeneización de capas en FreeHand: Cada archivo de planimetría identifica distintos tipos de materiales de los muros según el color que le es asignado (ejemplo: caliza, toba, arenisca, mortero, etc.). En los archivos originales estos rellenos se encuentran todos en una única capa. Se debe crear una capa de información para cada tipo de roca y cada atributo (cotas y unidades estratigráficas) (Figura 8). Para que al exportar el archivo como Shp [25], se adjudique como atributo el nombre de la capa a la que pertenece. 3.A.3.- De FreeHand a CorelDraw: En FreeHand se ha exportado la información en el formato de intercambio Adobe Illustrator 5.x (*.ai). Desde Corel Draw se lee y exporta en formato de intercambio para CAD DXF. Los nombres de las capas se mantienen a lo largo del proceso. En este punto la información está en condiciones de ser georreferenciada: 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.

Figura 8. Las capas resultante en el archivo de planimetrías.



Figura 9. Correspondencia entre dos puntos de Planimetría con dos puntos de la estructura del plano topográfico.

3.A.5.- Conversión a ShapeFile: Utilizando el programa “FME Universal Translator” [26] se transforma el archivo DXF en shp (Figura 10), generando un archivo para cada tipo de geometría: puntos, líneas y polígonos. Las capas de información del archivo original se convierten en atributos de los polígonos, líneas o puntos según correspondan. Así el tipo de rellenos se incluye como atributo de los polígonos y los textos de unidades estratigráficas y cotas de los dibujos en FreeHand como atributos de la capa de puntos.

3.A.6- Unión de todos los archivos ShapeFile individuales: Por último se genera un archivo ShapeFile con la unión de todos los dibujos de planimetría fragmentados a los que se les ha aplicado el proceso anterior (Figura 11). Este paso puede realizarse sin problemas con los archivos DXF georreferenciados, y realizando posteriormente la conversión a shp del archivo resultante de la unión. El proceso de transformación de los archivos de planimetría de FreeHand a shapefile es laborioso en edición y se ha de tener un especial cuidado en cada una de sus fases. Este trabajo debió ser realizado por una persona con conocimientos en el yacimiento arqueológico de Tiermes para poder ubicar cada planimetría en el sitio correspondiente. El tiempo del proceso de cada dibujo se estima en 20 minutos. Esta metodología para situar archivos de diseño gráfico en un servidor de mapas puede extrapolarse a otros ámbitos, además de arqueología, donde es frecuente el uso de ese tipo de software para mejorar la visualización de la cartografía.

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.

Figura 10. Interfaz de FME Universal Translator.

Figura 11. Visualización de la unión de varios archivos.



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 FreeHand

Figura 13. Visualización obtenida en el Cliente WMS. http://mapas.topografia.upm.es/tiermes

Figura 14. Visualización obtenida en el Cliente WMS de Figura 11

3.B.- VINCULACIÓN DE LA BASE DE DATOS ACCESS CON LA PLANIMETRIA.

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



Figura 15. Atributos del archivo shp de puntos de planimetrías

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.

3.B.4.- Inserción de la Capa Unidades Estratigráficas en el Servidor de Mapas: visualización y consulta

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

Figura 16. Consulta de Información de Unidades Estratigráficas en Cliente WMS.



4. Información Geográfica Básica de la Comarca de Tiermes-Caracena 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 la comarca de Tiermes-Caracena.

Figura 18. Visualización conjunta de las capas Ortofoto y Catastro de una región del municipio de Retortillo de Soria.

El punto de acceso del Servidor de Mapas es: http://mapas.topografia.upm.es/cgi-bin/tiermes? 5- CONCLUSIONES

• Se ha desarrollado una metodología para transformar archivos de diseño gráfico no georreferenciados a

shapefile georreferenciados, cuya aplicación no se limita tan solo a arqueología, sino que abarca también a otros ámbitos.

• Se ha alcanzado la interoperabilidad entre dos tipos de información, que por sus formatos y por la carencia de referencia espacial (en el caso de la planimetría) y de geometría (en el caso de la base de dato de Unidades Estratigráficas) no era posible de realizar con anterioridad.

• La información resultante se encuentra georreferenciada, es interoperable, navegable y consultable, a partir de la interfaz de Web Map Server y podría ser mantenida y actualizada con un WFS Transaccional.

• Puede lograrse el mismo estilo de visualización, sin pérdida de información en un Servidor de Mapas en Red. • Se converge con la iniciativa INSPIRE de la Unión Europea. • Las posibilidades de visualización pueden extenderse aún más con la utilización de la especificación de Diseño

de Estilos de Visualización por Capas del OGC (SLD). • Como futuro trabajo identificado se plantea una nueva metodología para la próxima campaña arqueológica

para que el gran volumen de información generada pueda ser incluido directamente en el Servidor de Mapas.

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/



DISEÑO DE UNA HERRAMIENTA BASADA EN LA GENERACIÓN INTERACTIVA DE ESTILOS PARA LA VISUALIZACIÓN DE CAPAS A TRAVÉS DE UN WMS

Maldonado Ibáñez, Ana (MS) 1 Moya Honduvilla, Javier (BS) 2

Manso Callejo, Miguel Ángel (MS) 3 Grupo de Investigación Mercator (Universidad Politécnica de Madrid),

[email protected] 1, [email protected] 2, [email protected] 3

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.

Diseño de una herramienta basada en la generación interactiva de estilos... Sesión 5


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. JUSTIFICACIÓN DEL DESARROLLO DE LA HERRAMIENTA 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. El esquema del estudio es el siguiente: Vamos a desglosar este esquema: 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

Conseguir mapas acorde a las necesidades del usuario a

partir de WMS: Obtención de Cartografía Temática a través

de un servidor

Especificación OGC Styled Layer

Descriptor (SLD)

SOLUCIÓN Desarrollo de una nueva herramienta de gestión de estilos mediante un WMS

DESENLACE2 3 OBJETIVO

1

Sesión 5 Diseño de una herramienta basada en la generación interactiva de estilos...


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. Este objetivo se conseguirá adecuando la petición de un mapa a un servidor: Cuando un usuario solicita un mapa a un WMS (Petición GetMap) introduciendo en la petición los parámetros básicos se obtiene un mapa que se ajusta a estos parámetros:

• 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:

<STYLEDLAYERDESCRIPTOR> <NAMEDLAYER> <NAME> Layer1</NAME> <USERSTYLE> . . . . . . . . . </USERSTYLE> </NAMEDLAYER> <NAMEDLAYER> <NAME> Layer2</NAME> <USERSTYLE> . . . . . . . . . </USERSTYLE> </NAMEDLAYER> </STYLEDLAYERDESCRIPTOR>

Definición de estilo para la capa Layer2

Definición de estilo para la capa Layer1

DocumentoSLD.sld



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.

• El tiempo de preparar y realizar la petición se incrementa enormemente, sobretodo cuando la petición y

devolución de un mapa por un WMS es casi instantánea.

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. La siguiente figura ilustra esta transformación de la petición GetMap:

Sample: DEFAULT style

Sample: DEFINED style (without filter)

Sample: DEFINED style (with filter)

Petición con Estilo por Defecto Petición con Estilo Personalizado

Documento SLD

Recodificaciónde Caracteres

http://mapas.euitto.upm.es/cgi-bin/madrid?SERVICE=WMS&Version=1.1.1&Request=GetMap&LAYERS=roads

http://mapas.euitto.upm.es/cgi-bin/madrid?SERVICE=WMS&Version=1.1.1&Request=GetMap&LAYERS=roadsSLD_BODY=%3CStyledLayerDescriptor%3E

%3C%2FStyledLayerDescriptor%3E.................

<StyledLayerDescriptor> </StyledLayerDescriptor>

.................

SLD_BODY=%3CStyledLayerDescriptor%3E

%3C%2FStyledLayerDescriptor%3E.................

1º

+

2º

3º



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:

USUARIO

SECTOR

APLICACIÓN WMS WFS

Inicia Aplicación

Leyenda de EsquemaGuardar Estilo

Recuperar Estilo

Añade Servidor WMS

Aceptar estilo y Aplicar

Acción

Muestra Capas

Presenta Imagen

Seleccionar capaEditar estilo con Filtro

UI de recuperaciónde Estilo

UI de Exploración yNombre de Archivo

Seleccionar capaEditar estilo

Geometría +Estilo por defecto

UI de Estilo concreto

Calcula valores MAX/MIN

UI de Estilo con Filtro

GetCapabilities

GetMap

Petición

Atributos

Respuesta

GetStyle

DescribeFeatureType

*

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

Para esto se hacen necesarios dos requerimientos:

• 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. FUTURAS LÍNEAS DE INVESTIGACIÓN 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. Otra posible línea de trabajo/investigación a desarrollar consistiría en el perfeccionamiento de la herramienta de modo que se mejoren los filtros y se puedan incluir técnicas de análisis SIG útiles para varios proyectos: Planificación del territorio, realización de mapas de riesgos…



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



Servicio web 3D parametrizable mediante un lenguaje de definición de escenas virtuales

Montoiro Cabada, Francisco Gabriel1

Varela Pet, José2

Viqueira Ríos, José Ramón3

Arias Rodríguez, Juan Enrique4

Xunta de Galicia, [email protected] Universidad de Santiago de Compostela, [email protected], [email protected], [email protected]

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). La creación y visualización de representaciones tridimensionales de la información geográfica se está revelando como una potente herramienta en diversos ámbitos de actuación. Diversos trabajos están identificando múltiples campos de aplicación, actuales o futuros, de sistemas SIG 3D interoperables (Altmaier y Kolbe, 2003; Held et al, 2004). Tal es el caso de la planificación urbanística y territorial, gestión de desastres naturales, turismo, sistemas de navegación y aplicaciones militares. Asimismo, nuevas directivas europeas en el ámbito de la gestión medioambiental están abriendo las puertas a la introducción de esta tecnología. La directiva 2002/49/CE sobre evaluación y gestión del ruido ambiental obligará a las administraciones a la publicación de mapas de ruidos. Estos mapas se elaboran a partir de la simulación de la propagación del sonido procedente de diversas fuentes de ruido en un espacio tridimensional. Para la construcción de estos escenarios tridimensionales será necesario acceder a diferentes fuentes de datos espaciales 3D, o datos bidimensionales susceptibles de ser presentados en un espacio 3D. En este último caso será preciso definir las operaciones o mecanismos necesarios para establecer dicha conversión. Por otro lado, desde el punto de vista de la estandarización de formatos y servicios, existen en el mercado diversas aplicaciones y sistemas SIG 3D (Nebiker, 2003) que, aunque permiten alcanzar cierto nivel de compatibilidad a través de formatos estándar para la representación de escenarios tridimensionales, no existe una formalización estándar de funcionalidades e interfaces que faciliten la interoperabilidad. 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.

Servicio web 3D parametrizable mediante un lenguaje de de�nición de... Sesión 5


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. El Open Geoespatial Consortium (OGC) 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. Servicios web OGC 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

Sesión 5 Servicio web 3D parametrizable mediante un lenguaje de de�nición de...


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. Servicios web de visualización 3D 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)



3. ARQUITECTURA DE UN SERVICIO WEB-GIS 3D 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.

Figura 2: Modelo de visualización (OGC, 2003)

Figura 3: Balanceo de funcionalidades cliente-servidor (OGC-W3DS) 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. 4. WEB 3D SCENE SERVICE 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.

Figura 4: Integración del W3DSS en un entorno distribuido Fuentes de datos espaciales 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.

Figura 5: Parámetros de localización y orientación de la cámara (OWS-W3DS, 2005)



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. 5. SLD3D: UN LENGUAJE PARA LA DEFINICIÓN DE ESCENAS VIRTUALES 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. Formato y estructura de los documentos SLD3D 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.  <StyledLayerDescriptor>  <SceneBackground> <BackgroundColor>0.3 0.3 0.6</BackgroundColor> </SceneBackground>  <SceneLighting> <AmbientLight> <AmbientColor>0.5 0.5 0.5</AmbientColor> </AmbientLight> <PointLight> <DiffuseColor>1.0 1.0 0.0</DiffuseColor> <Location>0.0 1000.0 0.0</Location> </PointLight> </SceneLighting>  <SceneCamera> <Location>508154 4671000 1000</Location> <Yaw>0.0</Yaw> <Pitch>30.0</Pitch> </SceneCamera> <SceneCamera> <Location>509434 4673560 300</Location> <Yaw>-90.0</Yaw> <Pitch>10.0</Pitch> </SceneCamera>  <UserLayer>  <RemoteOWS> <Service>WCS</Service> <OnlineResource href="http://gispc12.labsis.usc.es/cgi-bin/mapserv?map=wcs2.map"/> </RemoteOWS>  <LayerFeatureConstraints> <FeatureTypeName>mdt_5_cies</FeatureTypeName> </LayerFeatureConstraints>  <UserStyle> <FeatureTypeStyle> <Rule>  <S3DElevationGridSymbolizer> <SourceChannel>1</SourceChannel> <ElevationOffset>0.0</ElevationOffset> <ScaleFactor>1.0 1.0 1.0</ScaleFactor> <Resolution>20.0 20.0</Resolution>  <Material>  <MaterialColor>1.0 1.0 1.0</MaterialColor>  <ImageTexture> <OnlineResource href="http://mapas.topografia.upm.es/cgi-bin/mapserv.exe?map=e:\map s\cnauticas\cnauticas_web.map&request=GetMap&layers=nivel5&version=1.1.1&format=image/jpeg&EPSG:4326&bbox=-8.9221602,42.1818398,-8.88478548,42.25658924&width=1024&height=2048"/> <SamplingFactor>1.0 1.0 0.0</SamplingFactor> <Format>image/tiff</Format> </ImageTexture> </Material> </S3DElevationGridSymbolizer> </Rule> </FeatureTypeStyle> </UserStyle> </UserLayer> </StyledLayerDescriptor>

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



APLICABILIDAD DEL MODELO DE NOMENCLÁTOR DE ESPAÑA AL NOMENCLÁTOR CONCISO

Abad Power, Paloma1 Rodríguez Pascual, Antonio2

López Romero, Emilio3 Sánchez Maganto, Alejandra4

Instituto Geográfico Nacional (España). [email protected], [email protected] 2, [email protected], [email protected] 4

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. MODELO DE NOMENCLÁTOR DE ESPAÑA 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.

Un Nomenclátor se considera pues un conjunto de datos que permite:

- El establecimiento de un Sistema de Referencia basado en Identificadores Geográficos, según la norma ISO19112.

- La implementación de servicios de Nomenclátor (Gazetteer), Geoparser y Geocoder, tal y como los define Open Geospatial Consortium.

- La definición de un Nomenclátor Oficial, mediante la oportuna normalización y definición de todo o parte de su contenido como tal.

- La puesta a disposición de los usuarios de un Nomenclátor como producto, como conjunto de datos físico que se facilita en un formato determinado, en una gama de soportes y ocasionalmente con una aplicación de consulta y gestión.

Aplicabilidad del modelo de nomenclátor de España al nomenclátor... Sesión 5


2

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

Elementos del Modelo de Nomenclátor de España 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.

Figura 1: MNE Elementos Obligatorios

1. IdEntidad: Identificador de la entidad 2. NombreEntidad

- Nombre: Nombre de la Entidad - Idioma: Lengua de la entidad (lista controlada ISO639_2) - ClaseNombre: Si el nombre es preferente, variante, histórico, ect. (lista controlada) - Oficial: Si el nombre de la entidad es oficil o no - Identifier: Identificador de la fuente de donde el nombre geográfico es obtenido

Sesión 5 Aplicabilidad del modelo de nomenclátor de España al nomenclátor...


3

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.

Calidad del Nomenclátor:

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. En consecuencia, la calidad de la información recogida en un Nomenclátor debe determinarse de manera objetiva y aplicando métodos estadísticos para la determinación de una serie de parámetros de calidad: selección de una muestra representativa de los datos contenidos en el Nomenclátor y comparación con otro conjunto de datos considerado más fiable o con datos obtenidos del mundo real en un trabajo de campo. 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



4

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.

Figura 2 Cliente del Servicio de Nomenclátor del portal IDEE

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.

APLICABILIDAD AL NOMENCLÁTOR CONCISO 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. Los campos de los que consta el Nomenclátor Conciso son: • Nombre: es el nombre de cada elemento geográfico. • Variante: son las variantes o alónimos de los nombres geográficos que tengan otra denominación. Incluye entre

paréntesis la lengua cuando es diferente del nombre principal. • Antes: Son las denominaciones oficiales anteriores y no vigentes en la actualidad. • Clase y Entidad: Se refieren a lo que el MNE denomina Tipo de la entidad, en función de una Tabla de clasificación

de entidades geográficas. • Latitud, Longitud: Localización de los topónimos mediante coordenadas geográficas. • CCAA, Provincia: Nombre oficial de la CCAA y de la provincia donde se encuentra cada topónimo en función de

las coordenadas geográficas introducidas. • Mapa: El número de la hoja del Mapa Topográfico Nacional a escala 1:50.000 del IGN, donde se encuentra cada

elemento geográfico según las coordenadas introducidas. • Fuente del nombre geográfico • Notas: Campo para introducir notas aclaratorias



5

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_Entidad

PK IdEntidad

NivelObservacionesNombreDireccionLocalidadCodigoPostal

T_NombreEntidad

PK NombrePK,FK2 IdiomaPK,FK1 IdEntidad

EtimologíaPronunciacion

FK3 ClaseNombreOficialNormalizadoIdentifier

T_Idioma

PK Idioma

TipoIdioma

T_ClaseNombre

PK ClaseNombre

T_TipoEntidad

PK IdTipoEntidad

TipoCatalogoEntidades

T_Entidad_TipoEntidad

PK,FK1 IdEntidadPK,FK2 IdTipoEntidad

T_Codigo

PK CodigoPK,FK1 IdEntidad

SistemaCodificacion

T_EntidadLocal

PK IdEntidadLocal

FK1 ProvinciaFK2 Municipio

IslaComarca

FK3 EATIM

T_Entidad_EntidadLocal

PK,FK2 IdEntidadPK,FK1 IdEntidadLocal

T_Provincia

PK Codigo

Nombre

T_Municipio

PK Codigo

Municipio

T_EATIM

PK IdEATIM

TipoEATIMNombreEATIM

T_Entidad_Mapa

PK,FK2 IdEntidadPK,FK1 SeriePK,FK1 Hoja

T_Mapa

PK SeriePK Hoja

T_EntidadRelacionada

PK,FK1 IdEntidad1PK TipoRelacionPK IdEntidad2

DescripcionRelacion

T_Atributo

PK TipoAtributoPK ValorAtributoPK,FK1 IdEntidad

UnidadAtributoCalidadAtributoNotaAtributoFechaAtributo

T_Evento

PK TipoEventoPK FechaPK,FK1 IdEntidad

Descripcion

T_CodIdioma1

PK CodIdioma

T_CodIdioma2

PK CodIdioma

T_ClaseNombre

PK ClaseNombre

T_TipoEvento

PK TipoEvento

T_TipoRelacion

PK TipoRelacion

T_TipoGeometria

PK TipoGeometria

T_PosicionEspacial

PK TipoGeometriaPK SistemaReferenciaPK,FK1 IdEntidad

Geometria

Figura 3 Modelo de datos para el MNE

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:

Figura 4 Modelo de datos del MNE para el Nomenclátor Conciso



6

Los cambios más significativos son los siguientes: • IdEntidad: Será un código interno en la BD • NombreEntidad

Nombre, Idioma, ClaseNombre, Oficial e Identifier Normalizado (campo optativo que se incluye)

• TipoEntidad Tipo: se considera que una entidad solo puede tener dos tipos diferentes de entidad (tipoentidad1 y tipoentidad2) CatálogoEntidades va a ser único para todo el modelo

• PosicionEspacial Geometría (punto) y SistemaReferencia (ED50-UTM) van a ser únicos para todo el modelo mientras que las Coordenadas van a ser solo un par (posicionX y posicionY).

• EntidadLocal Provincia o provincias donde se encuentre la entidad mediante su código y se incluye el campo opcional Municipio también mediante su código INE.

• EntidadRelacionada (Campo opcional) IdEntidad se refiere al identificador de la entidad con la que se va a relacionar la entidad actual DescripciónRelación describe la relación que exite entre ambas entidades TipoRelación pudiéndo ser jerárquica o lógica

• Mapa (Campo opcional) Hoja y Serie en donde se encuentre le entidad

• Evento (Campo opcional) ÜltimaActualización y FechaultimaActualización para que quede constancia solamente de las actualizaciones de los nombres de las entidades.

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 1. Alexandria Digital Library Gazetteer Content Standard (CGS v 3.2) http://www.alexandria.ucsb.edu 2. ISO19112:2003 “Geographic Information- Spatial referencing by Geographic Identifiers” 3. Open Geospatial Consortium “Gazetteer Service Profile of the Web Feature Service Implementation Specification

0.0.9” http://www.opengeospatial.org 4. Metadata Dublín Core, (ISO15836:2003 ) http://dublincore.org/



SESIÓN 6

IDES REGIONAL, NACIONAL, TRANSNACIONAL

173

Sistema para la Gestión y Divulgación de Información Cartográfica del Instituto Cartográfico Valenciano. Proyecto cart@.

Felipe García, Beatriz

Instituto Cartográfico Valenciano, [email protected]

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.

Sistema para la Gestión y Divulgación de Información Cartográ�ca del... Sesión 6


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.

Sesión 6 Sistema para la Gestión y Divulgación de Información Cartográ�ca del...


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. Se ofrecerá información acerca del tipo de mantenimiento, incorporando la frecuencia de actualización. 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.



Figura 1: Evolución temporal de la serie ODCV05.

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. Herramienta de gestión de metadatos Manifiestas estas puntualizaciones, la generación automatizada de metadatos pasará por diseñar una herramienta que permita definir las siguientes operaciones:

• La generación y manipulación de conjuntos de datos basándose fundamentalmente en la herencia de propiedades, por la que un objeto cualquiera por el hecho de pertener a un determinado conjunto de datos ya posea esas propiedades.

• Captura masiva de metadatos a partir de: • La información cartográfica original, parte de la información necesaria en la generación de metadatos

puede ser extraida a partir de los ficheros originales de la información cartográfica • Bases de datos confeccionadas previamente al margen de la herramienta. • Metadatos generados con otras herramientas de creación de metadatos.

• Posibilitar la modificación, a cualquier nivel jerárquico, de la información incorporada, para permitir una eficiente actualización.

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.



Incorporación de la información a un servidor de cartografía 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.

Figura 2: Capa continua de la serie ODCV05 en la actualidad 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.

Figura 3: Herramientas básicas de navegación, información y medición.



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.

Figura 4: Herramientas de búsquedas alfanuméricas sencillas.

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.

Figura 4: Herramientas de recorte.

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.

Figura 5: Interfaz de búsqueda 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.



Figura 6: Opciones de compra

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.



La Infraestructura de Datos Espaciales de Galicia (I.D.E.G.)

Gallego Priego, Manuel Arias López, Alba

Cuñarro Taboada, Celso Docampo Bello, Carmen

Fanego Rioboo, Francisco González Bernárdez, Gonzalo

Román Díaz, Berta Serantes Durán, Inmaculada Suárez Barreiro, José Ramón Vega Fernández, José Antonio

Sistema de Información Territorial de Galicia (S.I.T.G.A). Sociedade Anónima para o Desenvolvemento Comarcal de Galicia. Xunta de Galicia

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 SITUACIÓN DE LA INFORMACIÓN GEOGRÁFICA EN GALICIA. 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

Sesión 6 La Infraestructura de Datos Espaciales de Galicia (I.D.E.G.)


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: Entre las principales funcionalidades que presenta este geoportal destacan:

• Visualización de mapas, fotografías aéreas o imágenes de Galicia • Búsqueda y localización de topónimos y elementos sobre un mapa • Elaboración de mapas temáticos sobre usos del suelo, geología, hidrografía, vías de comunicación, etc. • Medición de superficies, perímetros y longitudes sobre los mapas • Consulta de datos socioeconómicos • Impresión de mapas, fotografías e imágenes de satélite • Descarga de información territorial

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.

La Infraestructura de Datos Espaciales de Galicia (I.D.E.G.) Sesión 6


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

Cartografía temática (Datos socioeconómicos) 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 Geoportal IDEG 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/wmsgalicia/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/wfsgalicia/request.asp

Cartografía publicada Navegación sobre la cartografía turística de las comarcas de Galicia elaborada en el SITGA.

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.



Evolución del portal de la Infraestructura de Datos Espaciales de España y el Nodo IGN

López Romero, Emilio1

Rodríguez Pascual, Antonio Federico2 Abad Power, Paloma3

Sánchez Maganto, Alejandra4 IGN, Subdirección de Aplicaciones Geográficas (Madrid),

[email protected] 1, [email protected] 2, [email protected] 3, [email protected] 4 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. Recientemente se ha avanzado en la implementación de algunas utilidades de análisis y explotación de los datos, línea de trabajo que supondrá en el futuro una alternativa al entorno de explotación de la IG con aplicaciones pesadas en local, mediante el acceso a servicios de análisis interoperables desde clientes ligeros. 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. El Consejo Superior Geográfico, a través de su secretaría (responsabilidad atribuida al Instituto Geográfico Nacional), puso en marcha el proyecto para el desarrollo y creación del Geoportal de la Infraestructura de Datos Espaciales, abriéndolo a Internet en Junio de 2004. Desde entonces, el geoportal IDEE ha sufrido importantes reestructuraciones y ha avanzado en su objetivo de erigirse como un punto de acceso esencial para el descubrimiento, localización, acceso y utilización de los datos y servicios de información geográfica disponible sobre el territorio español. CARACTERÍSTICAS PRINCIPALES DEL GEOPORTAL IDEE 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.

Sesión 6 Evolución del portal de la Infraestructura de Datos Espaciales de...


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. NUEVA IMAGEN DEL GEOPORTAL IDEE 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:

Figura 1.- Antigua imagen del Geoportal de la IDEE

Evolución del portal de la Infraestructura de Datos Espaciales de... Sesión 6


Figura 2.- Nueva imagen del Geoportal de la IDEE

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 NUEVA ESTRUCTURA DEL GEOPORTAL IDEE 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 METADATOS DE CAPAS DE LOS PRODUCTOS DEL IGN 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. En consecuencia, resulta interesante y práctico el considerar la división jerárquica de un producto o serie cartográfica en las hojas o unidades que la componen y al mismo tiempo considerar la división del producto en capas temáticas. 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. SERVICIOS WEB DE ENTIDADES DEL NODO IGN 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. Los servicios web de entidades accesibles son:

- Servicio Web de Entidades de Vértices Geodésicos - Servicio Web de Entidades de Líneas Límites - Servicio Web de Entidades de CORINE LAND COVER - Servicio Web de Entidades de Base Cartográfica Numérica 1:1.000.000

APLICACIÓN CLIENTE PARA EL SERVICIO WEB DE ENTIDADES DE CORINE LAND COVER 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.

En la siguiente imagen se puede apreciar el aspecto del nuevo cliente:

Figura 3.- Cliente para el WFS del CORINE LAND COVER 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.

6. Newcomer, Eric “Understanding web services” Addison Wesley, 2004.

7. Barry, Douglas K. “Web services and service-oriented architectures” Morgan Kaufmann, 2003.

8. FDIS19115:2003 “Geographic Information – Metadata”

9. FDIS19112:2003 “Geographic Information – Geographic Identifiers”

10. ISO15836:2003 “Information and Documentation. The Dublin Core metadata elements set”



SDIGER: Experiences and identification of problems on the creation of a transnational SDI

J. Nogueras-Iso, M.Á. Latre, R. Béjar, P.R. Muro-Medrano F.J. Zarazaga-Soria,

Depto. de Informática e Ingeniería de Sistemas Universidad de Zaragoza (España)

[email protected], [email protected], [email protected], [email protected], [email protected]

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.

Sesión 6 SDIGER: Experiences and identi�cation of problems on the creation of...


ACTIVITIES OF THE PROJECT 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. Definition of a cross-border scenario 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).

TH E M A TIC D A TA < <E U R O P E> >

D G -E N V JR C W FD

< < FR AN C E, SP AIN > >

S D IG E R<< SP AIN > >

E N V IR O N M E N TM IN IS T R Y

R E F ER E N C E D A TA

IN S P IR E U S E C AS E S

P UB LIC A CC ES S

INFO

P UB LIC A CC ES S

INFO

<< A D O U R -G A R O N N E R B D > >

L ’A gencede l’eau

P UB LIC AC C ES S

IN FO

<< A D O U R -G A R O N N E R B D > >

L ’A gencede l’eau

P UB LIC AC C ES S

IN FO

P UB LIC AC C ES S

IN FO

< <F R A N C E >>


PU BLIC A C CE SS

IN FO

< <F R A N C E >>


PU BLIC A C CE SS

IN FO

PU BL IC A C CE SS

IN FO

< <E BR O R B D >>

C H EP UB LIC

A CC ES SINFO

< <E BR O R B D >>

C H EP UB LIC

A CC ES SINFO

P UB LIC A CC ES S

INFO

< <F R A N C E >>

IG N -FR A N C EP UB LIC

A CC ES SINFO

<< SP A IN > >

IG N -S P A INPU BLIC

AC CE SSIN FO

< <F R A N C E >>


A CC ES SINFO

< <F R A N C E >>


A CC ES SINFO

P UB LIC A CC ES S

INFO

<< SP A IN > >


AC CE SSIN FO

<< SP A IN > >


AC CE SSIN FO

PU BL IC AC CE SS

IN FO

<< E U R O PE >>

E urostat-G IS C O JR C IN S P IR E

PU BLIC AC CE SS

IN FO

<< E U R O PE >>

E urostat-G IS C O JR C IN S P IR E

PU BLIC AC CE SS

IN FO

PU BL IC AC CE SS

IN FO

SW 4b : E co. s ta tus

SW 4c : E co. pote ntia l

SW 4d : S ynth . po ll.

SW 4e : C hem . s ta tus

S u rfac e W B G ro u n dW B P rote c te d A rea s

SW 4b : E co. s ta tusSW 4b : E co. s ta tus

SW 4c : E co. pote ntia lSW 4c : E co. pote ntia l

SW 4d : S ynth . po ll.SW 4d : S ynth . po ll.

SW 4e : C hem . s ta tusSW 4e : C hem . s ta tus

S u rfac e W B G ro u n dW B P rote c te d A rea sS u rfac e W B G ro u n dW B P rote c te d A rea s

R efe renc eThem aticPres s ures•P oin t s ou rce po ll.•D iffu se s ourc e pol l.•W ate r abs trac tions•M orpho . a lte rat ions

Ex pert

Back ground

R e fe renc eR e fe renc eThem aticThem aticPres s ures•P oin t s ou rce po ll.•D iffu se s ourc e pol l.•W ate r abs trac tions•M orpho . a lte rat ions

Pres s ures•P oin t s ou rce po ll.•D iffu se s ourc e pol l.•W ate r abs trac tions•M orpho . a lte rat ions

Ex pert

Back groundBack groundSW 1: D is trict

SW 2: B a sins

SW 4: Su rface W B•R iver•La k e•Tra nsitio nal•C o astal

S urfa ce W B G rou ndW B M o nitorin g

SW 4b : E co. s ta tus

SW 4c : E co. pote ntia l

SW 4d : S ynth . po ll.

SW 4e : C hem . s ta tus

S u rfac e W B G ro u n dW B P rote c te d A rea s

SW 4b : E co. s ta tusSW 4b : E co. s ta tus

SW 4c : E co. pote ntia lSW 4c : E co. pote ntia l

SW 4d : S ynth . po ll.SW 4d : S ynth . po ll.

SW 4e : C hem . s ta tusSW 4e : C hem . s ta tus

S u rfac e W B G ro u n dW B P rote c te d A rea sS u rfac e W B G ro u n dW B P rote c te d A rea s

R efe renc eThem aticPres s ures•P oin t s ou rce po ll.•D iffu se s ourc e pol l.•W ate r abs trac tions•M orpho . a lte rat ions

Ex pert

Back ground

R e fe renc eR e fe renc eThem aticThem aticPres s ures•P oin t s ou rce po ll.•D iffu se s ourc e pol l.•W ate r abs trac tions•M orpho . a lte rat ions

Pres s ures•P oin t s ou rce po ll.•D iffu se s ourc e pol l.•W ate r abs trac tions•M orpho . a lte rat ions

Ex pert

Back groundBack groundSW 1: D is trict

SW 2: B a sins



SW 1: D is trict

SW 2: B a sins



SW 1: D is trictSW 1: D is trict

SW 2: B a sinsSW 2: B a sins



S urfa ce W B G rou ndW B M o nitorin gS urfa ce W B G rou ndW B M o nitorin g

Figure 1. Architecture of the SDIGER SDI.

The area covered by this SDI project is particularly interesting because although most of the Adour and Garonne river basins lay in French territory and Ebro river basin lay in Spanish territory, some stream and river headwaters are located in the other country. This is the case, for instance, of the Garonne river source, which is located in Spain and managed by the Ebro River Basin Authority, and of the Irati river headwaters, an Ebro river tributary which, on the contrary, is located in France and managed by the Water Agency for the Adour-Garonne River Basins. Cross-border information is, thus, of great importance for each of the Basin Authorities in order to assure that the Water Framework Directive requirements are fulfilled in each of the river basin districts. Additionally, this cross-border area includes several protected areas included within Natura 2000, the network of protected areas in the European Union. Within this scenario, two applications are going to be developed following the INSPIRE principles and proposed architecture:

• WFD Reporting. The WFD introduces a new approach to data and information collection and reporting. This use case proposes to use INSPIRE principles for fulfilling the reporting requirements of the member states to the European Commission. In particular data required by articles 3 and 5 of the WFD are taken as an example to implement the reporting mechanisms in an INSPIRE compliant way, i.e. the required data and information will be directly accessed within a spatial data infrastructure.

• Water abstraction request use case. In France and Spain, the use of both surface and groundwaters for private purposes requires an authorisation given by an authority. The administrative process for a water abstraction request requires users to provide an application form specifying the characteristics of the water abstraction point, water use and water discharge point. The objective of this use case is to provide users with some guidance, data and documentation needed to follow the administrative process of the water abstraction request. Stakeholders will be provided with a web application that will enable them to specify the request details (including location of the geographical elements related to the request). Users will be presented a report indicating whether the request is possible according to the legislation of the affected country, tabular information needed for the application form and that depends on the spatial data provided by the user, a printed map with the spatial data provided by the user to be included with the request, and an orientative, not legally binding report about the request compliance with WFD criteria.

Details of both applications can be found at the “Application Scenario” document available at the SDIGER portal (http://sdiger.unizar.es).

SDIGER: Experiences and identi�cation of problems on the creation of... Sesión 6


Metadata related activities 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. Definition of metadata profiles 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. Metadata edition tool 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.

Organization (Data Provider) Count IGN Spain 23700 CHE 35 IGN France 3 AEAG 18 DIREN 8 SMEAG 12 Eurostat (NUTS) 1 JRC (IMAGE2000) 2000 EEA (NATURA2000) 1 EuroGeographics 2 Total 25780

Table 1. Count of records in the metadata catalog

Multilingual access portal to data and services. 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. Multilingual aspects of the application 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

Entrance gate WFSCommon Schema

Common reference system

Local WFSLocal Models

Local coordinate systems

Request : Rivers

Translator

Request : Ríos, Rivières Answer : Ríos, Rivières

Answer : Rivers

AEAG WFSCHE WFS

User client browser

Entrance gate WFSCommon Schema

Common reference system

Local WFSLocal Models

Local coordinate systems

Request : Rivers

Translator

Request : Ríos, Rivières Answer : Ríos, Rivières

Answer : Rivers

AEAG WFSCHE WFS

Figure 2: GiMoDig approach for on-the-fly conversions

The process followed to fulfil this harmonisation of data models has been the following: • Analysing the data inventoried and identifying matching data • Taking into account other data models experiences: GISCO, Eurosion, data model proposed by GIS Working

Group for the WFD Common Implementation Strategy • Developing of a common data object oriented model (using UML) • Establishing mappings between original data structures at each institution and the common data model to

guarantee a seamless data integration and use. Finally, we are studying now the approaches to allow the conversion of data on the fly. One of these approaches is the analysis of the use of an on-the-fly schema translation tool from the GIMODIG project, which is based on the use of XSLT documents (see Figure 2). Additionally, other more pragmatic approaches are also taken into account, such as the creation of database views to transform national data into data compliant with the harmonized models. 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. Business plan for implantation of INSPIRE at the European level 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.

Maintenance for the second year period 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. Problems related with the definition of a useful application scenario 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. Problems related with metadata activities 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.

Problems related with data specifications 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. Problems related with services Definition of portrayal services 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.

Definition of a distributed catalog 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).

Definition of a transnational gazetteer 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

IGN -Spain - geographic names - administrative names - hydronyms 361581

CHE Ebro - water points 52902

IGN-France

- hydronyms - populated places - non-populated places - oronyms - other 94107

Total 508590

Table 2. Count of records in the Gazetteer

In addition, the initial objective of the project was to be able to offer a distributed gazetteer service. This initial objective found the same problems than the distributed catalog. Furthermore, to be able to offer a centralised gazetteer it was necessary to solve two additional problems:

• There are no approved specifications for gazetteer, with the consequent problems for the exchange of data. • Problems in the different typology of features. The IGN-F provides 74 different types, the IGN-S provides 50

different types, and the CHE provides 20 different types. These make a set of 144 different types. After studied them, the current gazetteer has 129 different types.

Problems related with the definition Geoportal 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 dream of reusing the infrastructure created for other SDIs 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. The management of a transnational/transinstitutional 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.



SESIÓN 7

SERVICIOS WEB II

209

La IDEE como Herramienta de Ayuda a la Elaboración del Inventario del Patrimonio Industrial de Aragón

F.J.Zarazaga-Soria1, M. García2, M. G. Hernández2, P. Biel2, F.J.López1, J.F.Valero1

1Dep. de Informática e Ingeniería de Sistemas Universidad de Zaragoza (España)

[email protected], [email protected], [email protected] 2Dep. de Historia del Arte

Universidad de Zaragoza (España) [email protected], [email protected], [email protected]

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

La IDEE como Herramienta de Ayuda a la Elaboración del Inventario... Sesión 7


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 parte del Patrimonio Cultural 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.

Sesión 7 La IDEE como Herramienta de Ayuda a la Elaboración del Inventario...


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). La situación actual del Patrimonio Industrial en Aragón 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:

• La industrialización de Zaragoza ha quedado minimizada por la destrucción implacable de gran cantidad de fábricas que se diseminaban en sus afueras hoy parte de la nueva trama urbana. El crecimiento de la ciudad entre las décadas de los 80 y 90 ha propiciado que las fábricas y otras tipologías arquitectónicas industriales, como las estaciones del ferrocarril, fueran absorbidas por este crecimiento y en la mayoría de los casos se convirtieran en elementos molestos para la especulación del suelo, por ello ni se ha planteado la conservación total o parcial de los edificios industriales.

• En el espacio rural, las nuevas fábricas como las azucareras u otras de menor transcendía regional pero no local, como por ejemplos las fábricas de harinas, han quedado abandonas pero no destruidas por lo que todavía pueden ser objeto de catalogación.

• En la década de los noventa y en el medio rural, se ha asistido a una revalorización del patrimonio industrial, predominantemente arquitectónico. Ante el cambio de modelo económico y el consiguiente hundimiento de la economía tradicional, en un numero cada vez más creciente de municipios se ha optado por un nuevo modelo de desarrollo económico basado en el patrimonio cultural. Así, fábricas, mataderos o estaciones de ferrocarril se han recuperado y rehabilitado para los más diversos fines.

• Dentro de esta situación debemos aludir al patrimonio industrial mueble. La situación más común es el desmantelamiento del edificio industrial encontrado en una situación de pérdida irremediable del patrimonio

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…). El Catálogo del Patrimonio Industrial y Obra Pública de Aragón 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. ESQUEMA GENERAL DE TRABAJO USANDO LOS RECURSOS DE LAS IDEs 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.

Aplicación del proceso 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



detalle y la cobertura de los mapas y planos dependerán de la amplitud geográfica de la zona de campo, así como de la duración e intensidad del trabajo a realizar.

o Búsqueda de informaciones previas y de apoyo al trabajo de campo. En esta actividad se llevará a cabo una documentación previa de la zona de campo sobre la que se va a trabajar. Dependiendo de la naturaleza del trabajo a realizar será necesario hacer búsquedas bibliográficas, recopilación de trabajos anteriores, contactar con personal de la zona para documentarse, etc.

• Trabajo de campo propiamente dicho. El objetivo de las tareas a realizar aquí es la captura de la información en campo. Esta captura será manual, automática o semi-automática dependiendo de la naturaleza y objetivos del trabajo de campo. Por norma general se distinguirán dos actividades principales:

o Caracterización geográfica del elemento objeto del estudio en campo. Generalmente con la ayuda del GPS, se vinculará el elemento objeto del estudio en campo a una posición geográfica (o conjunto de posiciones si el área geográfica que cubre es relevante).

o Caracterización documental del elemento objeto del estudio en campo. Utilizando un cuaderno de notas, o directamente sobre un equipo portátil, se documentarán los aspectos necesarios del elemento.

o Adicionalmente, y condicionado por el objeto de estudio, se acompañará la captura de información que represente la ruta de acceso (generalmente usando el GPS) hasta el elemento desde un punto de referencia bien caracterizado, fotografías y vídeos del mismo.

• Trabajo de gabinete. El objetivo de las tareas a realizar aquí es la normalización, estructuración y complemento de las informaciones recogidas en campo. Actividades a realizar:

o Normalización, estructuración y complemento de la información de caracterización del elemento objeto del estudio en campo. Se trata de introducir en el ordenador la información recopilada en el cuaderno de notas y acompañarla de actividades de normalización, estructuración y complemento. Esta información se volcará sobre almacenes de datos determinados y según procesos preestablecidos.

o Caracterización de informaciones adicionales recopiladas. Se llevará a cabo la documentación y normalización de otras informaciones obtenidas como pueden ser rutas, fotografías, etc.

o Revisión de la iteración con el fin de aportar mejoras “en línea” al proceso.. Cierre del proyecto y conclusiones 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 VISIÓN IDE DEL INVENTARIO DEL PATRIMONIO INDUSTRIAL DE ARAGÓN 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.



RECURSOS IDE UTILIZADOS EN ESTE PROYECTO 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



Encadenamiento de servicios web: Hacia IDEs basadas en servicios

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

Sesión 7 Encadenamiento de servicios web: Hacia IDEs basadas en servicios


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. INFRASTRUCTURAS DE SERVICIOS ESPACIALES 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.

Figura 1: Arquitectura de referencia de INSPIRE (extraído de [8])

Encadenamiento de servicios web: Hacia IDEs basadas en servicios Sesión 7


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. ENCADENAMIENTO DE SERVICIOS MEDIANTE COMPONENTES INTEGRADOS 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.

Figura 2: Interacciones entre los componentes del modelo. 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:

• Los aspectos descriptivos como metadatos referidos al contexto de la funcionalidad de un componente integrado.

• Los aspectos funcionales detallan la funcionalidad o las capacidades de un componente integrado en términos de la operación que ofrece y sus parámetros de entrada y salida.

• Los aspectos estructurales muestran como un componente integrado está internamente estructurado como combinación de servicios u otros componentes más simples, utilizando para ello los patrones de workflow.

• Los aspectos de enlace definen el flujo de datos tanto entre instancias de servicios web y componentes integrados como entre los propios componentes integrados que forman una composición.

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. Metodología de composición de servicios 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]. Proceso de abstracción de servicios 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.



Figura 3: Arquitectura detallada para la creación, composición y transformació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. Proceso de composición 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). Proceso de transformación de servicios 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.



APLICACIÓN DEL MODELO DE COMPONENTES INTEGRADOS 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).

Figura 4: Componente integrado monitorización encadenando componentes integrados. 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)



Pruebas benchmark de soluciones cliente/servidor en software libre

Esbrí Palomares, Miguel Ángel1 Higón Valero, José Vicente2

Departamento de Lenguajes y Sistemas Informáticos, Universidad Jaume I (Castellón), [email protected] 1

Consellería de Infraestructuras y Transportes de la Generalitat Valenciana (Valencia), [email protected] 2

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.

Sesión 7 Pruebas benchmark de soluciones cliente/servidor en software libre


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. EL CONTEXTO DEL BENCHMARKING 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

Pruebas benchmark de soluciones cliente/servidor en software libre Sesión 7


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. Servicios web de visualización y geo-procesamiento 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.



Descripción de la organización del sistema 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 Entorno de las pruebas para los Web Feature Services 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. Entorno de las pruebas para los Web Map Service 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. Descripción de los datos de prueba 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 sobre la capa poligon_g (WFS)

Figura 5: Radio de búsqueda utilizado en la operación espacial

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.

Operación BBOX sobre capas locales con distintas geometrías y tamaños

0,00

20,00

40,00

60,00

80,00

100,00

120,00

140,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

tiem

po d

e re

spue

sta

(seg

undo

s)

servidor4-geoserver

servidor4-mapserver

servidor3-geoserver

servidor3-mapserver

servidor2-geoserver

servidor2-mapserver

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.

Operación GetMap sobre capas locales con distintas geometrías y tamaños

0,00

5,00

10,00

15,00

20,00

25,00

30,00

punto

s_p

punto

s_m

punto

s_g

linea

s_p

linea

s_m

linea

s_g

polig

on_p

polig

on_m

polig

on_g

capas

Tiem

po d

e re

pues

ta (e

n se

gund

os)

geoservermapserver

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.



Operación GetMap sobre PostGIS con distintas geometrías y tamaño

0,00

5,00

10,00

15,00

20,00

25,00

30,00

35,00

40,00

punto

s_p

punto

s_m

punto

s_g

linea

s_p

linea

s_m

linea

s_g

polig

on_p

polig

on_m

polig

on_g

capas

tiem

po d

e re

spue

sta

(en

segu

ndos

)

geoserver

mapserver

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.

Operación GetMap sobre la capa poligon_m con 10 usuarios

0,0010,0020,0030,0040,0050,0060,0070,00

geoserver mapserver

solución

Tiem

po d

e re

spue

sta

(en

segu

ndos

)

poligon_m

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



La gestión de usuarios en una Infraestructura de Datos Espaciales

D. Portolés-Rodríguez1, R. Martínez-Cebolla2 Aragonesa de Servicios Telemáticos - Gobierno de Aragón (España), [email protected] 1, [email protected] 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.

Sesión 7 La gestión de usuarios en una Infraestructura de Datos Espaciales


CLASIFICACIÓN DE LOS ACTORES DE UNA IDE 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). Clasificación según perfiles de usuario 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. Según su perfil, los usuarios puede clasificarse de diferentes formas. A saber:

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

Figura 1: Clasificación de usuarios basada en perfiles

La gestión de usuarios en una Infraestructura de Datos Espaciales Sesión 7


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á) Clasificación según unidades de trabajo El concepto de unidad de trabajo 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.

Elementos de una unidad de trabajo 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. Entorno de trabajo global del sistema 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.

Figura 3: Entorno de gestión de usuarios basado en unidades de trabajo.

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. Valoración crítica de las alternativas presentadas 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. LA GESTIÓN DE USUARIOS EN FUNCIÓN DEL ÁMBITO DE LA 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.



CASO PRÁCTICO: CONSTRUCCIÓN DE UN ENTORNO DE TRABAJO PARA LA GESTIÓN DE USUARIOS EN EL GOBIERNO DE ARAGÓN 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:

• Acceso a todos los usuarios del sistema. • Acceso en modo lectura a todos los datos de la unidad de trabajo. • Acceso en modo lectura y escritura a todos los datos de la unidad de trabajo.

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.



SESIÓN 8

IDES LOCALES Y REGIONALES

247

Estableciendo bases organizacionales para una IDE local: aportaciones desde una Cooperativa de Datos Espaciales

Morant de Diego, Teresa1 Carretero Moreno, Inmaculada2

Martín Betancor, Moisés3 Rubio Royo, Enrique4

Universidad de Las Palmas de Gran Canaria (España), [email protected] 1, mmartin@@dcegi.ulpgc.es3 , [email protected] 4

Servicio de Planeamiento, Ayuntamiento de Las Palmas de Gran Canaria (España), [email protected] 2

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

Estableciendo bases organizacionales para una IDE local: aportaciones... Sesión 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. 2.- FACTORES PARA EL ÉXITO DE UNA IDE 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.

2.1 Problemas organizacionales 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

Sesión 8 Estableciendo bases organizacionales para una IDE local: aportaciones...


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]. 2.2 Propuesta para abordar las barreras organizacionales 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.- LA INICIATIVA SICAM 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].

3.2 Características de SICAM 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).

Figura 1.- Captura de pantalla de la entrada al Portal de SICAM

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

ORGANIZACIÓN Socios Usuarios SERVICIOS

MUNICIPALES ALP Administración de Rentas Arquitectura Alumbrado Público Policía Local Pymes Bomberos

Estadística Proyecto y Obras/Equipamiento Comunitario

Gestión Urbanística Proyecto y Obras/Obras de Urbanización

Limpieza Vías y Obras/Mantenimiento de red viaria

Medio Ambiente Mobiliario Urbano Patrimonio Planeamiento Unidad Integral del Agua Vías y Obras/Parques y Jardines

EMPRESAS MUNICIPALES Sagulpa

Guaguas municipales EMPRESAS DE

SERVICIOS Global Emalsa

OTRAS ADMINISTRACIONES

Universidad de Las Palmas de Gran Canaria

Figura 2.- Cuadro de organizaciones participantes en la Iniciativa SICAM

4.- LA COOPERATIVA SICAM 4.1 Concepto de “Cooperativa de Datos Espaciales” 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. 4.2 Bases conceptuales 4.2.1 El Interaccionismo Social 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]. 4.2.2 La Gestión del Cambio y del Conocimiento 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. 4.2.3 El modelo de Organización en Red SURICATA 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. 4.3 Características de la Cooperativa SICAM (CoS) 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 formulación de la Cooperativa SICAM (CoS) se tradujo en los siguientes elementos básicos:

- Un conjunto de conceptos y principios que la guían (esto es, la ”filosofía” subyacente) - Un entorno para la cooperación (arquitectura y desarrollos que posibilitan la compartición, coordinación,

interacción y comunicación entre los participantes) - Una coordinación de las acciones



4.3.1 Conceptos y principios 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”.

Los principios en los que se basa son: - No obligar a los socios en más que a lo que se comprometan voluntariamente - Establecer claramente responsabilidades en cuanto a la propiedad, mantenimiento y custodia de los datos - Garantizar la accesibilidad e interoperatibilidad entre los diferentes sistemas departamentales y SICAM - Considerar la coordinación como un proceso cuyo fin es el de facilitar la gestión de los recursos (humanos,

materiales, económicos y tiempo), los procesos (de introducción, desarrollo, uso y mantenimiento de la GI) y del cambio organizacional

- Constituir una forma de trabajo con base eminentemente técnica que no implique necesariamente la constitución de un reconocimiento “rubricado” por parte de las estructuras políticas responsables últimas de cada organización o grupo participante

- Potenciar una contribución global e integradora de los diferentes participantes, promoviendo una nueva forma de concebir la gestión territorial.

- Impulsar la migración a estándares que aseguren la total interoperatibilidad y a software abierto. Para alcanzar sus objetivos últimos, CoS considera de la máxima importancia:

- Establecer lazos de trabajo cooperativos, mediante la compartición de información en proyectos departamentales (a través de reuniones periódicas, formulación de estrategias y proyectos conjuntos

- Llegar a cuerdos para la cofinanciación de acciones y proyectos - Dotarse de la suficiente flexibilidad para adaptarse al rápido cambio tecnológico - Fomentar la adecuación al cambio e innovación en las organizaciones participantes, y - Fomentar la capacitación mediante el aprendizaje individual y organizacional, explorando las nuevas

posibilidades de enseñanza de la red, la compartición de recursos y de los entornos colaborativos 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]. 4.3.2 Entorno para la cooperación: experiencias 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 El establecimiento, progreso y consolidación de la Cooperativa de Datos Espaciales de la Iniciativa SICAM (CoS) ha mostrado con el tiempo que constituye el marco de trabajo organizativo y de coordinación más adecuado para ir venciendo los habituales problemas organizacionales e institucionales que surger siempre entorno a la GI, especialmente entorno a la implementación del SIG Corporativo. Es por ello que consideramos que CoS es un magnífico punto de partida para que, basándose en la consideración de la diversidad y la interacción entre participantes, se aborden dichos problemas o barreras, desempeñando un papel facilitador o de “motor de cambio” en las organizaciones. Desde CoS se garantizan, mediante la motivación, la interacción y la confianza, el necesario cambio de valores, actitudes y comportamientos que garantices el adecuado progreso y consolidación de la IDE local del municipio de Las Palmas de Gran Canaria, toda vez que se prepara a la administración para abordar los nuevos retos de mejora necesarios para el tránsito a una Sociedad Red que sea más sostenible. 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



IDEZar: un ejemplo de implantación de una IDE local

López Pellicer, F. J.1

Álvarez, P.2 Muro-Medrano, P.R. 3

Universidad de Zaragoza (España), [email protected] 1, [email protected] 2, [email protected] 3

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. LOS PRIMEROS PASOS DE LA INFRAESTRUCTURA DE DATOS ESPACIALES DE ZARAGOZA 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:

IDEZar: un ejemplo de implantación de una IDE local Sesión 8


• 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:

• las relacionadas con los componentes tecnológicos de la IDE; • las que inciden en los componentes de organización, tanto políticos como técnicos; • las que tratan con el componente de usuario, ya sea ciudadanos o técnicos del ayuntamiento, y; • las que impulsan los componentes de interoperabilidad e integración con el resto de iniciativas IDE.

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.

Sesión 8 IDEZar: un ejemplo de implantación de una IDE local


Figura 1: Organización técnica de IDEZar 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):

• El nodo de servicios básicos, que contiene aplicaciones básicas de visualización, búsqueda y georreferenciación así como servicios con información cartográfica de base, información cartográfica que permita referenciar datos, así como los servicios externos accesibles por medio de acuerdos.

• El nodo piloto temático Agenda 21 Local que contiene información temática del departamento de Medio Ambiente (calidad del aire, zonas protegidas, energías renovables).

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

CoreServices

Emergencias

OGCWMS

OGCWCS

OGCWFS

OGCCatalog

Datos Metadatos

ApplicationNivel aplicaciones

Nivel datosOrganización departamental

Organización funcional de un nodo

UrbanManagement

ServiciosBásicos

Infraestructuras

OGCWMS

OGCWCS

OGCWFS

OGCCatalog

Application

OGCWMSOGCWMS

OGCWCSOGCWCS

OGCWFSOGCWFS

OGCCatalog

OGCCatalog

Cartografía

ApplicationAplicación

Nivel servicios

Urbanismo

Medio Ambiente



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:

• determinar sus necesidades mediante la elaboración de casos de uso; • elaborar perfiles y desarrollar aplicaciones sensibles a ellos; y • aprovechar su experiencia como usuarios finales.

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:

• los ciudadanos, que acceden a la parte pública del portal; y • los miembros de la administración local, que acceden a las aplicaciones situadas en la Intranet del

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



Figura 2: Interoperabilidad en la práctica 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. DESCRIPCIÓN DEL NIVEL TECNOLÓGICO 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 incorporación de los datos existentes a la infraestructura, creando metadatos y transformando formatos no SIG a formatos SIG; y

• la creación de un modelo de datos urbanos que organice la información espacial disponible. 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;

IDEZar iniciativa aragonesa de datos espaciales

Nodos interorperables (interfaces estándar)

Nivel local

Nivel regional

IDEE

Nivel nacional

SB



• 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. Aplicaciones y casos de uso Se trabaja en las siguientes líneas con el fin de hacer visible la IDE:

• un geoportal orientado a los ciudadanos; • aplicaciones de Intranet para los miembros de la administración local para facilitar el trabajo de los técnicos

del ayuntamiento que manejen información susceptible de georreferenciarse; y • un nodo temático sobre la Agenda 21 consecuencia del compromiso del ayuntamiento.

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



Figura 3: Geoportal http://www.zaragoza.es/idezar 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").

Figura 4: aplicaciones del geoportal 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:



• Buscador de propósito general. • Visualizador de propósito general con la capacidad de incluir dinámicamente datos procedentes de cualquier

servidor de mapas que cumpla con la especificación WMS de OGC. • Buscador especializado en el departamento de Medio Ambiente. La diferencia estriba solo en los datos que

pueden ser encontrados. • Visualizador orientado a técnicos de planificación urbana. Sobre la cartografía urbana enlaza determinadas

zonas (en este caso distritos) con documentos (estadísticas, planes de desarrollo) que son accesible tras marcar sobre la zona.

• Herramienta de georreferenciación. 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.

Figura 5: Herramienta de georreferenciación Nodo temático Agenda 21 Como se ha comentado antes, la información medioambiental disponible en la administración es mucha, compleja y estaba poco o nada documentada. Descubrir cómo explotarla e integrarla en aplicaciones no fue tarea fácil. Teniendo en mente que uno de los objetivos de la Agenda 21 es la difusión de información medioambiental entre los usuarios se decidió hacer accesible dicha información mediante aplicaciones temáticas y mejorando las aplicaciones existentes. Por ejemplo, la aplicación de información de calidad atmosférica se modificó para incluir mapas servidos por un WMS del nodo básico.



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

Figura 6: nodo agenda 21 CONCLUSIONES Y TRABAJO FUTURO 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.



Creación de un catálogo de información territorial normalizada y un

canal de atención a demandas de información

Chanfreut Garballo, Mª Rosa1 Alameda Manzanares, Alejandro2

Empresa Pública Desarrollo Agrario y Pesquero. Consejería de Agricultura y Pesca. Junta de Andalucía (España), [email protected] 1 , [email protected] 2

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.

Creación de un catálogo de información territorial normalizada y un... Sesión 8


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

Sesión 8 Creación de un catálogo de información territorial normalizada y un...


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:

• Recoger la información territorial, de manera organizada y adecuadamente definida, en un sistema

centralizado. • Canalizar los flujos de información entrante y saliente en la Empresa. • Facilitar el acceso a los datos geográficos. • Atender las demandas de información territorial. • Identificar el derecho de uso y traslado de los datos para respetar la confidencialidad de los mismos.

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.

FASES DEL PROYECTO Son las siguientes:

• Especificaciones técnicas: el grupo responsable de este proyecto, ha realizado la evaluación de necesidades para detectar carencias en la gestión de la información dentro de la Empresa. Paralelamene, ha analizado diferentes metodologías de organismos nacionales e internacionales empleadas para la definición y organización de la información.

• Definición de procedimientos fundamentales para el desarrollo del proyecto. Algunos de ellos son los que siguen:

- Control del uso y alimentación del sistema - Atención a demandas de información. - Control de acceso y uso de datos. - Intercambio de información con otros organismos. - Registro de entrada y salida de datos.

• 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: Fase de revisión de iniciativas 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. Aplicaciones normalizadas para la gestión de metadatos 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. Difusión de los datos y atributos geográficos 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. Fase de elaboración de propuestas 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 Los metadatos recogidos en el Registro de información territorial agrario y pesquero incluyen:

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

Dataset title (Ob) (MD_Metadata > MD_Identification.citation > CI_Citation.title) Spatial representation type (Op) (MD_Metadata > MD_DataIdentification.spatialRepresentatio nType) Dataset reference date (Ob) (MD_Metadata > MD_Identification.citation > CI_Citation.date) Reference system (Op) (MD_Metadata > MD_ReferenceSystem) Dataset responsible party (Op) (MD_Metadata > MD_Identification.pointOfContact > CI_ResponsibleParty) Lineage (Op) (MD_Metadata > DQ_DataQuality.lineage > LI_Lineage) Geographic location of the dataset (by four coordinates or by geographic identifier) (C) (MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicBoundingBox or EX_GeographicDescription) On-line resource (Op) (MD_Metadata > MD_Distribution > MD_DigitalTransferOption.onLine > CI_OnlineResource) Dataset language (Ob) (MD_Metadata > MD_DataIdentification.lauguage) Metadata file identifier (Op) (MD_Metadata.fileIdentifier)

Dataset character set (C) (MD_Metadata > MD_DataIdentification.characterSet Metadata standard name (Op) (MD_Metadata.metadataStandardName) Dataset topic category (Ob) (MD_Metadata > MD_DataIdentification.topicCategory) Metadata standard version (Op) (MD_Metadata.metadataStandardVersion) Spatial resolution of the dataset (Op) (MD_Metadata > MD_DataIdentification.spatialResolution > MD_Resolution.equivalentScale) Metadata language (C) (MD_Metadata.language) Abstract describing the dataset (Ob) (MD_Metadata > MD_Identification.abstract) Metadata character set (C) (MD_Metadata.characterSet) Distribution Format (Op) (MD_Metadata > MD_Distribution > MD_Format.name and MD_Format.version) Metadata point of contact (Ob) (MD_Metadata.contact > CI_ResponsibleParty) Additional extent information for the dataset (vertical and temporal) (Op) (MD_Metadata > MD_DataIdentification.extent > EX_Extent) Metadata date stamp (Ob) (MD_Metadata.dateStamp)

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:

• Revisión de la quinta versión del Registro de información territorial. • Organización, definición y actualización de capas de información generales y específicas (procedente de

diferentes fuentes) utilizadas en la Empresa. • Creación de vías de comunicación con organismos generadores y consumidores de información territorial para:

cesión de información, actualización datos, permiso de uso de datos, intercambio de iniciativas de trabajo, etc. • Análisis de alternativas y planteamiento de metodologías para la difusión de los datos y metadatos (servicio de

catálogo de información geográfica y geoportal). Actualmente, el catálogo de metadatos se encuentra en fase dedesarrollo, por lo que el Registro de información territorial agrario y pesquero está dotado de herramientas de búsqueda e importación de metadatos para que el grupo gestor de información territorial de la Empresa pueda atender las demandas de datos que se reciben diariamente.

• Atención a demandas de información de diferentes Áreas de la Empresa y Administración a través de correo (en un futuro cercano se centralizará a través de un portal SIG). Hasta el momento, los consumidores de información, realizan sus peticiones a través de correo electrónico, utilizando un modelo de solicitud de datos, que es archivado en el Registro de demandas de información territorial por los gestores de la información.

• Identificación del derecho de uso y traslado de los datos. Los metadatos generados, indican el grado de confidencialidad de la información y, por tanto, permiten establecer un modelo de roles para evitar flujos ilegales de información y garantizar el acceso y uso correcto de los datos, al atender las peticiones.

• Control de entrada y salida de datos. Los flujos de información territorial están siendo registrados en el Registro de entrada y salida de datos. Esta aplicación mejora el rendimiento en el trabajo ya que evita confusiones, a veces surgidas en los envíos de información, cuando no existe constancia de ellos.



Problemas encontrados La ejecución del proyecto está presentado la problemática siguiente:

• 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 Las tareas pendientes de desarrollo son las siguientes:

• 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).



Jidee05

Documents

Transcript of Jidee05