IDENTIFICACIÓN Y ESTUDIO DE LOS GEOSERVICIOS ESENCIALES ...

IDENTIFICACIÓN Y ESTUDIO DE LOS GEOSERVICIOS ESENCIALES PARA LA IMPLANTACIÓN DE UNA IDE

DE ACUERDO CON LA DIRECTIVA INSPIRE Y EL OPEN GEOSPATIAL CONSORTIUM

MASTER EN GEOTECNOLOGÍAS CARTOGRÁFICAS EN

INGENIERÍA Y ARQUITECTURA

PROYECTO FIN DE MASTER

Junio 2010

Manuel Gallego Priego

Tutor: Angel Luis Muñoz Nieto

Identificación y estudio de los geoservicios esenciales para la implantación de una IDE de acuerdo con la Directiva INSPIRE y el Open Geospatial Consortium

2/109 Proyecto Fin de Máster. Manuel Gallego Priego

Máster en Geotecnologías Cartográficas en la Ingeniería y Arquitectura.


Índice general

Índice general...................................................................................................... 3 Índice de figuras ................................................................................................. 5 Índice de tablas ................................................................................................... 6 Resumen ............................................................................................................. 7 Términos y definiciones ...................................................................................... 8 1. INTRODUCCIÓN ........................................................................................... 11

1.1. Los servicios en las Infraestructuras de Datos Espaciales..................... 12

1.2. Descripción del proyecto..................................................................... 13

1.3. Cuestiones a resolver en el trabajo ..................................................... 13

2. SERVICIOS DE RED EN LA DIRECTIVA INSPIRE ................................................ 15

2.1. Normas de ejecución (Implementing Rules) ......................................... 16

2.2. Reglamento 976/2009 sobre Servicios de Red .................................... 17

2.3. Arquitectura de servicios de red .......................................................... 18

2.4. Descripción de los servicios previstos en INSPIRE ................................ 20

2.4.1. Localización ...................................................................................... 20

2.4.2. Visualización ..................................................................................... 23

2.4.3. Descarga ........................................................................................... 24

2.4.4. Transformación ................................................................................. 26

2.4.5. Acceso a servicios ............................................................................. 27

2.5. Calidad de los servicios ....................................................................... 28

2.6. Relación de documentos INSPIRE Network Services: ............................. 30

2.7. Sumario .............................................................................................. 31

3. ESPECIFICACIONES RELACIONADAS CON SERVICIOS DEL OPEN GEOSPATIAL CONSORTIUM .............................................................................................. 33

3.1. Especificaciones OGC para servicios web ............................................ 34

3.1.1. Servicios de localización .................................................................... 34

3.1.2. Servicios de visualización .................................................................. 37

3.1.3. Servicios de descargas ...................................................................... 39

3.1.4. Servicios de transformación .............................................................. 41

3.1.5. Complementos a servicios ................................................................. 42

3.2. Interacción entre datos y servicios ...................................................... 44

3.3. Sumario .............................................................................................. 45

4. SERVICIOS SOAP .......................................................................................... 47

4.1. Descripción de un servicio SOAP ......................................................... 47

4.2. Ejemplo de funcionamiento de un servicio SOAP ................................. 49

4.3. Servicios en funcionamiento ............................................................... 51




4.4. Sumario .............................................................................................. 51

5. METADATOS DE SERVICIO ............................................................................ 53

5.1. Normas, especificaciones y recomendaciones ..................................... 53

5.2. Propuesta de plantilla de metadatos ................................................... 58

5.3. Directorio de servicios ........................................................................ 58

5.4. Catálogo de servicios .......................................................................... 59

5.4.1. CatMDServices .................................................................................. 60

5.5. Sumario .............................................................................................. 61

6. EVALUACIÓN DE LA CALIDAD DE LOS SERVICIOS .......................................... 63

6.1. Requerimientos de calidad del W3C .................................................... 63

6.2. Servicio Status Checker ....................................................................... 64

6.3. Herramienta GeoPole .......................................................................... 67

6.4. Sumario .............................................................................................. 68

7. PROGRAMAS PARA CREAR SERVICIOS WEB DE INFORMACIÓN GEOGRÁFICA .. 71

7.1. MapServer ........................................................................................... 72

7.2. Geoserver ........................................................................................... 74

7.3. Deegree .............................................................................................. 75

7.4. Plataformas de software comercial ...................................................... 75

7.5. Cumplimiento de las especificaciones OGC ......................................... 76

7.6. Sumario .............................................................................................. 78

8. APLICACIONES CLIENTE PARA EL USO DE SERVICIOS WEB DE INFORMACIÓN GEOGRÁFICA ............................................................................................... 81

8.1. Clientes ligeros ................................................................................... 81

8.2. Clientes pesados ................................................................................. 82

8.3. Desarrollo de aplicaciones .................................................................. 84

8.4. Sumario .............................................................................................. 84

9. CONCLUSIONES ........................................................................................... 85

9.1. Consideraciones generales .................................................................. 85

9.2. Recomendación sobre servicios web en una IDE .................................. 86

9.3. Resumen final ..................................................................................... 87

Anexo I: CONFIGURACIÓN DE UN SERVICIO OGC ................................................ 89 Anexo II: GUÍA PARA EL USO DE GEOSERVICIOS .................................................. 99 Referencias ..................................................................................................... 107




Índice de figuras

1-1 Esquema de la estructura del proyecto. 14 2-1 Esquema de la arquitectura técnica de INSPIRE ([22] Network Services Architecture). 19 2-2 Esquema de funcionamiento del servicio de visualización ([23] Technical Guidance

View Services) 24 2-3 Servicio de transformación combinado con el servicio de descarga (modo directo) [28]

27 3-1 Esquema de funcionamiento del servicio de localización. [33] 35 3-2 Imagen del cliente de consulta de metadatos de la IDEE (www.idee.es). 36 3-3 Esquema UML de las operaciones del Web Map Service [34]. 38 3-4 Explicación del funcionamiento de la división en baldosas del WMTS [35]. 39 3-5 Diagrama de relación entre objetos para la arquitectura de una IDE (Adaptado y

traducido de [4] D. Nebert) 44 4-1 Esquema de funcionamiento de un conjunto de servicios SOAP (Elaboración propia).

48 4-3 Descripción de un geoservicio en el directorio de la IDEC (www.geoportal-idec.cat). 49 4-2 Formato del mensaje SOAP. 49 4-4 Descripción de la operación de un servicio en el directorio de la IDEC(www.geoportal-

idec.cat) 50 5-1 Copia de un fichero obtenido con la operación GetCapabilities del servicio WMS de la

cartografía básica de la IDEE 56 5-2 Imagen del Directorio de Servicios de la IDEE

(http://www.idee.es/CatalogoServicios/CatServ/directorio_servicios.html). 58 5-3 Aspecto del Catálogo de servicios de la IDEE (http://www.idee.es/IDEE-

ServicesSearch/). 59 5-4 Catálogo de la IDEC (http://delta.icc.cat/SDIExplorer/cercaCataleg.jsp) 60 6-1 de proceso de los dos modos: Real Time Testing (izquierda) y Archive Testing

(derecha). 65 6-2 Resultados ofrecidos por el Service Status Checker en modo real. 66 6-3 Resultado del Service Status Checker en modo archivo. 67 6-4 Resultados ofrecidos por la herramienta GEOPOLE sobre un servicio WMS. 68 6-5 Resultados ofrecidos por la herramienta GEOPOLE sobre un servicio WMS. 68 7-1 Aspecto de la página web de MapServer (http://mapserver.org/). 72 7-2 Arquitectura de funcionamiento de MapServer (Fuente:

http://mapserver.org/introduction.html) 73 7-3 Aspecto de la web de Geoserver (http:// geoserver.org/) 74 7-4 Imagen de la página web de Deegree (http://www.deegree.org/). 75 7-5 Marcas registradas o de certificación, que otorga OGC. 76 8-1 Aplicación cliente para la consulta de nombres geográficos (Geoportal de la IDEE). 82 8-2 Conexiones a datos disponibles en Geomedia. 83




Índice de tablas

2-1 Criterios de búsqueda para el servicio de localización ([17] Reglamento 976/2009

INSPIRE). 22 2-2 Requerimientos de calidad de servicio de INSPIRE [22]. 29 2-3 Resumen de los requerimientos de calidad (elaboración propia) 29 3-1 Comparación de las operaciones requeridas por INSPIRE con las que ofrece la

especificación CSW ISO AP [24] 37 3-2 Comparación de las operaciones requeridas por INSPIRE para el servicio de

visualización con la norma ISO para WMS [23]. 38 3-3 Comparación de las operaciones requeridas por INSPIRE para el servicio de descagas

con la norma ISO para WFS [25]. 40 3-4 Tabla con los servicios OGC y sus versiones soportadas, extraída del documento de

definición de los Metadatos de servicio del GTIDEE [15]. 46 5-1 Metadatos de servicios espaciales ([16] Reglamento 1205/2008 de metadatos) 54 5-2 Comparación de los elementos de metadatos presentes en el reglamento INSPIRE de

metadatos [16], en los ficheros de capacidades de los servicios web y en la primera propuesta del Núcleo Español de Metadatos de Servicio (NEMS) [15]. 57

6-1 Relación de conceptos para medir la calidad de los servicio web [6]. 64 6-2 Servicios soportados por el SSC. 65 7-1 Tabla comparativa del cumplimiento de las especificaciones OGC de las aplicaciones

servidoras. (Elaboración propia a partir del listado de productos registrados de OGC). 77

7-2 Tabla de número de productos según especificación (Fuente: OGC). 78 9-1 Recomendación de servicios de red para una IDE 87




Resumen

La aparición de las infraestructuras de datos espaciales ha proporcionado a la sociedad una potente herramienta para la utilización de la información geográfica. Además, ha obligado a las administraciones, únicas productoras de datos espaciales, a modernizar los métodos de producción cartográfica y a definir políticas poco restrictivas para el uso de estos datos.

Las IDEs han ayudado a fomentar el manejo de la información geográfica, para compartir datos y conocimiento en los sectores público y el privado, y a desarrollar nuevos productos de valor añadido. Y para utilizar plenamente la información puesta en juego por estas infraestructuras, se necesitan mecanismos ágiles y eficaces, que no sólo permitan a las personas acceder a la información, sino que posibilite que las máquinas se pueden interconectar a través de sus aplicaciones informáticas. Esa conexión se realiza a través de unos interfaces llamados servicios web, definidos siguiendo los estándares internacionales para lograr una plena interoperabilidad.

La puesta en marcha de la iniciativa INSPIRE en 2002 por parte de la Unión Europea, que culminó con la aprobación de una directiva cinco años más tarde, ha generado en Europa una corriente de trabajo colaborativo para conseguir que la información geográfica salga de los “cajones” de las administraciones y sea utilizada por todos los ciudadanos. Unos años antes, la industria del software para la gestión de estos datos, había creado una organización, el Open Geospatial Consortium (OGC), con el objetivo de desarrollar estándares disponibles dentro del campo de la información geográfica, y colaborando activamente con la organización internacional encargada de la normalización ISO.

Estas iniciativas han permitido establecer infraestructuras de datos espaciales de una manera más sencilla, gracias a la cantidad de documentación generada; pero también han creado confusión debido a la proliferación de normas, especificaciones y recomendaciones desde los distintos organismos nacionales e internacionales.

El objetivo de este trabajo ha sido estudiar todos los aspectos relativos a los servicios de información geográfica de cara a su implantación como uno de los principales componentes de las infraestructuras de datos espaciales en Europa. Se ha analizado la legislación INSPIRE, los estándares de OGC, otros estándares para servicios web y los productos de la industria del software para la publicación y la utilización de los servicios de información geográfica. Como resultado de este análisis, se han elaborado unas recomendaciones para la utiliza de estos servicios de información geográfica en una IDE.




Términos y definiciones

API (Application Programming Interface): es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software.

CSG (Consejo Superior Geográfico): órgano colegiado de la administración general del estado encargado de la coordinación de la información geográfica en España.

DOUE: Diario Oficial de la Unión Europea.

DT (Drafting Teams): equipos de redacción para las normas de ejecución de INSPIRE.

Especificación: es una descripción técnica, detallada y exhaustiva de un producto o servicio, que contiene toda la información necesaria para su producción. Algunas especificaciones pueden ser adoptadas como normas o como estándares.

Estándar: es un documento o práctica que, sin ser norma, está consagrado y aceptado por el uso y cumple una función similar a la de una norma. Incluye los documentos de tipo normativo que no han sido definidos por un organismo oficial de normalización. En ocasiones se les llama normas de facto o normas de hecho. Un ejemplo son los formatos DGN, shape,…

FGDC (Federal Geographic Data Committee): agencia que el desarrollo coordinado, uso, y distribución de los datos geoespaciales en EEUU.

IDEE: Infraestructura de Datos Espaciales de España.

HTML (HyperText Markup Language): es el lenguaje de marcado predominante para la elaboración de páginas web.

IR (Implementing Rules): normas de ejecución de INSPIRE.

JRC (Joint Research Centre): centro de investigación de la Unión Europea; dirige los trabajos relacionados con la directiva INSPIRE.

LMO (Legate Madate Organization): organismos que tienen el mandato legal de en asuntos de información geográfica.

Metadato: dato que define y describe otros datos. Existen diferentes tipos de metadatos según su aplicación.

NEMS (Nucleo Español de Metadatos de Servicio): recomendación del grupo de trabajo de la IDEE para metadatos de servicio.

Norma: es todo documento que armoniza aspectos técnicos de un producto, servicio o componente, definido como tal por algún organismo oficial de normalización, como son ISO, CEN o AENOR. En ocasiones se les llama normas de jure o normas de derecho.

OGC (Open Geospatial Consortium): organización internacional que tiene el objetivo de desarrollar estándares públicamente disponibles dentro del campo de la información geográfica.

OSGeo (Open Source Geospatial Foundation): organización no gubernamental cuya misión es dar soporte y promover el desarrollo colaborativo de tecnologías geoespaciales y datos abiertos.




QoS (Quality of Services): requerimientos de calidad de servicio.

Recomendación: es una directriz que promueve un organismo que intenta armonizar prácticas y usos en una comunidad determinada, normalmente basándose en un consenso previo. Su mayor o menor éxito depende de la influencia que es capaz de ejercer el organismo que la propone.

SDIC (Spatial Data Interest Community): grupos de interés en datos espaciales.

SOA (Services Oriented Architecture): concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.

SOAP (Simple Object Access Protocol, o Protocolo Simple de Acceso a Objetos): se trata de un protocolo para intercambiar mensajes, basado en XML, y de extendido uso en Servicios Web.

UDDI (Universal Description Discovery and Integration): Este protocolo permite la publicación y localización de los servicios. Los directorios UDDI actúan como una guía telefónica de web services.

UML (Unified Modeling Language): lenguaje de modelado de sistemas de software.

W3C (World Wide Web Consortium): consorcio internacional que produce recomendaciones para la World Wide Web.

WSDL (Web Services Definition Service): protocolo que se encarga de describir un web service cuando es publicado.

XML (eXtensible Markup Language): es un metalenguaje extensible de etiquetas desarrollado por el W3C.




1. INTRODUCCIÓN

En el mundo de la información geográfica, se estuvo trabajando mucho tiempo sin contacto directo entre los diferentes sistemas de información geográfica. Con la implantación de internet y la evolución de las tecnologías de la información, los GIS siguieron aislados hasta que se comenzó a pensar en desarrollar otra forma diferente de trabajo. La información geográfica tenía un problema: era “pesada” y por tanto difícil de transmitir por las redes de comunicación. La interconexión de aplicaciones sólo se podía hacer dentro del mismo edificio mediante redes de área local. Otro problema era la incompatibilidad de sistemas. Para usar datos de una aplicación de diferente fabricante, casi siempre había que pasar por el formato DXF, con la consiguiente pérdida de información.

El Open Geospatial Consortium (1994) empezó a abordar esos problemas. Tardó tiempo, pero sus recomendaciones sobre arquitectura de sistemas, codificaciones, formatos y lenguajes empezaron a dar sus frutos acompañadas del desarrollo de las TIC. Y en el año 2002 ya se empezó en Europa a hablar del concepto IDE a alto nivel, incluso político. En otros países como EEUU, Canadá o Australia se comenzó antes incluso.

Según Doug Nebert [2], responsable del Federal Geographic Data Committee (FGDC) durante mucho tiempo, una IDE es un mecanismo de transporte de datos espaciales y servicios, que necesita una puerta de entrada definida que permita conectar al productor de datos y al usuario con sus aplicaciones. Por tanto, es necesario definir unos interfaces transparentes que permitan conectar sistemas y aplicaciones con diferentes tecnologías.

Este asunto se tomó bastante en serio en Europa, y con la excusa, por decirlo de alguna forma, de las políticas medioambientales, se pusieron a trabajar un gran número de grupos de trabajo bajo el paraguas del Joint Research Center (JRC) para definir lo debería ser la Infraestructura de Datos Espaciales Europea (INSPIRE). En España, empezó a trabajar el grupo de trabajo de la Infraestructura de Datos Espaciales de España (IDEE) dependiente de la Comisión de Geomática del Consejo Superior Geográfico.

Para Max Craglia [3] del JRC, los componentes claves de una IDE son catálogos de los recursos disponibles, documentados de una manera estructurada a través de metadatos; las directivas de accesos y normas; y un conjunto de servicios para acceder y descargar los datos a nuestras aplicaciones GIS. Como se puede ver, no incluye a los datos entre estos componentes; y es que la producción de datos es algo que se da por hecho, se supone que todos los estados tienen información geográfica suficiente.

Las infraestructuras de datos espaciales están creadas para fomentar el uso de la información geográfica, para compartir datos y conocimiento en los sectores público y el privado, independientemente de la tecnología utilizada y con las máximas garantías de calidad. Para que funcionen las IDEs, se necesita internet como canal de transmisión, pero también es necesario unos protocolos de comunicación que permita a usuarios y a sistemas el acceso a los datos y a sus metadatos. Hacer que los sistemas sean interoperables.

El gobierno español aprobó en enero de 2010 un real decreto [7] para definir y regular el esquema nacional de interoperabilidad. En este texto, se




define la interoperabilidad como “la capacidad de los sistemas de información y de los procedimientos a los que éstos dan soporte, de compartir datos y posibilitar el intercambio de información y conocimiento entre ellos”. Además la considera necesaria “para la cooperación, el desarrollo, la integración y la prestación de servicios conjuntos por las Administraciones públicas; para la ejecución de las diversas políticas públicas; para la realización de diferentes principios y derechos; para la transferencia de tecnología y la reutilización de aplicaciones en beneficio de una mejor eficiencia; para la cooperación entre diferentes aplicaciones que habiliten nuevos servicios; todo ello facilitando el desarrollo de la administración electrónica y de la sociedad de la información”.

Por tanto, para hacer posible esa interoperabilidad, la tecnología ha creado los servicios web. Según el W3C (Consorcio World Wide Web), “los Servicios Web son un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web y que intercambian datos entre sí con el objetivo de ofrecer servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web. Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario”.

1.1. Los servicios en las Infraestructuras de Datos Espaciales

Cuando se utiliza internet, lo más normal es navegar entre páginas web, que usan en el lenguaje HTML con algún lenguaje de servidor (ASP, PHP, JSP, etc.) para acceso a bases de datos o conseguir páginas más dinámicas. Esta es la forma en que los humanos buscan, consultan e intercambian información a través de la red. Pero internet también se puede utilizar de una forma más transparente, en la que las personas no actúan, y son las máquinas las que se comunican entre sí. Cuando se entra en el visor de un geoportal, se pueden ver mapas de ese servidor, pero a veces el usuario sin darse cuenta, superpone una capa que está en un servidor de otro organismo. En ese caso, el geoportal en cuestión, sin que el usuario haga nada especial, llama a otro servidor y le pide la información para dibujar el mapa solicitado. Este es un caso sencillo de utilización de un servicio web entre dos sistemas sin que la persona tenga conocimiento de conexiones, protocolos o direcciones.

También es importante señalar que para INSPIRE todos los accesos a datos espaciales y metadatos, se deben producir a través de servicios de datos espaciales. Todos los servicios deben ser descritos por los metadatos de servicios, lo que permite a las personas y a las aplicaciones de software descubrirlos.

En el proceso de creación de las IDEs en España, se le dio mucha importancia a los metadatos y a los visores de los geoportales. Solo hubo un organismo que apostó fuertemente por los servicio, la Dirección General del Catastro, y ahora mismo son de los que mejor funcionan a nivel mundial. El resto de las organizaciones los fueron dejando o como mucho ponían en marcha un servicio de mapas (WMS). En estos momentos, la sociedad está demandando más servicios. Hay aplicaciones de valor añadido que son capaces de crear riqueza desarrollando productos basados en servicios web de otros organismos, y esto tiene que aumentar.




Los servicios de mapas o de visualización ya funcionan de forma regular. Cada vez hay más servicios de descargas, y se están empezando a poner en marcha los servicios de transformación o procesamiento. El desarrollo de estos últimos puede ser la clave para el uso de las IDEs como una potente herramienta de análisis y modelización. Un usuario podría llegar a usar un servicio de transformación de un geoportal noruego para procesar los datos de usos de suelo que pudiera coger del servicio de descarga de su región junto con el modelo digital de elevaciones de la NASA. Todavía tardará un poco de tiempo hasta que esto se pueda realizar, pero se está en camino de ello y la tecnología cada vez lo pone más fácil.

1.2. Descripción del proyecto

En este trabajo se va a analizar la situación actual de los servicios desde el punto de vista de las iniciativas legislativas, de las normas y especificaciones y de las aplicaciones de la industria, para proceder a implantarlos en una infraestructura de datos espaciales.

Para desarrollar el proyecto se han realizado las siguientes tareas:

• Estudio de la reglamentación INSPIRE: revisión del reglamento CE Nº 976/2009 para los servicios de red, el texto de la decisión 2009/442/CE sobre seguimiento e informe y el capítulo IV de la Directiva INPIRE (2007/2/CE) relativo a servicios en red.

• Identificación de las especificaciones del Open Geospatial Consortium sobre servicios web y su encuadramiento en la legislación de INSPIRE.

• Estudio de la presencia de los servicios SOAP en las infraestructuras de datos espaciales.

• Descripción de los metadatos definidos para identificar a los servicios de información geográfica.

• Evaluación y medida de la calidad de los servicios web.

• Estudio de software en el servidor: evaluación de los programas utilizados para poner en marcha los diferentes tipos de servicios web.

• Descripción de los tipos de aplicaciones cliente para geoservicios.

• Puesta en marcha de un servicio de visualización de mapas (WMS).

• Preparación de un manual básico de uso de geoservicios.

1.3. Cuestiones a resolver en el trabajo

Cuando una organización productora de datos espaciales va a poner en marcha una infraestructura de datos espaciales, o se va a sumar a otra de un nivel superior, necesita conocer los requerimientos que le exige la legislación, las herramientas que le puede proporcionar la industria y las experiencias que otros han tenido antes. Dentro de una IDE, uno de los componentes fundamentales son los servicios de información geográfica, que son esenciales para transportar la información desde el servidor al usuario.

Entre las cuestiones que se pretenden resolver en este trabajo, la principal es conocer si los requerimientos que exige la legislación europea en materia de




información geográfica con la directiva INSPIRE, a los organismos públicos productores de información geográfica, pueden ser atendidos con las especificaciones y productos que actualmente hay en el mercado.

Las otras cuestiones van a depender enormemente de la primera y se pueden enumerar de la siguiente forma:

• ¿Qué servicios tienen que está implementados en una IDE europea y cuando?

• ¿Qué requisitos de calidad deben mantener esos servicios?

• ¿Qué tecnología hay en la industria para construir servicios?

• ¿Cómo se pueden organizar los servicios en una IDE? ¿Qué metadatos deben tener?

• ¿Qué aplicaciones se pueden usar en la parte servidora? ¿Y en la parte cliente?

• ¿Cómo se configura un servicio?

1-1 Esquema de la estructura del proyecto.




2. SERVICIOS DE RED EN LA DIRECTIVA INSPIRE

En este capítulo se va a realizar el análisis de los servicios de red que impone la Directiva INSPIRE para las IDEs en Europa a partir de los textos aprobados y publicados, desde la propia directiva hasta los reglamentos y documentos elaborados por los “drafting teams” para definir las normas de ejecución.

En el texto de la directiva, los servicios son mencionados en el artículo 11, dentro del capítulo IV:

Servicios de red en la directiva INSPIRE (2007/2/CE, Cap IV, Art. 11)

1. Los Estados miembros establecerán y gestionarán una red con los siguientes servicios, orientados a los conjuntos de datos espaciales y servicios relacionados con ellos para los que se hubieran creado metadatos, de acuerdo con lo dispuesto en la presente Directiva:

servicios de localización que posibiliten la búsqueda de conjuntos de datos espaciales y servicios relacionados con ellos partiendo del contenido de los metadatos correspondientes, y que muestren el contenido de los metadatos;

servicios de visualización que permitan, como mínimo, mostrar, navegar, acercarse o alejarse mediante zoom, moverse o la superposición visual de los conjuntos de datos espaciales, así como mostrar los signos convencionales o cualquier contenido pertinente de metadatos;

servicios de descarga que permitan descargar copias de conjuntos de datos espaciales, o partes de ellos y, cuando sea posible, acceder directamente a ellos;

servicios de transformación, que permitan transformar los datos espaciales con vistas a lograr su interoperabilidad;

servicios que permitan el acceso a servicios de datos espaciales.

Estos servicios deberán tener en cuenta los requisitos pertinentes de los usuarios y ser fáciles de utilizar y de acceso al público, vía Internet o cualquier otra forma de telecomunicación.

2. A efectos de los servicios mencionados en el apartado 1, letra a), (localización) deberá aplicarse, como mínimo, la siguiente combinación de criterios de búsqueda:

• palabras clave; • clasificación de datos espaciales y servicios relacionados con ellos; • calidad y validez de los conjuntos de datos espaciales; • grado de conformidad con las normas de ejecución a que se refiere el

artículo 7, apartado 1 [1]; • localización geográfica; • condiciones que rigen el acceso y uso de los conjuntos y servicios d • e datos espaciales; • autoridades públicas responsables de la creación, gestión, mantenimiento

y distribución de los conjuntos y servicios de datos espaciales.

3. Los servicios de transformación citados en la letra d) del apartado 1 se combinarán con los demás servicios mencionados en dicho apartado de forma que puedan funcionar de acuerdo con las normas de ejecución a que se refiere el artículo 7, apartado 1.




De estos tres apartados del artículo, se puede extraer por un lado la clasificación que hace de los servicios, diferenciando cinco tipos (localización, visualización, descarga, transformación y acceso a otros servicios), que son los se utilizaran posteriormente para agrupar las especificaciones OGC y determinar los metadatos que deben llevar cada uno de los grupos. En el apartado segundo, se especifica la combinación de criterios para la búsqueda en los catálogos con los servicios de localización Y por último, se incide en cómo deben combinarse los servicios de transformación de datos para que la información sea interoperable, y se hace referencia a las normas de ejecución que son las que realmente van a desarrollar la normativa INPIRE (art. 7, apartado 1).

La definición de los servicios y su funcionamiento se estudia en el reglamento publicado posteriormente, y en un conjunto de documentos que se van a ver en este capítulo.

2.1. Normas de ejecución (Implementing Rules)

Para garantizar que las infraestructuras de datos espaciales de los Estados miembros sean compatibles y utilizables en un contexto de comunidad y transfronterizo, la Directiva exige que se adopten normas de ejecución (Implementing Rules, IR) de aplicación común en un número de áreas específicas:

• Metadatos

• Especificaciones de datos

• Servicios de red

• Compartir datos y servicios

• Seguimiento e informes

Para elaborar estas normas, se crearon unos equipos de trabajo llamados Drafting Teams (DTs o equipos de redacción) formados por grupos de expertos propuestos por los grupos de interés (SDIC) y los organismos que tienen el mandato legal de aplicar la directiva (LMO), y seleccionados por la Comisión.

El papel de estos equipos es analizar y revisar el material de referencia proporcionado para su tema, con el fin de elaborar el proyecto de Reglamento de ejecución que demanda INSPIRE y proporcionar recomendaciones para el equipo de consolidación en caso de problemas o conflictos con las especificaciones técnicas.

En este estudio, se va a analizar la norma de ejecución que se refiere a los servicios en red mediante el reglamento elaborado a tal efecto (Network Services, 976/2009), ya que es el que determina las características que deben tener los geoservicios para cumplir con INSPIRE. También se analizará en parte el reglamento de Metadatos (1205/2008) para extraer la información necesaria para catalogar los servicios.

Estos equipos han generado muchos documentos de todo tipo antes de llegar a la publicación del citado reglamento. Como fruto de su trabajo, se dispone de normas de ejecución para cada tipo de servicio, guías técnicas, recomendaciones, estudios sobre el estado del arte, etc.




2.2. Reglamento 976/2009 sobre Servicios de Red

Se trata de un reglamento (976/2009) formado por cinco artículos muy cortos y tres anexos. El primer anexo trata sobre los criterios para evaluar la calidad de los servicios, el segundo sobre los servicios de localización (búsqueda en catálogos de metadatos) y el tercero sobre los servicios de visualización. Adicionalmente, ya se dispone de un borrador para determinar los requisitos de los servicios de descarga y transformación (Draft COMMISSION REGULATION amending Regulation (EC) No 976/2009 as regards download services and transformation services) desde el 14 de diciembre de 2009.

Aunque este añadido al reglamento no esté aprobado todavía, en este trabajo, vamos a considerarlo como definitivo, pues las variaciones serán mínimas. Modifica ligeramente el texto del reglamento 976/2009 en cuanto al articulado y al anexo I, y añade dos nuevos anexos, el IV sobre los servicios de descarga y el V para los servicios de transformación.

En los considerandos iniciales del reglamento de servicios de red hace referencia a la obligación de los Estados Miembros de la UE de implantar y hacer operativa una red de servicios orientados a los conjuntos y servicios de datos espaciales. Recuerda que hay que garantizar la compatibilidad y la utilización de esos servicios, y para ello, se deben establecer unas especificaciones técnicas y unos criterios mínimos de rendimiento de los servicios.

Por tanto, el objetivo es que se conceda a las autoridades públicas y a terceros la posibilidad técnica de conectar sus conjuntos de datos y servicios espaciales con los servicios de red. Esto implica que se tienen que establecer unos requisitos adecuados que deben cumplir los servicios que se pongan en marcha dentro de las infraestructuras de datos espaciales.

Servicios de red en el Reglamento (CE) Nº 976/2009

El presente Reglamento determina los requisitos para el establecimiento y mantenimiento de los servicios de red previstos en el artículo 11, apartado 1, de la Directiva 2007/2/CE (en lo sucesivo denominados «los servicios de red»), así como las obligaciones relacionadas con la disponibilidad de esos servicios por parte de las autoridades públicas de los Estados miembros y terceros, con arreglo al artículo 12 de esa Directiva.

Definiciones:

capacidad operativa inicial: la facultad de un servicio de red de ofrecer toda su funcionalidad sin garantizar la calidad de servicio, de conformidad con las normas establecidas en el anexo I del presente Reglamento, o sin garantizar el acceso al servicio a todos los usuarios a través del geoportal Inspire; rendimiento: el nivel mínimo a partir del cual se considera alcanzado un objetivo y la rapidez con la que puede atenderse una petición dentro de un servicio de red Inspire; capacidad: el número máximo de peticiones simultáneas de servicio atendidas con un rendimiento garantizado; disponibilidad: la probabilidad de que el servicio de red esté disponible; tiempo de respuesta: el tiempo que tarda la operación en devolver el primer byte del resultado, medido en la ubicación del servicio del Estado miembro; petición de servicio: una única petición de una sola operación de un servicio de red Inspire; elemento de metadatos Inspire: un elemento de metadatos incluido en la parte B del anexo del Reglamento (CE) n o 1205/2008; publicar: la operación de insertar, suprimir




En el segundo artículo, aparece una serie de definiciones de los conceptos que se ponen en juego cuando hablamos de servicios. En los siguientes artículos se hace referencia a los diferentes anexos que hay para cada tipo de servicio.

Para evaluar la calidad de los distintos servicios (QoS), en el primer anexo de este reglamento, se fijan los criterios que se van a tener en cuenta. Estos se clasifican en relación con la capacidad, el rendimiento y la disponibilidad. Para medir estos criterios, no se tendrán en cuenta los servicios de terceros que estén

conectados y que puedan producir alteraciones debidas a efectos de cascada.

El rendimiento se evaluará midiendo el tiempo que tarda el servicio en enviar una respuesta al peticionario. La capacidad se medirá en el número mínimo de peticiones simultáneas atendidas por un servicio. Y la disponibilidad fija el porcentaje sobre el tiempo total que un servicio tiene que estar funcionando.

En el último apartado de este capítulo se detallan los criterios y se describen las exigencias de INSPIRE para determinar la calidad en el funcionamiento de los servicios de red.

o actualizar elementos de metadatos Inspire de recursos en el servicio de localización; lenguaje natural: un lenguaje hablado, escrito o por señas, usado por los seres humanos para la comunicación general; recogida: la operación de extraer de un servicio de localización elementos de metadatos Inspire de recursos y permitir la creación, supresión o actualización de esos metadatos en el servicio de localización de destino; capa: la unidad básica de información geográfica que puede solicitarse a un servidor como un mapa, de acuerdo con la norma EN ISO 19128.

2.3. Arquitectura de servicios de red

Cuando una organización productora de datos espaciales quiere compartir esos su información entre los distintos niveles de la misma, o con otros usuarios externos a ella, necesita establecer una serie de servicios para que accedan a los datos y se los remitan a los destinatarios finales. El funcionamiento de esos servicios de red tiene que responder a una arquitectura que permita interactuar a clientes y servidores sin una intervención manual repetitiva. Y esta arquitectura funcionará como un interfaz que facilita la interoperabilidad entre organizaciones para compartir la información geográfica.

Para la puesta en marcha de las infraestructuras de datos espaciales que dicta INSPIRE, el equipo de trabajo o “drafting team” de servicios de red (DT NS) propone una arquitectura que permite la comunicación entre las diferentes IDEs, y entre estas y los usuarios. La parte central de esta arquitectura es el denominado bus de servicios, a través del cual se establece la conexión entre aplicaciones y geoportales con los servicios, y lo que es más importante, entre los diferentes servicios entre sí.




2-1 Esquema de la arquitectura técnica de INSPIRE ([22] Network Services Architecture).

Es importante hacer notar que INSPIRE asume que el acceso a cualquier tipo de dato o metadato debe realizarse a través de servicios web (servicios de red). Estos tienen que ser descritos por las descripciones de servicios (metadatos de servicio que formarán parte de los metadatos de la IDE) permitiendo a las personas y a las aplicaciones de software localizar instancias específicas de cada servicio e invocarlos o llamarlo de una forma automática.

En el esquema anterior se puede ver representado el diseño conceptual de la arquitectura propuesta para el funcionamiento de una IDE conforme a INSPIRE. Dispone de tres capas: la primera de aplicaciones, la segunda de servicios y la tercera de datos y metadatos.

En la capa de aplicaciones se sitúan los geoportales, las aplicaciones cliente y cualquier otro software que pueda o necesite acceder a datos espaciales. Desde esta capa no se ven los datos directamente, sino que hay una capa de servicios intermedia que permite que las aplicaciones cliente accedan a los datos mediante una serie de especificaciones y protocolos estándares. Los servicios extraen los datos que también se encuentran almacenados siguiendo unas especificaciones para datos espaciales que en estos momentos están en proceso de redacción.

El propósito final de esta arquitectura es que mediante el bus de servicios, un usuario o una máquina, a través de una aplicación cliente, acceda a los datos de cualquier infraestructura de la misma forma, siempre que esta cumpla las especificaciones de datos y servicios. Es decir, alcanzar la máxima interoperabilidad posible compartiendo la información entre todos los niveles de una organización, y entre la organización y otros usuarios externos.

La arquitectura que propone INSPIRE está diseñada como una arquitectura orientada a servicios (SOA, service-oriented architecture), en la que los diferentes usuarios y proveedores exponen y consumen servicios mediante el bus de servicios. Este tipo de arquitectura se suele utilizar para la creación de sistemas altamente escalables y brinda una forma bien definida de exposición e invocación




de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

Para poner en práctica esta estructura, INSPIRE aconseja utilizar los estándares existentes en el mercado, y en el caso de las infraestructuras de datos espaciales, el rumbo lo marca el Open Geospatial Consortium (OGC). Los servicios web definidos por OGC soportan una mezcla de protocolos y enlaces con diferentes tecnologías. Las combinaciones más usuales son KVP (key-ValuePairs) enviado con HTTP/GET, XML enviado vía HTTP/POST y SOAP enviado mediante HTTP/GET, además de las combinaciones entre estos protocolos. Además, el W3C (World Wide Web Consortium) recomienda que se debería utilizar SOAP como protocolo para la mensajería de los servicios web.

Todos los servicios INSPIRE deberían utilizar una única tecnología de enlace estándar para todos los tipos de servicio. Con el fin de agilizar la integración y la aplicación, así como de obtener un beneficio máximo de los servicios ofrecidos, hay que evitar una mezcla de tecnologías. Por esta razón, habida cuenta de todos los requisitos, oportunidades y riesgos, se escoge SOAP como protocolo de comunicación y enlace predeterminado para todos los servicios. Para definir la aproximación de SOAP a INSPIRE, el DT de Servicios de Red promovió la elaboración de un estudio en detalle para ver si el enfoque que ofrece SOAP es viable para los geoservicios de INSPIRE (Technical Report: INSPIRE NETWORK SERVICES SOAP Framework [21] ).

2.4. Descripción de los servicios previstos en INSPIRE

Los servicios de red son necesarios para compartir los datos espaciales entre los diferentes niveles de una organización y entre las distintas IDEs. Esta interoperabilidad sólo se puede conseguir si se utilizan las mismas normas y mismos protocolos por todos los proveedores de datos y todos los usuarios de la información geográfica. El vehículo para alcanzar esa información, son los servicios a través de la red, en este caso internet, que permiten buscar, ver, modificar y descargar datos espaciales, así como acceder a otros servicios de datos espaciales y de comercio electrónico.

La directiva INSPIRE se clasifican en cinco tipos e se impone para cada uno una forma de trabajar y unos resultados a obtener:

• Servicios de localización, para buscar datos y servicios.

• Servicios de visualización, para ver mapas.

• Servicios de descarga, para obtener objetos geográficos.

• Servicios de transformación, para procesar datos espaciales.

• Servicios que permitan el acceso a servicios de datos espaciales, para encadenar diferentes servicios.

En las diferentes normas de ejecución para cada tipo de servicio y en los documentos orientativos elaborados por los equipos especializados, se encuentra la definición de las funcionalidades y operaciones de cada tipo de servicio.

2.4.1. Localización

En INSPIRE quedan definidos como los servicios “que posibiliten la búsqueda de conjuntos de datos espaciales y servicios relacionados con ellos partiendo del




contenido de los metadatos correspondientes, y que muestren el contenido de los metadatos”. En algunos textos los podemos encontrar con el nombre de servicios de descubrimiento, debido a la traducción directa desde el idioma inglés, en el que se denominan “discovery services”. En este trabajo se usará el nombre de servicios de localización que es como aparecen en la traducción oficial del reglamento de servicios 976/2009.

En todos los documentos que se pueden encontrar sobre la puesta en marcha de la iniciativa INSPIRE, estos son siempre los servicios que se nombran en primer lugar y a los que se dan más importancia. Incluso en la propia directiva, en el artículo 11.2, se detallan los criterio mínimos de búsqueda que se deben cumplir para que su funcionamiento sea correcto. El resto de los servicios se mencionan de una forma más escueta, y se empiezan a detallar en el reglamento.

Los servicios de localización deben hacer posible la búsqueda de conjuntos de datos y servicios, basándose en el contenido de sus correspondientes metadatos, y en la visualización de los mismos. Dentro de la comunidad geográfica, a lo largo del tiempo, se han asignado diferentes nombres a los instrumentos utilizados para la localización de datos espaciales y servicios a partir de las propiedades de los metadatos, como por ejemplo, Servicios de Catálogo, Directorios de Datos Espaciales, Clearinghouse, Catálogos Geográficos o Servicios de Localización de Geodatos. Para INSPIRE el nombre utilizado es el de Servicios de Localización.

Se necesitan estos servicios para buscar la información espacial, evaluarla y poder utilizarla, de forma que sólo con la información contenida en los metadatos, se puedan hacer esas operaciones. Por tanto, la definición del contenido de los metadatos es fundamental para que estos servicios funcione n correctamente, y este trabajo se asigna a otro drafting team (DT) que sólo se encargará de construir la implementación de los mismos. El funcionamiento del servicio de localización se describe en los documentos elaborados por el DT de Servicios de Red teniendo en cuenta el trabajo del otro equipo de redacción de metadatos. No se llega a definir una aplicación cliente, simplemente se desarrolla el entorno en el que se debe mover todo el funcionamiento de la localización de información, y para ello, se establecen cuatro funciones que se deben implementar para cumplir lo dictado en la directiva INSPIRE. Esas funciones son las siguientes:

• Get Discovery Service Metadata: proporciona al usuario toda la información necesaria sobre el servicio (proveedor, contenido, calidad, lenguaje de consulta, restricciones de acceso,...) y describe las posibilidades de este para permitir que una aplicación cliente pueda utilizar el servicio (lista de operaciones soportadas).

• Discover Metadata: permite recuperar todos los metadatos o un conjunto predefinido de ellos (seleccionados mediante una consulta) desde el lugar en donde se encuentran almacenados.

• Link Discovery Service: Esta función permite dar a conocer la disponibilidad de un servicio de localización de recursos a través del servicio de localización de la IDE, manteniendo los metadatos de recursos en la ubicación del propietario.

• Publish Metadata: esta operación permite crear, borrar o modificar metadatos de los elementos almacenados.




Los nombres se han dejado en inglés para no confundir los conceptos en las traducciones. Para realizar estas operaciones, en la propia directiva se establece un conjunto mínimo de criterios de búsqueda que permitirán localizar la información existente en una IDE a través del conjunto de metadatos disponible.

En el reglamento de servicios de red, detalla esos criterios de búsqueda y fija las operaciones que se deben garantizar para que el servicio funcione correctamente. La tabla siguiente es la que aparece en el anexo II del reglamento y detalla los elementos de metadatos que deben utilizarse para especificar los criterios de búsqueda:

Criterios mínimos de búsqueda Elementos de metadatos INSPIRE

Palabras clave Palabra clave (Keyword) Clasificación de datos y servicios espaciales (para conjuntos de datos espaciales y series de conjuntos de datos espaciales)

Categoría temática (Topic category)

Clasificación de datos y servicios espaciales (para servicios de datos espaciales)

Tipo de servicio de datos espaciales (Spatial data service type)

Calidad y validez de los conjuntos de datos espaciales

Linaje (Lineage)

Calidad y validez de los conjuntos de datos espaciales

Resolución espacial (Spatial resolution)

Grado de conformidad con las normas de ejecución a que se refiere el artículo 7, apartado 1, de la Directiva 2007/2/CE

Especificación (Specification)

Grado de conformidad con las normas de ejecución a que se refiere el artículo 7, apartado 1, de la Directiva 2007/2/CE

Grado de conformidad (Degree)

Localización geográfica Rectángulo geográfico envolvente (Geographic bounding box)

Condiciones que rigen el acceso a los conjuntos y servicios de datos espaciales, así como su utilización

Condiciones aplicables al acceso y al uso (Conditions applying to access and use)

Condiciones que rigen el acceso a los conjuntos y servicios de datos espaciales, así como su utilización

Restricciones de acceso público (Limitations on public access)

Autoridades públicas responsables del establecimiento, gestión, mantenimiento y distribución de los conjuntos y servicios de datos espaciales

Parte responsable (Responsible party)

Autoridades públicas responsables del establecimiento, gestión, mantenimiento y distribución de los conjuntos y servicios de datos espaciales

Función de la parte responsable (Responsible party role)

2-1 Criterios de búsqueda para el servicio de localización ([17] Reglamento 976/2009 INSPIRE).

Además de los elementos de esta lista, también estarán disponibles como criterios de búsqueda los siguientes elementos o series de elementos de metadatos INSPIRE:

• título del recurso (Resource Title);




• resumen del recurso (Resource Abstract);

• tipo de recurso (Resource type);

• identificador único del recurso (Unique Resource Identifier);

• referencia temporal (Temporal Reference).

Cuando se requiera combinar diferentes criterios para hacer la búsqueda, se permitirá la utilización de operadores lógicos y de comparación. También se dispondrá del operador espacial Intersects para localizar recursos basándose en la localización geográfica.

Como se puede ver en estos criterios, es necesario que los metadatos que se almacenen sobre la información geográfica sean lo más completo posible, de esta manera la localización de la información será más rápida y sencilla, ya que los criterios de búsqueda son muy completos.

2.4.2. Visualización

Como se puede suponer, los servicios de visualización son los más populares y extendidos en todas las IDEs. No se concibe una infraestructura sin su servicio de mapas, como también se le conoce. En la directiva se exige que toda la información como mínimo, pueda ser visualizada, excepto aquellos temas que estén bajo protección de seguridad o bajo secreto.

La visualización se puede hacer mediante una aplicación que haga de visor directo sobre la información geográfica almacenada, pero si se quiere que hay una mínima interoperabilidad, se debe desarrollar una serie de servicios que recubran esta información y, que permitan a las personas y a las máquinas visualizar los datos geográficos.

La definición que aporta la norma de ejecución (todavía en borrador, versión 3.0) para servicios de visualización es que se trata de “es un servicio de web que proporciona una representación visual de la información geográfica y temática mediante la creación de una imagen de estos datos usando reglas de representación y haciendo posible, como mínimo para una aplicación cliente, las operaciones de mostrar, navegar, zoom in/out, pan o superponer visualmente conjuntos de datos espaciales y mostrar la información de la leyenda, y cualquier contenido relevante de metadatos. Los conjuntos de datos pertenecen a los temas tratados por los anexos de la Directiva INSPIRE”.

Para este servicio, se han definido tres operaciones obligatorias, Get View Service Metadata, Get Map y Link View Service La primera proporciona toda la información necesaria sobre el servicio y describe todas sus posibilidades (Capabilities). La segunda devuelve un mapa con la información geográfica y temática procedente de los conjuntos de datos espaciales disponibles; y ese mapa es una imagen referenciada espacialmente. Y la tercera, permite a una autoridad pública o a un tercero dar a conocer un servicio de visualización para la mostrar sus recursos a través de este servicio de una IDE, manteniendo, al mismo tiempo, la capacidad de visualización en la ubicación de la autoridad pública o del tercero.

Hay otra operación, llamada Get Feature Information, que aparece en los documentos de las normas de ejecución y en las guías de implementación, pero luego no se ha citado en el reglamento de Servicios de Red. Se define como opcional, y como se verá en el siguiente capítulo, realmente se suele emplear en




los servicios de visualización. Esta operación devuelve la información sobre el elemento (feature) visualizado en el mapa señalado por un punto por el usuario.

Se exige que el servicio soporte al menos uno de los formatos gráficos PNG (Portable Network Graphics) o GIF (Graphics Interchange Format) sin compresión. Y respecto al sistema de referencia de coordenadas, se pide que las distintas capas a visualizar, utilicen un único sistema de referencia, y este debe estar definido según lo indicado en el Anexo I, punto 1 de la directiva. Lo que se pretende en este caso es que las capas que se visualicen superpuestas, tengan el mismo sistema de referencia de coordenadas para evitar la confusión del usuario.

El procedimiento para trabajar con este servicio es similar al anterior de localización, y como se verá a los siguientes. Siempre hay una operación para conocer el servicio y sus posibilidades o capacidades (traducción directa de Capabilities), luego una vez que se conoce lo que puede hacer el servicio, se solicita la información, en este caso el mapa, en el anterior, los metadatos. La tercera operación (Link View Service) está preparada para el enlace o encadenamiento de los diferentes servicios.

2-2 Esquema de funcionamiento del servicio de visualización ([23] Technical Guidance View

Services)

En el gráfico anterior, extraído del anexo E del documento [23] “Technical Guidance View Services v2.0”, se muestran las interacciones entre los diferentes actores que participan en el funcionamiento de un servicio de visualización. En un lado está el que publica la información (Publisher), que no tiene porqué ser el mismo que administra y gestiona el servicio (Administrator). El servicio de visualización (View service) está atento a las peticiones del usuario (Viewer). Este pregunta por las características del servicio (request capabilities), y una vez que tiene los metadatos del servicio y sabe lo que puede pedir, hace la petición del mapa (request map). Luego sobre este mapa se puede pedir información (request feature info).

2.4.3. Descarga

Para INSPIRE es muy importante que la información se pueda localizar y visualizar, como se ha visto en los dos apartados anteriores, pero también da un gran valor al uso y reutilización de la información espacial, y eso sólo se puede hacer mediante el servicio de descarga. Para muchos autores es uno de los




mayores logros de la directiva. En ella se definen como los servicios que “permiten descargar copias de conjuntos de datos espaciales, o partes de ellos y, cuando sea posible, acceder directamente a ellos”.

Los servicios de descarga son los mecanismos que permiten que los usuarios pueden tener acceso al contenido completo de la información capturada y transformada por los organismos productores, dentro de sus conjuntos de datos conforme a las especificaciones de los temas definidos para ellos. Se accede a los datos de forma que se pueden visualizar, editar, integrar con otros datos y analizar en profundidad con todas las posibilidades que permite la tecnología GIS.

Si en el servicio de visualización, el cliente recibía una imagen, con el servicio de descarga lo que recupera es un objeto o conjunto de objetos con sus atributos asociados. La tipología de estos objetos está definida en la [18] norma de ejecución sobre la interoperabilidad de conjuntos de datos espaciales y servicios (Implementing Rules on interoperability of spatial data sets and services) que todavía se encuentra en forma de borrador para publicarse en el DOUE.

Otro aspecto importante que hay que contemplar en este tipo de servicio es el concepto de “query”, que se puede definir como un conjunto de predicados (expresiones que pueden ser validadas para ser verdaderas o falsas) expresados en una sintaxis conocida, utilizada para identificar un subconjunto de recursos cuyas propiedades satisfacen a estos predicados. Es necesario utilizar la query para extraer la información que se necesita, pues a diferencia del servicio de visualización, en el que el tamaño del resultado dependía de la dimensión de la ventana solicitada, en este servicio, además de solicitar una zona (Bounding Box), la extracción variará de tamaño en función del número de objetos que se solicitan.

Hay dos formas de acceder a este servicio: una es mediante acceso directo y otra a través de conjuntos de datos predefinidos. En el primer caso, se consiguen los datos a partir de una query que extrae una parte o subconjunto del conjunto de datos espaciales; y en el segundo caso, se accede a todo el paquete de datos que previamente se ha colocado en el servicio como un todo.

Las operaciones que debe tener implementadas este servicio se describen en la siguiente tabla de acuerdo con la redacción del borrador de de adenda al reglamento de servicios de red [20] (Draft Commission Regulation amending Regulation 976/2009 as regards download services and transformation services) que difiere en alguna operación con lo redactado en la norma de ejecución [27] (Draft Implementing Rules for Download Services). Se ha usado el borrador de reglamento por ser el último documento publicado para este servicio.

Operación Descripción

Get Download Service Metadata

Proporciona toda la información necesaria acerca del servicio, los conjuntos de datos espaciales disponibles y describe las capacidades de servicio.

Get Spatial Data Set Permite la recuperación de un conjunto de datos espaciales.

Describe Spatial Data Set

Devuelve la descripción de todos los tipos de objetos espaciales contenidos en el conjunto de datos.

Link Download Service

Permite la declaración, por parte de una autoridad pública o una tercera parte, de la disponibilidad de un servicio para la descarga de conjuntos de datos






Operación Descripción espaciales o, cuando sea posible, objetos espaciales, a través servicio de la IDE, manteniendo la capacidad de descarga en la autoridad pública o enla ubicación del tercero.

Si el servicio permite el acceso directo, además debe implementar dos operaciones más:

Operación Descripción Get Spatial Object Esta operación permite la recuperación de objetos

espaciales basado en una consulta (query). Define Query Define la consulta que se va a usar para extraer el

subconjunto de datos con la operación Get Spatial Object.

Describe Spatial Object Type

Esta operación devuelve la descripción de los tipos de objetos espaciales especificados.

Para la operación Get Spatial Object, se han definido también una serie de criterios para realizar las búsquedas y selección de objetos sobre el conjunto completo de datos. Los criterios se pueden combinar utilizando operadores lógicos y de comparación, y son los siguientes:

• Identificador único de recursos del conjunto de datos espaciales.

• Todos los atributos relevantes y relaciones entre datos espaciales.

• Rectángulo geográfico envolvente.

• Tema.

2.4.4. Transformación

Este tipo de servicios es diferente a los que se han visto hasta ahora. Si los tres anteriores accedían a datos o metadatos y obtenían como resultado unos registros, una imagen de un mapa o unos objetos, este servicio se tiene que combinar con alguno de los anteriores para conseguir unos datos y posteriormente aplicarles una transformación, que debe quedar muy bien definida en los metadatos del servicio. El usuario debe buscar a través del servicio de localización las características de este servicio para conocer que transformaciones están disponibles y como se tienen que aplicar. La directiva los define como los servicios que “permiten transformar los datos espaciales con vistas a lograr su interoperabilidad”.

Para implementar este servicio se han definido tres operaciones:

Operación Descripción Get Transformation Service Metadata

Proporciona toda la información necesaria acerca del servicio y describe sus capacidades, incluyendo las categorías de transformación compatibles, las transformaciones soportadas, los tipos de datos de entrada aceptados, la definición del modelo e idiomas soportados.

Transform Realiza el proceso real de transformación.




Operación Descripción Link Transformation Service

Permite la declaración de disponibilidad de un servicio de transformación para transformar un conjunto de datos espaciales a través de servicios de este tipo en una IDE, manteniendo la capacidad de transformación en la autoridad pública o en la ubicación de terceros.

Como se comentaba al principio, este servicio, debido a su naturaleza, tiene una arquitectura muy diferente a los servicios anteriores, ya que se comporta como un servicio intermedio entre la aplicación usuaria y, normalmente, un servicio de descarga. Incluso en muchos casos, el servicio de transformación se puede añadir al servicio de descarga en forma de una nueva operación o funcionalidad.

2-3 Servicio de transformación combinado con el servicio de descarga (modo directo) [28]

En los gráficos anteriores se puede observar una visión conceptual del proceso de funcionamiento del servicio de transformación combinado con el servicio de descarga de formar diferentes. En el de la izquierda, la aplicación cliente hace una solicitud de transformación al servicio de transformación, y este le devuelve una “query” para que solicite los datos al servicio de descarga. La aplicación cliente solicita los datos, y una vez que los tiene, se los envía al servicio de transformación para que se los devuelva transformados. Sin embargo, en el gráfico de la derecha, es el servicio de descarga el que hace la solicitud al servicio de transformación y la aplicación cliente solo se tiene que preocupar de pedir los datos.

Hasta el momento, los grupos de trabajo de INSPIRE sólo han definido dos categorías de servicios de transformación: de sistema de referencia de coordenadas y de modelo de datos. Se ha elaborado guías de aplicación para estos tipos y en el futuro se irán añadiendo muchos más tipos de transformación.

2.4.5. Acceso a servicios

En la directiva aparece un quinto tipo de servicio que denomina Servicio de acceso a servicios y lo define como aquellos servicios que “permitan el acceso a servicios de datos espaciales”, sin aclarar nada más. Sin embargo, en el documento [22] “INSPIRE Network Services Architecture v3.0” describe algo más el cometido de estos servicios y los denomina Servicio de Invocación de Servicios de Datos Espaciales.


Este servicio permite definir los datos de entrada, de salida y el flujo de trabajo o servicio que combina otra serie de servicios. Es decir, un servicio de este tipo permite diseñar un flujo de trabajo encadenando diferentes servicios y estableciendo que datos se ponen en juego. Se puede invocar un servicio o un conjunto de ellos encadenados, de manera síncrona o asíncrona, a través de un motor que dirige todo llamado motor de flujo de trabajo. El encadenamiento de servicios se expresa en una notación estándar, por ejemplo XML, que puede ser reconocida por múltiples programa comerciales o de código abierto.

Una de las utilidades de este servicio es su conexión con servicios de comercio electrónico para cuando el acceso a los datos espaciales esté limitado por el pago de una tasa o derechos. Si un usuario necesita descargarse unas capas de información por las que el proveedor solicita un pago, se debe establecer un servicio de descarga encadenado a un servicio de pasarela de pago de forma que el usuario, aunque tenga que pagar dinero, pueda hacer la descarga de la forma más rápida y sencilla. En este caso, se enlazarían ambos servicios de forma que para el usuario fuera como uno único.

2.5. Calidad de los servicios

La puesta en marcha de servicios en una IDE no solo tiene seguir unas especificaciones y unas normas para conseguir la interoperabilidad, sino que tiene que cumplir unos criterios mínimos de calidad. En la definición de la arquitectura de INSPIRE, en el documento [22] Network Services Architecture (Version 3.0) editado en septiembre de 2008, se proponen unos requerimientos mínimos de calidad a cumplir por los geoservicios para que estos, y la infraestructura a la que pertenecen, sean considerados que cumplen con los preceptos que impone la directiva.

La tabla siguiente muestra los requerimientos de calidad de servicio (QoS) propuestos en ese documento:

Tipo criterio Requerimientos Definición

Rendimiento Rendimiento Representa el tiempo de respuesta de un servicio manteniendo la capacidad mínima fijada.

Rendimiento Capacidad Número de peticiones en un intervalo determinado de tiempo.

Mantenimiento de servicio Disponibilidad

Probabilidad de que el servicio es funcionando correctamente.

Mantenimiento de servicio Fiabilidad

Representa la capacidad de un servicio web para realizar sus funciones, en las condiciones indicadas, en un intervalo de tiempo especificado.

Otros QoS Seguridad

Es el aspecto de la calidad del servicio web que proporciona confidencialidad y no rechazo, mediante la autenticación de las partes implicadas, los mensajes cifrados y el control de acceso.




Otros QoS Conformidad

Representa el aspecto de calidad de un servicio que es conforme a las reglas, a las normas y a los acuerdos establecidos a nivel de servicio.

2-2 Requerimientos de calidad de servicio de INSPIRE [22].

En el reglamento 976/2009 y en la adenda a este, que está en fase de borrador, se concreta más y se fijan las magnitudes para establecer unos mínimos a cumplir. También fija la fecha en la estos servicios tienen que estar funcionando y cumpliendo esos criterios mínimos. Solamente considera tres requerimientos: rendimiento, capacidad y disponibilidad. Los dos primeros varían en función del tipo de servicio y el tercero, la disponibilidad, es fija para todos los servicios con un valor del 99% del tiempo total.

En la siguiente tabla se resumen los criterios de calidad de servicio (QoS) que especifican los anexos del reglamento para cada uno de los tipos de servicio:

Tipo servicio Rendimiento Capacidad Fecha funcionamiento

Tiempo

respuesta Peticiones simult. Capacidad Capacidad Situación normal operativa inicial plena

Localización 3 seg 30/seg 09/05/2011 09/11/2011 Visualización 5 seg 20/seg 09/05/2011 09/11/2011 Descarga 10 seg 10/seg 18 meses 24 meses Transformación 5/seg 19 meses 24 meses Acceso a servicios

2-3 Resumen de los requerimientos de calidad (elaboración propia)

El rendimiento se evaluará midiendo el tiempo que tarda el servicio en enviar una respuesta al peticionario. Para una situación normal, este tiempo deberá ser inferior a 3 segundos para los servicios de localización, de 5 segundos para los servicios de visualización (Get Map Request, para una imagen de 470 Kb)y 10 segundos para la descarga. La situación normal hace referencia al momento en que no hay una demanda máxima, que debe ser un 90% del tiempo total.

La capacidad se medirá por el número mínimo de peticiones simultáneas atendidas por un servicio. En un servicio de localización será de 30 por segundo, de 20 por segundo en el de visualización, 10 por segundo en el de descarga y 5 por segundo para el servicio de transformación, siempre y cuando se cumpla la QoS de rendimiento.

En cuanto a la fecha de entrada en funcionamiento, el reglamento impone dos fechas diferentes para cada tipo de servicio: la primera determina el día que debe estar funcionando el servicio con una capacidad operativa inicial, es decir, sin cumplir estos criterios de rendimiento, y la segunda fija la fecha a partir de la cual los servicios tienen que cumplir con los criterios mínimos exigidos en la tabla anterior.

Se puede ver que para el servicio de transformación no se ha ficjado ningún dato de rendimiento, y esto se deberá a que en este tipo de servicios es muy variado el funcionamiento que puede adquirir, y por tanto, es muy atrevido poner una magnitud.




2.6. Relación de documentos INSPIRE Network Services:

En esta sección se va a hacer una breve descripción de lso documentos generados por los equipos de redacción que la Unión Europea ha puesto a trabajar en el DT Network Services. Hay una gran cantidad de guías, informes, recomendaciones y documentos en general, y además, en diferentes estados de redacción. Se van a enumerar y describir los que se pueden considerar más importantes, que son los que se han utilizado para la redacción de este capítulo. Para conseguir esta documentación, se tiene que acceder al portal de INSPIRE a través del siguiente enlace: http://inspire.jrc.ec.europa.eu/index.cfm/pageid/5.

Como documentos legislativos, están la directiva y el reglamento de servicios de red aprobado en octubre de 2009. La adenda a este reglamento, que le aumenta la descripción de las características de los servicios de descarga y transformación, está en fase de borrador final (diciembre 2009) y tiene que estar a punto de ser aprobado.

Tras estos documentos, aparecen en la relación los documentos orientativos, o guías de aplicación, que definen como implementar cada uno de los servicios de acuerdo a las normas de ejecución de cada uno de los servicios.

• View Service Technical Guidance (version 2.0) 28.07.2009.

• Discovery Services Technical Guidance (versión 2.0) 23.07.2009 .

• Download Services Technical Guidance Draft (version 2.0) 25.09.2009.

• Coordinate Transformation Services Technical Guidance Draft 15.03.2010.

El documento referido a los servicios de descarga está todavía en forma de borrador, y en cuanto a los servicios de transformación, sólo hay un borrador para la transformación de coordenadas. Para la transformación de modelos de datos todavía no se tiene un documento de este tipo, hay algunos informes que se enumeraran más adelante. Por ahora, no hay más servicios de los que se vayan a definir estas guias de implementación, pero eso no quiere decir que en un futuro se preparen más documentos de este tipo.

Para cada uno de los tipos de servicios, excepto para los servicios de acceso a servicios de datos espaciales, hay un documento que refleja las normas de ejecución definidas y los requerimientos técnicos que tienen que seguir los servicios que sean de ese tipo para ser conformes a INSPIRE. Los cuatro están todavía en forma de borrador y son los siguientes:

• Draft Implementing Rules for Download Services (Version 3.0) 25/09/2009.

• Draft Implementing Rules for Transformation Services (Version 3.0) 07/09/2009.

• Draft Implementing Rule: Discovery Services (Version 3.0) 11/04/2008.

• Draft Implementing Rule: View Services (Version 3.0) 11/04/2008.

El resto de documentos es muy variado, unos están elaborados por los equipos de redacción, y otros son estudios realizados por profesionales o empresas externas a la Unión Europea, y que ha sido contratadas por esta para desarrollar algún tema, estudiar la situación de un determinado segmento del mercado o hacer unas pruebas de funcionamiento de algún aspecto relativo a la



http://inspire.jrc.ec.europa.eu/index.cfm/pageid/5


arquitectura general de funcionamiento de INSPIRE. A continuación se describen alguno de ellos:

• Network Services Architecture (Version 3.0) 30/09/2008 [22]. Este documento describe la parte de la arquitectura correspondiente a los servicios en red que posteriormente se tendrá en cuenta el la definición de las normas de ejecución para cada tipo de servicio.

• Technical Report: INSPIRE NETWORK SERVICES SOAP Framework 16.12.2008 [21] Proporciona una definición y realiza una propuesta sobre la posibilidad de utilizar el protocolo SOAP como un estándar en los servicios de red. Tiene en cuenta la situación actual de los componentes que entran en funcionamiento en un servicio y recomienda la solución más estable.

• Network Services Perforance Guidelines (versión 1.0) 13-12-2007. Establece unas líneas a seguir para la definición de los criterios mínimos de rendimiento para ser incluidos en las normas de ejecución de servicios de red.

• INSPIRE Technical Arquitecture – Overview (versión 1.2) 05-11-2007. Ofrece una primera descripción de la arquitectura técnica de INSPIRE, y enumera los elementos requeridos, las relaciones entre ellos y los responsables de cada acción.

• Development of Technical Guidance for the INSPIRE Transformation Network Service – State of Art analysis (versión 2.0) 10-06-2010. Es un informe que documenta las tecnologías punteras y los estándares existentes en cuanto a la trasformación de modelos de datos para su implementación como servicio.

2.7. Sumario

En este capítulo se ha analizado y resumido la documentación generada por los grupos de trabajo redactores del apartado de INSPIRE relativo a servicios de red. Se ha extraído de la directiva las necesidades que impone, y que amplia en el reglamento de servicios de red. Después se han estudiado las normas de ejecución para cada tipo de servicio y su funcionamiento en la arquitectura propuesta, para acabar analizando los requisitos de calidad fijados para controlar su rendimiento.

Hay una gran variedad de textos con una estructura compleja que no hace sencillo su estudio. Aunque en el portal de INSPIRE aparece una relación ordenada en el tiempo, los titulo de los documentos no son homogéneos y a veces no se sabe a qué categoría pertenece o si ya ha sido sustituido por una versión superior. Lo más importante es que hay bastante documentación y los problemas y las soluciones se estudian desde diferentes puntos de vista, lo que enriquece la discusión.

Al estudiar los documentos más antiguos, se pueden ver que las diferencias respecto a los nuevos, son fruto de la evolución de la tecnología y, sobre todo, del cambio en la forma de concebir la construcción de INSPIRE, que se va produciendo por el desarrollo de los diferentes temas que componen la infraestructura.




Respecto a los servicios, los redactores han avanzado bastante en la definición de los servicios de localización y visualización, ya que la directiva les otorga una mayor preponderancia que al resto. Aunque en los documentos técnicos, sobre todo cuando se comenta la arquitectura de funcionamiento, el servicio de descarga es el más considerado.

Para el servicio de transformación, se están preparando especificaciones para dos operaciones que se suelen utilizar con mucha frecuencia: cambio de sistema de referencia de coordenadas y modificación de modelos de datos. Sin embargo, hay muchas más posibilidades de diferentes servicios que encajarían en este apartado y que según se puede leer en algún documento, en el futuro se tratarán.

El servicio de acceso a servicios de datos espaciales está muy poco desarrollado y en ningún documento aclara si va a ser objeto de estudio o se va a dejar como un tipo de servicio que va a cubrir al resto de los servicios que no se pueden clasificar en los cuatro anteriores.

Uno de los aspectos más importantes de este capítulo es el apartado de medición de la calidad de los servicios que tiene que ofrecer una IDE. Para cada tipo de servicio se exigen unos criterios mínimos que debe cumplir en cuanto al rendimiento, la capacidad y la disponibilidad del mismo.




3. ESPECIFICACIONES RELACIONADAS CON SERVICIOS DEL OPEN GEOSPATIAL CONSORTIUM

El Open Geospatial Consortium (OGC), antes Open GIS Consortium, es una organización internacional que agrupa a más de 400 empresas, agencias gubernamentales y universidades para participar en un proceso de consenso con el objetivo de desarrollar estándares públicamente disponibles dentro del campo de la información geográfica. La iniciativa partió de la propia industria de desarrollo de software gráfico en 1994, y luego se fueron añadiendo empresas productoras de datos y agencias gubernamentales relacionadas con la cartografía y la información geográfica.

Los estándares OpenGIS® fomentan el uso de soluciones interoperables que posibilitan la web geográfica, los servicios inalámbricos y los productos basados en localización, en definitiva, incorporar las tecnologías de la información a la producción y uso de la cartografía. Las especificaciones permiten a los desarrolladores de la tecnología hacer que la información espacial compleja y sus servicios, sean accesibles y útiles con todo tipo de aplicaciones y usuarios. Su desarrollo se realiza mediante un proceso de consenso único apoyado por la industria, los gobiernos y los miembros académicos para hacer posible que las tecnologías de geoprocesamiento puedan interoperar en su máxima expresión.

En el proceso de creación o definición de un estándar para aplicar en el mercado, se producen una gran cantidad de documentos con diferentes nombres. Según el estado de definición del estándar, el documento puede cambiar de nombre y de versión. Pero hay otros documentos que son recomendaciones, consejos, informes o trabajos obtenidos tras una serie de pruebas. El listado de los más importantes es el siguiente:

• OpenGIS® Specifications: documentos técnicos que detallan interfaces o codificación entre componentes de software. Contienen los detalles necesarios para su implementación.

• Abstract Specification: proporcionan los fundamentos conceptuales y los modelos de referencia para las actividades de desarrollo de especificaciones de OGC.

• OGC Reference Model (ORM): proporcionan un marco de referencia para los diferentes trabajos de OGC. Describe la base de normas centrándose en las relaciones entre los documentos de especificaciones de OpenGIS.

• Best Practices Documents: documentos de debate y buenas prácticas sobre la implementación y el uso de especificaciones de OGC. Representan la posición oficial de OGC ante la adopción de las normas.

• Discussion Papers: su objetivo es crear discusión en la industria de la información geoespacial sobre un tema especifico que se ha tratado en los diferentes grupos de trabajo que se forman para la elaboración de estándares. No representan ninguna posición oficial de OGC.

• White Papers: documentos que describen posturas oficiales de OGC ante determinados temas.



http://www.opengeospatial.org/pressroom/papers


Este organismo ha elaborado una gran cantidad de especificaciones, y buena parte de ellas están destinadas a la definición de servicios web para favorecer la interoperabilidad entre productores y usuarios de información geográfica. Este trabajo se va a centrar en las especificaciones de servicios que forman parte de las infraestructuras de datos espaciales.

Si OGC representa la vía de facto para definir un estándar, el camino oficial lo determina la Organización Internacional para la Estandarización ISO, avalada por las organizaciones gubernamentales, mediante su comité técnico TC211. Esta vía es más lenta y finaliza cuando los diferentes países asumen esas normas. Sin embargo, el trabajo del Open Geospatial Consortium es mucho más ágil; elabora las especificaciones fomentando el consenso entre diferentes grupos de interés o consorcios, y con su uso en el tiempo, se convierten en normas de obligado cumplimiento.

[12] Conviene destacar la actividad que desarrolla el Consejo Consultivo Conjunto ISO/TC211-OGC. Éste grupo está codirigido por miembros del TC211 y OGC con el objetivo coordinar los esfuerzos normativos de ambos organismos. Como resultado se consigue establecer una única normativa de referencia en información geográfica digital, ISO 19100, recogiendo los fundamentos de las especificaciones OGC y asegurando la coordinación entre ambos ámbitos de estandarización.

3.1. Especificaciones OGC para servicios web

Las especificaciones que el Open Geospatial Consortium ha elaborado para definir los servicios web y los complementos a estos, se van a clasificar en este apartado según los tipos de servicios que define la directiva INSPIRE. No se va a estudiar a fondo cada una de las especificaciones, ya que están perfectamente descritas en los documentos correspondientes, sino que el objetivo es comentar como obedecen a los requerimientos que INSPIRE determina en sus diferentes reglamentos y documentos adicionales. También se van a comentar las versiones de estos servicios que se utilizan en estos momentos.

3.1.1. Servicios de localización

Este tipo de servicios está destinado a la consulta y edición de catálogos, y para realizar esas tareas, OGC tiene una especificación llamada Especificación de Servicios de Catálogo CSW.

Soporta la publicación y la consulta de metadatos de la información geográfica y los servicios, no sólo de la organización que mantiene el catálogo, sino que se permite el acceso a otros catálogos distribuidos en la red. Por tanto, tiene dos partes, una que permite la publicación de metadatos y otra que permite la consulta distribuida.

A continuación se resume la especificación CSW a partir del documento OGC que la describe [33] Catalogue Services Specification v 2.0.2 descargado del portal de OGC.

Por definición, los servicios de catálogo admiten la posibilidad de publicar y buscar colecciones de información descriptiva (metadatos) sobre datos, servicios y otros objetos relacionados. Los metadatos en los catálogos describen las características de los recursos, y pueden ser consultados y presentados para su evaluación y procesamiento, tanto por software como por las personas. Estos




servicios son necesarios para descubrir la información existente y llegar a los recursos de información registrados dentro de una comunidad de información como es una IDE.

3-1 Esquema de funcionamiento del servicio de localización. [33]

En el esquema anterior se puede ver el funcionamiento de este servicio para localizar un recurso (datos o servicio). La aplicación cliente necesita buscar un recurso, para ello pregunta al servicio de catálogo, que puede buscar en el catalogo de su organización o en otros catálogos que tiene enlazados. El servicio responde ofreciendo una serie (de 0 a n) de metadatos de los recursos que cumplen la condición exigida. La aplicación cliente muestra el listado de recursos y el usuario elige el que quiere visualizar, y tiene la posibilidad de enlazar con el recurso.

Las operaciones permitidas por este servicio son las siguientes, indicando entre paréntesis, si son obligatorias (M) o opcionales (O):

• GetCapabilities (M): Informa sobre sus características y posibilidades (fichero de capacidades).

• DescribeRecord (O): Permite al cliente consultar la estructura de los registros. Previamente deben crearse metadatos de los tipos de recursos.

• GetDomain (O): Permite a los usuarios consultar los valores permitidos de un parámetro o propiedad determinados.

• GetRecords (M): Cuando los usuarios soliciten la ejecución de una consulta al catálogo mediante una query que busca entre los metadatos catalogados, y devuelve un conjunto de resultados que contiene referencias (entre 0 y n) a todos los recursos registrados que satisfacen los requisitos de la consulta.

• GetRecordsByld (M): Permite a los usuarios obtener metadatos de recursos previamente referenciados en un conjunto de resultados previos o de una lista de identificadores de recursos.

• HarvestRecord (O): Permite que un usuario solicite, que un servicio de catálogo, intente obtener un recurso de una ubicación específica y, opcionalmente, crear una o más entradas para ese recurso.

• Transaction (O): Permite a los clientes solicitar acciones de inserción, actualización y borrado sobre una instancia del catálogo.




Cuando se quiere consultar un catálogo, la aplicación cliente utiliza la operación GetCapabilities para conocer los detalles del servicio. Si no conoce la estructura del sistema de almacenamiento, utiliza la segunda operación DescribeRecord. Con la operación GetDomain, se puede comprobar los posibles valores que puede tomar un campo determinado, y para realizar la consulta, se usa GetRecord. Esta operación da una lista de los registros que cumplen la query que se envía dentro de la operación. Con GetRecordsByld se obtiene los metadatos del registro seleccionado de la lista.

Para utilizar este servicio, es necesario tener una aplicación cliente que pueda conectar con el servidor para ejecutar las operaciones arriba definidas. En la siguiente imagen se muestra la aplicación cliente disponible en el geoportal de la IDEE (http://www.idee.es/csw/client.html), que es bastante clara en el uso de las diferentes operaciones de la especificación. Quizá es demasiado compleja para un usuario poco especializado, pero en este caso, para explicar el funcionamiento de un servicio CSW es perfecta.

3-2 Imagen del cliente de consulta de metadatos de la IDEE (www.idee.es).

Comparando esta especificación con los requerimientos de INSPIRE, se encuentran algunas diferencias, de forma que, si un servicio cumple con esta especificación estrictamente, no es conforme con lo que predica la directiva. En el documento [24] Discovery Services Technical Guidance de INSPIRE, se pueden encontrar las diferencias entre las exigencias de INSPIRE y lo que ofrece la especificación CSW v2.0.2 que se tomó como base para la redacción del perfil de aplicación CSW ISO AP. La comparación entre ambas se puede observar en el siguiente cuadro:



http://www.idee.es/csw/client.html


3-1 Comparación de las operaciones requeridas por INSPIRE con las que ofrece la especificación

CSW ISO AP [24]

Se ve que hay diferencias en la operación LinkDiscoveryService, que como tal no existe en OGC, es necesario combinar dos operaciones para obtener algo parecido. También en la operación PublishMetadata hay discrepancias, pues OGC distingue entre tratamiento de catálogos de sólo-lectura, con CSW y catálogos de lectura-escritura que necesitan la versión transaccional de CSW, llamada CSWT que es una especificación derivada de CSW.

Aunque no cumple completamente los requerimientos, los documentos técnicos de la norma de ejecución del servicio de localización, recomiendan el uso de esta especificación para la puesta en marcha de este servicio.

3.1.2. Servicios de visualización

Dentro de los servicios de visualización, OGC dispone de dos especificaciones, la más conocida y utilizada que es la correspondiente al servicio Web Map Service (WMS), y otra mucho más reciente, que ha surgido por la necesidad de ganar en velocidad a la hora de visualizar un mapa, la especificación Web Map Tile Service (WMTS).

La directiva INSPIRE en su artículo 5.4 dice que para definir las normas de ejecución se tendrán en cuenta los estándares internacionales existentes, además de los requerimientos de los usuarios. En el caso de estos servicios, OGC elaboró un estándar que luego a pasado a ser norma ISO (19128:2005(E) WMS 1.3.0) y que es la que se ha identificado como más adecuada para la implantación del servicio de visualización y por tanto, se recomienda en el documento [23] View Service Technical Guidance (versión 2.0). Eso no quiere decir que no se puedan utilizar otros estándares, siempre que cumplan los requerimientos de las normas de ejecución para servicios de visualización.

Otros dos estándares de facto de OGC se asocian a esta especificación para ayudar a la representación cartográfica. Son el Styled Layer Descriptor (SLD) que genera unos estilos predefinidos para aplicar las capas que se visualizan con WMS, y la especificación Symbology Encoding Implementation que define un lenguaje para definir estilos de capas y coberturas.

Web Map Service (WMS)

La especificación [34] Web Map Service (WMS) proporciona un sencillo interfaz HTTP para solicitar imágenes de mapas georreferenciados a las bases de datos geoespaciales distribuidas en una red. Una solicitud WMS define las capas




de información y el área de interés para ser procesado. La respuesta a la solicitud es una o más imágenes de mapa georreferenciado (JPEG, PNG, etc.) que pueden mostrarse en una aplicación de explorador o de escritorio. La interfaz también admite la posibilidad de especificar si las imágenes devueltas deben ser transparentes, por lo que se pueden combinar capas desde varios servidores o no.

3-2 Comparación de las operaciones requeridas por INSPIRE para el servicio de visualización con la

norma ISO para WMS [23].

Si se comparan las operaciones que demanda INSPIRE con las que ofrece esta especificación, se ve que coincidan casi perfectamente. La operación LinkViewService se asigna al servicio de localización de metadatos como otra operación. La otra operación que soporta WMS, GetFeatureInfo, no se pide en los documentos de INSPIRE aunque es bastante utilizada.

Hay otros detalles que hacen que WMS no se ajuste estrictamente, y para cumplir con lo demandado en Europa, se deba hacer una extensión de la especificación o un perfil de la misma. Uno de ellos es el enlace mediante el protocolo SOAP, que se demanda en el documento que describe la arquitectura de INSPIRE, y que la norma ISO WMS todavía no lo tiene definido.

En el siguiente esquema se detallan en lenguaje UML las tres operaciones que permite WMS con sus parámetros:

3-3 Esquema UML de las operaciones del Web Map Service [34].

Web Map Tile Service (WMTS)

Según el documento de OGC llamado [35] Web Map Tile Service Specification v1.0.0, esta especificación está basada en los trabajos previos realizados para desarrollar un servicio de visualización de mapas de alto rendimiento y escalable, que mejorara las prestaciones del WMS elaborado por OGC. WMTS está inspirado en la especificación de OSGeo llamada Tile Map Service (http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification). También se consideraron otras iniciativas similares, tales como Google Maps y OnEarth de la NASA. Este estándar OGC incluye tanto recursos y como procedimientos en un esfuerzo por armonizar este estándar de interfaz con la especificación de OSGeo.

Mientras WMS se centra en la representación de mapas personalizados y es una solución ideal para visualizar datos dinámicos o con estilos predefinidos (combinados con el estándar Style Layer Descriptor (SLD)), la especificación WMTS se centra en el rendimiento del servicio, y por tanto, proporciona mapas



http://www.opengeospatial.org/standards/wmts


estáticos, que se han dividido en partes (azulejos o baldosas), que permiten al servidor enviarlos más rápidamente al cliente, pues son pequeños y ya los tiene preparados. En el WMS, el servidor construye al momento cada mapa que se solicita, y en el caso del WMTS, ya se tiene el mapa preparado dividido en baldosas y con varios niveles de resolución.

3-4 Explicación del funcionamiento de la división en baldosas del WMTS [35].

En la imagen anterior se puede observar la división que se hace de cada capa y las capas adicionales que se generan con menos resolución para enviar al cliente cuando este solicite un mapa de gran extensión.

Dispone tres operaciones definidas, similares al WMS: GetCapabilities, GetTile (en vez de GetMap) y GetFeatureInfo.

3.1.3. Servicios de descargas

Como se ha visto en el apartado 2.4.3, el servicio de descarga definido por INSPIRE está dividió en dos tipos: acceso directo a través de query y acceso a conjuntos de datos predefinidos.

Entonces para el servicio de descarga de acceso directo, recomienda la utilización de la especificación Web Feature Service (WFS), que además se ha convertido en norma ISO/DIS 19142. Y para la elaboración de las querys, la especificación Filter Encodig (FE) tal y como se especifica en la ISO/DIS 19143. Ambas versiones han sido desarrolladas por OGC y el comité ISO/TC211 en colaboración, y son las últimas especificaciones de este tipo en materia de servicios de descarga.

Web Feature Service (WFS)

En el documento [25] Download Services Technical Guidance Draft (version 2.0) se puede ver un análisis de la conformidad del servicio demandado por INSPIRE con las normas ISO/DIS 19142/19143. Para el servicio de descarga de acceso directo, que en cierta medida es el más avanzado de los dos tipos que existen, el nivel de cumplimiento es muy alto, como se puede ver en la tabla siguiente:

Operación INSPIRE Operación ISO/DIS

Get Download Service Metadata GetCapabilities (WFS). Get Spatial Data Set GetFeature (WFS).




Describe Spatial Data Set DescribeFeatureType (WFS). Define Query Query elaborada según Filter Encoding

(FE) y pasada como parámetro. Link Download Service Publish Metadata (desde el servicio de

localización). 3-3 Comparación de las operaciones requeridas por INSPIRE para el servicio de descagas con la

norma ISO para WFS [25].

Hay una operación ISO/DIS llamada CreateStoreQuery, que almacena querys que cumplen FE, que recomienda que se implante aunque no se solicite entre las operaciones INSPIRE. Se trata de tener almacenadas una lista de consultas para luego ser llamadas como parámetros en una petición del servicio de descarga.

En la norma ISO/DIS recomendada no se habla nada de cómo utilizar el servicio de descarga sobre un conjunto de datos predefinidos. Se supone que será mediante una descarga sencilla de ficheros, pero no se comenta nada en los documentos.

El proceso de funcionamiento del servicio de descarga con WFS es el siguiente:

1. La aplicación cliente pide al servidor un fichero con las posibilidades o capacidades del servicio. Dicho fichero contiene una descripción de todas las operaciones que admite el WFS y una lista de todos los tipos de fenómenos (features) que pueden servir.

2. La aplicación cliente (opcionalmente) realiza una solicitud al servicio para que le facilite la definición de uno o más fenómenos o tipos de elemento que el WFS puede servir.

3. Basándose en la definición de los tipos de fenómeno que ha recibido, la aplicación cliente genera una solicitud de descarga de una serie de fenómenos.

4. La solicitud se envía al servidor web que aloja el servicio WFS.

5. Se invoca al WFS para leer y atender la solicitud.

6. Cuando el WFS ha completado el procesamiento de la solicitud, generará un informe de estado y envía todo al cliente. En caso de que se produzca un error, el informe de estado indicará este hecho.

Los datos descargados con este servicio van codificados en forma de GML (Geographic Markup Language) y todas las peticiones se hacen mediante XML.

Web Coverage Service

Esta es otra especificación OGC destinada a la descarga de información geográfica en forma de coberturas, es decir, información geográfica asociada a posiciones con valores de atributo dentro de un espacio limitado (mapa ráster, imagen de satélite, modelo digital de elevaciones, etc.). Si el servicio WMS devuelve un mapa estático aunque elaborado sobre datos dinámicos, el servicio WCS retorna el mapa con la semántica original. Los dos servicios envían al cliente un mapa en formato ráster, pero el WCS descarga los datos asociados a cada uno de los píxeles.

Si se compara con el WFS, la diferencia es que el WCS descarga fenómenos que representan una distribución continua en el espacio y el WFS envía los




objetos geográficos que representan una distribución discreta, es decir, son elemento vectoriales que ocupa una parte pequeña del espacia, aunque luego envuelvan la misma información.

Las operaciones que ofrece este servicio son:

• GetCapabilities:•Metadatos del servicio y de las coberturas que ofrece

• DescribeCoverage: Descripción detallada de una o varias coberturas.

• GetCoverage: Obtener una cobertura o parte de ella.

Como se puede ver, son las mismas operaciones que para el servicio WFS, per en vez de descargar fenómenos u objetos geográficos, descarga coberturas con un funcionamiento muy similar.

3.1.4. Servicios de transformación

Así como en los tres tipos de servicios anteriores había una correspondencia entre lo demandado por INSPIRE y las especificación existente, en este caso es más complicado. En primer lugar se trata de un servicio más abierto, pues no tiene muy definido lo que debe hacer, se han determinado una serie de operaciones teóricas, en las que pueden tener cabida un gran número de servicios muy diferentes.

Como se comentó en el capitulo anterior, este servicio está destinado a transformar datos que obtenemos con los otros servicios, fundamentalmente con el servicio de descarga. En cuanto a su aplicación práctica, el DT de servicio de red [28] (Draft Implementing Rules for Transformation Services) ha identificado dos tipos de servicios de transformación hasta la fecha: transformación de coordenadas, para el que se ha redactado un borrados de guía técnica [26], y transformación de modelo de datos, que está en una fase menos avanzada y sólo se dispone de un informe que analiza su implantación [19].

Sin embargo, OGC ha avanzado más y ha definido una especificación llamada Web Processing Service (WPS) que está preparada para hacer gran parte de lo que demanda INPIRE y algunas cosas más.

Web Processing Service (WPS)

Esta especificación comenzó llamándose Geoprocessing Service, pero la coincidencia del acrónimo con GPS, hizo que se cambiara el nombre al que conocemos ahora.

La especificación WPS define una interfaz estandarizada que facilita la publicación de procesos geoespaciales, y además permite que estos sean fácilmente localizables para que las aplicaciones cliente se puedan conectar a ella.

Un servicio WPS puede ser configurado para ofrecer cualquier tipo de funcionalidad GIS a los usuarios a través de la red, incluyendo cálculos pre-programados y/o modelos de computación que operan con los datos georreferenciados, que pueden estar en la red (a través de otros servicios) o en el mismo servidor que aloja el servicio.

Las operaciones que tiene programadas son:




• GetCapabilities: se obtiene una lista de las operaciones disponibles en el servicio.

• DescribeProcess: permite a los clientes del WPS preguntar y recibir una descripción de uno o más de los procesos que pueden ser ejecutados con la operación Execute. Esta descripción incluye los parámetros de entrada y los formatos de entrada y salida, y puede ser usada para construir automáticamente un interfaz que capture los valores de los parámetros.

• Execute: hace que las aplicaciones cliente puedan ejecutar un proceso específico implementado por el servidor, usando los valores de los parámetros de entrada proporcionados y recibiendo los valores de salida.

Esta especificación, según el documento que la describe [37] (OGC 05-007r7, OpenGIS® Web Processing Service Implementation Specification), proporciona mecanismos para identificar los datos georreferenciados requeridos para el cálculo, iniciar el cálculo y gestionar la salida hacia la aplicación cliente. Este servicio de procesamiento está dirigido a procesar tanto datos vectoriales como ráster o mapa de bits.

Está diseñada para permitir que un proveedor de servicios exponga un servicio con un proceso accesible vía web, como por ejemplo una intersección de polígonos, de manera que permite a la aplicación cliente enviar los datos de entrada y ejecutar el proceso sin necesidad de tener conocimientos especializados sobre cómo se realiza la operación. Al plantear una interfaz genérica, el servicio WPS se puede encadenar con otros servicio para exotraer los datos o para ofrecer los resultados.

3.1.5. Complementos a servicios

Como se ha visto en los servicios explicados en este capítulo, se necesitan algunas especificaciones que complementen a esos servicios y que les ayuden a definir mejor su funcionamiento. Se trata de especificar lenguajes para definir consultas o procesos, forma de detallar las simbologías o determinar el marco general de funcionamiento de los servicios OGC. Por tanto, no son especificaciones de nuevos servicios, pero si son necesarios para que la interoperabilidad sea máxima entre todos los actores implicados en el manejo de la información geográfica. En este apartado se van a relacionar y describir de una manera sencilla este tipo de complementos.

El primero es el OGC Web Services Common Standard, que no es una especificación, ni un complemento exactamente, sino que se trata de la definición del marco general común a los principales servicios de OGC. En el documento [32] publicado se especifican muchos de los aspectos que son, o deberían ser, comunes a casi todas las normas de implementación de servicios de OGC (OWS). Estos aspectos comunes son, principalmente, algunos de los parámetros y las estructuras de datos utilizadas en las operaciones de solicitud y respuesta por parte de los servicios. Por supuesto, luego cada implementación estándar debe especificar los aspectos adicionales de su interfaz, especificando todos los parámetros adicionales y estructuras de datos necesarias para cada servicio en particular.

El objetivo de esta especificación general es reducir los trabajos que se necesitan para redactar un estándar, acortar el tamaño de los documentos,




incrementar la interoperabilidad entre servicios y, sobre todo, reducir el trabajo para los desarrolladores que tieen que hacer aplicaciones cliente o servidoras.

Uno de los complemento más utilizados es el Styled Layer Descriptor (SLD) [38] que es un perfil de aplicación de la especificación Web Map Service (WMS). El servicio WMS admite la posibilidad de que un proveedor de información especifique las opciones de estilo básicas que se le deberían asignar a la información geográfica que está sirviendo. El servicio puede indicar estas opciones de representación pero de una forma muy simple, sólo con un nombre de estilo. El usuario no puede conocer el aspecto que tendrá el mapa y no puede definir sus propias reglas de estilo. El SLD surgió para tener una simbología con un lenguaje común en la definición de estos estilos entre aplicaciones cliente y servidores de datos.

La definición de este lenguaje, que es XML, para codificar la simbología se realiza en otro documento que acompaña a la especificación del SLD llamado Symbology Encoding (SE) [39], que permite cambiar la representación de los datos que aparecen tras un WMS. También se puede utilizar con WFS y WCS, por tanto, también admite la simbolización de coberturas.

Otra especificación que complementa a un servicio es el [41] Filter Encoding (FE) que desarrolla una codificación XML para la consulta en catálogos (CQL, Catalog Query Languaje) y que como se comentaba en el capítulo anterior, se utiliza con WFS para realizar la consulta de los datos a descargar. También se utiliza con otro tipo de servicios, puesto que muchos servicios ofrecen a la aplicación cliente un catálogo para buscar la información que está disponible o sus recursos.

Para el procesado de coberturas, hay otra especificación que desarrolla un lenguaje que permite que el procesamiento de datos ráster multidimensionales obtenidos de los servicios web o de los sensores, y se llama [42] Web Coverage Processing Service Language Interface Standard (WCPS).

Otra especificación que complementa a un servicio es la llamada [40] Web Map Context Documents (WMC) que los que hace es definir un tipo de documento o fichero en lenguaje XML que guarda la configuración de las capas que están cargadas en un cliente WMS. Es una utilidad que permite diferentes usos como:

• Disponer de una serie de vistas por defecto, que permiten al usuario arrancar su visor con una configuración predeterminada.

• Almacenar el resultado de una sesión, y continuarla posteriormente.

• Puede almacenar no sólo la configuración actual, sino también obtener información adicional acerca de cada capa (por ejemplo, los estilos disponibles, formatos, sistemas de referencia de coordenadas, etc.). Así se evita tener que consultar al servidor de mapas de nuevo cada vez que el usuario selecciona una capa que ya había cargado.

• Salvar una sesión de un usuario y enviársela a otro para que pueda arrancar en el mismo contexto.




3.2. Interacción entre datos y servicios

Después de explicar los servicios y especificaciones existentes, se va a pasar a describir el funcionamiento de los mismos en el entorno de una IDE. Para ello se ha escogido un diagrama elaborado por Doug Nebert (FGDC) y que se ha encontrado en un trabajo titulado [4] Development and Status of the U.S. National Spatial Data Infrastructure: Concepts and Components. Para este apartado, se ha traducido y se han actualizado alguno de sus componentes de forma que refleje el estado actual de las especificaciones.

3-5 Diagrama de relación entre objetos para la arquitectura de una IDE (Adaptado y traducido de [4]

D. Nebert)

En el diagrama se pueden ver tres zonas diferenciadas por el color de fondo y que se corresponden con cada una de las partes fundamentales de una IDE:

• Los servidores con los datos y los servicios que acceden a ellos (fondo rosado). Esta capa se podría dividir en dos, una con los datos y otra con los servicios, como aparece en los textos de muchos autores.

• El nodo o punto de acceso a la IDE con las aplicaciones cliente propias (fondo azul). En esta parte se encuentran los componentes que pueden utilizar los usuarios y/o las aplicaciones cliente para acceder a los datos.

• La capa de usuarios (fondo naranja), en la que se ven representadas las dos formas de interactuar con los datos y servicios: aplicaciones web y aplicaciones cliente.

Los datos están representados por los elementos en color marrón, y formados por la información espacial y sus metadatos. Dentro de los metadatos,




se almacenan la información relativa a datos espaciales, a servicios y a los registros de otros metadatos.

En los recuadros de color azul se sitúan los servicios (localización, visualización y descarga) que recubren los datos haciendo una pasarela para los usuarios. En este esquema no está representado el servicio de transformación, ya que es el más reciente y todavía su uso es limitado.

En la zona de fondo azul, se pueden encontrar una serie de aplicaciones preparadas para facilitar a los usuarios la utilización de los servicios: el geoportal, la consulta de catálogo, la consulta de nomenclátor (toponimia y direcciones) y el acceso al registro de metadatos externos El acceso desde estas aplicaciones a los datos se hace a través de los servicios que usan las especificaciones (en color azul oscuro) que se han visto en este capítulo.

La zona naranja representa el acceso de los usuarios, que pueden entrar a través de un navegador web al geoportal o directamente a los servicios a través de aplicaciones cliente de escritorio (GvSIG, ArcGIS, Geomedia, etc.).

3.3. Sumario

En este capítulo se ha realizado una revisión de las especificaciones existentes en el mercado referentes a servicios de información geográfica elaboradas fundamentalmente por el Open Geospatial Consortium, y con la ayuda en algún caso de ISO/TC211 y OSGeo.

Para alcanzar la máxima interoperabilidad entre sistemas es imprescindible el uso de normas y estándares. Se podría construir una IDE que cumpliera INSPIRE pero que no alcanzara una completa interoperabilidad con otras IDEs, pues cumplir las normas de ejecución de servicios de red (IR NS) no obliga a usar estándares, sólo los recomienda. Por eso es importante remarcar los beneficios que reporta el uso de los estándares OGC:

• Reducir costes, pues aumenta el ciclo de vida de la tecnología, al no ser dependientes de una solución determinada.

• Permite a los usuarios elegir la aplicación que más se ajuste a sus necesidades, pues sabe que va a cumplir unos estándares y no va a tener problemas de acceder a los datos.

• Ayuda a introducir requisitos de usuario en el proceso de normalización. Organizaciones como OGC promueven el consenso entre los usuarios y los proveedores de tecnología para cooperar en el avance de nuevas normas.

• Inserción rápida de nueva tecnología en el mercado pues los costes de adaptación son reducidos y el usuario puede comenzar a utilizarla con mayor rapidez.

Aún así, después de lo visto sobre las especificaciones OGC, quedan algunas lagunas que cubrir para alcanzar los requerimientos de INSPIRE. En la especificación CSW, no todas las operaciones son se ajustan a lo que se pide en la norma de ejecución de servicios de localización. Son detalles, pero a una organización que necesite poner en marcha un servicio de catálogo de metadatos, no le basta con comprar una aplicación del mercado y configurarla, sino que tiene que añadirle algunos retoques.




Con el servicio de visualización, el cumplimiento es prácticamente completo, los detalles que faltan se podría decir que son de adorno. No pasa lo mismo en el servicio de descarga, pues de las dos opciones que pide INSPIRE, acceso directo y acceso a subconjuntos predefinidos, esta última no se adapta al WFS de OGC. Se prevé que en los próximos trabajos de la especificación, esta adecuación sea más perfecta.

En cuanto al servicio de transformación, el problema no viene por el estándar que es bastante completo, sino que parece que las demandas de INSPIRE no están muy bien definidas.

Respecto al servicio de acceso a servicios de datos espaciales, no se ha tratado en este capítulo, pues su definición es reducida y lo que realmente implica es el encadenamiento de otros tipos de servicios que si se han visto.

También se puede comentar que, aunque INSPIRE recomienda apoyarse en especificaciones y estándares existentes, los redactores de las normas de ejecución han exigido unos requerimientos por encima de lo que hay en el mercado. Esto va a hacer muy difícil a las organizaciones el cumplir lo demandado en la directiva.

A continuación se relacionan los servicios con las versiones que soportan cada uno de ellos:

Tipo de Servicio

Versión Espacio de Nombres Elemento Raíz del

Capabilities

WMS

1.0.0

WMT_MS_Capabilities

1.0.7 WMT_MS_Capabilities



1.3.0 WMS_Capabilities

WCS

1.0.0 xmlns="http://www.opengis.net/wcs" wcs:WCS_Capabilities

1.1.0

xmlns:wcs="http://www.opengis.net/wcs/1.1" xmlns:owcs="http://www.opengis.net/wcs/1.1/ows" Capabilities

1.1 xmlns:wcs="http://www.opengis.net/wcs/1.1" Capabilities

WFS 1.0.0 xmlns:wfs="http://www.opengis.net/wfs" WFS_Capabilities

1.1.0 xmlns:wfs="http://www.opengis.net/wfs" wfs:WFS_Capabilities

CSW

2.0.0 xmlns:csw="http://www.opengis.net/cat/csw" Capabilities

2.0.1 xmlns:csw="http://www.opengis.net/cat/csw" Capabilities

2.0.2 xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" Capabilities

WPS 1.0.0 xmlns:wps="http://www.opengis.net/wps/1.0.0" wps:Capabilities 3-4 Tabla con los servicios OGC y sus versiones soportadas, extraída del documento de definición

de los Metadatos de servicio del GTIDEE [15].




4. SERVICIOS SOAP

La idea de introducir este capítulo en el trabajo está motivada por las posibilidades que ofrece el protocolo SOAP para crear todo tipo de servicios web. En el documento [22] que describe la arquitectura propuesta por INSPIRE, se recomienda el uso de este protocolo para recubrir los servicios, y así poder cumplir las exigencias de las normas de ejecución para cada tipo de servicio.

La definición de SOAP (Simple Object Access Protocol, o Protocolo Simple de Acceso a Objetos) es sencilla, se trata de un protocolo para intercambiar mensajes, basado en XML, y de extendido uso en Servicios Web. Se propone resolver los problemas de falta de interoperabilidad entre las diferentes opciones que existen en el mercado para utilizar aplicaciones distribuidas con diversas tecnologías, tomando como base protocolos ya establecidos y con gran aceptación en Internet, como HTML y XML. Es por tanto independiente del sistema operativo y del lenguaje de programación que se utilice.

Dentro de las infraestructura de datos espaciales, están empezando a proliferar servicios de este tipo, que no suelen corresponderse con un estándar pero que si cumplen el objetivo primordial de su creación, la interoperabilidad. Por ejemplo, se puede diseñar un servicio de visualización que cumpla con los requisitos y las operaciones que exige la norma de ejecución de INSPIRE y que no sea el WMS.

En el documento antes mencionado [22] sobre la arquitectura de INSPIRE y en un informe técnico posterior, [21] INSPIRE NETWORK SERVICES SOAP Framework, se recomienda el uso de este protocolo y se pide que las especificaciones OGC empiecen a considerar en las siguientes versiones, un recubrimiento con SOAP para que pueden conseguir adaptarse mejor a los requerimientos marcados en las normas de ejecución.

Como complemento a SOAP, estos documentos recomiendan el uso del lenguaje WSDL (Web Services Description Language) para la descripción de los servicios web. Es decir, cuando una aplicación se conecta a un servicio web, puede leer el WSDL para conocer que funciones ofrece el servicio. Aportan una serie de de argumentos a favor del uso de SOAP/WSDL dentro de los servicios web:

• Los servicios SOAP se están convirtiendo en un estándar de las tecnologías de la información, y por tanto, soporta reglas de implementación sostenibles.

• Un servicio SOAP garantiza integración más armónica y completa en los diferentes entornos de desarrollo.

• Los servicios SOAP proporcionan una integración directa y completa con otros entornos de servicios web.

• Los servicios SOAP tienen la posibilidad de soportar los servicios de administración de derechos utilizando los datos de envoltura SOAP.

4.1. Descripción de un servicio SOAP

Para realizar la descripción del funcionamiento de un servicio SOAP, se va a hacer con un ejemplo de lo que podría ser un servicio para elaborar mapas




temáticos a partir de una base de datos demográficos. Se ha construido un gráfico que simula las diferentes peticiones entre aplicaciones y servicios.

4-1 Esquema de funcionamiento de un conjunto de servicios SOAP (Elaboración propia).

Según el ejemplo gráfico, un usuario que dispone de una aplicación cliente, solicita a través de esta una petición a un geoportal para elaborar un mapa temático de densidad de población por municipio. El geoportal dispone de un servicio web que es capaz de satisfacer esta petición. Para proporcionar la información que necesita el cliente, debe hacer uso de otros recursos, que pueden ser en forma de servicios web o de acceso directo a bases de datos. En este caso, se ha planteado que para elaborar el mapa temático, se soliciten de la base de datos las geometrías de los contornos municipales, que vienen con la superficie de cada municipio. Para obtener los datos de población, se va a utilizar un servicio web que tiene el servicio de estadística. Y para presentar el mapa final, se van mostrar las capas de carreteras e hidrografía de una servicio de mapas WMS.

En todo este proceso intervienen una serie de tecnologías que hacen posible esta circulación de información a través de la red, utilizando cualquiera de los protocolos de transmisión (HTTP, FTP, SMTP, etc.). Por un lado, se tiene el servicio SOAP que vamos a llamar con el cliente, que para conocer cómo funciona, dispone de un lenguaje WDSL, que informa a la aplicación cliente sobre cómo debe interactuar con el servicio. El servicio que hemos llamado Servicio Web Mapas Temático, hace una llamada del mismo tipo al servicio de datos estadísticos que también está construido bajo el protocolo SOAP. Luego extrae los datos de las geometrías conectándose directamente a la base de datos espaciales, y junto con los datos estadísticos, elabora el mapa temático. Para hacer esta operación, el servicio deberá llamar a alguna librería GIS que le ayude a construir el mapa. Una vez que tiene el mapa elaborado, el servicio web hace una llamada al WMS para solicitar varias capas y superponerlas con el mapa creado. Para finalizar, envía a la aplicación cliente el mapa en formato ráster y un fichero XML con los datos asociados. De esta forma, la aplicación puede mostrar el mapa y utilizar los datos alfanuméricos del XML para que el cliente consulte el valor de cada color, por ejemplo.

Las peticiones que recibe el servicio tienen que estar formateadas de una manera previamente definida, que el servicio debe exponer en su descripción del




funcionamiento. Todos los mensajes SOAP, tanto los que recibe el servicio con las peticiones, como los que devuelve con las respuestas tienen la misma estructura.

Un mensaje SOAP está definido por tres niveles: ENVELOPE (obligatorio), HEADER (opcional), BODY (obligatorio).

Como se puede ver en el esquema, SOAP es muy parecido a una carta: es un sobre (ENVELOPE) que contiene una cabecera (HEADER) con la dirección del receptor del mensaje y con un conjunto de opciones de entrega Este componente permite introducir variables de seguridad en la transmisión del mensaje (autentificación, enrutamiento, etc.). Dentro del sobre está el contenido del mensaje (BODY), que posee toda la información del servicio web a tratar (métodos y datos). Para describir todos estos datos se utiliza un esquema XML. 4-2 Formato del mensaje SOAP.

4.2. Ejemplo de funcionamiento de un servicio SOAP

Se puede ver cómo funciona un servicio SOAP en el geoportal de la Infraestructura de Datos Espaciales de Cataluña (http://www.geoportal-idec.cat/geoportal/cas/geoserveis/ws-idec/), que dispone de una serie de servicios web, y entre ellos un servicio SOAP muy bien detallado que se puede utilizar como ejemplo de un servicio que está en funcionamiento actualmente.

Lo primero que se debe conocer es la descripción del servicio y para ello, en el geoportal hay una sección que explica los detalles del servicio: nombre, dirección web para invocarlo (URI), localización del fichero de descripción del servicio (WDSL) y los métodos que soporta:

4-3 Descripción de un geoservicio en el directorio de la IDEC (www.geoportal-idec.cat).

En el fichero de descripción WDSL, se puede encontrar la descripción de cada uno de los métodos y las operaciones que se pueden realizar con ellos, que variables se necesitan, de que tipo tiene que ser y como van a ser los resultados que envía.

Para ilustrar la explicación, se elige el método getCoordenadesUTM, que dado un topónimo, devuelve las coordenadas UTM del topónimo, su nombre y la comarca a la cual pertenece. En la misma página web, muestra de forma divulgativa como utilizar este método, aunque esto no sería necesario, ya que en el fichero WDSL está perfectamente descrito pero para las máquinas.




4-4 Descripción de la operación de un servicio en el directorio de la IDEC(www.geoportal-idec.cat)

Se puede observar que este método necesita dos variables de entrada: la clave (key) y el topónimo (toponim). La primera es usada para autentificar al usuario y la segunda es el nombre del cual queremos extraer sus coordenadas. En el ejemplo de petición que ofrece para hacer la petición se puede observar como en el apartado BODY, se invoca el servicio y se le pasan las dos variables antes mencionadas:

La respuesta que devuelve el servicio es otro fichero XML, en forma de mensaje SOAP, con los posibles resultados a la consulta (8 resultados). La aplicación cliente deberá recibir este fichero y mostrar al usuario los resultados para que este seleccione el que más le interesa. A continuación se muestra una parte de este fichero:




Este tipo de servicios están preparados para usarse desde aplicaciones hechas a medida para poder sacar el máximo provecho a las posibilidades que ofertan. En el propio geoportal de la IDEC se ofrecen una serie de desarrollos en PHP para que el usuario aprenda a utilizarlos.

4.3. Servicios en funcionamiento

Entre las IDEs españolas se pueden encontrar una serie de servicios OGC. No son muchos pues es algo que se está comenzando a implantar, pero en el futuro gran parte de los servicios van a estar disponibles con esta tecnología.

• Catastro Consulta del callejero OVC: https://ovc.catastro.meh.es/ovcserweb/OVCSWLocalizacionRC/OVCCallejero.asmx

• Catastro Consulta de coordenadas OVC: https://ovc.sedecatastro.gob.es/ovcserweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx

• IDEC Geoservicios: http://delta.icc.es/idecwebservices/indexcas.html#14

• IDEG Consultas socioeconómicas: http://sitga.xunta.es/WSQ/Request.aspx

• IDEG Nomenclátor: http://sitga.xunta.es/tlssitga/Request.aspx

• IDEG Transformación de coordenadas: http://ideg.xunta.es/wcts/request.aspx

• IDEG Descarga vectorial: http://sitga.xunta.es/sdiexport/Request.aspx

4.4. Sumario

Los servicios OGC abordan muchas de las demandas de desarrolladores y administradores de las IDEs respecto a la transmisión de la información a los usuarios. Pero no llegan a cubrir todas las demandas de INSPIRE, ni los requerimientos de muchos sistemas. Como complemento a estos servicios, se está empezando a usar un protocolo genérico que permite diseñar y poner en marcha servicios web que son válidos para la interacción con los datos geográficos.

En este capítulo se ha repasado esta tecnología desde un punto de vista de usuario, comentando sus propiedades y valorando sus ventajas e inconvenientes. También se ha explicado su composición, su funcionamiento y se han mostrado ejemplos de servicios activos en las IDEs españolas.

En pocos años, la tecnología de servicios basada en SOAP va a ser la que predomine en la industria y en los organismos productores y gestores de información geográfica. El Open Geospatial Consortium, por recomendación de INPIRE entre otros, tiene previsto hacer evolucionar sus especificaciones para que funcionen con este protocolo. Eso provocará que la mayor parte de los servicios que proporciones las IDEs estén basados en el protocolo SOAP.

También se está trabajando en mejorar la velocidad de transmisión de los mensajes SOAP, ya que su envió es más lento que en otros protocolos. Esto es debido a la gran cantidad de información que llevan en su interior y este es uno



https://ovc.catastro.meh.es/ovcserweb/OVCSWLocalizacionRC/OVCCallejero.asmx

https://ovc.catastro.meh.es/ovcserweb/OVCSWLocalizacionRC/OVCCallejero.asmx

https://ovc.sedecatastro.gob.es/ovcserweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx

https://ovc.sedecatastro.gob.es/ovcserweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx

http://delta.icc.es/idecwebservices/indexcas.html#14

http://sitga.xunta.es/WSQ/Request.aspx?request=GetCapabilities

http://sitga.xunta.es/tlssitga/request.aspx?request=getcapabilities

http://ideg.xunta.es/wcts/request.aspx?Request=GetCapabilities

http://sitga.xunta.es/sdiexport/Request.aspx?request=GetCapabilities


de los pocos problemas que se le pueden poner. En cuanto a su evolución, al estar basado en otros estándares del mercado, no sufrirá grandes cambios que afecten a los desarrollos ya implantados, y esto garantiza la compatibilidad entre diferentes versiones.




5. METADATOS DE SERVICIO

Como se ha venido comentando en los capítulos anteriores, los servicios de las IDEs constituyen la mejor herramienta para alcanzar la interoperabilidad entre usuarios, y sobre todo entre sistemas. Tener acceso a información geográfica a través de visores web, es muy útil para los usuarios normales, pero los profesionales necesitan conectar sus aplicaciones para luego proceder a realizar los geoprocesos necesarios para analizar y combinar los datos en profundidad. Aquí es donde los servicios son fundamentales, y como entran en juego aplicaciones y máquinas, es necesario poder encontrarlos de la manera más automática posible. Para eso se necesitan los metadatos de servicios y, por añadidura, los catálogos y los directorios que los contienen.

Las aplicaciones deben ser capaces de encontrar, evaluar, conectar y utilizar los servicios web sin necesidad de la intervención continuada de las personas. Eso obliga a exponer los servicios en algún lugar que reconozcan y puedan consultar. Por tanto, la tecnología para almacenar los metadatos y mostrar los catálogos debe también seguir unos estándares que permita a los programadores de las aplicaciones detectar los catalogo, buscar los servicios en ellos y extraer los metadatos de servicio que luego se van a emplear para interconectar los sistemas.

En este capítulo se va a repasar la documentación existente sobre los metadatos necesarios para identificar los servicios web de datos espaciales, y comentar el funcionamiento de los catálogos y directorios que los almacenan.

5.1. Normas, especificaciones y recomendaciones

Empezando por INSPIRE, se puede encontrar en el [16] reglamento 1205/2008 que normaliza lo relativo a metadatos en las infraestructuras de datos espaciales europeas, un apartado que describe la información que tiene caracterizar a los servicios espaciales. En este texto, primero aparece una relación de todos los elementos que hay que contemplar a nivel general, y luego especifica aquellos que se deben utilizar para describir conjuntos de datos, y por otro lado, los que van destinados a detallar servicios de datos espaciales.

De los veintiún elementos de metadatos definidos en el documento, quince son coincidentes en ambos conjuntos; luego para describir los datos se incorporan cuatro elementos más, y para los servicios, se añaden otros dos elementos relativos al tipo de servicio y al recurso acoplado (proporciona información sobre los datos a los que accede el servicio). Por tanto, para caracterizar los servicios de red, INSPIRE exige que se utilicen diecisiete elementos de metadatos.

A continuación se muestran estos elementos en una tabla extraída del reglamento de sobre metadatos [16]. En la primera columna se indica un número que es la referencia del elemento en el texto del reglamento. La siguiente columna es el nombre del elemento de metadatos. Luego sigue otra llamada multiplicidad que muestra el número de valores que puede llevar el elemento en la misma notación que se usa en UML (el asterisco significa muchos, y los dos puntos indican que el elemento puede tener valores entre el primer número y el último que aparecen a cada lado de los dos puntos). En la última columna se muestran las excepciones o condiciones que hay en algunos elementos.




5-1 Metadatos de servicios espaciales ([16] Reglamento 1205/2008 de metadatos)

Mientras en el reglamento de se exigen los elementos que se han visto, se tiene que tener en cuenta que hay una norma internacional sobre metadatos para información geográfica en general (ISO19115), y otra que describe la arquitectura basada en servicios (ISO 19119). En ambos documentos, sobre todo en el de metadatos, también se comenta la información necesaria para identificar los servicios web de información geográfica.

El equipo de redacción de las normas de ejecución relativas a metadatos (DT MD) redactó un documento llamado [31] INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, que tiene en consideración esas dos normas. En el texto se comparan los elementos de metadatos de las normas ISO con los de INSPIRE de una manera muy detallada. Analizando los elementos uno a uno, comparando los valores que pueden tener; resolviendo las posibles incongruencias y examinando los esquemas XML.

Las principales conclusiones a las que llega el documento para los metadatos en general, y por tanto, afectan a los servicios web que se consideran en este trabajo son:




• La conformidad de un conjunto de metadatos con el núcleo principal de ISO 19115 no garantiza que este conjunto, tanto de datos como servicios, sea conforme a INSPIRE.

• El uso de las directrices de INSPIRE para crear metadatos garantiza que los metadatos no están en conflicto con la ISO 19115. Sin embargo, la completa conformidad con ISO 19115, implica que se tienen una serie de elementos de metadatos adicionales que no están obligados por INSPIRE a recogerse.

En el caso español, parece que va a entrar en juego una recomendación sobre los metadatos de servicios llamada NEMS (Núcleo Español de Metadatos de Servicio), ya que el grupo de trabajo de la IDEE (Infraestructura de Datos Espaciales de España) dentro del Consejo Superior Geográfico, está preparando un documento que aumenta el número de elementos de metadatos a considerar. Este incremento lo justifican atendiendo a razones de mejora de la usabilidad, el rendimiento y las funcionalidades de los visualizadores de mapas, que son los servicios más utilizados hasta el momento.

El reglamento de INSPIRE, que deben cumplir todos los estados miembros de la UE, establece un conjunto de elementos mínimos que se requieren para cumplir con la directiva, pero no excluye la posibilidad de que las organizaciones documenten de manera más amplia la información que disponen con elementos complementarios derivados de otras normas internacionales.

A la hora de crear metadatos, también debe tener en cuenta el fichero de capacidades o Capabilities que lleva asociado cada servicio web, y que contiene información descriptiva sobre el servicio para que lo puedan identificar las aplicaciones cliente.

Esta información que lleva asociada cada servicio es muy útil para empezar a crear los metadatos del propio servicio web. Existen algunas aplicaciones que para elaborar estos metadatos, que luego incluyen en los catálogos de servicio, buscan los ficheros de capacidades de cada uno de sus servicios y rellenan una serie de campos. Luego los servicios de localización, son capaces de buscar los servicios disponibles de forma automática a través de estos catálogos.

Si una aplicación necesita buscar capas de información sobre un determinado lugar, no tiene porqué tener almacenadas las direcciones de todos los servicios de esa zona, sino que pueden ser buscados en a través de servicios de catálogo, mediante el servicio web de localización. Desde el catálogo puede acceder a los ficheros Capabilities de los servicios que le interesa, y una vez que se tiene este enlace, la aplicación puede invocar el WMS u otro servicio sin ningún problema ni intervención humana. Todo este proceso puede hacerse de forma automática gracias a que el catálogo es un servicio web y dispone de metadatos de los otros servicios de mapas.

Por ejemplo, en el caso de un WMS, el fichero que se obtiene con la operación GetCapabilities almacena una serie de datos generales del servicio, datos del administrador, condiciones de uso en su primera parte, listado de operaciones que permite con sus recursos, una descripción de todas las capas con sus sistemas de coordenadas, los tipos de formato que soporta y una serie de excepciones.

En los demás tipos de servicio OGC, el fichero es muy similar y siempre aporta datos descriptivos de lo que es capaz de hacer el servicio. En el caso de los servicios de transformación, por ejemplo WPS, este fichero se complementa




con otro obtenido en la operación DescribeProcess, que informa sobre como se hace el procesado o la transformación de los datos.

5-1 Copia de un fichero obtenido con la operación GetCapabilities del servicio WMS de la cartografía básica de la IDEE

Como se puede ver en la imagen superior, los datos que proporciona el fichero obtenido mediante GetCapabilities son bastante completos, por lo menos para hacerse una idea del tipo de servicio y de que información geográfica se puede obtener con él. En cuanto al aspecto visual de esta imagen, no es un fichero XML como puede apreciarse, se ha formateado y traducido con la aplicación WMS Inspector que funciona como complemento del navegador Firefox, y además de visualizar los ficheros de Capabilities de los servicios WMS, ayuda a buscar los enlaces a estos servicios según navegamos por los geoportales.




Teniendo en cuenta los datos que aparecen en este tipo de ficheros, junto con la información que exige INSPIRE a través de su reglamento de metadatos, y la recomendación NEMS [15] que está preparando el grupo de trabajo de la IDEE, se ha elaborado una tabla comparativa para mostrar los elementos considerados por cada uno y que puede dar una idea de un modelo a seguir en el futuro para implantar un catálogo de metadatos de servicio.

Reglamento 1205 INSPIRE Fichero Capabilities Propuesta NEMS Titulo del recurso Title /Name Título del servicio Resumen del recurso Abstract Resumen Tipo de recurso Tipo de recurso Localizador del recurso OnlineResource Localizador del recurso Recurso acoplado Recurso acoplado Tipo de servicio de datos espaciales Tipo de servicio

Palabra clave Palabra clave Rectángulo geográfico envolvente LatLonBoundingBox Rectángulo geográfico

envolvente Referencia temporal DimensionName Extensión temporal

Resolución espacial MinScaleDenominator/ MaxScaleDenominator Resolución espacial

Grado de conformidad Grado de conformidad

Condiciones de acceso y uso AccessConstrains/Fees Condiciones de acceso y uso

Restricciones de acceso público Attribution Restricciones de acceso

público

Organización responsable ContactInformation/ ServiceProvider Organización responsable

Punto de contacto de los metadatos Punto de contacto de los

metadatos Fecha de los metadatos Fecha de los metadatos Lengua de los metadatos Lengua de los metadatos SRS/CRS Sistema de referencia Request Nombre de operaciones

Format/ OutputFormat Formato

Protocolo de acceso Información adicional 5-2 Comparación de los elementos de metadatos presentes en el reglamento INSPIRE de metadatos

[16], en los ficheros de capacidades de los servicios web y en la primera propuesta del Núcleo Español de Metadatos de Servicio (NEMS) [15].

Como se puede observar en la tabla, los metadatos que contiene el fichero de capacidades de cada servicio es muy completo y podría bastar para rellenar los metadatos que solicita INSPIRE. Aunque faltan casi la mitad de los elementos, alguno de ellos como el Tipo de recurso o el Tipo de servicio, es un datos que viene implícito en el propio nombre del servicio. Por ejemplo, para un WMS el tipo de recurso tomaría el valor “servicio” y el tipo de servicio sería “visualización”. El Grado de conformidad, que es otro elemento que falta, va asociado a la especificación que sigue la construcción del servicio, y por tanto, el programa que carga los metadatos puede tener ya valores de este elemento asociados al tipo de especificación que detecte.




Otros elementos como Palabras clave, Lenguaje de metadatos o Punto de contacto de los metadatos, se podría incluir en alguno de los campos que tiene el fichero de capacidades para incluir textos.

Respecto a la propuesta española, parece que pretende hacer una recomendación más completa que la de INSPIRE, añadiendo una serie de elementos que ya lleva el fichero de capacidades y otros datos muy útiles sobre protocolos e información adicional. Para los creadores de metadatos, esta propuesta no supone mucho trabajo, pues los elementos añadidos vienen en el fichero de capacidades o se pueden deducir de su contenido.

5.2. Propuesta de plantilla de metadatos

Después de ver la comparación entre ISO 19115, el reglamento INSPIRE, el contenido de los ficheros Capabilities y las recomendación del GTIDEE, parece que si se tiene que proponer una plantilla o esquema para catalogar los servicios de una IDE, lo más cómodo seria diseñarla en base al fichero de capacidades. De esta forma, la creación de metadatos es prácticamente automática y permitiría a los administradores tener los servicios metadatados perfectamente sin necesidad de preocuparse porque varíen su configuración. El problema lo tendrían las IDEs europeas, que no cumplirían las obligaciones de la directiva.

Si se necesita cumplir con INSPIRE, como es el caso de las IDEs en España, la diferencia entre el esquema que del reglamento de metadatos y la recomendación del grupo de trabajo de la IDEE es mínima, y como se comentaba antes, los datos que faltan se pueden extraer del fichero de capacidades. Por tanto, para una IDE en territorio español, lo aconsejable seria utilizar la recomendación NEMS, pues cumple con INSPIRE y es más rica en la descripción de un servicio.

5.3. Directorio de servicios

Como la tecnología de los catálogos de servicios está todavía poco desarrollada, en muchas IDEs han empezado poner en marcha los directorios de servicio, que no es más que un listado organizado y jerarquizado que muestra un enlace a cada servicio. No disponen de elementos para realizar búsquedas, ni ofrecen más datos que la URL genérica del servicio o del fichero de capacidades.

5-2 Imagen del Directorio de Servicios de la IDEE

(http://www.idee.es/CatalogoServicios/CatServ/directorio_servicios.html).




En varias de las IDEs españolas, se puede encontrar este tipo de listados de servicios. En algunas como la de Andalucía, que tiene más de 100 servicios web, es muy útil porque recopila los servicios de todos los departamentos de la administración andaluza. En casi todas las demás IDEs, el número de servicios es mucho menor, y por tanto, más que un directorio, a veces es un listado de cuatro o cinco servicios.

En el geoportal de la IDEE funciona un directorio con más de 800 servicios, ya que almacena los servicios web de información geográfica de todas las IDEs españolas. Es muy sencillo, se puede listar la información por tipo de servicio y por ámbito del servicio, pero se le echa en falta un buscador sencillo. Se puede encontrar en la dirección http://www.idee.es/CatalogoServicios/.

5.4. Catálogo de servicios

Los metadatos de servicio que se han desarrollado en este capítulo van destinados a usarse en los catálogos de servicio, como ya se ha comentado. Pero debido a la falta de tecnología para gestión de estos catálogos, la implantación es mínima. Otra de las causas de la escasa presencia de catálogos de servicio es que las IDEs todavía tienen pocos servicios que describir, y para mostrar cinco servicios, no hace falta un catálogo.

Otras veces, como ocurre en muchas IDEs fuera de España, los servicios se describen en un catálogo único de datos y servicios. En este caso, las búsquedas son confusas, pues cuando se intenta encontrar mediante palabras clave que indiquen el tipo de datos a servir, aparece un listado muy largo y mezclado.

5-3 Aspecto del Catálogo de servicios de la IDEE (http://www.idee.es/IDEE-ServicesSearch/).



http://www.idee.es/CatalogoServicios/


La IDEE dispone de un catálogo bastante completo, con una forma similar al catálogo de datos, pero con campos de búsqueda orientados a servicios. Sin embargo, la IDE de Cataluña tiene almacenada la descripción de los servicios en el mismo repositorio que los datos. Esta fue una de las primeras IDEs que dispuso de los servicios catalogados.

5-4 Catálogo de la IDEC (http://delta.icc.cat/SDIExplorer/cercaCataleg.jsp)

5.4.1. CatMDServices

Antes de finalizar este capítulo, está bien hablar de la tecnología necesaria para poner en marcha un catálogo de servicios. Para ello se va a comentar un producto elaborado por la Universidad de Zaragoza y la empresa GeoSpatiumLab S.L., y patrocinado por el Instituto Geográfico Nacional. Se trata de una aplicación web, que sigue la línea que se inició con el desarrollo de CatMDEdit (editor de metadatos), y que usando tecnologías como Java, Google Web Toolkit o XML, permite la creación, edición, búsqueda y publicación de metadatos de servicio.

La principal característica a resaltar es que, aparte de mostrar un catálogo de servicio similar al de la IDEE, pone en marcha servicios web de localización, para que se pueda realizar la búsqueda sobre el catálogo de manera automática. También es capaz de crear y actualizar metadatos a partir del fichero de capacidades de cada servicio.

Se trata de un aplicativo de código abierto con licencia GNU Lesser General Public License (LGPL), que es multiplataforma y admite diferentes idiomas (español, inglés y francés). Se puede descargar desde el repositorio europeo OSOR.EU en el enlace: http://forge.osor.eu/projects/catmdservices/.

Dada su envergadura, no es una aplicación sencilla de instalar, pero por sus características se ajusta muy bien al tratamiento de los metadatos sobre los servicios. Según sus creadores [20], la arquitectura del catálogo que se crea con CatMDServices sigue el modelo multicapa, donde cada uno de sus componentes



http://forge.osor.eu/softwaremap/trove_list.php?form_cat=16

http://forge.osor.eu/softwaremap/trove_list.php?form_cat=16


que integran el producto final puede agruparse en distintos niveles en función de cuál sea su relación con el acceso a los datos o su interacción con el usuario final. Se distinguen tres capas o niveles diferenciados: almacenamiento de datos, servicios y aplicaciones.

5.5. Sumario

En este capítulo se ha resaltado la importancia de los metadatos sobre a servicios para que los sistemas de información puedan alcanzar las máximas cotas de interoperabilidad de una forma mecanizada. Pero igual que se ha investigado y trabajado mucho en los metadatos sobre datos, en cuanto a servicios se está empezando ahora.

En un principio, se trataron como un recurso más de una IDE, pero se está viendo, quizá gracias al desarrollo de las tecnologías de la información, que se necesitan otros elementos que los puedan caracterizar mejor.

Se ha estudiado lo que pide INSPIRE en su reglamento de metadatos sobre servicios, y se ha visto como resulta la comparación con la norma ISO 19115. También se ha comparado con una nueva propuesta que está elaborando el grupo de trabajo de la IDEE llamada NEMS (núcleo español de metadatos de servicio), que es más amplia que la de INSPIRE y que coincide en muchos elementos con los ficheros de capacidades que tienen cada uno de los servicios web.

Como propuesta de plantilla o esquema de metadatos de servicios se ha visto que es muy interesante la recomendación NEMS, pero si no fuera porque no es conforme a INPIRE, lo más interesante seria que los metadatos de servicios fueran los que se almacena en cada fichero de capacidades (Capabilities) de los propios servicios.

Luego se ha visto las dos estructuras utilizadas para contener listados de servicio: los directorios, como algo más informal, y lo catálogos de servicios, más complejo pero mucho más útil y eficaz.

Para finalizar, se ha visto brevemente una aplicación web de software libre que funciona bien para la implantación de estos catálogos.




6. EVALUACIÓN DE LA CALIDAD DE LOS SERVICIOS

Previamente, en los capítulos 2 y 3, se han comentado los criterios mínimos de calidad que deben cumplir los servicios web para ser conformes a las normas de ejecución de INSPIRE y a las especificaciones OGC. En este apartado se va a estudiar esa calidad desde un punto de vista más genérico, a partir de los criterios usados para cualquier tipo de servicio web.

También se van a analizar algunas herramientas y utilidades disponibles para monitorizar el cumplimiento de esos criterios de calidad exigidos.

6.1. Requerimientos de calidad del W3C

Basado en diferentes estudios experimentales, el W3C, como consorcio que desarrolla estándares que aseguran el crecimiento de la Web a largo plazo, ha definido los siguientes aspectos de calidad y ha descrito los requisitos deseados en cada uno de ellos [6]. A continuación se resumen estos aspectos en la siguiente tabla:

Concepto de calidad Definición

Rendimiento(*) Representa el tiempo de respuesta de un servicio en ser completado.. Puede sr medido en términos de tasa de transferencia, tiempo de respuesta, latencia, tiempo de ejecución, tiempo de transacción, etc. Un servicio de alta calidad debería tener una alta tasa de transferencia, una rápida respuesta, una baja latencia, un bajo tiempo de ejecución y un breve tiempo de transacción.

Fiabilidad(**) Representa la capacidad de un servicio web para realizar sus funciones necesarias en las condiciones indicadas y en un intervalo de tiempo especificado.

Escalabilidad Es la posibilidad de aumentar la capacidad del sistema informático del proveedor de servicios, de forma que aumente la capacidad del sistema para procesar las solicitudes de un número mayor de usuarios con más operaciones o transacciones en un intervalo de tiempo determinado.

Capacidad(*) Es número máximo de peticiones simultáneas al servicio con una respuesta garantizada.

Robustez Representa el grado en que un servicio web puede funcionar correctamente, incluso en presencia de entradas erróneas, incompletas o conflictivas.

Manejo de excepciones Es un indicador de la funcionalidad del sistema para manejar los problemas que pueden surgir cuando hay salidas erróneas y las alternativas que ofrece.

Precisión Se define como la tasa de error que tiene el servicio web en su funcionamiento.




Integridad Debería ser proporcionada por el servicio web de tal forma que un sistema o componente pueda prevenir el acceso no autorizado o la modificación de datos o programas del servidor.

Accesibilidad Se define como la capacidad de atender las peticiones de las aplicaciones cliente.

Disponibilidad (*) Representa la probabilidad de que el sistema funcione con fiabilidad.

Interoperabilidad Los servicios web deben ser utilizables para los diferentes entornos que se utilizan para implementar servicios, de modo que los desarrolladores que usan esos servicios, no tengan que pensar en un determinado lenguaje de programación o en un sistema operativo concreto.

Seguridad(**) El proveedor de servicios web debe proporcionar una política de seguridad adecuada y a diferentes niveles.

6-1 Relación de conceptos para medir la calidad de los servicio web [6]. (*) Presente en el reglamento de Servicios de Red y Arquitectura de INSPIRE [26, 29, 31]. (**) Presente en la descripción de la arquitectura de INSPIRE [22].

Como se ha visto en antes, las normas de ejecución de INSPIRE sólo se establecen criterios mínimos a cumplir para tres de estos aspectos: rendimiento, capacidad y disponibilidad. En el documento que describe la arquitectura [22], habla de seis criterios, que son los tres anteriores más la fiabilidad, la seguridad y la conformidad. Este último no aparece en el estudio de W3C como tal, pero podría asemejarse al de interoperabilidad.

Alguno de estos criterios, como interoperabilidad, integridad o robustez, son difíciles de medir en términos absolutos, sólo se podría hacer una comparativa con otros servicios y establecer unos valores de referencia. Para ello, la organización coordinadora, por ejemplo INSPIRE en Europa o la IDEE en España, deberían establecer unos valores de referencia, y sobre todo, una metodología de medición. También podría ser interesante, elaborar un ranking de cumplimiento de los criterios de calidad en los servicios web, y luego otorgar al algún tipo de reconocimiento para que el usuario, antes de conectarse al servicio, identifique esa marca de calidad.

6.2. Servicio Status Checker

El Federal Geographic Data Committee (FGDC) ha puesto en marcha un servicio para validar, probar y puntuar servicios web de información geográfica. Una vez que un servicio web es dado de alta, devuelve información resumida sobre su diagnóstico en función de las pruebas que realiza de una manera sistemática. Se pueden chequear una serie de servicios de acceso a datos y a metadatos. Se accede a él a través de la dirección http://registry.fgdc.gov/ statuschecker/index.php. Además, funciona como un servicio web con varias formas para invocarlo.

Con este servicio se pueden evaluar en estos momentos cinco tipos de servicios web, y en un futuro, están previstos otros cuatro más. En lo que respecta a servicios que se han visto en este trabajo, se pueden obtener resultados del WMS y WFS, y en poco tiempo se podrá trabajar con CSW y WCS.



http://registry.fgdc.gov/%20statuschecker/index.php

http://registry.fgdc.gov/%20statuschecker/index.php


Tipo de servicio Status

WMS Disponible

ESRI ArcIMS Image Disponible

WFS Disponible

Z39.50 Disponible

Web Accessible Folder (WAF) Disponible

CSW Previsto

WCS Previsto

ESRI ArcIMS Metadata Previsto

SOS Previsto

6-2 Servicios soportados por el SSC.

Se puede trabajar con el SSC (Service Status Checker) en dos modos diferentes: uno en tiempo real, y otro en modo de archivo. A continuación se detallan cada una de las formas de trabajo:

• Real Time Testing Mode (tiempo real): trabajando de esta forma, se realizan las peticiones al servicio web, y este responde inmediatamente con los resultados.

• Archive Testing Mode (modo archivo): Los catálogos de IDE proporcionan el listado de servicios al SSC y, diariamente, este ejecuta una serie de procesos que prueban todos esos servicios. Luego los resultados se almacenan en una base de datos y se pueden recuperar en cualquier momento.

6-1 de proceso de los dos modos: Real Time Testing (izquierda) y Archive Testing (derecha).

El proceso y los resultados de cada uno de los modos de es diferente, y por tanto, su utilidad va se encuadra en tareas diferentes. EL primero de ellos, el chequeo en tiempo real, va destinado a saber si un servicio funciona en un instante determinado, y es muy útil para chequear los servicios en cualquier momento y si no funciona correctamente, se puede lanzar una acción para restaurar el servicio o la base de datos.




Para probar cómo funciona el servicio en tiempo real, se efectúa una llamada al servicio para comprobar el servicio WMS de la IDEE (http://www.idee.es/wms/IDEE-Base/IDEE-Base?). Dentro de cada modo hay dos formas de invocar el servicio, una con HTTP GET (se invoca con parámetros en una URL) y otra con HTTP POST (se activa el servicio con un formulario, por ejemplo). Se hace la prueba con la primera opción que es más sencilla, y para ello, se construye la siguiente URL:

http://registry.fgdc.gov/statuschecker/services/rest/index.php?url=http://www.idee.es/wms/IDEE-Base/IDEE-Base?SERVICE=WMS&REQUEST= GetCapabilities &type=wms&formattype=xml

Como se puede ver, la URL lleva tres parámetros, y puede llevar un parámetro más opcional sobre el tipo de informe de salida:

• Url: http://www.idee.es/wms/IDEE-Base/IDEE-Base?SERVICE=WMS& REQUEST=GetCapabilities, que es la dirección del servicio WMS.

• Type: wms, que indica el tipo de servicio.

• Formattype: xml, es el formato en que muestra los resultados. También se puede usar html, y de esta forma envía el fichero XML formateado. Es opcional, por defecto es xml.

• Requesttype: indica si el informe es completo (full) o reducido (brief). También es opcional y por defecto es full.

Se hace la prueba con los dos tipos de informe, en XML y en HTML, y el resultado se puede ver en las siguientes imágenes. En este caso indica que el servicio funciona correctamente, y le puntúa entre 0 y 100 con el valor de 96,55 en un caso y 99,10 en otro. Luego especifica cómo se deben invocar las operaciones de GetCapabilities y GetMap.

6-2 Resultados ofrecidos por el Service Status Checker en modo real.




Para usar el otro modo de funcionamiento, el Archive Testing Mode, hay que dar de alta el catalogo que contiene los metadatos de nuestros servicios, y una vez que conocemos el identificador de nuestro catálogo en la base de datos del servicio Status Checker, podemos invocar el servicio de una manera similar al anterior modo, pero tenemos que indicar una fecha de inicio y otra de finalización del periodo de chequeo.

El resultado en este caso es más completo, y sobre todo da una idea del funcionamiento del geoservicio a lo largo de un periodo amplio de tiempo. Esta forma de trabajo está indicada para monitorizar el funcionamiento, y el modo en tiempo real, está enfocado ejecutar una tarea cuando el servicio no esté funcionando bien, pues se pueden obtener resultados en tiempo real.

6-3 Resultado del Service Status Checker en modo archivo.

6.3. Herramienta GeoPole

Otro servicio para controlar la calidad de geoservicios es el que presta la empresa SOURCEPOLE (www.sourcepole.com), a través de un producto web llamado GEOPOLE (http://geopole.org/) que es similar al visto en el apartado anterior, pero realizado con fines empresariales.

Permite chequear si funciona un servicio WMS introduciendo la URL de su operación de GetCapabilities, y como resultado ofrece un análisis de la composición del servicio en cuanto a capas de información y otras características. A diferencia del servicio Status Checker, no da datos de rendimiento, pero sí de funcionamiento. Pero además ofrece una serie de funcionalidades para los interesados en contratar los servicios de esta empresa

• Búsqueda de servicios WMS.

• Proporciona noticias de nuevos servidores WMS.

• Dispone de un repositorio de WMS que se actualiza diariamente.

• Facilita una API para la búsqueda de servidores.

• Comprueba la validación de la estructura del esquema WMS.



http://www.sourcepole.com/

http://geopole.org/


• Ofrece un servidor estadísticas.

• Permite mostrar las capas de los WMS sobre un visor propio.

Para probarlo, se utiliza el mismo servicio WMS de la IDEE que se ha utilizado en el apartado anterior, y los resultados son los siguientes:

6-4 Resultados ofrecidos por la herramienta GEOPOLE sobre un servicio WMS.

6-5 Resultados ofrecidos por la herramienta GEOPOLE sobre un servicio WMS.

Ofrece dos tipos de resultados, por un lado ofrece las características del servicio WMS (imagen superior) y luego hace un análisis cada una de las capas.

6.4. Sumario

Cuando los servicios web empiecen a ser una herramienta habitual entre las aplicaciones que usan a diario los profesionales que trabajan con la información geográfica, se deberá controlar y exigir unos parámetros de calidad, sobre todo en áreas que necesitan una disponibilidad plena por temas de emergencias o seguridad.

Con el objetivo de controlar la calidad, el W3C ha identificado doce conceptos como criterios que se deberían medir en cualquier sistema proveedor de servicios. Para realizar este control, es necesario diseñar herramientas que puedan ayudar a los administradores de las infraestructuras de datos espaciales a conocer cómo llega su información a los usuarios.

En este capítulo se han visto dos herramientas que han surgido a raíz de uso cada vez más frecuente de los geoservicios. El Service Status Checker, servicio del organismo norteamericano FGDC, que promueve el uso coordinado




de la información geográfica, se trata de una herramienta muy fácil de usar que analiza el funcionamiento de una gran variedad de servicios, y los clasifica según su rendimiento. Se puede utilizar de varios modos, pero se le echa en falta que explique su metodología de trabajo.

La otra herramienta, llamada GEOPOLE, es más limitada y está creada por una empresa privada. Está enfocada a analizar el servicio en cuanto a su contenido, pero no mide rendimientos ni capacidad.




7. PROGRAMAS PARA CREAR SERVICIOS WEB DE INFORMACIÓN GEOGRÁFICA

Para poner en marcha servicios web de información geográfica, se necesita una tecnología de servidor, es decir, una aplicación informática que sea capaz de recoger los datos del repositorio (base de datos, ficheros vectoriales, imágenes, etc.), colocarlos en los servicios y enviarlos por la red según las peticiones de los usuarios. En la máquina servidora se instalan un conjunto de programas informáticos que, de forma coordinada, realizan estas funciones. Primero escuchan la petición, luego buscan la información en la base de datos o en el disco duro, y preparan la porción de mapa solicitada en el formato que demanda el servicio. Se acaba el proceso enviando un fichero a la aplicación cliente.

Este apartado se va a centrar en repasar una serie de aplicaciones existentes en el mercado que realizan la función de servidor de mapas. Normalmente, van asociadas a una tecnología de servidor web HTTP, como pueden ser Apache (código abierto) o Internet Information Server (Microsoft), que les proporciona la pasarela para exponerse en internet. Crean el concepto de directorio virtual, que aloja las páginas web y así pueden ser leídas por los usuarios a través de sus navegadores u otro tipo de aplicaciones.

Hay una gran variedad de productos creados por las empresas de software comercial o por organizaciones y universidades que promueven el software libre. Cada programa posee una serie de características que los hacen más o menos apropiados para los diferentes tipos de servicios, aunque el funcionamiento es muy similar. Consiste en preparar un fichero de configuración que dispone de los datos relativos al almacenamiento de las capas de información geográfica, de la definición de los estilos gráficos que se van a utilizar en su representación, de los metadatos del servicio y de otra información necesaria para su funcionamiento. Otras plataformas en vez de usar estos ficheros, almacenan los datos necesarios en unas tablas de una base de datos de configuración del servicio. Esta segunda opción ofrece más posibilidades, pero es más compleja de usar.

Las organizaciones que están creando servicios web están apostando por el software Open Source, ya que funciona bastante bien para este cometido y es bastante estable. Detrás de su desarrollo hay una gran comunidad de programadores que trabajan aportando sus soluciones a organizaciones o fundaciones que las difunden, y que han conseguido estar a la altura de los grandes fabricantes.

Entre estas comunidades destaca OsGeo, que es una fundación sin ánimo de lucro, cuyo objetivo principal es apoyar y promocionar el desarrollo abierto y colaborativo de los datos y las tecnologías geoespaciales. La fundación proporciona apoyo económico, organizativo y legal a la comunidad de desarrolladores. Además es una entidad legal independiente a la que los miembros de la comunidad pueden aportar código fuente, donativos y otros recursos, seguros de saber que sus contribuciones permanecerán siempre para el beneficio de todos. Todos los proyectos de la fundación son completamente libres de uso bajo una licencia certificada por la Open Source Initiative (OSI).

Las aplicaciones comerciales de los grandes fabricantes como ESRI e INTERGRAPH también tienen implantación, y suelen estar asociadas a



http://www.opensource.org/


departamentos que ya disponen de esa tecnología para la gestión de sus sistemas de información geográfica corporativos.

7.1. MapServer

7-1 Aspecto de la página web de MapServer (http://mapserver.org/).

MapServer es un producto de código abierto muy popular cuyo propósito principal es mostrar mapas dinámicos a través de Internet a través de servicios web. Sus características principales incluyen:

• Soporte para la visualización y consulta de datos espaciales a partir de formatos vectoriales, ráster y conexiones a bases de datos.

• Capacidad de ser ejecutado en distintos sistemas operativos (Windows, Linux, Mac OS X, etc.).

• Soporte para diferentes lenguajes de programación de secuencias de comandos (PHP, Python, Perl, Ruby, Java, .NET).

• Realiza los cambios de sistema de proyección sobre la marcha.

• Representación gráfica de calidad.

• Muchas aplicaciones de código abierto realizadas para su personalización de listos para usar.

Está escrito en lenguaje C y fue originalmente desarrollado por el proyecto de ForNet de la Universidad de Minnesota (UMN) en cooperación con la NASA y el departamento de recursos naturales de Minnesota (MNDNR). Ahora es un proyecto de OSGeo y es mantenido por un creciente número de desarrolladores (casi 20) de todo el mundo.

Como se puede ver en la imagen siguiente, la arquitectura de funcionamiento es similar a la de otras aplicaciones servidoras de datos a través de internet. Mediante el fichero de configuración, que es un fichero de texto que generalmente tiene la extensión ".map", MapServer sabe a qué datos tiene que acceder, que formato de servicio es el elegido y que estilos visuales hay que




aplicar. El motor MapServer CGI Application prepara el mapa y se lo pasa al servidos web Apache para darle salida. Esta puede ser en forma de servicio WMS, WFS o WCS, pero también dispone de otros formatos gráficos de salida muy útiles como PDF, SVG o simplemente imágenes mediante HTML.

7-2 Arquitectura de funcionamiento de MapServer (Fuente:

http://mapserver.org/introduction.html)

También puede funcionar como biblioteca, realizando tareas especificas con un alto contenido dinámico en el lado del servidor, como proceso de transformación o análisis sobre la marcha. Las características [11] por las que destaca este servidor son:

• Sencillez de configuración y administración.

• Plataformas sobre las que puede operar.

• Velocidad de acceso a datos

• Cantidad de formatos tanto vectoriales como ráster soportados

En estos momentos es una de las tecnologías de servidor más utilizadas por los nodos de las infraestructuras de datos espaciales Y para facilitar su configuración, algunos programas de GIS como GvSIG, tienen una serie de extensiones que permiten crear los ficheros de configuración mediante asistentes sencillos.

En un anexo a este trabajo se explica cómo se prepara un servicio WMS con esta tecnología.




7.2. Geoserver

7-3 Aspecto de la web de Geoserver (http:// geoserver.org/)

Otro servidor muy utilizado es GeoServer, también de código abierto, que está escrito en Java y permite a los usuarios compartir y editar datos geoespaciales. Esta diseñado para promocionar la interoperabilidad, publica de datos de cualquier origen usando estándares abiertos. Siendo un proyecto impulsado por la Comunidad, GeoServer es desarrollado, probado y apoyada por un grupo diverso de individuos y organizaciones de todo el mundo.

GeoServer es la implementación de referencia del Open Geospatial Consortium (OGC) para las especificaciones Web Feature Service (WFS) y Web Coverage Service (WCS), y está certificada su compatibilidad con Web Map Service (WMS) de alto rendimiento.

[11] Este servidor de mapas forma parte de la nueva generación de aplicaciones desarrolladas sobre la especificación J2EE. El objeto principal de esta nueva generación de servidores es la utilización de las últimas tecnologías en el desarrollo de soluciones web empresariales, con lenguaje de programación Java. Esto permite el despliegue de la aplicación sobre cualquier servidor de aplicaciones conforme a la especificación J2EE, tanto los libres como Tomcat (Apache), JBoss (RedHat) o Geronimo (Apache), como los propietarios como WebLogic (BEA), WebSphere (IBM), etc.

Un aspecto pro el que destaca esta aplicación es por el soporte para el protocolo WFS-T (Web Feature Service Transactional) convirtiéndose en no sólo un servidor de cartografía sino en un intermediario para la edición remota de información geográfica mediante estándares. Con esta operatividad, los servicios web no sólo van a servir para buscar, consultar y descargar información, sino que van a permitir la edición e incorporación de datos a las bases de datos espaciales de los servidores. Esto va a suponer un cambio muy grande en la concepción de los sistemas de información geográfica y cuando se implante plenamente, tendrán que cambiar muchas aplicaciones.




7.3. Deegree

7-4 Imagen de la página web de Deegree (http://www.deegree.org/).

Deegree pertenece a un proyecto que nació en la Universidad de Bonn, y que luego continúo evolucionando en la empresa lat/lon GmbH, que lo utiliza para prestar servicios comerciales alrededor de su plataforma. Este software destaca por el gran número de especificaciones OGC que afirma cumplir, entre las que están WMS, WFS(-T), WCS, CSW, WPS, etc.

Realmente se trata de una infraestructura de componentes Java que se puede desplegar sobre cualquier servidor conforme a la especificación J2EE, ofreciendo un completo conjunto de capacidades geoespaciales. [11] Entre sus principales características, podemos destacar:

• Elevada capacidad de configuración y adaptación.

• Instalación y configuración complejas y nada "amistosas".

• Buen rendimiento comparado con otros servidores J2EE.

• Amplio abanico de estándares OGC (aunque no siempre 100% conformes).

• Comunidad de desarrollo no demasiado abierta, aunque con intención de mejorar este aspecto. Prueba de ello es su incorporación como proyecto incubado en OSGeo.

Esta tecnología no sólo da soporte a la parte servidora, sino que dispone de elementos para la creación de aplicaciones cliente de información geográfica. La configuración de los servicios también se realiza a través de un fichero de configuración diferente para cada uno de los servicios.

7.4. Plataformas de software comercial

Entre el software comercial hay en mercado para la gestión de sistemas de información geográfica, prácticamente todos los productos con tecnología de servidor disponen de servicios web conforme a las especificaciones de OGC. Se trata normalmente de programas muy complejos de instalar y gran catidad de



http://www.lat-lon.de/


módulos y/o extensiones. Suelen estar integrados en la familia de productos correspondiente y su precio es muy elevado, como mínimo tres o cuatro veces más que un programa para GIS de escritorio.

Un caso particular de este tipo de programas comerciales lo constituye MapGuide, que fue desarrollado por Autodesk, la empresa que también es propietaria de AutoCAD. Esta empresa lo liberó en 2006 como aportación a la creación de la fundación OSGeo. Dispone de un sistema de publicación web de fácil configuración y administración, y dispone de herramientas para la publicación desde AutoCAD. Son gratuitos algunos componentes y otros no.

El software propietario más utilizado quizá es ArcGIS Server de la empresa ESRI, pues tiene una gran implantación a nivel mundial. Es difícil resumir su forma de trabajo pues tiene una gran variedad de flujos de trabajo para conseguir cualquier tipo de publicación web y de servicios. Para programar en su entorno de desarrollo es muy versátil y admite bastantes tecnologías para la preparación de servicios y utilidades para el tratamiento de la información geográfica. El geoportal oficial de INSPIRE está creado con esta tecnología.

Otro gigante comercial en el mundo de la información geográfica es Intergraph, que con su familia de productos Geomedia, dispone de varias aplicaciones para la puesta en marcha de servicios web, y por supuesto, la publicación de cualquier tipo de aplicación. Aunque su implantación es menor que la ESRI, tiene una gran comunidad de usuarios.

La lista de programas capaces de crear servicios web de información geográfica es enorme, sólo hay que ver la lista de productos que tiene el Open Geospatial Consortium en su portal y que cumplen con las especificaciones que este ha elaborado (http://www.opengeospatial.org/resource/products/).

7.5. Cumplimiento de las especificaciones OGC

7-5 Marcas registradas o de certificación, que otorga OGC.

Un producto registrado [9] en el Open Geospatial Consortium significa que el software implementa una especificación OGC, es decir, que un desarrollador ha obtenido una copia de una norma de OGC y ha hecho un intento de seguir sus instrucciones en relación con la sintaxis de la interfaz o el esquema, y los comportamientos durante el desarrollo del software o de una aplicación cuya funcionalidad entra dentro del alcance de la norma. Luego, la empresa desarrolladora puede solicitar que su producto "implements the specified standard" y se puede registrar el producto en el sitio web del OGC.

Hay otros productos que aprueban el “OGC Compliance Testing Program”, es decir, han pasado un proceso formal para probar la conformidad, cumplen con todos los elementos obligatorios según lo especificado en el estándar y estos



http://www.opengeospatial.org/resource/products/


elementos operan como se describe en el estándar. Cuando se completan con éxito las pruebas de un producto, el personal de la OGC valida la prueba y, la empresa puede utilizar en sus productos las marcas del OGC (marcas registradas o marcas de certificación). Estas marcas pueden utilizarse en materiales de marketing y documentación para indicar a los usuarios que el producto cumple con unas normas específicas OGC.

Como resumen de la tecnología que se ha visto en este capítulo, se muestra una tabla con el listado de servicios más utilizados y se indica si cada uno de los productos de software vistos en este capítulo, están registrados en el Open Geospatial Consortium porque implementan la especificación correspondiente a ese servicio (señalados en la tabla con ●). Los productos que han pasado el programa de certificación de OGC (Certified OGC Compliance Testing Program) están marcados con una C. Toda la información sobre estos procesos de prueba y documentos sobre el proceso se pueden encontrar en el enlace http://www.opengeospatial.org/resource/testing/downloads.

MapServer GeoServer Deegree MapGuide ArcGIS Geomedia

WMS 1.3.0 C C C

WMS 1.1.1 ● ● C C C C

WMS 1.1.0 ● ● ● ● ●

WMS 1.0.0 ● ● ● ●

WFS 1.0.0 ● C ● ● C C

WFS-T C C

WCS 1.0.0 C C C ●

CSW 2.0 ● C ●

WPS 1.0 ●

WMC 1.0 ● ● ●

SLD 1.0 ● ● ● ●

GML 2.0 ● ● ● ● ●

FE 1.0 ● ● ●

● Producto registrado en OGC para esa implementación

C Cumplimiento certificado por OGC (Certified OGC Compliant Testing Program)

7-1 Tabla comparativa del cumplimiento de las especificaciones OGC de las aplicaciones servidoras. (Elaboración propia a partir del listado de productos registrados de OGC).

Como se puede ver en esta tabla, los grandes fabricantes, como ESRI e Intergraph, tienen el objetivo de cumplir con todas las especificaciones. Ahora mismo es algo valorado por el usuario; para las empresas es cuestión de prestigio y lo utilizan como herramienta de marketing. También se puede destacar a Deegree, que pretende cumplir con todas las especificaciones y además es de código abierto.



http://www.opengeospatial.org/resource/testing/downloads


En el portal de OGC, se puede encontrar bastante [9] documentación sobre los productos certificados o registrados. Existe la posibilidad de buscar por producto, por empresa o por especificación. También hay una tabla muy interesante que hace un ranking con el número de productos registrados para cada especificación. También se puede hacer lo mismo para los productos certificados con las pruebas de cumplimiento.

7-2 Tabla de número de productos según especificación (Fuente: OGC).

Total: número de implementaciones de la especificación. Comp.: número de implementaciones oficialmente compatibles.

Como era de suponer, la especificación más implementada es el servicio WMS, seguido por el WFS y el lenguaje GML. En futuro, esta tabla se equilibrará y probablemente empiecen a destacar los servicio de descarga y procesamiento, que posibilitan un trabajo más parecido al que se suele hacer con nuestros sistemas GIS y los datos en nuestro disco duros.

7.6. Sumario

En este capítulo se ha repasado la tecnología servidora para la publicación de servicios web de información geográfica. Se empezó por los tres conjuntos de aplicaciones de código abierto más implantadas en las organizaciones productoras de datos.

La primera de ellas MapServer parece que puede ser el más utilizado. Su configuración es sencilla y dispone de una gran cantidad de aplicaciones que se desarrollan sobre él y que añaden una gran cantidad de posibilidades a su uso. El segundo estudiado es GeoServer, desarrollado sobre Java, a diferencia de MapServer que está hecho en lenguaje C, forma parte de las implementaciones de referencia del OGC. Y el tercero es Deegree, que parece que posee un conjunto de aplicaciones más completo pero también más difícil de configurar.

En cuanto al software comercial, sólo se nombraron los más implantados en las organizaciones, ArcGIS y Geomedia. También se comento algo sobre




MapGuide que fue liberado su código, pero su empresa desarrolladora Autodesk, se ha quedado con algunos componentes que sigue comercializando.

Los tres programas de código abierto comentados junto con MapGuide, están bajo el paraguas de OsGEO, que es una fundación sin ánimo de lucro, que proporciona ayuda y promueve su utilización coordinando el trabajo de muchos programadores.

Para finalizar, se han comparado estos productos en cuanto al cumplimiento de las especificaciones OGC, y también se ha visto que especificaciones son las que mayor nivel de implantación tienen entre los productos de software para el tratamiento de información geográfica.




8. APLICACIONES CLIENTE PARA EL USO DE SERVICIOS WEB DE INFORMACIÓN GEOGRÁFICA

La utilización de los servicios web de información geográfica es muy variada. Por definición, los servicios son una interfaz que se colocan entre los datos y los usuarios, y permiten su interacción, sin depender de la plataforma de hardware o el lenguaje con el que se ha programado la aplicación cliente. Por tanto, hay diferentes formas de usar un servicio web de información geográfica.

Cuando se publicaron los primeros servicios WMS, lo normal era utilizarlos a través de un visor de mapas creado a propósito sobre una página web. Se debía utilizar un navegador de internet para utilizar el servicio. Con los primeros servicios de descarga (WFS) ocurría lo mismo, se seleccionaba sobre un visor la zona requerida y se pulsaba un botón para descargar el mapa en cuestión. El servidor enviaba un fichero GML comprimido para luego utilizarlo con nuestro programa de GIS. Al poco tiempo, estos programas de GIS empezaron a tener utilidades para incorporar la información de los servicios web.

Ahora es usual utilizar el servicio WMS para tener una cartografía de apoyo o una ortofoto de fondo mientras se trabaja con una aplicación GIS. También han surgido proyectos como Goolzoom o Wikiloc, que aportan valor añadido a los servicio web, mostrando unos visores de cartografía que son capaces de superponer diferentes capas extraídas de servidores en internet.

El siguiente paso puede ser la integración los servicios web de información geográfica en los sistemas corporativos, sobre todo de la administración pública. Se han hecho intentos, pero al final se acaba trabajando directamente sobre bases de datos distribuidas. Parece que ahora la tecnología puede permitir que, por ejemplo, cada departamento de un gobierno regional o local trabaje con su propio sistema de información geográfica, y que publique servicios para que los otros departamentos puedan visualizar, descargar o procesar sus datos, sin necesidad de hacer una grabación de datos en soportes físicos. En este caso los servicios web, podría solucionar los problemas que supondría crear un único GIS enorme, o tener una base de datos distribuida muy compleja, o incluo, hacer cambiar de tecnología a unos usuarios formados ya en otra.

Como se puede ver, hay formas muy diferentes de usar los servicios web, y eso es lo que se va a comentar a continuación; en función de los requerimientos, que tipo de aplicación se necesita para hacer uso de estos servicios.

8.1. Clientes ligeros

Dentro de una arquitectura cliente-servidor, se conoce como cliente ligero a aquella aplicación informática que se ejecuta en el ordenador “cliente” y la información la procesa en el servidor. Es el caso de los navegadores web (Internet Explorer, Firefox, Safari, etc.), que cuando se conectan a un servidor web, este construye una página extrayendo información de bases de datos, de ficheros o de imágenes, y se la envía al cliente para que la visualice en un leguaje sencillo (HTML); el navegador interpreta este lenguaje y nos enseña la página. Este es el caso más sencillo que se puede dar, luego se puede ir complicando al utilizar tecnologías que procesan parte de los datos en el cliente para hacer más ágil el proceso (AJAX, Flash, SilverLight, JavaFX, etc.) y ganar en interactividad.




Los clientes ligeros usan normalmente los geoservicios a través de los geoportales que se crean como punto de entrada a las infraestructuras de datos espaciales. En los geoportales, suelen existir un gran número de aplicaciones preparadas para usar cada tipo de servicio. Por ejemplo, para consultar metadatos, es normal que sea una aplicación sobre navegador, es raro encontrar un programa GIS de escritorio que sea capaz de conectarse a un servicio de localización (CSW). Es muy normal que un geoportal disponga de un visor para cargar servicios WMS, y que una vez visualizada la información con este servicio, se pueda proceder a descargarla con otro servicio (WFS).

8-1 Aplicación cliente para la consulta de nombres geográficos (Geoportal de la IDEE).

Por tanto, con este tipo de aplicaciones, se tiene la ventaja de que no tenemos que disponer de software para acceder, consultar y procesar datos espaciales, todo lo podemos hacer con un sencillo navegador. Sin embargo, cualquiera de estas operaciones está mucho más limitada en esta tecnología que si usamos un cliente pesado.

8.2. Clientes pesados

En este caso, el procesamiento de los datos se hace en la “parte cliente”, por tanto, lo que hace normalmente el servidor es enviar la información y el programa la procesa en el propio ordenador. Este tipo de acceso a los servicios web se utiliza normalmente para descargar geometrías (WFS) o coberturas (WFS). También se utiliza bastante el servicio de visualización (WMS) para tener cartografía de referencia o para imprimir como fondo de capas vectoriales.

Cuando los servicios de descarga sean más numerosos y más estables, los programas de GIS podrán estar trabajando con la información de múltiples bases de datos a lo largo de internet. La aplicación se conecta al servicio, descarga la




información a través de un servicio WFS y realiza los geoprocesos, pero no devuelve la información al servidor, pues este servicio no está preparado para esta operación. Para poder devolver la información procesada está el servicio WFS-T (transaccional) que es un servicio de descarga que luego pude reenviar los datos al servidor bajo ciertas condiciones.

Prácticamente todas las aplicaciones GIS de escritorio, como ArcGIS, Geomedia, GvSIG, etc., disponen de conexiones a datos mediante servicios web, usándose WMS, WFS y WCS. Los servicios de localización para búsqueda en catálogo de metadatos están empezando a aparecer en estos programas, pero su funcionamiento todavía no es muy normal, ya que el propio servicio CSW no está muy implantado.

8-2 Conexiones a datos disponibles en Geomedia.

Como se puede ver en la imagen superior, en un programa como Geomedia, cuando el usuario desea conectarse a un repositorio de datos, entre las opciones de las diferentes bases de datos o ficheros, aparecen los servicios web como un proveedor de datos más.

En estas aplicaciones, el problema puede surgir cuando se quieran conectar a servicios interoperables pero que no sigan un estándar del mercado. Se puede dar el caso de que se cree un servicio de descarga, que siga los requerimientos de INSPIRE, que utilice el protocolo SOAP recomendado también por Europa, pero al estar en el mercado, las aplicaciones no saben utilizarlo; por tanto, necesitaran que se desarrollen interfaces especiales para la conexión a este servicio. En este caso, se demuestra lo interesante que es que la industria esté implicada en la estandarización.




8.3. Desarrollo de aplicaciones

Los servicios web son módulos de software que realizan tareas, a los que se accede y se llama a través de una red, sobre todo internet. El desarrollador puede crear una aplicación cliente que llama a una serie de servicios web mediante llamadas a procedimientos o a un servicio de mensajes en los que se proporciona un fragmento o la mayor parte de la descripción de la aplicación. Los servicios web publicados se describen de forma que los desarrolladores pueden localizarlos y determinar si se ajustan a sus necesidades.

Permiten una gran versatilidad en su uso; por tanto, la forma de alcanzar el máximo rendimiento es desarrollando aplicaciones con componentes o librerías que permitan el manejo de la información geográfica. En este sentido, dentro del mundo del software libre hay una gran cantidad de entornos de desarrollo que son capaces de crear aplicaciones hibridas, que utilizan tecnologías web mezcladas con módulos de procesado en el ordenados cliente, y permiten crear herramientas muy útiles, y sobre todo, adaptadas a las necesidades de los usuarios.

En este momento, pensar en desarrollar un entorno corporativo para la gestión y difusión de la información geográfica es sencillo, pues existe una gran variedad de herramientas, y gracias a la interoperabilidad que demuestran, se puede concebir el proyecto utilizando componentes pertenecientes a diferentes entornos, aprovechando así la mejor funcionalidad de cada uno de ellos.

8.4. Sumario

Como la cantidad de herramientas que hay en el mercado para el uso de la información geográfica a través de servicios es enorme, en este apartado se ha repasado brevemente los diferentes entornos en que el usuario puede utilizar los servicios web. Se comentado la diferencia que hay entre trabajar con clientes ligero o gestionar los datos con aplicaciones de escritorio o clientes pesados. Y se ha finalizado con un pequeño paso por las ventajas del desarrollo de aplicaciones y componentes para la gestión de la información geográfica.

Como se ha visto en capítulo, la frontera entre lo que se ha distinguido como clientes ligero y pesados, cada vez es más difusa y con la aparición en escena de nuevas tecnologías en el desarrollo de software, la tendencia es a trabajar de una forma más hibrida.




9. CONCLUSIONES

En este capítulo se va a resumir el trabajo y a presentar una serie de consideraciones para el uso de los servicios web, obtenidas tras el análisis de la legislación, de las especificaciones y de la industria del software.

El trabajo ha sido motivado por la necesidad de determinar qué servicios de información geográfica son necesarios para que las organizaciones productoras de datos cumplan los preceptos de la directiva INSPIRE. Para realizar esa labor ha sido necesario buscar el equilibrio entre la legislación y la industria, teniendo en cuenta que en la redacción de las especificaciones, las empresas tienen un papel fundamental.

9.1. Consideraciones generales

La directiva INSPIRE, de obligado cumplimiento en todos los estados miembros de la UE, en su reglamento de servicio de red exige unos requerimientos para todos los servicios web de información geográfica que se publiquen en las infraestructura de datos espaciales de las administraciones públicas. Para estos servicios se definen unas características, un conjunto de criterios de calidad a cumplir y unas fechas para fijar su puesta en funcionamiento.

Por tanto, a la hora de establecer los servicios que conforman un IDE, se debería considerar lo siguiente:

• Crear servicios web no implica que se esté creando una infraestructura de datos espaciales. El concepto de IDE es algo más; supone que se debe que disponer de datos armonizados, metadatos de estos datos y los servicios, y sobre todo, políticas de datos que implique una coordinación a la hora de producir, gestionar y distribuir la información geográfica sobre la que se tiene competencia.

• La reglamentación INSPIRE recomienda el uso de estándares aceptados por la industria y que estén en funcionamiento, que es el caso de las especificaciones OGC.

• Las especificaciones OGC no llegan a cumplir completamente los requerimientos de INSPIRE, aunque se traten de estándares de la industria del software.

• La legislación permite que se puedan establecer servicios de información geográfica que no sigan los estándares, siempre que se ajusten a sus requerimientos..

• La creación o modificación de especificaciones por parte de la industria lleva un ritmo diferente a la generación de recomendaciones o reglamentos por parte de la administración.

• Existe una gran cantidad de documentación entre reglamentación, guías técnicas de implantación, especificaciones y recomendaciones que puede llegar a confundir a los administradores de las IDEs.

• La tecnología SOAP parece que se va a imponer en los servicio de información geográfica, pero las especificaciones de estos tienen que adaptarse.




• Es muy importante tener los servicios almacenados en un catálogo, con sus metadatos visibles a todos los usuarios. Las especificaciones para catalogar servicios todavía no están muy definidas.

• Actualmente, los servicios web de información geográfica son muy inestables, no se observan criterios para asegurar una calidad mínima. Es un campo en el que se ha trabajado poco.

• En la industria del desarrollo de software geográfico se trabaja muy bien en la implantación de los estándares. En las comunidades de software libre, hay muchos desarrolladores creando productos muy buenos.

9.2. Recomendación sobre servicios web en una IDE

Según Nebert [1], para una “satisfactoria implantación de una IDE se requiere la adopción de un conjunto de estándares para hacer posible la interoperabilidad. La proliferación de estos estándares y de nuevas versiones de viejos estándares eleva los temas de dependencia y compatibilidad que pueden impedir la implementación de la arquitectura de una IDE”.

Las recomendaciones que se pueden realizar tras el análisis efectuado en este trabajo se puede concretar en:

• Se debe tener en cuenta las diferentes versiones de las especificaciones sobre servicios a la hora de publicarlos en una IDE, pues dentro de los geoportales, se van a desarrollar aplicaciones cliente que acceden a servicios propios, con los que no habrá problema, pero también hay que posibilitar el acceso a otros servicios de otras IDE.

• En los servicios de localización, es muy complicado acceder a los metadatos distribuidos. Las aplicaciones cliente de consulta en catálogos de metadatos no son capaces a enlazar fácilmente a otros catálogos que no sean los de su propia IDE.

• Los servicios de visualización están muy extendidos, pero su funcionamiento es lento. Se debería pensar en mejorar el rendimiento con la especificación WMTS o con servicios de caché.

• En muchas IDEs los servicios de descarga sólo permiten obtener ficheros GML. Sería muy interesante que se dispusiera de un servicio WFS para descarga, pues así se podría utilizar desde aplicaciones GIS.

• Debería empezarse a pensar en servicios de procesamiento o transformación para ofrecer más funcionalidades. Si se dispusiera de buenos servicios de transformación, para muchos trabajos nos se necesitaría una aplicación GIS de escritorio, sino que se podría utilizar el navegador como un verdadero programa de gestión de información geográfica.

• Es necesario que se trabaje en adaptar las especificaciones de la industria a los requerimientos de INSPIRE. Si esto se realiza con desarrollos individualizados, el coste será muy alto.

Después de analizar la legislación, los estándares y la industria, se puede establecer la siguiente relación de servicios para que una infraestructura de datos espaciales cumpla con los requerimientos que se le imponen, y teniendo en




cuenta las puntualizaciones que se han realizado en los capítulos anteriores respecto a que sólo aplicando la especificación OGC de cada servicio no se llega a cumplir completamente con lo requerido en la directiva INSPIRE. En la tabla se recomienda el uso de una especificación OGC para cada tipo de servicio INSPIRE, excepto para el servicio de descarga, que se proponen dos, uno para datos vectoriales y otro para datos ráster.

Requerimiento INSPIRE Norma/estándar Servicio de localización CS-W 2.0 Servicio de visualización WMS 1.3 Servicio de descarga (vectorial) WFS 1.1 Servicio de descarga (ráster) WCS 1.0 Servicio de transformación WPS 1.0

9-1 Recomendación de servicios de red para una IDE

Por tanto, a los servicios implementados con las especificaciones de esta lista habría que completarlos con pequeños componentes para llegar a cumplir estrictamente con las operaciones que requiere el reglamento de servicios de red.

A esto hay que añadir los criterios mínimos de calidad de funcionamiento de los servicios, que son exigentes si se compara con el rendimiento de las aplicaciones que hay en el mercado, sobre todo en el aspecto rendimiento (tiempo de respuesta del servicio) y fiabilidad (porcentaje de tiempo funcionando), Quizá el tiempo de respuesta no es problema de las aplicaciones y si es debido a la infraestructura informática, pero la fiabilidad es una verdadera dificultad para una organización que quiere publicar sus datos a través de servicios.

Probablemente, la solución a los problemas con las operaciones de los servicios web sea el uso del protocolo SOAP sobre las especificaciones OGC; por lo menos esto es lo que recomienda INSPIRE, y dada la colaboración que parece existir entre ambos organismos, se estará trabajando en una nueva versión de las especificaciones. En cuanto al mantenimiento de la calidad, seguramente el uso de un protocolo ampliamente utilizado, como lo es SOAP, facilitará a los administradores de sistemas mantener el rendimiento y la fiabilidad de los servicios web a un nivel alto.

9.3. Resumen final

En este trabajo se ha repasado todos los aspectos que conciernen a la publicación de servicios web o servicios de red, dentro del marco que determina la directiva INSPIRE en Europa. Se empezó repasando la legislación determinada por la Unión Europea; luego se estudió el aspecto de la normalización desde el punto de vista de la industria; se continuó con aspectos como catalogación y calidad de los servicios, para después ver las aplicaciones existentes para publicar y utilizar geoservicios.

Y para concluir, se han realizado unas recomendaciones y unas consideraciones generales que se resumen a continuación:

• Se está realizando un gran esfuerzo en todos los aspectos y desde todos los niveles, ya que el uso de los servicio representa el futuro de la tecnología GIS.




• Se debería buscar un mayor equilibrio entre los estándares de la industria y los requerimientos de la legislación.

• Muchos administradores de las IDEs funcionan más próximos a la industria que a la reglamentación vigente.

• La incoherencia en la documentación genera confusión entre la comunidad de gestores, industria y usuarios.

• La calidad no se está teniendo en cuenta en las IDEs actuales; es una tarea pendiente para los próximos meses.

• Se debe trabajar más en la catalogación de los servicios para que su búsqueda sea más rápida y efectiva.

El trabajo ha estudiado los servicios web en las IDES, que aunque todavía están en un estado inicial de implantación, la evolución de la tecnología parece que va darles un gran protagonismo como parte fundamental de la arquitectura de los sistemas de información geográfica corporativos o de las infraestructuras de datos espaciales. Las bases están creadas y ahora sólo hace falta creer en ellos para diseñar las nuevas aplicaciones en base a su funcionamiento.




Anexo I: CONFIGURACIÓN DE UN SERVICIO OGC

Como complemento al trabajo, se ha realizado la tarea práctica de poner en marcha un servicio web conforme a una especificación OGC. Para ello, se han empleado dos tecnologías muy diferentes en muchos sentidos, pero sobre todo porque una es un software comercial con un precio de mercado, Geomedia WebMap, y otra es software de código abierto, MapServer. El servicio seleccionado para probar es el Web Map Service (WMS).

Se ha confeccionado una tabla que compara las características principales de estas dos plataformas, en las que se profundizará cuando se describa el trabajo con ellas.

MapServer Geomedia WebMap Código abierto, gratuito Código restringido, comercial Funciona sobre Apache, con PHP Trabaja sobre Internet

Information Server (IIS), con ASP. Usa fichero de texto para configuración de los servicios “.map”.

Almacena la configuración en tablas especificas de la base de datos.

Se ayuda de otras aplicaciones para agilizar la creación de ficheros de configuración.

Dispone de asistentes para crear los registros de configuración.

Se puede crear el fichero “.map” de manera manual, no es muy complicado.

La base de datos de configuración es muy difícil modificarla a mano, y crearla es imposible.

Para realizar las pruebas se han usado un conjunto de datos en formato “.shp” extraídos de la IDECyL y otros de elaboración propia utilizados en otras tareas de este Máster. Los datos se corresponden a la cartografía 1:10.000 de la ciudad de Ávila.

1. Servicio WMS con MapServer

Para empezar se busca la aplicación para descargar desde la página web MapServer.org. Se ofrecen varias opciones: descargar el programa o descargar todo el entorno servidor con alguna aplicación complementaria. Se elige la segunda opción ya que al mismo tiempo que se instala MapServer se instala también Apache y se configura todo de forma conjunta. Entre los tres conjuntos de aplicaciones que hay para el sistema operativo Windows, se escoge el paquete MS4W desarrollado por MapTools.org. El propósito de este paquete es permitir a los usuarios de todos los niveles instalar rápidamente un entorno de trabajo para el desarrollo de MapServer en Windows. Con esta instalación también se forma un entorno de empaquetado y distribución de aplicaciones MapServer.

En la red hay documentación abundante para realizar este trabajo, la utilizada en este caso ha sido un paquete con documentación y datos de prueba que tiene publicado el Geoportal de la IDEC [10].




También hay una guia en la OsGEO que relata de forma muy sencilla los pasos a seguir: http://wiki.osgeo.org/wiki/Crear_servicios_WMS_y_WFS_ con_MS4W_y_gvSIG_utilizando_nuestro_propio_juego_de_datos.

Para instalar el servidor, se descarga un paquete llamado MS4W v3.0-beta11 desarrollado para usar bajo sistema operativo Windows desarrollado por Gateway Geomatics. Este producto gratuito esta diseñado para ayudar a poner en marcha un servidor de mapas MapServer con facilidad y sin tener que poseer elevados conocimientos en programación. Además, hay disponibles una serie de paquetes con diferentes configuraciones y ejemplos para montar un verdadero servidor de mapas con servicios OGC.

MS4W contiene las instalaciones por defecto de Apache, PHP, MapServ, MapScript y algunas aplicaciones de ejemplo. Está estructurado de tal forma que permite la actualización de componentes individuales sin afectar a la instalación. El paquete de instalación base viene preconfigurado con el siguiente software:

• MapServer Utilities • Apache HTTP Server v. 2.2.15

• PROJ Utilities • PHP version 5.3.2

• Shapelib Utilities • MapServer CGI 5.6.3

• Shp2tile Utility • MapScript 5.6.3 (CSharp, Java, PHP, Python) • Shpdiff Utility

• Includes support for Oracle 11g, and SDE data (if you have associated client/dlls)

• AVCE00 Utilities

• OGR/PHP Extension 1.0.0

• MrSID support built-in

• GDAL/OGR 1.7.1 and Utilities

• OWTChart 1.2.0

Se comienza la instalación siguiendo las instrucciones, y para ello se descomprime el fichero que se ha descargado y desde la ventana de comandos, se ejecuta el fichero apache-install.bat. Con este ejecutable, se instala y configura el servidor Apache, necesario para que un ordenador sea capaz de servir páginas web con lenguaje PHP y por supuesto, HTML. Además, de instalar el servidor, configura los ficheros de MapServer de de los otros productos, de forma que queda un ordenador personal configurado como servidor de páginas web de una forma muy sencilla.



http://www.gatewaygeomatics.com/

http://www.gatewaygeomatics.com/


Después de instalar MapServer, se procede a poner en marcha el servicio WMS. Se empieza con un ejemplo que viene con el manual de Mapserver elaborado por la IDEC [10]. Este documento es muy ilustrativo para empezar a trabajar con este producto. Primero explica de una manera muy sencilla lo que es un servicio WMS, y después lo pone en práctica con el programa MapServer. En este caso solo se han usado los datos y los ficheros de configuración, ya que el servidor ya estaba montado.

El fichero de configuración “.map” se puede hacer a manualmente o utilizar algún programa que lo genere. Es este caso se ha utilizado GvSIG v 1.1.2 con la extensión de publicación. Primeramente se crea una vista sa partir de las capas en formato shape. Para probar se utilizan varios conjuntos de datos: el que proporciona el paquete IDEC, unas capas de municipios y fichero ráster de Galicia y el conjunto de datos la ciudad de Ávila.

Una vez que se ha preparado la vista con la simbología que se quiere mostrar y las escalas de visualización de cada capa, se procede a publicar. GvSIG lo que realmente hace es prepara el fichero de configuración “.map” con los datos que le proporciona la vista.




Desde la ventana del gestor de proyectos, se entra en la opción Publicación, se crea una nueva publicación y aparece la siguiente ventana para que definir el servidor en donde se va a publicar el servicio.

Publicación del servicio desde GvSIG.

Una vez elegida la URL del servicio, la que indica el directorio virtual que los usuarios van a ver. En este caso aparece http://localhost/ para llamar al servicio desde la propia máquina. Luego se cambia y se pone la URL externa del servicio. También se elige el tipo de tecnología de servidor entre MapServer y GeoServer, y el tipo de servicio: WMS 1.1.1, WFS 1.0.0 y WCS 1.0.0. Se elige Mapserver y WMS.

Después de aceptar se abre una ventana con tres pestañas. En la primera se pide el nombre del fichero de configuración y la carpeta en la que va a estar contenido. En la segunda, se coloca en nombre del servicio y una descripción del mismo. Y en la tercera pestaña, se seleccionan las capas de nuestra vista creada anteriormente y se les añade metadatos a cada capa. No hace falta cargar todas las capas, se pueden cargar las que se quiera.

Edición de los parámetros de configuración del WMS.

Al finalizar de rellenar todos esos datos y se pulsa en Publicar para que se genere el fichero “.map”.

Mensaje para confirmar la publicación.

Ahora ya tenemos nuestro servicio creado, se puede editar el fichero de

configuración para modificar lo que se quiera: metadatos, simbología, añadir o quitar capas, sistemas de referencia de coordenadas, etc.



http://localhost/


El fichero de configuración “.map” que se crea es el siguiente:

MAP NAME map_generated_by_gvsig EXTENT 350225.6476999996 4498366.712099999 364407.03170000017 4503689.775391845 SHAPEPATH "c:\ms4w\mapas" SYMBOLSET "wmsavila2.sym" FONTSET "fonts.txt" LEGEND IMAGECOLOR -1 -1 -1 LABEL FONT "vera" ANGLE FOLLOW COLOR 0 0 0 ENCODING "UTF-8" TYPE truetype SIZE 8 END STATUS ON TRANSPARENT ON END WEB IMAGEPATH "C:\ms4w\mapas\temp" METADATA "wms_encoding" "UTF-8" "wms_title" "Servicio WMS del callejero de Avila" "wms_abstract" "Prueba de WMS con los datos de rutas de Avila" "wms_srs" " EPSG:23030" "wms_onlineresource" "http://localhost/cgi-bin/mapserv?map=/ms4w/mapas/wmsavila2.map" END END PROJECTION "init=epsg:23030" END LAYER NAME "vias_comunicacion" STATUS ON TYPE LINE DATA "C:\ms4w\mapas\avila\vias_comunicacion.shp" MAXSCALE -1.0 MINSCALE -1.0 TRANSPARENCY 100 DUMP TRUE TEMPLATE "." SIZEUNITS pixels PROJECTION "init=epsg:23030" END CLASS STYLE COLOR 255 0 51 WIDTH 1 END NAME "default" END METADATA "wms_title" "vias_comunicacion" "wms_abstract" "Carreteras extraidas de la cartografia a escala 1:10.000 de IDECyL" "wms_extent" "350225.6476999996 4498366.712099999 364407.03170000017 4503262.5736" "gml_include_items" "all" END END # Layer




LAYER NAME "edificios" STATUS ON TYPE POLYGON DATA "C:\ms4w\mapas\avila\Edificios.shp" MAXSCALE -1.0 MINSCALE -1.0 TRANSPARENCY 100 DUMP TRUE TEMPLATE "." SIZEUNITS pixels PROJECTION "init=epsg:23030" END CLASS STYLE COLOR 255 204 51 OUTLINECOLOR 153 0 51 WIDTH 1 END NAME "default" END METADATA "wms_title" "edificios" "wms_abstract" "Edificaciones de la ciudad de Avila." "wms_extent" "350225.6476999996 4498366.712099999 364246.6520999996 4503262.5736" "gml_include_items" "all" END END # Layer LAYER NAME "RutaBomberos" STATUS ON TYPE LINE DATA "C:\ms4w\mapas\avila\RutaBomberos.shp" MAXSCALE -1.0 MINSCALE -1.0 TRANSPARENCY 100 DUMP TRUE TEMPLATE "." SIZEUNITS pixels PROJECTION "init=epsg:23030" END CLASS STYLE COLOR 255 0 0 WIDTH 5 END NAME "default" END METADATA "wms_title" "RutaBomberos" "wms_abstract" "Recorrido de ejemplo de una intervencion de los bomberos." "wms_extent" "356127.78369877476 4502056.385851713 358072.8561931228 4503278.615174131" "gml_include_items" "all" END END # Layer END # Layer END # Map File




2. Publicación con Geomedia WebMap

La forma de proceder para publicar un servicio WMS con Geomedia WebMap es muy similar a los que se ha vistos con MapServer y GvSIG. Sobre un programa GIS de escritorio se cargan las diferentes capas y se les asigna simbología y escalas de visualización; luego se publican en un directorio virtual de Internet Information Server (IIS).

Geomedia WebMap es el programa de servidor de la familia de productos Geomedia, desarrollada por la empresa Intergraph. Para hacer la primera parte del proceso, se utiliza el producto de escritorio Geomedia Professional, que es el programa destinado a la captura, edición y análisis de datos vectoriales. Se importan los ficheros en formato “.shp” y se almacenan en una base de datos MS Access con el formato de geometrías de Geomedia. Se podría publicar desde el fichero shape, pero el programa es más eficaz con la información en una base de datos.

Datos de Ávila sobre Geomedia Professional.

El programa dispone de un comando llamado GWM Publisher para activar el asistente de publicación en web. Al activarlo, el programa pide los datos del sitio web en donde se van a publicar los datos. Este directorio virtual debe estar creado antes con el administrador del Internet Information Server.

Después se elige el tipo de publicación o servicios que se quiere realizar. Las opciones son: WMS, WFS y aplicación web. Esta última no es un servicio, sino que el programa genera todo el código necesario para hacer una aplicación web para usar en un navegador. Se elige el servicio WMS y aparecen las siguientes ventanas:




Inicio y comandos del asistente de publicación de Geomedia

Una vez que se ha seleccionado el lugar de la publicación, empezamos el proceso propiamente dicho de seleccionar cada una de las capas, ajustar su simbología, sólo si se quiere cambiar la que viene de Geomedia Professional, y asignarle los sistemas de referencia de coordenadas.

Asignación de sistema de referencia de coordenadas al servicio WMS.

Ya está todo el proceso prácticamente finalizado, sólo falta repasar las capas por si se quieren agrupar en temas, pues la especificación WMS 1.3.0 permite esta opción. Si se confirma este formulario, el servicio queda publicado.

Con este conjunto de aplicaciones de Geomedia, como se decía al principio, no se genera un fichero de configuración como en MapServer, sino que se crea una base de datos en formato MSAccess que guarda todos los metadatos de la configuración de los servicios, que son prácticamente los mismos que en el




fichero “.map”. Es mucho más complejo y no es fácil modificarlo a mano, se puede caer en incosistencias.

Listado de tablas de la base de datos de configuración de Geomedia WebMap.

El servicio se ha creado sobre un servidor de prueba de la IDE de Galicia y para invocarlo desde un navegador hay que poner las siguientes sentencias:

GetCapabilities: http://ideg.xunta.es/wms_avila/request.aspx?VERSION=1.3.0&REQUEST=GetCapabilities&service=WMS

Fichero GetCapabilities del WMS formateado en HTML.

Una vez que conocemos sus características a partir del fichero de capacidades, se puede crear una URL para ver el mapa que proporciona en un navegador:

GetMap: http://ideg.xunta.es/wms_avila/request.aspx?VERSION=1.3.0&REQUEST=GetMap&LAYERS=Edificios,vias_comunicacion,RutaBomberos&CRS=EPSG:23030&BBOX=355600,4500000,358460.1,4501679.73&WIDTH=800&HEIGHT=800&FORMAT=image/png&STYLES=&EXCEPTIONS=application/vnd.ogc.se_xml&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE




Invocación del servicio WMS desde el navegador FireFox.

Y también se puede ver sobre GvSIG:

Capa WMS sobre GvSIG.




Anexo II: GUÍA PARA EL USO DE GEOSERVICIOS

En este apartado se van a dar unas directrices para el uso de los servicios web básicos de una IDE, enfocadas a los usuarios de programas de gestión de sistemas de información geográfica. Para ello, se van a usar los programas más utilizados por los profesionales en el manejo de los datos espaciales: ArcGIS, Geomedia y GvSIG. Además se comentan alguna de las aplicaciones cliente que se encuentran los geoportales de las IDEs para el uso de servicios.

Tipos de servicios

En la actualidad, hay una gran variedad de servicios publicados, y prácticamente todos, están elaborados siguiendo las especificaciones del Open Geospatial Consortium para servicios de información geográfica. Se clasifican de la siguiente forma:

CS-W (Catalog Service): servicio de localización de datos a partir de los catálogos de metadatos. Por lo general este servicio se utiliza a través de una aplicación web desarrollada expresamente para su uso. No se suele utilizar en aplicaciones de escritorio.

WMS (Web Map Service): servicio de visualización de mapas; proporciona imágenes de mapas georreferenciados a las bases de datos geoespaciales distribuidas en una red. Una solicitud WMS define las capas de información y el área de interés para ser procesado. La respuesta a la solicitud es una o más imágenes de mapa georreferenciado (JPEG, PNG, etc.) que pueden mostrarse en una aplicación de explorador o de escritorio.

WFS (Web Feature Service): servicio de descargas; permiten descargar copias de conjuntos de datos espaciales, o partes de ellos y, cuando sea posible, acceder directamente a ellos. La descarga se realiza en formato GML (Geographic Markup Language), aunque la mejor forma de trabajar con este servicio es a través de las aplicaciones GIS de escritorio. Los datos descargados con este servicio van codificados en forma de GML y

WCS (Web Coverage Service): servicio de descargas; permite la descarga de información geográfica en forma de coberturas, es decir, información geográfica asociada a posiciones con valores de atributo dentro de un espacio limitado (mapa ráster, imagen de satélite, modelo digital de elevaciones, etc.).

WPS (Web Processing Service): servicio de transformación; define una interfaz estandarizada que facilita la publicación de procesos geoespaciales, y además permite que estos sean fácilmente localizables para que las aplicaciones cliente se puedan conectar a ella. Hay tantas clases de servicios de procesado como procesos sequieran crear. Para utilizar este tipo de servicios hay que diseñar una aplicación cliente a medida de cada un clase de procesado.



http://www.opengeospatial.org/

http://www.opengeospatial.org/


Funcionamiento básico

El proceso de funcionamiento de estos servicios es muy similar aunque el resultado que se obtiene es muy diferente. Los pasos a seguir son:

1. La aplicación cliente pide al servidor un fichero con las posibilidades o capacidades del servicio mediante una operación que se llama GetCapabilities. Dicho fichero contiene una descripción de todas las operaciones que admite el servicio y una serie de datos adicionales que dependen del tipo de servicio (capas, istemas de referencia de coordenadas, metadatos, excepciones, restricciones de uso, etc.).

2. Opcionalmente, la aplicación cliente puede realizar una solicitud al servicio para que le facilite la definición de uno o más elementos. Sólo funciona en los servicios de descarga y transformación.

3. Basándose en las operaciones disponibles y en las capas o tipos de información que ha recibido, la aplicación cliente genera una solicitud al servicio sobre un área determinada (BoundingBox).

4. La solicitud se envía al servidor web que aloja el servicio.

5. Se invoca al servicio para leer y atender la solicitud.

6. Cuando el servicio ha completado el procesamiento de la solicitud, generará un informe de estado y envía el resultado al cliente. En caso de que se produzca un error, el informe de estado indicará este hecho.

Toda las comunicaciones entre servidos y cliente se realizan mediante fichero en formato XML. La utilización de cualquier servicio se puede hacer con un navegador de internet si se entienden los ficheros XML. Pero lo más normal es que se diseñen aplicaciones para realizar estas operaciones.

Catálogos y directorio de servicios

Como se ha comentado, se necesita conocer la dirección del servicio para poder acceder a él. Las IDEs disponen de catálogos con los servicios bien descritos. Otra opción son los directorios de servicios, que simplemente almacenan el enlace a los servicios en una lista jerárquica. Este producto es más utilizado por su baja complejidad. A continuación se detalla la dirección del catálogo y el directorio de la IDE española que posee más de 800 referencias:

Catálogo de servicios de la IDEE: http://www.idee.es/IDEE-ServicesSearch/.

Directorio de servicios de la IDEE: http://www.idee.es/CatalogoServicios/ CatServ/ directorio_servicios.html

Pasos a seguir

La descripción del uso de un servicio se va a realizar con un servicio WMS, y sería similar para WFS y WCS. Si en algún paso, el proceso difiere para otro servicio, se comentará. Para el servicio de localización, se comentará en otro apartado; y para el servicio de transformación, no se puede describir este proceso pues va a ser diferente para cada caso de procesamiento y no se puede utilizar por ahora con aplicaciones GIS.




I. Localizar el servicio

Lo primero que hay que hacer es buscar la dirección del servicio que quiere usar. Como el propio nombre indica, al ser un servicio web, la dirección es una URL que indica el nombre del servidor y de las carpetas en donde está publicado. Un ejemplo es esta dirección del servicio de visualización de mapas de la IDEE:

http://www.idee.es/wms/IDEE-Base/IDEE-Base?

Otras veces la URL finaliza sin el signo de interrogación como en este caso:

http://ideg.xunta.es/WMS_sg/Request.aspx

En alguno programas es necesario utilizarlo siempre, así que , si no lo lleva, se le puede poner el signo de interrogación al final de la URL que obtenemos del catálogo o página web.

II. Enlazar

Ahora hay que llamar al servicio para que envíe sus características. Para ello en cada programa tiene una función diferente. Normalmente está situada en el apartado de cargar capa o establecer conexión a datos.

En GvSIG, se utiliza la función Añadir Capa, y se lanza el formulario siguiente (izquierda) en el que se elige la pestaña de WMS y aparece una caja de texto con la etiqueta Servidor para introducir la URL. Cuando se pulsa el botón Conectar, la aplicación pide el fichero de capacidades del servicio y lo muestra en el mismo formulario sobre tres pestañas (derecha):

En la primera pestaña muestra la información general del servicio, es decir, los metadatos del servicio. En la siguiente pestaña que se ve en la siguiente imagen (izquierda) muestra la información de las capas disponibles en el servicio. Podemos seleccionar las que queremos cargar. Y en la tercera pestaña (derecha),



http://www.idee.es/wms/IDEE-Base/IDEE-Base?REQUEST=GetCapabilities&SERVICE=WMS

http://ideg.xunta.es/wms_sg/request.aspx?REQUEST=GetCapabilities&SERVICE=WMS


nos muestra los formatos gráficos disponibles y los sistemas de coordenadas que soporta el servicio. También permite elegir antes de hacer la petición.

Una vez seleccionadas las capas, el formato del fichero y el sistema de coordenadas, se debe pulsar en Aceptar para que el programa ejecute la siguiente operación.

Con ArcGIS es muy similar con la diferencia que toda la información la muestra en un formulario sin pestañas.




En Geomedia, se ejecuta la función Conexión nueva, y aparece el siguiente formulario, en donde se elige el tipo de conexión, en este caso WMS. Pide el nombre que le vamos a dar a la conexión, la descripción y la URL del servicio:

Luego aparece otra ventana con la relación de capas diponibles y se marcan las que se vayan a visualizar:

Al aceptar este formulario, se piden al servidor las capas marcadas.

III. Agregar la información

Este es el último paso que se debe realizar para obtener los datos, pero al usar estos asistentes que ayudan a conectarse al servicio, para el usuario no es más que aceptar los antes ha ido seleccionando.

La programa de GIS hizo en el segundo paso la operación GetCapabilities, cargó los datos descriptivos del servicio en estos asistentes que se han visto, y el




usuario ha seleccionado el área, las capas, el sistema de coordenadas y el formato. Y ahora al aceptar, envio al servidor estos datos con las operaciones GetMap para WMS, GetFeature para WFS o GetCoverage para WCS.

Al realizar estas operaciones, la aplicación GIS recibe del servidor la información y la organiza como unas capas más dentro del listado de capas que ya posee el usuario.

Servicios de localización:

Para utilizar este servicio, es necesario tener una aplicación cliente que pueda conectar con el servidor para ejecutar las operaciones propias de este servicio. En la siguiente imagen se muestra la aplicación cliente disponible en el geoportal de la IDEE (http://www.idee.es/csw/client.html), que es bastante clara en el uso de las diferentes operaciones de la especificación.



http://www.idee.es/csw/client.html


Como se puede ver en la imagen, se trata una aplicación web cliente que permite realizar las operaciones que disponibles en el servicio CS-W.

Cuando se quiere consultar un catálogo, la aplicación cliente utiliza la operación GetCapabilities para conocer los detalles del servicio. Si no conoce la estructura del sistema de almacenamiento, utiliza la segunda operación DescribeRecord. Para realizar la consulta, se usa GetRecords. Esta operación da una lista de los registros que cumplen la query que se envía dentro de la operación y que en el formulario se puede construir con las cajas de texto llamadas Tema, Categoria, Proveedor y con el mapa para definir el área de búsqueda. Con GetRecordsByld se obtiene los metadatos del registro seleccionado de la lista.




Referencias

[1] Introducing SDI 1.0: A Compatible Standards Suite. D. Nebert. U.S. Federal Geographic Data Committee Secretariat. Septiembre 2006

[2] Proposal for a Spatial Data Infrastructure Standards Suite: SDI 1.0. D. Nebert, C. Reed, and R. Wagner. 2007. Harlan Onsrud) (ed.), Research and Theory in Advancing Spatial Data Infrastructure Concepts. Redlands, CA: ESRI Press ISBN: 978-1-58948-162-6.

[3] Building INSPIRE: The Spatial Data Infrastructure for Europe. Max Craglia, Joint Research Centre of the European Commission. Primavera 2010 http://www.esri.com/news/arcnews/spring10articles/building-inspire.html.

[4] Development and Status of the U.S. National Spatial Data Infrastructure: Concepts and Components D. Nebert, U.S. Federal Geographic Data Committee Secretariat, Marzo 2006,

[5] Guía Breve de Servicios Web. Oficina española del W3C. 06/05/2010 en http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb

[6] QoS for Web Services: Requirements and Possible Approaches. W3C Working Group Note 25 November 2003. http://www.w3c.or.kr/kr-office/TR/2003/ws-qos/

[7] Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica. 28/01/2010 BOE.

[8] Desarrollo de un cliente web rico-OGC. M. Montesinos, J. Carrasco, C. Larrea. JIDEE06. Castellón 2006.

[9] Registered Products Open Geospatial Consortium, en http://www.opengeospatial.org/resource/products.

[10] Instalación y configuración de un servidor de mapas. Versión 3.0, 14 octubre 2009. IDEC. http://www.geoportal-idec.cat/geoportal/ .

[11] Servidores de mapas. Jorge G. Sanz Salinas 07-04-2009 https://confluence.prodevelop.es/display/pan/Servidores+de+mapas

[12] Normalización de la información geográfica. F. J.García, A. Rodríguez Pascual, Mapping Interactivo. http://www.mappinginteractivo.com/plantilla-ante.asp?id_articulo=1451 Enero 2008

[13] Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE. Nogueras-Iso J, J. Barrera, A. F. Rodríguez, R. Recio y C. Laborda (2008). In Actas de las V Jornadas de la Infraestructura de Datos Espaciales de España (JIDEE 2008), 5-7 Noviembre 2008.

[14] Development and deployment of a services catalog in compliance with the INSPIRE metadata implementing rules. J. Nogueras-Iso, J. Barrera, A.F. Rodríguez, R. Recio, C. Laborda, F.J. Zarazaga-Soria (2009). In Spatial Data Infrastructure Convergence: Research, Emerging Trends, and Critical Assessment (Peer reviewed research articles of GSDI-12 conference), Ed: B. van Loenen, J. Zevenbergen & J. Besemer), The Netherlands Geodetic Commission (NGC), 2009.




[15] Borrador de recomendación para la definición del Núcleo Español de Metadatos de Servicios. Grupo de trabajo de la IDEE, 13/10/2009. Consejo Superior Geográfico.

INSPIRE (http://inspire.jrc.ec.europa.eu)

[16] Reglamento 1205/2008 por el que se ejecuta la Directiva 2007/2/CE en lo que se refiere a Metadatos. 03/12/2008.

[17] Reglamento 976/2009 por el que se ejecuta la Directiva 2007/2/CE en lo que se refiere a Servicios de Red. 19/10/2009.

[18] Draft Implementing Rules on interoperability of spatial data sets and services. 11/12/2009.

[19] Schema Transformation Network Service: State of the Art Analysis. RSW Geomatics, 1Spatial and Rob Walker Consultancy M. Beare, M. Howard, S. Payne & P. Watson. 10/06/2010

[20] Draft Commission Regulation amending Regulation (EC) No 976/2009 as regards download services and transformation services. 14.12.2009.

[21] Technical Report: INSPIRE NETWORK SERVICES SOAP Framework. European Commission Joint Research Centre 16/12/2008.

[22] Network Services Architecture (Version 3.0) 30/09/2008

[23] View Service Technical Guidance (version 2.0) 28/07/2009.

[24] Discovery Services Technical Guidance (versión 2.0) 23/07/2009 .

[25] Download Services Technical Guidance Draft (version 2.0) 25/09/2009.

[26] Coordinate Transformation Services Technical Guidance Draft 15/03/2010.

[27] Draft Implementing Rules for Download Services (Version 3.0) 25/09/2009.

[28] Draft Implementing Rules for Transformation Services (Version 3.0) 07/09/2009.

[29] Draft Implementing Rule: Discovery Services (Version 3.0) 11/04/2008.

[30] Draft Implementing Rule: View Services (Version 3.0) 11/04/2008.

[31] INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119. 26/10/2008.

OPEN GEOSPATIAL CONSORTIUM (http://www.opengeospatial.org/)

[32] OGC 06-121r9 Web Services Common Standard Version 2.0.0 07/04/2010 en http://portal.opengeospatial.org/files/?artifact_id=38867

[33] OGC 07-006r1Catalogue Services Specification v2.0.2 23/2/2007 D. Nebert, A. Whiteside, P. Vretanos en http://portal.opengeospatial.org/files/?artifact _id=20596

[34] OGC 06-042 Web Map Service Specification v1.3.0. 15/03/2006. http://portal.opengeospatial.org/files/?artifact_id=14416






[35] OGC 07-057r7 Web Map Tile Service Specification v1.0.0. 06/04/2010. http://portal.opengeospatial.org/files/?artifact_id=35326.

[36] OGC 04-094 Web Feature Service (WFS) Implementation Specification v1.1.0 http://portal.opengeospatial.org/files/?artifact_id=8339.

[37] OGC 05-007r7, Web Processing Service IS version 1.0.0, en http://portal.opengeospatial.org/files/?artifact_id=24151.

[38] OGC 05-078r4 Styled Layer Descriptor Profile of the Web Map Service IS http://portal.opengeospatial.org/files/?artifact_id=22364.

[39] OGC 05-077r4 Symbology Encoding Implementation Specification en http://portal.opengeospatial.org/files/?artifact_id=16700

[40] OGC 05-005 Web Map Context Documents Version: 1.1.0. 19/01/2005 en http://portal.opengeospatial.org/files/?artifact_id=8618.

[41] OGC 04-095 Filter Encoding Implementation Specification Version: 1.1.0. 03/05/2005 en http://portal.opengeospatial.org/files/?artifact_id=8340.

[42] OGC 08-068r2 Web Coverage Processing Service (WCPS) Language Interface Standard Versión 1.0.0. 25/03/2009 en http://portal.opengeospatial.org/files/?artifact_id=32319.

[43] OGC 07-036 Geography Markup Language (GML) Encoding Standard en http://portal.opengeospatial.org/files/?artifact_id=20509.

http://www.opengeospatial.org/standards/wmts

IDENTIFICACIÓN Y ESTUDIO DE LOS GEOSERVICIOS ESENCIALES ...

Documents

Transcript of IDENTIFICACIÓN Y ESTUDIO DE LOS GEOSERVICIOS ESENCIALES ...