TRABAJO FIN DE MÁSTER ACCESO UNIFICADO A INFORMACIÓN CATASTRAL. Macas Espinosa Vinicio Xavier

Tamaño: px
Comenzar la demostración a partir de la página:

Download "TRABAJO FIN DE MÁSTER ACCESO UNIFICADO A INFORMACIÓN CATASTRAL. Macas Espinosa Vinicio Xavier"

Transcripción

1 TRABAJO FIN DE MÁSTER ACCESO UNIFICADO A INFORMACIÓN CATASTRAL Macas Espinosa Vinicio Xavier Director: Javier Nogueras Iso Máster Oficial en Tecnologías de la información geográfica para la ordenación del territorio: sistemas de información geográfica y teledetección Septiembre de 2012 Departamento de Geografía y Ordenación del Territorio Grupo de Sistemas de Información Avanzados

2 Agradecimientos Agradezco a los miembros del Grupo de Sistemas de Información Avanzados de la Universidad de Zaragoza por todos los conocimientos compartidos, gracias a los cuales se ha podido culminar con éxito el presente Trabajo Fin de Máster. A mis padres por todo su apoyo incondicional a mis acciones emprendidas en el transcurso de mi vida. A mis compañeros de clases, gracias a los cuales mi estancia en la ciudad de Zaragoza ha sido agradable por todos los momentos gratos compartidos. A la Secretaría Nacional de Educación Superior, Ciencia, Tecnología e Innovación de la República del Ecuador, entidad que ha hecho posible la realización de mis estudios en España por una beca otorgada. Al coordinador del Máster en Tecnologías de la Información Geográfica, Juan de la Riva y al tutor de este Trabajo Fin de Máster, Javier Nogueras Iso, por todas las facilidades prestadas durante el máster y realización de este trabajo. 1

3 Resumen La información catastral es información de referencia básica para el desarrollo de múltiples análisis y aplicaciones como la gestión de infraestructuras urbanas, gestión de vivienda, recaudación de impuestos sobre la propiedad y otras. Gestionar estas actividades utilizando Infraestructuras de Datos Espaciales facilita la planificación de procesos de desarrollo dentro de un área geográfica específica. El acceso a fuentes de datos catastrales de diferentes países de forma unificada presenta limitaciones debido a que cada país gestiona esta información utilizando procesos total o parcialmente diferentes, tanto a nivel de modelos de datos, como a formatos o servicios para su descarga. El análisis y recopilación de fuentes de datos de un grupo específico de países, por ejemplo aquellos miembros del Comité Permanente sobre el Catastro de Iberoamérica (CPCI), permite observar esta heterogeneidad. El objetivo de este Trabajo Fin de Máster es proponer una arquitectura interoperable donde se establezca un modelo de datos común de catastro junto con los servicios web necesarios que permitan acceder a los datos de las distintas fuentes de forma homogénea y estandarizada. Para definir el modelo común se ha tenido en cuenta sobre todo las especificaciones de datos propuestas por la directiva europea INSPIRE que tienen como base los modelos de datos de distintos entes catastrales de los países de la Unión Europea. Para verificar el acceso a datos y la interoperabilidad de los servicios se ha desarrollado una aplicación web que utiliza las funcionalidades de los servicios WFS (Web Feature Service) y WPS (Web Processing Service). La utilización de servicios interoperables permite acceder a los datos catastrales como fuente de información principal o como información complementaria para otras aplicaciones. Palabras Clave: Catastro, Web Feature Service, Web Processing Service, Interoperabilidad, Información Geográfica. Abstract Cadastral information is basic reference information for the development of multiple analysis and applications like urban infrastructures management, house management, land values taxation and others. The management of these activities using Spatial Data Infrastructures facilitates the planning of development processes in a specific geographic area. The access to cadastral data sources of different countries in a unified way has limitations because each country manages that information using totally or partially different processes, both in terms of data models and formats (or download services). The analysis and compilation of data sources for a specific group of countries, e.g. those from the members of the Iberoamerican Cadastre Permanent Board, allows to observe this heterogeneity. The objective of this Master Thesis is to propose an interoperable architecture for the establishment of a common model for cadastral data together with the necessary web services to facilitate access to different data sources in a harmonized and standardized way. In order to define a common model, this work has taken into account the data specifications proposed by the INSPIRE European directive, which are based on the cadastral data models of different European countries. In order to verify data access and service interoperability, this work also includes the development of a Web application that makes use of the functionalities provided by Web Feature Services (WFS) and Web Processing Services (WPS). The use of interoperable services allows the access to cadastral data as main information source or as complementary information for other applications. Key Words: Cadastre, Web Feature Service, Web Processing Service, Interoperability, Geographic Information. 2

4 Índice 1. Introducción... pág Contexto... pág Motivación... pág Objetivos... pág Metodología y Actividades... pág Estructura del documento... pág Desarrollo Analítico... pág Análisis de fuentes de datos catastrales en Iberoamérica... pág Propuesta de un Modelo Común y Pasarelas de Transformación pág Propuesta de un Modelo Común.... pág Pasarelas de Transformación... pág Implementación de los modelos ETL... pág Acceso a Datos de Catastro... pág El Estándar OGC Web Feature Service... pág El Estándar OGC Web Processing Service... pág Aplicación Web... pág Conclusiones... pág Referencias... pág Acrónimos... pág Anexos... pág Fuentes de Datos Catastrales... pág Agentes Catastrales en Iberoamérica... pág Descripción de los datos descargados de la Oficina Virtual del Catastro... pág Descripción de los datos descargados del Sistema de la Riqueza Territorial de Navarra... pág Descripción de los diagramas UML de los modelos de INSPIRE... pág Modelo de Parcelas Catastrales de INSPIRE... pág Modelo de Direcciones de INSPIRE... pág Modelo de Edificios de INSPIRE... pág Modelos Relacionales, resultado de la transformación de los diagramas de clases UML de INSPIRE.... pág Modelos ETL creados en Geokettle... pág Modelo de carga de datos obtenidos desde la Oficina Virtual del Catastro.... pág Modelo de carga de datos obtenidos desde el Sistema de Riqueza Territorial de Navarra.... pág Funcionamiento e Implementación de los servicios OWS.... pág Envío de Peticiones al WFS utilizando filtros OGC.... pág Configuración del servicio WPS.... pág Herramientas de software utilizadas.... pág Quantum GIS.... pág Geokettle.... pág PostgreSQL.... pág Deegree.... pág Eclipse.... pág. 90 3

5 Índice de Tablas tabla 1. Agentes catastrales participantes en la encuesta realizada por el CPCI tabla 2. Accesibilidad a datos catastrales tabla 3. Archivos de datos catastrales descargados tabla 4. Prefijos utilizados para a identificación de los modelos de INSPIRE tabla 5. Archivos de datos para el proceso de migración tabla 6. Correspondencia del archivo hojas.shp al modelo de parcelas catastrales tabla 7. Correspondencia del archivo masa.shp al modelo de parcelas catastrales tabla 8. Correspondencia del archivo parcela.shp al modelo de parcelas catastrales tabla 9. Correspondencia del archivo constru.shp al modelo de edificios tabla 10. Correspondencia del archivo inmuebles.csv al modelo de edificios tabla 11. Correspondencia del archivo inmuebles.csv al modelo de direcciones tabla 12. Atributos del elemento XML featuretypemapping tabla 13. Acrónimos tabla 14. Agentes catastrales de los países miembros del CPCI tabla 15. Acceso a datos geográficos catastrales tabla 16. Atributos de la tabla mapa tabla 17. Atributos de la tabla hojas tabla 18. Atributos de la tabla masa tabla 19. Atributos de la tabla parcela tabla 20. Atributos de la tabla subparce tabla 21. Atributos de la tabla constru tabla 22. Atributos de la tabla altipun tabla 23. Atributos de la tabla ejes tabla 24. Atributos de la tabla elemlin tabla 25. Atributos de la tabla elempun tabla 26. Atributos de la tabla elemtex tabla 27. Atributos de la tabla limites tabla 28. Descripción del atributo constru de la tabla constru tabla 29. Atributos de la tabla parcelas tabla 30. Atributos de la tabla parajes tabla 31. Atributos de la tabla subáreas tabla 32. Atributos de la tabla vías tabla 33. Atributos de la tabla unidades urbanas tabla 34. Atributos de la tabla municipios tabla 35. Atributos de la tabla polígono tabla 36. Atributos de la tabla cultivos tabla 37. Atributos de la tabla tipos tierra tabla 38. Estereotipos utilizados en los modelos de INSPIRE tabla 39. Atributos generales para todos las Clases de los modelos de INSPIRE tabla 40. Atributos de la clase BasicPropertyUnit tabla 41. Atributos de la clase CadastralBoundary tabla 42. Atributos de la clase CadastralParcel tabla 43. Atributos de la clase CadastralZoning tabla 44. Atributos de la clase Address tabla 45. Atributos de la clase AddressComponent tabla 46. Atributos de la clase adminunitname tabla 47. Atributos de la clase postaldescriptor tabla 48. Atributos de la clase addressareaname tabla 49. Atributos de la clase thoroughfarename tabla 50. Atributos del tipo de dato estructurado addresslocator tabla 51. Atributos del tipo de dato estructurado locatordesignator tabla 52. Atributos del tipo de dato estructurado locatorname tabla 53. Atributos del tipo de dato estructurado thoroughfarenamevalue tabla 54. Atributos del tipo de dato estructurado partofname tabla 55. Atributos de la clase abstractconstruction tabla 56. Atributos de la clase abstractbuilding tabla 57. Atributos de la clase building tabla 58. Atributos de la clase buildingunit tabla 59. Correspondencia entre los atributos del shapefile hojas y la tabla cp_cadastralzoning tabla 60. Correspondencia entre el shapefile masa y la tabla cp_cadastralzoning

6 tabla 61. Correspondencia entre el shapefile parcela y la tabla cp_cadastralparcel tabla 62. Correspondencia de las entradas constru.shp e inmuebles tabla 63. Correspondencia del archivo inmuebles al modelo de edificios tabla 64. Correspondencia del archivo inmuebles hacia el modelo de direcciones tabla 65. Transformación para la tabla ad_addresscomponentr tabla 66. Transformación para generar la tabla ad_addressrepresentation tabla 67. Tipos y niveles de los designadores de dirección tabla 68. Codificación de los designadores de dirección tabla 69. Transformación para generar la tabla locators tabla 70. Transformación para generar la tabla locatorname tabla 71. Transformación para crear los componentes de dirección tabla 72. Transformación para generar la tabla de partes de dirección

7 1. INTRODUCCIÓN 1.1. Contexto La obtención del Máster en Tecnologías de la Información Geográfica para la Ordenación del Territorio en la Facultad de Filosofía y Letras de la Universidad de Zaragoza requiere la realización de un trabajo fin de máster (TFM) que en es este caso es un trabajo académico específico. Este trabajo se ha realizado en el entorno del laboratorio de sistemas de información geográfica del Grupo de Sistemas de Información Avanzados (IAAA) 1, adscrito al Instituto de Investigación en Ingeniería de Aragón (I3A) 2 de la Universidad de Zaragoza. Las actividades del grupo están enfocadas al análisis, diseño, implementación, monitorización y evaluación de aplicaciones que abarcan áreas como sistemas de información geográfica (GIS), teledetección, infraestructuras de datos espaciales (IDE), metadatos y geoprocesamiento. Las investigaciones llevadas a cabo dentro del grupo se basan en las tecnologías de software libre y los estándares, especificaciones y/o recomendaciones establecidos por los organismos internacionales dedicados a facilitar el intercambio de información geográfica como el Open Geospatial Consortium (OGC) 3, la International Organization for Standardization (ISO) 4, o el World Wide Web Consortium (W3C) 5. La implementación de nuevas aplicaciones que permiten crear servicios interoperables es posible mediante la automatización de la interpretación, exploración, transformación y carga de datos que pueden ser obtenidos desde múltiples fuentes. Así, el grupo de investigación dedica sus esfuerzos a crear modelos que permitan automatizar estos procesos. La mayor parte de las aplicaciones consiguen la interoperabilidad con la implementación de geodatabases centralizadas sobre las cuales se crean distintos servicios web geográficos como servicios de mapas (Web Mapping Services - WMS) (Beaujardiere, 2006), servicios de features (Web Feature Services - WFS) (Vretanos, 2002), servicios de coberturas (Web Coverage Services - WCS) y servicios de procesamiento web (Web Processing Services - WPS) (Schut, 2007). La creación de los servicios web geográficos garantiza la realimentación técnica debido a que son servicios interoperables y pueden ser direccionados desde otras aplicaciones. Una de las temáticas específicas sobre la que se realizan aplicaciones es la administración del uso de la suelo, donde la utilización de sistemas de información geográfica es la clave para alcanzar la optimización de los procesos, que permiten a un país lograr sus objetivos para un desarrollo sostenible en base a la planificación y toma decisiones. La información geográfica disponible sobre la que se basa este tipo de aplicaciones se refiere a datos de catastro de diferentes fuentes, que en algunos casos son resultado de procesos sistematizados de levantamiento de información y almacenados en bases de datos centralizadas. En concreto, los territorios correspondientes a los países de Iberoamérica, son una base sobre la cual el Comité Permanente sobre el Catastro en Iberoamérica (CPCI) 6 ha emprendido la iniciativa de analizar periódicamente el grado de sistematización de los catastros y las tareas que se deben emprender en la implementación de sistemas de información multipropósito que permitan establecer bases nacionales únicas y automatizar la gestión del catastro para garantizar la seguridad de la propiedad. El objetivo del CPCI es la implantación de un Sistema de Información Catastral Iberoamericano, concebido como un sistema de información de creación colectiva (Data Catastro 2011). La iniciativa y los esfuerzos de la comunidad iberoamericana impulsan y motivan a aquellos países que aun no cuentan con la infraestructura tecnológica necesaria a iniciar la generación de datos geográficos, cumpliendo con los estándares que permitan disponer la información sobre modelos de datos únicos. Otra de las iniciativas importantes que abarcan la administración del uso del suelo es la directiva INSPIRE 7 que mediante la elaboración de especificaciones técnicas ha creado modelos de datos

8 estandarizados para los países miembros de la Unión Europea. Algunos de los modelos involucrados en la administración del uso del suelo son el modelo de Parcelas Catastrales, el modelo de Edificios, el modelo de Direcciones y el modelo de Uso del Suelo, los cuales permiten unificar información geográfica de los diferentes países, sobre aplicaciones desarrolladas en base a sistemas interoperables. La reingeniería de la administración del uso del suelo implica la necesidad de una visión que incorpore los objetivos de un desarrollo sostenible, argumentada en un enfoque más amplio e integrado (Williamson y Ting, 2001). Factores como el desarrollo sostenible, la globalización, urbanización, reformas económicas y la tecnología continúan cambiando la forma en que las poblaciones se relacionan con el territorio (Ting & Willamson, 1999). Estos cambios son los que impulsan a las organismos internacionales a llevar a cabo análisis sobre el estado del catastro en varios países. Varias investigaciones evalúan y comparan los sistemas catastrales existentes en el mundo, utilizando encuestas dirigidas a cada uno de los países, tomando en cuenta el estado de diferentes tópicos como el contexto, el marco institucional, el sistema catastral, la cartografía y los problemas identificados en cada país. Años atrás en uno de los análisis para la evaluación del catastro solamente participaron dos de los países iberoamericanos (Rajabifard et al., 2007), y actualmente el CPCI es el organismo que periódicamente evalúa el estado del catastro en la comunidad Motivación La existencia de geodatos de catastro en los países iberoamericanos y la necesidad de conocer factores como la disponibilidad de los datos, la existencia de servicios web geográficos, o los modelos de datos de los sistemas catastrales nos permiten tener un conocimiento de la base tecnológica sobre la que se puede un proponer un modelo unificado de catastro, tomando en cuenta las diferentes iniciativas de estandarización de modelos de datos existentes. La unificación de modelos catastrales requiere un análisis entre los modelos de datos de varios países que permitan garantizar la interoperabilidad y utilización de modelos comunes. Es fundamental conocer a fondo las propuestas de los modelos de datos referentes a la administración del uso del suelo, como aquellos propuestos en la iniciativa INSPIRE como Parcelas Catastrales, Edificios y Direcciones. Un entendimiento de los modelos mencionados nos permite crear modelos para la exploración, transformación y carga de datos catastrales provenientes de diferentes fuentes de datos para ser unificados en una plataforma tecnológica única. La ausencia de la componente catastro en varias de las IDES de los países iberoamericanos hacen necesaria la búsqueda de alternativas verificadas que pueden ser el inicio de la generación de sistemas de información geográfica sobre la web con una misma arquitectura, obteniendo de esta forma una plataforma única que permita centralizar la información catastral. La implementación de servicios web geográficos como WFS y WPS garantizan la interoperabilidad de las aplicaciones para permitir dinamizar y potencializar el valor de los datos de catastro, con lo cual se obtiene una fuente de información útil tanto para la comunidad en general como la retroalimentación técnica para otras aplicaciones. La utilización de software libre para el desarrollo de aplicaciones referentes al ámbito de las tecnologías de la información geográfica, se consolidan como una alternativa cada vez más utilizada, debido a las diferentes políticas gubernamentales de uso de software libre en la administración pública dentro de la comunidad iberoamericana Objetivos El objetivo de este Trabajo Fin de Máster es proponer una arquitectura interoperable donde se establezca un modelo de datos común de catastro junto con los servicios web necesarios que permitan acceder a los datos de las distintas fuentes de forma homogénea y estandarizada. Para ello, se establecen los siguientes subobjetivos: 7

9 Identificar los agentes catastrales en Iberoamérica y el estado del acceso a los datos catastrales ya sea datos en bruto o servicios web geográficos. Analizar los datos catastrales de las diferentes fuentes disponibles para crear un modelo de exploración, transformación y cargar los datos sobre un repositorio de datos único. Proponer una arquitectura de servicios web (WFS, WPS) que permita acceder a los datos de las distintas fuentes. Crear una aplicación cliente que permita acceder a los datos mediante un visualizador geográfico, con funcionalidades de búsqueda y geoprocesamiento Metodología y Actividades La metodología utiliza en el TFM, consta de tres fases: Planificación, Análisis y Desarrollo, como se muestra en la Figura 2. Estas fases se subdividen en el conjunto de actividades necesarias para alcanzar los objetivos propuestos: Planificación: Definición de objetivos y actividades. Análisis: Recopilar información relacionada con la temática de estudio para establecer el conjunto de países sobre los que se debe buscar los datos de catastro. Se procede a verificar la existencia de agentes catastrales en cada uno de los países y la recopilación de los sitios web para la búsqueda de servicios que disponga de datos catastrales para descarga o acceso por medio de servicios de features (WFS). Una vez identificadas las fuentes de descarga, se procede a compilar los datos para su análisis, y estructuración utilizando el modelo relacional de bases de datos. Desarrollo: Se procede a establecer e implementar el modelo único de datos sobre el que se debe cargar los datos previamente descargados. El proceso de carga de datos requiere la implementación de modelos ETL (Exploration, Transformation and Load) que permiten automatizar este proceso sobre la base de datos única. El repositorio de datos implantado permite la implementación de servicios web (WFS y WPS) para hacer posible la accesibilidad a los datos de tal forma que se puedan utilizar desde aplicaciones externas para visualización, consulta y geoprocesamiento. En la Figura 1 se muestra la utilización del tiempo en las tareas realizadas en el trabajo. La recopilación de la información junto a la implementación de los modelos ETL para la carga de los datos son tareas que demandan un alto coste de tiempo. Una buena recopilación de datos y una buena estructuración de los datos garantizan el éxito de los resultados que se pueden obtener de las tareas siguientes, como la implementación de los servicios OWS (WPS y WFS) la implementación de la aplicación web. Figura 1. Planificación de Tareas. 8

10 Figura 2. Diagrama de la metodología aplicada. 9

11 1.5. Estructura del documento La estructura del documento se organiza en seis capítulos que pretenden describir de forma clara las actividades desarrolladas para alcanzar los objetivos propuestos: El presente capítulo 1 de Introducción describe el contexto tecnológico y las motivaciones para la realización del TFM. Además se hace una descripción breve de las actividades a desarrollar para alcanzar los objetivos propuestos. El capítulo 2 describe las fuentes de datos utilizadas y el desarrollo de las actividades específicas como la unificación de modelos de datos, el acceso a datos y la implementación de una aplicación web que permite el acceso unificado a información catastral. El capítulo 3 describe las conclusiones obtenidas en base a las experiencias de la investigación, y desarrollo de las actividades realizadas en la ejecución del trabajo. Además se describen breves trabajos futuros que pueden ser integrados el resultado de este trabajo. En el capítulo 4 se listan las referencias bibliográficas de consulta, que han permitido establecer una base teórica y práctica sobre el trabajo. El capítulo 5 hace una descripción de los diferentes acrónimos utilizados en el presente documento. Al final del documento se encuentran los anexos que describen las especificaciones técnicas, procesos y el conjunto de herramientas de software utilizadas en las distintas fases de ejecución del trabajo. 10

12 2. DESARROLLO ANALÍTICO 2.1. Análisis de fuentes de datos catastrales en Iberoamérica Los países sobre los que se ha recopilado información relacionada a la temática de estudio son aquellos que son miembros del Comité Permanente sobre el Catastro de Iberoamérica, que en un total de veintiuno se muestran en la Figura 3. Figura 3. Países miembros del CPCI. Existen diferencias notables en la estructura de los sistemas de catastros entre los miembros del CPCI, partiendo desde la forma en que se administran los datos de catastro hasta la existencia de procesos sistematizados para el levantamiento, procesamiento y mantenimiento de la información catastral. Uno de los indicadores que nos muestra el estado del catastro es la accesibilidad a los datos. Con el desarrollo e implantación de infraestructuras tecnológicas para la gestión del catastro, se garantiza la disponibilidad de la información para las diferentes organizaciones y personas que utilizan este tipo de recursos. Son relevantes además las funcionalidades automatizadas dentro del acceso a la información. Para evaluar la accesibilidad el CPCI ha realizado encuestas a los agentes catastrales existentes en los países participantes, cabe indicar que dependiendo del tipo de administración del catastro que puede ser centralizada, descentralizada o mixta se pueden tener uno o varios agentes catastrales en un mismo país. En la Tabla 1 se muestra el número de agentes catastrales que participaron en la evaluación de acceso a datos. 11

13 Como se puede apreciar los países presentes en la Tabla 1 son fuentes potenciales para la obtención de datos catastrales. En el anexo se muestra un listado de todos los países miembros del CPCI, sus agentes catastrales y su participación dentro de las evaluaciones de catastro. Tabla 1. Agentes Catastrales participantes en la encuesta País Agentes Catastrales Encuestados por el CPCI Argentina 8 Colombia 3 El Salvador 1 España 1 México 3 Perú 2 Portugal 1 Uruguay 2 En cuanto a las restricciones de acceso a datos, en la mayoría de las entidades que tienen un sistema de acceso vía web, estas presentan restricciones a los datos catastrales, como la información que tiene reserva legal, por leyes de protección de datos o solo se permite consultar al titular de la parcela (Data Catastro 2011). A continuación se hace una breve descripción de la disponibilidad de datos correspondiente a los países presentes en la Tabla 1. En la República Federal de Argentina, la administración del catastro es descentralizada, por ello cada una de las veintitrés provincias que la conforman es responsable de cada uno de sus catastros, de esta forma cada provincia ha avanzado individualmente en cuanto a la modernización del catastro. Algunas de las provincias que destacan sobre las demás son: Santa Fe, Catamarca, Formosa y Tucumán. Estas provincias disponen de infraestructuras de datos espaciales con acceso a servicios de mapas (WMS). En cuanto a los agentes catastrales de las provincias restantes, algunos disponen de sitios web y están empezando el proceso de modernización del catastro. Dado que los datos no se encuentran disponibles para descargar sino solamente para la visualización, el catastro argentino es descartado como fuente de descarga de datos. La República de Colombia, sobresale sobre los países sudamericanos, el Instituto Geográfico Agustín Codazzi (IGAC) administra el sistema de información catastral (SIC) que de forma centralizada administra el catastro nacional con excepción de las ciudades de Bogotá, Santiago de Cali, Medellín y los municipios del departamento de Antioquia. Colombia cuenta con la Infraestructura Colombiana de Datos Espaciales (ICDE), que dispone de varios servicios WMS, entre los cuales está el servicio de Mapa Catastral. La ciudad de Bogotá ha desarrollado la Infraestructura de Datos Espaciales para el Distrito Capital (IDECA), la cual da acceso al catastro digital de Bogotá y a su geoportal 8. En Santiago de Cali está la oficina del catastro municipal, que despliega su información a través de servicios WMS por medio de la Infraestructura de Datos Espaciales de Santiago de Cali (IDESC). Se puede decir que Colombia avanza continuamente con la modernización del catastro pero aun no se dispone de los datos para su libre descarga sino solamente que es accesible desde visualizadores en geoportales. La República de El Salvador administra su catastro por medio del Centro Nacional de Registros (CNR). Esta institución dispone de un portal web que en la sección de productos digitales catastrales ofrece los datos de catastro por un precio específico, tanto la cartografía como la información de los propietarios de las parcelas. No dispone de una IDE ni de servicios de visualización de los datos. En España los datos catastrales son administrados por la Dirección General de Catastro (DGC) para quince de sus diecisiete comunidades autónomas. Las comunidades autónomas de Navarra y País Vasco administran sus catastros individualmente por separado. La DGC por medio de la Oficina Virtual del Catastro (OVC) difunde los datos catastrales por medio de servicios de descarga masiva de 8 Geoportal: es un portal web que permite acceder a servicios y datos geográficos. 12

14 datos y servicios WMS para el público en general. Además, cuenta con un servicio de features (WFS), que solo es accesible desde las entidades catastrales de la DGC presentes en las comunidades autónomas. La información disponible para el público en general permite acceso a los datos catastrales, con excepción de los nombres, apellidos, razón social, CIF, domicilio y valor catastral. La OVC además de los datos cartográficos de catastro dispone de varios servicios web que permiten acceso a datos de inmuebles complementarios a los datos catastrales. La Comunidad Autónoma Foral de Navarra administra su catastro por medio del Sistema de Riqueza Territorial, que permite el acceso a datos por medio de descarga de datos cartográficos y alfanuméricos. En la Comunidad Autónoma del País Vasco el catastro los administran tres distintas administraciones locales que son las diputaciones forales de Álava, Guipuzcoa y Vizcaya (Data Catastro 2009). La diputación de Álava permite acceso a datos desde su visualizador web de catastro. La diputación de Guipuzcoa permite acceso a los datos de cada municipio desde su sitio web y permite descargar los datos en formato dxf. La Diputación de Vizcaya dispone de un visualizador web para el acceso a datos, pero sin permitir la descarga de estos. En el anexo se hace una descripción de los datos que se pueden descargar de las fuentes de datos catastrales identificadas en España. Es importante mencionar que España es un modelo referente de gestión del catastro inmobiliario dentro del Comité Permanente sobre el Catastro de Iberoamérica, todos servicios de los que dispone en la OVC son accesibles desde la Infraestructura de Datos Espaciales de España (IDEE), que utilizando un catálogo de servicios de datos permite el acceso unificado a diferentes servicios de información geográfica que proveen varias instituciones públicas. En la República del Ecuador aún no existe una ley del catastro nacional. Sin embargo, la administración del catastro urbano es responsabilidad de cada municipio. En el ámbito rural el proyecto SigTierras gestiona el Programa Nacional de Información y Gestión de Tierras Rurales e Infraestructura Tecnológica. Esta iniciativa reciente se apoya en fotografías aéreas a escala 1:5000 para la posterior segmentación parcelaria en cada municipio. Este proyecto busca centralizar la información catastral del Ecuador, y actualmente dispone de un visualizador geográfico para acceder a las parcelas catastrales, sin que se puedan descargar los datos. La Infraestructura Ecuatoriana de Datos Geoespaciales (IEDG) permite el acceso a información geográfica por medio de servicios WMS, pero aun no cuenta con la componente de catastro. En la IDE del Ecuador converge la información geográfica proveniente de las distintas instituciones del estado, llevadas a cumplir obligatoriamente las políticas nacionales de información geoespacial, establecidas por el Consejo Nacional de Geoinformática (CONAGE). En la República Federal de México, al igual que en Argentina cada uno de sus estados tiene autonomía para la gestión del catastro, existen varias entidades catastrales a las que se puede acceder desde el Instituto Nacional de Estadística y Geografía (INEGI). El acceso a la información se realiza mediante consultas desde formularios disponibles en la web. En los servicios web que dispone el INEGI no se presenta la componente de catastro. La República de Perú, organiza el acceso a datos geográficos por medio del Portal de Datos Espaciales de Perú (GEOIDEP) desde el que se puede acceder a un catalogo de datos y un visualizador geográfico. El GEOIDEP no dispone de la componente catastro que es administrada de forma descentralizada para el catastro urbano y centralizada en la gestión del catastro rural. La ciudad de Lima cuenta con el Instituto Catastral de Lima que permite el acceso a la información catastral utilizando formularios web de consulta, sin que se pueda descargar datos. En Portugal el encargado de la administración del catastro es el Instituto Geográfico Portugués (IGP) que en la sección de productos de su sitio web dispone a la venta los datos catastrales. El Sistema Nacional de Información Geográfica se constituye como la IDE de Portugal, permite la visualización de los datos catastrales desde formularios web. Además presenta un catalogo de servicios de features (WFS) pero no dispone de la componente de catastro. La Republica Oriental del Uruguay administra su catastro de forma centralizada desde la Dirección Nacional del Catastro (DNC), existiendo también en el municipio de Montevideo el Servicio de Catastro y Avalúos. Desde el portal web de la DNC se puede acceder a la visualización de los datos catastrales de cada una de los departamentos, pero sin poder descargar datos. La 13

15 Infraestructura de datos de Espaciales de Uruguay permite el acceso a los datos de catastro utilizando un visualizador geográfico. Entre los países sudamericanos en el área de geotecnologías se destacan dos procesos: el inicio de las actividades orientadas a la formación de la Infraestructura de Datos Espaciales en 2004 bajo la coordinación del Instituto Geográfico Agustín Codazzi en Colombia y el reconocimiento oficial del Sistema Nacional de Coordinación de la Información Territorial en Chile en 2006 (Ebra, 2009). La Tabla 2 muestra un resumen de los datos catastrales accesibles y la posibilidad de descarga. En la Tabla 15 de los anexos se listan las direcciones de los accesos vía web de los que disponen estos países. País Argentina Colombia Ecuador El Salvador España México Perú Portugal Uruguay Tabla 2. Accesibilidad a Datos Catastrales Accesibilidad a Datos Catastrales Visualizador Geográfico Visualizador Geográfico Visualizador Geográfico Descarga de Datos con pago Visualizador Geográfico y Descarga de Datos Visualizador Geográfico Formularios Web Formularios Web y Visualizador Geográfico Visualizador Geográfico De lo descrito se concluye que el país que posibilita la descarga de datos para su posterior análisis y procesamiento es España, y las comunidades autónomas de Navarra y País Vasco del mismo país. Los demás países presentes en la Tabla 2 se encuentran en proceso de la modernización del catastro y desarrollo de Infraestructuras de Datos Espaciales que permitan la estandarización de los procesos utilizados en la gestión de datos geográficos. Los datos que se analizan son aquellos provenientes de organizaciones que posibilitaron la descarga, correspondientes a datos provenientes de la Oficina Virtual del Catastro de España y datos del Sistema de Riqueza Territorial de la Comunidad Foral de Navarra. Los archivos disponibles descargados se listan en la Tabla 3. Estas dos fuentes de información no disponen de modelos de datos específicos, sino que a partir de los datos descargados se ha deducido el modelo relacional de base de datos para cada fuente de información. Para obtener los modelos relacionales de datos que se muestran en las figuras 4 y 5, se han analizado las estructuras que se describen en detalle en los anexos y En la Tabla 3 se hace un listado de las fuentes de datos y los archivos descargados de forma masiva de cada una de ellas. Para el desarrollo de los modelos de migración de datos que más adelante se describen, inicialmente se cuenta con datos de tres municipios españoles como son Zaragoza, Jaca, Pamplona y el municipio ecuatoriano de Mejía. Tabla 3. Archivos de datos catastrales descargados Fuente de Datos Archivos Tipo de Datos MAPA Geográficos MASA Geográficos PARCELA Geográficos CONSTRU Geográficos Oficina Virtual del Catastro de SUBPARCE Geográficos España HOJAS Geográficos ALTIPUN Geográficos CARVIA Alfanumérico EJES Geográficos 14

16 ELEMLIN Geográficos ELEMPUN Geográficos ELEMTEX Geográficos LIMITES Geográficos Web Service OVC - España. inmuebles Alfanumérico Municipios Alfanumérico Parajes Alfanumérico Parcelas Alfanumérico Subareas Alfanumérico Subparcelas Alfanumérico Unidades_urbanas Alfanumérico Vías Alfanumérico Sistema de Riqueza Territorial Catast_Pol_Municipio Geográficos de Navarra Catast_Pol_ParcelaMixta Geográficos Catast_Pol_ParcelaRusti Geográficos Catast_Pol_ParcelaUrba Geográficos Catast_Pol_ParcelaVia Geográficos Catast_Pol_ParcelaPoligono Geográficos Catast_Pol_SubparUrba Geográficos Figura 4. Modelo Relacional de base de datos de la OVC. 15

17 Figura 5. Modelo relacional de base de datos de Navarra Propuesta de un Modelo Común y Pasarelas de Transformación Propuesta de un Modelo Común. A partir de los modelos relacionales de datos, por el análisis de la información contenida en los archivos descargados y al no tener modelos de datos estructurados correspondientes al resto de países del CPCI, con el objetivo de unificar modelos de datos, se eligen los modelos propuestos por la iniciativa INSPIRE. Específicamente los modelos UML de INSPIRE que permiten reestructurar la información descargada son los modelos de Parcelas Catastrales, Direcciones y Edificios. Cada uno de los modelos cuenta con especificaciones técnicas que se describen en el anexo 6.2. El proceso de análisis de los modelos de datos de la información descargada y los modelos de INSPIRE es fundamental en el trabajo de unificación de datos. Con el objetivo de llevar los modelos a una misma representación para su interpretación es necesario que los modelos de datos de INSPIRE representados en diagramas de clases UML (Unified Modeling Language) sean transformados al modelo relacional, que es una definición lógica, independiente y abstracta de los objetos, operadores y demás que en conjunto constituyen la máquina abstracta con la que interactúan los usuarios (Date, 2001). Las especificaciones de INSPIRE definen los estereotipos de la Tabla 38 del anexo 6.2, utilizados para definir los elementos que intervienen en un diagrama de clases UML, y además de estos estereotipos se definen los atributos generales de la Tabla 39, presentes en todos los objetos espaciales. A continuación se hace una breve conceptualización de los tres modelos de INSPIRE antes mencionados. En el modelo de Parcelas Catastrales de INSPIRE, las parcelas catastrales pueden estar formando una porción del territorio nacional. La parcela catastral es considerada como una sola área de superficie (tierra y/o agua), bajo los derechos de propiedad homogénea y única (INSPIRE Thematic Working Group Cadastral Parcels, 2010). En cuanto al modelo de Direcciones de INSPIRE, se define una dirección como la Localización de propiedades basadas en identificadores de dirección, usualmente por nombre de vía, número de casa, código postal. Para identificar la dirección sin ambigüedades en un amplio contexto una dirección debería estar asociada con un número de componentes de dirección que definen su 16

18 localización dentro de cierta área geográfica. Cada componente de dirección representa un identificador espacial como por ejemplo el nombre de la vía, distrito, código postal, municipalidad, región o país (INSPIRE Thematic Working Group Addresses, 2010). El modelo de Edificios de INSPIRE se basa en el modelo de aplicación Building Core 2D. Define los edificios como estructuras cerradas, sobre y/o bajo la superficie terrestre y son utilizados para resguardar personas, animales, cosas o la producción de bienes económicos y que refieren a cualquier estructura construida o levantada permanentemente sobre su sitio (INSPIRE Thematic Working Group Building, 2011). Un edificio puede estar compuesto de varias partes. Una parte de un edificio es una subdivisión de un edificio que es homogénea respecto a sus características físicas, funcionales o temporales. En el conjunto de elementos presentes en los tres diagramas de clases UML se identifican distintos tipos de asociaciones como asociaciones binarias y generalizaciones. En estas asociaciones participan diferentes tipos de estereotipos como: Feature Types, Data Types y Code Lists. A continuación se ejemplifican los criterios establecidos para la transformación al modelo entidad relación. Transformación de asociaciones binarias. En este caso tomamos la asociación binaria existente entre las clases CadastralParcel y CadastralZoning que se muestra en la Figura 6. Figura 6. Asociación entre las clases CadastralParcel y CadastralZoning. En este caso por cada objeto de la clase CadastralParcel pueden haber cero o un objeto de la clase CadastralZoning, mientras que por cada objeto de la clase CadastralZoning pueden haber cero o varios objetos de la clases CadastralParcel. Esto significa que por cada zona catastral pueden existir varias parcelas catastrales y que cada parcela catastral puede pertenecer a una sola zona catastral. Esto llevado al modelo relacional, permite establecer claves primarias en las tablas correspondientes a cada clase y la clave ajena zoning en la tabla CadastralParcel, referenciada desde la clave primaria de la tabla Cadastralzoning. De ahora en adelante establecemos la utilización de los prefijos listados en la Tabla 4 para distinguir a qué modelo pertenece cada una de las tablas. Tabla 4. Prefijos utilizados para la identificación de los modelos de INSPIRE Modelo CadastralParcels Address Buildings Prefijo CP La transformación del la asociación descrita entre las clases llevada al modelo relacional es el que se muestra en la Figura 7. AD BU Figura 7. Resultado de transformación de UML al modelo relacional. 17

19 En caso de que la multiplicidad sea (0..*) a ambos lados de la asociación, la transformación da lugar a una tercera tabla. En el caso de la asociación entre las clases CadastralParcel y Address que se muestra en la Figura 8, el resultado en el modelo relacional da lugar a una tercera tabla con el nombre ad_addressparcel, la cual se referencia con dos claves ajenas hacia las tablas cp_cadastralparcel y ad_address, como se muestra en la Figura 9. Figura 8. Asociación entre las clases CadastralParcel y Address. Figura 9. Resultado de transformación de UML al modelo relacional con multiplicidad [(0..*) (0..*)]. Transformación de Tipos de Datos Estructurados. Las asociaciones entre un Feature Type y un Data Type, se representan en UML como se muestra en la Figura 10, en este caso el tipo de dato GeographicPosition es utilizado en la clase Address, y la multiplicidad en el atributo position indica que puede haber una o más posiciones por cada dirección. Para transformar esta asociación, la clase se representa con una tabla y el tipo de dato con otra, cada una con su clave primaria. En la tabla que representa al tipo de dato se crea una clave ajena referenciada hacia la clave primaria de la tabla correspondiente a la clase. De esta forma queda establecida una relación de uno a varios entre las tablas como se muestra en la Figura 11. Figura 10. Representación de una Feature Type y un Data Type en UML. Figura 11. Transformación de UML al modelo relacional de un Tipo de Dato. Transformación de la generalización. En este caso la clase hija hereda los atributos de la clase padre, por lo tanto la clase padre da lugar a una tabla con su respectiva clave primaria y la clase hija da lugar a una tabla sin clave primaria, por lo tanto se crea una clave ajena referenciada a la clave primaria de tabla que representa la clase padre. En la Figura 12 se muestra la clase hija AbstractBuilding que hereda los atributos de la clase padre AbstractConstruction y la muestra el resultado de la transformación al modelo relacional. 18

20 Figura 12. Representación de una generalización. Figura 13. Resultado de la transformación de una generalización. Los resultados de la transformación de los modelos de Parcelas Catastrales, Edificios y Direcciones se muestran en las figuras del anexo 6.3. Los modelos relacionales nos permiten definir de forma clara el proceso de implementación de las tablas en la base de datos. Las dependencias entre las tablas exigen que los scripts sql para la creación de las tablas, se ejecuten en el siguiente orden: Script para el modelo de Parcelas Catastrales. Script para el modelo de Edificios. Script para el modelo de Direcciones. Script para el Ingresar los datos a los CodeLists. La implementación de las tablas de la base de datos se ha realizado en el Sistema Gestor de Bases de Datos Relacionales PostgreSQL 9, que gracias a su extensión espacial PostGIS permite la administración de información geográfica e información alfanumérica de forma conjunta. PostGIS procesa y almacena datos geográficos con diferentes tipos de geometrías sobre las tablas espaciales en PostgreSQL. Además permite la integración con otras herramientas de tratamiento de información geográfica como R 10, Grass 11, QGIS 12, Mapserver 13 (Cagnacci y Urbano, 2007) Pasarelas de Transformación A partir de los modelos relacionales correspondientes a las fuentes de datos y la unificación del modelo relacional de INSPIRE, es necesario considerar que datos de los archivos descargados son susceptibles de ser migrados a la base de datos. El análisis de los modelos de INSPIRE y los datos descargados, permite establecer correspondencias entre los atributos de los archivos descargados hacia los atributos de las tablas del modelo de INSPIRE. Estas correspondencias son establecidas tomando en cuenta las definiciones de las clases y sus atributos presentes en las especificaciones técnicas de los modelos. El análisis de correspondencia de datos establece que varios de los archivos descargados no deben ser tomados en cuenta para la carga de datos. En la Tabla 5 se listan los archivos que son tomados en cuenta para el proceso de migración de datos

21 Tabla 5. Archivos de datos para el proceso de migración. Fuente de Datos Archivo Tipo de Datos MAPA Geográficos MASA Geográficos PARCELA Geográficos Oficina Virtual del Catastro CONSTRU Geográficos de España SUBPARCE Geográficos HOJAS Geográficos Inmuebles (Web Service) Alfanumérico Subareas Alfanumérico Unidades_urbanas Alfanumérico Vías Alfanumérico Catast_Pol_Municipio Geográficos Sistema de Riqueza Catast_Pol_ParcelaMixta Geográficos Territorial de Navarra Catast_Pol_ParcelaRusti Geográficos Catast_Pol_ParcelaUrba Geográficos Catast_Pol_ParcelaVia Geográficos Catast_Pol_ParcelaPoligono Geográficos La asignación de correspondencias requiere del análisis de las relaciones espaciales entre los objetos para lo cual se ha utilizado un sistema de información geográfica que permita visualizar los datos y las relaciones implícitas en la información alfanumérica. En el caso de los datos provenientes de la OVC, estos se encuentran en formato shapefile, excepto el archivo de inmuebles que es un archivo CSV, obtenido desde un web service en base a las referencias catastrales de las parcelas. Correspondencias de los Datos de la Oficina Virtual del Catastro Los archivos shapefile y el archivo de inmuebles se distribuyen en las tablas SQL correspondientes con los modelos de INSPIRE como se presenta en la Figura 14. Figura 14. Correspondencia de datos de la OVC hacia los modelos de INSPIRE. 20

22 En las siguientes tablas se detalla la correspondencia de los campos de los archivos shapefile descargados de la OVC, hacia las tablas SQL implementadas en la base de datos. Tabla 6. Correspondencia del archivo HOJAS.shp al modelo de Parcelas Catastrales Shapefile Original HOJAS.shp the_geom GEOM MAPA FECHAALTA FECHABAJA HOJA NINTERNO Tabla SQL cp_cadastralzoning geometry inspireversion beginlifespanversion endlifespanversion nationalcadastralzoningreference label level levelname inspirens En las tablas de correspondencia como la Tabla 6, si un campo del archivo original no tiene correspondencia a la tabla SQL, el dato que contiene el campo del archivo original se pierde. Las tablas de correspondencia son necesarias para la implementación de los modelos de migración de datos, en los cuales se realizan procesos de exploración, transformación y carda de datos Tabla 7. Correspondencia del archivo MASA.shp al modelo de Parcelas Catastrales Shapefile Original MASA.shp the_geom AREA COORX COORY DELEGACION FECHAALTA FECHABAJA HOJA MAPA MASA MUNICIPIO Tabla de salida cp_cadastralzoning geometry referencepoint inspireversion beginlifespanversion endlifespanversion nationalcadastralzoningreference label level levelname inspireversion Tabla 8. Correspondencia del archivo PARCELA.shp al modelo de Parcelas Catastrales Shapefile Original PARCELA.shp the_geom COORX Tabla de salida cp_cadastralparcel geometry referencepoint 21

23 COORY VIA NUMERODUP NUMSYMBOL AREA FECHAALTA FECHABAJA GEOM MAPA MUNICIPIO MASA TIPO PARCELA REFCAT referencepoint areavalue inspireversion beginlifespanversion endlifespanversion zoning nationalcadastraltype nationalcadastralreference label inspireid Tabla 9. Correspondencia del archivo CONSTRU.shp al modelo de Edificios Entradas COSNTRU.shp (co) y tabla inmuebles (inm) co.the_geom co.fechaalta co.fechabaja co.refcat co.constru inm.luso Tabla de salida bu_abstractconstruction (ac), bu_abastractbuilding (ab), bu_currentuse (cu), bu_buildinggeometry (bg) bg.geometry ac.inspireversion ac.beginlifespanversion ac.endlifespanversion ac.inspireid bu.numberofwellings bu.numberoffloorsaboveground bu.numberofbuildingunits cu.currenteuse bu.inspirens Tabla 10. Correspondencia del archivo inmuebles.csv al modelo de Edificios Entrada Inmuebles.csv corx cory pc1 pc2 car cc1 cc2 sfc Tabla de salida bu_buldingunit (bu), xtbu_buildingunitextention(xbu) bu.geometry bu.inspireid xbu.officialarea bu.inspirens bu.inspireversion bu.beginlifespanversion 22

24 Tabla 11. Correspondencia del archivo inmuebles.csv al modelo de Direcciones Entrada Inmuebles pc1 pc2 car cc1 cc2 corx cory Tabla de salida ad_address(ad), ad_addresscomponent(ac), ad_geographicposition (gp) ad.inspireid ac.inspireid ad.inspirens ad.inspireversion ad.status ad.beginlifespanversion gp.geometry ac.inspirens ac.inspireversion ac.beginlifespanversion ac.status Correspondencias de los Datos del Sistema de Riqueza Territorial de Navarra. Como se muestra en la Figura 15 los datos descargados desde el Sistema de Riqueza Territorial de de Navarra, útiles en la migración de datos son seis archivos en formato shapefile que se corresponden hacia el modelo de Parcelas Catastrales y tres archivos de texto que se corresponden hacia el modelo de Direcciones. En este caso no tenemos correspondencia hacia el modelo de Edificios, debido a que en los datos descargados no contienen las subdivisiones de las parcelas. En el anexo se hace una descripción de las correspondencias entre los archivos descargados y las tablas sql de la base de datos. Las correspondencias hacia un modelo común de datos permiten establecer las transformaciones de datos que se deben aplicar para la carga de datos desde los archivos descargados hacia la base de datos Implementación de los modelos ETL Las herramientas de Extracción-Transformación-Carga (ETL) son utilizadas para la extracción de datos de varias fuentes, permiten depurar, personalizar, dar un nuevo formato a los datos para finalmente llevarlos a un repositorio. La construcción de procesos ETL es potencialmente una de las grandes tareas involucrada en el almacenamiento de datos, puede llegar a ser complejo, consumir tiempo y recursos. La implementación de los procesos requieren el entendimiento de tres aspectos principales: las fuentes de datos, el almacén de datos de destino y la correspondencia de los datos. Las fuentes de datos y el almacén de destino por lo general se encuentran en modelos estándares como diagramas entidad relación o diagramas de clases UML, pero el mapeo para la correspondencia de los datos no es un modelo estándar. En los procesos ETL, los datos se extraen de las fuentes de datos, se transforman para que pueda existir una correspondencia hacia el modelo del destino de datos y son cargados hacia la base de datos (Moss, 2005). Los procesos ETL son una combinación compleja de procesos y tecnologías que consumen una parte significante de la implantación de una base de datos y requiere de habilidades de diseñadores de bases de datos y desarrolladores de aplicaciones. Es necesario que el desarrollo del proceso disponga de su documentación de diseño para el éxito de la fase de carga de datos. 23

25 Figura 15. Correspondencia del Sistema de Riqueza Territorial Navarra hacia los modelos de INSPIRE. Un modelo ETL se compone de tres pasos funcionales consecutivos: Extracción, Transformación y Carga, como se muestra en la Figura 16. Figura 16. Estructura general de un proceso ETL. La Extracción es el primer paso en cualquier escenario ETL, es responsable de extraer los datos de las diferentes fuentes. Cada fuente de datos tiene sus distintas características que necesitan ser administradas en orden para extraer de forma efectiva los datos. Este paso necesita integrar de forma efectiva diferentes plataformas, tales como diferentes sistemas de administración de bases de dato, diferentes sistemas operativos y diferentes protocolos de comunicaciones. El segundo paso en cualquier escenario ETL es la transformación de los datos, que busca depurar y estructurar los datos de entrad para garantizar que los datos sean correctos, completos, consistentes y no existan ambigüedades. En este paso se procesan los datos para que la correspondencia de los datos de entrada hacia la base de datos sea exitosa. 24

26 La carga de datos hacia un repositorio de datos como puede ser una base de datos es el paso final en el escenario ETL. In este paso se cargan sobre la base de datos, los datos provenientes de los pasos previos de extracción y transformación. La creación de modelos ETL permite la reutilización de tareas. En este caso se ha utilizado la herramienta ETL Geokettle 14, que es una herramienta muy potente para datos espaciales, dedicada a la integración de fuentes de datos para la construcción y actualización de bases de datos geoespaciales, almacenes de datos y servicios. Por cada una de las fuente da datos se ha creado un modelo ETL, teniendo como resultado tres modelos ETL. En cuanto al sistema de referencia espacial asignado a las tablas espaciales de la base de datos es el Sistema de Referencia Terrestre Europeo de 1989 (ETRS89), por esta razón todos los sistemas de referencia espacial correspondientes a los datos que sean llevados hacia las tablas espaciales de PostgreSQL, deben ser transformados en las transformaciones implementadas en Geokettle. La implementación de los modelos ETL en Geokettle se describen en el anexo 6.4. Fuentes de datos distintas requieren procesos ETL diferentes, según las correspondencias a la base de datos. La Figura 17, muestra el modelo ETL, compuesto de tres subprocesos ETL, que trabajan sobre las tres fuentes de datos diferentes y almacenan los datos transformados sobre una base de datos única. Como se muestra en la Figura 18, la herramienta utilizada organiza los procesos de forma distribuida de tal forma que el modelo principal está compuesto de trabajos independientes y estos trabajos se componen de transformaciones específicas que procesan los archivos de entrada y envían los datos a los correspondientes almacenes de datos de salida. La versatilidad de Geokettle permite integrar datos y geodatos en múltiples formatos, y en la fase de transformación permite integrar diversas tecnologías de procesamiento de datos y geoprocesamiento de datos espaciales. Figura 17. Procesos ETL diferentes que trabajan en un escenario de ejecución paralela. El almacenamiento de los datos en el repositorio único, hace factible la implementación de servicios OCG (OWS) que permiten el acceso a datos desde diferentes aplicaciones Acceso a Datos de Catastro Los servicios geoespaciales permiten a los usuarios tener acceso a los datos y compartir información de una forma rápida y más eficiente. Lo que hace a los servicios geoespaciales diferentes de los servicios web comunes son las características de los datos geoespaciales sobre los cuales operan, los cuales son diversos, tienen un gran volumen y cierta complejidad (Granell et al., 2007). Esto dificulta la integración de los datos geoespaciales por los diferentes modelos de datos existentes, formatos de datos y relaciones espaciales (intersección, cruce, etc.) Sin embargo, las arquitecturas orientadas a servicio (SOA) que involucran la administración de datos geoespaciales son posibles en parte gracias a la comunidad geoespacial, bajo el apoyo del OGC, que ha propuesto descripciones de

27 interfaces específicas, algunas complementarias a las ya utilizadas para web services (WSDL, SOAP). Algunos de los estándares desarrollados por el OGC son el Web Feature Service (WFS), Web Map Service (WMS), Web Coverage Service (WCS) y Catalog Web Service (CSW). Figura 18. Estructura de modelos ETL en Geokettle. Los servicios geoespaciales pueden proveer datos geoespaciales o no geoespaciales y funcionalidades como la extracción de datos desde un repositorio remoto, transformación de coordenadas, transformaciones de formato, rutinas de interpolación, representación de mapas, etc. La comunidad geoespacial se ha dado cuenta que la generación de estándares para el acceso web a sistemas de geoprocesamiento es un paso en la evolución de las infraestructuras de datos geoespaciales (Yang et al., 2010). Por otra parte la estandarización debe impulsar la implementación de servicios de geoprocesamiento, los cuales no solo deben beneficiar la investigación en las geociencias, sino además otras áreas (Li et al., 2010). El OGC aprobó el estándar llamado Web Processing Service (WPS) en su versión (Schut, 2007). Las especificaciones del estándar WPS describen un mecanismo por el cual el geoprocesamiento puede ser realizado por servidores remotos, principalmente utilizando extensible markup language (XML) para la comunicación a través de internet. Las especificaciones indican que para el protocolo de comunicación se utiliza XML. Un documento XML está hecho para elementos individuales, los cuales son contenedores lógicos para datos relacionados. Un elemento puede contener otros elementos, y cualquier elemento puede contener atributos que describen el elemento. XML está diseñado para ser directamente utilizado en internet, legible por los humanos y razonablemente claro, formal y conciso y fácil de crear (Bray et al., 2008). El acceso a los datos de catastro que se encuentran almacenados en el repositorio único, se ha implementado utilizando los estándares Web Feature Service (WFS) y Web Processing Service (WPS) El Estándar OGC Web Feature Service De acuerdo a OGC la interface del estándar Web Feature Service define una interface para peticiones específicas para obtener objetos geográficos utilizando llamadas a una plataforma web independiente (Vretanos, 2002). El estándar WFS define interfaces y operaciones para acceso a datos y la manipulación de un conjunto de objetos geográficos, incluyendo: 26

28 Obtener objetos utilizando consultas sobre condiciones espaciales o no espaciales. Obtener la descripción de las propiedades de los objetos. Crear nuevas instancias de objetos. Eliminar una instancia de un objeto. Actualizar una instancia de un objeto. Bloquear la instancia de un objeto. El conjunto de las operaciones de la especificación WFS se lo ha identificado como Web Feature Service Transactions o WFS-T de forma abreviada. El conjunto de las cuatro últimas operaciones de la lista constituyen las operaciones necesarias que permiten la funcionalidad de edición de datos geoespaciales sobre la web. La codificación especificada para la entrada y salida de datos es el Geography Markup Language (GML) (Cox et al., 2002). La implementación del WFS que permite el acceso a los datos vectoriales catastrales se ha desarrollado utilizando Deegree 15, que es un software de código abierto para Infraestructuras de datos Espaciales y la web geoespacial. Deegree incluye componentes para administración de datos geoespaciales, incluyendo el acceso a datos, visualización, descubrimiento y seguridad. Este software está desarrollado en base a los estándares del OGC y el ISO TC 211. La configuración del WFS consiste en un archivo XML de configuración y uno o varios feature stores 16 que pueden acceder a diferentes fuentes de datos como shapefiles o bases de datos espaciales como PostGIS. La Figura 19 muestra como deegree accede a distintos feature stores desde el servicio de features. Figura 19. Componentes involucrados en la configuración de un WFS en deegree. La configuración del feature store, es una de las principales tareas, debido a que permite el acceso a los datos. Tomando en cuenta que los datos que provee el WFS deben ajustarse en su estructura de salida a los modelo UML de INSPIRE, deegree provee distintos tipos de configuración de feature stores como son: Shape feature store. Memory feature store. Simple SQL feature store. SQL feature store: Basics. SQL feature store: Table-driven mode. SQL feature store: Schema-driven mode. Para este caso específico la configuración del feature store utilizada es SQL feature store: Schema-driven mode, que permite recuperar definiciones de Feature Types y declaraciones de propiedades de un esquema de aplicación GML. En esta configuración se debe definir el identificador de la conexión JDBC, el sistema de referencia de coordenadas de las geometrías almacenadas y los esquemas GML que definen la estructura de los datos de salida. La Figura 20, muestras los parámetros de configuración del archivo XML correspondiente al Feature Store Un Feature Store en deegree es un mecanismo de acceso hacia los datos almacenados en diferentes formatos. 27

29 Figura 20. Configuración básica de un SQLFeatureStore. En el archivo de configuración del Feature Store se define como los Feature Types del esquema XML son mapeados a las tablas y columnas de la base de datos. Para esto el Schema-driven mode utiliza el mapeo relacional, donde cada Feature Type es definida por el elemento XML <FeatureTypeMapping> que se describe en la Tabla 12. Tabla 12. Atributos del elemento XML FeatureTypeMapping ATRIBUTO name table DESCRIPCIÓN Es el nombre del Features Type a mapear. Utiliza los mecanismos de namespace (xmlns) para indcar los prefijos utilizados (cp, ad, bu-core2d) Es el nombre de la tabla de la base de datos que almacena los datos correspondientes al Feature Type. Las propiedades pueden ser mapeadas desde tablas relacionadas, pero la tabla debe contener al menos una columna que se constituya como Feature Id. En la configuración del Feature Store, cada elemento <FeatureTypeMapping> debe tener un elemento interno del tipo <FIDMapping>, que se corresponde al Feature Id de la tabla de la base de datos. En la Figura 21 se muestra el mapeo de la tabla cp_cadastralparcel hace la Feature Type CadastralParcel y el Feature Id cadastralparceldbk mapeado hacia el FIDMapping Figura 21. Mapeo de una tabla hacia un Feature Type y su FIDMapping. Cada elemento <FeatureTypeMapping> además del FIDMapping puede contener las propiedades del Feature Type que se asocian con los campos de la tabla de base de datos. Estas propiedades pueden ser de diferentes tipos: Primitive : Mapea un valor simple de la feature como puede ser un valor de texto o numérico. Geometry: Mapea un valor geométrico de la feature. Feature: Mapea hacia una feature referenciada desde la feature inicial. Complex: Mapea un elemento complejo que se corresponden a los Data Types del esquema GML. La Figura 22 muestra el mapeo de tres de las propiedades del Feature Type Cadastral Parcels, hacia las columnas de la tabla cp_cadastralparcel. 28

30 Figura 22. Mapeo de una tabla hacia un Feature Type y su FIDMapping. En la configuración del Feature Store se deben especificar cada una de los Feature Types que necesitan ser desplegados en el WFS. En el anexo se muestra varias de las pruebas realizadas para verificar el funcionamiento del WFS en el cual se ha incluido el estándar de consulta OGC Filtering (Vretanos, 2005). Para acceder al WFS en funcionamiento se ha seleccionado peticiones tipo Get, utilizando la URL (uniform resource locator) del servicio, enviando parámetros y filtros que permitan obtener datos específicos. Al verificar las propiedades del WFS, utilizando la operación GetCapabilities, podemos encontrar el listado de operaciones que podemos realizar sobre las features de las tablas de base de datos. Las operaciones las podemos encontrar en la sección ows:operationsmetadata del resultado de la operación GetCapabilities. Las operaciones que permite realizar el WFS son: DescribeFeatureType: La función de esta operación es generar una descripción de los feature types que se encuentran disponible con la implementación del WFS. Define como el WFS espera las instancias de las features para ser codificados sobre la entrada (en respuesta solicitudes de Insert o Update) y como las instancias de las features puden ser generadas sobre las salidas (en respuesta a solicitudes GetFeature y GetGmlObject). GetFeature: Es una operación que permite obtener una o varias features de un WFS. GetGmlObject: Permite obtener features por ID desde un WFS. Transaction : Esta orientado a describir las operaciones de transformación de datos que están disponibles para las features en la web. Esta operación permite realizar transacciones de Insert, Update y Delete. GetCapabilities: Esta operación está presente en todos los servicios web OGC (OWS), y permite obtener los metadatos de la descripción de un servicio web. De las operaciones listadas, la operación GetFeature permite acceder a los datos para realizar consultas remotas sobre la base de datos. Esta operación es la más utilizada para proveer el acceso a los datos de catastro. En la Figura 23 se muestra un ejemplo de la operación GetFeature sobre la Feature Type ad:address, utilizando un filtro de igualdad sobre la propiedad inspireid El estándar OGC Web Processing Service La especificación Web Processing Service define un mecanismo por el cual un cliente puede enviar una tarea de procesamiento a un servidor para que este la ejecute (Schut, 2007). El servicio define una instancia de servidor, o servidor, como una entidad la cual puede proveer de uno o más procesos, o tareas de procesamiento individual. De esta forma cualquier servidor puede ser capaz de resolver múltiples diferentes, y no necesariamente procesos relacionados. Cualquier actividad de geoprocesamiento puede ser presentada en un formato online plug-in (Michaelis y Ames, 2009). 29

31 Figura 23. Operación Get Feature sobre ad:address. El principal objetivo de los servicios de procesamiento web es definir un protocolo de comunicación XML para geoprocesamiento remoto. Existen tres tipos de peticiones clave que pueden ser resultas por un servidor WPS: GetCapabilities, DescribeProcess, y Execute. La primera no requiere de ningún parámetro y solicita al servidor una lista de los procesos individuales que están disponibles en el servidor, junto con un breve resumen y palabras clave. Una vez que se ha seleccionado un proceso, la petición DescribeProcess puede ser enviada. La respuesta a esta solicitud la misma información que la respuesta a GetCapabilities, mas información detallada sobre los parámetros de entrada necesarios para el proceso. Los resultados complejos por lo general son codificados en XML, utilizando GML y, gramática XML, para codificar y comunicar el contenido geoespacial. La tercera petición (Execute) puede ser invocada, solicitando al servidor que resulva una operación. Los parámetros necesarios para la petición Execute incluyen el nombre del proceso y los parámetros de entrada necesarios. La respuesta a Execute es un documento ExecuteResponse, otro documento XML el cual indica el estado del proceso, las entradas que fueron utilizadas y valores de salida simples o enlaces a salidas complejas. El estado del proceso puede ser ProccessAcepted, que indica que el proceso ha sido recibido; Process Started, indica que el proceso está en ejecución; ProcessSucceeded, significa que el proceso ha sido completado; o ProcessFailed, indicando que ha ocurrido un error. El WPS se ha implementado utilizando el software Deegree y la herramienta de desarrollo Eclipse 17 que permite implementar las clases utilizadas en cada uno de los procesos que provee el servicio. La secuencia ordenada para la implementación del WPS requiere la implementación de la clase java que recibe los parámetros de entrada y realiza los cálculos correspondientes a un proceso específico para devolver los parámetros correspondientes a los resultados. Como segundo paso se debe implementar el proceso que consiste en la configuración de un archivo XML donde se especifican el identificador del proceso y el nombre y el tipo de entradas y salidas del proceso. El tercer y último paso consiste en la configuración del WPS. En esta forma Deegree provee de uno o varios procesos a la vez como se muestra en la Figura

32 Figura 24. Procesos y Clases en un WPS. El proceso que se implementa en este caso específico consiste en la obtención de un buffer como parámetro de salida a partir de las coordenadas de un punto y la distancia a la que se realiza el buffer como parámetros de entrada. Para esto se ha implementado la clase java del anexo que permite obtener el buffer a partir de los parámetros de entrada. Una vez que la clase se encuentra implementada se procede la configuración del proceso que invoca e la clase correspondiente. Figura 25. Identificador y Clase Java en la configuración de un proceso en Deegree. La Figura 25 muestra un fragmento del archivo de configuración XML que se describe en el anexo 6.5.2, donde se especifica el identificador del proceso Buffer y la especificación de la clase java wpsclass.org.deegree.wps.bufferprocesslet que realiza las operaciones del proceso Aplicación Web Los servicios OGC (WFS y WPS) que se han implementado pueden ser utilizados por usuarios expertos que conocen los procedimientos y detalles técnicos para acceder a estos servicios, por esta razón es necesario proveer al público en general que utiliza información catastral de una herramienta que permita interactuar con los servicios de acceso a datos de forma transparente. Con la finalidad de permitir el acceso a datos se ha desarrollado una aplicación web geoespacial en la cual se pueden realizar consultas y tareas de geoprocesamiento. A nivel de IDEs no existen muchos servicios que soporten la implementación conjunta de procesos de negocio geoespaciales y una interface gráfica de usuario (GUI) dirigida al público en general (Granell et al., 2010). La aplicación web tiene como objetivo ser útil para el público en general, mientras que los servicios son accesos a la funcionalidad geoespacial que pueden ser reutilizados por los usuarios profesionales (Bejar et al., 2012). Las funcionalidades de la aplicación han sido propuestas a partir de la disponibilidad de datos catastrales existentes, y están dirigidas a realizar consultas sobre los datos de las parcelas catastrales, los inmuebles y las direcciones de los inmuebles. La interface principal de la aplicación dispone de un visualizador geográfico y un formulario para realizar las consultas como se muestra en Figura 26. Algunas de las prestaciones de la aplicación son: Búsqueda de una parcela a partir de una referencia catastral. Búsqueda de las direcciones que se encuentran en una referencia catastral. Búsqueda de un inmueble a partir de la referencia catastral del inmueble. Búsqueda de los edificios que están dentro de una parcela. Estadísticas de las parcelas en función de un buffer a una distancia específica. 31

33 Figura 26. Interface Gráfica de Usuario de la aplicación web. Figura 27. Arquitectura de la Aplicación. La aplicación que se ha desarrollado está estructurada sobre una arquitectura multinivel la cual está formada por varios componentes como servicios interoperables y el servidor de bases de datos. En la Figura 27 se pueden identificar el nivel de presentación de la aplicación que permite acceder al usuario utilizando una GUI que dispone de un visualizador geográfico y un panel de consultas. El segundo nivel se corresponde a los servicios web (WPS, WFS y WMS) que son invocados desde el 32

34 nivel de presentación para la visualización de mapas y la ejecución de las distintas funcionalidades que ofrece la aplicación. Y el tercer nivel de se corresponde al componente del servidor de base de datos que resuelve las solicitudes de datos enviadas desde el Web Feature Service. La aplicación puede establecer dos flujos de datos que permite al usuario obtener un resultado específico: Si el usuario utiliza una funcionalidad de búsqueda específica, como puede ser la búsqueda de una parcela catastral o un inmueble, la aplicación invoca directamente al servicio de features el cual se encarga de extraer la información requerida desde la base de datos. Si el usuario utiliza la funcionalidad de realizar una estadística realizando un buffer a una distancia específica, la aplicación invoca el servicio de procesamiento para luego invocar al servicio de features, el cual obtiene información a partir de los resultados del servicio WPS. En la Figura 28 se muestra un diagrama del proceso para el cálculo de estadísticas sobre la capa de Parcelas Catastrales a partir de un buffer a una distancia específica. En el diagrama se pueden identificar las entradas y salidas que intervienen en las operaciones, donde el proceso inicia con la selección de la parcela en la interfaz de la aplicación web, después utiliza el servicio de procesamiento para calcular el buffer a partir del centroide la parcela seleccionada y un radio específico. El buffer resultante sirve como entrada del servicio de features que obtiene las parcelas que se encuentran dentro del buffer calculado. Los resultados del WFS son procesados por la lógica de proceso de la aplicación para obtener las estadísticas, y finalmente los resultados son mostrados hacia la interfaz de usuario. Algunos de los cálculos que se realizan son: Área promedio de las parcelas dentro del buffer. Altura máxima y mínima de los edificios existentes dentro del buffer. Número de Inmuebles existentes dentro del buffer. Uso de los inmuebles dentro del buffer. Disponer de una aplicación web con funcionalidades de consulta y geoprocesamiento permite potencializar el valor y la utilización de los datos catastrales. Además permite al usuario contar con una herramienta que le permita conocer mejor su entorno geográfico. 33

35 Figura 28. Proceso de cálculo de estadísticas de una parcela a partir de un Buffer. 34

36 3. CONCLUSIONES La implementación de una aplicación que permita el acceso unificado a de distintas fuentes de datos catastrales de forma homogénea y estandarizada ha permitido evaluar la accesibilidad a los datos y el estado de las infraestructuras tecnológicas para la gestión del catastro de las que disponen los países miembros del CPCI. La disponibilidad de datos catastrales de España marca una diferencia significativa frente a los demás países miembros del CPCI. Países como Argentina, Colombia, Chile México, Ecuador, El Salvador, Portugal, Perú, Puerto Rico y Uruguay permiten el acceso gratuito a la visualización de datos catastrales por medio de visualizadores geográficos o formularios web de consulta. En este conjunto de países se evidencia la madurez de sistemas de gestión catastral como los existentes en Colombia, Argentina, México y Uruguay. La evolución de los sistemas de gestión catastral, viene impulsada por las iniciativas nacionales de cada país, que buscan generar información geográfica para la gestión del territorio y el desarrollo de Infraestructuras de Datos Espaciales. Los modelos de datos estandarizados como aquellos propuestos por la iniciativa europea INSPIRE, son una base verificada sobre la cual se tiene una referencia para la unificación de datos catastrales de diferentes fuentes. La existencia de metadatos sobre los datos catastrales disponibles para descarga facilita el entendimiento de la estructuración de la información para generar modelos relacionales de datos que permitan asignar correspondencias hacia un modelo único. La utilización de herramientas ETL permite automatizar las tareas de análisis y carga de datos de una fuente específica, hacia un repositorio de datos común. De esta forma, un modelo ETL diseñado para una fuente de datos específica es reutilizable para datos que provengan de esa misma fuente. En cambio si es necesario cargar datos al repositorio común desde una fuente diferente, esto demandará la implementación de un nuevo modelo ETL. La implementación de los servicios OGC (WFS y WPS), que permiten el acceso a datos de una forma homogénea y estandarizada, garantizan la interoperabilidad y disponibilidad de la información ya sea como componentes que pueden ser utilizados en una aplicación destinada al público en general o como servicios utilizados por usuarios especializados. Disponer de una aplicación web con funcionalidades de consulta y geoprocesamiento sobre información geográfica de catastro obtenida de diferentes fuentes permite comparar de mejor forma las realidades de los sistemas de gestión catastral de los diferentes países. Además las funcionalidades de un sistema de información geográfica sobre la web permiten potencializar el valor y la importancia de los datos de catastro para la toma de decisiones en el proceso de planificación sobre un territorio. El desarrollo de las tecnologías de la información geográfica basadas en la utilización de software libre y estándares abiertos es una alternativa viable para la implantación de infraestructuras tecnológicas compatibles e interoperables para aquellos países en vías de desarrollo. Como trabajo futuro se pretende avanzar con la automatización de carga de datos hacia los demás modelos de INSPIRE que complementan los datos catastrales. Esto permite generar una infraestructura de datos cada vez más integrada. Sobre la aplicación web se pueden generar nuevas funcionalidades de consulta y geoprocesamiento ya sea sobre los datos de catastro o demás datos correspondientes a otros modelos de INSPIRE. El desarrollo de complementos sobre la aplicación web para generar cartografía automática sobre internet es una alternativa que permite potencializar la utilización y consumo de información catastral. 35

37 4. REFERENCIAS Beaujardiere, J. (2006): OpenGIS Web Map Server Implementation Specification, v1.3.0, OGC Open Geospatial Consortium Inc. Bejar, R.; Latre, M.; Lopez-Pellicer, F.; Nogueras-Iso, J.; Zaragoza-Soria, F.; Muro-Medrano, P. (2012): SDI-based business process: A territorial analysis web information system in Spain. Computers & Geosciences Journal, Vol. 46, pp Bernardi, D.; Calvanese, D.; De Giacomo, G. (2005): Reasoning on UML class diagrams. Artificial Intelligence Journal, Vol. 168, pp Bray, T.; Paoli, J.; Sperberg-McQueen, C.; Maler, E.; Yergeau, F. (2008): Extensible Markup Language (XML) 1.0 (Fifth Edition), Disponible en /. Cagnacci, F.; Urbano, F. (2008): Managing wildlife: A spatial information system for GPS collars data. Environmental Modelling & Software Jorurnal, Vol. 23, pp Cox, S.; Cuthbert, A.; Lake, R.; Martell, R.; (2002): OpenGIS Geography Markup Language (GML) Implementation Specification, Version 2.1.2, OpenGIS project document OGC 02-69, Open GIS Consortium Inc. Disponible en CPCI. (2009): DATA CATASTRO 2009, disponible en CPCI. (2011): DATA CATASTRO 2011, disponible en Date, C.J. (2000): An introduction to database systems, Addison Wesley Longman, Inc., United States of America, 936 pp. El-Sappagh, S.; Hendawi, A.; El Bastawesy, A. (2011): A proposed model for data warehouse ETL processes. Computer and Information Sciences Journal of King Saud University, Vol. 23, pp Erba, D.A. (2008): El Catastro Territorial en América Latina y el Caribe. Cambridge, Lincoln Institute of Land Policy. 427 pp. Granell, C.; Diaz, L.; Gould, M. (2010): Service-oriented applications for environmental models: Reusable geospatial services, Environmental Modelling & Software Journal, Vol. 25, pp Granell, C.; Diaz, L.; Gould, M. (2007): Managing eart observation data with distributed geoprocessing services, Proccedings of the International Geoscience and Remote Sensing Symposium, pp INSPIRE Thematic Working Group Addresses. (2010): Data Specification on Addresses Guidelines, D2.8.I.5, disponible en INSPIRE Thematic Working Group Building. (2011): Data Specification on Building Draft Guidelines, D2.8.III.2, disponible en INSPIRE Thematic Working Group Cadastral Parcels. (2010): Data Specification on Cadastral Parcels Guidelines, D2.8.I.6, disponible en Li, X.; Di, L.; Han, W.; Zhao, P.; Dadi, U. (2010): Sharing geoscience algorithms in a Web serviceoriented environment (GRASS GIS example). Computers & Geosciences Journal, Vol. 36 pp Michaels, C.; Ames, D. (2009): Evaluation and Implementation of the OGC Web Processing Service for Use in Client-Side GIS. Geoinformatica Journal, Vol. 13, pp Moreno-Sanchez, R.; Anderson, G.; Cruz, J.; Hayden, M. (2007): The potential for the use of open source software and open specifications in creating web-based cross-border health spatial information services. Geographic Information Science Journal, Vol. 21, num 10, pp Rafoss, T.; Sælid, K.; Sletten, A.; Fredrik Gyland, L.; Engravslia, L. (2010): Open geospatial technology standards and their potential in plant pest risk management GPS-enabled mobile phones utilising open geospatial technology standards Web Feature Service Transactions support 36

38 the fighting of fire blight in Norway. Computers and Electronics in Agriculture Journal, Vol. 74, pp Rajabifard, A.; Williamson, I.; Steudler, D.; Binns, A.; King, M. (2007): Assessing the worldwide comparison of cadastral systems. Land Use Policy Journal, Vol 24, pp Rumbaugh, J.; Jacobson, I.; Booch, G. (1999): The Unified Modeling Language User Guide, Addison Wesley Longman, Inc., United States of America, 568 pp. Schut, P. (2007): OpenGIS Web Processing Service, OpenGIS project document OGC r7, Open Geospatial Consortium Inc. Disponible en Sede Electrónica del Catastro. (2011): Cartografía Catastral en Formato Shapefile, disponible en Ting, L.; Williamson, I. (1999): Land Administration and Cadastral Trends: the impact of the changing humankind-land relationship and global drivers. Proceedings of the joint United Nations and FIG International Conference on Land Tenure and Cadastral Infrastructures for Sustainable Development, Conferencia, de Octubre, 1999, Melbourne. Vretanos, P. (2002): Web Feature Server Implementation Specification. Version , OpenGIS project document OGC , Open Geospatial Consortium Inc. Disponible en Vretanos, P. (2005): OpenGIS Filter Encoding Implementation Specification, OpenGIS project document OGC , Open Geospatial Consortium Inc. Disponible en Williamson, I.; Ting, L. (2001): Land Administration and cadastral trends a framework for reengineering. Computers, Environment and Urban Systems Journal, Vol. 25, pp Yang, C.; Raskin, R.; Goodchild, M.; Gahegan, M. (2010): Geospatial Cyberinfrastructure: Past, present and future. Computers, Environment and Urban Systems Journal, Vol. 34, pp

39 5. ACRÓNIMOS Tabla 13. Acrónimos. CNR CONAGE CPCI DGC DNC DSA ETL GEOIDEP GIS GML GUI I3A IAAA ICDE IDE IDECA IDEE IDESC IEDG IGAC IGP INEGI INSPIRE ISO JDBC OGC OVC OWS SOA SOAP SRT SQL UML URL W3C WCS WFS WMS WPS WSDL XML Centro Nacional de Registros del Salvador Consejo Nacional de Geoinformática Comité Permanente sobre el Catastro en Iberoamérica Dirección General de Catastro de España Dirección Nacional del Catastro del Uruguay Data Staging Area Extract, Transform and Load Portal de Datos Espaciales de Perú Geographic Information System Geography Markup Language Graphic User Interface Instituto de Investigación en Ingeniería de Aragón Grupo de Sistemas de Información Avanzados Infraestructura Colombiana de Datos Espaciales Infraestructura de Datos Espaciales Infraestructura de Datos Espaciales para el Distrito Capital Infraestructura de Datos Espaciales de España Infraestructura de Datos Espaciales de Santiago de Cali Infraestructura Ecuatoriana de Datos Geoespaciales Instituto Geográfico Agustín Codazzi Instituto Geográfico Portugués Instituto Nacional de Estadística y Geografía Infrastructure for Spatial Information in Europe International Organization for Standardization Java Database Connectivity Open Geospatial Consortium Oficina Virtual del Catastro OGC Web Services Service-Oriented Architecture Simple Object Access Protocol Sistema de Riqueza Territorial de Navarra Structured Query Language Unified Modeling Language Uniform Resource Locator World Wide Web Consortium Web Coverage Service Web Feature Service Web Map Service Web Processing Service Web Services Description Language extensible Markup Language 38

40 6. ANEXOS 6.1. Fuentes de Datos Catastrales Agentes Catastrales en Iberoamérica En la Tabla 14 se hace un listado de los agentes catastrales existentes en los países miembros del CPCI. Cada país tiene una participación más relevante frente a otros países, dependiendo de la disponibilidad de información y tecnificación del catastro. Algunos países miembros del CPCI no participan de forma activa en el comité, esto se muestra en la columna Participación CPCI. Tabla 14. Agentes Catastrales de los países miembros del CPCI. País Agentes Catastrales Participación CPCI Dirección Provincial de Catastro Territorial de Buenos Aires Si Dirección General de Catastro e Información Territorial de Chubut Si Dirección General de Catastro de Córdoba Si Dirección General de Catastro de La Pampa Si Argentina Dirección general de catastro e información territorial de Río Negro Si Servicio de catastro e información Territorial de Santa Fe Si Administración General de Catastro de Catamarca Si Dirección Provincial de Catastro y Tierras Fiscales de San Luis: Si Formosa: Dirección General del Catastro Territorial Si Departamento Administrativo de Planeación - Antioquia Si Instituto Geográfico Agustín Codazzi Si Colombia Subdirección de Catastro Municipal de Santiago de Cali Si Unidad Administrativa Especial de Catastro Distrital Si Subsecretaría de Catastro de Medellín Si El Salvador Instituto Geográfico y del Catastro Nacional, Centro Si Nacional de Registros España Dirección General del Catastro Si México Instituto de Catastro de Puebla Si Instituto Mexicano de Catastro Si Perú Organismo de Formalización de la Propiedad Informal Si Instituto Catastral de Lima Si Portugal Instituto Geográfico Portugués Si Dirección Nacional de Catastro Uruguay Servicio de Catastro y Avalúos de la Intendencia Si Municipal de Montevideo Jefatura Municipal de Campiñas, Secretaria Si Brasil Municipal de Planeamiento Catastro Nacional de Inmuebles Rurales No Bolivia Sistema Integrado de saneamiento y titulación No Costa Rica Sistema de información de registro inmobiliario No Chile División del Catastro Nacional de los Bienes del Estado Si Ecuador Dirección Metropolitana de Catastro del Municipio de Quito Si Ministerio de Agricultura, Ganadería y Pesca (SIGTIERRAS) No Guatemala Registro de Información Catastral No Dirección General de Catastro y Geografía. No Honduras Catastro Rural del Instituto Nacional Agrario. No Sistema Nacional de Administración de la Propiedad. No Nicaragua Dirección General de Ingresos, División de Catastro Si Fiscal Puerto Rico Centro de Recaudación de Ingresos Municipales No 39

41 País Agentes Catastrales Participación CPCI Paraguay Servicio Nacional de Catastro No Panamá Autoridad Nacional de administración de tierras No República Dirección General del Catastro Nacional No Dominicana Venezuela Dirección de Planificación Urbana y Catastro Si Instituto Geográfico de Venezuela Simón Bolívar No Tabla 15. Acceso a datos Geográficos Catastrales. País Argentina Colombia España México Perú Portugal Uruguay Ecuador Acceso a datos Geográficos https://sitdgc.cba.gov.ar https://www.sedecatastro.gob.es/ovcframes.aspx?tipo=tit&a=masiv Servicio de mapas de catastro de la Descripción de los datos descargados de la Oficina Virtual del Catastro Las descripciones que se realizan en este apartado corresponden a información obtenida de la OVC (Sede Electrónica del Catastro, 2011) de la cual se ha deducido el modelo relacional que se muestra en la Figura 29. A partir de la Tabla 16 se hace una descripción de archivos descargados y sus correspondientes atributos. 40

42 Figura 29. Modelo Relacional de base de datos de la OVC. MAPA: Identificación de cada una de las zonas con cartografía diferente. Normalmente en cada municipio hay un mapa de urbana y otro mapa de rústica. Dentro de un mismo mapa hay coherencia cartográfica pero entre mapas puede haber pequeñas inconsistencias. Tabla 16. Campos de la tabla MAPA NOMBRE CAMPO NINTERNO MAPA TIPO DELEGACIO MUNICIPIO PROYE TIPOMALLA ESTADO DESCRIP HAX HBX HCX HAY HBY HCY FECHAALTA FECHABAJA FECHAPUB COMENTA THE_GEOM DESCRIPCIÓN Numero secuencial asignado por el sistema Identificativo del mapa (número secuencial) (U)rbana o (R)ústica Código de la Delegación de Hacienda Municipio al que corresponde el mapa Código del sistema de proyección delmapa. Tipo de referencia de HOJA al generar nuevas manzanas. Estado del mapa (para saber si hay una carga masiva, etc en curso) Descripción del mapa Coeficiente AX transformación X =AX.X + BX.Y + CX Coeficiente BX transformación Coeficiente CX transformación Coeficiente AY transformación Y = AY.X + BY.Y + CY 10 Coeficiente BY transformación Coeficiente CY transformación Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico Fecha de la cartografía oficial. Comentarios sobre el mapa, de uso interno de la Gerencia del Catastro. Geometría poligonal del mapa 41

43 HOJAS: Hojas de división de la cartografía urbana. Tabla 17. Atributos de la tabla HOJAS NOMBRE CAMPO DESCRIPCIÓN NINTERNO Numero secuencial asignado por el sistema MAPA Número del mapa al que pertenece la Manzana o polígono DELEGACIO Código de la Delegación de Hacienda MUNICIPIO Municipio al que corresponde el mapa MASA Código de manzana urbana (5 caracteres) o de polígono rústico (3 caracteres) HOJA Posiciones 8 a 14 de la referencia catastral (urbana) o código de sector (rústica) TIPO Tipo de parcelas que admite. Puede ser R o U AREA Superficie del elemento en metros cuadrados FECHAALTA Fecha de dibujo del elemento gráfico FECHABAJA Fecha de borrado del elemento gráfico COORX Coordenada Y del centroide de la manzana COORY Coordenada Y del centroide de la manzana THE_GEOM Geometría poligonal de la masa MASA: Agrupaciones de parcelas (manzanas de urbana y polígonos de rústica) Tabla 18. Atributos de la tabla MASA NOMBRE CAMPO NINTERNO MAPA TIPO AREA FECHAALTA FECHABAJA THE_GEOM DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tipo de parcelas que admite. Puede ser R o U Superficie del elemento en metros cuadrados Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico Geometría poligonal de la Hoja. PARCELA. Parcelas catastrales. Las parcelas que tienen el campo. PARCELA = no existen en realidad y son un artificio necesario dentro del sistema de información geográfica catastral para conseguir la continuidad de la cartografía rústica. Tabla 19. Atributos de la tabla PARCELA NOMBRE CAMPO NINTERNO MAPA DELEGACIO MUNICIPIO MASA HOJA TIPO PARCELA REFCAT VÍA DESCRIPCIÓN Numero secuencial asignado por el sistema Número del mapa al que pertenece la parcela Código de la Delegación de Hacienda Municipio al que corresponde el mapa Referencia de la manzana/polígono a la que pertenece la parcela Posiciones 8 a 14 de la referencia catastral (urbana) o código de sector (rústica) Tipo de PARCELA a la que pertenece la subparcela: (R)ústica, (X)Dominio público o ajuste topográfico, excepcionalmente (U)rbana Número de parcela dentro de la manzana o polígono Referencia catastral de la parcela Código de vía pública (calle o Plaza). 42

44 NOMBRE CAMPO NUMERO FECHAALTA FECHABAJA COORX COORY AREA THE_GEOM DESCRIPCIÓN Número de portal. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico Coordenada Y del centroide de la manzana Coordenada Y del centroide de la manzana Superficie del elemento en metros cuadrados Geometría poligonal de la Parcela SUBPARCE. Subparcelas de cultivo (zonas de igual cultivo o aprovechamiento dentro de una parcela). Las que tienen el campo PARCELA= deben ser ignoradas. Tabla 20. Atributos de la tabla SUBPARCE NOMBRE CAMPO NINTERNO MAPA DELEGACIO MUNICIPIO MASA HOJA TIPO PARCELA REFCAT SUBPARCE FECHAALTA FECHABAJA COORX COORY AREA THE_GEOM DESCRIPCIÓN Numero secuencial asignado por el sistema Número del mapa al que pertenece la subparcela Código de la Delegación de Hacienda Municipio al que corresponde el mapa Referencia de la manzana/polígono a la que pertenece la subparcela Posiciones 8 a 14 de la referencia catastral (urbana) o código de sector (rústica) Tipo de PARCELA a la que pertenece la subparcela: (R)ústica, (X)Dominio público o ajuste topográfico, excepcionalmente (U)rbana Referencia de parcela a la que pertenece la subparcela. Referencia catastral de la parcela Clave de subparcela rustica Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico Coordenada Y del centroide de la manzana Coordenada Y del centroide de la manzana Superficie del elemento en metros cuadrados Geometría poligonal de la subparcela Tabla CONSTRU. Subparcelas urbanas que representan los volúmenes edificados dentro de una parcela. Tabla 21. Atributos de la tabla CONSTRU NOMBRE CAMPO DESCRIPCIÓN NINTERNO Numero secuencial asignado por el sistema MAPA Número del mapa al que pertenece la subparcela DELEGACIO Código de la Delegación de Hacienda MUNICIPIO Municipio al que corresponde el mapa MASA Referencia de la manzana/polígono a la que pertenece la subparcela HOJA Posiciones 8 a 14 de la referencia catastral (urbana) o código de sector (rústica) TIPO Tipo de parcela (U, D, R) PARCELA Referencia de parcela a la que pertenece la subparcela. REFCAT Referencia catastral de la parcela CONSTRU Rótulo con las alturas construidas. Ta FECHAALTA Fecha de dibujo del elemento gráfico FECHABAJA Fecha de borrado del elemento gráfico COORX Coordenada Y del centroide de la manzana 43

45 NOMBRE CAMPO COORY AREA THE_GEOM DESCRIPCIÓN Coordenada Y del centroide de la manzana Superficie del elemento en metros cuadrados Geometría poligonal de la subparcela ALTIPUN: Puntos de altimetría con cota y puntos de las redes geodésicas y topográficas. Tabla 22. Atributos de la tabla ALTIPUN NOMBRE CAMPO NINTERNO MAPA TTGGSS COTA NUMSYMBOL FECHAALTA FECHABAJA DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tema, grupo y subgrupo, según anexo de codificación de la información geográfica Cota del punto en metros sobre el nivel del mar. Campo calculado, con el numero del símbolo con el que hay que representar el elemento. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico EJES. Ejes de elementos lineales (calles, carreteras) Tabla 23. Atributos de la tabla EJES NOMBRE CAMPO NINTERNO MAPA TTGGSS VÍA NUMSYMBOL FECHAALTA FECHABAJA DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tema, grupo y subgrupo, según anexo de codificación de la información geográfica Código de la entidad lineal (parte 2). Para descripción ver CARVÍA. Campo calculado, con el numero del símbolo con el que hay que representar el elemento. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico ELEMLIN. Elementos cartográficos lineales Tabla 24. Atributos de la tabla ELEMLIN NOMBRE CAMPO NINTERNO MAPA TTGGSS VÍA NUMSYMBOL FECHAALTA FECHABAJA DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tema, grupo y subgrupo, según anexo de codificación de la información geográfica Código de la entidad lineal (parte 2). Para descripción ver CARVÍA. Campo calculado, con el número del símbolo con el que hay que representar el elemento. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico 44

46 ELEMPUN. Elementos cartográficos puntuales Tabla 25. Atributos de la tabla ELEMPUN NOMBRE CAMPO NINTERNO MAPA TTGGSS VÍA NUMSYMBOL FECHAALTA FECHABAJA DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tema, grupo y subgrupo, según anexo de codificación de la información geográfica Código de la entidad lineal (parte 2). Para descripción ver CARVÍA. Campo calculado, con el numero del símbolo con el que hay que representar el elemento. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico ELEMTEX. Rótulos del mapa Tabla 26. Atributos de la tabla ELEMTEX NOMBRE CAMPO NINTERNO MAPA TTGGSS ROTULO NUMSYMBOL FECHAALTA FECHABAJA DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tema, grupo y subgrupo, según anexo de codificación de la información geográfica Texto a colocar en el mapa. Campo calculado, con el numero del símbolo con el que hay que representar el elemento. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico LIMITES. Límites administrativos (de municipio, de suelo de naturaleza urbana, etc) Tabla 27. Atributos de la tabla LIMITES NOMBRE CAMPO NINTERNO MAPA TTGGSS NUMSYMBOL FECHAALTA FECHABAJA DESCRIPCIÓN Numero secuencial asignado por el sistema Mapa en el que esta dibujado el elemento gráfico Tema, grupo y subgrupo, según anexo de codificación de la información geográfica Campo calculado, con el numero del símbolo con el que hay que representar el elemento. Fecha de dibujo del elemento gráfico Fecha de borrado del elemento gráfico Atributos de las construcciones, correspondientes a el campo CONSTRU de la tabla CONSTRU. Tabla 28. Descripción del atributo constru de la tabla constru ATRITUTO CONSTRUCCION -I, -II Volúmenes bajo rasante (1, 2 alturas) I, II Volúmenes sobre rasante (1, 2 alturas) B Balcón T Tribuna (balcón techado) TZA Terraza 45

47 ATRITUTO POR SOP PJE MAR P CO EPT SS ALT PI TEN ETQ SILO SUELO PRG DEP ESC TRF JD YJD FUT VOL ZD RUINA CONS PRESA ZBE ZPAV GOLF CAMPING TERRENY HORREO PTLAN ZPAV DARSENA CONSTRUCCION Porche Soportal Pasaje Marquesina Patio Cobertizo Entreplanta Semisótano Altillo Piscina Pista de Tenis Estanque Silo Suelo vacante, sin construir. También se puede utilizar el sinónimo Pérgola Depósito Escalera Transformador Jardín Jardín que se valora Campo de Fútbol Voladizo Zona Deportiva Ruinas En construcción Cuerpo de presa en embalses Balsas y estanques que se valoran Obras de urbanización interior Campo de GOLF Camping Sinónimo de SUELO Hórreo, panera, cabazo. Pantalán (embarcadero de pequeño porte, soportado por pilotes y a veces móvil). Se utilizará este código particularmente para los puntos de amarre de puertos deportivos. Un muelle se codificará con el código genérico Dársena, aguas resguardadas artificialmente por un puerto Descripción de los datos descargados del Sistema de la Riqueza Territorial de Navarra La información descrita en este apartado ha sido obtenida en el documento Texto explicativo de datos alfanuméricos que se descarga junto a los datos. Los datos se proporcionan en varias tablas ASCII relacionadas con las siguientes variables: Tabla 29. Atributos de la tabla Parcelas Campos Longitud [Código Municipio] 3 [Código Población] 4 46

48 [Polígono] 2 [Parcela] 4 [Código Paraje] 4 [Centroide X] 7v3 [Centroide Y] 7v3 [Referencia Plano] 10 [Zona Valorativa] 3 A efectos de la valoración del suelo por el método residual, las Ponencias de Valoración de cada municipio delimitan zonas valorativas, también llamadas polígonos fiscales. En las parcelas que no tienen asignado polígono fiscal, esta variable aparece con un cero. El código de paraje se atribuye únicamente a parcelas que no tienen dirección postal. Tabla 30. Atributos de la tabla Parajes Campos Longitud [Código Municipio] 3 [Código Paraje] 4 [Nombre Paraje] 40 Tabla 31. Atributos de la tabla Subáreas Campos Longitud [Código Municipio] 3 [Código Población] 4 [Polígono] 2 [Parcela] 4 [Subarea] 2 [Código Vía] 4 [Número Postal] 3 [Extensión Número Postal] 3 [Superficie] 10 v2 [Superficie Ocupada] 10v2 [Superficie Consolidada] 10v2 [Nombre de la Casa] 35 [Número Ascensores] 2 Se denomina subarea a un código que agrupa a una o varias unidades urbanas, formando parte del identificador de éstas. A ella se asignan la dirección, hasta número de portal, el nombre de la casa en caso de que esté recogida, el número de ascensores del edificio y la consolidación a efectos de valoración de las unidades urbanas por repercusión. Tabla 32. Atributos de la tabla Vías Campos Longitud [Código Municipio] 3 [Código Población] 4 [Código Vía] 4 [Tipo Vía] 2 [Nombre Vía] 40 [Nombre Vía Completo ]

49 Tabla 33. Atributos de la tabla Unidades Urbanas Campos Longitud [Código Municipio] 3 [Código Población] 4 [Polígono] 2 [Parcela] 4 [Subarea] 2 [Unidad Urbana] 4 [Escalera] 1 [Planta] 2 [Puerta] 10 [Tipo Constructivo] 4 [Categoría Construcción] 1 [Superficie Privativa] 10v2 [Superficie Cerrada] 10v2 [Superficie Abierta] 10v2 [Superficie Comunes] 10v2 [Año de Construcción] 4 [Grado de reforma] 1 [Año de Reforma] 4 [Código Destino] 2 [Conservación (%)] 3 [Vivienda Interior] 1 [ConsumoEdificabilidad] 1 Tabla 34. Atributos de la tabla Municipios Campos Longitud [Código Municipio] 3 [Nombre Municipio castellano] 40 [Nombre Municipio euskera] 40 Tabla 35. Atributos de la tabla Polígono Campos Longitud [Código Municipio] 3 [Código Polígono] 4 [Municipio] 40 Tabla 36. Atributos de la tabla Cultivos Campos Longitud [Código Cultivo] 4 [Descripción Cultivo] 25 Tabla 37. Atributos de la tabla Tipos Tierra Campos Longitud [Código Tipo Tierra] 1 [Descripción Tipo Tierra] 25 Las unidades urbanas pueden ser elementos constructivos o porciones de suelo no afectado por construcción. 48

50 Los elementos constructivos son partes de una construcción que se diferencian por sus características, especialmente por aquéllas que influyen sobre la valoración por el método aditivo. Tienen asignada la componente vertical de su dirección postal (no atribuido a la subárea) y su superficie construida, así como el resto de datos que influyen sobre su valoración. La superficie construida privativa se desglosa en superficie cerrada y abierta solamente en unidades de nueva construcción o reformadas recientemente. La superficie de comunes atribuida a una unidad incluida en un edificio en régimen de división horizontal es la suma de las superficies construidas de todos los elementos comunes en que participa, multiplicada por el coeficiente de participación de la unidad en los elementos comunes. El grado de reforma puede ser total medio o de conservación y en caso de estar registrada más de una reforma, se incluye únicamente la última. El dato de consumo de edificabilidad puede tomar los valores: C (consume edificabilidad) o N (no consume edificabilidad) Descripción de los diagramas UML de los modelos de INSPIRE Los diagramas de clases UML propuestos por INSPIRE permiten modelar en una forma declarativa, la estructura estática de un dominio de aplicación, en términos de conceptos y relaciones entre las clases. Por ello debemos concentrarnos en los diagramas de clases UML con una perspectiva conceptual (Berardi et al., 2005). En particular no nos centramos en las características de las clases con una perspectiva de implementación como las propiedades tales como pública, protegida o privada que se establecen en las operaciones y los atributos. UML también contiene varias restricciones que intentan proveer una limitada pero muy potente capacidad de extensibilidad (Rumbaugh et al., 1999). Las clases en un diagrama UML se establecen por un conjunto de objetos con propiedades comunes. Una clase es representada gráficamente como un rectángulo dividido en tres partes tal como se muestra en la Figura 30. La primera parte es el nombre de la clase, el cual debe ser único en el diagrama de clases. La segunda parte contiene los atributos de la clase, cada uno con un nombre, una multiplicidad y un tipo de dato. La tercera parte contiene las operaciones de la clase. Figura 30. Representación gráfica de una clase. Una asociación en UML es una relación entre las instancias de dos o más clases. Los nombres de asociaciones son únicos en un diagrama de clases UML. Una asociación binaria RB entre dos clases C1 y C2 es gráficamente representada como se muestra en la Figura 31. Figura 31. Representación una asociación binaria en UML. 49

51 . La multiplicidad nt..nu sobre la asociación binaria especifica que cada instancia de la clase C1 puede participar en al menos n t veces y por mucho con n u veces en la relación RB. En mt..mu el significado es análogo para la clase C2. Cuando la multiplicidad es omitida, esto significa que es 0..*. Un tipo particular de asociación binaria son las agregaciones, las cuales desempeñan un rol importante en los diagramas de clases UML. Una agregación es una relación binaria entre las instancias de dos clases, definiendo una relación entre un todo y sus partes, i.e., una relación que especifica que cada instancia de una clase (clase contenedora) contiene un conjunto de instancias de otras clases (clase contenida). Una agregación se representa gráficamente como se muestra en la Figura 32, donde el diamante indica el todo. Figura 32. Representación una agregación. En UML se puede utilizar la generalización entre una clase padre y una clase hija para especificar que cada instancia de la clase hija es también una instancia de la clase padre. Por lo tanto, las instancias de la clase hija heredan las propiedades de la clase padre, pero por lo general estas poseen propiedades adicionales que en general la clase padre no puede mantener (Berardi et al., 2005). Muchas generalizaciones pueden ser agrupadas para formar clases jerárquicas como se muestra en la Figura 33. Figura 33. Jerarquía de clases en UML. Las especificaciones de INSPIRE definen estereotipos utilizados para definir los elementos que intervienen en un diagrama de clases UML, estos se definen en la tabla 3. Tabla 38. Estereotipos utilizados en los modelos de INSPIRE Estereotipo Descripción applicationschema Esquema de aplicación de INSPIRE de acuerdo a la ISO featuretype Es una clase del tipo objeto espacial datatype Es una clase del tipo de datos estructurado sin un identificador Type Es una clase de tipo abstracto que no es un objeto espacial Voidable Es una descripción hacia un atributo o una asociación, que lo describe como no obligatorio codeliste Es una clase de enumeración de valores tipo string para representar un dominio de posibles valores para un atributo Además de estos estereotipos se definen los atributos generales presentes en todos los objetos espaciales. 50

52 Tabla 39. Atributos generales para todos los objetos Atributo beginlifespanversion endlifespanversion validfrom validto Descripción Están relacionados al periodo de existencia del objeto especial dentro del data set especial, correspondiente al punto de vista geográfico. Están relacionados a la existentica de la entidad en el mundo real, que se corresponde al punto de vista legal Modelo de Parcelas Catastrales de INSPIRE En el contexto de INSPIRE, las parcelas catastrales pueden estar formando una porción del territorio nacional. La parcela catastral es considerada como una sola área de superficie (tierra y/o agua), en la ley nacional bajo los derechos de propiedad homogénea y única. Los objetos espaciales del modelo además de los atributos generales presentan un conjunto de atributos específicos. En la Figura 34 se muestra el diagrama de clases UML del modelo. Figura 34. Diagrama de clases UML del modelo de Parcelas Catastrales de INSPIRE. 51

53 Como podemos ver en el diagrama cada uno de los atributos de los objetos es de un tipo de datos específico como GM_Curve, DateTime, CharacterString, GM_Object etc. A continuación se describen los objetos espaciales del modelo de Parcelas Catastrales. La clase BasicPropertyUnit está definida como la unidad básica de propiedad que está registrada en los libros de registro de la propiedad o su equivalente. Esta puede consistir de un o más parcelas geográficamente adyacentes o separadas. Este objeto tiene los siguientes atributos. Tabla 40. Atributos de la clase BasicPropertyUnit Atributo Descripción OBLIGATORIO inspireid identificador externo del objeto espacial SI nationalcadastralrefer Es un identificador a nivel nacional, que permite acceder SI ence a los registros del catastro nacional o su equivalente. areavalue Área registrada en la cuantificación, es el área proyectada sobre el plano horizontal de las parcelas que componen la unidad básica de propiedad. validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, pudiendo ser cesada para ser modificada. administrativeunit Es el atributo de asociación hacia la unidad administrativa con el nivel jerárquico más bajo que contiene la unidad básica de la propiedad. La clase CadastralBoundary se define como una parte de los límites de la parcela catastral. Un límite catastral puede ser compartido por dos parcelas catastrales, y tiene los atributos que se describen en la Tabla 41. Tabla 41. Atributos de la clase CadastralBoundary Atributo Descripción OBLIGATORIO geometry Geometría del límite de la parcela (tipo línea) SI inspireid identificador externo del objeto espacial SI estimatedaccuracy Es la precisión absoluta de la posición estimada para el límite catastral en el sistema de coordenadas de referencia utilizado por INSPIRE validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, pudiendo ser cesada para ser modificada. parcel Es la parcela a la que limita. Un límite catastral pude limitar a una o dos parcelas catastrales. La clase CadastralParcel hace referencia a las parcelas catastrales están definidas por la directiva INSPIRE como areas definidas por registros catastrales o equivalentes y tienen los siguientes atributos específicos: Tabla 42. Atributos de la clase CadastralParcel Atributo Descripción OBLIGATORIO geometry Geometría de la parcela catastral SI inspireid Identificador externo del objeto espacial SI label Texto usado para representar la identificación de la SI parcela catastral nationalcadastralrefer ence Referencia catastral de la parcela SI 52

54 Atributo Descripción OBLIGATORIO areavalue Área registrada en la cuantificación, es el área proyectada sobre el plano horizontal de la parcela catastral. referencepoint Un punto contenido en la parcela catastral validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, pudiendo ser cesada para ser modificada. administrativeunit Es el atributo de asociación hacia la unidad administrativa con el nivel jerárquico más bajo en la que está contenida la parcela catastral. basicpropertyunit Es el atributo de asociación a la unidad básica de propiedad a la que pertenece la parcela catastral zoning Es el atributo de asociación a la zona catastral del nivel más bajo que contiene a la parcela catastral La clase CadastralZoning está definida como áreas intermedias ordenadas jerárquicamente para dividir el territorio nacional en parcelas catastrales. Tabla 43. Atributos de la clase CadastralZoning Atributo Descripción OBLIGATORIO geometry Geometría de la parcela catastral SI inspireid Identificador externo del objeto espacial SI label Texto usado para representar la identificación de la zona SI catastral nationalcadastralzoni Identificador a nivel nacional SI ngreference level Es el nivel de la zona catastral en la jerarquía del catastro nacional levelname Nombre de la zona catastral, en la jerarquía nacional del catastro. name Nombre de la zona catastral originalmapscaledeno El denominador de la escala en el mapa en papel original minator referencepoint Un punto contenido en la zona catastral validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, pudiendo ser cesada para ser modificada Modelo de Direcciones de INSPIRE La directiva INSPIRE define una dirección como la Localización de propiedades basadas en identificadores de dirección, usualmente por nombre de vía, número de casa, código postal. Para identificar la dirección sin ambigüedades en un amplio contexto una dirección debería estar asociada con un número de componentes de dirección que definen su localización dentro de cierta área geográfica. Cada componente de dirección representa un identificador espacial como por ejemplo el nombre de la vía, distrito, código postal, municipalidad, región o país. La Figura 35 muestra el diagrama de clases UML del modelo de direcciones, el cual está conformado por seis objetos espaciales y seis tipos de datos estructurados. 53

55 Figura 35. Diagrama de clases UML del modelo de Direcciones de INSPIRE A continuación se describen los objetos espaciales y los tipos de datos estructurados. 54

56 La clase Address es una identificación de una ubicación fija de una propiedad por medio de una composición estructurada de nombres geográficos e identificadores. El objeto espacial, referenciado por la dirección, está definido como el objeto direccionable. El objeto direccionable puede ser una parcela catastral o a un edificio a través de asociaciones. En muchas situaciones el objeto direccionado está presente en el mundo real. Sin embargo, las direcciones pueden también referenciar a objetos en planificación, bajo construcción o inclusive históricos. Una parte de la identificación de los objetos (e.g. edificios), las direcciones son a menudo utilizados por un gran número de otras aplicaciones para identificar tipos de objetos, como por ejemplo estadísticas sobre habitantes en los edificios, para impuestos de empresas que ocupan un edificio, y la utilización de las instalaciones. La posición geográfica de una dirección es representada por un punto que incluye información sobre sus orígenes. El punto basado en representación espacial ha sido adoptado por la simplicidad de la implementación de la especificación de datos y refleja la situación de los países. Tabla 44. Atributos de la clase Address Atributo Descripción OBLIGATORIO postion Hace referencia al tipo de dato estructurado SI GeographicPosition inspireid Identificador externo del objeto espacial SI locator Hace referencia al tipo de dato estructurado SI AddressLocator alternativeidentifier Identificador temático de la dirección del objeto SI espacial, el cual permite interoperabilidad con sistemas existentes o aplicaciones status Validez de la dirección validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, pudiendo ser cesada para ser modificada. parcel Es la parcela catastral a la que la dirección es asociada building Es el edificio al que la dirección es asociada. La clase AddressComponent es un elemento abstracto, es el identificador o nombre geográfico de un área geográfica específica, ubicación, u otro objeto espacial el cual define el alcance de una dirección. Se han definido cuatro subclases de componentes de dirección: nombre de área administrativa, nombre de área de dirección, nombre de vía pública y la descripción postal. Tabla 45. Atributos de la clase AddressComponent Atributo Descripción OBLIGATORIO inspireid Identificador externo del objeto espacial SI alternativeidentifier Identificador temático de la dirección del objeto espacial, el cual permite interoperabilidad con sistemas existentes o aplicaciones status Validez de la dirección validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, pudiendo ser cesada para ser modificada. Entre las subclases de componentes y AddressComponent existe un generalización donde cada componente hereda los atributos de AddressComponent. 55

57 La clase AdminUnitName Es un componente de dirección que representa el nombre de la unidad administrativa donde un país tiene o practica derechos jurisdiccionales para el gobierno local, regional o nacional. Tabla 46. Atributos de la clase AdminUnitName Atributo Descripción OBLIGATORIO name nombre geográfico oficial de la unidad administrativa SI level El nivel de la administración en la jerarquía administrativa nacional. La clase PostalDescriptor representa la identificación del código postal. Tabla 47. Atributos de la clase PostalDescriptor Atributo Descripción OBLIGATORIO postname Uno o más nombres creados y mantenidos para propósitos postales para identificar una subdivisión de direcciones y puntos de entrega postal. SI postcode Un código creado y mantenido para propósitos postales para identificar una subdivisión de direcciones y puntos de entrega postal La clase AddressAreaName representa una dirección de área que es una subdivisión real de un área administrativa, así pues cada dirección de área está totalmente dentro de la municipalidad, por ello cada parte de esa dirección de área esta dentro de la municipalidad. Tabla 48. Atributos de la clase AddressAreaName Atributo Descripción OBLIGATORIO name Nombre propio aplicado a la dirección de area SI La clase ThoroughfareName es un componente de dirección que representa el nombre de un pasaje o vía que va de un lugar a otro. Tabla 49. Atributos de la clase ThoroughfareName Atributo Descripción OBLIGATORIO name Hace referencia al tipo de dato estructurado SI ThoroughfareNameValue En algunos de los atributos tal y como se muestra en la figura 5 se utilizan tipos de datos estructurados. AddressLocator es un tipo de datos estructurado que representa una designación legible para las personas o nombre que permite al usuario o aplicación referenciar o distinguir la dirección de las direcciones vecinas, dentro del alcance de un nombre de vía, dirección de nombre del área, nombre de la unidad administrativa o designación postal en la cual la dirección está situada. Tabla 50. Atributos del tipo de dato estructurado AddressLocator Atributo Descripción OBLIGATORIO designator Del tipo de dato estructurado LocatorDesignator name Del tipo de dato estructurado LocatorName level El nivel al que se refiere el localizador, codelist SI LocatorLevelValue withinscopeof El componente de dirección que define el alcance dentro del cual el localizador de dirección es asignado 56

58 LocatorDesignator es el tipo de dato estructurado que se refiere a un número o secuencia de caracteres que identifican de forma única a un localizador dentro de un alcance. La identificación total de un identificador puede incluir uno o mas locator designators. Tabla 51. Atributos del tipo de dato estructurado LocatorDesignator Atributo Descripción OBLIGATORIO designator El texto que identifica a una parte del localizador que SI puede estar compuesto por uno o más dígitos o varios caracteres type Es el tipo del valor del designator, tiene como dominio de valores el codelist LocatorDesignatorTypeValue SI LocatorName es el tipo de dato estructurado que se refiere a un nombre que identifica al designator en el mundo real, puede ser un nombre de edificio, o una habitación dentro de un edificio. Tabla 52. Atributos del tipo de dato estructurado LocatorName Atributo Descripción OBLIGATORIO name El texto que identifica a una parte del localizador SI type Es el tipo del valor del nema, tiene como dominio de valores el codelist LocatorNameTypeValue ThoroughfareNameValue es el tipo de dato estructurado que permite descomponer una dirección en varias partes, este objeto tiene dos atributos. Tabla 53. Atributos del tipo de dato estructurado ThoroughfareNameValue Atributo Descripción OBLIGATORIO name Es un nombre propio aplicado a la vía SI nameparts Es una o varias partes en las que el nombre de la vía puede ser subdividido por medio del tipo de datos estructurado PartOfName Y en cuanto al tipo de datos estructurado PartOfName! se encarga de subdividir el nombre de una vía, en el nombre del elemento y el tipo de elemento. Tabla 54. Atributos del tipo de dato estructurado PartOfName Atributo Descripción OBLIGATORIO part Es una cadena de caracteres que expresa una parte SI separada del nombre de la vía type Es el tipo de la parte de la vía, debe ser asignada desde el codeliste PartTypeValue En el anexom se presentan el conjunto de Code Lists utilizados en el modelo de direcciones Modelo de Edificios de INSPIRE Este modelo se basa en el modelo de aplicación Building Core 2D, que incluye cuatro objetos: building, building part, other construction y building unit. Los edificios son estructuras cerradas, sobre y/o bajo la superficie terrestre y son utilizados para resguardar personas, animales, cosas o la producción de bienes económicos y que refieren a cualquier estructura construida o levantada permanentemente sobre su sitio. Un edificio puede estar compuesto de varias partes. Una parte de un edificio es una subdivisión de un edificio que es homogéneo respecto a sus características físicas, funcionales o temporales. El modelo de Edificios de INSPIRE es muy flexible debido a que la geometría de los edificios puede ser representada de diferentes formas, como puntos o polígonos. En la descripción de cada uno 57

59 de los objetos se describen los atributos que permite caracterizar los edificios. En la Figura 36 se muestra el modelo. Figura 36. Diagrama de clases UML del modelo de Direcciones de INSPIRE En el modelo se verifica las asociaciones con los modelos de parcelas catastrales y direcciones, que se relacionan a partir de la clase abstracta más general AbstractConstruction. La clase AbstractConstruction que agrupa propiedades comunes de objetos que pueden ser edificios, partes de edificios y otras construcciones. Tabla 55. Atributos de la clase AbstractConstruction Atributo Descripción OBLIGATORIO inspireid Identificador externo del objeto espacial SI validfrom Fecha y hora oficial en que la parcela fue creada. validto Fecha y hora oficial en que la parcela fue cesada, 58

60 conditionofconstructi on dateofconstruction dateofdemolition dateofrenovation elevation externalreference heightaboveground name addresses cadastralparcels pudiendo ser cesada para ser modificada. Es el estado de la construcción en el mundo real Es la fecha de la construcción, que puede no existir, debido a que la construcción aún puede ser un proyecto Es la fecha de demolición de la construcción. Es la fecha de la última renovación de la construcción Es una medida absoluta vertical con respecto a una referencia Es una referencia a un sistema de información externo que contiene información relacionada a la construcción Altura de la construcción medida desde el suelo Nombre de la construcción Permite la asociación con el modelo de direcciones, y es definido como la dirección o direcciones que puede tener una construcción. Permite la asociación con el modelo de parcelas catastrales, y es definido como la parcela o parcelas que puede tener una construcción La clase AbstractBuilding es un subtipo de la clase AbstractConstruction y agrupa las propiedades comunes de los objetos del tipo edificios y partes de edificios. Tabla 56. Atributos de la clase AbstractBuilding Atributo Descripción OBLIGATORIO currentuse Describe el tipo de actividades que se realizan en el edificio. geometry Es la representación geométrica del edificio numberofbuildingunits Es el número de unidades de un edificio, que se definen como la subdivisión de una parte de un edificio. numberofdwellings Es el número de sobre rasantes de un edificio numberoffloorsabovegr Es el número de bajo rasantes de un edificio ound specificinterest Define algo característico de un edificio con propósitos temáticos. La clase Building es un subtipo de la clase AbstractBuilding y define objetos espaciales que representan estructuras cerradas, sobre y/o bajo la superficie terrestre y son utilizados para resguardar personas, animales, cosas o la producción de bienes económicos Tabla 57. Atributos de la clase Building Atributo Descripción OBLIGATORIO parts Describe el tipo de actividades que se realizan en el edificio. La clase BuildingPart es un subtipo de la clase AbstractBuilding y representa una subdivisión de un edificio que es homogénea respecto a sus características físicas, funcionales o temporales. La clase BuildingUnit representa una subdivisión de un edificio que es homogénea respecto a su administración, tiene los mismos derechos, restricciones y/o responsabilidades. Esta clase prestende decribir todo o una partde de un edificio desde la perspectiva de su administración. Por lo general las building units están separadas. 59

61 Tabla 58. Atributos de la clase BuildingUnit Atributo Descripción OBLIGATORIO externalreference Es una referencia a un sistema de información SI externo que contiene información relacionada a la construcción geometry Es la representación geométrica del edificio addresses Permite la asociación con el modelo de direcciones, y es definido como la dirección o direcciones que puede tener una construcción Modelos Relacionales, resultado de la transformación de los diagramas de clases UML de INSPIRE. Figura 37. Diagrama Entidad Relación del modelo de Parcelas Catastrales 60

62 Figura 38. Diagrama Entidad Relación del modelo de Edificios 61

63 Figura 39. Diagrama Entidad Relación del modelo de Direcciones 62

64 6.4. Modelos ETL creados en Geokettle Modelo de carga de datos obtenidos desde la Oficina Virtual del Catastro. Gracias a la modularidad de Geokettle, se han implementado tres trabajos y tres transformaciones individuales. Este conjunto de procesos están agrupados en el trabajo Modelo_ETL_OVC.kjb que se muestra en la Figura 40. Figura 40. Estructura del modelo de carga de datos de la OVC. Cada una de las transformaciones están formadas por varias tareas y cada uno de los trabajos está conformado por varias transformaciones. La Figura 41 muestra la secuencia ordenada para la ejecución de los trabajos y transformaciones correspondientes, de acuerdo al modelo implementado. Figura 41. Secuencia para la Carga de datos de la OVC. 63

65 Previo a la ejecución del modelo se debe cargar los datos de los inmuebles sobre la tabla inmuebles, que han sido descargados del webservice de la OVC, a partir de las referencias catastrales de cada una de las parcelas. A continuación se describe la funcionalidad de cada uno de los trabajos y los subprocesos que los componen. Transformación UltimoRegistro.ktr La Figura 42 muestra las tareas que dan lugar a esta transformación. Permite saber cuál es el identificador del último registro de un grupo de once tablas las cuales pueden dar lugar a duplicidad de relaciones en el momento de reutilizar los modelos. Con esta transformación se establecen los registros que se deben tomar en cuenta en cada ejecución del modelo de transformación y carga de datos, la ejecución de esta transformación da paso a la ejecución de los siguientes trabajos que permiten la migración de los datos. Figura 42. Transformación UltimoRegistro En esta transformación se realizan once procesos similares en paralelo, donde la tarea que diferencia a estos procesos es la selección de tabla de entrada sobre la que se aplica el proceso. Se utiliza código javascript para el control de la primera ejecución del modelo, debido a que en este caso 64

66 el máximo identificador en cada tabla es cero. Se selecciona el identificador máximo de cada tabla y se lo almacena en una tabla auxiliar (tb_uregistros) sobre la cual se realizan las consultas en las transformaciones siguientes. Cabe indicar que las tablas auxiliares que se crean en las diferentes transformaciones son eliminadas al final de la ejecución del modelo. Tomando en cuenta que el sistema de referencia espacial(srs) de los datos originales es el European Datum 1950 Zona 30 Norte correspondiente a EPSG y que la normativa de INSPIRE establece que la información geográfica debe tener como sistema de referencia espacial el sistema ETRS89 correspondiente al EPSG 4258, observaremos como factor común en las transformaciones las tareas de transformación de sistema de referencia espacial desde el EPSG al EPSG 4258, en la Figura 43 se visualizan las tareas necesarias para la transformación de coordenadas. Trabajo CadastralParcels.kjb Figura 43. Tareas para la transformación de sistema de referencia espacial. Este trabajo está conformado por tres transformaciones: hojas, masa y parcela como se muestra en la Figura 44. Estas transformaciones hacen referencia los shapefiles obtenidos desde la Oficina Virtual del Catastro, y se encarga de la migración de datos de los tres shapefiles al modelo CadastralParcels de INSPIRE. Como se describe en líneas siguientes los shapefile hojas.shp y masa.shp se corresponden a la tabla cp_cadastralzoning del modelo de INSPIRE, mientras que el archivo parcela.shp es cargado sobre la tabla cp_cadastralparcel. Transformación Hojas Figura 44. Trabajo CadastralParcels Esta transformación importa los datos del shapefile hojas.shp a la tabla cp_cadastralzoning, realizando la correspondiente transformación del sistema de referencia espacial, en el bloque de javascript utilizado se da formato a las fechas de alta y baja de cada uno de los features así como también el inspireid e inspirens (namespace) necesarios para insertar los datos sobre la tabla de salida. 65

67 Figura 45. Transformación Hojas Tabla 59. Correspondencia entre los atributos del shapefile hojas y la tabla cp_cadastralzoning. Shapefile Original Tabla de salida Transformación hojas.shp cp_cadastralzoning the_geom Cambio de SRS ( ) geometry GEOM MAPA FECHAALTA a formato numero inspireversion a formato fecha beginlifespanversion FECHABAJA a formato fecha endlifespanversion HOJA nationalcadastralzoningreference label NINTERNO level_order="1storder" level level_name="hoja" levelname ES.OVC.HOJAS inspirens Transformación Masa Esta transformación importa los datos del shapefile masa.shp a la tabla cp_cadastralzoning, realizando la correspondiente transformación del sistema de referencia espacial. Figura 46. Transformación Masa Al insertar los datos de shapefile sobre una misma tabla, la diferencia entre masa y hoja es que en la propiedad level de la tabla de salida a los datos de hoja.shp le corresponde el primer orden (1stOrder) y a los datos de masa.shp le corresponde el segundo orden (2ndOrder). La relación de entre hoja y masa debe ser establecida por la propiedad upperlevelunit, pero al realizar la ejecución de la selección de las claves ajenas, no existe una correspondencia total desde las hojas hacia las masas, por esto se estableció no insertar ningún dato en la propiedad upperlevelunit. Si es necesario establecer alguna relación se la debe realizar utilizando criterios espaciales. Tabla 60. Correspondencia entre el shapefile masa y la tabla cp_cadastralzoning. Shapefile Original Tabla de salida Transformación masa.shp cp_cadastralzoning the_geom Cambio de SRS ( ) geometry AREA 66

68 COORX COORY Calcular Punto desde coordenadas DELEGACION FECHAALTA a formato numero inspireversion a formato fecha beginlifespanversion FECHABAJA a formato fecha endlifespanversion HOJA MAPA MASA nationalcadastralzoningreference MUNICIPIO NINTERNO concatenar HOJA y MASA label level_order="2ndorder" level level_name="masa" levelname ES.OVC.MASA inspireversion Transformación Parcelas Esta transformación importa los datos del shapefile parcela.shp a la tabla cp_cadastralparcel, en este caso se está ordenando los datos por la propiedad masa del shapefile, lo que permite realizar una consulta sobre la base de datos en la tabla cp_cadastralzoning con el fin de obtener la clave foránea desde la masa correspondiente, creando así el dato para ser insertado en la propiedad zoning que establece la relación entre las tablas cp_cadastralzoning y cp_cadastralparcel. Se realiza la transformación del SRS y se realiza la inserción de datos a la tabla de salida. Figura 47. Transformación Parcelas Tabla 61. Correspondencia entre el shapefile parcela y la tabla cp_cadastralparcel. Shapefile Original Tabla de salida Transformación parcela.shp cp_cadastralparcel the_geom Cambio de SRS ( ) geometry COORX referencepoint COORY referencepoint VIA NUMERO NUMERODUP NUMSYMBOL AREA areavalue FECHAALTA a formato numero a formato fecha inspireversion beginlifespanversion 67

69 FECHABAJA a formato fecha endlifespanversion NINTERNO GEOM MAPA DELEGACIO MUNICIPIO MASA HOJA TIPO PARCELA REFCAT Consulta a base de datos para obtener la clave ajena desde la tabla cp_cadastralzoning ES.OVC.PARCELA zoning nationalcadastraltype nationalcadastralreference label inspireid inspirens En resumen con estas tres transformaciones se cargan los datos hacia las tablas cp_cadastralzoning y cp_cadastralparcel. Trabajo Buildings La Figura 48 muestra que este trabajo está conformado por cuatro transformaciones cuyo nombre hace referencia a las tablas sobre las que se cargan los datos. A continuación se realiza la descripción de cada una de las cuatro transformaciones, donde en cada transformación se cargan datos sobre una o más tablas. Transformación AbstractConstruction Figura 48. Trabajo Buildings A partir del shapefile CONSTRU.shp y la tabla inmuebles se cargan los datos a las tablas bu_abstractconstruction, bu_abstractbuilding, bu_currentuse,bu_buildinggeometry y bu_building que aparecen como tablas de salida en la figurans. En uno de los javascript se calcula cuantos sobre rasantes y cuantos bajo rasantes existen en la subparcela. En el javascript Uso Construcción se establece según el valor del campo luso de la tabla inmuebles un valor que se corresponda con el code list bu_currentusevalue, previamente creado sobre la base de datos. En el shapefile CONSTRU tenemos diferentes subparcelas pero con la misma referencia catastral, y además por cada una de ellas tenemos varias versiones, sin poder distinguir que versión de constru.shp se corresponde con que versión de parcela.shp. Inicialmente se consideró la posibilidad de codificar las subparcelas, añadiendo un caracter alfabético secuencialmente, pero existen casos con más de mil registros con las misma referencia catastral, por esto ha codificado las subparcelas de constru.shp añadiendo un número secuencial a la referencia catastral inicial. 68

70 Figura 49. Transformación AbstractConstruction En la Figura 49 se muestra que se agrupan los registros por la referencia catastral y son codificados, se realiza una búsqueda a la base de datos sobre la tabla inmuebles Número Inmuebles para saber cuántos inmuebles existen por cada referencia catastral. Tenemos también una secuencia generada desde la clave primaria de la tabla bu_abstractconstruction que permite crear la clave ajena sobre las demás tablas, debido a que bu_abstractconstruction es la clase padre de las demás tablas. Entradas constru.shp (co) y tabla inmuebles (inm) Tabla 62. Correspondencia de las entradas constru.shp e inmuebles. Transformación Tabla de salida bu_abstractconstruction (ac), bu_abastractbuilding (ab), bu_currentuse (cu), bu_buildinggeometry (bg) co.the_geom Cambio de SRS ( ) bg.geometry a formato numero ac.inspireversion co.fechaalta a formato fecha ac.beginlifespanversion co.fechabaja a formato fecha ac.endlifespanversion Se codifica las referencias catastrales ac.inspireid co.refcat utilizando un número secuencial calcular el número de sobre rasantes bu.numberofwellings co.constru calcular el número de bajo rasantes bu.numberoffloorsaboveground Contar en la tabla inmuebles cuantos inmuebles existen por cada referncia catastral bu.numberofbuildingunits inm.luso a partir de los posibles valores del codelist currenteusevalue, asignar un valor correspondiente ES.OVC.CONSTRU cu.currenteuse bu.inspirens Transformación AbsConstSubparce Como se muestra en la Figura 50, a partir del shapefile subparce.shp y la tabla inmuebles, se insertan los datos sobre las tablas bu_abstractconstruction, bu_abstractbuilding, bu_currentuse y bu_buildinggeometry. A diferencia de la transformación anterior no es necesario codificar las subparcelas, ya que vienen codificadas y si es posible distinguirlas por la referencia catastral. 69

71 También se calcula el número de inmuebles por cada referencia catastral, pero no el número de rasantes y sobrerasantes ya que el shapefile subparce.shp no tiene un campo con los datos que permiten su cálculo. Transformación BuildingUnit Figura 50. Transformación AbsConstSubparce Esta transformación carga los datos de la tabla inmuebles a la tabla bu_buildingunit y su extensión, que se ha creado en la base de datos con la finalidad de no perder datos que no se pueden asignar al modelo original de INSPIRE. La tabla inmuebles tiene datos geográficos correspondientes a las coordenadas del inmueble, estos datos están coordenadas geográficas decimales en el sistema de proyección WGS84, se trato de utilizar la función Point from X,Y que dispone Geokettle, pero debido a que las coordenadas poseen valores negativos esta operación no dio resultado, por esto en el javascript se incluye la trasformación de las coordenadas geográficas decimales a coordenadas proyectadas UTM utilizando el algoritmo que utiliza las fórmulas de Coticchia-Surace. Una vez que se transforma las coordenadas se calcula la geometría de cada punto para ser transformado finalmente al SRS ETRS89. Figura 51. Transformación BuildingUnit La Figura 51 además muestra la utilización de una secuencia a partir de la clave primaria de la tabla bu_buildingunit, la cual es utilizada sobre la tabla de extensión xtbu_ buildingunitxtend. 70

72 Transformación RelBuildingBuildingUnit Para establecer la relación entre bu_building y bu_buldingunit se debe hacer una comparación espacial de intersección entre las subparcelas oficiales que se encuentran en bu_abstractconstruction y los puntos de los inmuebles almacenados en bu_buildingunit. La Figura 52 muestra la sentencia sql donde se seleccionan las claves ajenas que participan de cada relación a partir de una primera condición espacial de intersección con la función ST_Intersects entre las geometrías de ambas entidades. Además se puede ver las condiciones de selección de las subparcelas oficiales contenidas en bu_abstractconstruction partir de las fechas. La tabla sobre la que se insertan las relaciones obtenidas es bu_buildingbuildingunit. Figura 52. Transformación RelBuildingBuildingUnit Tabla 63. Correspondencia del archivo inmuebles al modelo de Edificios. Entrada Inmuebles Transformación Tabla de salida bu_buldingunit (bu), xtbu_buildingunitextention(xbu) corx cory pc1 pc2 car cc1 cc2 sfc Calcular la geometría con las formulas de Coticchia-Surace Concatenar pc1,pc2,car,cc1,cc2 para obtener la referncia catastral de 20 dígitos de los inmuebles bu.geometry bu.inspireid xbu.officialarea ES.OVC.WS.INMUEBLES bu.inspirens 1 bu.inspireversion calcular fecha actual bu.beginlifespanversion 71

73 En resumen el trabajo Buildings.kjb se conforma de cuatro transformaciones que permiten cargar y distribuir los datos de los shapefile constru.shp, subparce.shp y la tabla inmuebles sobre ocho tablas correspondientes al modelo de edificios de INSPIRE. Trabajo Address Este trabajo se constituye como se muestra en la Figura 53, por nueve transformaciones y toma como fuente de datos aquellos obtenidos desde el webservice de la Oficina Virtual del Catastro. Al partir de la tabla inmuebles se redistribuyen los datos hacia las diferentes tablas del modelo de direcciones de INSPIRE. A continuación se describen cada una de las transformaciones. Transformación Address Figura 53. Trabajo Address A partir de la tabla inmuebles se cargan los datos sobre las tablas ad_adress, ad_addresscomponent y ad_geographicposition, esta última tabla almacena el punto geométrico de cada una de las direcciones. En cuanto a las dos primeras tablas existe una correspondencia de uno a uno por lo cual las claves primarias y ajenas en cada una de las tablas dependen de la secuencia creada a partir de la clave primaria de la tabla ad_address. Figura 54. Transformación Address 72

74 El inspireid de cada una de las tablas se ha conformado por la referencia catastral de veinte dígitos, lo que hace a cada una de las direcciones y sus componentes únicos en cada una de las tablas. Tabla 64. Correspondencia del archivo inmuebles hacia el modelo de Direcciones. Entrada Inmuebles pc1 pc2 car cc1 cc2 corx cory Transformación Concatenar pc1,pc2,car,cc1,cc2 para obtener la referencia catastral de 20 dígitos de los inmuebles Tabla de salida ad_address(ad), ad_addresscomponent(ac), ad_geographicposition (gp) ad.inspireid ac.inspireid ES.OVC.WS.INMUEBLES ad.inspirens 1 ad.inspireversion current ad.status calcular fecha actual ad.beginlifespanversion Calcular la geometría con las formulas de Coticchia-Surace gp.geometry ES.OVC.WS.INMUEBLES ac.inspirens 1 ac.inspireversion calcular fecha actual ac.beginlifespanversion current ac.status Transformación RelacionAddressComponent En esta transformación participan las tablas ad_address y ad_addresscomponet, con el fin de crear las relaciones entre ambas, la propiedad que se compara entre ambas en la búsqueda sql es el inspireid y las relaciones obtenidas son insertadas sobre la tabla ad_addresscomponentr. Figura 55. Transformación RelacionAddressComponent Tabla 65. Transformación para la tabla ad_addresscomponentr. Entrada ad_address(ad), ad_addresscomponent(ac) ad.addresdbk ac.addrescomponentdbk Transformación Consulta sobre las dos tablas de entrada que participan en la relación para establecer las claves ajenas Tabla de salida ad_addresscomponentr addressdbk component 73

75 Transformación AddRepresentation Esta transformación permite cargar los datos sobre la tabla ad_addressrepresentation a partir de la tabla inmuebles y la relación con la tabla ad_address. La tabla de salida almacena datos correspondientes al código postal, la calle el número, la unidad administrativa y número de portal. Figura 56. Transformación AddRepresentation Tabla 66. Transformación para generar la tabla ad_addressrepresentation. Entrada ad_address(ad), inmuebles(inm) inm.pc1 inm.pc2 inm.car inm.cc1 inm.cc2 ad.addresdbk inm.np inm.nm inm.pnp inm.nem inm.dp inm.nv Transformación Concatenar pc1,pc2,car,cc1,cc2 para obtener la referencia catastral de 20 dígitos de los inmuebles, con este código se debe realizar la consulta sobre la base de datos para obtener la clave ajena desde la tabla ad_address concatenar np,nm "puerta" "Codigo Postal" Tabla de salida ad_addressrepresentation addressfeature adminunit locatordesignator addressarea postcode thoroughfare locatorname postname Transformación AddressLocator En esta transformación se crea la tabla auxiliar locators por medio de sentencias sql. A partir de la tabla inmuebles se genera una tabla de tipos de localizadores (tabla con el nombre locators) donde en una tarea javascript se codifican los valores donde cada registro tiene el valor de la referencia catastral de 20 dígitos para poder relacionar con su respectiva clave ajena. Figura 57. Transformación AddressLocator 74

76 Por ejemplo si tenemos un registro de la tabla inmuebles : id portal bloque escalera planta puerta refcat BL D XXX A partir de este registro se crean cinco registros diferentes por cada designador según el tipo establecido en las especificaciones de INSPIRE. Los tipos y niveles de designator a utilizar son los que se muestran en la Tabla 67: Tabla 67. Tipos y niveles de los designadores de dirección. propiedad tipo nivel portal addressnumber sitelevel bloque entrancedooridentifier accesslevel escalera staircaseidentifier accesslevel planta flooridentifier accesslevel puerta unitidentifier unitlevel Con este criterio para el registro de la tabla inmuebles citado en la tablan la desagregación tiene como resultado los 5 registros de la Tabla 68. Tabla 68. Codificación de los designadores de dirección. designator propiedad tipo nivel refcat 5 portal addressnumber sitelevel XXX BL5 bloque entrancedooridentifier accesslevel XXX 5 escalera staircaseidentifier accesslevel XXX 03 planta flooridentifier accesslevel XXX D puerta unitidentifier unitlevel XXX Una vez que cada registro es desagregado se realiza una búsqueda sobre la tabla ad_addresscomponent para encontrar la clave ajena y se procede a insertar los datos sobre la tabla auxiliar que se ha creado. En las sentencias sql se realizan cinco inserciones por cada registro como se muestra en la figuran. Figura 58. Inserción de datos hacia la tabla locators En la siguiente tabla se muestra como se corresponden cada uno de los tipos de localizadores hacia la tabla de salida auxiliar locators. 75

77 Tabla 69. Transformación para generar la tabla locators. Entrada inmuebles pc1 pc2 car cc1 cc2 pnp bq es pt pu Transformación Concatenar pc1,pc2,car,cc1,cc2 para obtener la referncia catastral de 20 dígitos de los inmuebles "addressnumber" "sitelevel" "entrancedooridentifier" "accesslevel" "staircaseidentifier" "accesslevel" "flooridentifier" "accesslevel" "unitidentifier" "unitlevel" Tabla de salida locators refcat desig tipo level desig tipo level desig tipo level desig tipo level desig tipo level Transformación Locatordesignator Esta transformación permite a partir de la tabla locators, en la que se desagregaron los datos en la transformación anterior, distribuir los datos s las diferentes tablas ad_addresslocator, que es la clase padre y sus clases hijas ad_locatorname y ad_locatordesignator, asignando en cada una de las tablas como clave ajena la clave primaria de la tabla ad_addresscomponent. Figura 59. Transformación Locatordesignator. 76

78 Tabla 70. Transformación para generar la tabla LocatorName. Entrada locators (L), ad_addresscomponent (ac) L.refcat ac.addresscomponentdbk L.level L.tipo L.desig Transformación Realizando una consulta hacia la base de datos se obtiene la clave ajena para las tablas de salida "Inmueble" "sitename" Tabla de salida ad_addresslocator(al), ad_locatorname(ln), locatordesignator(ld) al.withinscopeof Ln.addresslocatordbk Ld.addresslocatordbk al.level Ln.name Ln.type Ld.type Ld.designator Transformación TipoComponentes Esta transformación permite distribuir los datos de la tabla inmuebles sobre los diferentes tipos de componentes de una dirección como son: adminunitname, postalcodedescriptor, addressareaname, thoroughfarename y thoroughfarenamevalue. Se toma como clave ajena la relación con la clave primaria desde la tabla ad_addresscomponent. Figura 60. Transformación TipoComponentes 77

79 Tabla 71. Transformación para crear los componentes de dirección. Entrada inmuebles (inm), ad_addresscomponent (ac) inm.pc1 inm.pc2 inm.car inm.cc1 inm.cc2 ac.addresscomponentdbk inm.nm inm.dp inm.nm inm.ldt Transformación Concatenar pc1,pc2,car,cc1,cc2 para obtener la referncia catastral de 20 dígitos de los inmuebles, con est código se debe realizar la consulta sobre la base de datos para obtener la clave ajena desde la tabla ad_addresscomponent "3rdOrder" Tabla de salida ad_adminunitname(au), ad_postaldescriptor(pd), ad_addressareaname(an), ad_thoroughfarename(tfn), ad_thoroughfarenamevalue(tfnv) au.addresscomponentdbk pd.addresscomponentdbk an.addresscomponentdbk tfn.addresscomponentdbk au.name au.level pd.postcode an.name tfnv.name Transformación TipoVias La transformación tipo vías realiza un proceso similar a la desagregación de un registro realizado en una de las transformaciones anteriores (AddressLocator). La Figura 61 se muestra la creación de la tabla auxiliar tipovias, la tabla de entrada inmuebles y el javascript que permite crear por cada registro dos nuevas filas, que pretenden diferenciar dos componentes de una dirección que son el tipo (type) y el nombre(name), necesarias para ser utilizadas en la transformación ThorounghfareName. Figura 61. Transformación TipoVias Figura 62. Inserción de datos hacia la tabla tipovias 78

80 Transformación ThoroughfareName Esta transformación permite distribuir la información de la tabla tipovias en la tabla ad_partofname, la cual almacena las posibles partes de las que está formado el nombre de una vía, en este caso el nombre y el tipo. Figura 63. Transformación ThoroughfareName La Figura 64 muestra la entrada de la tabla tipovias. Figura 64. Entrada de datos de la tabla tipovias Tabla 72. Transformación para generar la tabla de partes de dirección. Entradas tipovias (tv), ad_thoroughfarenamevalue(tfnv) Transformación Tabla de salida ad_partofname tv.refcat tfnv.thoroughfarenamevaluedbk tv.descripcion tv.tipo Realizando una consulta hacia la base de datos se obtiene la clave ajena desde las dos tablas de entrada para la tabla de salida thoroughfarenamevaluedbk part type Un ejemplo de los datos de la tabla de salida es la Figura 65, donde se muestra el resultado de la descomposición de la dirección en partes, y la referencia hacia el nombre de una vía con la correspondiente clave ajena. 79

81 Transformación EliminarAuxiliares Figura 65. Datos que contiene la tabla ad_partofname Con la transformación anterior se finaliza la carga de datos des de la tabla inmuebles a las tablas correspondientes al modelo de direcciones de INSPIRE, en esta transformación que solo consta de una tarea, que es la ejecución de sentencias SQL, se procede a eliminar las tablas auxiliares creadas en las transformaciones previas. Transformación RelacionesEsquemas Figura 66. Sql para eliminar tablas auxiliares Esta transformación es la transformación final, la cual se encarga de cargar los datos en las tablas que relacionan los tres modelos de INSPIRE sobre los que se está trabajando: Parcelas Catastrales, Edificios y Direcciones. Las tablas de salida sobre las que se insertan los datos son cuatro: bu_abstractconstructioncadastralparcels : Es la relación entre las tablas bu_abstractconstruction y cp_cadastralparcels. Para esta tabla se seleccionan las parcelas en su versión oficial y todas las features de bu_abstractconstruction. ad_addressbuildingunit : Es la tabla que almacenas las relaciones entre la tabla bu_buldingunit y ad_address, que se relacionan por la propiedad inspireid que es la referencia catastral de 20 dígitos de cada inmieble. ad_addressabstractconstruction : Es la tabla de relación entre ad_address y la tabla bu_abstractconstruction. Al realizar la relación entre las direcciones y las subparcelas de constru.shp (bu_abstractconstruction) que en la columna inspireid se encuentra codificada de forma 80

82 secuencial, y en la columna inspireid de la tabla ad_address se tiene la referencia catastral de 20 dígitos NO se tiene una relación implícita, por lo cual se realiza relación espacial de intersección. ad_addressparcel : Es la tabla de relación entre las tablas ad_adress y cp_cadsatralparcel entre las que existe una relación entre la propiedad inspireid de cp_cadastralparcel y los primeros catorce dígitos del inspireid de a d_address. Figura 67. Transformación para establecer las relaciones entre los modelos de INSPIRE En la Figura 67 se muestra cuatro procesos en paralelo que cargan independientemente los datos sobre sus correspondientes relaciones, las tablas de entrada, por ejemplo SQL FKs1 establece el criterio de relación entre las dos tablas participantes, las tareas del tipo uregistro1 se encargan de calcular el último registro en cada una de las tablas para evitar duplicar las relaciones ya existentes, lo cual se consigue filtrando los datos que nos pertenezcan a aquellos ya existentes en las relaciones. Así finalizan el modelo de carga de datos correspondientes a la Oficina Virtual del Catastro. Algo necesario para la reutilización del modelo, direccionar la ejecución del modelo hacia los directorios donde se encuentren los datos catastrales de un nuevo municipio Modelo de carga de datos obtenidos desde el Sistema de Riqueza Territorial de Navarra. A diferencia de los datos descargados desde la OVC, los datos descargados desde el Sistema de Riqueza Territorial de Navarra no tienen correspondencia hacia el modelo de Edificios de INSPIRE, por esta razón el modelo ETL para estos datos consta de dos trabajos que su vez están formados por las transformaciones que ejecutan las correspondientes tareas de exploración, transformación y carga de datos. 81

83 Figura 68. Modelo ETL para los Datos del SRTN El primer trabajo es el trabajo TrabajoCadastralParcelsNavarra, el cual está formado por cuatro transformaciones que se encarga cargar los datos desde los shape file de muncipios, polígonos y parcelas catastrales hacia las tablas del modelo de Parcelas Catastrales de INSPIRE. Figura 69. Trabajo CadastralParcelsNavarra. La transformación UltimoRegistro cumple la misma función descrita en el modelo ETL para los datos de la OVC. Las transformaciones Municipio y polígono cargan los datos correspondientes a la tabla cp_cadastralzoning y se corresponden a las transformaciones Hojas y Masa del modelo ETL para los datos de la OVC. La transformación parcelas navarra se muestra en la Figura 70. Esta transformación realiza cuatro procesos paralelos tomando como fuentes de datos cuatro archivos shapefile que contienen parcelas de diferente tipo y la salida de esta transformación es la inserción de datos sobre la tabla cp_cadastralparcel, obteniendo de esta forma los datos de los cuatro shapefiles en un mismo repositorio. En la tarea que se ha denominado Consulta a cp_cadastralzoning se establece la zona catastral a la que pertenecer cada parcela. Figura 70. Transformación parcelasnavarra 82

84 En este caso las parcelas de entrada no disponen de un campo con el área de cada parcela, por lo tanto se procede al cálculo del área de cada parcela utilizando la tarea Calculo Area. El segundo trabajo que forma parte del modelo ETL, es el trabajo AddressNavarra, el cual utiliza los datos alfanuméricos para establecer las relaciones existentes entre los datos descargados y cargar los datos sobre el modelo de direcciones según el análisis de correspondencias. Figura 71. Trabajo AddressNavarra El Trabajo AddressNavarra está conformado por trece transformaciones que se encargan de distribuir los datos alfanuméricos descargados sobre el modelo de direcciones de INSPIRE. A diferencia de los datos de direcciones de la OVC, estos datos no tienen una componente geográfica. La transformación Crear Tablas Auxiliares, crea las tablas inmuebles, subareas y vias, que son tablas auxiliares para estructurar los datos previo a la distribución sobre las tablas de salida Figura 72. Transformación Crear Tablas Auxiliares La transformación Vias carga los datos desde el archivo vias_201.txt hacia la tabla auxiliar vias separando los datos en código de vía, nombre de vía y tipo de vía. Figura 73. Transformación Vias. 83

85 La transformación subareas carga los datos desde el archivo subareas_201.txt hacia la tabla auxiliar subareas. En esta transformación se obtienen datos que permiten relacionar los datos de las parcelas catastrales y los datos de las vías. De esta forma se puede asignar una vía a cada una de las parcelas. Figura 74. Script de la transformación subareas. La transformación CargarInmuebles, extrae los datos del archivo unidades_urbanas_201.txt y los lleva hacia la tabla auxiliar inmuebles, en la cual se almacena datos relacionados a la dirección de los inmuebles como el número de portal, escalera, planta y puerta de los inmuebles existentes en cada parcela. Figura 75. Transformación CargarInmuebles En adelante las demás transformaciones de las que está formado el trabajo AddressNavarra se corresponde exactamente a las transformaciones del modelo ETL para los datos de la OVC. Esto se ha conseguido llevando los datos alfanuméricos de entrada a una misma estructura que es la tabla inmuebles. A partir de la transformación AddressNavarra la distribución de los datos desde las tabla inmuebles hacia las tablas del modelo de Direcciones de INSPIRE utilizan las mismas correspondencias descritas desde la Tabla 64 hasta la Tabla Funcionamiento e Implementación de los servicios OWS Envío de Peticiones al WFS utilizando filtros OGC. Los filtros OGC son filtros en codificación XML que permiten obtener objetos específicos en similitud a una clausula WHERE utilizada en el lenguaje SQL. Un Web Feature Service puede utilizar filtros OGC en la operación GetFeature para definir las condiciones que debe cumplir la feature a obtener. Para establecer las condiciones de los filtros existen tres tipos de operadores: Espaciales, Comparativos y Lógicos. Operadores Espaciales Este tipo de operadores permite comparar las geometrías de dos objetos espaciales y son: Equals Disjoint Touches Within 84

86 Overlaps Intersects Crosses Contains DWithin Beyond BBOX. Operadores de Comparación Este tipo de operadores permite comparar el valor de las propiedades de un objeto: PropertyIsEqualTo PropertyIsNotEqualTo PropertyIsLessThan PropertyIsGreaterThan PropertyIsLessThanOrEqualTo PropertyIsGreaterThanOrEqualTo PropertyIsLike PropertyIsNull PropertyIsBetween And Or Not Operadores Lógicos Permite establecer varios criterios de consulta en un mismo filtro A continuación se muestra en figuras algunos ejemplos de peticiones realizadas al WFS utilizando algunos filtros OGC. Figura 76. GetFeature hacia la feature CadastralZoning 85

87 Figura 77. GetFeature hacia la feature CadastralParcel Figura 78. GetFeature hacia la feature Address Figura 79. GetFeature hacia la feature BuildingUnit 86

88 Figura 80. GetFeature hacia la feature CadastralParcel utilizando un operador espacial Figura 81. GetFeature hacia la feature CadastralParcel utilizando un operador lógico Configuración del servicio WPS. Para la implementación del servicio WPS el cual provee del servicio de buffer al tener como parámetros de entrada las coordenadas de un punto y una distancia específica se ha implementado la clase java que contiene la función que se muestra en la Figura 82, en la cual se recibe los parámetros 87

89 de entrada distancia e inputgml desde el proceso y se devuelve hacia el proceso el parámetro de salida BufferedGeometry. Los nombre de los parámetros de entrada y salida en la clase java deben ser los correspondientes a los configurados en el archivo XML correspondiente al proceso. En la Figura 83 se muestra la configuración del proceso Buffer en el cual se especifican los parámetros de entrada inputgml como una entrada compleja <ComplexInput> y la distancia como un tipo de entrada simple <LiteralInput>. Además se especifica la salida del proceso BufferedGeometry como una salida compleja <ComplexOutput>. En la Figura 84 se muestra la configuración del WPS, en el cual se han configurado los parámetros que Deergree establece por defecto. Una vez que el servicio es implementado el proceso Buffer está listo para recibir solicitudes sobre sus operaciones. En Deegree los tipos de entradas pueden ser: LiteralInput Es utilizado para parámetros de entrada simples, con valores literales, que están dados por cadenas simples como: azul, 48, calle Tomás Bretón. BoundingBoxInput Este tipo de entrada especifica un bounding box específico en un Sistema de coordenadas de referencia por defecto o específico. ComplexInput Puede ser una estructura XML compleja o bien datos binarios, utilizada para entradas de tipo geométrico. Figura 82. Función para la obtención de un buffer a partir de un punto y una distancia. 88

90 Figura 83. Configuración del proceso Buffer. Figura 84. Configuración del WPS 89

Encuesta iberoamericana de información catastral. Resultados Tercera Edición

Encuesta iberoamericana de información catastral. Resultados Tercera Edición Encuesta iberoamericana de información catastral Resultados Tercera Edición Recordemos los objetivos de la encuesta La construcción de un Sistema de Información Iberoamericano: Un sistema de información

Más detalles

DIRECCIÓN DE EVALUACIÓN, CONTROL Y DIFUSIÓN DE LA INFORMACIÓN - (DECDI)

DIRECCIÓN DE EVALUACIÓN, CONTROL Y DIFUSIÓN DE LA INFORMACIÓN - (DECDI) DIRECCIÓN DE EVALUACIÓN, CONTROL Y DIFUSIÓN DE LA INFORMACIÓN - (DECDI) 3 CONCEPTOS TEÓRICOS INFRAESTRUCTURA DE DATOS ESPACIALES Ing. Sylvia Huilcamaigua Qué es una IDE Colección básica pertinente de tecnologías,

Más detalles

IDEZar: Procesos, herramientas y modelos urbanos aplicados a la integración de datos municipales procedentes de fuentes heterogéneas

IDEZar: Procesos, herramientas y modelos urbanos aplicados a la integración de datos municipales procedentes de fuentes heterogéneas IDEZar: Procesos, herramientas y modelos urbanos aplicados a la integración de datos municipales procedentes de fuentes heterogéneas López Pellicer, F.J., Álvarez, P., Muro-Medrano, P.R.. Departamento

Más detalles

LA CARTOGRAFÍA CATASTRAL COMO SERVICIO WEB DE LA DIRECCIÓN GENERAL DEL CATASTRO

LA CARTOGRAFÍA CATASTRAL COMO SERVICIO WEB DE LA DIRECCIÓN GENERAL DEL CATASTRO LA CARTOGRAFÍA CATASTRAL COMO SERVICIO WEB DE LA DIRECCIÓN GENERAL DEL CATASTRO Jefe de Servicio de Sistemas Informáticos Jefe de Área Coord. Informatica Jefe de Servicio de Sistemas Informáticos Jefe

Más detalles

SISTEMA DE INFORMACIÓN TERRITORIAL PARA LA ADMINISTRACIÓN LOCAL: GeoPISTA

SISTEMA DE INFORMACIÓN TERRITORIAL PARA LA ADMINISTRACIÓN LOCAL: GeoPISTA SISTEMA DE INFORMACIÓN TERRITORIAL PARA LA ADMINISTRACIÓN LOCAL: GeoPISTA Dirección General para el Desarrollo de la Información Ministerio de Industria, Turismo y Comercio Director Técnico proyectos PISTA

Más detalles

Soluciones de Cartografía, GIS y Teledetección www.tycgis.com. CURSO INFRAESTRUCTURAS DE DATOS ESPACIALES (IDEs) Y ELABORACIÓN DE METADATOS

Soluciones de Cartografía, GIS y Teledetección www.tycgis.com. CURSO INFRAESTRUCTURAS DE DATOS ESPACIALES (IDEs) Y ELABORACIÓN DE METADATOS CURSO INFRAESTRUCTURAS DE DATOS ESPACIALES (IDEs) Y ELABORACIÓN DE METADATOS MODALIDAD ONLINE Profesionales formando a Profesionales 2015 formacion@tycgis.com Calle Rodríguez San Pedro 13, 3ª Planta, Oficina

Más detalles

Geoservicios del Open Geoespatial Consortium

Geoservicios del Open Geoespatial Consortium Página1 Taller: Puesta. I. Introducción Uno de los aportes más significativos en la tecnología Web, es sin duda la estandarización del método de acceso a la información para los clientes, simplificando

Más detalles

Dirección General del Catastro. La estandarización del Catastro y las Infraestructuras de Datos Espaciales. El ejemplo Español

Dirección General del Catastro. La estandarización del Catastro y las Infraestructuras de Datos Espaciales. El ejemplo Español La estandarización del y las Infraestructuras de Datos Espaciales. El ejemplo Español Por qué es necesaria la estandarización de los datos? Qué es una infraestructura de datos espaciales? INSPIRE, la infraestructura

Más detalles

Implantación de una Infraestructura de Datos Espaciales en el Ministerio de Fomento

Implantación de una Infraestructura de Datos Espaciales en el Ministerio de Fomento Implantación de una Infraestructura de Datos Espaciales en el Ministerio de Fomento Alonso Jiménez, José Ángel (1), Anguix, A. (2), Rosa, J.M. (2), (1) Instituto Geográfico Nacional Av. GeneralIbáñez de

Más detalles

Sistema de Información Catastral

Sistema de Información Catastral Sistema de Información Catastral Un sistema de información para la definición de Políticas de ordenamiento Territorial Arq. Liliana Bustamante Instituto Geográfico Agustín Codazzi. Subdirección de Catastro

Más detalles

Desarrollo de un servidor de mapas utilizando software libre

Desarrollo de un servidor de mapas utilizando software libre Jornadas Regionales de Información Geográfica y Ordenamiento Territorial 1(2009): 168 175 Ministerio Secretaría General de la Gobernación, Proyecto SIT SantaCruz Diaz B.G. y Calviño P. (Compiladores) /

Más detalles

SERVICIO WPS PARA LA OBTENCIÓN DE INFORMACIÓN ALFANUMÉRICA. Josefina Sáez Burgaya

SERVICIO WPS PARA LA OBTENCIÓN DE INFORMACIÓN ALFANUMÉRICA. Josefina Sáez Burgaya SERVICIO WPS PARA LA OBTENCIÓN DE INFORMACIÓN ALFANUMÉRICA Josefina Sáez Burgaya Diputació de Barcelona Àrea d Infraestructures, Urbanisme i Habitatge Oficina Tècnica de Cartografia i SIG Local Urgell,

Más detalles

IDEJaén, una IDE como herramienta Municipal para la Gestión del Territorio.

IDEJaén, una IDE como herramienta Municipal para la Gestión del Territorio. IDEJaén, una IDE como herramienta Municipal para la Gestión del Territorio. Julio Torres Manjón 1, José Antonio Rodríguez Mellado 2 1 Responsable del SIG de la Diputación Provincial de Jaén Plaza de San

Más detalles

CONFIGURACIÓN DE UN SERVIDOR OPENGIS CON GEOMEDIA WEB MAP PUBLISHER.

CONFIGURACIÓN DE UN SERVIDOR OPENGIS CON GEOMEDIA WEB MAP PUBLISHER. CONFIGURACIÓN DE UN SERVIDOR OPENGIS CON GEOMEDIA WEB MAP PUBLISHER. Definición de un site con WMS+WFS+OpenLS+Catalog Service para la Direcció General de Carreteres. RESUMEN Joan Dídac Soler Fundació UPC

Más detalles

Workshop Taller I: Introducción a los SIG

Workshop Taller I: Introducción a los SIG Taller I: Introducción a los SIG Talleristas: Comunidad SIG MAPA EDUCATIVO Qué es la información geográfica? https://www.youtube.com/watch?v=qvkldkhvvyo Qué es un SIG o GIS? Las siglas significan lo mismo,

Más detalles

gvsig un cliente para el Servicio WFS de la D.G. del Catastro

gvsig un cliente para el Servicio WFS de la D.G. del Catastro gvsig un cliente para el Servicio WFS de la D.G. del Catastro A. Cano, L. Virgós, J.M. Olivares, F. J. Quintana, F. García Cepeda Subdirección General de Estudios y Sistemas de Información Dirección General

Más detalles

Las especificaciones de INSPIRE para la parcela catastral

Las especificaciones de INSPIRE para la parcela catastral Las especificaciones de INSPIRE para la parcela catastral Amalia Velasco 2011-03-18 Reunión GT en Barcelona 1 Metodología para la definición de las especificaciones del modelo de datos La metodología se

Más detalles

Servicios Web de CartoCiudad. Ministerio de Fomento

Servicios Web de CartoCiudad. Ministerio de Fomento Servicios Web de CartoCiudad. Ministerio de Fomento DATOS GENERALES Antecedentes del servicio De acuerdo con el Real Decreto 1545/2007, de 23 de noviembre, por el que se regula el Sistema Cartográfico

Más detalles

Portal de Servicios Geográficos en Línea como Factor de Desarrollo de las IDE

Portal de Servicios Geográficos en Línea como Factor de Desarrollo de las IDE Portal de Servicios Geográficos en Línea como Factor de Desarrollo de las IDE Lilia Patricia Arias Duarte Jefe del Centro de Investigación y Desarrollo en Información Geográfica - CIAF Instituto Geográfico

Más detalles

Internet: Orígenes. En 1983 ARPANET se separa de la red militar que la originó.

Internet: Orígenes. En 1983 ARPANET se separa de la red militar que la originó. Curso Introductorio Internet: Orígenes Los orígenes de Internet se remontan a la década del 60. Surge como un proyecto de investigación estadounidense dentro de un ámbito militar. Su objetivo: crear una

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Novedades de CartoCiudad en 2012: Primeros pasos hacia el cumplimiento de INSPIRE

Novedades de CartoCiudad en 2012: Primeros pasos hacia el cumplimiento de INSPIRE Novedades de CartoCiudad en 2012: Primeros pasos hacia el cumplimiento de INSPIRE Alicia González Jiménez 1, José Miguel Rubio Iglesias 1, Ana Velasco Tirado 1, Julián González García 1, Patricia Trigo

Más detalles

Infraestructura de Datos Espaciales de la Isla de la Palma

Infraestructura de Datos Espaciales de la Isla de la Palma Infraestructura de Datos Espaciales de la Isla de la Palma Bermejo Dominguez, Juan Antonio (1), Anguix Alfaro, Alvaro (2) (1) Cabildo Insular de La Palma Avda. Maritima Nº 34 Santa Cruz de La Palma Tfn:

Más detalles

CartoCiudad apuesta por el software libre.

CartoCiudad apuesta por el software libre. VI JORNADAS DE SIG LIBRE CartoCiudad apuesta por el software libre. Julián González García (1), Ana Velasco Tirado (1), Alicia González Jiménez (1), José Miguel Rubio Iglesias (1), Paloma Verdejo Herreras

Más detalles

Curso online Desarrollo de Aplicaciones Web Mapping

Curso online Desarrollo de Aplicaciones Web Mapping Curso online Desarrollo de Aplicaciones Web Mapping El curso va dirigido a todos aquellos profesionales que desean adquirir los conocimientos prácticos y teóricos para desarrollar aplicaciones web de mapas

Más detalles

Nota de prensa. La Cartografía Catastral ya se encuentra disponible en Internet para Administraciones e Instituciones

Nota de prensa. La Cartografía Catastral ya se encuentra disponible en Internet para Administraciones e Instituciones Nota de prensa El Ministerio de Economía y Hacienda pone la información catastral a disposición de los internautas La Cartografía Catastral ya se encuentra disponible en Internet para Administraciones

Más detalles

Juan Ramón Pérez Pérez jrpp@uniovi.es Departamento de Informática. Universidad de Oviedo

Juan Ramón Pérez Pérez jrpp@uniovi.es Departamento de Informática. Universidad de Oviedo Juan Ramón Pérez Pérez jrpp@uniovi.es Departamento de Informática. Universidad de Oviedo Qué es un SIG Definición Casos de estudio. Características Funcionalidades Aplicaciones Tipos de SIG Raster Vectorial

Más detalles

Cacheado de datos procedentes de servicios WFS en la aplicación web del proyecto EuroGeoSource

Cacheado de datos procedentes de servicios WFS en la aplicación web del proyecto EuroGeoSource Cacheado de datos procedentes de servicios WFS en la aplicación web del proyecto EuroGeoSource R. Béjar 1a, D. Gayán-Asensio 1, M. Á. Latre 1, R. Rioja 2, M. Usón 2 1 Universidad de Zaragoza, Zaragoza,

Más detalles

Dar a conocer el contexto de los metadatos geográficos como un elemento clave en la consolidación de una Infraestructura de Datos Espaciales.

Dar a conocer el contexto de los metadatos geográficos como un elemento clave en la consolidación de una Infraestructura de Datos Espaciales. METADATOS Objetivos: Compartir experiencias con los asistentes en la elaboración de metadatos geográficos y reconocer su importancia como mecanismo de preservación y difusión de la información geográfica.

Más detalles

INFRAESTRUCTURAS DE DATOS ESPACIALES Y SERVIDORES DE MAPAS EN INTERNET

INFRAESTRUCTURAS DE DATOS ESPACIALES Y SERVIDORES DE MAPAS EN INTERNET INFRAESTRUCTURAS DE DATOS ESPACIALES Y SERVIDORES DE MAPAS EN INTERNET INTRODUCCIÓN : LA INICIATIVA INSPIRE Y EL OPEN GIS CONSORTIUM El mundo de los SIG evoluciona rápidamente, como sucede con cualquier

Más detalles

Metadatos, Estándares y Bodegas de Datos. Lilia Patricia Arias Duarte Jefe Centro de Investigación n y Desarrollo en Información n Geográfica CIAF

Metadatos, Estándares y Bodegas de Datos. Lilia Patricia Arias Duarte Jefe Centro de Investigación n y Desarrollo en Información n Geográfica CIAF Metadatos, Estándares y Bodegas de Datos Lilia Patricia Arias Duarte Jefe Centro de Investigación n y Desarrollo en Información n Geográfica CIAF Instituto Geográfico Agustín n Codazzi - IGAC AGENDA Contexto

Más detalles

Desarrollo e implantación de un Geoportal y de servicios de Infraestructura de Datos Espaciales en el Ayuntamiento de Barcelona

Desarrollo e implantación de un Geoportal y de servicios de Infraestructura de Datos Espaciales en el Ayuntamiento de Barcelona Desarrollo e implantación de un Geoportal y de servicios de Infraestructura de Datos Espaciales en el Ayuntamiento de Barcelona Miguel Ángel Bolívar Leyva Informació de Base i Cartografia Institut Municipal

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Soluciones de código c abierto en el campo de los Sistemas de Información Geográfica

Soluciones de código c abierto en el campo de los Sistemas de Información Geográfica Soluciones de código c abierto en el campo de los Sistemas de Información Geográfica Conferencia Internacional de Software Libre Málaga, 2004 Málaga, 19 de Febrero de 2004 Presentación Ponente: Óscar Gómez

Más detalles

Editor Web Arqueológico mediante WFS-T

Editor Web Arqueológico mediante WFS-T Editor Web Arqueológico mediante WFS-T Mantenimiento y edición gráfica de conjuntos de datos espaciales. CARDOSO SANTOS, Juan Luis; VILLAFRANCA ARTIEDA, Miguel Se presenta una aplicación Web de análisis

Más detalles

Infraestructura de Datos Espaciales de Venezuela, una IDE 100% software libre

Infraestructura de Datos Espaciales de Venezuela, una IDE 100% software libre IV JORNADAS DE SIG LIBRE Infraestructura de Datos Espaciales de Venezuela, una IDE 100% software libre V.González 1, F. Peñarrubia 2, J.Higón 2, J. Sanz 3 y A.Anguix 4. 1 Creativa C.A. Asociación gvsig.

Más detalles

La implementación de INSPIRE y las herramientas gvsig

La implementación de INSPIRE y las herramientas gvsig http://ww w.ign.es La implementación de INSPIRE y las herramientas gvsig 8as Jornadas Internacionales de gvsig Author Antonio F. Rodríguez GT IDEE, CODIGE 1 «La necesidad humana de compartir cosas es evidente»

Más detalles

Qué es un Servicio Web?

Qué es un Servicio Web? Qué es un Servicio Web? Los Servicios Web son componentes que permiten la comunicación entre aplicaciones ubicadas en diversos puntos geográficos de manera interoperable, por medio del uso de estándares

Más detalles

Formación en Infraestructura de Datos Espaciales

Formación en Infraestructura de Datos Espaciales Formación en Infraestructura de Datos Espaciales María Ester Gonzalez 1, Argentina Sampaio Costa 2, Miguel Ángel Bernabé Poveda 1, María Teresa Manrique Sancho 1 1 2 Laboratorio de Tecnologías de la Información

Más detalles

Infraestructura de Datos Espaciales de la Isla de La Palma: un camino hacia la colaboración, formación n y difusión. Cabildo Insular de La Palma

Infraestructura de Datos Espaciales de la Isla de La Palma: un camino hacia la colaboración, formación n y difusión. Cabildo Insular de La Palma Infraestructura de Datos Espaciales de la Isla de La Palma: un camino hacia la colaboración, formación n y difusión Cabildo Insular de La Palma 1 Infraestructura de Datos Espaciales de la Isla de La Palma

Más detalles

REPUBLICA DE COLOMBIA. Decreto No.

REPUBLICA DE COLOMBIA. Decreto No. Decreto No. "Por el cual se establece la obligatoriedad del uso de los parámetros y estándares establecidos por la Infraestructura Colombiana de Datos Espaciales -- ICDE para la producción, intercambio

Más detalles

CONSULTA Y ACTUALIZACIÓN DE INFORMACIÓN CATASTRAL MEDIANTE SERVICIOS WEB

CONSULTA Y ACTUALIZACIÓN DE INFORMACIÓN CATASTRAL MEDIANTE SERVICIOS WEB CONSULTA Y ACTUALIZACIÓN DE INFORMACIÓN CATASTRAL MEDIANTE SERVICIOS WEB Carlos Alonso Peña Coordinador del Área de Desarrollo Roberto Fernández Gómez Jefe de Área de Gestión e Informática Elsa Yáñez Morante

Más detalles

Avances del Catastro hacia la interoperabilidad y el trabajo colaborativo

Avances del Catastro hacia la interoperabilidad y el trabajo colaborativo UIMP CUENCA 2008 SEMINARIO Oportunidades de las Tecnologías de la Información Geográfica para la Administración Local y el Desarrollo sostenible Avances del Catastro hacia la interoperabilidad y el trabajo

Más detalles

CartoCiudad: Una apuesta colaborativa de las Administraciones Públicas y de interoperabilidad de datos espaciales

CartoCiudad: Una apuesta colaborativa de las Administraciones Públicas y de interoperabilidad de datos espaciales CartoCiudad: Una apuesta colaborativa de las Administraciones Públicas y de interoperabilidad de datos espaciales A. González 1, A. Velasco 1, P.Trigo 1, S.Mas 1, P. Verdejo 1, G. Andrés 1 1 Instituto

Más detalles

Juan Arias Juan.arias@one.gob.do Departamento de Cartografía Oficina Nacional de Estadística República Dominicana

Juan Arias Juan.arias@one.gob.do Departamento de Cartografía Oficina Nacional de Estadística República Dominicana Juan Arias Juan.arias@one.gob.do Departamento de Cartografía Oficina Nacional de Estadística República Dominicana PREÁMBULO La Oficina Nacional de Estadística desde el año 1993 ha realizado varios esfuerzo

Más detalles

PROYECTO OFICINA VIRTUAL DE CATASTRO

PROYECTO OFICINA VIRTUAL DE CATASTRO PROYECTO OFICINA VIRTUAL DE CATASTRO Una Estrategia conjunta: GOBERNACIÓN DE ANTIOQUIA -EDATEL Departamento Administrativo de Planeación DONDE QUEDA ANTIOQUIA? MARCO LEGAL 1. El departamento de Antioquia

Más detalles

Balance de la IDEBarcelona y desarrollo de las IDE locales

Balance de la IDEBarcelona y desarrollo de las IDE locales Balance de la IDEBarcelona y desarrollo de las IDE locales Josefina Sáez Burgaya Oficina Técnica de Cartografía y SIG Local Área de Territorio y Sostenibilidad Diputación de Barcelona JIIDE 2012 Madrid

Más detalles

Sistema de Geocodificación Libre: Callejero Digital de Andalucía.

Sistema de Geocodificación Libre: Callejero Digital de Andalucía. III JORNADAS DE SIG LIBRE Sistema de Geocodificación Libre: Callejero Digital de Andalucía. Carmen Guerrero de Mier (1), Jesús Jurado Estévez (2), y, Jesús M. Rodríguez Leal (3), Álvaro Zabala Ordoñez

Más detalles

Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE

Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE V Jornadas Técnicas de la IDE de España (JIDEE2008) Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE J. Nogueras 1, J. Barrera 1, A.F. Rodríguez 2, R. Recio 1 y

Más detalles

patrimoniogalego.net, una experiencia de catalogación social del patrimonio cultural

patrimoniogalego.net, una experiencia de catalogación social del patrimonio cultural patrimoniogalego.net, una experiencia de catalogación social del patrimonio cultural La creación de un nodo IDE a partir del aprovechamiento de la componente geográfica de los datos recopilados por voluntarios

Más detalles

Introducción al manejo de Nodos IDE y SIG Institucionales

Introducción al manejo de Nodos IDE y SIG Institucionales Hacia una definición de las IDE Introducción al manejo de Nodos IDE y SIG Institucionales Cuando nos introducimos en el campo de las Infraestructuras de Datos Espaciales (IDE) nos encontramos con varias

Más detalles

Sistema de Información Geográfica de Apoyo al Banco de Proyecto de Inversión Pública

Sistema de Información Geográfica de Apoyo al Banco de Proyecto de Inversión Pública Sistema de Información Geográfica de Apoyo al Banco de Proyecto de Inversión Pública E. Bal 1, J. Vásquez 2 1 Dirección de Programación de Inversiones, Departamento Banco de Proyectos Ministerio de Economía

Más detalles

SIG.URBANISMO Sevilla. Francisco López Larrínaga Director S.I.G.

SIG.URBANISMO Sevilla. Francisco López Larrínaga Director S.I.G. SIG.URBANISMO Francisco López Larrínaga Director S.I.G. SIG.URBANISM O Los primeros pasos del SIG Comienza la andadura en 1.995 con la cartografía digital y una primera iniciativa que no llega a tener

Más detalles

Matriz Comparativa de Soluciones para el Desarrollo de Sistemas de Información Geográfica (SIG).

Matriz Comparativa de Soluciones para el Desarrollo de Sistemas de Información Geográfica (SIG). Matriz Comparativa de Soluciones para el Desarrollo de Sistemas de Información Geográfica (SIG). Introducción Somos Ingeniería, Datos y Tecnología, C.A. (IDyT, C.A.), una empresa consultora conformada

Más detalles

Servicios Web con funcionalidad Geográfica como herramientas para el análisis y generación de información estratégica en las organizaciones.

Servicios Web con funcionalidad Geográfica como herramientas para el análisis y generación de información estratégica en las organizaciones. III JORNADAS DE SIG LIBRE Servicios Web con funcionalidad Geográfica como herramientas para el análisis y generación de información estratégica en las organizaciones. Millares Roó (1), José Antonio y Antonio

Más detalles

*Keywords: Open GIS, spatial data infrastructures, public participation GIS, Globalization,

*Keywords: Open GIS, spatial data infrastructures, public participation GIS, Globalization, *Type of submission: Regular *Preferred type of presentation: Paper *Title: gvsig: Soluciones Open Source en las tecnologías espaciales *First author's name: Alvaro *First author's surname: Anguix Others

Más detalles

1 Escuela Politécnica del Ejército, Ecuador, mauroqs@gmail.com 2 Escuela Politécnica del Ejército, Ecuador, alejosbr@hotmail.com

1 Escuela Politécnica del Ejército, Ecuador, mauroqs@gmail.com 2 Escuela Politécnica del Ejército, Ecuador, alejosbr@hotmail.com ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN WEB ACADÉMICO-ADMINISTRATIVA PARA EL COLEGIO MARÍA DE NAZARET, MEDIANTE EL USO DE TECNOLOGÍAS SOFTWARE LIBRE Mauricio Quilachamín Simbaña, Alejandro

Más detalles

Infraestructuras de Datos Espaciales: una aplicación al contexto de los Servicios Basados en la Localización (SBL)

Infraestructuras de Datos Espaciales: una aplicación al contexto de los Servicios Basados en la Localización (SBL) Advanced Information Systems Laboratory Infraestructuras de Datos Espaciales: una aplicación al contexto de los Servicios Basados en la Localización (SBL) Pedro J. Álvarez http://iaaa.cps.unizar.es Department

Más detalles

WMS de la Dirección General del Catastro

WMS de la Dirección General del Catastro WMS de la Dirección General del Catastro José Miguel Olivares García 1 Luis Ignacio Virgós Soriano 2 Dirección General del Catastro (España) jmiguel.olivares@catastro.meh.es, 1 Dirección General del Catastro

Más detalles

ArcGIS. Catálogo de cursos

ArcGIS. Catálogo de cursos ArcGIS Catálogo de cursos 2015 ArcGIS Desktop ArcGIS Desktop ArcGIS 1: Introduction to GIS (10.2)... 2 ArcGIS 2: Essential Workflows (10.2)... 3 ArcGIS 3: Performing Analysis (10.2)... 3 Building Geodatabases

Más detalles

IV Jornadas Técnicas de la IDE de España (JIDEE 07)

IV Jornadas Técnicas de la IDE de España (JIDEE 07) IV Jornadas Técnicas de la IDE de España (JIDEE 07) La interoperabilidad geográfica como horizonte para la Diputación de Pontevedra. Implantación de GEOPISTA [Autor 1:]Rafael Llano de la Concha, Diputación

Más detalles

Módulo 4. GIS Middleware. Servidores de Mapas (GeoServer)

Módulo 4. GIS Middleware. Servidores de Mapas (GeoServer) Curso en Interoperatividad y GIS. GPIP Módulo 4. GIS Middleware. Servidores de Mapas (GeoServer) Docente: Horacio Castellaro. Instituto Geográfico Nacional castellaro@gmail.com Institución Patrocinadora

Más detalles

Catálogo GIS como herramienta para la gestión y publicación de cartografía.

Catálogo GIS como herramienta para la gestión y publicación de cartografía. Catálogo GIS como herramienta para la gestión y publicación de cartografía. Alejandro Lamas Pérez, Francisco Xavier Sotelo Rúa, Jorge Tourís Otero. Sixtema Área Central 25 J, 15707 Santiago de Compostela

Más detalles

Portal de Coordinación de Canalizaciones Subterráneas.

Portal de Coordinación de Canalizaciones Subterráneas. VIII JORNADAS DE SIG LIBRE Portal de Coordinación de Canalizaciones Subterráneas. J.L. Cardoso Santos (1), Iván Pérez Gómez (1) y Roberto Urío Andueza (1) (1) Área GeoWeb, Departamento de Sistemas de Información

Más detalles

Programa GeoSUR Diseño de Sistemas y Arquitectura

Programa GeoSUR Diseño de Sistemas y Arquitectura Programa GeoSUR Diseño de Sistemas y Arquitectura Título Autores Arquitectura de los sistemas asociados al Programa GeoSUR Michelle Anthony. USGS Eric van Praag, CAF Fecha 1 de julio de 2008 Tema Tipo

Más detalles

CURSO. Software a usar: Quantum GIS Fecha: Junio 24-27, 2014 Instructor: Ing. Leonardo Ruiz Lugar: Guadalajara Duración: 40 horas INVERSION: TEMARIO

CURSO. Software a usar: Quantum GIS Fecha: Junio 24-27, 2014 Instructor: Ing. Leonardo Ruiz Lugar: Guadalajara Duración: 40 horas INVERSION: TEMARIO CURSO SISTEMAS DE INFORMACIÓ F N GEOGRÁFICA USANDO SOFTWARE E LIBRE CON N QGIS Software a usar: Quantum GIS Fecha: Junio 24-27, 2014 Instructor: Ing. Leonardo Ruiz Lugar: Guadalajara Duración: 40 horas

Más detalles

El proyecto IDERioja. Infraestructura de Datos Espaciales. La Rioja. Información general. www.iderioja.org www.larioja.org

El proyecto IDERioja. Infraestructura de Datos Espaciales. La Rioja. Información general. www.iderioja.org www.larioja.org El proyecto IDERioja Infraestructura de Datos Espaciales. La Rioja Información general www.iderioja.org www.larioja.org versión E1.0 - Junio 2005 Edición y Realización: Sección de SIG y Cartografía (Gobierno

Más detalles

IDE y Tecnología a del Open Geospatial Consortium (OGC) Dr. Ignacio Guerrero Andes GeoConsulting LLC Huntsville, Alabama, USA

IDE y Tecnología a del Open Geospatial Consortium (OGC) Dr. Ignacio Guerrero Andes GeoConsulting LLC Huntsville, Alabama, USA IDE y Tecnología a del Open Geospatial Consortium (OGC) Dr. Ignacio Guerrero Andes GeoConsulting LLC Huntsville, Alabama, USA Participación n de Ignacio Guerrero en el Open Geospatial Consortium (OGC)

Más detalles

Estándares geoespaciales dentro de la plataforma ArcGIS

Estándares geoespaciales dentro de la plataforma ArcGIS Estándares geoespaciales dentro de la plataforma ArcGIS Leonardo Espinosa Camilo Pedraza Farías Agenda La Plataforma ArcGIS Iniciativas de Interoperabilidad Entidades Creadoras de Estándares Estándares

Más detalles

Desarrollo de Sistema de Información Geográfico para la Gestión de Catastro Urbano en Gobiernos Locales de Perú. Marino Carhuapoma Hilario

Desarrollo de Sistema de Información Geográfico para la Gestión de Catastro Urbano en Gobiernos Locales de Perú. Marino Carhuapoma Hilario Desarrollo de Sistema de Información Geográfico para la Gestión de Catastro Urbano en Gobiernos Locales de Perú. Marino Carhuapoma Hilario Msc. En Ingeniería de Catastro mcarhuapoma@gmail.com www.geomatica.ideasg.org

Más detalles

Adaptaciones de Geonetwork para la construcción de IDE sectoriales.

Adaptaciones de Geonetwork para la construcción de IDE sectoriales. I JORNADAS DE SIG LIBRE Adaptaciones de Geonetwork para la construcción de IDE sectoriales. (1) Victor Pascual Ayats (1) Institut Cartogràfic de Catalunya Centre de suport IDEC (Infraestructura de Dades

Más detalles

ArcGIS. for Server. Comprendiendo nuestro mundo. Tel: (506) 2280-5479 info@geotecnologias.com www.geotecnologias.com

ArcGIS. for Server. Comprendiendo nuestro mundo. Tel: (506) 2280-5479 info@geotecnologias.com www.geotecnologias.com ArcGIS for Server Comprendiendo nuestro mundo ArcGIS for server. crear, distribuir y gestionar servicios SIG COMPATIBILIDAD PARA MUCHOS TIPOS DE APLICACIONES Puede usar ArcGIS for server para crear servicios

Más detalles

RESUMEN EJECUTIVO III REUNIÓN ANUAL DEL COMITÉ PERMANENTE SOBRE EL CATASTRO EN IBEROAMERICA, CPCI CARTAGENA DE INDIAS NOVIEMBRE DE 2009

RESUMEN EJECUTIVO III REUNIÓN ANUAL DEL COMITÉ PERMANENTE SOBRE EL CATASTRO EN IBEROAMERICA, CPCI CARTAGENA DE INDIAS NOVIEMBRE DE 2009 RESUMEN EJECUTIVO III REUNIÓN ANUAL DEL COMITÉ PERMANENTE SOBRE EL CATASTRO EN IBEROAMERICA, CPCI CARTAGENA DE INDIAS NOVIEMBRE DE 2009 1. INTERRELACIÓN CATASTRO REGISTRO 1.1. La Relación del Catastro

Más detalles

Pliego técnico Datos Geoespaciales, Servicios WEB y Spatial Warehouse

Pliego técnico Datos Geoespaciales, Servicios WEB y Spatial Warehouse Pliego técnico Datos Geoespaciales, Servicios WEB y Spatial Warehouse Introducción 1 Introducción... 1 1.1 Objetivos... 1 2 Descripción de la Solución... 1 2.1 Componentes del Sistema... 1 2.1.1 Almacén

Más detalles

Introducción a los servicios OpenGIS (o deshaciendo una divertida maraña de siglas ;-))

Introducción a los servicios OpenGIS (o deshaciendo una divertida maraña de siglas ;-)) (o deshaciendo una divertida maraña de siglas ;-)) Grupo de Programadores y Usuarios de Linux Grupo de Ingeniería Cartográfica de la Escuela de Ingenieros de Caminos, Canales y Puertos IX Jornadas sobre

Más detalles

PLATAFORMA SaaS PARA IMPLEMENTACIÓN IDE Provincia de Santiago del Estero. Santiago del Estero, 1 de Agosto de 2014

PLATAFORMA SaaS PARA IMPLEMENTACIÓN IDE Provincia de Santiago del Estero. Santiago del Estero, 1 de Agosto de 2014 PLATAFORMA SaaS PARA IMPLEMENTACIÓN IDE Provincia de Santiago del Estero Santiago del Estero, 1 de Agosto de 2014 > AGENDA Qué es la Plataforma Saas IDE de ARSAT? Ventajas Arquitectura Características

Más detalles

DESARROLLO DE SISTEMA DE INFORMACIÓN GEOGRÁFICA SOBRE PLATAFORMA WEB

DESARROLLO DE SISTEMA DE INFORMACIÓN GEOGRÁFICA SOBRE PLATAFORMA WEB Inmobiliaria Nueva Vía S.A. (INVIA) Phillips 84, Oficina 65, Piso 6 Santiago Centro / Chile e-mail: leo.corvalan@invia.cl LICITACIÓN PÚBLICA DESARROLLO DE SISTEMA DE INFORMACIÓN GEOGRÁFICA Parte II. Bases

Más detalles

Capítulo 1 Introducción

Capítulo 1 Introducción Capítulo 1 Introducción Dentro de los muchos campos que abarca la universidad para la investigación científica, se encuentra el de los Sistemas de Información Geográfica (SIG). Para ello, cuenta con el

Más detalles

Del SIG de escritorio al entorno clienteservidor con Web Processing Service

Del SIG de escritorio al entorno clienteservidor con Web Processing Service Del SIG de escritorio al entorno clienteservidor con Web Processing Service J. Masó 1, Xavier Pons 2,1 1 Centre de Recerca Ecològica i Aplicacions Forestals (CREAF) Universitat Autònoma de Barcelona (UAB)

Más detalles

CREACIÓN DE UNA APLICACIÓN WEB PARA GEOLOCALIZAR BASES DE DATOS USANDO TECNOLOGÍAS OPEN SOURCE. Autor: Jorge López Pérez

CREACIÓN DE UNA APLICACIÓN WEB PARA GEOLOCALIZAR BASES DE DATOS USANDO TECNOLOGÍAS OPEN SOURCE. Autor: Jorge López Pérez CREACIÓN DE UNA APLICACIÓN WEB PARA GEOLOCALIZAR BASES DE DATOS USANDO TECNOLOGÍAS OPEN SOURCE Autor: Jorge López Pérez Tutores: Laura Sala i Martí (LIGIT) César Martínez Izquierdo (ETC/SIA) 16 de Marzo

Más detalles

Lope Lorenzo Martínez. Lcdo. en Geografía lope.lorenzo@gmail.com GEODATABASE

Lope Lorenzo Martínez. Lcdo. en Geografía lope.lorenzo@gmail.com GEODATABASE Lope Lorenzo Martínez. Lcdo. en Geografía lope.lorenzo@gmail.com GEODATABASE ESTRUCTURA PARTE TEÓRICA PARTE PRÁCTICA PARTE TEÓRICA 1- MODELOS DE DATOS EN LOS S.I.G. 2- QUE ES UNA GDB 3- VENTAJAS E INCONVENIENTES

Más detalles

Sociedade para o Desenvolvemento Comarcal de Galicia. WorkShop SIGNII. Santiago de Compostela, 9 de Mayo de 2007

Sociedade para o Desenvolvemento Comarcal de Galicia. WorkShop SIGNII. Santiago de Compostela, 9 de Mayo de 2007 Sociedade para o Desenvolvemento Comarcal de Galicia WorkShop SIGNII. Santiago de Compostela, 9 de Mayo de 2007 Qué quiere el usuario? Componentes de un Portal WEB Ver un mapa Obtener una capa de información

Más detalles

DIRECCIÓN DE EVALUACIÓN, CONTROL Y DIFUSIÓN DE LA INFORMACIÓN - (DECDI)

DIRECCIÓN DE EVALUACIÓN, CONTROL Y DIFUSIÓN DE LA INFORMACIÓN - (DECDI) DIRECCIÓN DE EVALUACIÓN, CONTROL Y DIFUSIÓN DE LA INFORMACIÓN - (DECDI) 1 CONCEPTOS TEÓRICOS NORMAS ISO TC211: FAMILIA ISO 19100 Ing. Sylvia Huilcamaigua NORMATIVA Es el soporte de una Infraestructura

Más detalles

PUESTA EN SITUACIÓN. Pagina 2 CASO DE GESTIÓN (UVA)

PUESTA EN SITUACIÓN. Pagina 2 CASO DE GESTIÓN (UVA) PUESTA EN SITUACIÓN Una importante administración pública desea desarrollar una plataforma online para gestionar información geoespacial vía web dentro de su intranet. La información geoespacial que han

Más detalles

S I T A R. Sistema de Información Territorial de Aragón. Primeros pasos hacia una Infraestructura de Datos Espaciales

S I T A R. Sistema de Información Territorial de Aragón. Primeros pasos hacia una Infraestructura de Datos Espaciales S I T A R Sistema de Información Territorial de Aragón Primeros pasos hacia una Infraestructura de Datos Espaciales Los comienzos Septiembre 2003: Concurso: Servidor corporativo de cartografía digital

Más detalles

Infraestructuras de Datos Espaciales:

Infraestructuras de Datos Espaciales: Infraestructuras de Datos Espaciales: De la economía tribal al mercado global Barcelona, 12 Febrero 2003 Estructura Presentación: * Definición de términos * Qué es una IDE * Cómo funciona. Estándares *

Más detalles

http://www.idesf.santafe.gov.ar

http://www.idesf.santafe.gov.ar http://www.idesf.santafe.gov.ar Infraestructura de Datos Espaciales de Santa Fe: desarrollos y prototipos Ing. Pedro Arriondo Ing. Eric Retamosa 30 de septiembre de 2009 TEMARIO Primer versión del GeoPortal

Más detalles

CartoBCN: Portal web de Descargas de Cartografía del Ayuntamiento de Barcelona

CartoBCN: Portal web de Descargas de Cartografía del Ayuntamiento de Barcelona CartoBCN: Portal web de Descargas de Cartografía del Ayuntamiento de Barcelona Miguel Ángel Bolívar Leyva Informació de Base i Cartografia Institut Municipal d Informàtica Ajuntament de Barcelona Av. Diagonal,

Más detalles

Software Libre para alcanzar la colaboración en un SIG corporativo- El caso de la Confederación Hidrográfica del Duero

Software Libre para alcanzar la colaboración en un SIG corporativo- El caso de la Confederación Hidrográfica del Duero III JORNADAS DE SIG LIBRE Software Libre para alcanzar la colaboración en un SIG corporativo- El caso de la Confederación Hidrográfica del Duero Javier Fernández Pereira. (1), Francisco Vega González (2),

Más detalles

Los Proyectos y Servicios Web de Información Geográfica del MAPA

Los Proyectos y Servicios Web de Información Geográfica del MAPA Reunión del GT de la IDEE 14 de Febrero de 2008 Los Proyectos y Servicios Web de del MAPA Reunión del GT de la IDEE 14 de Febrero de 2008 1.- Situación de Partida 2.- SIGMAPA 3.- GeoPortal del MAPA 1.-

Más detalles

Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE

Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE Desarrollo de un catálogo de servicios compatible con las normas de ejecución de INSPIRE J. Nogueras Iso 1, J. Barrera 1, A.F. Rodríguez 2, R. Recio 1 y Christian Laborda 3. 1 Depto. de Informática e Ingeniería

Más detalles

Estándares aplicables a las IDE

Estándares aplicables a las IDE Unidad V: Estándares aplicables a las IDE Ricardo Mansilla Técnico del Servicio Geográfico Coordinador IDE Instituto Geográfico Nacional Por quéestándares? Conjunto de datos disponible Conjunto de datos

Más detalles

MASTER EN GEOTECNOLOGÍAS CARTOGRÁFICAS EN INGENIERÍA Y ARQUITECTURA PROYECTO FIN DE MASTER. Junio 2010. Manuel Gallego Priego

MASTER EN GEOTECNOLOGÍAS CARTOGRÁFICAS EN INGENIERÍA Y ARQUITECTURA PROYECTO FIN DE MASTER. Junio 2010. Manuel Gallego Priego 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

Más detalles

ANTECEDENTES RED RURAL NACIONAL

ANTECEDENTES RED RURAL NACIONAL Inicio 1. ANTECEDENTES RED RURAL NACIONAL 2. OBJETIVOS 3. PARTICIPANTES INICIO 4. EJES DEL PROYECTO 5. ACTUACIONES SOFTWARE Y FORMACIÓN INVENTARIO Y MODELO DE DATOS INFRAESTRUCTURA DE RED IDE - RURAL DESARRO

Más detalles

Catálogo de Datos y Simbología IDET

Catálogo de Datos y Simbología IDET Catálogo de Datos y Simbología IDET "Taller de Uso de Simbología IDET en ArcGIS, QGIS y gvsig " Roberto Jesús Dip Eugenia García Posse María Florencia Olivera Objetivo Definir el conjunto de datos geoespaciales

Más detalles

XIII CONFERENCIA IBEROAMERICANA EN SISTEMAS DE INFORMACIÓN GEOGRÁFICA (XIII CONFIBSIG)

XIII CONFERENCIA IBEROAMERICANA EN SISTEMAS DE INFORMACIÓN GEOGRÁFICA (XIII CONFIBSIG) Geografía y Sistemas de Información Geográfica (GEOSIG). Revista digital del Grupo de Estudios sobre Geografía y Análisis Espacial con Sistemas de Información Geográfica (GESIG). Programa de Estudios Geográficos

Más detalles

Servicios de mapas de la Dirección General del Catastro. Dirección General del Catastro

Servicios de mapas de la Dirección General del Catastro. Dirección General del Catastro Servicios de mapas de la Dirección General del Catastro Luis Ignacio Virgós Soriano Dirección General del Catastro Luis.Virgos@catastro.meh.es El génesis En un principio, Catastro mantenía a los planos

Más detalles

qgis intensivo Nivel iniciación y nivel intermedio 90 horas FORMACIÓN

qgis intensivo Nivel iniciación y nivel intermedio 90 horas FORMACIÓN qgis es un sistema de información geográfica libre y de código abierto (SIN COSTES DE LICENCIA) qgis intensivo Nivel iniciación y nivel intermedio FORMACIÓN 90 horas /formación formación específica adaptada

Más detalles

Infraestructura de Datos Espaciales, un instrumento del egob para el intercambio de la Información Geográfica

Infraestructura de Datos Espaciales, un instrumento del egob para el intercambio de la Información Geográfica Infraestructura de Datos Espaciales, un instrumento del egob para el intercambio de la Información Geográfica 30 de noviembre, 2010 Cristina Zerpa Yuri Resnichenko Fabricio Álvarez Aníbal Pacheco IDE conceptos

Más detalles

PARTICIPACIÓN DE LA DIRECCIÓN GENERAL DEL CATASTRO EN EL PROGRAMA URBANISMO EN RED

PARTICIPACIÓN DE LA DIRECCIÓN GENERAL DEL CATASTRO EN EL PROGRAMA URBANISMO EN RED Madrid, febrero marzo 2007 PARTICIPACIÓN DE LA DIRECCIÓN GENERAL DEL CATASTRO EN EL PROGRAMA URBANISMO EN RED 1.- NECESIDAD DE INFORMACIÓN DEL PLANEAMIENTO URBANÍSTICO PARA LA DIRECCIÓN GENERAL DEL CATASTRO.

Más detalles