GUÍA DE TRANSFORMACIÓN DE CONJUNTOS DE DATOS ESPACIALES DE CUBIERTA TERRESTRE AL MARCO INSPIRE

Transcripción

1 CODIIGE GTT-OS 25 de enero de 2016 Pág.1 GUÍA DE TRANSFORMACIÓN DE CONJUNTOS DE DATOS ESPACIALES DE CUBIERTA TERRESTRE AL MARCO INSPIRE Título Creador Guía de transformación de Conjuntos de Datos Espaciales de Cubierta terrestre al marco INSPIRE Grupo Técnico de Trabajo de Ocupación del Suelo Fecha 25 de enero de 2016 Objetivo Estado Descripción Guía de ayuda para la transformación de los Conjuntos de Datos Espaciales de Cubierta terrestre según las especificaciones de datos de Cubierta Terrestre definidas en el marco de la Directiva INSPIRE. Aprobado Esta guía incluye un resumen de los Reglamentos INSPIRE de interoperabilidad de datos espaciales, de las Directrices Técnicas para Cubierta Terrestre y explicaciones complementarias Contribuciones Formato PDF Identificador Idioma Período de validez Español Hasta próxima revisión

2 CODIIGE GTT-OS 25 de enero de 2016 Pág.2 Versiones Nº versión Fecha Autor/modificado por Comentarios Delgado Hernández, Julián Mesa Zambrano, Belén Valcárcel Sanz, Nuria Abad Power, Paloma Rodríguez Pascual, Antonio F Delgado Hernández, Julián Generación de la versión 0 y difusión interna dentro del GTT- OS del CODIIGE. Envío para su aprobación por el CODIIGE. Revisión de estructura y propuestas de mejora Generación de la 1ª versión Caballero García, Mª Elena Valcárcel Sanz, Nuria Villa Alcázar, Guillermo Rodríguez Pascal, Antonio F. Generación de la 2ª versión Paloma Abad Power Revisión para generar la v2.1 Emilio López Romero Fernando Alonso-Pastor Revisión para generar la v Delgado Hernández, Julián Revisión para generar la v3 Valcárcel Sanz, Nuria Caballero García, Mª Elena

3 CODIIGE GTT-OS 25 de enero de 2016 Pág.3 Índice 1 Resumen de las especificaciones de datos de Cubierta Terrestre Transformación Referencias A. Anexo: Conjunto de Pruebas Abstractas B. Anexo: Lista de clases y atributos... 37

4 CODIIGE GTT-OS 25 de enero de 2016 Pág.4 Preámbulo La Directiva 2007/2/CE del Parlamento Europeo y del Consejo de 14 de marzo de 2007 por la que se establece una Infraestructura de Información Geográfica en Europa (INSPIRE) en su artículo 7 prevé la elaboración y publicación de Normas de Ejecución que establezcan las disposiciones técnicas que obliguen a los productores de datos a armonizar sus conjuntos de datos espaciales para que sean interoperables. Además, establece que los Estados miembros garantizarán que todos los conjuntos de datos espaciales INSPIRE de nueva definición estén disponibles de conformidad con esas Normas de Ejecución en un plazo de 2 años desde su publicación, y que los conjuntos de datos ya definidos y en producción lo estarán en un plazo de 7 años a partir de la publicación de dichas Normas de Ejecución. Como desarrollo de este planeamiento se han aprobado los siguientes reglamentos: Reglamento (UE) Nº 1089/2010 en lo que se refiere a la interoperabilidad de los conjuntos y los servicios de datos espaciales: en este Reglamento se definen los requisitos para garantizar la interoperabilidad y la armonización de los conjuntos de datos de los temas del Anexo I de la Directiva (R1089, 2010). Reglamento (UE) Nº 102/2011, de 4 de febrero de 2011 que modifica el Reglamento (UE) Nº 1089/2010 introduciendo cambios en aspectos relativos a listas controladas (R102, 2011). Reglamento (UE) Nº 1253/2013, de 21 de octubre de 2013 que modifica el Reglamento (UE) Nº 1089/2010. Añade las disposiciones técnicas para los conjuntos de datos espaciales relativos a los temas de los anexos II y III de la Directiva Inspire, e introduce modificaciones en las disposiciones técnicas existentes relativas a los temas del Anexo I de la Directiva (R1253, 2013). El Reglamento 1089/2010 final resultante, con sus modificaciones, es de obligado cumplimiento en todos los Estados miembros desde el momento de su entrada en vigor, sin necesidad de transponer ni aprobar ninguna disposición legislativa nacional. Define por lo tanto el marco legal obligatorio que deben cumplir los conjuntos de datos para estar armonizados y ser interoperables. Teniendo en cuenta la fecha de su entrada en vigor, se deduce el siguiente calendario de cumplimiento: - Conjuntos de datos de nueva producción del Anexo I Conjuntos de datos de nueva producción de los Anexos II y III Conjuntos de datos ya existentes en del Anexo I Conjuntos de datos ya existentes en de los Anexos II y III Ahora bien, con el fin de ayudar al cumplimiento de esos reglamentos, se ha publicado un conjunto de Directrices Técnicas que definen unas especificaciones de datos para cada tema cuyo seguimiento implica el cumplimiento de los Reglamentos citados.

5 CODIIGE GTT-OS 25 de enero de 2016 Pág.5 El propósito de esta Guía de Transformación es apoyar y facilitar esa tarea de transformación de los conjuntos de datos para que cumplan los mencionados Reglamentos INSPIRE. Mientras que los Reglamentos y la Directiva establecen unas obligaciones legales que describen el qué deben implementar los Estados miembros, este documento sirve de directrices técnicas que describen cómo los Reglamentos y la Directiva puede ser implementados. Seguir estas Directrices Técnicas permite conseguir la mayor interoperabilidad posible entre los conjuntos de datos.

6 CODIIGE GTT-OS 25 de enero de 2016 Pág.6 1 Resumen de las especificaciones de datos de Cubierta Terrestre Este documento tiene como propósito ayudar a las organizaciones responsables de la producción de conjuntos de datos INSPIRE del tema Cubierta Terrestre en el proceso de transformación de sus datos para que sean conformes con las especificaciones INSPIRE de ese tema y con las decisiones de aplicación alcanzadas en CODIIGE. Hay que aclarar que este documento no constituye unas especificaciones de datos, sino simplemente una ayuda y guía para adaptar los conjuntos de datos a las especificaciones INSPIRE definidas en las Directrices Técnicas (Technical Guidelines). La norma UNE EN-ISO «Información geográfica Especificaciones de producto de datos» establece que unas especificaciones de datos son una descripción técnica detallada y precisa de un producto de datos que lo define y que debe incluir toda la información necesaria para generarlo. Las especificaciones de datos INSPIRE, descritas en las mencionadas Directrices Técnicas (Technical Guidelines) han sido redactadas siguiendo la estructura y contenido definidos en la norma UNE EN-ISO Los aspectos generales de las especificaciones de datos INSPIRE se encuentran descritos en el documento Documento CODIIGE para el entendimiento de las especificaciones INSPIRE. En él se describe su forma, contenido y se pormenoriza en los Reglamentos UE 1089/2010, 102/2011 y 1253/2013. Los siguientes apartados de este documento se resumen los aspectos fundamentales de las especificaciones de datos INSPIRE de Cubierta Terrestre (DS-LC, 2013). 1.1 Introducción INSPIRE define la Cubierta Terrestre (Land Cover) como la cubierta física y biológica de la superficie de la Tierra, incluidas las superficies artificiales, las zonas agrarias, los bosques, las zonas naturales o seminaturales, los humedales y las láminas de agua. Se definen los siguientes términos específicos relativos a este tema: - sistema de clasificación (classification system), sistema de asignación de los objetos a clases, en conformidad con ISO : objeto cubierta terrestre (land cover object), objeto espacial (punto, píxel o polígono) en el que se ha observado la cubierta terrestre. - leyenda (legend), aplicación de una clasificación en un área específica usando una escala cartográfica y un conjunto de datos específicos definidos. - unidad cartográfica mínima (minimal mapping unit), área más pequeña de un polígono que puede representarse en un conjunto de datos concreto de cubierta terrestre. - situación (situation) es el estado de un objeto de cubierta terrestre determinado en un momento concreto en el tiempo.

7 CODIIGE GTT-OS 25 de enero de 2016 Pág Estructura y contenido de los datos Se incluyen tres esquemas básicos de aplicación para este tema: Nomenclatura de la cubierta terrestre (Land Cover Nomenclature) Cubierta terrestre vectorial (Land Cover Vector) Cubierta terrestre ráster (Land Cover Raster) Los esquemas UML incluyen información adicional sobre el modelo que no está en los Reglamentos, en particular las multiplicidades de atributos y asociaciones. Los tres esquemas incluyen los siguientes tipos de datos y clases de objetos espaciales, tal y como establece el reglamento: Nomenclatura de la cubierta terrestre (Land Cover Nomenclature) - Nomenclatura de la cubierta terrestre (LandCoverNomenclature) Cubierta terrestre vectorial (Land Cover Vector) - Conjunto de datos de cubierta terrestre (LandCoverDataset) - Unidad de cubierta terrestre (LandCoverUnit) Cubierta terrestre ráster (Land Cover Raster) - Cubierta en malla de cubierta terrestre (LandCoverGridCoverage) El modelo de este tema se basa en un conjunto de datos que consiste en una colección de unidades de cubierta terrestre que pueden ser puntos, polígonos (Land Cover Vector) o celdillas ráster (Land Cover Raster), a las que se les asocia un código válido de cubierta terrestre según una Nomenclatura (Land Cover Nomenclature) y una referencia temporal de observación de los valores de clase asignados. Las especificaciones INSPIRE no prescriben ni recomiendan ninguna Nomenclatura de cubierta del suelo. Existe una única realidad, pero muchas maneras diferentes de describirla en función del objetivo perseguido, la metodología y la terminología del observador. Tratar de establecer un sistema de clasificación único en Europa limitaría el uso de los datos. El modelo vectorial y el ráster tienen las mismas aplicaciones y sólo se diferencian en dos aspectos puramente técnicos: - El modelo vectorial permite asignar múltiples códigos a cada unidad de cubierta, para seguir los cambios temporales de cubierta por ejemplo, mientras que el modelo ráster sólo permite asociar un único código a cada unidad. - El modelo ráster no permite el uso de mosaicos. En un mosaico se asignan varios códigos de clasificación a una unidad de cubierta terrestre y se le asocia además un porcentaje de cubierta a cada uno de ellos. Un caso general de uso de datos de cubierta del suelo es la determinación de cambios en las estadísticas de cada valor de clase en diferentes fechas. Como puede verse en la figura 1, este aspecto es fundamental en las especificaciones INSPIRE en este tema.

8 CODIIGE GTT-OS 25 de enero de 2016 Pág.8 Fig. 1. Gráfico simplificado de las clases de objetos en de las especificaciones INSPIRE Land Cover El esquema de la Nomenclatura de la cubierta terrestre tiene un tipo de dato fundamental: - la Nomenclatura (LandCoverNomenclature) definida por un identificador (inspireid), por la publicación de los valores de clase (nomenclaturecodelist), organismo responsable (responsableparty) y una descripción, ya sea hecha mediante documentación externa (externaldescription) proporcionada como una URL (o más para varios idiomas, por ejemplo) o mediante documentación adjunta (embeddeddescription) conforme a la norma ISO , que define un metalenguaje (LCML) para ello (véase la figura 2). Fig. 2. El tipo de dato LandCoverNomenclature DT Requisito 3 1. Una nomenclatura de cubierta del suelo debe estar siempre descrita por uno de estos dos atributos externaldescription (descripción externa) o embeddeddescription 1 Los números asignados a los requisitos, DT requisitos y recomendaciones en este documento no son correlativos, porque aquí se reflejan sólo los más importantes de las especificaciones de datos INSPIRE y se ha preferido mantener su numeración original.

9 CODIIGE GTT-OS 25 de enero de 2016 Pág.9 (descripción adjunta según ISO ) a pesar de que ambos atributos voidable, siempre se ha de aportar uno de ellos. Recomendación 1. La documentación de una Nomenclatura de cubierta terrestre debe estar en inglés (como external Description). El modelo vectorial tiene las siguientes clases de objeto fundamentales: - Conjunto de datos de cubierta terrestre (LandCoverDataSet), que representa al conjunto de datos. Sólo es necesario representarlo una vez por conjunto. Por ejemplo CORINE Land Cover 2000 será uno, y CORINE Land Cover 2006, otro. Estará definido por un identificador (inspireid), una extensión geográfica básica (extent), un nombre (name), la nomenclatura utilizada (nomenclaturedocumentation), los parámetros temporales de gestión de la información (beginlifespanversion fecha y hora en la que esta versión del objeto ha sido insertada o actualizada en el conjunto de datos; endlifespanversion fecha y hora en la que esta versión del objeto ha sido retirada o sustituida) y los parámetros temporales de la validez de los datos (validto, validfrom) que informan desde cuándo y hasta cuándo el presente conjunto de datos es el más apropiado para usar de la serie temporal a la que pertenece (véase la figura 3). Fig. 3. La clase LandCoverDataset DT Requisito 4. Un conjunto de datos de cubierta terrestre debe tener sólo un tipo de geometría, polígonos o puntos. No se permite la mezcla de distintas geometrías en el mismo conjunto de datos. Recomendación 2. Cada conjunto de datos debe tener una descripción de su ámbito especial en el atributo extent similar al element EX_GeographicExtent de ISO y todas las LandCoverUnit deben estar dentro del extent. - Unidad de cubierta terrestre (LandCoverUnit) que es una porción de espacio representada por un objeto geométrico (polígono o punto) con información de cubierta del suelo asignada. Está definido por un identificador (inspireid), una geometría (geometry), unos parámetros temporales de gestión de la información (beginlifespanversion, endlifespanversion) y la información sobre cubierta del suelo y fecha de observación (landcoverobservation) (véase la figura 4).

10 CODIIGE GTT-OS 25 de enero de 2016 Pág.10 Fig. 4. La clase LandCoverUnit Entre las dos clases anteriores existe una relación de agregación, un LandCoverDataset no es en realidad más que una agregación de LandCoverUnit (véase la figura 5). Fig. 5. Relación entre LandCoverSataset y LandCoverUnit DT Requisito 5. La representación espacial de un conjunto de datos de cubierta terrestre debe ser un conjunto de objetos espaciales (puntos o superficies) sin solapes. Recomendación 7. Si en un conjunto de datos no se mantienen los atributos del ciclo de vida (lifecycleinfo), todos los objetos espaciales deben tener valores vacíos de esos atributos con el motive de unpopulated. - Observación de cubierta terrestre (LandCoverObservation) representa la información temática de cubierta asignada a una unidad de cubierta terrestre. Una unidad podrá tener 1 o muchas observaciones, en función de la nomenclatura usada o de la fecha de

11 CODIIGE GTT-OS 25 de enero de 2016 Pág.11 observación. Estará definida por un valor de clase procedente de una nomenclatura (class), una fecha de observación (observationdate) y opcionalmente un mosaico de valores de clase (mosaic) que describe aquellos casos en los que la observación se compone de más de un valor (véase la figura 6). Fig. 6. LandCoverObservation En cuanto a la descripción de los aspectos temporales, se definen las siguientes fechas: a) event date (fecha del evento): momento o intervalo corto de tiempo (validfrom, validto) en el que aparece una nueva cubierta terrestre como consecuencia de un evento, por ejemplo una tormenta destructiva, un incendio, construcción de una infraestructura, construcción de un dique, etc. Es el momento en el que el cambio en la cubierta terrestre aparece y puede modelarse como voidable. b) observation date (fecha de observación): momento en el que se registra la información que proporciona la fuente de datos. Por ejemplo, la fecha de toma de las imágenes de satélite o aéreas usadas como fuente de datos. Puede variar de un polígono a otro. c) reference date (fecha de referencia): año o fecha aproximados en los que se asume convencionalmente que el conjunto de datos es válido. Por ejemplo la fecha de referencia del CLC2006 es el año 2006, aunque las imágenes utilizadas eran del intervalo Esta fecha no está expresamente requerida por en el modelo de datos, se informaría mediante el nombre del conjunto de datos o en los metadatos. d) edit date (fecha de edición): momento en el que se edita una unidad espacial (LandCoverUnit) y puede ser beginlifespanversion (fecha y hora en las que se inserta o cambia la versión del objeto espacial) o endlifespanversion (fecha y hora en las que se retira o sustituye la versión del objeto espacial). e) release date/date of last revision (fecha de la última revisión): momento en el que un conjunto de datos se completa y acaba; es el momento de cierre de la última edición o revisión antes de suministrarlo a los usuarios vía WMS, por ejemplo. Esta fecha no está requerida por en las especificaciones. f) publishing date (fecha de publicación): momento en el que un conjunto de datos se publica por primera vez. Después de una fecha de publicación puede haber varias fechas de última revisión. Esta fecha no está requerida por en las especificaciones. DT Requisito 6. La información temporal sobre el conjunto de datos de cubierta terrestre se debe proporcionar mediante la (b) fecha de observación (a nivel de todo el conjunto de datos y

12 CODIIGE GTT-OS 25 de enero de 2016 Pág.12 en sus metadatos) y la (d) fecha de edición (tanto a nivel del conjunto de datos como a nivel de LandCoverUnit, mediante begin/endlifespanversion). Recomendación 8. La información temporal sobre cubierta terrestre del tipo (c) fecha de referencia y (e) fecha de última revisión deben proporcionarse a nivel de cubierta y en los metadatos. - Valor de cubierta terrestre (LandCoverValue): En el caso de que la observación sea compleja, compuesta por más de una clase según un mosaico, se usará más de un valor de cubierta terrestre. Cada uno de ellos está definido por un valor de clase procedente de una nomenclatura(class) y por un porcentaje de cubierta (coveredpercentage). Una observación puede tener 1 o varios valores (LandCoverValue) (véase la figura 7). Fig. 7. Valor de cubierta terrestre El modelo extendido (Extended Data Model) permite además caracterizar las unidades de cubierta terrestre (LandCoverUnit) para recoger características adicionales o complementarias, como por ejemplo la densidad arbórea o el porcentaje de suelo sellado, mediante el uso de parámetros. Fig. 8. Tipos de parámetros

13 CODIIGE GTT-OS 25 de enero de 2016 Pág.13 - Parámetro de cubierta terrestre (ParameterType): En caso de que se quiera recoger información temática adicional distinta a los valores de clase se han de utilizar parámetros. Un parámetro está definido por un nombre (name) una fecha de observación (observationdate) y una medida del mismo, que puede ser de presencia (PresenceParameter) o ausencia de una clase, número de objetos (CountableParameter) o porcentaje (PercentageParameter). Estos parámetros se relacionan con las unidades (LandCoverUnit). Una unidad puede tener asociados uno o varios parámetros. Fig. 9. Modelo de cubierta terestre Ejemplos de la estructura y contenido de los datos según las especificaciones INSPIRE En las figuras siguientes, se muestran ejemplos de utilización de las especificaciones INSPIRE de cubierta del suelo en función de las clases de objetos utilizados.

14 CODIIGE GTT-OS 25 de enero de 2016 Pág.14 Fig. 10. Ejemplo de aplicación de las especificaciones INSPIRE a un polígono del CORINE Land Cover Como la observación realizada sobre el polígono sólo posee un valor de clase (111 Urbano continuo), condición de partida del CORINE Land Cover, no es necesario recurrir a mosaicos con más de un valor de clase.

15 CODIIGE GTT-OS 25 de enero de 2016 Pág.15 Fig. 11. Ejemplo de aplicación de las especificaciones INSPIRE a un polígono del SIOSE En este caso puede verse que la observación está compuesta por un mosaico de más de un valor de clase. Las clases SIOSE dentro del polígono pueden corresponderse con los valores de clase propuestos en INSPIRE. Fig. 12. Ejemplo de aplicación de los parámetros INSPIRE a un polígono del SIOSE Gracias a la presencia de clases SIOSE dentro de los polígonos, es posible determinar parámetro físicos. Estos parámetros no son clases de nomenclaturas por si mismas, pero informan sobre caracteríticas importantes del paisaje (p. e.: FCC = fracción de cabida cubierta, calculada para la suma de presencias de clases arbóreas). Estos parámetros se pueden calcular y proporcionar a INSPIRE. 1.3 Sistemas de referencia, unidades de medida y mallas Los Sistemas de Referencia por Coordenadas a usar son los adoptados por INSPIRE por defecto, definidos en las especificaciones INSPIRE del tema «Sistema de Referencia de Coordenadas» (DS-CRS, 2010). DT Requisito 1. Como sistema de referencia de coordenadas tridimensional y bidimensional (componente horizontal), se usará el European Terrestrial Reference System 1989 (ETR89), para las áreas dentro del ámbito de aplicación del mismo. DT Requisito 2. El International Terrestrial Reference System (ITRS) u otro sistema de referencia de coordenadas conforme con el ITRS, será usado para áreas fuera del ámbito de aplicación del ETR89.

16 CODIIGE GTT-OS 25 de enero de 2016 Pág.16 DT Requisito 4. Para la representación plana de coordenadas se usarán una de las siguientes proyecciones: Acimutal Equivalente de Lambert (ETRS89-LAEA), Cónica Conforme de Lambert (ETRS89-LCC) o la Transversa Mercator (ETRS89-TMzn). Recomendación 1. Para el análisis espacial e informe pan-europeo, se necesita la representación real del área, por lo que se recomienda usar ETRS89-LAEA. Recomendación 2. Para la representación cartográfica conforme pan-europea de escalas menores o iguales a 1: , se recomienda usar ETRS89-LCC. Recomendación 3. Para la representación cartográfica conforme pan-europea de escalas mayores o iguales a 1: , se recomienda usar ETRS89-TMzn. Códigos EPSG correspondientes: - ETRS89-LAEA: ETRS89-LCC: ETRS89-TM28, 29, 30, 31 respectivamente: 3040, 3041, 3042, ETRS89-UTM28, 29, 30, 31 respectivamente: 25828, 25829, 25830, REGCAN, huso 28: 4083 Fuente: Calidad de los datos En este tema se recomienda determinar una serie de elementos de la calidad, de manera no obligatoria, conforme a la norma UNE-EN ISO Información geográfica Calidad: Sección de las especificaciones Elemento de calidad Subelemento Medida de la calidad Compleción Comisión Se marcan los Ítems en exceso Compleción Omisión Se marcan los Ítems que faltan Consistencia lógica Consistencia Lógica Consistencia lógica Consistencia lógica Exactitud posicional Exactitud posicional Consistencia conceptual Se marcan los ítems que no cumplen las Consistencia de dominio Consistencia de formato reglas del Modelo Conceptual Se marcan los ítems con un valor fuera del dominio permitido Se marcan los ítems almacenados sin seguir el modelo físico Consistencia topológica Nº de ítems que se autointersectan de Exactitud absoluta Exactitud relativa Exactitud temática Corrección de la clasificación manera errónea. EMC en planimetría EMC en planimetría - Tasa de clasificaciones erróneas (valor registrado frente al valor real) - Matriz de confusión

17 CODIIGE GTT-OS 25 de enero de 2016 Pág Exactitud temática Corrección de atributos no cuantitativos Exactitud temática Exactitud de atributos cuantitativos Tasa de error: nº de valores de atributo erróneos en relación al total Comparación gráfica de la densidad de valores de cubierta de referencia con los existentes Recomendación 11 Si es imposible expresar un elemento de la calidad con un valor cuantitativo, se puede expresar mediante una descripción textual (quality descriptive result). No se establecen en ningún caso umbrales mínimos de calidad para ninguno de los elementos considerados. Sin embargo, se recomiendan unos valores umbral (falso para los cinco primeros; 0 para 7.1.6; el tamaño de píxel de las imágenes utilizadas para 7.1.7, y el 15 % para 7.1.9). 1.5 Metadatos En cuanto a los metadatos que contempla el Reglamento Europeo 1205/2008 (R1205, 2008) sobre metadatos de datos y servicios: Recomendación 24: Los metadatos del conjunto de datos deben incluir una declaración de la conformidad de los datos con estas especificaciones. Recomendación 25: El elemento de metadatos conformidad debe utilizarse para describir una clase de conformidad de las definidas en el Conjunto de Pruebas Abstractas (ATS). Recomendación 26: Si un conjunto de datos no es completamente conforme, se recomienda documentar si cumple o no cada clase de conformidad del ATS. Recomendación 27: Si se han producido los datos conforme a una especificación de producto, debe documentarse. Recomendación 28: Si se definen requisitos mínimos de calidad, se debe documentar su cumplimiento aquí. Recomendación 30: Se recomienda describir el linaje del conjunto de datos. Recomendación 32: Se recomienda recoger en los metadatos al menos la fecha de la última revisión de los datos, utilizando «Date of last revision». Requisito 13 Se añaden los siguientes ítems de metadatos de manera obligatoria para garantizar la interoperabilidad: - Sistema de Referencia de Coordenadas. - Sistema de Referencia Temporal, en caso de que haya información temporal. - Encoding. (Formato físico). - Consistencia topológica. Es obligatorio solo si se incluyen elementos del Generic Network Model y no se asegura la topología de los ejes.

18 CODIIGE GTT-OS 25 de enero de 2016 Pág.18 - Tipo de representación espacial. Recomendación 34: Se recomienda que estos metadatos de interoperabilidad estén disponibles en un Servicio de catálogo junto con el resto que marca el reglamento de metadatos. Recomendación 35: Además, se recomienda incluir una serie de ítems de metadatos específicos de este tema INSPIRE, para describir la información de mantenimiento y la de calidad: Elemento de metadatos Multiplicidad Información de mantenimiento 0..1 Completitud Comisión 0..* Completitud Omisión 0..* Consistencia lógica Consistencia conceptual 0..* Consistencia lógica Consistencia de dominio 0..* Consistencia lógica Consistencia de formato 0..1 Consistencia lógica Consistencia topológica 0..* Exactitud posicional - Absoluta 0..* Exactitud posicional - Relativa 0..* Exactitud temática Corrección de la clasificación 0..* Exactitud temática Corrección de atributo no cuantitativo 0..* Exactitud temática Exactitud de atributo cuantitativo 0..* Exactitud temporal Consistencia temporal 0..* Exactitud temporal Validez temporal 0..* 1.6 Distribución Requisito 8: Los Estados miembros deben proporcionar actualización de manera regular. Las actualizaciones deben estar disponibles como mucho 6 meses después de que se hayan actualizado los ficheros originales (internos). De acuerdo a lo establecido en la Directiva INSPIRE, es obligatorio implementar servicios de visualización y descarga para distribuir la información de Cubierta del suelo. 1.7 Encoding (formato físico) Requisito 7: Debe ser conforme a UNE-EN ISO y las reglas de encoding deben publicarse. Se propone GML, tal y como se define en la norma ISO Geographic Información Encoding, como formato físico por defecto. Se proporcionarán plantillas XML para verificar la conformidad de formato: Nomenclatura de cubierta terrestre: Cubierta terrestre vectorial:

19 CODIIGE GTT-OS 25 de enero de 2016 Pág.19 Cubierta terrestre ráster: Requisito 12: Los documentos XML de datos deben validarse sin errores utilizando los esquemas XML proporcionados. 1.8 Representación (o simbología) Las capas a incluir en un servicio de visualización serán: Nombre de la capa Título de la capa Tipos de objeto Palabras clave LC.LandCoverPoints LandCoverPoints LandCoverUnit Land Cover, Points LC.LandCoverSurfaces LandCoverSurfaces LandCoverUnit Land Cover, Surfaces, Polygons LC.LandCoverRaster LandCoverRaster LandCoverGridCoverage Land Cover, Raster, Rectified Grid Existen unas recomendaciones de representación según INSPIRE, así como un estilo por defecto definido en las Directrices Técnicas. Capa LC.LandCoverPoints Recomendación 2: para la cubierta del suelo expresada como puntos, se recomienda que éstos sean representados por círculos de tamaño de 3 píxeles con un color de relleno (correspondiente a una leyenda) y un contorno negro (#000000). Estilo LC.LandCoverPoints Default Style: Los puntos se representan mediante círculos de un tamaño de 3 píxeles rellenos de negro (#000000) con borde negro (#000000). Capa LC.LandCoverSurfaces Recomendación 1: para la cubierta del suelo expresada como polígonos o superficies, se recomienda que éstos sean representados por un color de relleno (correspondiente a una leyenda) y un contorno negro (#000000) y de 3 píxeles de grosor. Estilo LC.LandCoverSurfaces Default Style: Los polígonos se representan rellenos de blanco (#FFFFFF) con un contorno negro (#000000) y de 3 píxeles de grosor. Capa LC.LandCoverRaster Estilo LC.LandCoverRaster Default Style: Los polígonos se representan rellenos de blanco (#FFFFFF) con un contorno negro (#000000) y de 3 píxeles de grosor.

20 CODIIGE GTT-OS 25 de enero de 2016 Pág.20 2 Transformación El Grupo Técnico de Trabajo CODIIGE en Ocupación del Suelo identificó los puntos fundamentales a desarrollar para la adopción de las especificaciones INSPIRE de una manera común sobre todos los conjuntos de datos. Éstos se materializaban en utilizar como base un conjunto común de clases y atributos, principalmente ya presentes en SIOSE, junto con las clases y atributos de otros sistemas que se consideraron necesarios. En el Anexo B se describen las decisiones alcanzadas, que pueden resumirse en: i) Debido a que INSPIRE no define una nomenclatura de clases de cubierta terrestre, se ha de elaborar una nomenclatura, para categorizar mediante un valor de etiqueta, todos los elementos superficiales. Existe por lo tanto una Nomenclatura de clases CODIIGE acompañadas de sus definiciones textuales. ii) Debido a que INSPIRE no define un conjunto de parámetros o atributos de cubierta terrestre, se ha de elaborar una lista que sirva para profundizar en la descripción de la información que proporciona la nomenclatura anterior, proporcionando Atributos de interés CODIIGE, acompañados por sus definiciones textuales. iii) En relación con el uso del suelo, existente y planificado, el grupo de trabajo no propone modificaciones a INSPIRE, por lo que deberán adoptarse directamente las especificaciones que desarrolla la Directiva, como se describe en la Guía de transformación de conjuntos de datos espaciales de usos del suelo al marco INSPIRE (GT-US, 2015). Para implementar unas especificaciones de datos, ya sean de INSPIRE o de cualquier otro ámbito, pueden enumerarse las siguientes fases a realizar: Fase 1: Identificación de las relaciones entre los objetos, atributos y relaciones del conjunto de datos original y los objetos, atributos y relaciones de las especificaciones destino. Resulta un trabajo teórico donde se descubren los paralelismos y diferencias entre el modelo de los datos original y el modelo propuesto, para obtener las pautas en la transformación de los datos. Popularmente se conoce esta tarea con las palabras inglesas de mapping o matching; se empleará a partir de ahora en este documento la palabra correspondencia para aludir a esta tarea. Fase 2: Aplicación de la transformación de los datos sobre conjuntos de datos reales. En esta fase, una vez definida de manera teórica la correspondencia, se desarrolla un modelo de procesos que permita reconstruir la estructura de los datos demandada. El resultado serán los datos, de cada productor o responsable, conforme al modelo de las especificaciones INSPIRE y las decisiones de CODIIGE. Durante esta fase se ha de asegurar el cumplimiento de los requisitos establecidos en las especificaciones INSPIRE sobre: - Sistemas de referencia - Unidades y mallas - Requisitos temáticos específicos - Calidad de los datos

21 CODIIGE GTT-OS 25 de enero de 2016 Pág.21 - Metadatos - Captura de datos Fase 3: Codificación de los datos según el formato demandado y generación de servicios web. INSPIRE y CODIIGE establecen que los datos han de ser diseminados mediante servicios web o ficheros GML. Por este motivo, en esta fase se desarrollarán los procesos necesarios para trasformar los datos resultantes de la fase anterior a los formatos GML y generar servicios web INSPIRE. Durante esta fase se ha de asegurar el cumplimiento de los requisitos establecidos en las especificaciones INSPIRE sobre: - Distribución - Representación Fase 4: Comprobación de que se ha efectuado correctamente todo el proceso aplicando las pautas definidas en el Anexo A Conjunto de pruebas abstractas (Abstract Test Suite). Independientemente de que siempre es recomendable que una organización, diferente a la que ha producido los datos, verifique la conformidad de un conjunto de datos, el productor debe incluir como última fase del proceso de transformación de sus datos la verificación de que el resultado es conforme. 2.1 Fase 1: Correspondencia de los modelos de los conjuntos de datos (Mapping) Para identificar las relaciones entre los modelos de datos (de ahora en adelante MD) original y final, es necesario conocer adecuadamente ambas estructuras de datos. La estructura del MD original es conocida por el organismo responsable de los datos, pero la estructura propuesta por las especificaciones INSPIRE y CODIIGE puede resultar desconocida, por ello es recomendable que los organismos consulten los documentos de especificaciones INSPIRE de cubierta del suelo (DS-LC, 2013) Aunque el objetivo de este documento no es resumir o traducir las especificaciones INSPIRE, sino ayudar a su puesta en práctica, en el Apartado 1 se encuentran resumidos las consideraciones más importantes como apoyo a una mejor comprensión de la documentación original. Esta correspondencia al tratarse de un ejercicio teórico, se puede realizar en una tabla donde a un lado se encuentran los objetos y atributos del MD original, y al otro los objetos y atributos del MD destino. En concreto para la cubierta del suelo en el ámbito CODIIGE se pueden enumerar unos pasos bien identificados: cumplir la estructura propuesta por INSPIRE y satisfacer la nomenclaturas de clases y atributos definida en el grupo de trabajo del CODIIGE.

22 CODIIGE GTT-OS 25 de enero de 2016 Pág.22 Fig. 13. Gráfico que identifica las diferentes partes en la correspondencia Parte INSPIRE de la correspondencia Para desarrollar la correspondencia, INSPIRE publica en su web unas mapping tables para cada tema, por lo que los usuarios europeos pueden descargarlas y trabajar sobre ellas. Cada fichero *.xml se corresponde con un paquete del modelo de datos del tema correspondiente. Estos ficheros *.xml pueden ser abiertos con Excel como se explica en las figuras 14 y 15 o con un gestor de tablas equivalente. Cada organismo podrá usar las tablas de correspondencia que necesite en función de sus datos, teniendo presente que los ficheros que hacen referencia a «modelos base» han de usarse siempre. Para el tema de cubiertas del suelo existen 4 ficheros: - LandCoverNomenclature_Mapping_Table.xml (modelo base) - LandCoverVector_Mapping_Table.xml (modelo para datos vectoriales) - LandCoverExtension_Mapping_Table.xml (modelo extendido para datos vectoriales) - LandCoverRaster_Mapping_Table.xml (modelo para datos ráster) Fig. 14. Apertura con Excel de un fichero de tabla de correspondencia.

23 CODIIGE GTT-OS 25 de enero de 2016 Pág.23 Fig. 15. Aspecto de las tablas de correspondencia. Esta imagen es un ejemplo, se recomienda al lector abrir el fichero directamente para leer de manera detallada cada celda en excel. El formato de estas tablas es sencillo, a la izquierda se encuentran los objetos y atributos propuestos por las especificaciones INSPIRE y a la derecha las celdas están en blanco para que cada responsable de un conjunto de datos pueda rellenarlas en función de la estructura de sus conjuntos de datos (MD original). El significado de cada columna INSPIRE, a la izquierda en la tabla, es el siguiente: - Type: nombre de la clase de objeto definido en INSPIRE. - Documentation: definición de la clase de objeto definida en INSPIRE. - Atribute/Association role/constraint: nombre del atributo de la clase de objeto INSPIRE; o nombre de la relación de la clase de objeto con otra clase de objeto INSPIRE; o nombre de la constricción sobre la clase de objeto INSPIRE. - Atribute/Association role/constraint documentation: definición del atributo, relación o constricción de la clase de objeto INSPIRE. - Value/Enumerations: Tipo de datos, valor o conjunto de valores que pueden aceptar los atributos y relaciones que previamente se han identificado. - Multiplicity: Multiplicidad del atributo, relación o constricción. Si es igual a 1, sólo tomará un valor. Si es 1..* podrá tomar uno o muchos. Si es 0..1 tomará uno o ningún valor, por lo que será opcional. Y así en otras posibles combinaciones de multiplicidades. - Voidable / Non-voidable. Indica si el atributo, relación o constricción es voidable. Al trabajar con estas tablas, se han de tener en cuenta una serie de consideraciones importantes: - Si el atributo o relación tiene multiplicidad de al menos 1, quiere decir que es un atributo obligatorio que hay que proporcionar siempre. - Si el atributo o relación tiene multiplicidad de al menos 0, quiere decir que es opcional, y el responsable de los datos decide si quiere proporcionarlo o no.

24 CODIIGE GTT-OS 25 de enero de 2016 Pág.24 - Si el atributo o relación es voidable, eso quiere decir que si el responsable de los datos posee esa información, resulta obligatorio proporcionarla; pero se admite que no se disponga de ella y por lo tanto no se suministre (CODIIGE, 2015). CODIIGE aconseja la utilización de este tipo de tablas, ya sea las originales de INSPIRE u otras propias semejantes realizadas por el responsable de los datos. La correspondencia se lleva a cabo cumplimentando las celdas en blanco de la derecha con la información disponible en cada conjunto de datos. Es precisamente en ese momento cuando el responsable de los datos descubre si las especificaciones INSPIRE tal y como están son adecuadas y suficientes para describir sus datos de manera satisfactoria. Puede ocurrir que haya atributos INSPIRE que no se encuentren en sus datos o al contrario, que existan atributos contemplados en sus datos no considerados en INSPIRE. Suele ocurrir que sea necesario separar, reorganizar o renombrar valores de atributos nacionales para que encajen dentro de la estructura propuesta de INSPIRE, con lo que todas estas circunstancias deben quedar reflejadas en la tabla, ya que será la base para desarrollar un modelo de procesos que materialice la trasformación más adelante. Fig. 16. Ejemplo de una tabla de correspondencias rellenadas para el CORINE Land Cover y las especificaciones INSPIRE v2.0 dentro del proyecto HLANDATA (2011) Parte CODIIGE de la correspondencia Esta sección hace referencia a la adopción de la nomenclatura y atributos definidos dentro del GTT de Ocupación del suelo del CODIIGE, los cuales se encuentran definidos en la última versión en el Anexo B. Los responsables de los datos han colaborado en la definición de las clases, dentro del Comité Editor o mediante comentarios generales, por lo que se puede decir que la idoneidad de esta

25 CODIIGE GTT-OS 25 de enero de 2016 Pág.25 nomenclatura ya ha sido verificada y consensuada, por lo tanto, es directamente aplicable por los productores de datos. Los responsables de los datos son capaces de relacionar sus propias clases con las clases consensuadas en el GTT de Ocupación del suelo. Como se ha explicado en documentos de trabajo anteriores, no existe obligatoriedad de completar toda la nomenclatura, pues es posible que ciertos conjuntos de datos sean muy temáticos (p. e.: forestales, agrícolas, etc.) y no alcancen a cubrir todas las clases consensuadas. En cuanto a los niveles, tampoco existe obligatoriedad de cubrir el 2º nivel de forma completa, un responsable de datos puede usar de forma adecuada y ordenada clases del 1º y del 2º nivel para recoger sus datos. 2.2 Fase 2: Aplicación de la transformación Un modelo de procesos permite reconstruir una estructura de datos, dando como resultado que los datos de cada productor o responsable sean conformes al modelo de las especificaciones INSPIRE y las decisiones de CODIIGE. Durante esta fase se ha de asegurar el cumplimiento de los requisitos obligatorios establecidos en las especificaciones INSPIRE sobre sistemas de referencia, unidades y mallas, requisitos temáticos, calidad de los datos, metadatos y captura de datos, como se ha descrito en el Apartado 1 En cuanto a las recomendaciones de las especificaciones, aunque no son completamente obligatorias, resulta muy aconsejable seguirlas para maximizar la interoperabilidad de los conjuntos de datos resultantes. Esta fase será propia para cada conjunto de datos origen y la herramienta de procesado escogida, por lo desde el GTT CODIIGE OS se ofrecerán las pautas comunes a todos los conjuntos de datos (p. e. estructura de los ficheros de salida) y las recomendaciones aplicables durante la transformación. De entre las herramientas disponibles hoy día para la transformación a INSPIRE se encuentran: - SAFE software FME. Herramienta ETL corporativa que es capaz de manejar de manera muy eficaz conjuntos de datos geográficos y adaptarlos a diversos modelos de datos. Además, desde la versión 2014 es capaz de utilizar ficheros XSD de definición de modelos de datos INSPIRE. - Humboldt HALE (Alignment Editor). Herramienta ETL software libre, más reducida en cuanto a transformaciones, pero especialmente enfocada a la traducción de modelos de datos a INSPIRE, capaz de utilizar ficheros INSPIRE XSD. - Otras herramientas ETL software libre o licencia gratuita son: o Geokettle, o Talend Data Integration, o Geobide Converter, Como la distribución de los conjuntos de datos ha de realizarse mediante un servicio web, si la transformación a INSPIRE resulta sencilla, ésta puede llevarse a cabo directamente con

26 CODIIGE GTT-OS 25 de enero de 2016 Pág.26 servidor de datos (p.e. Geoserver, MapServer, etc.). Por el contrario, si la transformación es más complicada, será necesario previamente acomodar los conjuntos de datos mediante una herramienta de trasformación, y posteriormente ser publicados con el servidor. En los casos concretos de cubierta terrestre, datos como el CORINE Land Cover puede transformase directamente con un servidor de datos. Sin embargo datos más complejos como el SIOSE necesita una transformación precia para facilitar el trabajo del servidor. Fig. 17. Gráfico simplicado de la transformación 2.3 Fase 3: Codificación de los datos y servicios web En esta fase se desarrollarán los procesos necesarios para trasformar los datos resultantes de la fase anterior a formato GML y generar servicios web INSPIRE. Para satisfacer los requisitos marcados por la Directiva en cuanto al modelo de datos y formato de los datos, se han de usar los ficheros XSD publicados por INSPIRE. Durante esta fase se ha de asegurar el cumplimiento de los requisitos establecidos en las especificaciones INSPIRE sobre distribución y representación descritos en el Apartado 1. La codificación de los conjuntos de datos en formato GML puede hacerse de manera separada a su transformación (fase 2) o de manera conjunta. En función de los estudios realizados sobre de las herramientas y los ficheros XSD INSPIRE, CODIIGE OS propondrá la mejor solución. La distribución de los conjuntos de datos ha de realizarse mediante un servicio web. En este punto se seguirán las pautas marcadas definidas por el GTT de Arquitectura, Normas y Servicios en red del CODIIGE.

27 CODIIGE GTT-OS 25 de enero de 2016 Pág.27 Fig. 18. Gráfico simplificado de la codificación de los datos y generación de servicios web A continuación se muestra un ejemplo de petición de datos a partir de un servicio web de descarga INSPIRE, con datos del CORINE Land Cover. =1 2.4 Fase 4: Conjunto de pruebas abstractas El conjunto de pruebas abstractas (Abstract Test Suite, ATS) analiza la conformidad de los conjuntos de datos transformados con las especificaciones INSPIRE. CODIIGE OS no propone pruebas adicionales de las contempladas en las especificaciones INSPIRE de cubierta del suelo (DS-LC, 2013) Annex A. Se establecen diferentes clases de conformidad que puede satisfacer un conjunto de datos espaciales por separado: 1) Conformidad del Esquema de Aplicación 2) Conformidad de los Sistemas de Referencia 3) Conformidad de la consistencia de datos 4) Conformidad con las Normas de Ejecución de Metadatos 5) Conformidad de la accesibilidad 6) Conformidad de la distribución de datos 7) Conformidad de la representación 8) Conformidad con las Directrices Técnicas Las clases de conformidad 1 a 7 se ocupan de verificar la conformidad con los Reglamentos de interoperabilidad de datos y servicios (R1089, 2010) y la clase de conformidad 8 aborda la

28 CODIIGE GTT-OS 25 de enero de 2016 Pág.28 conformidad con las especificaciones INSPIRE de Cubierta Terrestre (DS-LC, 2013)(véase el anexo A).

29 CODIIGE GTT-OS 25 de enero de 2016 Pág.29 3 Referencias CODIIGE. (2015). Documento CODIIGE para el entendimiento de las especificaciones INSPIRE. DS-CRS, I. (26 de abril de 2010). INSPIRE Data Specifications on Coordinate Reference System v3.1. DS-LC, I. (4 de febrero de 2013). INSPIRE Data Specifications on Land Cover v3.0rc3. DS-LU, I. (4 de febrero de 2013). INSPIRE Data Specifications on Land Use v3.0rc3. GT-US, C.-O. (2015). Guía de transformación de conjuntos de datos espaciales de usos del suelo al marco INSPIRE. INSPIRE. (2007). Directiva 2007/2/CE del Parlamento Europeo y del Consejo de 14 de marzo del 2007 por la que se establece una infraestructura de información espacial en la Comunidad Europea. LISIGE. (2010). Ley 14/2010, de 5 de julio, sobre las infraestructuras y los servicios de información geográfica en España. R102, I. (2011). Reglamento (UE) Nº 102/2011, de 4 de febrero de 2011 que modifica el Reglamento (UE) Nº 1089/2010 introduciendo cambios en aspectos relativos a listas controladas. R1089, I. (2010). Reglamento UE 1089/2010 de la Comisión de 23 de noviembre de 2010, por el que se aplica la Directiva 2007/2/CE del Parlamento Europeo y del Consejo en lo que se refiere a la interoperabilidad de los conjuntos y los servicios de datos espaciales. R1205, I. (2008). Reglamento 1205/2008 de la Comisión por el que se ejecuta la Directiva 2007/2/CE del Parlamento Europeo y del Consejo en lo que se refiere a los metadatos. R1253, I. (2013). Reglamento UE 1253/2013 de la Comisión de 21 de octubre de 2013 que modifica el Reglamento (UE) n o 1089/2010 por el que se aplica la Directiva 2007/2/CE en lo que se refiere a la interoperabilidad de los conjuntos y los servicios de datos espaciales.

30 CODIIGE GTT-OS 25 de enero de 2016 Pág.30 A. Anexo: Conjunto de Pruebas Abstractas En este anexo se resumen el Conjunto de Pruebas Abstractas (Abstract Test Suite, ATS) definido en las Directrices Técnicas que contienen las especificaciones INSPIRE de datos sobre cubierta terrestres (DS-LC, 2013) que definen un procedimiento y metodología para verificar si un conjunto de datos es conforme o no con dichas especificaciones. El resumen que aquí se hace es meramente informativo e introductorio y no debe tomarse en ningún caso como un documento que sustituye a las Directrices Técnicas originales (DS-LC, 2013), cuya lectura y consulta se recomienda en cualquier caso. Este ATS es aplicable a los conjuntos de datos que ya se han transformado para publicarse mediante servicios de descarga INSPIRE de ficheros predefinidos, no a los conjuntos de datos almacenados como originales. Se divide en dos partes: - La parte 1 incluye las pruebas para comprobar la conformidad con el Reglamento de Interoperabilidad de datos y servicios espaciales, e incluye referencias a los artículos del reglamento a los que se refiere cada prueba. - La parte 2 incluye las pruebas necesarias para comprobar la conformidad con las Directrices Técnicas, es decir con los requisitos de las Directrices Técnicas, cuyo cumplimiento implica la conformidad con los requisitos del Reglamento. Se establecen las siguientes clases de conformidad: Parte 1 A.1) Conformidad del Esquema de Aplicación A.2) Conformidad de los Sistemas de Referencia A.3) Conformidad de la consistencia de datos A.4) Conformidad con las Normas de Ejecución de Metadatos A.5) Conformidad de la accesibilidad A.6) Conformidad de la distribución de datos A.7) Conformidad de la representación Parte 2 A.8) Conformidad con las Directrices Técnicas Para ser conforme con una clase de conformidad, un conjunto de datos debe pasar todas las pruebas definidas en esa clase.

31 CODIIGE GTT-OS 25 de enero de 2016 Pág.31 Por otro lado, los conjuntos de datos que tienen más o que tienen menos tipos de objeto y tipos de datos que los incluidos en el reglamento pueden ser conformes si pasan todas las pruebas especificadas. Por ejemplo, si un conjunto de datos tiene más tipos de objeto y tipos de datos será conforme si los tipos de objeto y de datos que están definidos en el Reglamento cumplen todas las pruebas y si los adicionales no entran en conflicto con ninguno de los requisitos exigidos 2. Algunas pruebas de la clase A.1 Conformidad con el Esquema de Aplicación pueden automatizarse mediante una herramienta de validación con esquemas xml, pero en ese caso hay que tener en cuenta que a veces una aparente falta de conformidad puede deberse a un error de la herramienta o del esquema utilizado. 2 El Anexo F del Generic Conceptual Model (D2.5) contiene un ejemplo de cómo extender los esquemas de aplicación INSPIRE.