UNIVERSIDAD TÉCNICA PARTICULAR DE...

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

ÁREA TÉCNICA

TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y

COMPUTACIÓN

Visualización de Información Geográfica usando Geosparql. Piloto sobre

datos de proyecto SmartLand

TRABAJO DE TITULACIÓN

AUTOR: Torres Guarnizo, Charbel Alexander

DIRECTOR: Piedra Pullaguari, Nelson Oswaldo, Ing.

LOJA – ECUADOR

2016

Esta versión digital, ha sido acreditada bajo la licencia Creative Commons 4.0, CC BY-NY-SA: Reconocimiento-No comercial-Compartir igual; la cual permite copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al ser divulgada. http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es

Septiembre, 2016

http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es

ii

APROBACIÓN DEL DIRECTOR DEL TRABAJO DE TITULACIÓN

Ing.

Nelson Oswaldo Piedra Pullaguari.

DOCENTE DE LA TITULACIÓN

De mi consideración:

El presente trabajo de titulación: Visualización de Información Geográfica usando

Geosparql. Piloto sobre datos de proyecto SmartLand realizado por Torres Guarnizo

Charbel Alexander, ha sido orientado y revisado durante su ejecución, por cuanto se

aprueba la presentación del mismo.

Loja, junio del 2016

f)……………….

iii

DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS

“Yo Torres Guarnizo Charbel Alexander declaro ser autor (a) del presente trabajo de

titulación: Visualización de Información Geográfica usando Geosparql. Piloto sobre datos de

proyecto SmartLand, de la Titulación Sistemas Informáticos y Computación, siendo Nelson

Oswaldo Piedra Pullaguari director (a) del presente trabajo; y eximo expresamente a la

Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos

o acciones legales. Además certifico que las ideas, conceptos, procedimientos y resultados

vertidos en el presente trabajo investigativo, son de mi exclusiva responsabilidad.

Adicionalmente declaro conocer y aceptar la disposición del Art. 88 del Estatuto Orgánico de

la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice:

“Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones,

trabajos científicos o técnicos y tesis de grado o trabajos de titulación que se realicen con el

apoyo financiero, académico o institucional (operativo) de la Universidad”

f. ..............................................................

Autor Torres Guarnizo Charbel Alexander

Cédula 1104890973

iv

DEDICATORIA

El presente trabajo quiero dedicarlo a mi esposa Jessica Briceño, a mi hijo Charbel Yael, a

mis padres Charbel Torres y Georgia Guarnizo a mis hermanas Diana y Sandra, quien

siempre han sido pilar fundamental en mi vida, apoyándome a lo largo de mi formación

personal y profesional, con sus consejos, paciencia, experiencias y sobre todo con su amor

incondicional.

v

AGRADECIMIENTO

El presente trabajo de fin de titulación primeramente quiero agradecer a Dios por

bendecirme y llenarme de gloria para llegar a donde estoy, por permitirme hacer realidad

este sueño tan anhelado.

A la Universidad Técnica Particular de Loja por darme la acogida en sus instalaciones,

dándome la oportunidad de estudiar y ser un profesional.

A mi director de trabajo de fin de titulación, por su esfuerzo y dedicación, quien con sus

conocimientos, experiencia, paciencia y motivación, logró en mí formar un profesional y ante

todo una persona, brindándome el apoyo necesario y me ha sabido guiar en el desarrollo de

este proyecto.

Quiero agradecer a mis docentes a lo largo de la carrera universitaria, quienes aportaron a

mi formación, con sus experiencias, anécdotas y conocimientos. Haciendo una mención

especial a la Ing. Elizabeth Cadme, quien fue un pilar fundamental en el desarrollo de este

trabajo, quien con su paciencia, tiempo, conocimientos supo guiarme por el camino

correcto.

A mis padres quien con su esfuerzo, ayuda y sabiduría financiaron este proyecto que inicie

tiempo atrás, a mis hermanas Diana y Sandra que con su apoyo, consejos insistencia y

perseverancia lograron guiarme.

A mi esposa e hijo quienes han estado siempre ahí con su apoyo incondicional, paciencia y

entendimiento a lo largo de este camino, siendo mi motor, mi motivación.

Finalmente quiero agradecer a mis amigos Mario Correa y Freddy Romero, quien siempre

han estado brindándome su amistad, consejos, apoyo ánimo y compañía, por la

experiencias compartidas a lo largo de nuestra formación personal y quienes me han

permitido más que todo crecer como persona.

A todos ellos gracias y que Dios los bendiga siempre.

vi

INDICE DE CONTENIDOS

1. CAPÍTULO I - ESTADO DEL ARTE .......................................................................................................... 7

1.1. Introducción .................................................................................................................................................... 8

1.2. Antecedentes ................................................................................................................................................... 9

1.2.1. La evolución de la web. ..................................................................................................................... 9

1.3. Linked Data. .................................................................................................................................................. 10

1.3.1. Proceso de datos enlazados (metodologías existentes) ................................................... 11

1.4. Datos Geoespaciales .................................................................................................................................. 11

1.5. RDF Store ....................................................................................................................................................... 12

1.5.1. RDF Store con soporte para Geosparql. .................................................................................. 12

1.6. GeoSparql – Un lenguaje de consulta para datos geográficos en RDF. ................................. 13

1.7. Trabajos Relacionados ............................................................................................................................. 16

1.7.1. Ontologías. ........................................................................................................................................... 16

1.7.2. Herramientas...................................................................................................................................... 17

1.7.3. Metodologías. ..................................................................................................................................... 19

2. Capítulo II – Planteamiento del problema ....................................................................................... 21

3. Capítulo III – DISEÑO DE LA SOLUCIÓN .......................................................................................... 29

3.1. Diseño de Solución ..................................................................................................................................... 30

3.2. Metodología para generar Linked Data con datos espaciales. ................................................. 31

3.3. Arquitectura de aplicaciones. ................................................................................................................ 32

3.3.1. Introducción. ...................................................................................................................................... 32

3.3.2. Definiciones, Acrónimos y Abreviaturas . ............................................................................... 32

3.3.3. Visión General. ................................................................................................................................... 32

3.3.4. Representación de la Arquitectura............................................................................................ 35

3.3.5. Vista de Escenarios - Casos de Uso. ........................................................................................... 36

3.3.6. Vista Lógica. ........................................................................................................................................ 37

3.3.7. Vista Procesos. ................................................................................................................................... 38

3.3.8. Vista Implementación/Desarrollo. ............................................................................................ 40

3.3.9. Vista Física. .......................................................................................................................................... 42

4. Capítulo IV – Desarrollo, Implementación y Pruebas ................................................................. 44

4.1. Desarrollo ...................................................................................................................................................... 45

4.1.1. Identificación, selección y extracción de fuentes de datos. ............................................. 45

4.1.2. Limpieza de Datos. ........................................................................................................................... 53

4.1.3. Modelado. ............................................................................................................................................. 54

4.1.4. Generación de datos RDF de prueba. ....................................................................................... 59

4.1.5. Publicación de los datos en repositorio semántico con soporte para Geosparql. . 64

4.1.6. Consumo y Visualización ............................................................................................................... 67

vii

4.1.7. Consideraciones para extraer información desde un shapefile a rdf bajo el estándar geosparql, utilizando las herramientas propuestas. .......................................................... 71

4.2. Puesta en producción ............................................................................................................................... 72

4.2.1. Puesta en producción de la herramienta para transformar shapefile a Rdf. ........... 72

4.2.2. Puesta a producción del visualizador....................................................................................... 73

4.3. Pruebas ........................................................................................................................................................... 74

4.3.1. Pruebas a la herramienta para extraer datos desde shapefile a RDF. ........................ 75

4.3.2. Pruebas de rendimiento de servidor Parliament triple Store. ....................................... 76

4.3.3. Pruebas a la herramienta de visualización. ........................................................................... 85

5. Análisis de Resultados ............................................................................................................................. 91

5.1. Integración de información de diferentes fuentes de datos ..................................................... 92

5.2. Modelar datos espaciales utilizando datos Geoesparql ............................................................. 95

5.3. Explotar los datos enlazados a través de herramientas de visualización. .......................... 95

CONCLUSIONES ................................................................................................................................................... 99

RECOMENDACIONES ..................................................................................................................................... 101

BIBLIOGRAFÍA .................................................................................................................................................. 102

viii

Índice de figuras

Figura 1. Actividades de la metodología para la generación y publicación de Linked Data ¡Error! Marcador no definido. Figura 2. Architecture for the Ecuadorian Geospatial linked Data repository (Saquicela, Elaboración: Espinoza, Piedra, & Villazón, 2014) ............................................................................................ 31 Figura 3 Vista general Arquitectónica de la solución propuesta ............................................................... 33 Figura 4 Las vista del Modelo “4+1 View”. .......................................................................................................... 35 Figura 5 Vista de casos de uso .................................................................................................................................. 37 Figura 6 Vista Lógica de la herramienta de extracción desde shapefile a RDF .................................... 38 Figura 7 Vista de procesos Herramienta de extracción desde shapefile a RDF ................................... 39 Figura 8 Vista de procesos Aplicación Web – Visualizador de datos geoespaciales .......................... 40 Figura 9 Vista Implementación/Desarrollo – Herramienta Software para generar RDF desde Shapefile – Aplicación Web para visualizar los datos geoespaciales ....................................................... 41 Figura 10 Vista Física – Equipos necesarios para ejecutar las 2 herramientas desarrolladas ...... 42 Figura 11. Shapefile visto desde ARCMAP........................................................................................................... 49 Figura 12. Proceso de transformación de sistemas de coordenadas ....................................................... 49 Figura 13 Estructura del archivo de configuración para .............................................................................. 52 Figura 14. Grafo de Vocabulario Geosparql visualizado en la herramienta Protégé ......................... 55 Figura 15. Propuesta de Ontología basada en GEOSPARQL para Representar en RDF Datos Espaciales ......................................................................................................................................................................... 56 Figura 16 Transformar de Sujeto, predicado y objeto almacenadas en MySQL a RDF bajo el modelo propuesto ......................................................................................................................................................... 62 Figura 17. Grafo de la información generada después de ejecutar la herramienta ........................... 63 Figura 18. Grafo de ejemplo de estructura de shapefile luego de ejecutar el convertidor ............. 63 Figura 19. Diagrama de flujo de datos al momento de transformar de sujeto, predicado y objeto desde la base de datos relacional a rdf ................................................................................................................. 64 Figura 20. Página inicio Parliament Triple Store ............................................................................................. 65 Figura 21. Creación de índices espaciales ........................................................................................................... 65 Figura 22. Subir archivo RDF a Parliament ........................................................................................................ 66 Figura 23. Visualizar los datos en el ENDPOINT de parliament triple store ......................................... 67 Figura 24 Captura de pantalla de la herramienta de visualización de datos geográficos- Visualización de la provincia de AZUAY y Zamora Chinchipe ..................................................................... 68 Figura 25 Lista de objetos disponibles ................................................................................................................. 70 Figura 26. Interfaz para escribir consulta Sparql directamente en la herramienta Parliament Triple Store ...................................................................................................................................................................... 77 Figura 27. Resultados de Consulta Sparql de ..................................................................................................... 78 Figura 28. Resultados de la consulta Geosparql de la prueba 2 – Aeropuertos del cantón Guayaquil .......................................................................................................................................................................... 79 Figura 29. Resultados de la consulta Geosparql de prueba 3 – Cantones de la Provincia de Loja80 Figura 30. Resultado de la Consulta Geosparql - Prueba 4 – Ríos Dobles de la Provincia de Azuay ............................................................................................................................................................................................... 81 Figura 31. Resultados de la ejecución de la consulta – cantones de la provincia de Loja ............... 84 Figura 32. Resultado del visualizador – Prueba de visualizar Puntos geográficos - Aeropuertos de Ecuador ........................................................................................................................................................................ 86 Figura 33. . Resultado del visualizador – Prueba de visualizar un único Punto – Aeropuerto Mariscas Sucre ................................................................................................................................................................ 86 Figura 34 Resultado de visualizador - Prueba de visualizar líneas - Ríos del Ecuador .................... 87 Figura 35 Resultado de visualizador - Prueba de visualizar polígonos – Provincia de Zamora Chinchipe y Azuay. ........................................................................................................................................................ 88

ix

Figura 36. Resultado de visualizador - Prueba de visualizar multi-polígonos – Provincia del Guayas ................................................................................................................................................................................ 88 Figura 37. Resultado de visualizador - Prueba de visualizar resultados de función contains de Geosparql – Aeropuertos de la provincia de Manabi. ..................................................................................... 89 Figura 38. Captura de pantalla de Arcmap - Creación de un mapa nuevo en blanco. ..................... 105 Figura 39. Captura de Pantalla de ARCMAP – Añadir información geográfica desde archivos shape ................................................................................................................................................................................. 106 Figura 40. Propiedades del shapefile - Sistema de coordenadas ............................................................. 107 Figura 41. Ventana de configuración para transformación del sistema de coordenadas ............. 108 Figura 42. Ventana de configuración para exportar shapefile en............................................................ 109 Figura 43 Convertir de Shapefile a Sujeto, Predicado y Objeto ................................................................ 110 Figura 44 Ejecutar la Herramienta desde Netbeans ShapeRDF ............................................................... 111 Figura 45 Herramienta - Formulario de configurar Conexión a Base de datos ................................. 112 Figura 46 Herramienta - Abrir herramienta de Extraer Datos ................................................................ 113 Figura 47 Seleccionar archivo con extensión *.shp para la extracción de datos ............................... 113 Figura 48 Formulario de configurar el número de grupos a crear para la extracción de datos ............................................................................................................................................................................ 114 Figura 49 Formulario para clasificar los diferentes campos en objetos ............................................... 114 Figura 50 Formulario de configurar el identificador de cada uno de los grupos.............................. 115 Figura 51 Formulario para asignar un tipo de objeto geográfico a cada uno de los grupos ........ 116 Figura 52 Configuración de las relaciones entre los diferentes grupos ................................................ 117 Figura 53 Mensaje de finalización la extracción de ....................................................................................... 117 Figura 54 Visualización datos extraídos desde phpMyadmin .................................................................. 118 Figura 55 Diagrama de secuencia del convertidor de shapefile a sql .................................................... 119 Figura 56 Abrir herramienta para añadir equivalencia de metadatos .................................................. 120 Figura 57 Formulario para añadir equivalencia de Metadatos ................................................................ 121 Figura 58 Estructura del archivo donde se encuentran las equivalencias de los metadatos ...... 122 Figura 59 Ejecutar módulo de Limpieza de base de datos ......................................................................... 123 Figura 60 Seleccionar los datos a los que se desea aplicar el proceso de limpieza de datos ....... 124 Figura 61 Ejemplo de resultados luego de ejecutar la limpieza de datos ............................................ 125 Figura 62 Ejecutar Módulo generar vocabulario ............................................................................................ 137 Figura 63 Iniciar módulo para transformar datos de SQL a RDF ............................................................ 138 Figura 64 Seleccionar la tabla que se desea transformar a rdf. ................................................................ 139 Figura 65. Fracción de Archivo rdf ejecutado en el ejemplo anterior ................................................... 139 Figura 66. Instalando Parliament ......................................................................................................................... 141 Figura 67. Progreso de Instalación de Parliament ......................................................................................... 142 Figura 68. Levantando Parliament ....................................................................................................................... 143 Figura 69. Captura Archivo de configuración de parliament .................................................................... 144 Figura 70 Arquitectura de capas de la herramienta ShapeRDF ............................................................... 146 Figura 71 Diseño de la herramienta ShapeRDF .............................................................................................. 147 Figura 72 Diseño de Desarrollo de la .................................................................................................................. 148 Figura 73 Diseño de la base de datos de la herramienta ShapeRDF ...................................................... 148 Figura 74 Archivo de configuración para extracción de grupos Ejemplo parroquias_rurales.shp ............................................................................................................................................................................................. 159 Figura 75 Archivo de configuración de relaciones - Ejemplo parroquias_rurales.shp ................... 160 Figura 76Arquitectura del visualizador de datos ........................................................................................... 161 Figura 77 Vista Física Aplicación Web ................................................................................................................ 162

x

Índice de tablas

Tabla 1. Base de datos con soporte para RDF y SPARQL .................................................................... 12 Tabla 2 Propiedades RIF en rcc8 con equivalente en OGC ........................................................................... 15 Tabla 3 Instituciones Públicas generadoras y/o custodias de información geoespacial en Ecuador que apoyan al catálogo nacional de objetos geográficos ............................................................ 23 Tabla 4 Vista de Casos de Uso .................................................................................................................................. 35 Tabla 5 Vista Lógica ...................................................................................................................................................... 36 Tabla 6 Vista de procesos ........................................................................................................................................... 36 Tabla 7 Vista de implementación ............................................................................................................................ 36 Tabla 8 Vista de Despliegue/Física ........................................................................................................................ 36 Tabla 9 Fuentes de Información Seleccionadas ................................................................................................ 46 Tabla 10 Otras Fuentes de Información Seleccionadas ................................................................................. 47 Tabla 11 Estructura de Tripletas ............................................................................................................................ 50 Tabla 12 Estructura del shapefile correspondiente a canton ..................................................................... 51 Tabla 13. URI base para recursos espaciales ..................................................................................................... 58 Tabla 14. Estructura de uri para identificar una clase ................................................................................... 58 Tabla 15. Estructura de URI para identificar una instancia ......................................................................... 59 Tabla 16 Funciones predefinidas para procesamiento de datos espaciales utilizando consultas geosparql ........................................................................................................................................................................... 69 Tabla 17. Resultados de transformación desde Shapefile a RDF ...................................................... 75 Tabla 18. Resultados de transformación desde Shapefile a RDF ............................................................... 93 Tabla 19. Ventajas y desventajas de utilizar shapefile y RDF bajo el estándar Geosparql .............. 96 Tabla 20 Ejemplo de vocabulario extendido para recurso provincias .................................................. 127 Tabla 21 Ejemplo de vocabulario extendido para recurso Cantón ......................................................... 128 Tabla 22 Ejemplo de vocabulario extendido para recurso Parroquia Rural ..................................... 129

xi

Índice de Apéndices

Apéndice A. Manual de usuario para cambiar el sistema de coordenadas al sistema WGS84 de un shapefile .......................................................................................................................................................................... 105 Apéndice B. Manual de Usuario – Extraer datos desde fuente shapefile a sujeto, predicado y objeto. ............................................................................................................................................................................... 110 Apéndice C. Manual de usuario – Limpieza de datos .................................................................................... 120 Apéndice D. Utilizar vocabulario extendido a la hora de extraer datos ................................................ 126 Apéndice E. Vocabulario Propuesto en RDF ..................................................................................................... 132 Apéndice F. Manual de Usuario – Crear archivo de vocabulario ............................................................. 137 Apéndice G. Manual de usuario para transformar a RDF ............................................................................ 138 Apéndice H Manual de Instalación de Parliament ......................................................................................... 140 Apéndice I. Manual de Desarrollador .................................................................................................................. 145 Apéndice J. Archivos de configuración para extracción de datos ............................................................ 158 Apéndice K. Manual del Programador – Visualizador de Datos ............................................................... 161

1

RESUMEN

El presente trabajo de fin de titulación, se centra en el desarrollo de un prototipo que permita

la integración de datos geoespaciales proveniente de diferentes fuentes de información,

centrándose en la información que se encuentra en formato shapefile, tomando como

mecanismo de integración la web semántica, incorporando las ventajas de ésta a la hora de

trabajar con datos geoespaciales.

Para ello se debe transformar la información en formato RDF, bajo el estándar Geosparql; el

mismo que propone una ontología para la representación de los mismos y una extensión de

lenguaje de consulta sparql para el procesamiento de datos geoespaciales.

Para ello se brinda una serie de herramientas desarrolladas por el autor que permiten

transformar la información almacenada en archivos con extensión shapefile(*.shp) a RDF.

Herramientas que se acoplan a la metodología propuesta en el trabajo Ecuadorian Linked

Data.

Siguiendo con la metodología se desarrolló una herramienta que permite visualizar

información geográfica consultando la información en el endpoint de Parliament Triple Store,

proporcionando una herramienta demo que permite ejecutar consultas geosparql,

procesando datos espaciales.

Palabras clave.- linked data, geosparql, shapefile, geo linked data

2

ABSTRACT

This paper titration end, focuses on the UN Development prototype that enables integration

from different sources of information, geospatial data, focusing on information found in

shapefile format, Integration Mechanism Based Semantic Web, incorporating the advantages

of this a time to work with geospatial data.

This requires transforming information in RDF format, under the Standard Geosparql. Same

proposes an ontology for the representation of Self and an extension of SPARQL query

language for processing geospatial data.

For this, a series of tools developed by the author for transforming the information stored in

files with extension shapefile (*. SHP) RDF is provided. Tools that are coupled to the

methodology proposed in the Ecuadorian Labor Linked Data.

Following the methodology itself developed a tool to visualize Geographic Information

Consulting Information at the endpoint of Parliament Triple store, providing a demonstration

tool that lets you run geosparql Queries, Spatial Data Processing.

Achieving the Integration of spatial information base obtaining a non-relational data with

information represented in RDF under Standard Geosparql, ready to be consumed and

exploited from different tools.

Keywords: linked data geosparql, shapefile, geo linked data.

3

INTRODUCCIÓN

Smart Land es una iniciativa de la Universidad Técnica Particular de Loja - UTPL para

colectar datos, reduciendo redundancia, gestionar y modelar datos e indicadores sociales,

biólogos, ambientales y de infraestructura, con el fin de proponer una gestión innovadora del

territorio. Al escuchar el término Smart Land dentro del proyecto propuesto de la UTPL nos

dice. “Con Smart Land nos referimos a un territorio en el que se usa con intensidad las TICs

con el propósito de mejorar la calidad de vida de los ciudadanos, y de mejorar la gestión del

medio ambiente”. (Smartland, UTPL, 2014).

Dentro de esta iniciativa surge la necesidad de procesar grandes volúmenes de datos,

visualización de información, sistemas de información geográfica, para ello se trata de

involucrar tecnologías de la web Semántica, entre otras, por lo que es importante involucrar

los conceptos y ventajas de ésta dentro de la iniciativa con el fin de traer los beneficios de la

web semántica a este proyecto. Pero en si ¿qué es la web semántica? “Básicamente es un

concepto que propone la inclusión de metadatos semánticos a la web para que pueda ser

comprendida de mejor manera por los agentes informáticos, ya sean navegadores o spiders

de los motores de búsqueda” (Luca, 2011), o como lo define la el Consorcio de la Word

Wide Web que textualmente dice: “es una web extendida, dotada de mayor significado en la

que cualquier usuario en Internet podrá encontrar respuestas a sus preguntas de forma más

rápida y sencilla gracias a una información mejor definida” (W3C), basándonos en las

definiciones se puede definir a la web semántica como aquella información en la web que

utiliza metadatos con el fin de dar un significado semántico a los datos para mejorar los

procesos de búsqueda y recuperación de información (más exacta, más definida y más

precisa).

Para colaborar con la propuesta de la UTPL con el planteamiento del Proyecto Smart Land

sobre los territorios de la Provincia de Zamora Chinchipe, para lograr una gestión inteligente

del mismo utilizando tecnologías de la información especialmente tecnologías de web

semántica, Linked data, para lo cual se propone centrarse en datos geoespaciales

recolectados por los diferentes equipos de investigación, para ello se ha planificado

desarrollar un prototipo que permita visualizar información geográfica, cuyo desarrollo se

detalla a lo largo de este trabajo.

4

JUSTIFICACIÓN

Considerando el incremento en la actualidad de los datos geoespaciales y la cantidad de

información geoespacial recolectada por los investigadores participantes en el proyecto

Smart Land, sumada a la información liberada por las instituciones gubernamentales dentro

de sus propias iniciativas de datos abiertos, además de la necesidad de lograr un

razonamiento espacial con esta información, nace la idea y a la vez la necesidad de contar

con mecanismos que permitan integrar la información y a la vez herramientas que permitan

visualizarla, con todas las ventajas que linked data va a aportar, haciendo de esta

información entendible tanto para la máquina y para el ser humano.

A la hora generar datos enlazados con la información geográfica, se obtiene los beneficios

de la web semántica:

Compartir datos

Enlazar datos a otros datos

Interoperabilidad, permitirá acoplarse a otros datos independientemente de los

formatos en los que estén

Capa de presentación independiente del origen de los datos

Mediante la visualización se pueden encontrar algunas cosas u obtener conocimiento

que no se observa así, simplemente con los datos almacenados en un repositorio si

no que puede ayudar a obtener nuevo conocimiento.

Por estas razones es importante que dentro del proyecto Smart Land se utilice tecnología

semántica, ya que permitirá integrar información y a la vez presentar sus datos mediante

visualizaciones que generen un razonamiento espacial.

5

METODOLOGÍA

Para el desarrollo del proyecto se usó un enfoque evolutivo e incremental. Se inició con la

definición de los objetivos globales y alcance, del proyecto, en esta etapa se identificó la

problemática y los requisitos, a continuación de esto se planteó una propuesta de solución,

se realizó un modelado y diseño de la solución

Posterior a esto se procedió a evaluar la propuesta.

Luego de evaluar la propuesta se procedió a la implementación de la misma bajo los

requerimientos especificados, realizando un refinamiento de solución, para posteriormente

pasar a integrar las herramientas desarrolladas, y finalmente se realizó una evaluación de la

solución en base a lo implementado.

A lo largo del proyecto se llevó a cabo metodologías de gestión de proyectos, metodologías

de desarrollo de software y metodología para la generación de linked data, llevando a la par

estas metodologías, lo que nos ayudó a obtener los resultados esperados.

6

OBJETIVOS

Objetivo General

Construir un prototipo funcional que permita integrar información geoespacial

proveniente de diferentes fuentes de información y visualizar un conjunto de datos

enlazados geoespaciales del proyecto Smart Land e incluir un mecanismo de

procesamiento.

Objetivo Específico

Integrar información geoespacial para generar datos enlazados en un dominio

seleccionado.

Utilizar Geosparql para modelar datos geoespaciales.

Explotar los datos enlazados a través de una herramienta propia de visualización.

Desarrollar una herramienta que ayude a los usuarios a generar razonamiento

espacial.

7

1. CAPÍTULO I - ESTADO DEL ARTE

8

1.1. Introducción

Con el gran incremento de información de la web y con ello el crecimiento de Linked Data

por la necesidad de tener la información enlazada, a la vez los Sistemas de Información

Geografía (SIG) se han convertido en herramientas muy populares para la representación y

razonamiento de datos geográficos (Elmes, 2005).

El incrementó de la cantidad de datos geoespaciales publicados en RDF y Linked Data,

suman a la necesidad inherente de poder publicar dichos datos bajo un estándar con el fin

de poder operar permitiendo tener un razonamiento espacial; En el trabajo titulado

Configuraciones epistémicas y cognitivas en tareas de visualización y razonamiento espacial

nos dice que “Se trata de evaluar los procesos y capacidades de los sujetos para realizar

ciertas tareas que requieren “ver” o “imaginar” mentalmente los objetos geométricos

espaciales, así como relacionar los objetos y realizar determinadas operaciones o

transformaciones geométricas con los mismos” (José A. Cajaraville, 2006), por otro lado

Antonio Morales en su trabajo nos dice que “son técnicas cualitativas de razonamiento y

representación espacial que ofrecen una forma de interacción con los datos espaciales más

intuitiva y cercana a la forma de pensar de las personas”, (Antonio Morales Nicolás, 2010).

Hace algunos años atrás, tenían muchas limitantes las herramientas de esa época, sin

embargo en los últimos años, varios intentos como el modelo de W3C Geo XG1, KML o

GeoJSON2 (Geographic JavaScript Object Notation), entre otros, han proporcionado niveles

de apoyo a los conceptos geoespaciales. De los cuales se generó el estándar OGC

Geosparql el cual apoya la representación y la consulta de datos geoespaciales de la Web

Semántica obteniendo mejores resultados.

Una vez definido el vocabulario que se va trabajar que permita representar los datos y un

lenguaje de consulta para la Web Semántica hay que encontrar un servidor de datos para

RDF con soporte paraa Geosparql, ya que no bastará con un servidor de datos con soporte

únicamente para SPARQL3. Existen varias opciones las cuales se analizará en el apartado

“RDF Store” con soporte para GeoSparql.

Una vez que los datos tengan un formato estándar, el lenguaje de consulta y el servidor de

datos para RDF que permita acceder a dicha información permitiendo operar sobre ella, hay

que pasar a la necesidad inicial que es tener un razonamiento espacial, lo que significa

poder explotar dichos datos. Para ello existen varias herramientas, una de las más potentes

1 http://www.w3.org/2005/Incubator/geo/ 2 http://geojson.org/ 3 http://www.w3.org/TR/rdf-sparql-query/

9

y de licencia Open Source es MAP4RDF la cual brinda una forma de explorar y visualizar

dichos datos entendibles ya para el ser humano.

El propósito de este trabajo es desarrollar una herramienta similar a la anterior pero que

además de brindar los beneficios de MAP4RDF sea un desarrollo propio que permita

controlar todos los aspectos de la visualización de tal manera que se pueda generar un

grado de independencia entre la aplicación y los datos a utilizar, el generar el prototipo

funcional con un subconjunto de información geoespacial disponible: lo que permitirá evaluar

la funcionalidad y aplicabilidad de la herramienta.

1.2. Antecedentes

1.2.1. La evolución de la web.

A lo largo de los años desde los orígenes de la Web, ha venido evolucionando, con la

aparición de nuevas tecnologías, más usuarios conectados a la red y nuevos dispositivos

que permiten acceder a la web. Desde aquel entonces se puede definir 3 etapas o

generaciones claramente establecidas en la evolución de la web que son:

1.2.1.1. Web 1.0.

Es una generación de web estática en la que no se permitía la interacción con el usuario,

únicamente se podía leer el contenido, siendo este limitado ya que solo estaba disponible la

información que el administrador del sitio colocaba. Alrededor de unos 15 años

aproximadamente desde su creación se le da el nombre Web 1.0 conjuntamente cuando

aparece la web 2.0 únicamente para poder diferenciar y comparar estas dos generaciones

de la web.

1.2.1.2. Web 2.0.

La Web 2.0 es la etapa actual en la que está la web, una etapa en la que ya se permite

interactuar a los usuarios, ya sea con el sitio o con otros usuarios a través de distintas

aplicaciones, dando acceso a millones de recursos, independientemente de la posición

geográfica del mismo o el idioma que se use, siendo estos factores sumamente importantes

para el éxito de la web, lo que hace que cada día se incluyan muchos más usuarios.

También como lo menciona la W3C 4 , esto ha originado sus principales problemas:

sobrecarga de información y heterogeneidad de fuentes de información con el consiguiente

problema de interoperabilidad, lo que le da cabida a una nueva generación de la web, la que

se la define como Web Semántica o Web 3.0

4 http://www.w3c.es/

10

1.2.1.3. Web semántica o web 3.0.

Según la W3C define a la web semántica como “Una web extendida, dotada de mayor

significado en la que cualquier usuario en Internet podrá encontrar respuestas a sus

preguntas de forma más rápida y sencilla gracias a una información mejor definida. Al dotar

a la web de más significado y, por lo tanto, de más semántica” (W3C).

Para entender bien el concepto se debe definir bien las operaciones, que se llevarán a cabo

sobre datos existentes, datos bien definidos, para ello la web semántica utiliza RDF,

SPARQL y OWL, los cuales son mecanismos que permiten convertir la web en una

infraestructura global en la que es posible compartir, reutilizar datos y documentos entre

diferentes tipos de usuarios. (W3C)

1.3. Linked Data.

Los datos enlazados son la solución de la web semántica para mantener los datos

vinculados a otros datos o información relacionada, de manera que los usuarios o las

máquinas puedan explorar datos, estos deben estar estructurados para que se puedan

interconectar con otros datos.

Los ordenadores pueden leer automáticamente los datos, permitiendo consultar y conectar

datos de diferentes fuentes de información, a través de las siguientes tecnologías:

HTTP(HyperText Transfer Protocol)

Protocolo de transferencia de hipertexto, siendo uno de los métodos de intercambio de

información en la web, linked data utiliza este método para reutilizar la infraestructura

existente. (Lapuente, 2013)

RDF(Resource Description Framework)

Un modelo estándar para el intercambio de datos en la Web. RDF tiene características que

facilitan la fusión de datos incluso si los esquemas subyacentes difieren, y soporta

específicamente la evolución de esquemas con el tiempo. (Group, 2014)

RDF utiliza tripletas para describir los recursos. Un recurso intermedio (URI) para establecer

la relación entre 2 extremos, siendo el primero necesariamente un recurso (URI) y el

segundo pudiendo ser un recurso o un dato.

URI(Uniform Resource Identifier)

11

Es una cadena de caracteres estructurada para identificar un recurso único dentro de una

red.

Los datos enlazados se basan en 4 principios definidos por (Berners-Lee, 2006)

1. Utilizar URIs para identificar los recursos publicados en la web

2. Aprovechar el HTTP de la URI para que la gente pueda localizar y consultar (es

decir, desreferenciar) estos recursos.

3. Proporcionar información útil acerca del recurso cuando la URI haya sido

desreferenciada.

4. Incluir enlaces a otras URI relacionadas con los datos contenidos en el recurso, de

forma que se potencie el descubrimiento de información en la web.

1.3.1. Proceso de datos enlazados (metodologías existentes)

Para generar y publicar datos enlazados existen diferentes metodologías, cada una de ellas

con su diferente ciclo de vida, a continuación se menciona algunas de ellas:

LOD2

DAtalift

W3C Linked Data cookbook

Luego de analizar cada una de ellas se vio que tienen ciertas limitantes que no va a permitir

que se pueda cumplir a cabalidad el propósito de este trabajo por eso posteriormente se

decidió usar el Ciclo de Vida: Geospatial Linked Data propuesto por (Saquicela, Espinoza,

Piedra, & Villazón, 2014) en su trabajo Ecuadorian Geospatial Linked Data, modelo que se

explicará en un apartado posterior.

1.4. Datos Geoespaciales

Los datos espaciales son objetos o procesos que ocupan el espacio geográfico.

Los datos espaciales dan respuestas a preguntas de localización, en casi cualquier base de

datos se tiene datos espaciales, si se habla de una dirección, o de un país o ciudad, esa

base de datos ya contiene datos espaciales, de aquí la necesidad de tener un razonamiento

espacial.

El Open Geospatial Consortium (OGC) es un consorcio de la industria internacional de las

481 empresas, agencias gubernamentales y universidades que participan en un proceso de

consenso para desarrollar estándares de interfaz de acceso público. Estándares OGC®

apoyan las soluciones interoperables que "geo-Enable" de la web, móvil y localización

12

servicios y corriente-basado de TI” ((OGC), 2012) define la siguiente jerarquía de tipos de

datos espaciales

Point

Linestring

Polygon

MultiPoint

MultiLinestring

MultiPolygon

GeomCollection

1.5. RDF Store

Rdf Store o triplestore comúnmente conocidas, son base de datos construidas

especialmente para almacenar y consultar tripletas, que es lo que utiliza RDF para describir

sus recursos.

Existe un gran sin número de RDF Store, cada una de ellas desarrolladas en distintos

lenguajes de programación y lanzadas bajo diferentes tipos de licencia, dentro de las más

utilizadas están.

Tabla 1. Base de datos con soporte para RDF y SPARQL

Nombre Lenguaje

que se Desarrolló

URL Licencia

OpenLink Virtuoso

C http://virtuoso.openlinksw.com/ GPL v2 o Comercial

Parliament Triple Store

Java, C++ http://parliament.semwebcentral.org/ BSD licence

Sésamo Java http://www.openrdf.org/ BSD-style license

Soprano C++ http://soprano.sourceforge.net/ LGPL v2

BigData Java www.bigdata.com GPL v2

Apache Jena Java Jena.apache.org Apache 2

1.5.1. RDF Store con soporte para Geosparql.

Sin embargo no todas las bases de datos implementaron Geosparql, pero existen algunas

bases de datos que si lo implementaron ya sea en su totalidad o parcialmente, a

continuación un pequeño análisis de éstas:

1.5.1.1. Openlink Virtuoso Universal Server.

13

Virtuoso, es un servidor de datos para RDF nativo disponible en código abierto. Proporciona

carga mediante línea de comandos, una API de conexión, soporte para SPARQL y el

servidor web para realizar consultas SPARQL y la carga de datos a través de HTTP.

Además de esto, un Virtuoso ofrece los puentes para que pueda ser usado con Jena y

sésamo.

Desde la versión 7.1 OpenLink Virtuoso también contiene algunas funciones geoespaciales

y el razonamiento basado en prefijos de proveedores, aunque no es compatible con

Geosparql es utilizable para información espacial..

1.5.1.2. Ontotext OWLIM.

OWLIM tiene una aplicación geoespacial parcial basada en prefijos de proveedores, no es

compatible con Geosparql, pero es suficiente para el uso básico. Ontotext establece que

OWLIM apoyará con las características de Geosparql en la versión 5.7 (actualmente 5.4).

1.5.1.3. Parliament Triple Store.

En la información que proporciona Parliament triple Store5 se encuentra lo siguiente:

Parliament tiene una implementación casi completa de Geosparql utilizando JENA y un

procesador de consultas ARQ modificado.

Parliament apoya Geosparql, la norma recién aprobada OGC para datos semánticos

geoespaciales. Usando su índice geoespacial. Parliament puede responder eficientemente

consultas como "encontrar todos los artículos que se encuentran dentro de la región X"

(Parliament, 2009).

1.6. GeoSparql – Un lenguaje de consulta para datos geográficos en

RDF.

GeoSPARQL es un lenguaje de consulta para RDF de datos geográficos.

En el 2012 la OGC aprobó y publicó la primera versión de OGC GeoSPARQL – a

Geopgraphic Query Language for RDF Data con el propósito de tener un estándar que

apoye la representación y la consulta de datos geoespaciales de la Web Semántica. (Open

Geospatial Consortium, 2012)

5 http://parliament.semwebcentral.org/

14

GeoSPARQL define un vocabulario para representar datos geoespaciales en RDF,

basándose en estándares de la OGC, y a la vez define una extensión de consulta SPARQL

para procesar datos geoespaciales. GeoSPARQL fue diseñado para dar cabida a los

sistemas basados en el razonamiento y sistemas basados en cálculos cuantitativos

espaciales (Open Geospatial Consortium, 2012), en conclusión GeoSPARQL ofrece:

Un vocabulario ontológico para representar información geoespacial en RDF / OWL

mediante:

GML (Geography Markup Language).

Características simples, Tcc8

Una interfaz de consulta que permite utilizar:

o Funciones topológicas para razonamiento cuantitativo

o Conjunto de Reglas Rule Interchange Format(RIF) 6 reglas de inferencia

básicos para la transformación de consulta e interpretación.

Geosparql no define un vocabulario amplio para representar información espacial. En su

lugar, se define un conjunto básico de clases, propiedades y tipos de datos que pueden ser

utilizados para construir patrones de consulta. (Open Geospatial Consortium, 2012)

Relaciones topológicas

Todas las entidades espaciales están inherentemente relacionadas con alguna otra entidad

espacial. Ya sea que dos entidades se intersecan de alguna manera o están se encuentran

a miles de millas de distancia, la relación que comparten puede ser descrita y evaluada.

(Battle & Kolas, 2012)

Se describe un intervalo para la lógica de razonamiento sobre el espacio. Utilizando una

lógica simple que define las funciones, relaciones de expresión y razonamiento sobre

regiones espaciales.

Esta lógica se conoce como Conexión Región Cálculo (RCC).

Un subconjunto de CCR es RCC8, la cual define las ocho funciones dos a dos mutuamente.

Las relaciones que pueden ser utilizados para implicar el resto de las relaciones en RCC.

(Randell, Cui, & Cohn, 1992)

Geosparql también ha implementado Region Coneection Calculus 8 (RCC8), con el fin de

permitir un procesamiento de datos espaciales, en la Tabla 2 Propiedades RIF en rcc8 con

6 http://www.w3.org/TR/rif-overview/

15

equivalente en OGC se muestra la representación gráfica de las propiedades RIF (funciones

para procesamiento de datos geospaciales), con su equivalente en RCC8 al igual que en

OGC.

Tabla 2 Propiedades RIF en rcc8 con equivalente en OGC

Propiedad Representación

Gráfica

Propiedades

en RCC8

Propiedad

en OGC

URI propiedad

en OGC

DC (a,b)

DC disjoint geo:sfdisjoint

~DC (a,b)

¬DC intersects geo:sf-intersects

EC (a,b)

EC touches geo:sftouches

PO (a,b)

PO overlaps geo:sfoverlaps

EQ (a,b)

EQ equals geo:sfequals

TPP (a,b)

TPP within geo:sfwithin

TPPi (b,a)

TPPi contains geo:sfcontains

nTPPi (a,b)

nTPPi contains geo:sfcontains

a

a b

a b

a

b b

b

a

a

b

a

b

b

a b

16

1.7. Trabajos Relacionados

Existen varios trabajos en el área de procesamiento de datos geográficos que de una u otra

forma han aportado para la visualización de este tipo de datos, estos aporte van desde:

ontologías, herramientas para compartir shapfiles, herramientas de visualización de datos y

metodologías para generar linked data espacial, a continuación se mencionan un resumen

de algunos de ellos.

1.7.1. Ontologías.

1.7.1.1. W3C Geo XG.

W3C Geospatial Incubator Group propone la iniciativa de comenzar a abordar las cuestiones

de localización y propiedades geográficas de los recursos para la web de hoy y de mañana,

tomando un paso concreto para actualizar el vocabulario W3C GEO, sentando las bases

para una mayor ontología geoespacial integral, y la formulación de una propuesta de trabajo

del grupo W3C para desarrollar recomendaciones para promover la representación física de

la web ubicación y geografía. (Lieberman, Singh, & Goad, 2007) .

1.7.1.2. LinkedGeoData ontology (lgdo).

LinkedGeoData permite agregar una dimensión espacial a la web de datos / web semántica.

Utiliza la información recopilada por el proyecto OpenStreetMap y la hace disponible como

una base de conocimiento RDF según los principios de Linked Data. Se articula estos datos

con otras bases de conocimiento en la iniciativa Linking Open Data. (Stadler,

LinkedGeoData.org, 2015)

1.7.1.3. GeoNames ontology.

El GeoNames Ontology permite añadir información semántica geoespacial a la palabra Wide

Web. Sobre 8,3 millones de GeoNames topónimos tienen ahora una URL única con el

correspondiente servicio web RDF. Otros servicios describen la relación entre los topónimos.

GeoNames integra datos geográficos como nombres de lugares en varios idiomas, la

elevación, la población y otros de diversas fuentes. Todas las coordenadas lat / long están

en WGS84 (World Geodetic System 1984). Los usuarios pueden editar manualmente,

17

corregir y añadir nuevos nombres utilizando una interfaz de wiki usuario. (Vatant & Wick,

2012)

1.7.1.4. NeoGeo Vocabulary.

El NeoGeo vocabulary se basa en la GML, de características simples, desde el Open

Geospatial Consortium. Geometrías simples se describen (junto con sus coordenadas) de

forma explícita en RDF, y geometrías compuestas se describen como una agregación de

geometrías simples. Este enfoque permite el razonamiento y consulta en estas geometrías,

así como la fabricación bordes compartidos más explícitos. (Salas, et al., 2011)

1.7.2. Herramientas.

1.7.2.1. Herramientas para convertir shapefiles a RDF.

1.7.2.1.1. GEOMETRYtoRDF.

Define un conjunto de RDF para obtener información geométrica (que podría ser en GML o

WKT). El GML y WKT, se manipula con GeoTools (Biblioteca java de código abierto que

proporciona herramientas para datos geoespaciales, con el fin de recuperar la geometría,

puede ser para realizar la transformación de coordenadas si es necesario). Finalmente,

utilizamos Jena (Un Marco para la Web Semántica Java), para generar RDF geoespacial

final. El RDF generado es compatible con el vocabulario WSG84 y Ontología GML. (Vilches-

Blázquez, Manuel, Villazón-Terrazas, Corcho, & Gómez Pérez, 2010)

1.7.2.2. Herramientas de visualización.

1.7.2.2.1. LGD Browser.

El LGD Browser y Editor (disponible en http://browser.linkedgeodata.org), con el fin de

mostrar los beneficios de revelar la información estructurada en Open Street Map, se

desarrolló un navegador basado en facetas y editor para LinkedGeoData. Permite navegar

por el mundo mediante el uso de un mapa intuitivo. Una vez que se selecciona una región,

analiza el navegador las descripciones de los nodos y las formas en esa región y genera

facetas para el filtrado. (Jens Lehmann, 2010)

Si un usuario inicia sesión en la aplicación mediante el uso de sus credenciales de OSM,

los elementos que se muestran directamente se pueden editar en la vista del mapa. Para

ello, el navegador genera una forma dinámica sobre la base de las propiedades existentes.

El formulario también permite añadir propiedades adicionales arbitrarias. En orden para

fomentar la reutilización de las propiedades y los valores de la propiedad, el editor realiza

una búsqueda de escritura anticipada para las propiedades existentes y valores de la

http://browser.linkedgeodata.org/

18

propiedad y los clasifica de acuerdo a la frecuencia de uso. Cuando se realizan cambios,

éstos se almacenan localmente y se propagan a la base de datos principal de OSM

utilizando el API de OSM. (Stadler, Lehmann, Höffner, & Auer, 2012)

1.7.2.2.2. STEVIE.

Es una aplicación desarrollada por el Instituto de Ciencia y Tecnologías de la Web en la

Universidad de Coblenza, que utiliza LinkedGeoData.

STEVIE permite crear y editar puntos de interés (POI) y anotarlos semánticamente. Las

anotaciones utilizan la ontología LinkedGeoData y también están vinculados entre sí a

DBpedia. las anotaciones permitirá emplear técnicas de agrupamiento en STEVIE, que se

utilizan para agrupar conjuntos de objetos similares en el tamaño de pantalla limitado de un

teléfono móvil. La aplicación permite la creación de eventos y, por lo tanto, combina la

información espacial y temporal. Se hace hincapié en que proporciona una interfaz de

usuario intuitiva para navegar esas dos dimensiones. Con el fin de mostrar PDI y

clasificarlos, Stevie utiliza el LinkedGeoData Interfaz REST, ontología y SPARQL endpoint.

(Stadler, Lehmann, Höffner, & Auer, 2012)

1.7.2.2.3. MAP4RDF.

Es un software open source que únicamente necesita ser configurado para usar cualquier

SPARQL endpoint y que proporciona a los usuarios una visualización de datos

georeferenciados y en RDF en un mapa, siendo una herramienta de navegación por facetas

para explorar los datos enriquecidos con información geométrica.

Los aspectos geoespaciales de los datos se pueden modelar usando el modelo de datos del

W3C Geo XG o GeoSPARQL mencionados en su página oficial (Corcho, 2011).

Map4rdf nos permite:

Navegar a través de su interfaz basada en facetas.

Visualizar información geoespacial y geométrica a través del API de google (Google

Maps) u Open Street Maps.

Visualizar información Geométrica (puntos, líneas, polígonos, etc.)

Visualización de datos estadísticos utilizando SCOVO.

Edición y almacenamiento de los datos mostrados en formato de datos RDF.

Filtrado de consultas.

Fácil configuración a través del panel de administración o archivo de configuración.

19

En proyecto Al finalizar el proyecto se aporta con dos herramientas que permiten integrar

información, utilizando herramientas de la web semántica, aplicándolas en un software

propio que está disponible para libre acceso, estas herramientas permiten integrar

información geoespacial proveniente desde shapefile.

1.7.3. Metodologías.

Entre algunas de las metodologías para generar Linked data geoespacial se tiene la

propuesta por Vilches-Blázquez en su trabajo Combinando Linked Data con servicios

geoespaciales, propone un modelo de ciclo de vida incremental iterativo basado en

continuas mejoras y extensiones del Linked Data generado. La referida metodología

contempla las siguientes actividades: (1) especificación, (2) modelado, (3) generación de

RDF, (4) generación de links, (5) publicación y (6) explotación. Cada una de estas

actividades está compuesta de una o más tareas. La muestra una visión general de las

actividades que recoge la metodología propuesta.

Figura 1. Actividades de la metodología para la generación y

publicación de Linked Data

Fuente: (Vilches-Blázquez, Manuel, Villazón-Terrazas, Corcho, & Gómez Pérez, 2010)

20

Actividades de la metodología para la generación y publicación de Linked Data Esta

metodología ha sido aplicada con éxito en la producción de Linked Data para diferentes

organizaciones e iniciativas, tales como: Instituto Geográfico Nacional (GeoLinked Data),

Biblioteca Nacional de España (datos.bne.es3), Agencia Estatal de Meteorología

(AemetLinkedData.es4) y Grupo Prisa (Webenemasuno.es). (Vilches-Blázquez, Sevilla

Sánchez, Villalón, Rodríguez, & Gómez Pérez, 2013)

A la vez Víctor Saquicela en su trabajo Ecuadorian Geospatial Linked Data proponen el

siguiente ciclo de vida.

Selección de las fuentes de datos

Diseño de URIs de recursos geoespaciales

Vocabularios Geoespaciales

Generación de RDF a partir de datos geoespacial

Vinculación de datos geoespaciales

Publicación y explotación

En este capítulo ha permitido analizar el estado de la situación actual del problema que se

desea resolver, se ha realizado una breve introducción a la problemática, en la que

podemos concluir que existe gran información geográfica liberada en la web, y la dificultad

para integrarla.

Se hace una breve introducción a la web semántica, como funciona, ventajas que brindan al

usar esta tecnología y una revisión de las herramientas disponibles.

Se realizó un breve análisis de las herramientas existentes a la hora de trabajar con datos

geoespaciales, este análisis se lo basó en trabajos relacionados al tema y en base a la

experiencia propia de los desarrolladores de los mismos. Determinando que utilizar Linked

data como mecanismo para integrar información geográfica es un mecanismo viable.

21

2. CAPÍTULO II – PLANTEAMIENTO DEL PROBLEMA

22

La información en la web ha incrementado, al igual la cantidad de datos espaciales

publicados en ella. Millones de usuarios de internet están subiendo información a la misma,

ya sea en portales web, redes sociales etc. Un buen porcentaje de esta información es

información geográfica.

La iniciativa de distintos gobiernos e instituciones de diferentes países han tomado la

iniciativa de tener datos abiertos (Open Data). Básicamente consiste en poner a disposición

a la sociedad los datos que gestiona la administración pública. Esta iniciativa ha logrado que

las instituciones liberen gran cantidad de información.

Países como Reino Unido, España, México entre otros, a la vez algunas universidades

como la Universidad de Arizona (Estados), la universidad de Granada (España) han

adoptado esta iniciativa creando ya repositorios abiertos.

El gobierno ecuatoriano se ha sumado a esta iniciativa, liberando gran cantidad de

información. Dentro de esta información hay grandes volúmenes de datos geográficos que

se han liberado.

Existiendo gran diversidad de información geográfica, disponible de diferentes fuentes, sin

embargo en algunos casos, esta se encuentra en diferentes formatos, usan distintos

sistemas de coordenadas, la información se encuentra dispersa y no está relacionada.

El gobierno ecuatoriano a través de la Secretaria Nacional de Planificación y Desarrollo

(SEMPLADES), ha tenido la iniciativa de organizar dicha información con el fin de

estandarizar el contenido, estructura y comportamiento de objetos, atributos y dominios, con

el fin de facilitar su manejo e intercambio de información, bajo las Políticas Nacionales de

Información Geoespacial7 en la que indica “que toda información geoespacial debe estar

estructurada de acuerdo al catálogo de objetos nacional vigente” y que “las instituciones

productoras y/o custodias de información geoespacial deben contar con una base de datos

geográfica estructurada, basada en el catálogo de objetos nacional vigente” a través del

catálogo nacional de objetos geográficos, actualmente está vigente la versión 2.0 publicada

por la Secretaría Nacional de Planificación y Desarrollo (SENPLADES) en el 2013.

Las instituciones generadoras y/o custodias de información geoespacial que apoyan al

catálogo nacional de objetos geográficos son:

7 https://ipgh.org/Secciones-Nacionales/ECUADOR/Files/Politic-Nales_Info-Geoesp.pdf

23

Tabla 3 Instituciones Públicas generadoras y/o custodias de información geoespacial en

Ecuador que apoyan al catálogo nacional de objetos geográficos

Abreviatura Institución Portal Oficial

INAMHI Instituto Nacional de

Meteorología e

Hidrología

http://www.serviciometeorologico.gob.ec/

SENAGUA Secretaria Nacional de

Agua

http://www.agua.gob.ec/

IGEPN Instituto Geofísico http://www.igepn.edu.ec/

MAGAP-CGSIN Ministerio de

Agricultura, Ganadería,

Acuacultura y Pesca

http://www.agricultura.gob.ec/

MAE Ministerio del Ambiente

Ecuador

http://www.ambiente.gob.ec/

ARCOM Agencia de Regulación

y Control Minero

http://www.controlminero.gob.ec/

CONELEC Consejo Nacional de

Electricidad

http://www.conelec.gob.ec/

CNT Corporación Nacional

de Telecomunicaciones

https://www.cnt.gob.ec/

EMASEO Empresa Metropolitana

de Aseo de Quito

http://www.emaseo.gob.ec/

EPMAPS Empresa Pública

Metropolitana de Agua

Potable de Quito

http://www.aguaquito.gob.ec/

IGM Instituto Geográfico

Militar

http://www.igm.gob.ec/

SNGR Secretaria Nacional de

Gestión de Riesgos

http://www.gestionderiesgos.gob.ec/

INIGEMM Instituto Nacional de

Investigación

Geológico Minero

Metalúrgico

http://www.geoinvestigacion.gob.ec/

MINTEL Ministerio de

Telecomunicaciones y

Sociedad de la

http://www.telecomunicaciones.gob.ec/

24

Información

EP PETROECUADOR Empresa Pública de

Hidrocarburos del

Ecuador

http://www.eppetroecuador.ec/

MIDUVI Ministerio de desarrollo

Urbano y Vivienda

http://www.habitatyvivienda.gob.ec/

MDMQ Municipio del Distrito

Metropolitano de Quito

http://www.quito.gob.ec/

MTOP-SPTMF Ministerio de

Transporte y obras

publicas

http://www.obraspublicas.gob.ec/

DGAC Dirección General de

Aviación

http://www.aviacioncivil.gob.ec/

INOCAR Instituto Oceanográfico

de la Armada

http://www.inocar.mil.ec/web/

CONALI Comisión Nacional de

Limites

INPC Instituto Nacional de

Patrimonio Cultural

http://www.inpc.gob.ec/

CODENPE Consejo de Desarrollo

de las Nacionalidades

y Pueblos del Ecuador

http://www.codenpe.gob.ec/

MSP Ministerio de Salud

Pública

http://www.salud.gob.ec/

MINEDUC Ministerio de

Educación

http://educacion.gob.ec/

MIDENA-FF.AA. Ministerio de Defensa

Personal

http://www.defensa.gob.ec/

INMOBILIAR Servicio de Gestión

Inmobiliaria del Sector

Público

http://www.inmobiliar.gob.ec/

MINTUR Ministerio de Turismo http://www.turismo.gob.ec/

En la tabla 3, se muestra un listado de las instituciones gubernamentales que aportan con

información geográfica, y trabajan de acuerdo al catálogo nacional de objetos geográficos,

siendo un total de 29 instituciones que aportan con un total de 273 objetos geográficos

25

según el catálogo Nacional de Objetos Geográficos distribuidos en 11 Categorías. Sin

embargo muchas instituciones crean muchos más objetos adicionales a los que están en el

Catálogo Nacional.

Para acceder a esta información se puede hacer a través de los sitios gubernamentales de

cada una de las instituciones generadoras. Sin embargo algunos de los objetos están

disponibles en el Sistema Nacional de información8 a través del siguiente enlace:

http://sni.gob.ec/coberturas

Sin embargo algunas de las instituciones, no han logrado estructurar la información bajo los

estándares propuestos en el catálogo nacional.

Existiendo información que:

Se encuentra alineada al catálogo en su totalidad.

Se encuentra alineada parcialmente al catálogo

Información que no se encuentra alineada al catálogo nacional.

Por otro lado la iniciativa de SmartLand, proyecto propuesto por la Universidad Técnica

Particular de Loja, con el apoyo de algunas instituciones gubernamentales, han generado y

levantando información geográfica, esta es abierta y se encuentra disponible en el portal del

proyecto http://smartland.utpl.edu.ec/. La UTPL a través del proyecto SmartLand se ha

convertido en otra institución generadora de información geográfica.

Lo que quiere lograr en este proyecto es tener una gestión inteligente del territorio, sin

embargo al tratar de lograr esto no podemos dejar a un lado lo que nos menciona Volker

Coors en su trabajo Ohne smarte Geodaten keine smarten Städte / Sin datos geográficos

inteligentes no hay ciudades inteligentes, en el que analiza la importancia de los datos

espaciales para el desarrollo de las Smart Cities. Realiza análisis de flujos de datos de

sensores geoespaciales y su integración en común, información sobre el modelo urbano

conduce a datos geoespaciales inteligentes. En la que concluye que tener datos

geoespaciales inteligentes constituye una condición necesaria para la ciudad del futuro,

cuya infraestructura está vinculada con la información y los componentes relacionados con

la comunicación (Coors, 2015). Teniendo en cuenta que la SmartLand es una iniciativa

mucho más allá de Smart Citties partiendo desde esta, por lo que podríamos aplicar el

mismo concepto.

8 http://sni.gob.ec/coberturas

http://smartland.utpl.edu.ec/

26

Las distintas fuentes generadoras de información utilizan distintos mecanismos y

metodologías para levantar y generar la información, lo que ocasiona que esta se encuentre

en:

Distintos formatos de almacenamiento de información como: shp, xls, csv, GeoJson,

KML/KMZ, base de datos, entre otros.

Los datos geográficos se encuentran en diferentes sistemas de coordenadas como

WGS84, UTM 17S, entre otras.

Con estos antecedentes el presente proyecto de tesis ha detectado que en relación a los

datos geográficos existen algunos problemas que se pretende solucionar en este trabajo,

resumiendo la problemática se ha clasificado en tres grandes grupos:

Integración de Información.- integrar información de diversas fuentes es un proceso

complicado:

El origen de la información es diverso.

Cada organismo o institución almacena en formatos diferentes, algunos inclusive

propietarios.

Los datos geográficos se pueden almacenar en diferentes sistemas de coordenadas

Instituciones generadoras de información geográfica no se rigen en su totalidad por

los estándares establecidos.

No todos los datos que están publicados, ni catalogados o descritos de una manera

eficaz, hay ausencia de metadatos lo que dificulta el acceso de forma automatizada

y la integración de los mismos.

Es imprescindible un marco de trabajo común que permita nombrar y definir

elementos de una forma estándar.

Resumiendo la integración de la información debería ser simple, transparente, abierta,

efectiva y universal.

Acceso a la información.- si bien distintos gobiernos e instituciones de varios países ha

tomado la iniciativa de tener datos abiertos, les faltan comprender que la accesibilidad a la

información es un requerimiento de las sociedades actuales, es por eso que hoy en día

acceder a dicha información es un problema debido a que:

27

El acceso a la información es a través de los diferentes sitios gubernamentales, el

acceso a esto es limitado por que no se han divulgado sus repositorios, la cantidad

de datos que existen en algunos casos es poca.

No existe un repositorio común que sea el único punto de acceso integrador de toda

la información geográfica del país.

Los sitios que han adoptado la política de datos abiertos, colocan en sus plataformas

la información en formatos crudos que pueden ser procesados por técnicos y

especialistas que manejen el tema y los pueden reutilizar para diferentes fines, pero

que pasa con los usuarios no técnicos que simplemente desean visualizar la

información.

A la hora de trabajar con datos geográficos existe una barrera para llevar a cabo el

intercambio de información con facilidad, a pesar de los avances tecnológicos que se tiene.

Esto se debe a que los usuarios esperan las siguientes características para lograr

interoperabilidad:

Sencillo.- El usuario no siempre conoce la información de los datos que tiene o de su

sistema fuente, al usuario le interesa poder importarlos y utilizarlos.

Transparente.- Los procesos complejos para la transformación o interoperabilidad de

la información debe ser transparente para el usuario.

Abierto.- La interoperabilidad debe poder aplicarse a todas las tecnologías,

permitiendo el intercambio de datos, sin importar la tecnología que se use.

Efectivo.- La transformación de los datos debe ser fiable y los resultados útiles.

Universal.- Las herramientas deben ser accesibles y funcionar sin importar la

tecnología que utilice.

Todo esto no es fácil de conseguir, es complejo de lograr que todas las instituciones o

personas que generen información geoespacial adopten un mismo estándar a nivel global.

Adicional ello existe ya una gran cantidad de información que no se encuentra bajo los

estándares establecidos, sin embargo no se puede desechar toda esta información.

Dificultad de visualizar la información.- los datos geográficos disponibles en los sitios web

de datos abiertos dificultan la interoperabilidad de la información:

La información geográfica debería estar disponible en variedad de formas y aplicativos que

aseguren el acceso considerando las diferentes necesidades y preferencias de los usuarios.

La barrera que existen para visualizar la información dificulta la capacidad de análisis de los

datos.

28

En este capítulo se detalla el problema que se quiere solucionar con este trabajo, se inicia

explicando el por qué hubo un incremente en la información geoespacial liberada en la web,

concluyendo que fue que una gran cantidad de instituciones gubernamentales y privadas

tomaron la iniciativa de generar datos abiertos, poniéndolas a disposición de la sociedad

para el uso y el beneficio de la misma.

Luego de ello se analizó las razones y las necesidades de los usuarios de trabajar con datos

geoespaciales; concluyendo que los usuarios cada vez buscan tener un mejor razonamiento

espacial, con el fin de poder obtener datos inteligentes que aporten al desarrollo de las

Smart Cities.

Luego de esto se describe las principales dificultades a la hora de trabajar con datos

geoespaciales, determinando que una de las principales razones es que existe una

diversidad y variedad de información, por lo que es difícil cumplir con la demanda de

interoperabilidad.

Finalmente se determinó las características que buscan los usuarios en las herramientas a

la hora de realizar intercambio de datos geoespaciales.

29

3. CAPÍTULO II I – DISEÑO DE LA SOLUCIÓN

30

3.1. Diseño de Solución

Para dar solución al problema planteado en el Capítulo II – Planteamiento del problema, se

propone lo siguiente:

- Utilizar Linked Data como mecanismo que permita estructurar, organizar e integrar

información geoespacial

- Almacenar la información en RDF, previamente se debe transformar la información a

RDF, para ello es importante seguir una metodología, la cual se detalla en el

apartado 3.2 Metodología en donde se explica cómo generar linked data con datos

espaciales.

- Desarrollar una herramienta de software.- generar RDF basándonos en la

metodología seleccionada se propone desarrollar un prototipo de herramienta que

permita transformar información geográfica a RDF bajo el estándar propuesto en la

sección 3.5 Modelado, centrándose en la información que se encuentra almacenada

en formato shapefile (archivos con extensión *.shp). En el tipo de archivo shapefile

se encuentra gran parte de la información geográfica liberada por las instituciones

gubernamentales en la iniciativa de datos abiertos.

- Finalmente se desarrollará una aplicación que permita visualizar la información

generada. Siguiendo con la metodología Geospatial Linked Data, en la última parte

de esta consiste en explotar los datos, la propuesta sería visualizar los datos a través

de un prototipo que permita visualizar la información generada permitiendo al usuario

tener un razonamiento espacial. Para ello se propone desarrollar una herramienta

web que permita visualizar los datos geográficos, consumiendo la información desde

un endpoint, aplicando reglas RIF propias del lenguaje de consulta Geosparql.

Manteniendo por separado los datos y la visualización.

La arquitectura de prototipos a desarrollar para transformar desde shapefile a RDF y el

prototipo que permita visualizar dicha información se detalla en la sección 3.3 Arquitectura

de aplicaciones. El prototipo se caracteriza por ser único, genérico, adaptable y sigue la

metodología seleccionada para generar RDF y usa el estándar propuesto en la sección 3.5

Modelado.

Este prototipo será modular, el mismo que permitirá realizar la transformación de una

manera óptima, dando versatilidad y escalabilidad a la herramienta a la hora de transformar

la información.

31

El prototipo será desarrollado utilizando software libre, convirtiéndose en un prototipo

multiplataforma.

Para obtener mejores resultados a lo largo del desarrollo se aplicará metodologías de

desarrollo de software para las dos herramientas con el fin de obtener un mejor resultado.

3.2. Metodología para generar Linked Data con datos espaciales.

Para generar RDF es necesario seguir una metodología, al tratarse de datos espaciales se

ha seleccionado la metodología propuesta por (Saquicela, Espinoza, Piedra, & Villazón,

2014) Geospatial Linked Data.

En la Figura 2. Architecture for the Ecuadorian Geospatial linked Data repository (Saquicela,

Elaboración: Espinoza, Piedra, & Villazón, 2014), se puede observar la metodología a utilizar,

determinando que esta se acopla a las necesidades del proyecto y va acorde a los objetivos

planteados, permitiendo llegar a integrar datos con información geoespacial, la misma se

detalla a continuación.

Figura 2. Architecture for the Ecuadorian Geospatial linked Data repository (Saquicela,

Elaboración: Espinoza, Piedra, & Villazón, 2014)

En una primera etapa se realiza la selección y análisis de las fuentes de datos, esto

brindará una idea clara de los datos con los que se va a trabajar permitiendo llevar a

cabo todo el proceso de trasformación a RDF.

32

Definir URIs para recursos geoespaciales

Vocabulario geoespacial

Generación de tripletas RDF

Enlazando Datos Geoespacial

Publicar los datos

Visualizar los datos

3.3. Arquitectura de aplicaciones.

3.3.1. Introducción.

El presente documento proporciona un panorama de la arquitectura de software, para el

conjunto de aplicaciones, herramientas, tecnologías a utilizar con el fin de cubrir las

necesidades presentes en el Capítulo II – Planteamiento del problema Basándose en la

solución planteada. Para lograr mostrar el diseño se presentará un conjunto de vistas

arquitectónicas: casos de uso, lógica, procesos, implementación y despliegue. Ya que las

vistas sirven para representar diversos aspectos de un sistema, con el fin de capturar y

transmitir el funcionamiento del mismo.

Para presentar los modelos de las vistas se utiliza el lenguaje de modelado UML (Unified

Modeling Language)9.

3.3.2. Definiciones, Acrónimos y Abreviaturas .

UML: Unified Modeling Language

Software: Según la (Real Academia Española, 2001) es el conjunto de programas,

instrucciones y reglas informáticas que permiten ejecutar distintas tareas en una

computadora. Se considera que el software es el equipamiento lógico e intangible de

una computadora.

3.3.3. Visión General.

El presente documento presenta una vista general de la arquitectura de las aplicaciones de

software que conforman la solución o parte de la misma. Las secciones del mismo están

organizadas, principalmente, tomando en consideración el Modelo de vistas “4+1” expuesto

por (Kruchten, 1995). Para cada vista se detalla un diagrama UML, está reservada una

sección del presente documento para cada una de estas. Mediante las diferentes secciones

9 http://www.uml.org/

33

que componen este documento se pretende satisfacer la inquietud o expectativas, con

respecto al software, que puedan tener diferentes actores, entre ellos algunos

stakeholders10.

Figura 3 Vista general Arquitectónica de la solución propuesta

La solución planteada, en la que se observa que se inicia desde la fuente de información la

cual debe ser procesada hasta un punto donde pueda ser explotada/consumida con mejores

condiciones y beneficios como se la encuentro en su fuente. Como podemos observar en la

Figura 3 Vista general Arquitectónica, tenemos tres secciones:

Información.- en esta sección básicamente lo que se realiza siguiendo la

metodología, se selecciona las fuentes de información con las que se va a

trabajar, como ya se lo mencionó anteriormente se centra en la información

que se encuentre en formato shapefile. Este proceso de selección de fuentes

de información lo realiza el usuario.

10 http://www.iese.edu/es/files/La%20evaluaci%C3%B3n%20del%20concepto%20de%20stakeholders%20seg%C3%BAn%20Freeman_tcm5-39688.pdf

analysis Analysis View

HERRAMIENTA

SOFTWARE

HERRAMIENTA

SOFTWARE

FUENTE DE

INFORMACION

FUENTE DE

INFORMACION

APLICACION WEB

EXTRACCIÓN EXPLOTACIÓN

SERVIDOR DE

TRIPLETAS

INFORMACIÓN

GENERAR

EXTRAERPUBLICACIÓN

DE RDF EXPLOTACION/CONSUMO

CONSULTAR/ VISUALIZAR

34

Extracción.- en este proceso se extrae la información de las fuentes

seleccionadas, extrayendo dicha información en forma de tripletas sujeto,

predicado y objeto, para finalmente ser procesada y transformada bajo el

estándar propuesto, modelado que se detalla en la sección 3.5 Modelado,

quedando la información lista para la siguiente sección.

Explotación.- en esta etapa básicamente se empieza a explotar la

información generada anteriormente, esto se lo puede realizar de diferentes

maneras, en el presente proyecto se centrará únicamente en la visualización

de dicha información como mecanismo de explotación de la misma.

La arquitectura planteada se caracteriza por dividir las responsabilidades comunes en

capas, cada capa se apila verticalmente. La comunicación entre capas es explicita y de bajo

acoplamiento, permitiendo una fuerte separación de las funcionalidades soportando

flexibilidad y mantenimiento. Las características principales son las siguientes:

- Funcionalidades de las capas claramente definidas. Cada capa tiene su

responsabilidad asignada, y el flujo de información está claramente definido.

- Alta cohesión.

- Reusable. Las capas inferiores no tienen dependencia de las capas superiores

por lo que se puede armar nuevos escenarios.

- Perdida de acoplamiento. Esto se logra por la abstracción y eventos en los

cuales se basa.

35

3.3.4. Representación de la Arquitectura.

Mediante el Modelo de vistas “4+1” (Kruchten, 1995) se expone la arquitectura propuesta, de

los dos aplicativos a desarrollar, dichas vistas permiten a cualquier Stakeholder encontrar lo

que necesita en la arquitectura. Estas vistas son plasmadas a través de diversos tipos de

diagramas de UML. Cabe recalcar que el Modelo de vistas “4+1” se utiliza para una

descripción de la arquitectura de Software, en la presente solución la utilizaremos a manera

de metodología, permitiendo mostrar la funcionalidad requerida de manera más clara.

Figura 4 Las vista del Modelo “4+1 View”.

Fuente: (Kruchten, 1995)

A continuación se detalla cada una de las vistas, así como los artefactos que la conforman,

cada vista se diferencias las dos aplicaciones, por lo que por cada vista existe dos

diagramas.

Tabla 4 Vista de Casos de Uso

VISTA DE CASOS DE USO

Audiencia Los interesados del Sistema y Usuarios Finales.

Descripción: Muestra un conjunto de casos de uso y su relación con actores. Los

casos de uso mostrados son los encontrados a nivel del negocio, es

decir no describe las funcionalidades específicas de la aplicación.

Artefactos: Modelo de Casos de Uso.

36

Tabla 5 Vista Lógica

VISTA LÓGICA

Audiencia: Diseñadores

Descripción: Organización general de las aplicaciones.

Artefactos: Diagrama de componentes.

Tabla 6 Vista de procesos

VISTA DE PROCESOS

Audiencia: Integradores.

Descripción: Requerimientos No Funcionales: Describe los aspectos de

concurrencia y sincronización (Procesos).

Artefactos: Diagrama de Procesos, definición de alto nivel.

Tabla 7 Vista de implementación

VISTA DE IMPLEMENTACIÓN

Audiencia: Programadores

Descripción: Muestra características de interés para la construcción de la solución. Por

ejemplo Tecnología, paquetes.

Artefactos: Diagrama de paquetes.

Tabla 8 Vista de Despliegue/Física

VISTA DE DESPLIEGUE/FISICA

Audiencia: Deployers o Administradores de Sistemas.

Descripción: Describe el mapeo o ubicación de los componentes Software (archivos

JAR’s, EAR’s y WAR’s) en el Hardware, y detalla los aspectos de

distribución del Sistema.

Artefactos: Diagrama de Despliegue.

3.3.5. Vista de Escenarios - Casos de Uso.

En esta sección se muestran los Casos de Uso considerados como relevantes para la

arquitectura, así como también los principales Actores. Con el término “relevante” asociado

a un Caso de Uso, se refiere a la capacidad que tiene este de incidir en la arquitectura y que

representan alguna funcionalidad significativa.

37

Figura 5 Vista de casos de uso

Herramienta software para generar RDF.- Este aplicativo abarca cuatro caso de uso,

como se puede observar. Los requerimientos que cubre son los referentes a la extracción de

los datos desde los archivos fuente (shapefile), quitar las impurezas (limpiarlo), transformarlo

y enlazar la información (creación del archivo RDF)

Visualizador.- Este aplicativo debe consumir la información de un endPoint en donde será

cargado el archivo RDF generado con Herramienta software. El consumo trata de mostrar la

información de manera intuitiva para el usuario, así como la ejecución de consultas

GeoSparql.

3.3.6. Vista Lógica.

La presente vista muestra la estructura de los componentes en cada una de las capas. La

vista lógica que compone la arquitectura capas, está compuesta por la capa de

presentación, capa de negocio y la capa de datos.

uc Use Case Model

Usuario

Generar RDF

Limpiar Datos

Extraer Datos

HERRAMIENTA SOFTWARE VIZUALIZADOR

Usuario

Realizar consulta

VISUALIZARGenerar

Vocabulario

38

Figura 6 Vista Lógica de la herramienta de extracción desde shapefile a RDF

3.3.7. Vista Procesos.

La presente vista de procesos muestra la comunicación entre los componentes de la

arquitectura. Esto permite establecer las dependencias entre los componentes y la

comunicación entre cada una de las capas. Cabe recalcar que las flechas representan cómo

interactúan los paquetes, es decir que paquete hace el llamado a otro. Por ejemplo: el

paquete “Extraer” utiliza/llama al paquete GeoTools.

39

Figura 7 Vista de procesos Herramienta de extracción desde shapefile a RDF

Como se puede ver, hay paquetes de software que son librerías externas, estas son: Jena,

GeoTools, Conector Mysql y JsonSimple. Estas librerías simplemente se las utiliza en la

implementación de la solución.

La aplicación Web, es la encargada de consumir los datos procesados con la herramienta

de software y cargados en el EndPoint, es decir, visualizar los datos espaciales procesados.

cmp Diagrama de Procesos

Extraer

INTERFAZ

LOGICA

Limpiar

Vocabulario

GenerarRDFGeoTools

JENA

JSON SIMPLE

DATOS

CONECTOR MYSQL

HERRAMIENTA SOFTWARE

40

Figura 8 Vista de procesos Aplicación Web – Visualizador de datos geoespaciales

3.3.8. Vista Implementación/Desarrollo.

La presente vista muestra los paquetes en cada una de las capas y la tecnología de

implementación de cada uno de los paquetes. La vista de desarrollo ayuda al grupo de

desarrollo para contemplar una visión general de las tecnologías usadas en toda la

arquitectura. A demás permite el desarrollo/implementación independiente de cada uno de

los módulos y considerar los módulos con los cuales se comunicará, para desarrollar la

solución con características necesarias.


Extraer

INTERFAZ

LOGICA

Limpiar

Vocabulario

GenerarRDFGeoTools

JENA

JSON SIMPLE

DATOS

CONECTOR MYSQL

HERRAMIENTA SOFTWARE APLICACION WEB

persistencia

Serv icios

BASE DE DATOS

INTERFAZ (HTML)

SERVIDOR ENDPOINT (

PARLAMENT )

RECUPERA DATOS

RETORNA JSONCONSUME

CONSULTA GEOSPARQL

41

Figura 9 Vista Implementación/Desarrollo – Herramienta Software para generar RDF desde

Shapefile – Aplicación Web para visualizar los datos geoespaciales

La herramienta software para generar RDF, está desarrollada en un ambiente de escritorio,

escrito en el lenguaje de programación java. La organización del código está basada en

capas:

- Presentación. Es responsable de la gestión de la interfaz de usuario y presentación

de los datos provenientes de la parte Lógica.

- Lógica. Encargada del procesamiento de los datos brindados por la parte de acceso a

datos y de brindar los resultados del procesamiento a la parte de Presentación.

- Acceso a Datos. Su propósito es extraer los datos necesarios para el procesamiento

por la parte lógica de la aplicación. La fuente de extracción puede ser una Base de

Datos, archivos, servicios, etc.

La misma organización del código en capas se la utiliza para la aplicación web. En la

aplicación web se agrega una capa de servicios, la cual utiliza Rest para exponer/publicar

servicios necesarios por la capa de interfaz (JavaScript).

La plataforma de ejecución de cada una de las aplicaciones debe contener los siguientes

paquetes de software instalados para su correcto funcionamiento:

cmp Component View

datos

interfaz

logica

HERRAMIENTA SOFTWARE

JAVA CLASS

JENA

GEOTOOLS

JSON-

SIMPLE

LIBRERIAS EXTERNAS

MYSQL 5.6

JAVA SWING

APLICACION WEB

persistencia

serv icios

interfaz⦁ HTML

⦁ JQUERY

⦁ BOOTSTRAP

⦁ API-OPENSTREETMAP

MYSQL 5.6

EJB -REST

JPA

JDBC

JDBC

AJAX

42

Herramienta Software.- Máquina virtual de java (JVM) 1.7 o superior, motor de base de

datos Mysql 5.6.

Aplicación Web.- Servidor de aplicaciones, Glassfish 4.1, JVM, JDK 1.8.

Adicional a las aplicaciones diagramadas anteriormente es necesario contar con servidor de

tripletas Parliamant Triple Store versión 2.7.6 y el sistema operativo debe contar con el jdk

1.7

3.3.9. Vista Física.

La presente vista muestra los dispositivos físicos necesarios para la ejecución de los

módulos de software planteados, se muestra la comunicación entre los dispositivos, las

plataformas necesarias y los sistemas de software que se desplegarán en cada una de los

dispositivos.

Figura 10 Vista Física – Equipos necesarios para ejecutar las 2 herramientas desarrolladas

Se utilizará dos dispositivos físicos para el funcionamiento de la solución:

Máquina de escritorio.- es una máquina con un sistema operativo (Windows, Linux o Mac)

y contener los paquetes de software detallados en la vista de implementación. Los

requerimientos recomendados para la ejecución óptima del aplicativo son los siguientes:

Espacio en disco: 50GB (dependiendo de la cantidad de información a procesar)

Memoria Ram: 4GB

Procesador: Core I3, 2.4Ghz

deployment Deployment Model

«device»

Maquina de Escritorio

«device»

Serv idor

HERRAMIENTA DE

SOFTWARE

Aplicacion Web

Parlament

43

Servidor.- en este dispositivo se encontrará desplegada la aplicación web y el servidor de

tripletas Parliament. Los requerimientos recomendados para la ejecución óptima de los

aplicativos son los siguientes:

Espacio en disco: 100GB (dependiendo de la cantidad de información a procesar)

Memoria Ram: 16GB

Procesador: Intel Core I7 3770, 3.4Ghz o similar

En este capítulo se define la solución al problema planteado en el capítulo anterior,

determinando que se usará la web semántica como mecanismo de integración de

información, lo que permitirá interoperabilidad con otros datos.

Se plantea desarrollar dos herramientas que nos permitirán generar datos enlazados, estos

datos deberán estar bajo el estándar geosparql, y deberán ser generados bajo la

metodología seleccionada para generar geolinked data.

Se define la arquitectura de software de cada una de las herramientas, utilizando el modelo

de Vista “4+2”.

Las herramientas propuestas nos permitirán hacer lo siguiente:

Generar RDF desde los archivos shapefile, permitirá transformar tripletas RDF bajo

el estándar geosparql.

Visualizar los datos sobre un mapa de Open Street Map

Estos prototipo de herramientas se caracterizan por ser genéricas, adaptables y siguen la

metodología seleccionada para generar RDF; además será modular, permitirá realizar la

transformación de una manera óptima, dando versatilidad y escalabilidad a la herramienta a

la hora de transformar la información, sin olvidar que el prototipo será desarrollado utilizando

software libre, convirtiéndose en un prototipo multiplataforma.

Con la primera herramienta desarrollada se dará solución al problema de integración de

información, y con la segunda herramienta diseñada daremos solución a la problemática de

visualización de datos geoespaciales y la vez también aporta como mecanismo de

integración.

44

4. CAPÍTULO IV – DESARROLLO, IMPLEMENTACIÓN Y PRUEBAS

45

4.1. Desarrollo

Para desarrollar las herramientas propuestas en el capítulo anterior, siguiendo la metodología seleccionado se desarrolló las siguientes etapas:

4.1.1. Identificación, selección y extracción de fuentes de datos.

4.1.1.1. Identificación, selección de fuentes de datos.

Para la selección de fuentes de datos, al tratarse de un prototipo genérico que funcione para

distintas fuentes de información, se ha seleccionado diversas fuentes de datos, para ello se

basa en el Catálogo Nacional de Objetos Geográficos Versión 2 11 , publicado por la

Secretaría Nacional de Planificación y Desarrollo (SENPLADES)12. En el cual existe una

gran cantidad de objetos disponibles.

En este caso, un objeto como lo definen en el Catálogo Nacional de Objetos Geográficos se

estaría referenciando a un shapefile.

Se realizó un análisis previo basado en la cantidad de archivos, categorías de la

información, relaciones entre los objetos y que la información sea entendible de forma

sencilla. Obteniendo como resultado que para las pruebas de laboratorio se trabaje con la

Categoría H Demarcación, del Catálogo Nacional de Objetos Geográficos, con sus

respectivas subcategorías, teniendo como resultado un total de 25 shapefile.

Se procedió a buscar los shapefile correspondientes a la categoría seleccionada en los sitios

de las instituciones generadoras de dichos recursos, sin embargo no todos fueron

encontrados o no están disponibles.

Estos archivos contienen información diversa con el objetivo de generar datos de prueba

que permitan probar las funciones que ofrece la extensión de lenguaje de consulta

Geosparql y la forma en que se integrarán los datos.

11 http://www.planificacion.gob.ec/wp-content/uploads/downloads/2014/04/Catalago-Nacional-de-objetos-geogr%C3%A1ficos.pdf 12 http://www.planificacion.gob.ec/

46

En la siguiente tabla se muestra las fuentes de información seleccionadas.

Tabla 9 Fuentes de Información Seleccionadas

Nombre del Objeto Categoría Subcategoría Institución Generadora

Disponible

Límites de la organización

territorial del Estado

Demarcación Organización territorial del estado

CONALI No

Provincia Demarcación Organización territorial del estado

INEC Si

Cantón Demarcación Organización territorial del estado

INEC Si

Parroquia rural Demarcación Organización territorial del estado

INEC Si

Zona de planificación Demarcación Niveles administrativos de planificación y

prestación de servicios

SENPLADES Si

Distrito Demarcación Niveles administrativos de planificación y


SENPLADES No

Circuito Demarcación Niveles administrativos de planificación y


SENPLADES No

Zona de administración

hídrica

Demarcación Niveles administrativos de planificación y


SENAGUA No

Régimen especial Demarcación Niveles administrativos de planificación y


No

Patrimonio de Área Natural del Estado

(PANE)

Demarcación Límites de áreas naturales

MAE Si

Bosque y vegetación protector


MAE Si

Patrimonio forestal del Estado


MAE No

47

Reserva de biosfera Demarcación Límites de áreas naturales

MAE Si

Zona Intangible Demarcación Límites de áreas naturales

MAE Si

Unidad hidrográfica Pfafstetter

Demarcación Limites hidrográficos SENAGUA Si

Unidad hidrográfica tradicional

Demarcación Limites hidrográficos SENAGUA No

Manzana Demarcación Área de competencia de gobiernos autónomos

descentralizados Municipales

GAD Municipal

No

Mancomunidad Demarcación Asociado a demarcación No

área regada Demarcación Asociado a demarcación MAGAP No

Área de concesión Demarcación Asociado a demarcación CONELEC ARCOM

No

Sector disperso censal

Demarcación Asociado a demarcación INEC No

Localidad dispersa censal

Demarcación Asociado a demarcación INEC No

Hito Demarcación Asociado a demarcación IGM No

Zona de Información Demarcación Asociado a demarcación IGM No

Luego de recolectar la información se trabajará con 9 shapefile de prueba correspondientes

a Demarcación, para ampliar los casos de pruebas basándose en los criterios de selección

el punto anterior, se incluirá información de otras categorías,.

En la siguiente tabla se detalla la información de los objetos seleccionados:

Tabla 10 Otras Fuentes de Información Seleccionadas

Nombre del Objeto Categoría Subcategoría Institución Generadora

Disponible

Aeropuertos Infraestructura de transporte

Transporte Aéreo IGM Si

Catastro Turístico Geografía Socioeconómica

Turismo MINTUR Si

48

Centros de Salud Geografía Socioeconómica

Salud MSP Si

Centros Educativos Geografía Socioeconómica

Educación MINEDUC Si

Cuencas Si

Ferrocarril Infraestructura de transporte

Transporte terrestre Si

Río Hidrografía y Oceanografía

Aguas Interiores IGM Si

Isla Hidrografía y Oceanografía

Aguas Interiores IGM INOCAR

Si

Lago Hidrografía y Oceanografía

Aguas Interiores IGM

Si

Poblados Geografía Socioeconómica

Asentamiento Humanos

Si

Ciudades Patrimoniales

Geografía Socioeconómica

Asociado a asentamientos

humanos

Si

Vías Infraestructura de transporte

Transporte terrestre IGM Si

Subcuencas Si

Unidades Hidrográficas

Hidrografía y Oceanografía

IGM

Si

Se recomienda abrir los shapefile en un software de información geográfica, para asegurar

que sea un shapefile válido, se sugiere usar la herramienta ArcMap13 es una herramienta

pagada pero con la versión TRIAL se puede verificar adecuadamente la validez de los

archivos. A continuación se muestra como ejemplo la información de un shapefile

correspondiente a las provincias del Ecuador abierto desde ArcMap.

13 http://www.esri.com/software/arcgis/arcgis-for-desktop/free-trial

49

Figura 11. Shapefile visto desde ARCMAP

El estándar Geosparql, trabaja en el sistema de coordenadas WGS84, la mayoría de los

archivos seleccionados están en el sistema de coordenadas WGS1984 UTM Zone 17S, para

solucionar esto, se realizó un proceso semi-automático, que permite convertir los archivos al

sistema que se necesita, utilizando la versión de prueba de ArcMap 10.2.2, el cual permitió

realizar este procedimiento.

El proceso que se lleva a cabo para transformar el sistema de coordenadas es el siguiente:

Figura 12. Proceso de transformación de sistemas de coordenadas

50

Para cambiar el sistema de coordenadas del Sistema WGS84 UTM Zone 17S a WGS 84

revisar el Apéndice A. Manual de usuario para cambiar el sistema de coordenadas al

sistema WGS84 de un shapefile.

4.1.1.2. Extracción de información.

Luego de identificar y seleccionar las fuentes de información, se procede a extraer la

información de los shapefile.

Al momento de extraer esta información se debe obtener la información en forma de tripletas

(sujeto, predicado y objeto) y almacenarlas.

Para almacenar las tripletas se utilizó una base de datos relacional, la misma que se ha

seleccionado MySQL Server Community14, ya que es una base de datos de código abierto.

Para realizar la extracción de datos se desarrolló una herramienta que permita pasar la

información de un archivo con extensión .shp (shapefile), a tripletas, almacenando estas en

una base de datos MySQL.

Previo a la extracción de datos se definió la estructura de las tripletas que se obtendrá para

posteriormente ser almacenadas en la base de datos MySQL.

Tabla 11 Estructura de Tripletas

Estructura

Sujeto Predicado Objeto

<tipo><identificador_del_recurso> <Nombre_de_la_columna> Texto correspondiente a

(fila, columna)

Ejemplo

aeropuertos1 nombre Aeropuerto Eloy Alfaro

aeropuertos1 The_geom POINT (-80.42902828999996

-0.6298843859999579)

Hay que tener en consideración que:

Tipo: corresponde al nombre del shapefile a extraer, este puede ser cambiado por el

usuario a la hora de extraer la información.

14 http://dev.mysql.com/downloads/mysql/

51

identificador del recurso: corresponde a la columna seleccionada por el usuario

como identificador del recurso, en caso de que esta sea una columna vacía, se

tomará el tipo del recurso concatenado con el número de fila del recurso.

Previo a la extracción de datos, se crea dos archivos de configuración que son:

conf_grupos.json y conf_dependencia.json.

En estos archivos se encuentra la configuración de cómo se desea que se extraiga la

información. Permitiendo crear grupos, asignar un identificar del recurso y un tipo para cada

grupo creado, además de ello permite configurar la forma en la que los grupos se

encuentran relacionados.

A continuación se muestra un ejemplo de estos archivos de configuración para el caso del

shapefile canton.shp.

Tabla 12 Estructura del shapefile correspondiente a canton

Archivo Canton.shp

Grupos Grupo 1 Grupo 2

Tipo Tipo: canton Tipo: provincia

Campos

Disponibles

The_g

eom

DPA_VA

LOR

DPA_ANI

O

DPA_CANT

ON

DPA_DESC

AN

DPA_PR

OVIN

DPA_DESPRO

Identificador Identificad

or

Identificador

Para configurar la extracción del shapefile canton.shp el archivo de configuración

conf_grupos.json tendrá la siguiente estructura.

52

Figura 13 Estructura del archivo de configuración para

extraer la información de canton.shp

Para crear este archivo de configuración se proporciona interfaz gráfica, o el usuario puede

crear uno previamente en cualquier otra herramienta, siempre teniendo en cuenta que la

estructura del json se mantenga.

Para realizar la extracción revisar el Apéndice B. Manual de Usuario – Extraer datos desde

fuente shapefile a sujeto, predicado y objeto.

Considerar las siguientes recomendaciones.

El nombre del shapefile sea un nombre descriptivo de la información que contiene.

Ejemplo, si la información del archivo contiene la información geográfica de los

aeropuertos, el nombre del archivo puede ser “aeropuertos.shp”. Si el archivo

corresponde a un objeto que se encuentra en el catálogo Nacional de Objetos

Geográficos, se debe respetar el nombre del objeto, únicamente se deberá escribir el

nombre en minúsculas, sin tildes. En caso de que existan espacios, estos deberán

ser remplazados por guion bajo “_”.

53

Ejemplo

Nombre en el Catálogo Nacional de Objetos Geográficos

Parroquia Rural

Nombre del archivo shape (recomendado)

parroquia_rural

Los datos se inserten en una tabla con el nombre del shapefile o el tipo.

El sistema de coordenadas del shapefile sea WGS 84.

Realizar un análisis previo de la información que contiene el shapefile. En varios

casos el archivo contiene información adicional, que corresponde a otros objetos, sin

embargo esta está relacionada entre sí.

Ejemplo

parroquia_rural.shp

Este archivo contiene información de la parroquia rural, el cantón y la provincia a la

que pertenece cada una de las parroquias existentes, sin embargo dicha información

de cantones y provincias corresponde a otros objetos geográficos.

Teniendo en cuenta las recomendaciones y definida la estructura en la que se va a extraer

los datos, se procedió a desarrollar en JAVA un aplicativo de escritorio, utilizando como

librería principal Geotools15, para extraer los datos.

El propósito de esta herramienta es convertir información en formato shapefile a sujeto,

predicado y objeto y almacenarlas en una base de datos MySQL.

4.1.2. Limpieza de Datos.

Una vez que se ha extraído los datos de las fuentes de información, es importante realizar

una limpieza previa de los mismos, con el objetivo de los datos almacenados en la base de

datos no existan caracteres especiales, espacios no deseados, entre otros.

Luego de realizar la extracción de datos, se procede a realizar una comparación de la

información extraída con la información del Catálogo Nacional de Objetos Geográficos. De

esta comparación surge un inconveniente, las instituciones generadoras de los shapefile, no

han adoptado las estándares propuestos por la Secretaria Nacional de Planificación y

Desarrollo (SENPLADES) En Información Geográfica Tomo I16

15 http://www.geotools.org/ 16 http://www.ipgh.gob.ec/portal/index.php/biblioteca-menu/143/view/60/Geograf%C3%ADa/18/estandares-de-informacion-geografica-tomo-i

54

Por esto es necesario realizar una limpieza de datos que permita acercar la información

extraída a los estándares propuestos en el Catálogo Nacional de Objetos Geográficos. Con

el fin de que los datos queden bajo un estándar logrando que nuestra herramienta sea

versátil y escalable.

Para realizar la limpieza de la información hay que tener cuidando de que no quede

información importante fuera.

Se realizó un análisis manual, comparando la información de cada shapefile de las fuentes

seleccionadas con el Catálogo Nacional, con el fin de encontrar los metadatos equivalentes

del shapefile en el catálogo. Estas equivalencias se las almacena en un archivo de

configuración para la limpieza de datos, llamado limpiezaData.json, con el fin de que este

archivo se convierta en una base de datos, la misma que se irá alimentando para que la

limpieza de datos cada vez sea más exacta y completa.

Para alimentar este archivo se creó una interfaz que permita ir añadiendo nuevas

equivalencias.

Una vez que se tenga el archivo con las equivalencias correctas se procede a ejecutar la

herramienta de limpieza. Para llevar a cabo este proceso revisar el Apéndice C. Manual de

usuario – Limpieza de datos .

4.1.3. Modelado.

4.1.3.1. Modelado del vocabulario.

Con la información en el formato correcto y las fuentes de información se procede a

representar la información en formato RDF, para lo cual se tiene que definir la ontología o

vocabulario a utilizar.

El vocabulario que se propone utilizar para representar los datos geoespaciales en RDF bajo

el estándar propuesto por Open Geoespatial Consortium (OGC)17, es Geosparql, vocabulario

que permite representar cualquier tipo de objeto espacial y brinda un conjunto de funciones

para realizar un razonamiento espacial.

Geosparql no define un vocabulario amplio. Sino un conjunto básico de clases, propiedades

y tipos de datos que son utilizados para construir patrones de consulta.

17 http://www.opengeospatial.org/

55

Geosparql permite representar datos en Geography Markup Language (GML)18 y Well-

Known Text o texto de lenguaje de marcas (WKT)19, utilizado para representar vectores

geométricos, es decir objetos en un mapa.

Este vocabulario ha sido utilizado en diferentes proyectos como Linked Data Geográfico

Conforme a Geosparql Caso de aplicación: División territorial y administrativa de

Colombia desarrollado por Jhonny Alexis Saaevedra Velásquez, Luis Manuel Vilches

Blázquez y Oscar Corcho García, Ecuadorian Geospatial Linked Data por (Saquicela,

Espinoza, Piedra, & Villazón, 2014). Y actualmente se adapta a las necesidades del

proyecto en desarrollo, adicional a ello una gran comunidad, está adoptando este formato de

representación.

La ontología Geosparql está disponible para descargar en RDF en el sitio web20, para poder

observar la estructura de la ontología a través de un grafo, se procedió a abrir el archivo en

Protégé21, el cual muestra el siguiente grafo:

Figura 14. Grafo de Vocabulario Geosparql visualizado en la herramienta Protégé

18 http://www.opengeospatial.org/standards/gml 19 http://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/wkt-wkb.html 20 http://www.opengeospatial.org/standards/geosparql 21 http://protege.stanford.edu/

http://protege.stanford.edu/

56

En la figura se observa que la ontología incluye una clase: SpatialObject, con dos subclases

primarias, geo: Feature y geo:Geometry; estas clases están destinadas a ser conectadas a

una ontología que represente un dominio de interés. Permitiendo que otras características

puedan conectarse a sus geometrías a través de la propiedad geo:hasGeometry,

proporcionando la oportunidad de representar cualquier objeto espacial bajo este mismo

estándar.

Sin embargo para representar los datos elegidos en la selección de fuentes de información,

no es necesario utilizar toda la ontología, por lo que se ha realizado una selección de las

clases y propiedades a utilizar que muestra a continuación. La misma que se adapta para

cualquier tipo de shapefile, siendo esta la propuesta genérica para representar información

que contiene los shapefile en RDF bajo el estándar Geosparql.

Para incluir información no relevante que se encuentra en el shapefile disponible, se

presenta un propuesta de vocabulario extendido para cada tipo de shapefile, esta

propuesta permite ampliar cada vez más el vocabulario dependiendo del shapefile que se

tenga y de la información del mismo que desee representar, para trabajar con esta

propuesta se debe alimentar la base de datos del vocabulario de la aplicación con el objetivo

de tener un vocabulario más amplio y que se ajuste a necesidades particulares, para

configurar y aplicar el vocabulario revisar el Apéndice D. Utilizar vocabulario extendido a la

hora de extraer datos

Figura 15. Propuesta de Ontología basada en GEOSPARQL para Representar en RDF

Datos Espaciales

Se propone utilizar el siguiente vocabulario con sus respectivas clases y propiedades.

57

A continuación se detalla las clases y propiedades que se va a utilizar en el vocabulario

genérico

:

Prefijos:

geo: http://www.opengis.net/ont/geosparql#

sf: http://www.opengis.net/ont/sf

Clases:

geo:SpatialThing.- cualquier cosa con extensión espacial, i.n. tamaño, forma o

posición. por ejemplo personas, lugares, así como las áreas abstractas.

geo:Feature.-

geo:Geometry.-

sf:Point.- un punto es un objeto geométrico dimensional y representa una única

ubicación en el espacio de coordenadas. Un punto tiene un valor de la coordenada x,

un valor de la coordenada y. Si se pide en el sistema de referencia espacial

asociado, también puede tener valores de coordenadas para z y m. El límite de un

Point es el conjunto vacío.

sf:MultiLineString.- un MultiLineString es un MultiCurva cuyos elementos son

cadenas lineales.

sf:MultiPolygon.- un MultiPolygon es un MultiSurface cuyos elementos son

polígonos. Las afirmaciones para multipolígonos son los siguientes.

o En el interior de 2 polígonos que son elementos de un MultiPolygon pueden

no cruzarse.

o Los límites de las 2 polígonos que son elementos de un MultiPolygon no

pueden cruzar y puede tocar a sólo un número finito de puntos.

o Un MultiPolygon se define como cerradas topológicamente.

o Un MultiPolygon no debe tener líneas de corte, picos o pinchazos, un

MultiPolygon es un conjunto regular cerrado Point,

o El interior de un MultiPolygon con más de 1 Polígono no está conectado; el

número de componentes conectados del interior de un MultiPolygon es igual

al número de polígonos en el MultiPolygon. El límite de un MultiPolygon es un

conjunto de curvas cerradas (cadenas lineales) que corresponden a los

límites de sus elementos polígonos. Cada curva en el límite de la

MultiPolygon está en el límite de exactamente 1 elemento polígono, y cada

58

Curva en el límite de un elemento polígono está en el límite de la

MultiPolygon.

Propiedades:

geo:hasGeometry.- una representación espacial para una función determinada.

geo:hasDefaultGeometry.- la geometría predeterminada que se utiliza en los

cálculos espaciales. Por lo general es la geometría más detallada.

geo:asWKT.- serialización de una geometría en estándar WKT.

geo:asGML.- serialización de una geometría en estándar GML.

Esta es la parte de la ontología de Geosparql que se utilizó para representar datos

geoespaciales, y se lo utilizó en el desarrollo del proyecto.

Una vez que se ha seleccionado la fuente de datos y modelado el vocabulario para

representar los datos, se procede a transformar la información extraída de las fuentes

seleccionadas a RDF bajo el vocabulario propuesto.

4.1.3.2. Definir URIs para recursos Geoespaciales

Definir el formato de URI, antes de generar la información en RDF, esto permitirá identificar

cada recurso que se genere, con la certeza de que cada URI se refiere a un recurso único.

Para esto se propone lo siguiente:

La base de la URI será:

Tabla 13. URI base para recursos espaciales

URI Base

http://geosparql.ec/resource/

La URI para identificar un recurso tendrá la siguiente estructura:

Tabla 14. Estructura de uri para identificar una clase

Estructura

http://geosparql.ec/resource/<clase>

Ejemplo

http://geosparql.ec/resource

http://geosparql.ec/resource/%3cclase%3e

59

http://geosparql.ec/resource/provincia

Nota: El ejemplo de URI, hace referencia al recurso provincia

La URI para identificar un elemento en específico mantendrá la URI base, se añadirá la

clase y el nombre del recurso:

Tabla 15. Estructura de URI para identificar una instancia

Estructura

http://geosparql.ec/resource/<clase>/<nombre_del_elemento>

Ejemplo

http://geosparql.ec/resource/provincia/loja Nota: El ejemplo de URI, hace referencia al recurso provincia Loja

4.1.4. Generación de datos RDF de prueba.

Para generar RDF se eligió desarrollar un módulo de la herramienta, utilizando como

lenguaje de desarrollo Java 1.822, Apache Jena 2.6.423, librería de java para generar RDF,

ya que con el servidor de tripletas seleccionado existe compatibilidad.

4.1.4.1. Generar Vocabulario propuesto basado en Geosparql para

representar datos espaciales.

Para crear el modelo de acuerdo al vocabulario se creó un nuevo módulo que permite crear

un archivo con extensión (rdf). En él se define las clases y propiedades con sus respectivas

etiquetas y comentarios, adicional a ello se incluyó el dominio y rango de cada una de las

propiedades, para la parte del vocabulario de geosparql, adicional a ello crea el vocabulario

en RDF con la información que se encuentra en la base de datos, los mismos que se puede

ir incrementando para representar información que contengan los shapefile en RDF.

A continuación se explica brevemente como trabaja el módulo de vocabulario:

Parámetros iniciales para generar el Vocabulario:

22 https://www.oracle.com/java/index.html 23 https://jena.apache.org/

60

Se crea un modelo utilizando la librería Jena.

Se asigna la ruta donde se desea guardar el archivo vocabulario.rdf, por defecto

está en el directorio ArchivosRdf.

Considerando los parámetros iniciales se procede a crear las clases y propiedades

correspondientes a geosparql, el vocabulario que permitirá representar bajo este mismo

estándar la información de cualquier shapefile.

Luego se añade al modelo la información de vocabulario que se encuentra en la base de

datos, para finalmente crear el archivo rdf con la información que se encuentra en el

modelo, en la ruta especificada.

Teniendo como resultado, el archivo vocabulario.rdf, el mismo que se encuentra en RDF,

lo puede encontrar en el Apéndice E. Vocabulario Propuesto en RDF. En el siguiente

recuadro se muestra un fragmento del archivo generado como ejemplo.

Para ejecutar el módulo revisar el Apéndice F. Manual de Usuario – Crear archivo de

vocabulario

Para mayor información de la programación del módulo revisar el Apéndice I. Manual de

Desarrollador

<rdf:Description rdf:about="geo:SpatialThing">

<rdfs:comment>Anything with spatial extent, i.e. size, shape, or position. e.g. people, places, bowling balls, as well as abstract areas like cubes.</rdfs:comment>

<rdfs:label>SpatialThing</rdfs:label>

<rdfs:label>Objeto Espacial</rdfs:label>

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>

</rdf:Description>

<rdf:Description rdf:about="js:psj">

<rdfs:comment>psj</rdfs:comment>

<rdfs:label>Paisaje</rdfs:label>

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>

</rdf:Description>

61

4.1.4.2. Transformación de datos de prueba bajo el vocabulario

propuesto en RDF.

Con el vocabulario implementado, se procede a generar tripletas en RDF desde la

información que se extrajo anteriormente.

Para este proceso se desarrolló un módulo en JAVA, utilizando como librería principal

Apache Jena para generar RDF.

El propósito de este módulo es convertir la información que se encuentra en forma de

tripletas en la base de datos MySQL a RDF representando la información bajo el estándar

Geosparql y en caso de que amerite incluir la función de vocabulario extendido. Función que

permite añadir nuevas propiedades a los recursos, utilizando la información que se

encuentre en la base de datos para representar la mayor cantidad de información posible en

rdf.

El módulo fusiona la información obtenida del proceso de extracción, con el de modelado

para obtener información en tripletas en formato RDF, bajo el modelo propuesto.

62

Figura 16 Transformar de Sujeto, predicado y objeto almacenadas en MySQL a RDF bajo el

modelo propuesto

Tener en cuenta que los datos geográficos que se encuentran en la base de datos relacional

se encuentren de manera adecuada, es decir que hayan pasado el proceso previo de

limpieza de datos, adicional a esto considerar que los datos de coordenadas estén en el

sistema WGS 84, En caso de que los datos no se encuentren en este sistema de

coordenadas la herramienta de igual manera los transforma pero la información geoespacial

ya no se encuentra bajo el estándar geosparql, o podrá presentar errores.

La herramienta busca si existe en la base de datos en la tabla vocabulario alguna

coincidencia con el tipo de datos a transformar, en caso de que exista aplicará el vocabulario

extendido, caso contrario extraerá la información básica.

Para ejecutar el proceso de transformación revisar Apéndice G. Manual de usuario para

transformar a RDF

Una vez transformada la información que se encontraba en tripletas en la base de datos a

rdf visto en grafo se observa lo siguiente:

63

Figura 17. Grafo de la información generada después de ejecutar la herramienta

De manera que la aplicación se adapta a cualquier estructura de archivos shape, la

información se estructurá de la siguiente forma:

Figura 18. Grafo de ejemplo de estructura de shapefile luego de ejecutar el convertidor

El flujo de datos al momento de ejecutar la herramienta de transformación se muestra en la

figura a continuación.

64

Figura 19. Diagrama de flujo de datos al momento de transformar de sujeto, predicado y

objeto desde la base de datos relacional a rdf

El proceso de transformación se debe repetir para cada una de las tablas que se desee

transformar a RDF.

4.1.5. Publicación de los datos en repositorio semántico con soporte para

Geosparql.

Para publicar la información es necesario tener un repositorio semántico, para este caso se

necesita uno con soporte para Geosparql, para explotar los datos a través de la extensión

del vocabulario Geosparql; para este propósito se usará Parliament Triple Store.

Una vez instalado Parliament Triple Store, en un servidor local.

Se puede acceder a él través de la siguiente dirección:

65

http://localhost:8888/parliament.

Figura 20. Página inicio Parliament Triple Store

Antes de subir nuestros archivos RDF, considerar que se va a trabajar con datos

Geoespaciales, por lo que hay que crearlos, para ello se realiza clic en Indexes.

Figura 21. Creación de índices espaciales

http://localhost:8888/parliament

66

Se hace clic en Create All, y se puede observar que se crearon los índices espaciales, este

proceso se lo recomienda realizar antes de insertar datos al endpoint.

Para subir el archivo RDF se ejecuta lo siguiente:

Clic en Insert Data,

En la sección File Insert, se hace clic en Seleccionar archivo

Se escoge el archivo *.owl

En Data to Insert se escoge la opción Auto Detect o RDF/XML.

Finalmente clic en el botón Insert File obteniendo como resultado un mensaje HTTP

OK: 200 en caso de que se haya subido el archivo de manera correcta.

Figura 22. Subir archivo RDF a Parliament

67

De esta forma se encuentran ya los datos cargados en el repositorio semántico. Este

proceso se deberá repetir, cuantas veces sea necesario, dependiendo de la cantidad de

archivos RDF que se posea.

Se recomienda subir los datos en el grafo por defecto, con el fin de facilitar más adelante la

consulta de los mismos.

Para comprobar que los datos se han subido correctamente, hacemos clic en Explore.

Figura 23. Visualizar los datos en el ENDPOINT de parliament triple store

Una vez que se encuentra la información en el repositorio semántico se procede a consumir

y visualizar la información.

4.1.6. Consumo y Visualización

Una vez que se ha cargado los datos a Parliament Triple Store, se procede a realizar

consultas Sparql y Geosparql.

Este proceso se lo puede realizar desde distintos lugares, ya sea directamente en el servidor

de tripletas o a través de algún aplicativo que se conecte al endpoint de Parliament.

Siguiendo con la explotación de los datos a través de la visualización se procedió a

desarrollar una herramienta de visualización de datos geográficos, la misma que se conecta

68

al endpoint de Parliament Triple Store, consulta los datos y los representa sobre un mapa de

Open Street Map.

La herramienta permite realizar lo siguiente.

Visualizar geometrías GeoSparql WKT (Puntos, líneas y polígonos) a través de OSM

(Open Street Map)

Buscar por facetas

Procesamiento de datos geoespaciales a través de la extensión de lenguaje de

consulta geoSparql.

Figura 24 Captura de pantalla de la herramienta de visualización de datos geográficos -

Visualización de la provincia de AZUAY y Zamora Chinchipe

En la siguiente figura mostramos una captura de pantalla de la herramienta desarrollada, en

ella graficamos como ejemplo la provincia de Azuay (polígono de color negro) y la provincia

de Zamora Chinchipe (polígono de color verde).

69

En la herramienta se implementó las funciones para procesamiento de datos de geosparql,

estas se detallan a continuación:

Tabla 16 Funciones predefinidas para procesamiento de datos espaciales utilizando

consultas geosparql

Función Propiedad en

Geosparql

Sintaxis Descripción

disjoint geo:sfdisjoint geof:sfDisjoint(?geom1,

?geom2)

Devuelve las geometrías si

no comparten ningún

espacio juntos

touches geo:sftouches geof:sfTouches(?geom1,

?geom2)

Devuelve las geométricas si

tienen al menos un punto

en común, pero sus

interiores no se cruzan

overlaps geo:sfoverlaps geof:sfOverlaps(?geom1,

?geom2)


están son de igual

dimensión, pero no está

completamente contenidas

por la otra

equals geo:sfequals geof:sfEquals(?geom1,

?geom2)


estas representan la misma

geometría

within geo:sfwithin geof:sfWithin(?geom1,

?geom2)

Devuelve la geometrías si la

geometría 2 está

completamente dentro de la

geometría 1

contains geo:sfcontains geof:sfContains(?geom1,

?geom2)


y solo si no hay puntos en

el exterior y al menos un

punto del interior de la

geometría 2 se encuentra

en el interior de la

geometría 1.

distance geof:distance geof:distance(?geom1,

?geom2,units:anyUnit)

Devuelve la distancia más

corta entre dos puntos en

los objetos geométricos.

70

La herramienta en el primera pestaña Objetos nos proporciona una lista con los tipos de

objetos disponibles en el endpoint, y las instancias posibles. Siendo todas estas los objetos

disponibles para visualizar.

Figura 25 Lista de objetos disponibles

en la herramienta para graficar

Estas opciones, dependen de la información que se encuentra disponible en el endpoint, y

se actualizan automáticamente, al hacer clic en la casilla de verificación permitirá graficar o

eliminar el objeto del mapa.

En la segunda pestaña Facetas, se presentan el facetado. Básicamente agrupa las

instancias de objetos de acuerdo al tipo. Permitiendo encontrar fácilmente los elementos

para graficar.

En la tercera pestaña Consultas, es donde la herramienta permite realizar procesamiento

de datos espaciales, dando las opciones de seleccionar el objeto con la geometría A y el

objeto con la geometría B, para luego mandar a procesar esta información de acuerdo a la

regla RIF que el usuario haya seleccionado, representando la información sobre el mapa de

OSM en caso de que sea necesario, básicamente permite realizar procesamiento de datos

71

geoespaciales, se selecciona la figura A y figura B y una función RCC8, de acuerdo a los

resultados obtenidos, esta devolverá los datos correspondientes representados en el mapa.

4.1.7. Consideraciones para extraer información desde un shapefile a rdf bajo

el estándar geosparql, utilizando las herramientas propuestas.

Para realizar la transformación de un shapefile a RDF bajo el estándar geosparql, utilizando

la metodología propuesta por (Saquicela, Espinoza, Piedra, & Villazón, 2014) se debe

realizar el siguiente proceso.

Seleccionar el shapefile.

Verificar que sea un shapefile válido.

Verificar que el sistema de coordenadas del shapefile sea WGS 84, en caso de que

no se encuentre en este sistema transformarlo a WGS 84.

Extraer la información de shapefile en forma de tripletas (sujeto, predicado y objeto) y

almacenarlo en una base de datos MySQL

Ejecutar la herramienta de limpieza de datos.

Ejecutar la herramienta de transformar de tripletas a RDF

Teniendo en cuenta lo siguiente:

Sistemas de coordenadas del shapefile debe estar en WGS 84

El nombre del shapefile se convierte en el nombre de clase, en lo posible utilizar el

nombre correspondiente en el Catálogo Nacional De Objetos Geográficos.

El valor del objeto correspondiente al predicado seleccionado deberá ser un valor

único, en el mejor de los casos deberá contener un nombre descriptivo, ya que este

se convierte en la etiqueta de cada instancia.

72

4.2. Puesta en producción

4.2.1. Puesta en producción de la herramienta para transformar shapefile a

Rdf.

Para poder ejecutar la herramienta es necesario tener previamente las siguientes

herramientas:

1. Software

Servidor de Base de Datos

o MySql 5.6.21 Community Server

IDE

o Netbeans 8.0.2

Java

o JDK 1.8

o Librerías de Java

Geotools 12-RC1

Jena 2.4

Json simple 1.1.1

Silk 2.6.1

Nota: Las librerías de Java están incluidas dentro de la herramienta, el trabajar con otras

versiones de estas puede afectar el funcionamiento de la aplicación.

2. Hardware

Requisitos mínimos

o Procesador: Intel core i3-3220M

o Ram: 4 Gb

Requisitos recomendados

o Procesador: Intel core i7-3770

o Ram: 16 Gb

Para desplegar la aplicación debemos seguir el siguiente procedimiento.

1. Descargar el proyecto del repositorio desde el siguiente link:

https://[email protected]/charbelalex/shaperdf/get/23f9d9ab8ff3.zip

2. Descomprimir el proyecto en la ruta deseada.

3. Configurar la base de datos, para ello realizar lo siguiente:

https://[email protected]/charbelalex/shaperdf/get/23f9d9ab8ff3.zip

73

a. Iniciar el servidor de base de datos MySql.

b. Crear una base de datos, con el nombre que se desee. Asegurarse de que la

codificación de esta sea UTF8

c. Ejecutar el script bd_inicial.sql que se encuentra en el directorio Configuracion

4. Abrir la carpeta del proyecto en Netbeans.

5. Hacer clic derecho sobre la carpeta del proyecto en Netbeans y clic en Run Project o

Ejecutar proyecto.

Luego de haber realizado este proceso, la aplicación se desplegó correctamente.

Nota: La aplicación necesita una conexión a la base de datos MySql para ello se debe

configurar la conexión a través de la interfaz gráfica que proporciona la herramienta, o

modificar el archivo coneccion_bd.json en el directorio de Configuracion.

4.2.2. Puesta a producción del visualizador.

Para poder ejecutar la herramienta es necesario tener previamente las siguientes

herramientas:

3. Software

Servidor de Base de Datos

o MySql 5.6.21 Community Server

Servidor de aplicaciones

o Glassfish server 3.5

Servidor de datos RDF

o Parliament Triple Store

4. Hardware

Requisitos recomendados

o Procesador: Intel core i7-3770

o Ram: 16 Gb

Para desplegar la aplicación debemos seguir el siguiente procedimiento:

1. Descargar el código fuente de la aplicación desde el repositorio:

https://bitbucket.org/charbelalex/visualizadorrdf/get/6b826fe964ce.zip

2. Descomprimir el proyecto en la ruta deseada.

3. Configurar la base de datos, para ello realizar lo siguiente:

o Iniciar el servidor de base de datos MySql.

https://bitbucket.org/charbelalex/visualizadorrdf/get/6b826fe964ce.zip

74

o Crear una base de datos, con el nombre que desee. Asegurarse de que la

codificación de esta sea UTF8

o Ejecutar el script visualizador_db.sql que se encuentra en el directorio config.

4. Abrir el proyecto en netbeans

5. Configurar la capa de persistencia, para acceder y gestionar los datos de la base de

datos.

6. Levantar el servidor de datos RDF Parliament Trilpe Store, ver manual de instalación

en el Apéndice H Manual de Instalación de Parliament.

7. Luego de levantar el servidor de datos, recordar crear los índices espaciales y subir

la información al servidor, para ello revisar la sección 4.1.5 Publicación de datos en

el repositorio.

8. Una vez que se haya realizado las configuraciones, procedemos a realizar clic

derecho sobre el proyecto. Clic en Clean and Build

9. Clic en Run proyect

10. Abrir el navegador y escribir la siguiente dirección:

localhost:8080/visualizador

En caso de que se ha cambiado el puerto del servidor, debemos remplazar el 8080 por el

número de puerto correspondiente.

4.3. Pruebas

En la fase de pruebas tenemos que poner a prueba las principales herramientas utilizadas

en el proyecto, están son:

Herramienta para extraer datos desde un shapefile a RDF.

Se midió la capacidad de la herramienta para transformar shapefile a RDF.

Parliament Triple Store

Se midió la capacidad del servidor de tripletas para retornar los datos y de procesar

información espacial.

Visualizador

Medir la capacidad del visualizador para graficar los diferentes puntos, líneas o

polígonos que se necesite.

75

4.3.1. Pruebas a la herramienta para extraer datos desde shapefile a RDF.

En esta etapa se probó la eficacia de la herramienta para transformar información desde

shapefile a RDF.

Para esta prueba se tomó una muestra 36 archivos shapefile, que se procedió a

transformarlos a RDF obteniendo como resultado un total de 27 archivos transformados.

La lista de los archivos transformados se muestra en la tabla Tabla 17. Resultados de

transformación desde Shapefile a RDF.

Tabla 17. Resultados de transformación desde Shapefile a RDF

Nombre del Archivo Origen

Institución Generadora

Tamaño (MB)

Sistema de Coordenadas Origen

Nombre del Archivo Destino

Tamaño (MB)

provincias.shp

INEC 8.33 WGS 85 provincia.rdf 20.24

cantón.shp INEC 17.5 UTM 17S canton.rdf 42.53

Parroquia rural shp

INEC UTM 17S parroquia_rural.rdf 0.00

Zona de planificación

shp

SENPLADES 6.88 WGS 85 zona_de_planificacion.rdf

16.72

Patrimonio de Área

Natural del Estado

(PANE) shp

MAE 7.73 UTM 17S pane.rdf 18.78

Bosque y vegetación protector

shp

MAE 2.23 UTM 17S bosque_y_vegetacion_protector.rdf

5.42

Reserva de biosfera shp

MAE 0.39 UTM 17S reserva_de_biosfera.rdf 0.95

Zona Intangible

shp

MAE 0.34 UTM 17S zona_intangible.rdf 0.83

Unidad hidrográfica

Pfafstetter.shp

SENAGUA UTM 17S unidad_hidrografica_pfafstetter.rdf

0.00

Aeropuertos.shp

IGM 0.16 WGS 85 aeropuertos.rdf 0.39

Catastro Turístico.shp

MINTUR 0.21 UTM 17S catastro_turistico.rdf 0.51

Centros de MSP 3.11 UTM 17S centros_de_salud.rdf 7.56

76

Salud.shp

Centros Educativos.s

hp

MINEDUC 529 UTM 17S centros_educativos.rdf 1285.47

Cuencas.shp IGEPN UTM 17S cuencas.rdf 0.00

Ferrocarril.shp

MTOP-SPTMF

0.02 UTM 17S ferrocarril.rdf 0.05

Río.shp IGM rio.rdf 0.00

Isla.shp IGM INOCAR 529 UTM 17S isla.rdf 1285.47

Lago.shp IGM 0.05 WGS 85 lago.rdf 0.12

Poblados.shp MIDUVI 0.1 UTM 17S poblados.rdf 0.24

Ciudades Patrimoniale

s.shp

MDINPC UTM 17S ciudades_patrimoniales.rdf

0.00

Vías.shp MTOP-SPTMF

2.12 UTM 17S vias.rdf 5.15

Subcuencas.shp

IGEPN UTM 17S subcuencas.rdf 0.00

Unidades Hidrográficas

.shp

EPMAPS 0.02 UTM 17S unidades_hidrograficas.rdf

0.05

Teniendo como resultado una efectividad de la herramienta del 72%, los archivos restantes

se desconoce la razón por la que no se pudo transformar a RDF.

La herramienta se probó en los siguientes equipos:

Portátil con procesador core i3-3220M con 4 Gb de Ram

Computador de escritorio con procesador core i7-3770 con 16 Gb de Ram

Y a la hora de transformar el mismo shapefile a RDF la máquina de escritorio, lo realiza

150% más rápido que la de escritorio, asi que se puede determinar que el rendimiento de la

aplicación mejora, con la infraestructura que posea, sin embargo en ambas pruebas se

obtuvo los mismos resultados.

4.3.2. Pruebas de rendimiento de servidor Parliament triple Store.

4.3.2.1. Consultas Directas en el Servidor de Tripletas.

Para probar el rendimiento del servidor primeramente se ejecutó una serie de consultas

sparql y geosparql, directamente en el servidor.

Para ello hacemos al servidor y hacemos clic en Query.

77

Figura 26. Interfaz para escribir consulta Sparql directamente en la herramienta Parliament

Triple Store

En esta página, se brinda una área de texto en el que permite escribir la consulta sparql.

Permite seleccionar el formato en el que se desea que se retorne los resultados, ya sea en

una tabla HTML, CSV, Json entre otras, y finalmente seleccionar el grafo en el que se desea

ejecutar la consulta.

78

Prueba 1. Consulta Sparql 1 - Nombre de las provincias del Ecuador

Para este caso de prueba se ejecutó la siguiente consulta Sparql, la misma que deberá

devolver el nombre de las provincias de Ecuador, poniendo como límite que muestre

únicamente 10 resultados.

Para esta prueba se solicita que devuelva el nombre de las provincias de Ecuador, en

formato de tabla en HTML, en la figura 27. Se muestra los resultados luego de ejecutar la

consulta de la prueba 1.

Figura 27. Resultados de Consulta Sparql de

prueba 1 – Nombres de las provincias del Ecuador

SELECT distinct ¿nombre

WHERE {

?r1 a <http://www.geosparql.ec/resource/provincias>.

?r1 rdfs:label ?nombre.

} LIMIT 10

http://www.geosparql.ec/resource/provincias

79

Prueba 2. Consulta Geosparql 1 – Aeropuertos del cantón Guayaquil

Para probar que el vocabulario se encuentra correctamente implementado y los datos están

bajo el estándar geosparql, se procede a generar consultas en las que se realice un

razonamiento espacial..

La consulta de prueba que se ejecutó deberá devolver como resultado, el nombre y las

coordenadas de los aeropuertos que se encuentren dentro del cantón Guayaquil. La

consulta que se ejecuto se muestra a continuación:

El resultado que devuelve la consulta es la siguiente:

Figura 28. Resultados de la consulta Geosparql de la prueba 2 – Aeropuertos del cantón

Guayaquil

SELECT distinct ?ubicacion ?nombre

WHERE {

?s a <http://www.geosparql.ec/reosurce/aeropuertos>.

?s <http://www.opengis.net/ont/geosparql#hasGeometry> ?d.

?s rdfs:label ?nombre.

?d geo:asWKT ?ubicacion.

?r2 rdfs:label ‘GUAYAQUIL’.

?r2 geo:hasGeometry ?geo2.

?geo2 a ?geoType2;

geo:asWKT ?figura2.

FILTER (geof:sfContains(?figura2, ?ubicacion))

}

http://www.geosparql.ec/reosurce/aeropuertos

http://www.opengis.net/ont/geosparql#hasGeometry

80

Prueba 3. Consulta Geosparql 2 – Cantones de la Provincia de Loja

La consulta deberá devolver los nombres de los cantones de la provincia de Loja con sus

respectivas coordenadas. La siguiente consulta es la que se ejecutó en la prueba 3.

Luego de ejecutar la consulta se obtuvo el siguiente resultado:

Figura 29. Resultados de la consulta Geosparql de prueba 3 – Cantones de la Provincia de

Loja

SELECT distinct ?nombre ?ubicacion

WHERE {

?r1 a <http://www.geosparql.ec/reosurce/provincias>.

?r1 rdfs:label ‘LOJA’.


?geo1 a ?geoType;

geo:asWKT ¿figura1.

?r2 a <http://www.geosparql.ec/reosurce/cantones>.



?geo2 geo:asWKT ?ubicacion.

FILTER (geof:sfContains(?figura1, ?ubicacion))

}

http://www.geosparql.ec/reosurce/provincias

http://www.geosparql.ec/reosurce/cantones

81

Prueba 4. Consulta Geosparql 3 – Ríos dobles de la Provincia de Azuay

La consulta deberá devolver como resultado el nombre y las coordenadas de los Ríos que

intersequen la provincia de Azuay. La consulta que nos permite obtener estos resultados es

la siguiente:

Luego de ejecutar la consulta se obtuvo los siguientes resultados:

Figura 30. Resultado de la Consulta Geosparql - Prueba 4 – Ríos Dobles de la Provincia de

Azuay

SELECT distinct ?nombre ?ubicacion

WHERE {

?r1 a <http://www.geosparql.ec/reosurce/rio_doble>.


?r1 geo:hasGeometry ?geo.

?geo a ?geoType;

geo:asWKT ¿ubicacion.

?r2 a <http://www.geosparql.ec/reosurce/provincias>.

?r2 rdfs:label ‘AZUAY’.


?geo2 geo:asWKT ?figura2.

FILTER (geof:sfIntersects(?figura2, ?ubicacion))

}

http://www.geosparql.ec/reosurce/rio_doble

82

Luego de ejecutar las pruebas, se comprobó, que si es posible realizar cálculos

geoespaciales, utilizando las funciones del lenguaje de consulta de geosparql. Ya que los

resultados que se muestran no se encuentran en la información de manera explícita.

También se comprobó el rendimiento de Parliament Triple Store, ya que al realizar estas

pruebas obtuvimos muchas veces error interno en el servidor.

Al ejecutar las consultas en el servidor levantado en un equipo con las siguientes

características:

Portátil con Core i3-3120M 2.5 Ghz con 4 Gb de memoria RAM.

Los resultados obtenidos son 2 resultados positivos de cada 10 intentos de ejecutar la

misma consulta en el servidor. Ocasionando en varias veces el equipo deje de responder.

Por esta razón se procedió a levantar el servidor en un equipo con mejores recursos. El

mismo tiene las siguientes características:

Equipo de escritorio Core i7-3770 3.4 Ghz con 16 GB de memoria RAM.

Obteniendo 6 resultados positivos de cada 10 intentos. El servidor demora en responder y

ocupa entre el 90% y 100% del procesador mientras realiza los cálculos.

83

A pesar de esto, se obtuvo mejores resultados mejorando la infraestructura física del

servidor.

4.3.2.2. Consultas en el endpoint de Parliament desde otras

aplicaciones.

Se procedió a construir una aplicación web que permita consultar el vocabulario propuesto, y

ejecutar consultas geosparql conectándose al endpoint de Parliament, obteniendo los

resultados de las consultas en formato json, para luego ser presentado en nuestra

aplicación, conjuntamente con HTML.

84

Prueba 1. Consulta Geosparql 2 conectándose al Endpoint desde aplicación externa –

Cantones de la Provincia de Loja

Se ejecuto nuevamente la consulta de la prueba 3, pero esta vez se la ejecuto desde una

herramienta externa y se obtuvo los siguientes resultados:

Figura 31. Resultados de la ejecución de la consulta – cantones de la provincia de Loja

En algunos casos al momento de ejecutar las consultas devuelve un error interno del

servidor, siendo esto porque no se pudo ejecutar la consulta en un tiempo determinado, ya

sea por falta de memoria o procesador.

El resultado obtenido fue, que el 70% de las consultas ejecutadas aplicando funciones

geoesparql el resultado fue exitoso, devolviendo los resultados esperados.

Sin embargo el rendimiento aún sigue siendo bajo, sin embargo se obtuvo una mejora del

10% al conectarse desde una aplicación externa.

Otro intento para mejorar el rendimiento del servidor, fue cambiar el tiempo de espera de

respuesta en la configuración del servidor, sin embargo no se notaron cambios en el

rendimiento del servidor.

La solución encontrada para poder seguir utilizando el servidor fue reiniciar el mismo, a

pesar de no ser la vía más factible, sin embargo nos soluciona el problema

85

momentáneamente. . Convirtiéndose este inconveniente una de las desventajas más

grandes de Parliament Triple Store.

4.3.3. Pruebas a la herramienta de visualización.

Para las pruebas del visualizador, es necesario probar las diferentes funciones para graficar

los diferentes objetos geográficos.

El rendimiento de la herramienta de visualización depende de las siguientes herramientas

externas:

Servidor de Tripletas Parliament Triple Store

Servidor de base de datos

Acceso a Open Street Map

En caso de que alguna de estas herramientas no estén disponibles, el aplicativo dejará de

funcionar.

De las cuales la que mayor cantidad de veces ocasiona problemas devolviendo resultados

no esperados es el servidor de tripletas debido al bajo rendimiento del mismo.

Para esta esta etapa de pruebas se utilizara la información correspondiente a la

demarcación de Ecuador, para poder entender de manera fácil e intuitiva los resultados

obtenidos. Adicional a ello se utilizará la información de los aeropuertos del país y de los

ríos.

4.3.3.1. Pruebas de visualización de puntos.

Para probar que se estén graficando correctamente los puntos sobre el mapa de open Street

Map se procedió a graficar todos los aeropuertos del país, obteniendo el siguiente

resultado.

86

Figura 32. Resultado del visualizador – Prueba de visualizar Puntos geográficos -

Aeropuertos de Ecuador

En la imagen podemos observar que cada punto naranja representa a un aeropuerto.

Otra prueba realizada fue graficar un único punto, para lo cual se procedió a graficar el

Aeropuerto Mariscal Sucre de la provincia de Pichincha. Obteniendo el siguiente resultado:

Figura 33. . Resultado del visualizador – Prueba de visualizar un único Punto – Aeropuerto

Mariscas Sucre

87

En la imagen se observa el punto de color naranja que representa la ubicación geográfica

del Aeropuerto Mariscal Sucre.

4.3.3.2. Pruebas de visualización de líneas.

Para probar que se estén graficando correctamente líneas sobre el mapa de OSM, se

procedió a graficar los ríos del Ecuador, obteniendo los siguientes resultados:

Figura 34 Resultado de visualizador - Prueba de visualizar líneas - Ríos del Ecuador

Las líneas que observamos dibujadas sobre el mapa, cada una de ellas representa los ríos

del Ecuador.

4.3.3.3. Pruebas de visualización de polígonos.

Para probar que se estén graficando correctamente polígonos sobre el mapa de OSM, se

procedió a graficar la provincia de Azuay y Zamora Chinchipe, obteniendo los siguientes

resultados:

88

Figura 35 Resultado de visualizador - Prueba de visualizar polígonos – Provincia de

Zamora Chinchipe y Azuay.

En la imagen podemos observar de color verde la provincia de Azuay y de color amarillo la

provincia de Zamora Chinchipe.

Una prueba adicional fue graficar multi-polígonos, como prueba se graficó sobre el mapa de

OSM la provincia de Guayas, la misma que está formada por varios polígonos.

Figura 36. Resultado de visualizador - Prueba de visualizar multi-polígonos – Provincia del

Guayas

89

4.3.3.4. Pruebas de visualización de objetos geográficos utilizando

funciones de Geosparql.

En esta etapa de pruebas se procedió, a aplicar como ejemplo la función geoesparql

Contains. Para ello se procedió a graficar los aeropuertos que se encuentra dentro de la

provincia de Manabi. Los resultados se muestran a continuación:

Figura 37. Resultado de visualizador - Prueba de visualizar resultados de función contains

de Geosparql – Aeropuertos de la provincia de Manabi.

En la imagen se puede observar, que los aeropuertos de la provincia de Manabi están

marcados con puntos de color naranja.

En algunos de los casos la aplicación aparentemente no devuelve resultados, esto se da por

las siguientes razones.

No existe conexión con el servidor de tripletas

El objeto geográfico a graficar no tiene la información necesaria (No existen las

coordenadas en el repositorio semántico)

A la hora de aplicar las funciones geosparql no hay resultados coincidentes.

En este capítulo, se lo dividió en tres apartados que corresponden a:

Desarrollo de la solución

90

En esta etapa se detalla paso a paso todo el proceso que se siguió para implementar las

herramientas diseñadas en el capítulo anterior siguiendo la metodología para generar linked

data con datos geoespaciales.

Implementación

En esta etapa se detalla las herramientas necesarias para poder ejecutar las herramientas

desarrolladas, se brinda un manual paso a paso de como implementar y configurar la

herramienta para extraer de datos, y la herramienta que nos permite visualizar los datos

sobre un mapa de Open Street Map.

Fase de pruebas de las herramientas

En la fase de pruebas se puso a prueba 3 herramientas, primeramente la herramienta que

nos permite extraer los datos desde los shapefile a RDF, en segundo lugar el rendimiento

del servidor de tripletas Parliament Triple Store y finalmente el visualizar de datos

geoespaciales.

91

5. ANÁLISIS DE RESULTADOS

92

Los resultados obtenidos en el desarrollo del presente trabajo de fin de titulación de acuerdo

a los objetivos planteados al inicio del proyecto, obteniendo como resultado un prototipo

funcional que nos permite integrar información geoespacial de diferentes fuentes de

información, visualizar los datos y procesar dicha información, para ayudar a los usuarios a

tener un razonamiento espacial e lograr interoperabilidad con la información seleccionada.

5.1. Integración de información de diferentes fuentes de datos

Como resultado de la integración de información se obtuvo primeramente un total de 29

instituciones gubernamentales que se unieron a la iniciativa de datos abiertos que liberaron

información geoespacial en el formato shapefile, las cuales proporcionan 273 archivos

distribuidos en 11 diferentes categorías.

Para este prototipo y para demostrar que la solución implementada funciona como

mecanismo de integración de datos espaciales de información proveniente de diferentes

fuentes de datos, teniendo en cuenta la diversidad de información que pueda existir se tomó

archivos shapefile, provenientes de n fuentes de datos.

De los cuales se tomaron como muestra 36 archivos shapefile, que se procedió a

transformarlos a RDF obteniendo como resultados que se muestran en la tabla 17.

Resultados de transformación desde Shapefile a RDF.

Se integró de los 36 archivos un total de 27 archivos, que estuvieron en un inicio en diversos

sistemas de coordenadas.

Actualmente se encuentran en formato RDF, en el sistema de coordenadas WGS 84

representados bajo el estándar Geosparql.

Estos archivos generados fueron subidos al servidor Parliament Triple Store, integrando la

información de acuerdo al contenido de los archivos origen y a la configuración que se

realizó para cada archivo a la hora de transformarlo.

93

Tabla 18. Resultados de transformación desde Shapefile a RDF

Nombre del Archivo Origen

Tamaño Tamaño

(MB)

Sistema de Coordenadas

Origen Nombre del Archivo Destino

Tamaño (MB)

Sistema de Coordenadas

provincias.shp INEC 8.33 WGS 85 provincia.rdf 20.24 WGS 84

cantón.shp INEC 17.5 UTM 17S canton.rdf 42.53 WGS 85

Parroquia rural shp INEC UTM 17S parroquia_rural.rdf 0.00 WGS 86

Zona de planificación shp

SENPLADES 6.88 WGS 85 zona_de_planificacion.rdf 16.72 WGS 87

Patrimonio de Área Natural del

Estado (PANE) shp MAE 7.73 UTM 17S pane.rdf 18.78 WGS 88

Bosque y vegetación

protector shp MAE 2.23 UTM 17S bosque_y_vegetacion_protector.rdf 5.42 WGS 89

Reserva de biosfera shp

MAE 0.39 UTM 17S reserva_de_biosfera.rdf 0.95 WGS 90

Zona Intangible shp

MAE 0.34 UTM 17S zona_intangible.rdf 0.83 WGS 91

Unidad hidrográfica

Pfafstetter.shp SENAGUA UTM 17S unidad_hidrografica_pfafstetter.rdf 0.00 WGS 92

Aeropuertos.shp IGM 0.16 WGS 85 aeropuertos.rdf 0.39 WGS 94

Catastro Turístico.shp

MINTUR 0.21 UTM 17S catastro_turistico.rdf 0.51 WGS 95

Centros de Salud.shp

MSP 3.11 UTM 17S centros_de_salud.rdf 7.56 WGS 96

Centros Educativos.shp

MINEDUC 529 UTM 17S centros_educativos.rdf 1285.47 WGS 97

Cuencas.shp IGEPN UTM 17S cuencas.rdf 0.00 WGS 98

94

Ferrocarril.shp MTOP-SPTMF 0.02 UTM 17S ferrocarril.rdf 0.05 WGS 99

Río.shp IGM rio.rdf 0.00 WGS 100

Isla.shp IGM INOCAR 529 UTM 17S isla.rdf 1285.47 WGS 101

Lago.shp IGM 0.05 WGS 85 lago.rdf 0.12 WGS 102

Poblados.shp MIDUVI 0.1 UTM 17S poblados.rdf 0.24 WGS 103

Ciudades Patrimoniales.shp

MDINPC UTM 17S ciudades_patrimoniales.rdf 0.00 WGS 104

Vías.shp MTOP-SPTMF 2.12 UTM 17S vias.rdf 5.15 WGS 105

Subcuencas.shp IGEPN UTM 17S subcuencas.rdf 0.00 WGS 106

Unidades Hidrográficas.shp EPMAPS

0.02 UTM 17S unidades_hidrograficas.rdf 0.05 WGS 107

95

La extracción de los datos desde la fuente de datos, se realizó utilizando el vocabulario

extendido, se añadió información adicional, reutilizando distintos vocabularios para darle un

mayor significado semántico a los datos.

Los datos en formato RDF se pueden enlazar a otros repositorios semánticos.

Teniendo como resultado una efectividad de la herramienta del 72%, los archivos restantes

se desconoce la razón por la que no se pudo transformar a RDF.

5.2. Modelar datos espaciales utilizando datos Geoesparql

Como estándar para representar los datos espaciales se utilizó geosparql. Se representó 27

archivos de diferentes fuentes de información, con diferente información y estructura.

Toda esta información está bajo un mismo estándar.

Se realizó procesamiento de datos espaciales a través de las funciones implementadas en

geosparql.

Queda demostrado que se puede representar cualquier tipo de información espacial bajo

este estándar, abriendo gran cantidad de opciones de estudio para trabajos futuros.

5.3. Explotar los datos enlazados a través de herramientas de

visualización.

Una vez que obtuvimos los datos en formato RDF representados bajo el estándar

Geosparql, se desarrolló una herramienta web que nos permite visualizar la información que

se encontraba en el servidor de datos RDF.

Consultar los datos en este servidor resulta dificultoso para usuarios que desconozcan

lenguaje de consulta sparql.

Para ello se creó un mecanismo que permitan consultar datos de forma sencilla e intuitiva.

Representando los resultados sobre un mapa de Open Street Map, lo que le permitirá al

usuario tener un razonamiento espacial.

Se implementó un mecanismo que permita utilizar las funciones de procesamiento de datos

espaciales de geosparql para procesar la información almacenada en el servidor de tripletas.

96

Sin embargo el servidor de tripletas seleccionado lastimosamente tiene un rendimiento muy

malo a la hora de procesar datos geoespaciales ocasionando que el servidor deje de estar

disponible, hasta un reinicio del mismo.

Para mejorar el rendimiento del servidor se recomienda aumentar las características del

equipo donde se ejecuta Parliament Triple Store, sin embargo por cuestión de recursos

económicos este resulta complicado.

Luego de realizar este análisis en base a la problemática inicial y a la solución propuesta

para cumplir con los objetivos planteados al inicio del proyecto podemos obtener un cuadro

comparativo de las ventajas y desventajas que se tiene al almacenar los datos geográficos

en un archivo shapefile o en formato para la web semántica bajo el estándar geosparql.

Tabla 19. Ventajas y desventajas de utilizar shapefile y RDF bajo el estándar Geosparql

Ventajas de los datos almacenados en

Shapefile

Ventajas de los datos representados en

web semántica utilizando el estándar

Geosparql

Menor espacio en disco

Gran cantidad de herramientas para

procesamiento de datos espaciales

Formato estándar para datos

geográficos

Se puede almacenar la información

en distintos sistemas de coordenadas

Mantiene por separado los datos de

los metadatos

Gran cantidad de herramientas para

visualizar este tipo de archivos

Integración de datos a través de

linked data

Datos geográficos con significado

semántico

Datos listos para ser integrados con

otros datos a través de Linked Data

(Interoperabilidad)

Funciones básicas para

procesamiento de datos

geoespaciales

Rendimiento bajo de las herramientas

disponibles hasta el momento a la

hora procesar datos geoespaciales

bajo el estándar geosparql

Representación de coordenadas en

serialización WKT o GML

Todas las coordenadas en WGS 84

Desventajas de los datos almacenados en

Shapefile

Desventajas de los datos representados

en web semántica utilizando el estándar

97

Geosparql

La mayoría de las herramientas

disponibles para visualizar este tipo

de archivos son pagadas.

Se compone de varios archivos.

Solo puede almacenar una geometría

por tabla

No puede almacenar valores nulos

Falta de rendimiento de las

herramientas disponibles para

procesar datos espaciales.

Necesitan una infraestructura de gran

capacidad para procesar la

información.

Funciones básicas de procesamiento

de datos geoespaciales

Inexistencia de herramientas para

levantar información en este formato

Por la experiencia adquirida en el desarrollo del presente trabajo, es de suma importancia

que se maneje un estándar para el manejo de la información, se recomienda que la

información que liberen estas instituciones, tienen que estar basada en estándares, ya sea

utilizando los estándares definidos por SEMPLADES para el caso de Ecuador, u optar por

los estándares propuestos por OGC para los sistemas de información geográfica

La información debería ser liberada en formatos libres como: txt, CSV, json, GML/XML entre

otros, para permitir consumir dicha información.

Luego de transformar todos estos datos a RDF bajo el estándar Geosparql, utilizando las

herramientas desarrolladas se tiene como resultado: La base de datos no relacional subida

en el servidor de tripletas Parliament Triple Store.y a la vez se puede visualizar esta

información a través del visualizador desarrollado. Esta iniciativa se ha probado con datos

de Ecuador, sin embargo se podría extender a los demás países.

Después de analizar los resultados obtenidos con las herramientas implementadas con el fin

de dar solución a la problemática planteada.

Se determinó que se logró solucionar el problema parcialmente, ya que no se buscó crear

un repositorio geoespacial estandarizado. No se definió un estándar para que todas las

instituciones o personas que se dedican a levantar información lo adopten. Únicamente se

brindó una serie de herramientas que permitan a los usuarios transformar su información a

un formato libre, estandarizado, que permita integrar la información. Centrándonos en la

información almacena en shapefile, primeramente por la cantidad de información que hay y

segundo porque la información publicada en este formato por las diferentes instituciones,

podríamos considerarla como información formal u oficial.

98

Abriendo las puertas para estudios futuros, a través de diferentes ramas, por ejemplo:

Extender la herramienta para que trabaje con otros formatos de archivos como csv,

xls, def, etc.

Implementar un repositorio semántico utilizando las herramientas

Enlazar datos geoespaciales con otro tipo de información.

Mejorar el visualizador, creando o implementando nuevas funcionalidades.

Generar un proceso de transformación inverso con la información enlazada.

Implementar un visualizador de mapas para móviles, que permite realizar consultas

y búsquedas básicas de información.

Servicios de consulta con protocolo REST.

Sin duda alguna existen un sin número de trabajos futuros que se puede desarrollar a partir

de este proyecto.

En este capítulo se analizó los resultados obtenidos con las herramientas desarrolladas,

determinado en cada una de las etapas, como aportaron a la solución de la problemática

planteada, a pesar de que no se logró solucionar como se esperaba debido a la complejidad

del caso y a la magnitud del mismo, sin embargo se brindó una serie de herramientas que

hace un considerable aporte a la solución La herramienta para transformar los shapefile a

RDF nos da una efectividad del 72% a la hora de transformar información, a pesar de no

tener la efectividad buscada o requerida por los usuarios que buscan interoperabilidad de

datos geoespaciales, sin embargo se la puede usar como base para generar datos de

prueba para trabajos fututos.

99

CONCLUSIONES

El presente trabajo de fin de titulación tuvo como objetivo desarrollar un prototipo funcional

que permite integrar información geoespacial proveniente de diferentes fuentes de

información. Luego de implementar la solución planteada se puede concluir lo siguiente:

A pesar de no solucionar en su totalidad la problemática planteada en un inicio, sin embargo

si se brinda una herramienta que nos permita integrar la información a través de la web

semántica, dando una solución parcial al problema.

Las herramientas que nos permite integrar datos geoespaciales provenientes de

instituciones gubernamentales y privadas que han liberado información geográfica,

utilizando tecnología linked data como parte de la iniciativa de datos abiertos. Para el

proceso de conversión de datos geográficos desde formatos shapefile a RDF fue necesario

el desarrollo de una herramienta que permita al usuario hacerlo fácilmente a través de una

interfaz gráfica o de línea de comandos, adaptándose a la estructura del shapefile. Esta

herramienta ha quedado como una librería java para ser consumida desde otra aplicación.

Para todo el proceso se ha trabajado bajo el estándar geosparql.

Las consultas sobre los datos geográficos en formato RDF se presentan utilizando

geosparql como estándar y como extensión del lenguaje de consulta SPARQL, que permite

realizar procesamiento de datos espaciales a través de las funciones que éste tiene

implementadas.

Todos los resultados de este trabajo, tales como documentación técnica y archivos de

prueba están disponibles. La información se encuentra en formato RDF.

Actualmente se han enlazado datos de las fuentes de datos utilizadas en este trabajo, sin

embargo están listos para ser enlazados a fuentes externas tales como dbpedia, u otras

fuentes de datos que se puedan georeferenciar con los conjuntos de datos obtenidos.

Para la visualización de estos datos geográficos generados, se desarrolló una herramienta

web que permite conectarse a cualquier endpoint que contenga una implementación de

geosparql, proporcionando las funciones de navegación a través de facetas. Se puede

visualizar la información geoespacial sobre un mapa de OpenStreetMap y realizar

procesamiento de los datos utilizando algunas funciones de geosparql.

Las funciones para procesamiento de información espacial, a pesar de tener un rendimiento

bastante bajo, brindan una gran utilidad para enriquecer la información.

100

Las herramientas GIS nos brindan un mejor rendimiento y una mayor diversidad a la hora de

realizar procesamiento de datos geoespaciales, sin embargo, es posible realizar un

procesamiento de datos con la extensión de lenguaje de consulta geosparql, siendo este

procesamiento válido para usuarios que buscan únicamente herramientas básicas de

procesamiento de datos geoespaciales.

Se ha verificado que los archivos en formato shapefile son mucho más livianos que los datos

en formato RDF habiendo una diferencia aproximadamente de 240% en relación al peso.

Para el almacenamiento de tripletas de tipo geográfico se utilizó Parliament Triple Store,

porque brinda en su totalidad la extensión de lenguaje de consulta geosparql, sin embargo a

la hora de ejecutar el procesamiento de datos espaciales a través de las consultas

geosparql tiene un rendimiento bastante bajo cuando se procesan grandes volúmenes de

datos, ocasionando respuestas inesperadas por el servidor.

101

RECOMENDACIONES

Para dar continuidad a este proyecto se recomienda utilizar la herramienta desarrollada para

la extracción de información geográfica desde fuentes shapefile, ya que existe gran cantidad

y variedad de información, que puede ser representada en la web semántica, quedando lista

esta para ser enlazada a otras fuentes de información permitiendo el enriquecimiento de la

misma.

En la sección de visualización de este trabajo se pueden incrementar funciones geosparql

para el procesamiento de datos Geoespaciales dentro del visualizador.

Este trabajo de tesis queda abierto a la definición de vocabularios extendidos que permitirán

representar información adicional a las geometrías que contienen los datos geográficos

observados dentro de un archivo shapefile

Es factible la extracción desde diferentes fuentes de datos, como Excel, bases de datos

relacionales entre otros para ampliar las fuentes de datos de consulta

Seguir una metodología de desarrollo de software y a la vez una metodología para generar

linked data, a pesar de la dificultad para llevar ambas metodologías a la par, se obtiene muy

buenos resultados, garantizando la fiabilidad del proyecto.

Las instituciones pueden brindar a sus usuarios la posibilidad de visualizar datos espaciales

proporcionado visualizadores geoespaciales a sus usuarios.

102

BIBLIOGRAFÍA

(OGC), O. G. (2012). OGC. Retrieved from http://www.opengeospatial.org/ogc

Diseño e Dmplementacion de un Repositorio Ecuatoriano de Datos Enlazados Geoespaciales. (2014, Junio). Cuenca, Azuay, Ecuador.

Antonio Morales Nicolás, I. M. (2010, 03). Razonamiento Espacial con Relaciones Cardinales Basado en Problemas de Satisfacción de Restricciones y Lógicas Modales. Universidad de Murcia, 223.

Battle, R., & Kolas, D. (2012). Enabling the geospatial Semantic Web with Parliament and GeoSPARQL. Semantic Web, 355-370.

Berners-Lee, T. (2006, 07 27). Linked Data. Retrieved 06 14, 2014, from http://www.w3.org/DesignIssues/LinkedData.html

bioontology. (n.d.). Comparison of Triple Stores. Retrieved from bioontology.org: http://www.bioontology.org/wiki/images/6/6a/Triple_Stores.pdf

Coors, V. (2015). Ohne smarte Geodaten keine smarten Städte. Fachbeitrag, 248.

Corcho, O. (2011). Map4rdf. Retrieved from http://oeg-upm.github.io/map4rdf/

Elmes, G. A. (2005). GIS and Society: Interrelation, Integration, and. A Research Agenda for Geographic Information, 287.

Group, R. W. (2014, 02 25). Resource Description Framework (RDF).

Jens Lehmann. (2010, 04 20). Linjked GeoData. Retrieved 11 10, 2015, from http://linkedgeodata.org/LGDBrowser

José A. Cajaraville, T. F. (2006). Configuraciones epistémicas y cognitivas en tareas de visualización y razonamiento espacial. In X SIMPOSIO DE LA SEIEM, 7.

Kruchten, P. (1995). Architectural Blueprints—The “4+1” View. Tutorial Proceedings of Tri-Ada, 540-555.

Lapuente, M. J. (2013, 12 08). Hipertexto, el nuevo concepto de documento en la cultura de la imagen. Universidad Complutense de Madrid, 184.

Lieberman, J., Singh, R., & Goad, C. (2007, 07 21). W3c geospatial vocabulary. Incubator group report. W3C.

Luca, D. d. (2011, 07 02). RedUsers Comunidad de Tecnología. Retrieved 06 12, 2014, from http://www.redusers.com/noticias/html5-y-su-importancia-en-la-web-semantica/

MULTIAYUNTAMIENTO, O. -P. (n.d.). Open data Portal de dades obertes. Retrieved 11 11, 2015, from http://opendata.cloudbcn.cat/MULTI/es/what-is-open-data

Open Geospatial Consortium. (2012, 09 10). OGC GeoSPARQL - A Geographic Query Language for RDF Data, 1.0. (M. P. Herring, Editor) Retrieved from https://portal.opengeospatial.org/files/?artifact_id=47664

103

Parliament. (2009, 06). Parliament™ A High-Performance Triple Store, SPARQL Endpoint, and Reasoner. Retrieved from http://parliament.semwebcentral.org/

Randell, D. A., Cui, Z., & Cohn, A. (1992). A spatial logic based on regions and connection. kr, 92, 165-176.

Salas, J. M., Hart, A., Norton, B., Vilches, L. M., De León, A., Goodwin, J., et al. (2011). eoGeo Vocabulary: Defining a shared RDF representation for GeoData. NeoGeo.

Saquicela, V., Espinoza, M., Piedra, N., & Villazón, B. (2014). Ecuadorian Geospatial Linked Data.

SENPLADES. (2013). Catálogo Nacional de Objetos Geográficos Versión 2.0. Quito, Ecuador.

Smartland, UTPL. (2014, 06 12). Smartland. (U. T. Particular, Producer) Retrieved from Smartland: http://smartland.utpl.edu.ec/

Stadler, C. (2015, 07 21). LinkedGeoData.org. Retrieved 11 10, 2015, from http://linkedgeodata.org/About

Stadler, C., Lehmann, J., Höffner, K., & Auer, S. (2012). LinkedGeoData: A Core for a Web of Spatial Open Data. Semantic Web, 333-354.

Vatant, B., & Wick, M. (2012, noviembre). geonames.org. Retrieved 11 10, 2015, from http://www.geonames.org/ontology/documentation.html

Vilches-Blázquez, L. M., Sevilla Sánchez, C., Villalón, M., Rodríguez, A. F., & Gómez Pérez, A. (2013). Combinando Linked Data con servicios geoespaciales. IV Jornadas Ibéricas de Infraestructuras de Datos Espaciales , 10.

Vilches-Blázquez, Manuel, L., Villazón-Terrazas, B., Corcho, O., & Gómez Pérez, A. (2010). GeoLinked data and INSPIRE through an application case. In Proceedings of the 18th SIGSPATIAL International Conference on Advances in Geographic Information Systems, 446 - 449.

W3C. (n.d.). Guía Breve de Web Semántica. Retrieved 05 23, 2014, from W3C: http://www.w3c.es/Divulgacion/GuiasBreves/WebSemantica

104

APÉNDICES

105

Apéndice A. Manual de usuario para cambiar el sistema de coordenadas

al sistema WGS84 de un shapefile

Para ejecutar este proceso se realiza lo siguiente:

1. Abrir ArcMap 10.2.2

2. Crear un mapa en blanco para ello clic en Archivo/Nuevo/Mapa en blanco/Aceptar

Figura 38. Captura de pantalla de Arcmap - Creación de un mapa nuevo en blanco.

3. Añadir el o los archivos shapefile que se necesitar transformar a WGS84 para ello

clic Archivo/Añadir datos/Añadir datos…, se selecciona el archivo *.shp que se

desea añadir y realizar clic en Agregar.

106

Figura 39. Captura de Pantalla de ARCMAP – Añadir información geográfica desde

archivos shape

4. Después de agregar el archivo shape al software, se procede a realizar la

transformación del sistema de coordenadas, para ello se hace clic derecho sobre

Capas, clic en Propiedades, en la pestaña de Sistema de Coordenadas.

107

Figura 40. Propiedades del shapefile - Sistema de coordenadas

Se muestra el sistema de coordenadas actual del shapefile, hacer clic en

Transformaciones.

5. Se selecciona el sistema de coordenadas inicial, Convertir desde: GCS_

WGS_1984 En: WGS 84, en caso de que no haya esta opción pulsamos el botón

agregar, buscamos WGS 84, clic en Aceptar.

108

Figura 41. Ventana de configuración para transformación del sistema de coordenadas

6. Clic en Aceptar.

7. Una vez realizada la trasformación, proceder a exportar los datos en el nuevo

sistema de coordenadas, para ello clic derecho sobre los datos de la capa que se va

a exportar, en este caso aptitud_agricola, datos/Exportar Datos…

109

Figura 42. Ventana de configuración para exportar shapefile en

el nuevo sistema de coordenadas

8. Marcar la opción el marco de los datos, definir la URL de la ruta de salida, con el

nombre del nuevo archivo y clic en Aceptar.

9. Como resultado de este proceso, se obtiene un nuevo archivo shapefile, en el

sistema WGS 84.

Se repite este proceso desde el paso 3, para transformar nuevos archivos shapefile

al sistema de coordenadas WGS 84.

110

Apéndice B. Manual de Usuario – Extraer datos desde fuente shapefile a

sujeto, predicado y objeto.

Para ello se lleva a cabo el siguiente proceso:

Figura 43 Convertir de Shapefile a Sujeto, Predicado y Objeto

La herramienta extrae toda la información que contiene el shapefile y genera un script SQL

de MySQL en forma de tripletas, utilizando dos archivos de configuración en la que se

detalla la forma de extraer los datos.

La información que extrae la herramienta, difiere según el archivo, ya que la estructura de

cada uno de estos archivos puede ser diferente, sin embargo la herramienta adapta la

información bajo la estructura de sujeto, predicado y objeto propuesto, para ello se cambia

los parámetros en los archivos de configuración. Sin embargo es importante tener en cuenta

las recomendaciones realizadas en el apartado 4.1 Extracción de Información.

La herramienta se encuentra disponible en:

https://bitbucket.org/charbelalex/shaperdf.git

https://bitbucket.org/charbelalex/shaperdf.git

111

La herramienta actualmente dispone de interfaz gráfica para permitir de manera sencilla la

extracción de datos, sin embargo adicional a ello permite ejecutar únicamente el archivo jar,

para recibir un archivo de configuración previamente diseñado, siempre y cuando mantenga

la misma estructura.

Para ejecutar la herramienta se abre el proyecto ShapeRdf desde cualquier IDE, ya sea

Netbeans o Eclipse, se recomienda Netbeans 8.0, y se ejecuta el proyecto. (Clic derecho

sobre el proyecto y clic en Run), o ejecutar el archivo jar que se encuentra en la carpeta dist

directamente, ya sea desde consola o con doble clic en Windows.

Figura 44 Ejecutar la Herramienta desde Netbeans ShapeRDF

Una vez que se ha ejecutado el proyecto se despliega la siguiente ventana:

112

Figura 45 Herramienta - Formulario de configurar Conexión a Base de datos

1. Inicialmente pedirá que se configure la conexión a la base de datos MySql. Esto es

opcional, en caso que se desee que los datos se exporten directamente a la base de

datos se deberá configurar en esta ventana, caso contrario la aplicación crea un

script Mysql con la información extraída.

2. Clic en Conectar.

3. Posterior en el menú Herramientas/Extraer Datos o presionar Ctrl + S

113

Figura 46 Herramienta - Abrir herramienta de Extraer Datos

4. La herramienta solicita seleccionar el archivo shape (*.shp)

Figura 47 Seleccionar archivo con extensión *.shp para la extracción de datos

5. Clic en Abrir, la herramienta carga la interfaz que permitirá crear el archivo de

configuración para la extracción, para ello solicita el número de grupos en los que se

114

desea extraer la información, esto se lo obtiene del análisis previo que se realiza al

archivo a exportar, en este caso de ejemplo, parroquia_rural.shp, tiene información

de parroquias rurales, cantones y provincias, por lo tanto se necesita 3 grupos.

Figura 48 Formulario de configurar el número de grupos a crear para la

extracción de datos

6. Clic en Aceptar, posterior a esto se carga la ventana en la que se asignará las

diferentes columnas, a los grupos.

Figura 49 Formulario para clasificar los diferentes campos en objetos

Tener en cuenta de asignar todas las columnas a los grupos, con el fin de extraer toda la

información necesaria.

115

7. Clic en Siguiente, En esta parte se configura la columna que contiene el identificador

del recurso, esto se lo debe realizar por cada grupo creado.

Figura 50 Formulario de configurar el identificador de cada uno de los grupos

8. Hacer clic en Asignar Identificador, posteriormente se procede a configurar el tipo

de información a la que corresponde cada uno de los grupos. Se recomienda que el

tipo sea igual al nombre del archivo correspondiente en el catálogo nacional de

Objetos Geográficos, teniendo en cuenta las recomendaciones para nombrar el

archivo.

116

Figura 51 Formulario para asignar un tipo de objeto geográfico a cada uno de los grupos

9. Clic en Asignar Tipo. Con esto se finaliza la extracción, posteriormente pasar a

configurar las relaciones entre los grupos en caso de existan.

117

Figura 52 Configuración de las relaciones entre los diferentes grupos

En este paso se asigna la relación entre los grupos, según el previo análisis que se realizó al

inicio.

10. Finalmente clic en Extraer Datos, esperar que se ejecute el proceso de extracción,

este proceso podrá tardar varios minutos dependiendo de la cantidad de información

que contenga el archivo Shape.

Figura 53 Mensaje de finalización la extracción de

datos correctamente

118

Todo este proceso se realizó con el fin de crear los archivos de configuración de la

extracción de datos, Los archivos de configuración se podrán ver en el Apéndice J. Archivos

de configuración para extracción de datos.

Para visualizar los datos extraídos se accede a la base de datos, en caso de que la

extracción se haya realizado directamente a la base de datos, caso contrario se puede

encontrar el script en ArchivosSql/nombre_del_archivo_shape.sql, el cual más adelante

se tiene que importar a la base de datos.

Se puede observar que la información se extrajó correctamente en base a la configuración

realizada previamente. Para poder ver mediante interfaz gráfica se accede a través de

phpMyadmin.

Figura 54 Visualización datos extraídos desde phpMyadmin

El flujo de datos que se lleva a cabo al momento de extraer la información desde el shapefile

al sujeto, predicado y objeto es el siguiente:

119

Figura 55 Diagrama de secuencia del convertidor de shapefile a sql

El proceso de transformación se debe repetir para cada uno de los shapefile que se desee

pasar a una base de datos MySQL en forma de tripletas.

El nombre de tabla en el que se insertan los datos en la base de datos MySQL corresponde

al nombre del shapefile que se seleccionó.

120

Apéndice C. Manual de usuario – Limpieza de datos

Para añadir una nueva equivalencia se debe ejecutar la aplicación desde Netbeans, ir al

Menú Configurar/Añadir Objetos a la Limpieza

Figura 56 Abrir herramienta para añadir equivalencia de metadatos

Se presenta un formulario para añadir nuevas equivalencias, en la que se elige el objeto al

que pertenece la equivalencia, la palabra a Buscar sería como se encuentra la información

en el archivo shape y su equivalencia en el catálogo Remplazar.

121

Figura 57 Formulario para añadir equivalencia de Metadatos

Finalmente se presiona el botón Añadir.

Se recomienda agregar cuantos elementos sea necesario con el fin de que la limpieza de

datos se realice de manera correcta y efectiva, obteniendo como resultado una base de

datos para limpieza completa.

La estructura del archivo en que se encuentran los metadatos equivalentes es la siguiente:

122

Figura 58 Estructura del archivo donde se encuentran las equivalencias de los metadatos

El contenido completo del archivo se muestra en el Apéndice E. Vocabulario Propuesto en

RDF

Una vez realizado el proceso de configuración de la limpieza de datos, se procede a limpiar

la base de datos.

Esta limpieza consiste en buscar en la base de datos la información que no está acorde al

catálogo y remplazarlo por su equivalente en el catálogo, siempre y cuando sea posible o

exista esta equivalencia.

Para ello Vamos al menú Herramientas/Limpiar Base de Datos o presionar Ctrl + L.

123

Figura 59 Ejecutar módulo de Limpieza de base de datos

Se muestra una lista con las tablas u objetos disponibles para la limpieza, se selecciona la

tabla que se desea limpiar y clic en Limpiar Tabla.

124

Figura 60 Seleccionar los datos a los que se desea aplicar el proceso de limpieza de datos

Esperar un momento que el proceso de limpieza se ejecute, hasta que se muestre el

mensaje de finalización correcta de la limpieza.

Este proceso se debe repetir cuantas veces sea necesario dependiendo de la cantidad de

tablas que se desee limpiar.

El tiempo de ejecución depende de la cantidad de información que exista en la tabla.

La herramienta desarrollada realiza el siguiente proceso.

Conecta a la base de datos y obtiene los datos

Carga archivo de configuración.

Busca metadatos erróneos.

Remplaza por el equivalente.

Actualiza la base de datos.

Nota: Tener en cuenta que para realizar la limpieza de datos es necesario la conexión a la

base de datos.

Luego de ejecutar la herramienta se obtiene los siguientes resultados.

125

Figura 61 Ejemplo de resultados luego de ejecutar la limpieza de datos

126

Apéndice D. Utilizar vocabulario extendido a la hora de extraer datos

Introducción

Con el fin de presentar una propuesta genérica, y a la vez brindando la opción de extraer

datos desde un shapefile y trasformar la información de dicho archivo en RDF bajo el

estándar GeoSparql y a la vez extraer información adicional que se encuentra en el archivo

permitiendo representar dicha información en RDF, se ha incluido un mecanismo que

permita extraer propiedades personalizadas para cada de archivo shape y a la vez

representar dicha información en RDF. Este mecanismo consiste en buscar el nombre del

archivo en una base de datos que mantiene información de vocabularios extendidos en caso

de que los haya. Esta base de datos consta de dos tablas únicas (tiposhape y vocabulario).

Al momento que se ejecuta la herramienta de transformar SQL a RDF la herramienta toma

el nombre de la tabla seleccionada y busca dicho nombre en la tabla tiposhape, si este es

encontrado en dicha tabla automáticamente la herramienta cargará las propiedades que se

encuentren adheridas a este archivo shape desde la tabla vocabulario para extraer los

datos, en caso de que no se encuentre este nombre en la tabla tiposhape, se extraerá

únicamente la información genérica. Cabe recalcar que para que este mecanismo funcione

se basa en el nombre de la tabla a extraer datos, el mismo que se encuentra bajo un

estándar previamente definido. Para mayor información sobre como nombrar los archivos

consultar el apartado Extracción de datos de shape a SQL.

Ejemplos de Vocabularios

Para pruebas de laboratorio se seleccionó la categoría de demarcación, con la subcategoría

de Organización territorial del Estado del catálogo Nacional de Objetos Geográficos.

En base a la información que contienen dichos archivos se procedió a buscar propiedades

en distintos vocabularios que permitan representar dicha información.

A continuación se presentan los distintos ejemplos:

127

Ejemplo 1 – Provincias

Tabla 20 Ejemplo de vocabulario extendido para recurso provincias

Campo Descripción Prefijo Uri Propiedad

the_geom Geometría del objeto

fcode Código de Identificación del objeto geográfico según el Catálogo Nacional.

gn http://www.geonames.org/ontology#

Code

DPA_PROVIN

Codificación de dos dígitos para cada provincia.

dbpedia-owl

http://dbpedia.org/ontology/

provinceIsoCode

DPA_DESPRO

Nombre de la provincia rdfs http://www.w3.org/2000/01/rdf-schema#

label

DPA_ANIO Año de generación de la información,

js http://www.geo.org/geo/

TXT Texto aclaratorio del objeto

rdfs http://www.w3.org/2000/01/rdf-schema#

comment

TYPE Tipo de objeto geográfico

rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#

type

128

Ejemplo 2 – Cantón

Tabla 21 Ejemplo de vocabulario extendido para recurso Cantón





Code

DPA_CANTON

Codificación de cuatro dígitos para cada cantón.

Dbpedia-owl


provinceIsoCode

DPA_DESCAN

Nombre del cantón rdfs http://www.w3.org/2000/01/rdf-schema#

label





comment



type



129

Ejemplo 3 – Parroquia Rural

Tabla 22 Ejemplo de vocabulario extendido para recurso Parroquia Rural





Code

DPA_PARROQ

Codificación de seis dígitos para cada parroquia.

Dbpedia-owl


provinceIsoCode

DPA_DESPAR

Nombre de la parroquia rural


label





comment



type



130

Agregar vocabularios a la base de datos

Para agregar nuevos vocabularios a la base de datos, hay que basarse en el catálogo

nacional de objetos geográficos.

Primeramente se debe identificar el tipo de archivo shape o el tipo de objeto

geográfico.

Una vez identificado este objeto, se procede a insertar en la tabla tiposhape lo

siguiente.

fcode.- corresponde al Código de Identificación del objeto geográfico según el

Catálogo Nacional, este código se lo encuentra en el catálogo. Por ejemplo

HA004

nombre.- corresponde al nombre del tipo de archivo al que corresponderá el

vocabulario, tener en cuenta que todo debe ir en letras minúsculas, sin

espacios, en caso de que existan remplazar por guion bajo, sin tildes ni

caracteres especiales, por ejemplo parroquia_rural.

Descripción.- descripción correspondiente al tipo de archivo, esta se puede

encontrar en el catálogo,

Fuente.- nombre o acrónimo de la institución generadora del archivo shape.

Esta inserción se la puede realizar en la base de datos a través utilizando la interfaz de

usuario de phpMyadmin, o cualquier otro gestor de base de datos, o desde la consola.

Tener en cuenta que los campos fcode y nombre son obligatorios, los demás son

opcionales y se los puede dejar en blanco.

Luego de haber insertado en la tabla tiposhape, automáticamente se agregarán 3

propiedades correspondientes a este tipo en la tabla vocabulario. Las propiedades que

se agregan automáticamente son the_geom, type, relación. Ya que éstas son

propiedades que todos los archivos tienen.

Posteriormente se debe ingresar las propiedades adicionales en la tabla vocabulario,

asociando dicha propiedad al tipo shape a través del campo fcode. Aquí se debe llenar

los siguientes campos.

Id_tipo.- código correspondiente al valor que se encuentra en fcode en la tabla

tiposhape,- dependiendo del tipo de archivo deseamos asociar la propiedad.

Código.- código de la propiedad en el catálogo nacional de objetos

Geográficos.

131

Nombre.- nombre de la propiedad en el catálogo nacional de objetos

Geográficos

Descripción.- descripción de la propiedad en el catálogo nacional de objetos

Geográficos

Prefijo.- prefijo del vocabulario al que pertenece la propiedad equivalente en

rdf

Uri.- Uri del vocabulario al que pertenece la propiedad equivalente en rdf

Predicado.- predicado que se encuentra en la tabla luego de realizar la

limpieza de los datos. Acción que se realiza posterior a la extracción.

Propiedad.- nombre de la propiedad en el vocabulario equivalente en rdf.

Id.- identificador único de la fila. Este campo se lo deja en blanco ya que se

incrementa automáticamente.

Se debe insertar tantas filas como sea necesario dependiendo de la cantidad de

propiedades que deseemos añadir.

Conclusión

Este mecanismo permite añadir distintas propiedades para realizar una transformación

más efectiva de shape a RDF, realizando la herramienta más escalable y aplicable, sin

embargo es importante que para mantener un orden y que la información se encuentre

bajo un estándar, tener en cuenta las sugerencias y acatarse al catálogo Nacional de

Objetos Geográficos, Sin embargo todo esto queda a decisión del usuario.

132

Apéndice E. Vocabulario Propuesto en RDF

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:thegeom="http://purl.org/dc/terms2/"

xmlns:dcterms="http://purl.org/dc/terms/"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns:dbpedia="http://dbpedia.org/ontology/"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:igeo="http://rdf.insee.fr/def/geo#"

xmlns:gn="http://www.geonames.org/ontology#"

xmlns:place="http://purl.org/ontology/places/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#" >

<rdf:Description rdf:about="geo:asWKT">

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>

<rdfs:label>asWKT</rdfs:label>

<rdfs:comment>Serialización de una geometría en estándar WKT.</rdfs:comment>

<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>

<rdfs:domain rdf:resource="geo:Feature"/>


</rdf:Description>

<rdf:Description rdf:about="dcterms:isPartOf">

<rdfs:comment>isPartOf</rdfs:comment>

<rdfs:label>Relacion</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="geo:asGML">


<rdfs:label>asGML</rdfs:label>

<rdfs:comment>Serialización de una geometría en estándar GML.</rdfs:comment>

<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>

133

<rdfs:domain rdf:resource="geo:Geometry"/>


</rdf:Description>

<rdf:Description rdf:about="geo:Geometry">

<rdfs:subClassOf rdf:resource="sf:Point"/>

<rdfs:subClassOf rdf:resource="sf:MultiLineString"/>

<rdfs:comment>Concepto genérico para un rango taxonómico como un género o

especie.</rdfs:comment>

<rdfs:label>Geometry</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="gn:Code">

<rdfs:comment>Code</rdfs:comment>

<rdfs:label>Código</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="thegeom:the_geom">

<rdfs:comment>the_geom</rdfs:comment>

<rdfs:label>the_geom</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="sf:MultiLineString">

<rdfs:comment>Un MultiLineString es un MultiCurva cuyos elementos son cadenas

lineales.</rdfs:comment>

<rdfs:label>MultiLineString</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="sf:Point">

<rdfs:comment>Un punto es un objeto geométrico dimensional y representa una

única ubicación en el espacio de coordenadas. Un punto tiene un valor de la

coordenada x, un valor de la coordenada y. Si se pide en el sistema de referencia

espacial asociado, también puede tener valores de coordenadas para z y m. El límite

de un Point es el conjunto vacío.</rdfs:comment>

134

<rdfs:label>Point</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="geo:Feature">

<rdfs:comment>Esta clase representa el tipo de entidad de nivel superior. Esta

clase es equivalente a GFI_Feature define en la norma ISO 19156: 2011, y es

superclase de todos los tipos de entidades.</rdfs:comment>

<rdfs:label>Feature</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="geo:hasGeometry">


<rdfs:label>hasGeometry</rdfs:label>

<rdfs:comment>Una representación espacial para una función

determinada.</rdfs:comment>

<rdfs:range rdf:resource="geo:Geometry"/>



</rdf:Description>

<rdf:Description rdf:about="rdfs:label">

<rdfs:label>identificador</rdfs:label>

<rdfs:label>nombre</rdfs:label>

<rdfs:label>Nombre parroquia</rdfs:label>

<rdfs:label>Nombre cantón</rdfs:label>

<rdfs:comment>label</rdfs:comment>

<rdfs:label>Nombre provincia</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="igeo:codeCanton">

<rdfs:comment>codeCanton</rdfs:comment>

<rdfs:label>Código cantón</rdfs:label>

135


</rdf:Description>

<rdf:Description rdf:about="geo:hasDefaultGeometry">


<rdfs:label>hasDefaultGeometry</rdfs:label>

<rdfs:comment>La geometría predeterminada que se utiliza en los cálculos

espaciales. Por lo general es la geometría más detallada..</rdfs:comment>

<rdfs:range rdf:resource="geo:Geometry"/>



</rdf:Description>

<rdf:Description rdf:about="dbpedia:year">

<rdfs:comment>year</rdfs:comment>

<rdfs:label>Año</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="rdfs:comment">

<rdfs:comment>comment</rdfs:comment>

<rdfs:label>Texto Asociado</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="sf:MultiPolygon">

<rdfs:comment>Un MultiPolygon es un MultiSurface cuyos elementos son

polígonos. Las afirmaciones para multipolígonos son los siguientes.

o En el interior de 2 polígonos que son elementos de un MultiPolygon pueden no

cruzarse.

o Los límites de las 2 polígonos que son elementos de un MultiPolygon no

pueden cruzar y puede tocar a sólo un número finito de puntos.

o Un MultiPolygon se define como cerradas topológicamente.

o Un MultiPolygon no debe tener líneas de corte, picos o pinchazos, un

MultiPolygon es un conjunto regular cerrado Point,

o El interior de un MultiPolygon con más de 1 Polígono no está conectado; el

número de componentes conectados del interior de un MultiPolygon es igual al número

136

de polígonos en el MultiPolygon. El límite de un MultiPolygon es un conjunto de curvas

cerradas (cadenas lineales) que corresponden a los límites de sus elementos

polígonos. Cada curva en el límite de la MultiPolygon está en el límite de exactamente

1 elemento polígono, y cada Curva en el límite de un elemento polígono está en el

límite de la MultiPolygon.</rdfs:comment>

<rdfs:label>MultiPolygon</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="dbpedia:provinceIsoCode">

<rdfs:comment>provinceIsoCode</rdfs:comment>

<rdfs:label>Código provincia</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="geo:SpatialObject">

<rdfs:subClassOf rdf:resource="geo:Geometry"/>

<rdfs:subClassOf rdf:resource="geo:Feature"/>

<rdfs:comment>Cualquier cosa con extensión espacial, i.n. tamaño, forma o

posición. por ejemplo personas, lugares, así como las áreas

abstractas.</rdfs:comment>

<rdfs:label>SpatialObject</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="place:Parish">

<rdfs:comment>Parish</rdfs:comment>

<rdfs:label>Código parroquia</rdfs:label>


</rdf:Description>

<rdf:Description rdf:about="rdf:type">

<rdfs:comment>type</rdfs:comment>

<rdfs:label>type</rdfs:label>


</rdf:Description>

</rdf:RDF>

137

Apéndice F. Manual de Usuario – Crear archivo de vocabulario

Una vez ejecutada la aplicación hacer clic en Herramientas Generar Vocabulario o

presionar la combinación de teclado Ctrl+V.

Figura 62 Ejecutar Módulo generar vocabulario

Luego de realizar esto, se espera unos segundos y aparece en pantalla el mensaje de

confirmación que el archivo se ha creado correctamente.

138

Apéndice G. Manual de usuario para transformar a RDF

Para iniciar el proceso de transformación y a la vez generar los archivos RDF, se lleva

a cabo el siguiente proceso:

1. Una vez que se ejecuta la aplicación, se realiza clic en

herramientasTransformar SQL a RDF o presionar la combinación de teclado

Ctrl + R.

Figura 63 Iniciar módulo para transformar datos de SQL a RDF

2. Se abrirá una ventana que permite seleccionar los datos disponibles para

transformar, se selecciona la tabla deseada y se presiona el botón Generar

RDF, este proceso podrá tardar unos minutos, dependiendo de la cantidad de

información que se deba transformar.

3. Cuando el proceso finalice se mostrará un cuadro de diálogo en el que indica

que el archivo se creó correctamente.

139

Figura 64 Seleccionar la tabla que se desea transformar a rdf.

4. Una vez terminado el proceso se ha creado un archivo con el mismo nombre

de la tabla que se seleccionó con extensión rdf, por ejemplo provincia.rdf. El

archivo se crea en el directorio ArchivosRdf.

Figura 65. Fracción de Archivo rdf ejecutado en el ejemplo anterior

140

Apéndice H Manual de Instalación de Parliament

Para instalar parliament Triple Store se utilizó la User Guide de Parliament24, sin

embargo a la hora de instalar se realizó algunos cambios.

Hardware y software utilizado para la instalación

• SO: Windows 8 64 bits, procesador x64

• Procesador: Intel(R) Core i7-3770 CPU @ 3.40Ghz

• Ram: 16.00 GB

Antes de proceder a descargar el “Parliament” se verifica el tipo de sistema operativo

en el que se va a trabajar para poder descargar la versión de “Parliament” que se

adecue con el sistema.

En este caso se va a trabajar con un sistema operativo de Windows de 64 bits y una

versión de “Parliament” de inicio rápido, ya con esta información se dirige a la página

de oficial de Parliament25 y se busca la parte donde dice downloads y se busca el

siguiente archivo:

ParliamentQuickStart-v2.7.4-msvc10-64.zip

Ahora se procede a descargar y descomprimir “Parliament” el cual se puede hacer en

el disco raíz por ejemplo:

C:\ParliamentKB

Ahora se ejecuta lo que es el compilador de visual C ya, porque la instalación se la

realizó en Windows, el nombre de este archivo es vcredist_x64.exe, dependiendo de

la versión del sistema operativo, se encuentra en la siguiente dirección:

C:\ParliamentKB\RedistributablePackages\msvc-10.0-sp1\vcredist_x64.exe

Al ejecutar este compilador se abrirá una ventana muy similar a la siguiente:

24 http://parliament.semwebcentral.org/ParliamentUserGuide.pdf 25 http://parliament.semwebcentral.org/

141

Figura 66. Instalando Parliament

En la cual se acepta los términos y condiciones y se procede a dar clic en Instalar:

142

Figura 67. Progreso de Instalación de Parliament

Una vez concluida la instalación del compilador (vcredist_x64.exe), se procede a

instalar Parliament para ello, se abre una consola como administrador, se dirigen al

fichero donde se descomprimió Parliament, en este caso

C:\ParliamentKB\ se escribe en la consola Parliament desde consola, presionar la

tecla Enter.

C:\ParliamentKB >InstallParliamentService.bat

Luego de instalar el servicio de Parliament, se escribe lo siguiente en la consola:

C:\ParliamentKB >StartParliament.bat

143

Figura 68. Levantando Parliament

Por defecto Parliament se inicia en el puerto 8080 por lo que se puede acceder a ella

en su navegador con la siguiente dirección:

http://localhost:8080/parliament/

En caso de que exista un servicio que se encuentre ejecutando en este puerto, se lo

puede cambiar ingresando al archivo xml desde cualquier editor de texto, este se

encuentra en la siguiente dirección

C:\ParliamentKB\conf\jetty.xml

En la cual se modifica la siguiente línea:

<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

144

Figura 69. Captura Archivo de configuración de parliament

Ya que se encuentra “Parliament” funcionando, hay que realizar un último detalle para

que pueda realizar consultas con Geosparql, lo cual sería crear los índices espaciales

en la siguiente dirección asumiendo de que no se ha modificado el puerto.

http://localhost:8080/parliament/indexes.jsp

Seleccionar la opción de “Create All”. Esto permitirá a su “Parliament” crear índices

espaciales en las nuevas tripletas ingresadas.

Luego de haber realizado esto usted está listo para comenzar a realizar una geo-

consulta.

Nota: La versión de java para que Parliament funcione correctamente se recomienda utilizar JDK 1.7

145

Apéndice I. Manual de Desarrollador

Introducción

La aplicación desarrollada permite transformar información geográfica que se

encuentra en shapefiles a rdf bajo el estándar geosparql, brindando una serie de

herramientas que permitirán generar dicha información partiendo desde los archivos

shape, siguiendo el proceso que propone en el proyecto Ecuadorian Linked Data.

En este documento se describe de manera técnica el desarrollo de la herramienta que

permite transformar información que se encuentra en archivos shape a rdf.

Se describe la arquitectura, estructura de datos y paquetes que permiten implementar

la aplicación y a la vez las herramientas, aplicaciones y librerías a usar.

A lo largo de este documento se detallará, la Arquitectura que se implementó en la

herramienta, se detalla paso a paso el diseño lógico y de desarrollo de la misma, y se

dará paso a paso el desarrollo de cada uno de los módulos.

Propósito

El objetivo de este documento es orientar a personal técnico de desarrollo de software

para el manejo y uso de la herramienta, permitiendo a futuro la corrección de errores,

implementar nuevas herramientas, mantenimiento y reutilización de las mismas.

Arquitectura

146

La arquitectura que se implementó en la herramienta, teniendo en cuenta que es una

aplicación de Escritorio se diseñó una arquitectura de capas, teniendo tres capas que

corresponden a Interfaz de Usuario, lógica y datos. Los módulos desarrollados se

basan en esta arquitectura.

Figura 70 Arquitectura de capas de la herramienta ShapeRDF

Lo módulos desarrollados, están diseñados bajo el estilo arquitectónico 3 capas.

Definiendo y asegurándose que cada una de ellas, cumpla con sus funciones

específicas.

Interfaz o presentación.- en esta capa se maneja básicamente todo lo que es

presentación, aspectos gráficos de la herramienta, formularios, es la que

permite interactuar con el usuario.

Lógica o Negocio.- es donde se incluye toda la lógica de negocio, es decir se

encarga del procesamiento de los datos los datos brindados por la capa de

datos. La capa de presentación ocupa los datos brindado por esta capa.

Datos.- se ocupa del acceso a los datos y de persistir en ellos. Acceso a los

datos, conexión a la base de datos Mysql.

Las ventajas por la que se usó e implementó esta arquitectura es que se asigna

funcionalidades a cada una de ellas, lo que permite reusarlas, esto convierte en una

aplicación escalable, ya que mantiene separadas las diferentes funciones.

Diseño Lógico.

cmp Component View

EnlazadoLimpiezaExtraccion Transformacion

ShapeRDF

LOGICA

DATOS

INTERFAZ

147

Figura 71 Diseño de la herramienta ShapeRDF

148

Diseño de Desarrollo.

Figura 72 Diseño de Desarrollo de la

Herramienta ShapeRDF

Modelo de Base de datos

Figura 73 Diseño de la base de datos de la herramienta ShapeRDF

149

La base de datos para que la herramienta funcione, necesita de la tabla tiposhape y

vocabulario, estas 2 estas tienen una relación de uno a muchos (1 a *)

respectivamente.

Adicional a ello existe un disparador que inserta a la tabla vocabulario, por cada

elemento que se añada a la tabla tiposhape.

Las demás tablas se crean dinámicamente de acuerdo al uso de la aplicación bajo la

estructura que se muestra de ejemplo de provincia en el diagrama de base de datos.

El script de la base de datos se encuentra disponible dentro del directorio

Configuracion/scriptBd.sql

Módulos

Aplicación Principal

Introducción

La aplicación principal básicamente contiene la interfaz de la aplicación, a través de

esta ventana, se puede acceder a las distintas herramientas.

Permite administrar la conexión a la base de datos, brinda información y ayuda de

cómo utilizar las distintas herramientas.

Para el desarrollo de la misma se utilizó la biblioteca de interfaz Swing.

Dentro de este formulario tenemos diferentes elementos

Menú Principal

En este menú se ubican todos los menús que se van a crear

Menú

El menú está compuesto por 3 menús que son:

Herramientas

Permite acceder a todas las herramientas disponibles.

Configuración

Permite acceder a las opciones de configuración de la aplicación

Ayuda

Permite acceder contenido de ayuda de la aplicación

150

Menú Ítem

Extraer Datos

Llama a la herramienta Extraer datos

Limpiar base de datos

Llama a la herramienta para limpiar a la base de datos

Transformar SQL a RDF

Llama a la herramienta que permite transformar datos de Sql a Rdf

Generar Vocabulario

Llama a la herramienta que genera el vocabulario propuesto

Enlazar

Llama a la herramienta que permite enlazar datos a través de Silk

Salir

Permite cerrar la aplicación

Clases

Clase Descripción Capa

FormPrincipal.java Carga la interfaz de la aplicación permitiendo acceder a todas las herramientas a través de esta

Interfaz

FormConfigDb.java Permite configurar la conexión a la base de datos Interfaz

ValidarConexion.java Gestiona la conexión con la base de datos Lógica

ConeccionDb.java Establece la conexión con la base de datos Datos

Métodos

Main()

Este método es el método principal de la aplicación, permite ejecutar la

aplicación, adicional a ello en este menú se encarga de dar la apariencia a la

aplicación.

CentrarVentanaInterna()

Este método se encarga de mostrar los formularios internos en la aplicación

centrados a la ventana. Recibe como entrada un formulario interno

(jInternalFrame).

validar()

Este método retornar un valor de verdadero o falso si se pudo o no restablecer

la conexión con la base de datos. Recibe como datos de entrada en cadena de

texto los siguientes elementos: host, puerto, nombre de la base de datos,

usuario y contraseña.

151

conectar()

Este método establece la conexión con la base de datos. Recibe como datos

de entrada en cadena de texto los siguientes elementos: host, puerto,

nombre de la base de datos, usuario y contraseña.

Módulo de Extracción de datos

Introducción

Este módulo permite extraer los datos de un archivo shape a una base de datos Mysql

o en un script, obteniendo la información, en sujeto predicado y objeto.

Para la extracción previamente se crea archivos de configuración de extracción, para

la creación de los mismos se lo puede hacer a través de interfaz.

Clases


FormConfExtraccion.java Brinda la interfaz gráfica para generar los archivos de configuración y de dependencias para la extracción de datos.

Interfaz

Extracion.java Extrae la información del archivo shape, en base a los archivos de configuración previamente creados, para finalmente devolver un script sql o la información en la base de datos

Lógica


Variables Globales

FeatureCollection collection.- Variable global de tipo FeatureCollecion propio de la

librería Geotools, donde se almacena los datos del shape en memoria.

Métodos

cargarShape()

Este método carga a memoria el archivo shape, a través de la librería

Geotools, recibe como entrada una cadena de texto equivalente a la ruta del

archivo shape.

getNombresColumnas()

Este método devuelve un Arraylist con los nombres de las columnas que

contiene el archivo shape.

152

getDatosShape()

Este método devuelve toda la información disponible del archivo shape en un

FeatureCollection que es una variable propia de la librería Geotools.

extraerDatosABAseDatos()

Este método extrae los datos del archivo shape directamente a la base de

datos, de acuerdo a como se configuró la extracción en los archivos de

configuración. Recibe como entrada el archivo de configuración de grupos y el

de dependencias que básicamente son 2 archivos que almacenan un json de

configuración y el nombre del archivo shape. Tener en cuenta que la

información del archivo shape ya se encuentra en memoria anteriormente.

extraerDatosASql()

Este método extrae los datos del shapefile en un script Sql, de acuerdo a como

se configuró la extracción en los archivos de configuración. Recibe como

entrada el archivo de configuración de grupos y el de dependencias que

básicamente son 2 archivos que almacenan un json de configuración y el

nombre del archivo shape. Tener en cuenta que la información del archivo

shape ya se encentra en memoria anteriormente.

Datos Entrada

Recibe como entrada la ruta del archivo shape. Y 2 json de configuración con la

organización de los grupos para posteriormente extraer los datos.

Datos Salida

Script almacenado en un Archivo .sql con los datos del shape bajo la estructura de

sujeto predicado y objeto. O los datos directamente en la base de datos.

Módulo de Limpieza de Datos

Introducción

Este módulo permite limpiar la información de la base de datos, tratando de que la

información que se encuentra en la base de datos quede bajo los estándares

propuestos ene l catálogo nacional de objetos geográficos. Esto lo realiza a través de

una comparación de la información que se encuentra en la base de datos, con la

información que se encuentra en el archivo Configuración/limpiezaData.json archivo

que se le añade información manualmente bajo una estructura, comparando de forma

manual los metadatos del archivo shape con la del catálogo nacional de objetos

geográficos.

153

Para finalmente actualiza la base de datos.

Clases


FormLimpiarDatos.jar Formulario que permite consultar las tablas

disponibles en la base de datos para

posteriormente ejecutar la limpieza de

datos

Interfaz

FormAniadirDatosLimpieza.ja

r

Formulario que permite añadir metadatos

al archivo limpiezaData.json

Interfaz

Limpieza.java Actualiza la base de datos con la

información que se encuentra bajo los

estándares establecidos en casos de ser

posibles

Lógica


Variables Globales

OntModel model.- Variable global de tipo OntModel propio de la librería Jena, en este

se almacena todo el vocabulario creado.

Métodos

limpiar()

Recibe el nombre de la tabla que se desea ejecutar la limpieza y ejecuta la

limpieza en la base de datos, retornando el valor de verdadero o falso si la

misma se ha ejecutado.

consultarTablas()

Devuelve una lista de las tablas que están disponibles para ejecutar la limpieza

de datos.

añadirLimpieza()

Añade elementos al archivo de configuración limpiezaData.json recibiendo

como parámetro la tabla en la que se desea añadir, el valor a buscar y la

palabra a remplazar.

Datos Entrada

El módulo de limpieza recibe como entrada el nombre de la tabla que se desea limpiar,

los datos en la base de datos y un archivo json de configuración de la limpieza con los

metadatos a buscar y remplazar bajo la estructura propuesta.

154

Datos Salida

El modulo ejecuta actualizaciones en la base de datos directamente remplazando por

el metadato equivalente.

Módulo Generar Vocabulario

Introducción

El modulo genera un archivo llamado vocabulario.rdf que contiene el vocabulario

propuesto bajo el estándar geosparql en rdf, adicional a ello genera el vocabulario

propuesto para hacer archivos específicos, esto lo hace utilizando la base de datos.

Clases


Principal Permite iniciar la herramienta que genera el vocabulario Interfaz

GenerarVocabulario.java Genera el vocabulario en rdf Lógica

Vocabulario Crea los prefijos, clases y propiedades del vocabulario Geosparql

Lógica

Wkliteral Permite generar y representar las coordenadas geográficas en WKT

Lógica

ConeccionBd Establece la conexión con la base de datos Datos

Variables Globales

Métodos

generarVocabulario()

Recibe una cadena de texto que equivale a la ruta del archivo donde se desea

almacenar el archivo a crear. Llama a los métodos

generarVocabularioGeosparql() y generarVocabularioExtendido().

generarVocabularioGeosparql()

Este método crea la parte del vocabulario que corresponde a geosparql, sus

clases propiedades, a la vez agregándole sus respetivas etiquetas(label) y

comentarios(comment).

generarVocabularioExtendido()

Este método crea la parte del vocabulario extendido, para ello utiliza la

información que se encuentra en la base de datos, en las tablas tiposhape y

vocabulario.

crearArchivo()

Este método recibe como parámetros de entrada el modelo o model de tipo

OntModel método propio de la librería Jena, que contiene en memoria todo lo

155

que corresponde a vocabulario creado y la ruta donde se desea almacenar el

archivo para finalmente crear el archivo.

crearPropiedad()

Este método permite crear una propiedad en rdf, recibe como entrada cadenas

de texto con el prefijo, nombre de la propiedad, etiqueta o label y la descripción

de la propiedad, está la añada directamente a la variable global model.

crearClase()

Este método permite crear una clase en rdf, recibe como entrada cadenas de

texto con el prefijo, nombre de la clase, etiqueta o label y la descripción de la

clase, está la añada directamente a la variable global model.

Datos Entrada

Recibe como entrada la ruta donde se desea almacenar el archivo a crear y la

información de las tablas tiposhape y vocabulario, esta información la lee directamente

de la base de datos por lo que se debe asegurar de que existan en la base de datos,

los script de estas 2 tablas lo puede encontrar en el directorio

Configuración/vocabulario.sql

Datos Salida

Como salida se obtiene un archivo vocabulario.rdf con el vocabulario en rdf en la ruta

especificada.

Módulo Transformación de SQL a RDF

Introducción

Este módulo permite transformar información geográfica que se encuentra en una

base de datos relacional en forma de sujeto predicado y objeto a un archivo rdf con la

misma información pero representada en rdf bajo el vocabulario propuesto geosparql.

Clases


FormGenerarRdf.java Presenta las tablas disponibles para

transformar a rdf

Interfaz

GenerarRdf.java Realiza la transformación de la información Lógica

156

que se encuentra en la base de datos bajo la

estructura de sujeto predicado y objeto a rdf

ConeccionBd.java Establece la conexión con la base de datos Datos

Variables Globales

String nombreTabla.- se mantiene como variable global el nombre de la tabla que se

desea transformar

Model model.- es la variable donde se almacenará toda la información en rdf a crear.

ConecciónBd coneccionBd.- mantendrá la conexión a la base de datos activa para

obtener la información de la base de datos.

JSONObject vocabulario.- carga la información del vocabulario que se encuentra en

la base de datos en un json.

Métodos

getMD5()

Este método transforma la cadena de texto de ingreso a codificación MD5

devolviendo la misma cadena de texto pero bajo esta codificación.

Rdf()

Este método transforma la información de la base de datos a rdf. Tiene como

parámetro de entrada el nombre de la tabla a transformar, sin embargo utiliza

el json de vocabulario para poder realizar el proceso almacenando toda la

información en rdf en la variable global model.

crearRdf()

Este método crear un archivo con el nombre de la tabla seleccionada para la

transformación y extensión rdf escribiendo en el archivo la información que

contiene la variable global model.

getVocabulario().

Consulta el vocabulario de la base de datos y lo pone en una estructura de json

para que el método de Rdf() pueda trabajar en base a este.

consultarTablas()

Consulta las tablas de la base de datos disponibles para la transformación,

devolviendo como resultado un ArrayList con los nombre de las tablas

Datos Entrada

157

Recibe como datos de entrada el nombre de la tabla a transformar y el vocabulario que

se encuentra en la base de datos.

Datos Salida

Devuelve un archivo con extensión .rdf dentro del directorio

ArchivosRdf/nombre_de_la_tabla.rdf con los datos transformados.

158

Apéndice J. Archivos de configuración para extracción de datos

Archivo Configuración de grupos

La información de este archivo corresponde a los grupos creados para la extracción de

datos, en este archivo se define los atributos que pertenece a cada grupo u objeto

geográfico, el tipo de objeto y el identificador del objetos.

La extensión del archivo es *.json, se encuentra en

ShapeRdfDemo\Configuracion\conf_grupos.json

La información de este archivo variará dependiendo del archivo shape a extraer, sin

embargo es importante que se mantenga su estructura.

Atributos.- es importante que estén igual a los nombres de las columnas del archivo

shape, la coincidencia debe ser en mayúsculas y minúsculas.

Tipo.- se recomienda mantener todo en letras minúsculas sin espacios, estos deberán

ser remplazados por guion bajo en caso de ser necesario, la cadena de texto tiene que

estar basada en el catálogo nacional de objetos geográficos, en caso de que no exista

se puede utilizar otro valor, el que deberá ser un nombre descriptivo a la información

que contiene el archivo shape.

Identificador.- corresponde al nombre de la columna que contiene el identificador

único del recurso, esta deberá ser una columna que contenga un valor único,

descriptivo del recurso. En caso de que no exista podrá ser un atributo que tenga el

valor vacío.

159

Figura 74 Archivo de configuración para extracción de grupos Ejemplo

parroquias_rurales.shp

Archivo Configuración de relaciones

Este archivo contiene la configuración de las relaciones entre los grupos, para poder

extraer la información.

Este es un archivo de extensión *.json, se encuentra en

ShapeRdfDemo\Configuracion\conf_dependencia.json

Posee elementos que van numerados desde el 1 hasta n-1, siendo n el número de

grupos creados en el archivo de configuración de grupos. En caso de que exista un

único grupo este archivo deberá ir vacío.

Para cada elemento de este archivo existen los siguientes atributos.

160

Sujeto.- es un valor numérico en el que define el número del grupo de origen de la

relación, el que pasará a ser el sujeto en la extracción de datos.

Objeto.- es un valor numérico en el que define el número del grupo de destino de la

relación, el que pasará a ser el objeto de la relación en la extracción de datos.

Identificador.- corresponde al nombre de la columna del objeto o destino de la

relación, es importante que sea el mismo nombre que se definió como identificador en

la creación de grupos, este nombre corresponde al destino de la relación.

Figura 75 Archivo de configuración de relaciones - Ejemplo parroquias_rurales.shp

161

Apéndice K. Manual del Programador – Visualizador de Datos

Introducción

La siguiente herramienta, permite consultar y explotar la información almacenada en el

Parliament Triple Store, brindando una interfaz para poder consultar la información y

realizar un procesamiento de datos geoespaciales, representando los datos

gráficamente sobre un mapa de Open Street Map (OSM), permitiéndole al usuario final

tener un razonamiento espacial.

Arquitectura

La herramienta se implementó bajo la arquitectura propuesta que es:

Figura 76Arquitectura del visualizador de datos

Es una herramienta Web implementada con una interfaz de usuario escrita en HTML,

permitiendo interactuar al usuario con la herramienta a través de javascript, jsp y ajax.

Accediendo a la información de la base de datos a través de la capa de persistencia

utilizando como ORM Hibernate, para finalmente consumir los datos del endpoint

utilizando Jena.

Para Ejecutar la Herramienta

Para ejecutar la herramienta web es necesario tener lo siguiente:

Aplicación Web.- Servidor de aplicaciones, Glassfish 4.1, JVM, JDK 1.8.

Base de Datos.- Base de datos Mysql


Extraer

INTERFAZ

LOGICA

Limpiar

Vocabulario

GenerarRDFGeoTools

JENA

JSON SIMPLE

DATOS

CONECTOR MYSQL

HERRAMIENTA SOFTWARE APLICACION WEB

persistencia

Serv icios

BASE DE DATOS

INTERFAZ (HTML)

SERVIDOR ENDPOINT (

PARLAMENT )

RECUPERA DATOS

RETORNA JSONCONSUME

CONSULTA GEOSPARQL

162

Servidor de Tripletas.- Es necesario contar con servidor de tripletas Parliamant

Triple Store versión 2.7.6, el sistema operativo debe contar con el jdk 1.7 o superior.

Un navegador con conexión a internet, preferiblemente google chrome o Microsoft

Edge.

Vista Física

La presente vista muestra los dispositivos físicos necesarios para la ejecución de los

módulos de software planteados, las plataformas necesarias y los sistemas de

software que se desplegarán en cada una de los dispositivos.

Figura 77 Vista Física Aplicación Web

Se utilizará dos dispositivos físicos para el funcionamiento de la solución:

Máquina de escritorio.- es una máquina normal con un sistema operativo (Windows,

Linux o Mac) y contener los paquetes de software detallados en la vista de

implementación. Los requerimientos recomendados para la ejecución óptima del

aplicativo son los siguientes:

Espacio en disco: 50GB (Dependiendo de la cantidad de información a

procesar)

Memoria Ram: 4GB

Procesador: Core I3, 2.4Ghz

deployment Deployment Model

«device»

Maquina de Escritorio

«device»

Serv idor

HERRAMIENTA DE

SOFTWARE

Aplicacion Web

Parlament

163

Servidor.- en este dispositivo se encontrara desplegada la aplicación web y el servidor

de tripletas Parliament. Los requerimientos recomendados para la ejecución óptima de

los aplicativos son los siguientes:

Espacio en disco: 100GB (Dependiendo de la cantidad de información a

procesar)

Memoria Ram: 16GB

Procesador: Intel Core I7 3770, 3.4Ghz o similar

Si puede ser un servidor con mejores características, mejorará el rendimiento de la

tienda de tripletas Parliament Triple Store.

Estructura del Proyecto

Interfaz

La interfaz de usuario se encuentra en el archivo index.jsp, en este archivo se carga

los objetos e instancias de objetos disponibles en el servidor de tripletas.

Para realizar esto la herramienta consulta al servidor de tripletas, y crea una lista con

los objetos disponibles almacenando esta información en la base de datos MySql.

A través del ORM Hibernate se accede a la información de la base de datos y se

presenta los objetos e instancias disponibles en los menús de Objetos, Facetas y

consultas. Creando la interfaz amigable para que el usuario pueda consultar la

información disponible en el endpoint. Para posteriormente representar los datos

consultados sobre un mapa de OSM.

En la sección de objetos se presenta una lista con los objetos e instancias de objetos

disponibles.

En la sección de facetas igualmente se muestran los objetos e instancias de objetos

disponibles, pero esta vez están agrupadas de acuerdo al tipo de objeto, facilitando la

búsqueda de los elementos a graficar.

En la sección de consulta se muestra un formulario en la que permite seleccionar 2

geometrías disponibles en la tienda de tripletas y procesar esta información espacial a

través de la consulta geoesparql utilizando las funciones previamente definidas, las

mismas que se detallan en Tabla 16 Funciones predefinidas para procesamiento de

datos espaciales utilizando consultas geosparql.

164

Funciones Java

Las funciones creadas utilizan el ORM hibernate para acceder a consultar la base de

datos, y también para alimentar la misma.

Consumir Base de datos

buscarAllObjetos.- esta función consulta todos los objetos e instancias de objetos

disponibles en la base de datos.

BuscarAllFacetas.- esta función consulta todos las facetas e instancias de objetos

disponibles en la base de datos.

Alimentar Base de datos

crearObjetos.- permite alimentar la base de datos con la información obtenida del

servidor de tripletas.

Funciones JavaScript

Las funciones de javascript se encentran en el archivo funciones.js dentro del

directorio js. Las funciones implementadas son las siguientes.

graficarDatos.- esta función permite graficar líneas y polígonos en el mapa, recibe

como datos de entrada, los coordenadas geográficas a graficar, si se desea que se

marque o desmarque la figura y el color con el que se desea pintar la figura.

Como salida tiene los datos graficados sobre el mapa de OSM.

graficarPuntos.- esta función permite graficar puntos en el mapa, recibe como datos

de entrada, los coordenadas geográficas del punto o puntos a graficar, si se desea que

se marque o desmarque el punto y el color con el que se desea pintar el punto.

Como salida tiene el punto graficado sobre el mapa de OSM.

consultarCordenadasObjeto.- esta función llama a un Web Service dependiendo del

tipo de dato que se desea consultar. Recibiendo como datos de entrada, el objeto a

graficar, el tipo de objeto y el campo seleccionado. Como resultado se obtiene los

datos limpios para ser graficados, ya sea por la función graficarDatos o graficarPuntos,

sin embargo en medio de este proceso llama a otras funciones ya sea limpiar o

limpiarVarios, los que retornan los datos limpios de acuerdo al formato que necesita

OSM para ser graficados.

165

Limpiar.- limpia la información que viene del servidor de tripletas eliminando

elementos adicionales no necesarios para graficar sobre OSM, cuando el valor que

devuelve el ws es correspondiente a uno solo. Recibe como dato de entrada el

elemento con la información que viene directamente del servidor de tripletas. Como

resultado retorna una cadena limpia para ser graficada sobre OSM,

limpiarVarios.- limpia la información que viene del servidor de tripletas eliminando

elementos adicionales no necesarios para graficar sobre OSM, cuando el valor que

devuelve el ws es correspondiente a más de un elemento. Recibe como dato de

entrada los elementos con la información que viene directamente del servidor de

tripletas. Como resultado retorna una cadena limpia para ser graficada sobre OSM,

SeleccionarRif.- esta función no recibe parámetros de entrada, sin embargo a través

de java script se obtiene los valores de las listas que se seleccionaron las geometrías

a procesar y la función con la cual se va a realizar el procesamiento de datos

espaciales. Consumiendo un ws que se encarga de armar la consulta Geosparql,

ejecutarla y retornados los resultados de la consulta, con los datos previamente

obtenidos a través de java script. Esta función tiene inicio en el momento en que los

usuario realizan clic sobre el botón visualizar.

Servicios Web

Se implementaron 3 servicios web que permiten realizar las consultas al endpoint de

Parliament Triple Store. Los servicios implementados son:

Consultar.- recibe como parámetro de entrada el objeto y el tipo, devolviendo los

resultados que sean del tipo especificado y que en la etiqueta label contengan el valor

del objeto solicitado.

consultarVarios.- únicamente se recibe el tipo de los objetos a consultar y se

devuelve una cadena de texto con todas las coordenadas de los objetos que son del

tipo indicado.

consultarCalcular.- este recibe como parámetro los objetos o instancias de objetos

de cada geometría a buscar y la regla de procesamiento de datos geoespaciales a

aplicar. Devuelve como resultado la o las geometrías obtenidas luego de realizar el

procesamiento de datos.

Para alimentar la base de datos hay que ejecutar los siguientes archivos

insertarobjetos.jsp e insertarinstancias.jsp, estos script consultan al servidor de

166

tripletas los objetos e instancias de objetos disponibles y los almacena en la base de

datos relacional. Es importante que se ejecuten en ese orden.

Para ejecutar la herramienta

Descargar el proyecto desde:

https://[email protected]/charbelalex/visualizadorrdf.git

Importar la base de datos a Mysql, el script se encuentra dentro del proyecto

Visualizador_db.sql

Abrir el proyecto desde el IDE de preferencia

Cambiar la conexión a la base de datos en el archivo persitence.xml

Configurar la dirección del servidor de tripletas en la siguiente variable:

String uriEndpoint:localhost:8888/parliament/sparql

Clic derecho sobre el proyecto, clic en Clean and Built

Clic derecho sobre el proyecto, clic en RUN

Nota: Tener en cuenta que el servidor de tripletas se encuentre levantado.

https://[email protected]/charbelalex/visualizadorrdf.git

UNIVERSIDAD TÉCNICA PARTICULAR DE...

Documents

Transcript of UNIVERSIDAD TÉCNICA PARTICULAR DE...