103907 by UNIGIS América Latina

Master Thesis ǀ Tesis de Maestría submitted within the UNIGIS MSc programme presentada para el Programa UNIGIS MSc at/en

Interfaculty Department of Geoinformatics- Z_GIS Departamento de Geomática – Z_GIS University of Salzburg ǀ Universidad de Salzburg

GEOPROCESAMIENTO ONCLOUD COMPUTING CON SISTEMAS NOSQL Y RDBMS CASO DE ESTUDIO: MANIPULACIÓN DE DATOS GPS EN LATINOAMÉRICA GEOPROCESSING IN CLOUD COMPUTING WITH NOSQL AND RDBM SYSTEMS CASE STUDY: GPS DATA MANIPULATION IN LATIN AMERICA by/por

José Miguel Victoria Urresti 01422558

A thesis submitted in partial fulfilment of the requirements of the degree of Master of Science (Geographical Information Science & Systems) – MSc (GIS)

Bogotá D.C.- Colombia, febrero de 2017

COMPROMISO DE CIENCIA Por medio del presente documento, incluyendo mi firma personal certifico y aseguro que mi tesis es completamente el resultado de mi propio trabajo. He citado todas las fuentes que he usado en mi tesis y en todos los casos he indicado su origen.

José Miguel Victoria Urresti CC 1130617433 Bogotá D.C., 2 de agosto de 2017

Victoria Urresti, José Miguel

A mis padres y hermanos, en especial a mi madre por estar siempre presente, más allá de la distancia. A mis amigos y compañeros, por brindarme su ayuda en el momento preciso. A toda mi familia por la alegría transmitida al verme encaminar mis metas. José Miguel Victoria Urresti.

Victoria Urresti, José Miguel

Agradecimientos Manifiesto mis sinceros agradecimientos a:

A mis padres y hermanos por su apoyo, comprensión y acompañamiento continúo.

A Laure Collet y Anton Eitzinger, por ser tan diligente en cada inquietud o inconveniente durante la finalización del ciclo de proyecto.

A todos los instructores y comité del Programa de Posgrado en Sistemas de Información Geográfica de UNIGIS América Latina de la promoción 2014A

A mis amigos y compañeros que son especialistas o conocedores del tema que aborda esta investigación y que con sus sabios consejos siempre aportaron de manera positiva a mi proyecto

Finalmente, a todos y cada una de las personas que directa o indirectamente con sus buenos deseos siempre dieron una voz de aliento en cada momento crítico durante este camino.

¡Gracias!

Victoria Urresti, José Miguel

Resumen Con el crecimiento acelerado del uso de dispositivos y aplicaciones móviles en el mundo, los datos geo-etiquetados o de localización son cada vez más relevantes para la gestión de datos en tiempo real. No obstante, dado su rapidez de adquisición, el almacenamiento en sistemas de gestión centralizados tradicionales sufren de limitaciones inevitables, debido a escalamiento de los grandes volúmenes de entrada. Paralelamente, en la última década, las tecnologías en la publicación de datos geoespaciales vía internet están en auge, como también la adopción de normas para el intercambio de información geográfica siguiendo los conceptos de la Infraestructura de Datos Espaciales (IDE). Sin embargo, seguir estos paradigmas de procesamiento espacial no resultan eficientes cuando se maneja gran cantidad de datos que se deben recopilar, publicar y/o editar en tiempo real. Para esta investigación se estudió la viabilidad del geoprocesamiento Web de datos GPS (Global Positioning System) masivos en 16 países de Latinoamérica procedentes de una plataforma LBS (Location Based Services). Los datos se gestionaron desde bases de datos espaciales relacional (PostgreSQL) y NoSQL (MongoDB) y fueron publicados como servicios OGC (WMS, WFS, WFS-T), teniendo en cuenta una infraestructura de servicio Web en la nube Amazon (AWS). Se compararon los beneficios de usar cada almacén de datos para la integración de datos geoespaciales. Para esto, se definieron dos experimentos, el primer experimento probo el rendimiento de carga y la capacidad de consulta concurrente y espacial con los datos. El segundo experimento evaluó el comportamiento de interoperabilidad entre almacén de datos, servidor de mapas y un cliente cartográfico Web. Para cada experimento se definieron diferentes escenarios: sub conjuntos de datos, rangos de tiempos y operaciones espaciales básicas. Basado en el procedimiento metodológico de esta investigación, se evidencio que, desde una aplicación Web moderna en la nube, se pueden gestionar grandes bancos de datos. Sin embargo, MongoDB ofrece mejores resultados, la disponibilidad y velocidad en el retorno de datos geográficos desde servicios de OGC fue mejor a la de PostgreSQL. En este sentido, la metodología fue viable y puede aplicarse para la creación de servicios geoespaciales que gestionen fenómenos como incidentes, tráfico y rastreo vehicular. Dado las ventajas y desventajas de cada alternativa tecnológica implementada, se sugiere tener presente las mejoras de dichas tecnologías o la aparición de nuevas tecnologías geoespaciales similares a esta investigación. Por lo tanto, permitirá tener un panorama amplio acerca de la rentabilidad de usar o no una arquitectura en la nube o tipo de base de datos espacial específica, que se adapte a la lógica de negocio o una nueva investigación con temática diferente.

Palabras Claves: OGC, RDBMS, GPS, Cloud Computing, NoSQL.

Victoria Urresti, José Miguel

Abstract With the growing use of mobile devices and applications worldwide, geo-tagged or spatial data are becoming more relevant to real-time data management. However, given its fast acquisition, traditional centralized storage management systems suffer from inevitable limitations due to the large volumes of data. In parallel, in the last decade, technologies in publishing geospatial data via the internet is booming, as well as the adoption of standards for the exchange of geographic information following the concept of a Spatial Data Infrastructure (SDI). However, following these paradigms of spatial processing is not efficient for collecting, handling, publishing and/or editing a large amount of data in real time. In this research, the feasibility of geoprocessing of large volumes of data GPS (Global Positioning System) in 16 Latin American countries from an LBS (Location Based Services) platform is studied. Data were managed from spatial relational (PostgreSQL) and NoSQL (MongoDB) databases and published as OGC services (WMS, WFS, WFS-T), considering an Amazon Web service infrastructure (AWS). We compared the benefits of using each datastore for the integration of geospatial data. For this, two experiments were defined, first tested the load performance and the capacity for concurrent and spatial queries with the data. The second experiment evaluated the interoperability behavior between a datastore, a map server and a Web mapping client. For each experiment, different scenarios were defined: sub sets of data, time ranges and basic spatial operations. Based on the methodological procedure of this research, it was proven that, from a modern Web application in the cloud, large data banks can be managed. However, MongoDB offers better results, the availability and speed of return of geographic data from OGC services was better than with PostgreSQL. In that respect, the methodology was feasible and can be applied for the creation of geospatial services that manage phenomena such as incidents, traffic and vehicle tracking. Given the advantages and disadvantages of each implemented technological alternative, itâ&#x20AC;&#x2122;s suggested to keep in mind the improvements of these technologies or the appearance of new geospatial technologies like this research. Therefore, it will allow a better prospect about the profitability of using an Cloud architecture or specific spatial databases types, which adapt to the similar business logic or a new research with a different topic. Palabras Claves: OGC, RDBMS, GPS, Cloud Computing, NoSQL

Victoria Urresti, JosĂŠ Miguel

Índice General 1.

INTRODUCCIÓN

1.1

ANTECEDENTES DEL PROBLEMA

1.2

OBJETIVO GENERAL

1.3

OBJETIVOS ESPECÍFICOS

1.4

PREGUNTAS DE INVESTIGACIÓN

1.5

HIPÓTESIS

1.6

JUSTIFICACIÓN

1.7

ALCANCE

MARCO TEÓRICO

2.1

BIG DATA

2.1.1 Big Data Espacial

2.2

CLOUD COMPUTING

2.3

SERVICIO WEB

2.4

DEFINICIÓN DE BASE DE DATOS

2.4.1 Teorema del CAP

2.4.2 Propiedades ACID

2.4.3 Propiedades BASE

2.4.4 Escalamiento Vertical Y Horizontal

2.4.5 Sistema De Gestión Datos Relacional

2.4.6 Sistema De Gestión De Datos NoSQL

2.4.7 DBaaS

2.5

OGC

2.6

GeoJSON

2.7

SISTEMA GLOBAL DE NAVEGACIÓN POR SATÉLITE

2.8

TECNOLOGÍAS Y PROYECTOS BASE DE LA INVESTIGACIÓN

2.8.1 Tecnologías Cliente-Servidor

2.8.2 Investigaciones Relacionadas

METODOLOGÍA

3.1

DEFINICIÓN DE ZONA E INFORMACIÓN DE ESTUDIO

3.1.1 Zona geográfica Efectiva

3.1.2 Caracterización de la Información

3.1.2.1 Información Geográfica GPS

3.1.2.2 Información Geográfica de Clientes WT

Victoria Urresti, José Miguel

3.1.2.3 Información Geográfica para Georreferenciación

3.2

ANÁLISIS DE REQUERIMIENTOS

3.2.1 Requerimientos no Funcionales del Sistema

3.2.2 Requerimientos Funcionales del Sistema

3.3 SELECCIÓN DE ALTERNATIVAS TECNOLÓGICAS Y SISTEMAS NOSQL/RDBMS

3.3.1 Definición de Software Geoespacial

3.3.2 Descripción de Entorno Hardware

3.4

DEFINICIÓN DE AMBIENTE EN BASES DE DATOS

3.5

PANORAMA DE CONSULTAS E IMPLEMENTACIÓN

3.5.1 Niveles de la Arquitectura Implementada

3.5.2 Integración y consumo desde servicios de OGC

3.6

IMPLEMENTACIÓN DE EXPERIMENTOS Y PROTOTIPO WEB

3.6.1 Experimento 1: Análisis a nivel almacén de datos

3.6.2 Experimento 2: Interoperabilidad a través servicios de OGC

RESULTADOS

4.1

Experimento 1: Análisis a nivel almacén de datos

4.2

Experimento 2: Interoperabilidad a través servicios de OGC

DISCUSIÓN

CONCLUSIONES

REFERENCIAS

APÉNDICE A. Instalación MongoDB en Amazon EC2

APÉNDICE B. Instalación PostgreSQL-PostGIS en Amazon EC2

APÉNDICE C. Instalación Geoserver y Apache en Amazon EC2

APÉNDICE D. Instalación soporte de MongoDB en Servidor Geoserver

APÉNDICE E. Estructura de los datos

APÉNDICE F. Tareas de Depuración de datos

101

APÉNDICE G. Demostración de WFS Transaccional

103

Victoria Urresti, José Miguel

Glosario ACID: Atomicity, Consistency, Isolation and Durability (en español Atomicidad, Consistencia, Aislamiento y Durabilidad) AJAX: Asynchronous JavaScript And XML (en español JavaScript asíncrono y XML) API: Application Programming Interface AWS: Amazon Web Services (en español Servicio Web de Amazon) BASE: Basically Available, Soft state, Eventually consistent DBaaS: Database as a service (en español: Base de datos como servicio) CAP: Consistency, Availability, Partition Tolerance (en español: consistencia, disponibilidad, toleracia al particionado). CPU: central processing unit (en español; unidad de procesamiento central) CRUD: Create, Read, Update and Delete (en español: Crear, Obtener, Actualizar y Borrar) CSV: Comma Separated Values (en español: valores separados por coma) DBMS: Database Management System (en español: Sistema de Gestión de Base de Datos). EC2: Elastic Compute Cloud (en español: computación elástica en la nube) GB: GIGABYTE, acrónimo compuesta de las palabras Giga (Termino griego que significa gigante) y Byte, unidad de información base utilizada en computación. GiST: Generic Index Structure (en español: Estructura de Indice Generico) GML: Geography Markup Language GNU: GNU's Not Unix (en español: GNU no es Unix). GNSS: Global Navigation Satellite System (en español: Sistema Global de Navegación por Satélite) GPL: General Public License (en español: Licencia Pública General) GPS: Global Positioning System (en español: Sistema de Posicionamiento Global) GUI: Graphical User Interface (en español: Interfaz gráfica de usuario). HTTP: Hypertext Transfer Protocol (en español: Protocolo de transferencia de hipertexto). IMEI: International Mobile Station Equipment Identity (en español: Se refiere a

Victoria Urresti, José Miguel

identidad internacional de equipo móvil). IaaS: Infrastructure as a service (en español: Infraestructura como un servicio). IT: Information Technology (en español; Tecnologías de la información) JSON: JavaScript Object Notation JSONP: JavaScript Object Notation with Padding LBS: Location Based Services (en español: Servicios Basados en Localización). LIDAR: Laser Imaging Detection and Ranging (en español: Detección y Selección de Imágenes Láser) MapReduce: Map and Reduce (en español: hace referencia a funciones en programación funcional: Map y Reduce) MVC: Modelo, Vsita, Controlador NoSQL: Not Only SQL OGC: Open Geospatial Consortium. OWS: OGC Web Service Common. PaaS: Platform as a service (en español: plataforma como un servicio). POO: Programación Orientada a Objetos. RDBMS: Relational Database Management System (en español: Sistema de gestión de bases de datos relacionales). REST: Representational State Transfer (en español: Transferencia de Estado Representacional). SaaS: Software as a Service (en español: Software como un servicio) SDSS: Spatial Decision Support Systems (en español: sistemas de ayuda a la decisión espacial). SFS: Simple Features Interface Standard (en español: interfaz estándar de features simples). SIG: Sistema de información geográfica (del original en inglés: GIS - Geographic Information System) SLD: Styled Layer Descriptor (en español: Descriptor de Capas con Estilo). SOAP: Simple Object Access Protocol SQL: Structured Query Language (en español: Lenguaje de consulta estructurado). VANT: Vehículo Aéreo No Tripulado. vCPU: Virtual Central Processing Unit (Unidad de procesamiento central asignada Victoria Urresti, José Miguel

a una máquina virtual). WAMI: Wide Area Motion Imagery (en español; Imágenes en movimiento para Grandes Areas) WCS: Web Coverage Service (en español: Servicio de coberturas en la Web). WFS: Web Feature Service (en español: Servicio de entidades vectoriales). WFS-T: Transactional Web Features Service (en español: Servicio de entidades vectoriales transaccional). WGS84: World Geodetic System 84 (en español; Sistema Geodésico Mundial 1984). WKT: Well Known Text (en español; Representación de texto conocido) WMS: Web Map Service (en español: Servicio de mapas en la Web). WT: Compañía Widetech S.A.S XML: eXtensible Markup Language (en español; lenguaje de marcas Extensible).

Victoria Urresti, José Miguel

Índice de Figuras Figura 1. Visualización de las conexiones de usuarios Twitter............................. 20 Figura 2. Diagrama de Visión general de Cloud Computing. ............................... 24 Figura 3. El Teorema de CAP. ............................................................................. 26 Figura 4. Escalamiento Vertical (A) y Horizontal (B). ........................................... 29 Figura 5. Estructura general de una base de datos relacional ............................. 30 Figura 6. Arquitectura General de Base de Datos NoSQL MongoDB .................. 32 Figura 7. Relación entre el cliente/servidor y protocolos OGC. ............................ 34 Figura 8. Representación geométrica (izq.) y estructura (der.) GeoJSON en Web ............................................................................................................................. 36 Figura 9. Funcionamiento de un GNSS ................................................................ 38 Figura 10. Diagrama de proceso de investigación. .............................................. 49 Figura 11. Zona de estudio de proyecto, Latinoamérica.. .................................... 50 Figura 12. Representación de 450 mil ubicaciones aprox. de Flota Vehicular Reportadas en 3h. ................................................................................................ 52 Figura 13. Arquitectura Lógica del sistema .......................................................... 61 Figura 14. Arquitectura general de interoperabilidad en sistemas RDBMS y NoSQL. ................................................................................................................ 62 Figura 15. GUI de Prototipo de digitalización cartográfica Web ........................... 73 Figura 16. Tiempos de consulta de actualización y borrado concurrente ............. 75 Figura 17. Tiempos de consultas espaciales datos GPS vs. entidades ............... 76 Figura 18. Renderización de entidad POI desde prototipo Web........................... 77 Figura 19. Operación de Edición WFS-T a entidad desde prototipo Web ............ 78 Figura 20. Listado de repositorio de complemento Mongo-Geoserver ................. 98 Figura 21. Componente de MongoDB habilitado en Geoserver ........................... 98

Índice de Fragmentos Fragmento 1. Inserción de múltiples localizaciones GPS en MongoDB ............... 65 Fragmento 2. Inserción de múltiples localizaciones GPS en PostgreSQL ........... 66 Fragmento 3. Borrado de múltiples localizaciones GPS en MongoDB................. 67 Fragmento 4. Borrado de múltiples localizaciones GPS en PostgreSQL ............. 67 Fragmento 5. Actualización de múltiples localizaciones GPS en MongoDB ........ 68 Fragmento 6. Actualización de múltiples localizaciones GPS en PostgreSQL ..... 68 Fragmento 7. Consulta de intersección espacial sobre MongoDB ....................... 69 Fragmento 8. Respuesta de consulta de intersección espacial en MongoDB ..... 70 Fragmento 9. Consulta de intersección espacial sobre PostgreSQL ................... 70 Fragmento 10. Consulta espacial de cercanía para MongoDB y PostgreSQL ..... 71 Fragmento 11. Consulta de distancia esférica para MongoDB y PostgreSQL ..... 72

Victoria Urresti, José Miguel

Índice de Tablas Tabla 1. Listado de Requerimientos No Funcionales del sistema ........................ 54 Tabla 2. Listado de Requerimientos Funcionales del sistema.............................. 55 Tabla 3. Puntos de referencia para consultas geoespaciales .............................. 59 Tabla 4. Datos GPS capturados en diferentes lapsos de tiempo. ........................ 64 Tabla 5. Tiempo requerido para carga de datos de territorio Colombia ............... 74 Tabla 6. Atributos de entidades Zonas y puntos de interés .................................. 99 Tabla 7. Atributos de entidad Intersecciones...................................................... 100 Tabla 8. Atributos de entidad localizaciones GPS .............................................. 100

Victoria Urresti, José Miguel

1. INTRODUCCIÓN El propósito de este trabajo científico es revisar y probar la posibilidad de crear servicios interoperables OGC (Open Geospatial Consortium) - WMS (Web Map Service), WFS (Web Feature Service), WFS-T (Transactional Web Features Service)- consumiendo grandes volúmenes de datos provenientes de dispositivos GPS1 que son recibidos en una plataforma de logística y rastreo satelital que provee servicio en Latinoamérica para aproximadamente para una flota de 80.000 unidades. Los datos fueron almacenados tanto en un sistema base de datos NoSQL como Relacional.

1.1 ANTECEDENTES DEL PROBLEMA En la actualidad la gestión de datos con relación a su almacenamiento y recuperación ha sido reto para las grandes corporaciones. Desde la aparición de las bases de datos2, en la década de los 60, estas han tenido como tarea ser un medio de almacenamiento y recuperación de manera estructurada (Strauch, 2013). A través del tiempo, estos medios tecnológicos han evolucionado, conforme han aparecido nuevas fuentes de información y datos sin precedentes lo cual ha promovido el diseño y evolución de estos gestores de almacenamiento. Aun así, los sistemas de bases de datos relacionales3 (RDBMS; Relational Database Management System) son los más utilizados, no obstante, una arquitectura desarrollada recientemente está ganando popularidad, los sistemas NoSQL 4 (Strauch, 2013). Los sistemas de gestión de bases de datos relacionales aparecieron en la década de 1970, como por un aporte de Edgar Codd, se convirtieron en una opción popular debido al modelo teórico sólido. El modelo de Codd era un modelo de 0 a 12 pasos que ayudó a las bases de datos relacionales en inconvenientes con redundancia, 1

GPS; sistema que permite determinar en toda la Tierra la posición de un objeto (véase en Marco Teórico) 2 Base de datos; colección de datos que está especialmente organizados para ser buscados y recuperados rápidamente por una máquina (Enciclopedia Británica, 2014) 3 5 Ver definición en página 29; 30 Capitulo Marco Teórico

Victoria Urresti, José Miguel

accesibilidad, y establecimiento de beneficios de integridad de datos (Voorhis, 2015). El sistema almacena los datos en tablas y, a su vez, estas contienen relaciones entre sí. Cada columna representa un campo y cada fila representa un registro (Rigaux, Scholl y Voisard, 2002). En contraste, el movimiento NoSQL se refiere al desarrollo de sistemas no relacionales, lo que permite un enfoque para el mejor ajuste de los datos no estructurados y semi-estructurados sin las restricciones de los modelos de datos mal ajustados. Estos sistemas pueden presumir de rendimiento y ofrecer ventajas sobre los sistemas relacionales, por lo general carecen de la fiabilidad relacional debido a una menor integridad en los datos. Las arquitecturas tradicionales de RDBMS se han vuelto menos adaptables en el tratamiento de grandes volúmenes de datos no estructurados o lo que se conoce como Big Data. El termino Big Data se refiere a los conjuntos de datos con estructuras heterogéneas con tamaños más allá de la capacidad de las herramientas de software utilizadas comúnmente para capturar, gestionar y procesar los datos con un tiempo transcurrido tolerable (Snijders, Matzat y Reips, 2012). Para hacer frente a estos enormes conjuntos de datos no estructurados recurrentes,

los

sistemas

distribuidos

NoSQL

proporcionan

técnicas

almacenamiento e indexación usando funciones MapReduce5, las que producen en general un sistema más adecuado para estos tipos de datos (Dean y Ghemawat, 2008). Según Mabrouck (s.f.), los datos no espaciales no son el único tipo de datos que ha experimentado este aumento de los volúmenes. Igual se aplica la noción de Big Data al campo de la base de datos espaciales donde datos espaciales provenientes de teléfonos inteligentes, dispositivos GPS o sensores remotos se han masificado. Por otro lado, la computación en nube ha tenido un impacto significativo en la informática, hardware y otros dominios. En la nube, la infraestructura puede actuar

MapReduce; modelo de programación utilizado para dar soporte a la computación paralela sobre grandes colecciones de datos en grupos de computadoras. Victoria Urresti, José Miguel

como servicio (IaaS6), la plataforma puede actuar como servicio (PaaS7), y el software puede actuar como servicio (SaaS8). Las nuevas características de la computación en nube permiten a los gobiernos y los grupos comerciales reducir la cantidad de hardware invertido y ahorrar energía. La computación en nube puede reducir las inversiones de la compañía en el inicio de un negocio y también puede reducir el desperdicio de tiempo de CPU9 cuando el número de solicitudes simultáneas se cambia dinámicamente (Armbrust et al., 2010). Según Mabrouck (s.f.), en la actualidad, la investigación sobre computación geoespacial orientado en la nube es un tema de gran interés, y se espera que la computación en nube juegue un papel más importante en el campo de ciencias de la tierra.

1.2 OBJETIVO GENERAL El objetivo principal es evaluar la viabilidad del geoprocesamiento de datos GPS masivos capturados en 16 países de Latinoamérica desde RDBMS y Sistemas NoSQL espaciales desde servicios OGC alojados en la nube.

1.3 OBJETIVOS ESPECÍFICOS •

Comparar beneficios y desventajas en rendimiento e integridad de consultas geoespaciales sobre RDBMS y Sistemas NoSQL

•

Evaluar RDBMS y Sistemas NoSQL para el almacenamiento de datos vectoriales geográficos sin límite de esquema, número/tamaño de entidades que mitigue el problema del control de grandes volúmenes de datos.

•

Determinar costos y beneficios de construir un prototipo Web SIG para geoprocesamientos de datos previamente almacenados RDBMS y Sistemas NoSQL

•

Identificar las ventajas y desventajas que conlleva de realizar procesos de geoprocesamiento de datos GPS a través de servicios OGC.

IaaS; en computación es el acrónimo de infraestructura como un servicio. PaaS; en computación es el acrónimo de plataforma como un servicio. 8 SaaS; en computación es el acrónimo de software como un servicio. 9 CPU; es el hardware en un ordenador y/o dispositivos programables, que interpreta las instrucciones de un programa informático 7

Victoria Urresti, José Miguel

1.4 PREGUNTAS DE INVESTIGACIÓN «PI - 1» ¿Qué ventajas y desventajas conlleva de realizar procesos de geoprocesamiento a través de servicios OGC y almacén de datos NoSQL? «PI - 2» ¿Es posible tener un control de grandes bancos de datos geoespaciales implementando las nociones de la Big Data? «PI - 3» ¿Existen sistemas de almacenamiento de datos vectoriales geográficos sin límite de esquemas, número/tamaño de entidades que mitigue el problema del control de grandes volúmenes de datos? «PI - 4» ¿Cuál es el costo-beneficio de construir una herramienta SIG10 avanzada para procesos de procesamiento en Web?

1.5 HIPÓTESIS La aplicación de nociones de Big Data a partir de sistemas NoSQL y/o RDBMS espaciales y arquitecturas onCloud, permiten almacenar y geoprocesar datos procedentes de sistemas de posicionamiento global a lo largo de Latinoamérica desde base de datos y plataformas Web.

1.6 JUSTIFICACIÓN Se observa que el panorama actual en SIG no ha sido ajeno a la creciente tendencia de compartir y procesar información mediante herramientas publicadas en la Web que en su mayoría se orientan a la visualización y consulta de información geográfica. Adicionalmente, los últimos avances tecnológicos han dado la posibilidad de incorporar a los SIG la capacidad de geoprocesamiento de un gran volumen de datos, eliminando la necesidad de utilizar herramientas instaladas en un equipo específico para cumplir con tales propósitos. No obstante, esto supedita realizar un estudio comparativo sobre la importancia de elegir entre dos tipos de almacenes; relacionales y NoSQL, teniendo en cuenta las necesidades de la 10

SIG; es un sistema usado para describir y categorizar la Tierra y otras geografías con el objetivo de mostrar y analizar la información a la que se hace referencia espacialmente. Victoria Urresti, José Miguel

complejidad de consultas, tiempos de respuesta y capacidad de interoperabilidad. Diversas investigaciones que se exponen en este estudio han demostrado que las aplicaciones y servicios geoespaciales basadas en la nube pueden obtener un alto rendimiento y una mejor eficiencia mediante la utilización de la capacidad de escalabilidad y virtualización en la nube (Huang et al., 2013).

Por dicha razón, es una oportunidad y reto el desarrollar una metodología para centralizar y gestionar datos de localización masivos que apoye a compañías de logística. Para este caso de estudio, se trabajó con datos de la empresa Widetech SAS11 (WT), que actualmente debe capturar a través de red móvil GSM12/GPRS13 miles de datos GPS desde aproximadamente 80 mil vehículos.

1.7 ALCANCE El alcance de esta investigación es implementar un Servicio de Procesamiento Web Avanzado Cloud Computing, orientado a la manipulación de localizaciones GPS de vehículos a lo largo de Latinoamérica, comprobando y asegurando la posibilidad de organizar bancos de datos geoespaciales bajo dos alternativas RDBMS o Sistemas NoSQL. El servicio mantendrá la alta concurrencia y disponibilidad para un equipo de digitalizadores y analistas cartográficos, sin necesidad de mantener una infraestructura y software instalado en ordenadores en sitio, reduciendo los costos en procesos de gestión y actualización de datos geográficos con licencias de cero costo al desarrollarse con alternativas Open Source. El estudio realizado permitirá observar el potencial de PostgreSQL y MongoDB en la nube, para el mantenimiento de datos GPS a gran escala y su posterior uso para toma de decisiones en actividades logísticas en el sector de transporte; además de estudiar la viabilidad 11

Widetech SAS., una empresa de servicios SaaS (Software as a Service), basados en tecnologías de geolocalización, rastreo satelital, monitoreo remoto e innovación móvil (Widetech, 2016). 12 GSM (Sistema Global para la Comunicación Móvil) es un sistema de telefonía móvil digital que es ampliamente utilizado en mundo. 13 GPRS; es un servicio de comunicaciones inalámbricas basado en paquetes

Victoria Urresti, José Miguel

de explotar alternativas como el monitoreo de información de tráfico en tiempo real, gestión de novedades o incidentes en carretera, levantamiento cartográfico de nuevas carreteras o la predicción de mejores rutas para vehículos.

Victoria Urresti, José Miguel

2. MARCO TEÓRICO 2.1 BIG DATA Big Data es un concepto que hace referencia al almacenamiento de grandes cantidades de datos y a los procedimientos para encontrar patrones repetitivos dentro de esos datos. El fenómeno del Big Data también es llamado, es español, datos a gran escala (Gonzalo, 2013). El término hace referencia a una cantidad de datos que supera la capacidad del software convencional para ser capturados, administrados y procesados en un tiempo razonable. Gonzalo (2013) agrega que el volumen de los datos masivos crece constantemente. En el 2012, se estimaba su tamaño de entre una docena de terabytes hasta varios petabytes de datos en un único conjunto de datos. Por ejemplo, en la Figura 1, se puede observar gráficamente el tráfico de información masiva que emite la red social Twitter en un segundo.

Figura 1. Visualización de las conexiones de usuarios Twitter. Fuente: Social Media Research Foundation, 2012

Victoria Urresti, José Miguel

2.1.1 Big Data Espacial El Big Data espacial trata de un conjunto de datos geográficos tan grandes que no pueden hacer frente con eficacia por los sistemas de gestión de base de datos común. NosoloSIG (2014) indica que el término Big Data Espacial no solo hace referencia a grandes volúmenes de datos con una componente espacial, sino también a la variedad de contenido y la velocidad en que esos datos se generan o almacenan. Es decir, volumen, variedad y velocidad.

Big Data Espacial se origina en los dos modelos básicos existentes, es así como Cugler, Oliver, Evans, Shekhar y Medeiros (2013) citan, en su investigación, la existencia de conjuntos de datos espaciales relevantes tanto Raster como Vector que han surgido de varias fuentes:

Datos WAMI (Wide area motion imagery): Son Imágenes en movimiento provenientes de sensores remotos usadas para la vigilancia persistente principalmente en zonas urbanas densamente pobladas. La cobertura de video para áreas amplias y la persistencia de estos sistemas permiten encontrar patrones mediante la agregación temporal de información. Sin embargo, existen desafíos asociados con el uso de vehículos aéreos no tripulados (VANT) en la recolección y gestión de conjuntos de datos ráster. Primero, un VANT tiene un área de captura pequeña debido a la altura de vuelo relativamente baja; por lo tanto, tiene que capturar una gran cantidad de imágenes en un período muy corto de tiempo para lograr la cobertura espacial para muchas aplicaciones. Lo segundo, el procesamiento de imágenes es otro desafío porque requiere demasiado tiempo para rectificar y realizar los mosaicos. La gran cantidad de datos supera con creces la capacidad del recurso humano disponible. Por lo anterior es necesario desarrollar técnicas automatizadas, eficientes y precisas para manejar estos grandes datos espaciales (Cugler et al., 2013).

Datos LiDAR (Laser Imaging Detection and Ranging): Son datos provenientes de sensor que generan imágenes laser de detección y escalado a partir de

Victoria Urresti, José Miguel

sincronización de pulsos láser desde una posición aérea (plano o satélite) sobre un área seleccionada para producir cartografía. Los datos Lidar son muy usados para analizar superficies o extraer features. En particular los datos tipo punto representan un gran volumen y sus atributos tienen tamaños tremendos, por lo que es difícil categorizar estos conjuntos de datos para los usuarios finales (Cugler et al., 2013).

Por otro lado, existen fuentes que generan gran volumen de datos vectoriales tradicionales, dentro de las cuales Cugler et al. (2013) exponen las siguientes:

Datos VGI (Volunteered geographic information): Son datos originados bajo la noción de recopilar, sintetizar, verificar y redistribuir datos geográficos que son proporcionados, modificados y compartidos a través de servicios interactivos en línea del usuario (por ejemplo, OpenStreetMap, Wikimapia, GoogleMap, GoogleEarth, etc.). En los últimos años, VGI ha llevado a un crecimiento explosivo en la disponibilidad de información geográfica generada por el usuario y requiere modelos de almacenamiento más grandes para manejar conjuntos de datos espaciales a gran escala. El desafío para VGI es mejorar la calidad del servicio de datos con respecto a la exactitud, credibilidad, fiabilidad y valor total (Cugler et al., 2013).

Datos de rastreo GPS: Estos datos están disponible debido a la rápida proliferación de teléfonos móviles y dispositivos de navegación dentro del vehículo. Las trazas GPS actualmente permiten ofrecer sugerencias de rutas personalizadas a los usuarios para reducir, por ejemplo, el consumo de combustible. Una vez más, un obstáculo clave es el tamaño del conjunto de datos (Cugler et al., 2013).

2.2 CLOUD COMPUTING Mell y Grance (2011) afirman que: La computación en nube es un modelo que permite el acceso conveniente a la demanda a un conjunto compartido de recursos computacionales configurables Victoria Urresti, José Miguel

(por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios) que se pueden aprovisionar y liberar rápidamente con un esfuerzo de gestión o un proveedor de servicios mínimos Interacción. Este modelo de nube promueve la disponibilidad (p. 2). En síntesis, Mell y Grance (2011) indican cinco características esenciales en Cloud Computing: ● Autoservicio

bajo

demanda.

consumidor

puede

proveer

unilateralmente capacidades de computación sin requerir interacción humana con el proveedor de cada servicio. ● Amplio acceso a la red. Las capacidades están disponibles a través de la red y se accede a través de mecanismos estándar que promueven el uso por plataformas de clientes finas o gruesas heterogéneas (por ejemplo, teléfonos móviles, portátiles y PDA). ● Agrupación de recursos. Los recursos informáticos se agrupan para servir a múltiples consumidores con recursos asignados dinámicamente y reasignados de acuerdo con la demanda del consumidor. El cliente generalmente no tiene control o conocimiento sobre la ubicación exacta de los recursos proporcionados. ● Elasticidad rápida. Las capacidades se pueden aprovisionar rápida y elásticamente. ● Servicio

medido.

Los

sistemas

Cloud

controlan

optimizan

automáticamente el uso de recursos aprovechando una capacidad de medición en algún nivel de abstracción apropiado al tipo de servicio.

De acuerdo con Chee y Franklin (2010), el termino Cloud Computing se refiere a “un paradigma en el que la información se almacena de manera permanente en servidores de internet y se envía a cachés temporales de cliente, lo que incluye equipos de escritorio, centros de ocio, portátiles, etc.” (p. 3).

Victoria Urresti, José Miguel

Figura 2. Diagrama de Visión general de Cloud Computing. Fuente: Johnston, 2014)

Tal como se observa en la Figura 2, este modelo permite incluso al usuario acceder a un catálogo de servicios estandarizados y responder con ellos a las necesidades de un negocio, de forma flexible y adaptativa, en caso de demandas no previsibles o de picos de trabajo, adicionalmente comercialmente se ofrece como pago por el consumo y no por costo fijo.

2.3 SERVICIO WEB Un servicio Web se define como un componente de aplicación programable, al que se puede acceder mediante protocolos estándar de internet, lo que garantiza las comunicaciones de extremo a extremo. La comunicación entre un cliente 14 y un Web Services15 se realiza sobre el protocolo HTTP16 que es el mismo protocolo que se utiliza para la navegación Web. Este protocolo no está orientado a conexión, por

Cliente (informática); aplicación informática o un ordenador que consume un servicio remoto en otro ordenador conocido como servidor 15 Web Services; es una aplicación Web en ejecución (software) capaz de atender las peticiones de un cliente 16 HTTP; es el protocolo de comunicación que permite las transferencias de información en la World Wide Web Victoria Urresti, José Miguel

lo tanto, la comunicación se establece para cada consulta de manera atómica, de manera que el acceso a los servicios Web se realiza únicamente en tiempo de ejecución del cliente y sólo cuando se precisa la información ofrecida. Cuando la aplicación recibe la respuesta del servicio, la manipula adecuadamente y presenta sus resultados al usuario (García, 2012).

2.4 DEFINICIÓN DE BASE DE DATOS Según la definición de la Enciclopedia Británica (2014), una base de datos es una colección de datos que está especialmente organizados para ser buscados y recuperados rápidamente por una máquina. Las bases de datos se construyen para crear, leer, actualizar y modificar, esto es conocido como CRUD17, que son básicamente funciones en bases de datos o en la capa de persistencia en un software para gestión de datos.

Antes de presentar los distintos tipos de soluciones de bases de datos y sus casos de uso, es necesario introducir conceptos y teoremas teóricos importantes. Aunque sería idóneo tener un sistema en el que los datos sean siempre consistentes, disponibles en todo momento, fáciles y rápidos de recuperar y donde el tiempo empleado para procesar datos evolucione de forma lineal con la cantidad de datos, se debe reconocer que los cumplimientos de todas estas necesidades son, al menos hoy, imposibles. Por lo tanto, el objetivo de elegir un sistema de almacenamiento de datos es entender qué propiedades son esenciales y que, cuales podrían fallar para prever un posible impacto en una implementación dada.

2.4.1 Teorema del CAP El teorema CAP (del inglés Consistency, Availability, Partition Tolerance) o Brewer es una proposición que indica que un sistema de datos distribuidos puede asegurar, a lo sumo, dos de las siguientes propiedades: consistencia, disponibilidad y 17

CRUD, En computación es el acrónimo de Create, Read, Update and Delete

Victoria Urresti, José Miguel

tolerancia de partición. Es decir, estas propiedades no pueden proporcionarse simultáneamente en un sistema distribuido (Browne, 2009). Desde un punto de vista de datos, estas propiedades tienen el siguiente significado: ● Consistencia: Todos los usuarios tienen la misma visión de los mismos datos en todo momento. ● Disponibilidad: Los datos están disponibles para lecturas y escrituras en todo momento. ● Tolerancia de partición: Los datos se distribuyen entre los nodos de un clúster.

Por lo anterior, dentro de las opciones de bases de datos, estas se pueden categorizar dentro de tales propiedades, solo llegando a cumplir máximo 2 de las tres propiedades del Teorema CAP, como se aprecia en la Figura 3.

Figura 3. El Teorema de CAP. Fuente: Bravo, 2015)

2.4.2 Propiedades ACID ACID (del inglés Atomicity Consistency Aislamiento Durabilidad) es un concepto que se refiere a las cuatro propiedades de un sistema de base de datos: atomicidad, consistencia, aislamiento y durabilidad concebidas por Reuter y Härder (1983) para describir las propiedades que las transacciones de datos deben seguir para ser Victoria Urresti, José Miguel

confiables. Dichas propiedades aseguran la preservación de la integridad de los datos durante las transacciones. Esta es una definición de las propiedades de ACID (Reuter y Härder 1983): ● Atomicidad: Todas las operaciones en una transacción se completarán, o ninguna. ● Coherencia: Antes y después de las transacciones, la base de datos está en un estado consistente. ● Aislamiento: Las operaciones no pueden tener acceso a los datos que se modifican actualmente. ● Durabilidad: Los datos no se pierden una vez finalizada la transacción.

Frenoy (2013) afirma que: En un sistema de base de datos particionada, el sistema de acuerdo con el teorema CAP debe elegir entre consistencia y disponibilidad de datos. Los sistemas compatibles con ACID preservan la consistencia de los datos sobre la disponibilidad. Conservar la consistencia de los datos tiene un costo en términos de rendimiento y, en algunos casos de uso, los usuarios necesitan más disponibilidad que la consistencia de todos los tiempos. Para hacer frente a estos casos de uso surgió un nuevo conjunto de propiedades llamadas BASE (p. 7).

2.4.3 Propiedades BASE Las propiedades BASE (del inglés Basically Available, Soft state, Eventually consistent) se refieren a las características en diseño de sistemas de datos que dan prioridad a la disponibilidad sobre la consistencia de las operaciones. Son una alternativa frente a las propiedades ACID. Según Pritchett (2008), estas propiedades buscan mejorar significativamente las prestaciones de consistencia en los datos en todo momento, mejorando la disponibilidad al permitir que los nodos tengan diferentes vistas de los datos durante el menor tiempo posible. Las propiedades BASE, a comparación de las ACID, hacen posible mejorar todo el Victoria Urresti, José Miguel

rendimiento del sistema, añadiendo más máquinas en el sistema en lugar de mejorar la potencia de cada máquina involucrada en el sistema, en el caso de sistemas sin restricciones en la coherencia de datos justo al final cada operación, y que solo requieren un estado consistente después de algún tiempo. En otras palabras, se hace posible escalar el sistema más bien horizontalmente que verticalmente. Pritchett (2008) agrega que “las propiedades BASE son opuestas a ACID que surge por las nuevas necesidades técnicas, y la posibilidad de adquirir hardware a menor costo”. (p. 1).

2.4.4 Escalamiento Vertical Y Horizontal Dentro de los métodos para agregar recurso a un sistema existen dos grandes categorías: escalamiento vertical y horizontal (Maged, Moreira, Shiloach y Wisniewski, 2007).

Escalamiento Vertical (Scale-up) es la agregación de recursos a (o eliminación de ellos), un solo nodo en un sistema, típicamente el escalamiento involucra la adición de CPU’s o memoria a una sola computadora (Figura 4. A). Este escalamiento vertical de los sistemas existentes también permite usar la tecnología de virtualización de manera más efectiva, ya que proporciona más recursos para el conjunto alojado de sistemas operativos y módulos de aplicación para compartir. Esta escalabilidad se refiere al rendimiento mejorado de las aplicaciones en ejecución en una versión ampliada del sistema (Hesham y Mostafa, 2005).

Victoria Urresti, José Miguel

Figura 4. Escalamiento Vertical (A) y Horizontal (B). Fuente: KB's Data Scientist, 2012

Escalamiento Horizontal (Scale-out) significa agregar más nodos a (o eliminar nodos de) un sistema, se puede ver como agregar un nuevo equipo a una aplicación de software distribuida (Figura 4. B). Son sistemas que pueden configurar cientos de pequeñas computadoras en un clúster para obtener una potencia computacional agregada que a menudo excede la de las computadoras basadas en un solo procesador tradicional. Este crecimiento ha llevado a la demanda de software que permite una gestión y mantenimiento eficiente de múltiples nodos, así como de hardware para el almacenamiento de datos compartidos con una cantidad de periféricos de entrada/salida mucho mayor, ya que el escalamiento horizontal demandaría más nodos tantos por cada ordenador o máquina que se desee agregar. Esta escalabilidad se refiere al número máximo de procesadores que un sistema puede acomodar (Hesham y Mostafa, 2005).

2.4.5 Sistema De Gestión Datos Relacional Un sistema de gestión de datos relacional es un sistema de gestión de base de datos (DBMS) que se basa, como su nombre lo indica, en el modelo relacional. López (2011) afirma que “en el modelo relacional se basa en el concepto matemático de relación. En este modelo, la información se representa en forma de tablas o relaciones, donde cada fila de la tabla se interpreta como una relación Victoria Urresti, José Miguel

ordenada de valores” (p. 1). A continuación, se muestra la estructura general de un servidor de base de datos relacional (Figura 5), conformado por una parte estática que define el modelo de almacenamiento (tablas, archivos de configuración y de eventos) y la definición de una instancia, parte dinámica, conformada por procesos (lectura, escritura, captura de eventos etc.) y datos (registros, columnas índices, meta código etc.).

Figura 5. Estructura general de una base de datos relacional. Fuente: Wikimedia Commons, 2010

De acuerdo con López (2011), los RDBMS usan un modelo que es relativamente sencillo, por tal razón, no es casual si ha sido elegido de referencia para construcción de la gran mayoría sistema de gestión de datos para entidades financieras, la fabricación logística, aseguradoras y otras aplicaciones desde la década de 1980.

2.4.6 Sistema De Gestión De Datos NoSQL El artículo de Rouse (2015) expone que los sistemas de datos NoSQL son sistemas que tiene como objetivo solucionar los problemas de escalabilidad y rendimiento de Victoria Urresti, José Miguel

Big Data que las bases de datos relacionales no pueden resolver. NoSQL es especialmente útil cuando es necesario acceder y analizar grandes cantidades de datos no estructurados o datos que se almacenan de forma remota en varios servidores virtuales en la nube.

Rouse (2015) señaló que: Si bien es cierto que algunos sistemas NoSQL son totalmente norelacionales,

otros

simplemente

evitan

funcionalidades

relacionales

seleccionadas como esquemas de tablas fijas y operaciones conjuntas. Por ejemplo, en lugar de utilizar tablas, una base de datos NoSQL podría organizar los datos en objetos, pares clave/valor, tuplas (p. 1).

Dependiendo de la forma en la que almacenen la información, existen diferentes tipos de bases de datos NoSQL, según expone Acens Company (2014):

1. Bases de datos clave-valor. Es el modelo de base de datos NoSQL más conocido, además de ser el más sencillo en cuanto a funcionalidad. En este sistema cada elemento está identificado por una llave única, lo que permite recuperación de la información de forma rápida. Se caracterizan por ser muy eficientes para lectura y escritura. En el documento, Acens Company (2014) indica algunos ejemplos de este tipo de bases de datos como Cassandra, BigTable o HBase.

2. Bases de datos documentales. El almacenamiento se hace como un documento, se tiene preferencia para la estructura simple como basados en JSON18 o XML19. De acuerdo con Acens Company (2014), “este tipo de implementación permite, además de realizar búsquedas por clave-valor, realizar consultas más avanzadas sobre el contenido del documento… Son las bases de datos NoSQL más versátiles”. (p.3). En Acens Company (2014), se citan ejemplos de este tipo como: CouchDB, MongoDB. Con respecto a MongoDB se puede observar en la 18

JSON; Formato de intercambio para la representación datos simples y estructurados basados en texto legible para el ser humano 19 XML; es un metalenguaje que permite definir lenguajes de marcas desarrollado por el World Wide Web Consortium (W3C) Victoria Urresti, José Miguel

Figura 6, que su arquitectura general está diseñada para tener: un esquema dinámico tipo documento (JSON) para los datos, manejadores de consulta nativos (como por ejemplo: métodos insert(), .find()), un conjunto de réplicas similar a un sistema a un comportamiento horizontal, y alto rendimiento debido al gestión sobre los datos, índices y uso de memoria.

Figura 6. Arquitectura General de Base de Datos NoSQL MongoDB. Fuente: Kalan, 2014

3. Bases de datos en grafo. En estos sistemas la información se representa como nodos de un grafo y sus relaciones con aristas del mismo. Este tipo de base de datos alcanza su mejor rendimiento cuando posee una estructura normalizada. De acuerdo con Acens Company (2014), “este tipo de bases de datos ofrece una navegación más eficiente entre relaciones que en un modelo relacional” (p. 5). Acens Company (2014) indica algunos ejemplos de este tipo de bases de datos como: Neo4j, InfoGrid o Virtuoso.

4. Bases de datos orientadas a objetos. En este tipo, la información se representa mediante objetos, similar a las nociones de los lenguajes de programación orientada a objetos (POO). Acens Company (2014) indica algunos ejemplos de este Victoria Urresti, José Miguel

tipo de bases de datos como: Zope, Gemstone o Db4o.

2.4.7 DBaaS DBaaS es un modelo de base de datos como servicio que corre sobre una plataforma Cloud Computing permitiendo a los usuarios a realizar requerimientos on-demand de ambientes de bases de datos. Como las bases de datos y los ambientes son aprovisionados y des-aprovisionados entonces los recursos informáticos asociados son consumidos y luego puestos en libertad. Los costos computacionales consumidos son sometidos a un proceso de seguimiento y monitoreo para posteriormente ser cobrados al consumidor. La implementación de DBaaS simplifica las infraestructuras de las tecnologías informáticas, haciendo fácil la distribución de funcionalidad de base de datos a muchos usuarios y múltiples divisiones y secciones con el mismo hardware e infraestructura de software (Pérez, 2016).

2.5 OGC OGC, anteriormente conocido como Open GIS Consortium, es una sociedad creada en 1994 que agrupa a más de 372 organizaciones públicas y privadas y tiene como propósito, definir los estándares abiertos e interoperables para la información geográfica (OGC, 2015). OGC es una organización no lucrativa y lidera el desarrollo de normas para los datos geográficos relacionados con las operaciones y servicios, que en la actualidad han sido ampliamente adoptadas en los SIG (McKee, 2014). De igual forma, OGC persigue acuerdos entre las diferentes empresas del sector para posibilitar la interoperabilidad de sus sistemas geográficos, con el fin de facilitar el intercambio de la información geográfica en beneficio de los usuarios. Las más importantes y populares especificaciones OGC desarrolladas son: WMS, WFS, WCS y GML20 (OGC, 2015). En los últimos años, el acceso a enormes cantidades de datos geográficos a través

GML; Es un sublenguaje de XML descrito bajo gramática XML Schema para el modelado, traslado y almacenamiento de información geográfica. Victoria Urresti, José Miguel

del internet ha ido en aumento. Por otro lado, OGC tiene interfaces y protocolos definidos para apoyar soluciones que desarrollan estándares que permiten la interoperabilidad de información y servicios espaciales. La Figura 7 describe las normas OGC que ayudan a herramientas SIG a comunicarse mediante el uso del servidor espacial con interfaces y aplicación.

Figura 7. Relación entre el cliente/servidor y protocolos OGC. Fuente: Shadura, 2010

En la actualidad, hay organizaciones, incluyendo gobernaciones, el sector privado y las organizaciones académicas que se han unido al OGC. Los siguientes son algunos ejemplos de miembros de la OGC: Google, ESRI, Microsoft, Oracle, NASA, IBM, MIT. En el mundo de los SIG, especialmente en el ámbito de la cartografía en la red interoperable, servicios Web OGC son muy significativos porque proporcionan la normalización y oportunidades para que los usuarios compartan información geoespacial a pesar de que los datos proceden de diferentes fuentes y/o diferentes aplicaciones (Quadro, 2016). A continuación, se exponen los Victoria Urresti, José Miguel

servicios OGC más usados. WMS es una de las especificaciones más conocidas. Ofrece una interfaz HTTP simple para imágenes de mapa desde unas bases de datos geoespaciales distribuida. Una vez que un cliente envía una solicitud especificando el área de interés, el servicio produce un contenido de información geográfica dentro del área y, a continuación, envía la respuesta al cliente como imágenes de mapa (entre los formatos más conocidos están: JPEG, GIF, PNG o SVG). El cliente puede ver fácilmente este tipo de imágenes del mapa a través de un navegador Web sin necesidad de tener ningún conocimiento sobre el contenedor y creador de dichos datos (OGC, 2015). WFS es el principal servicio Web geoespacial que proporciona una interfaz que permite peticiones a atributos geográficos a través de internet, sin importar la plataforma cliente. Al igual que en WMS, una vez que un cliente envía una solicitud a un servidor de funciones Web para pedir datos geográficos, el servidor proporciona datos de carácter geoespacial en formato de salida como: GML, Shapefile, JSON, JSONP, CSV21 (OGC, 2015). WFS-T o WFS Transaccional es un WFS básico de funciones Web que permite la consulta y recuperación, a la vez que se pueden ejecutar acciones de creación, eliminación, y la actualización de features (OGC, 2015).

2.6 GeoJSON GeoJSON es un formato estándar abierto basado en el formato JSON diseñado para almacenamiento de elementos geográficos sencillos, junto con sus atributos no espaciales. Observando la Figura 8, este formato posee una gramática basada en el estándar WKT22 del OGC y su estructura define elementos geométricos, a partir de una tipología (punto, multipunto, línea, multi línea, polígono, multi polígono

CSV; tipo de formato para documentos sencillos, usado para representar datos de forma tabular (las columnas se delimitan por un carácter común y las filas por salto de línea). 22 WKT; es una codificación o sintaxis en ASCII estandarizada creada para describir objetos espaciales expresados de forma vectorial Victoria Urresti, José Miguel

o colecciones) y un arreglo de coordenadas, los elementos pueden ser de tipo punto, líneas, polígonos y colecciones de elementos (Butler et al., 2008).

Figura 8. Representación geométrica (izq.) y estructura (der.) GeoJSON en Web. Fuente: Leafletjs, 2016

El formato es ampliamente utilizado en aplicaciones de cartografía en entornos Web y bases de datos, al permitir el intercambio de datos de manera rápida, ligera y sencilla. El formato GeoJSON difiere de otros estándares SIG en que no está desarrollado y mantenido por una organización oficial, sino que es mantenido por una comunidad de desarrolladores en internet.

2.7 SISTEMA GLOBAL DE NAVEGACIÓN POR SATÉLITE Los Sistema global de navegación por satélite o GNSS (Global Navigation Satellite System), son un conjunto de tecnologías que proveen de posicionamiento geoespacial con cobertura global de manera autónoma. Los orígenes del GNSS se sitúan en la década de los 70 con el desarrollo del sistema militar estadounidense GPS (Global Positioning System), destinado al guiado de misiles, localización de objetivos y tropas etc. A través de una red de satélites, un receptor de GNSS es capaz de determinar su posición en cuatro dimensiones (longitud, latitud, altitud, y tiempo), lo que ha dado lugar a multitud de aplicaciones civiles y militares (GSA, 2016). Por otro lado, García (2008), indica que los sistemas de navegación por Victoria Urresti, José Miguel

satélite tienen una estructura, que se divide en tres segmentos que a continuación se describen:

Segmento espacial. Es el segmento compuesto por los satélites que forman el sistema, tanto de navegación como de comunicación. Los satélites de navegación orbitan alrededor de la Tierra, repartiéndose en distintos planos orbitales, los de comunicación son los que forman los llamados sistemas de aumento que sirven para la corrección de errores de posicionamiento.

Segmento de control. Es el conjunto de estaciones en tierra que recogen los datos de los satélites. El segmento es complejo en su definición, siendo propio de cada país o coalición de países, se estructura en función de distintos criterios como más convenga. Su función es garantizar las prestaciones del sistema mediante monitoreo del segmento espacial y aplicar correcciones de posición orbital y temporal a los satélites, enviando información de sincronización de relojes atómicos y correcciones de posicionamiento de órbitas a los distintos satélites.

Segmento de usuario. Formado por los equipos GNSS que reciben las señales que proceden del segmento espacial. Este dispositivo está formado por un conjunto de elementos básicos que son: La Antena receptora de GNSS a la frecuencia de funcionamiento del sistema, de cobertura hemisférica omnidireccional. El flujo o ciclo de funcionamiento de un sistema de navegación por satélite se puede interpretar gráficamente como aparece en la Figura 9.

Victoria Urresti, José Miguel

Figura 9. Funcionamiento de un GNSS. Fuente: Furquet (2016)

2.8 TECNOLOGÍAS

PROYECTOS

BASE

INVESTIGACIÓN El siguiente apartado consiste en presentar tecnologías y proyectos en los cuales se basó la investigación, teniendo en cuenta dos aristas; publicación de servicios en la nube y la interoperabilidad y consulta de datos desde tipos de bases de datos específicas.

2.8.1 Tecnologías Cliente-Servidor Base de Datos NoSQL Espacial. De acuerdo con MongoDB (2015), la base de datos MongoDB es un sistema de almacenamiento orientado a documentos, desarrollado bajo código abierto y escrito en C++ y que tiene como enfoque principal tener alto rendimiento en la manipulación de datos representados en estructuras simples. Dentro de sus funcionalidades puede realizar sharding que consiste en la función de repartir uniformemente la carga de trabajo, permitiendo escalar horizontalmente una aplicación y trabajar con grandes cantidades de datos. MongoDB guarda estructuras de datos en documentos similares a JSON con un esquema dinámico, a su vez ofrece una serie de índices y mecanismos de consulta para manejar la información geoespacial (MongoDB, 2015) Victoria Urresti, José Miguel

Con respecto al soporte espacial, MongoDB posee un índice espacial llamado geohashing, el cual tiene mecanismos de consulta para manipular la información geoespacial. Dicho índice tiene en cuenta la definición de dos tipos de superficies que representan los datos; plana, es decir, arreglos de coordenadas que no considera la curvatura de la Tierra y esférica, arreglos de coordenadas que considera las distancias y relaciones topológicas teniendo en cuenta la curvatura de la Tierra. Para datos que representan superficies esféricas se usan objetos GeoJSON con coordenadas en longitud, latitud y sistema de referencia WGS8423, que es el datum predeterminado que usa MongoDB para la interpretación de geometrías (MongoDB, 2015).

Base de Datos Relacional Espacial. Ballatore, Tahir, McArdle y Bertolotto (2009), en su investigación, definen los sistemas de gestión de datos espaciales como sistemas con un modelo de datos y lenguaje de consulta que proporciona indexación espacial y algoritmos para consultas espaciales, tales como, MySQL y Oracle con su módulo Spatial, PostgreSQL con su extensión espacial PostGIS. En particular, en su estudio comparativo toman de referencia este último, dado que es una tecnología Geoespacial de código abierto que, según su exploración, tiene como bondades, la capacidad de almacenar y consultar entidades geográficas (cumpliendo el estándar SDSS24) sobre el gestor PostgreSQL. Según Ballatore et al. (2009), PostGIS es ampliamente soportado por un gran número de servidores geoespaciales Web comerciales y de código abierto. Es totalmente compatible con los estándares OGC como Simple Features for SQL (SFS25). Aparte del soporte espacial básico, tiene un API (del inglés Application Programming Interface) para manejo de topología, validación de datos, transformación de coordenadas y programación de otras funcionalidades geográficas. Ballatore et al. (2009)

WGS84; es un sistema de referencia y Datum geodésico centrado y fijo en la Tierra, consistente en constantes y parámetros de un modelo que describen el tamaño, forma y gravedad y campos geomagnéticos de la Tierra. (p. 2 -1) (NGA, 2004). 24 SDSS; Spatial decision support systems (en español: sistemas de ayuda a la decisión espacial). 25 SFS; es una especificación OGC que establece normas para manipulación de datos espaciales través de la interfaz SQL Victoria Urresti, José Miguel

concluyen que, a medida que el proyecto continúa creciendo, se han propuesto características

adicionales

para

soporte

ráster,

enrutamiento,

superficies

tridimensionales, curvas y splines. Solución Cloud Computing. Como de referencia se estudió Amazon EC226 que, de acuerdo con la documentación oficial de Amazon (2014), es una solución que proporciona la capacidad de computación escalable en la nube de Amazon Web Services (AWS). El uso de Amazon de EC2 elimina la necesidad de invertir en hardware por lo que reduce el tiempo requerido para implementar aplicaciones, se puede usar servidores virtuales por demanda y configurar la seguridad, redes y gestores de almacenamiento.

Dentro de las características principales de Amazon EC2 están: entornos virtuales de computación (llamados instancias), configuraciones de CPU, memoria, almacenamiento y capacidad de red para sus instancias (tipos de instancia), múltiples ubicaciones físicas para sus recursos, como instancias y volúmenes de almacenamiento en bloque (Amazon EBS), conocidos como regiones y zonas de disponibilidad, metadatos conocidos como etiquetas que puede crear y asignar a sus recursos de Amazon EC2 y redes virtuales que puede crear que están lógicamente aisladas del resto de la nube de AWS y que opcionalmente pueden conectarse a su propia red, conocidas como Nubes virtuales privadas (Amazon, 2014).

Servidor de Mapas Web. De acuerdo con el estudio de Ballatore et al. (2009), un servidor cartográfico Web es una librería para la publicación de aplicaciones SIG en línea, que generalmente incluyen la funcionalidad se consultar base de datos espaciales, soporte para representación de datos ráster y vector e integración con otras librerías geográficas. Ballatore et al. (2009) destacan a Geoserver como un servidor con un gran soporte y de código abierto escrito en Java que permite a los usuarios compartir y editar datos geoespaciales. 26

EC2; termino referido a computación elástica en la nube (del original en inglés; Elastic Compute Cloud) creada por Amazon Inc. Victoria Urresti, José Miguel

Geoserver está diseñado para la interoperabilidad y publicación de datos espaciales usando estándares de OGC, además, apoya la edición de datos geográficos del lado cliente mediante WFS-T. Cuenta con una herramienta de administración Web para configurar sus opciones espaciales y no espaciales. Una característica importante de GeoServer es el uso de SLD27, un estándar OGC para representar estilos cartográficos, incluye OpenLayers integrado, GeoWebCache para el mapeo de mosaicos y soporte amplio para muchos bases de datos como PostGIS, ArcSDE, Oracle y DB2 (Ballatore et al., 2009). Cliente Cartográfico Web. Ballatore et al. (2009) afirman que: “gracias a la difusión de las tecnologías web orientadas a AJAX28, soluciones SIG de ámbito Web han experimentado un crecimiento notable en la última década. Servicios conocidos como Google Maps y Virtual Earth proporcionan a los desarrolladores herramientas poderosas” (p.60). No obstante, aunque estos productos son muy populares, están totalmente controlados por empresas que pueden decidir alterar o discontinuar arbitrariamente. Por el contrario, las bibliotecas de mapeo de código abierto ofrecen alternativas viables para construir poderosos mapas web interactivos, permitiendo al desarrollador elegir las fuentes y formatos de datos como es el caso de OpenLayers que es una librería de JavaScript orientado a objetos y basados en componentes de prototype29, construida para representar datos espaciales dentro de aplicaciones sobre ambiente Web, sin dependencias del servidor (Ballatore et al., 2009). Constituyendo la principal alternativa de código abierto a las herramientas comerciales equivalentes. Como ocurre con muchas tecnologías geoespaciales de código abierto, OpenLayers implementa métodos estándar para el acceso a datos geográficos, como el servicio de mapas web (WMS) de OGC y los estándares WFS. A nivel conceptual, OpenLayers pretende separar la

SLD; se refiere a es un esquema XML propuesto por OGC como lenguaje estándar para describir el conjunto de capas que dan apariencia a un mapa. 28 AJAX; es una técnica de desarrollo web para realizar solicitudes asíncronas a un servidor desde un cliente Web 29 Prototype; se refiere a un framework escrito en JavaScript, orientado al desarrollo sencillo y dinámico de aplicaciones web. Victoria Urresti, José Miguel

visualización espacial y las herramientas de manipulación de los datos espaciales, una idea que no se implementa en el equivalente comercial Google Maps (Ballatore et al., 2009).

2.8.2 Investigaciones Relacionadas En la investigación de diseño e implementación de una solución NoSQL en una plataforma SaaS, Frenoy (2013) reconoce que, aunque las soluciones NoSQL son nuevas e innovadoras, “no hay una guía que explique qué solución es mejor dependiendo del caso” (p.1). Frenoy (2013) plantea una visión general de cada tipo de solución NoSQL, explicando cuándo y por qué un cierto tipo de solución sería una opción buena o mala para un caso de uso dado. Después de seleccionar la mejor alternativa NoSQL, explica la implementación de dicho almacén de datos. Sin embargo, Frenoy (2013) agrega que “no hay una guía de "mejores prácticas" para obtener este conocimiento” (p.4). Por lo anterior, su investigación como último alcance se orienta a construir un prototipo, implementando el almacén MongoDB probando varias configuraciones que dieron como resultado diferentes niveles de rendimiento. Posteriormente, explica el resultado principal que obtuvo de sus experimentos, lo cual lo lleva concluir que la tecnología de NoSQL es una solución viable que trae nuevas posibilidades, especialmente en términos de escala y representación de datos heterogéneos. Además, Frenoy, (2013) agrega que: Otras soluciones e incluso otros tipos de soluciones, puede traer otros beneficios y superar MongoDB. Si los almacenes de datos de key-value y los almacenes de datos orientados a gráficos están diseñados para casos específicos y no encajan a una necesidad específica, un almacén de datos orientado a columnas puede ser otra buena solución (p.36). Por el lado, Ranjit et al. (2013) sugirieron una solución NoSQL, en el año 2012, para la ciudad de Bangkok, implementando un sistema de información de tráfico en tiempo real para mejorar la optimización de rutas, a partir de 10,000 unidades GPS instaladas en vehículos de transporte público. Las unidades GPS recolectaban Victoria Urresti, José Miguel

datos que incluían información como: localización espacial (latitud y longitud) y el tiempo UNIX30 registrado cada 3 a 5 segundos. El reto principal de este estudio era manejar grandes volúmenes de datos, aproximadamente 50 millones de datos por día, con un tamaño en archivo de 3.5 GB. Para procesar esta gran cantidad de datos, era necesaria una gran cantidad de tiempo y recursos. Por lo anterior, Ranjit et al. (2013), con el uso del sistema de distribución Apache Hadoop, controlaron el procesamiento de grandes volúmenes de datos reduciendo el tiempo de procesamiento y extracción drásticamente para 50 millones de registros GPS a aproximadamente 10 minutos empleando 2 clusters, es decir, dos máquinas autónomas e independientes interconectadas para formar un único recurso informático a diferencia de un procesamiento convencional que se realiza con una sola máquina. El método con computación en cluster comprobó que es adecuado procesar los grandes volúmenes de datos y producir la información relevante bajo un sistema distribuido Apache Hadoop que mantenía modelos de programación efectivos, diseñando un escalamiento de una máquina a varias, cada una ofreciendo computación y almacenamiento local (Ranjit et al., 2013).

McCarthy (2014) desarrolló su investigación sobre el interrogante: si las tecnologías NoSQL tenían un lugar en los SIG. Para ello comparó PostgreSQL y MongoDB para almacenar y consultar datos de OpenStreetMap de forma escalable desde pequeños a grandes volúmenes. En su investigación, McCarthy (2014) formuló una serie de consultas espaciales y no espaciales para probar ambos sistemas bajo una misma plataforma y un conjunto de datos, alterando la complejidad en las operaciones y la escala geográfica en los datos. En dicha investigación, McCarthy obtuvo una visión de cómo cualquiera de los sistemas de bases de datos puede presentar ventajas de rendimiento relacionadas con el tamaño de los datos. La investigación destaca cómo el rendimiento de cada sistema está limitado por la funcionalidad del sistema. McCarthy (2014) observa en sus resultados que MongoDB no puede soportar las necesidades espaciales de un SIG que demande operaciones espaciales avanzadas, sin embargo, si las funcionalidades espaciales 30

Tiempo UNIX; se refiere a instantes de tiempo transcurridos desde la medianoche UTC del 1 de enero de 1970 Victoria Urresti, José Miguel

son básicas, MongoDB sería una factible alternativa de alto rendimiento si se requiere manipular grandes conjuntos de datos. Además, afirma que PostgreSQL con su extensión espacial PostGIS tiene una amplia y especializada funcionalidad espacial que lo convierte en el mejor sistema espacial, sin embargo, el aumento del tamaño del conjunto de datos presenta una relación de ralentización del sistema (McCarthy, 2014). El uso de cada sistema es dependiente de la aplicación, pero en la actualidad, el sistema NoSQL es espacialmente superado por lo que no es apto de la industria especializada SIG. Además, se identifica que en una indexación espacial en ambos almacenes se afecta en menor medida el sistema NoSQL y tiene mejores beneficios en sistema relacional. Para McCarthy (2014), MongoDB muestra signos prometedores para la funcionalidad espacial básica y con sus capacidades de escalado, el uso posible para las aplicaciones espaciales basadas en Web parece mucho más realista y agrega que PostgreSQL con una extensión espacial es un sistema de base de datos especializada para usuarios de SIG por su profusa funcionalidad espacial.

Vijayshree y Patil (2013) vieron la necesidad de lograr acceder fácilmente a datos climáticos teniendo como insumo, sensores utilizados para la recopilación de información ambiental, tales como cambios en la temperatura, la presión del aire, la calidad del agua, velocidad de vientos y precipitación. El objetivo de Vijayshree y Patil (2013) fue analizar la gran cantidad de datos multidimensionales generados por diversos sensores y la interoperabilidad entre los diversos sistemas que se ocupa de este tipo de datos complejos. Los sensores estaban distribuidos geográficamente y sus redes no tomaban en cuenta la información de contexto debido a que proporcionan interfaces heterogéneas de acceso a los datos. En este trabajo se demostró la automatización de un sensor para generar la información de los datos climáticos para el estado de Karnataka en la India, dado la heterogeneidad de los datos y las múltiples fuentes se usó Jenkins que es un modelo de informática que consiste en hacer integraciones automáticas y que interactúa con la nube para buscar datos climáticos y probar qué servidor es el mejor framework para la automatización de datos. Adicionalmente, MongoDB es usado para almacenamiento de los datos climáticos, de acuerdo con Vijayshree y Victoria Urresti, José Miguel

Patil (2013) esta era la mejor solución para manejar gran cantidad de datos sobre el clima de manera efectiva. Vijayshree y Patil (2013) diseñaron y desarrollaron un servicio bajo REST Spring que es una arquitectura de software para crear servicios distribuidos como la World Wide Web; allí se expuso toda la información de datos climáticos como un API para consumo. Según Vijayshree y Patil (2013), la solución propuesta logra un enganche independiente de la plataforma e interoperabilidad con otras aplicaciones debido a la arquitectura en capas desarrollado. Adicionalmente, hicieron una comparación de servicios Web basados en SOAP31 y REST, comprobando que REST es la solución más apropiada para la integración de datos de manera distribuida a nivel de internet. Usar Spring MVC32 resulta ser robusto, flexible y proporciona una clara distinción del modelo, vista controlador, lo cual facilita el desarrollo de la aplicación. El servicio expuesto obtuvo varias condiciones climáticas tales como la temperatura, presión, humedad etc., de diversas ciudades de Karnataka como resultado.

En lo que respecta a sistemas de almacenamiento de bases de datos existen diversos estudios que han realizados diferentes niveles de comparación para determinar la efectividad de sistemas NoSQL y RDBMS dependiendo de las necesidades y el campo de acción (Baas, 2012). Baas (2012) realizó una investigación en el campo de los SIG, en donde hace una comparación de un almacén de datos NoSQL llamado Neo4j con una tradicional, la base de datos PostgreSQL, para el almacenamiento y consulta de datos de vectores espaciales. El objetivo de este estudio fue determinar cuál sistema de base de datos, relacional; como PostgreSQL con extensión espacial PostGIS, o NoSQL; como Neo4j-espacial, sería más efectivo como tecnología subyacente para la consulta de los datos de OpenStreetMap.

La metodología de evaluación diseñada para comparar las dos bases de datos implica tanto medidas objetivas y subjetivas: mediciones basadas en la

SOAP; es protocolo para definir servicios Web por medio de intercambio de datos XML MVC; es un patrón de arquitectura de software, usado para separar datos, la lógica de negocio e interfaz de usuario y el módulo comunicación de una aplicación 32

Victoria Urresti, José Miguel

documentación y experiencia. Las pruebas objetivas incluyen la velocidad de procesamiento en base a un conjunto predefinido de consultas, los requisitos de espacio en disco, y escalabilidad (Baas, 2012). En cuanto a pruebas subjetivas incluyen la madurez/nivel de apoyo, estabilidad y facilidad de uso (Baas, 2012). Mientras tanto, el marco de evaluación aplicado a las pruebas objetivas podría ser utilizado como un banco de pruebas para evaluar el rendimiento y la fiabilidad de los nuevos almacenes de datos espaciales. Un entorno de prueba se ha creado utilizando los mismos datos de OpenStreetMap, tanto en la base de datos gráfica y la base de datos relacional. Baas (2012) agrega que, respecto a mediciones objetivas, los resultados de esta investigación demuestran que la base de datos NoSQL es más beneficiosa cuando las consultas se expresan para algoritmos de grafos a nivel regional. Las consultas que se adaptan bien a este enfoque son, por ejemplo, análisis de ruta más corta o consultas de conectividad. Consultas simples como bounding box o delimitación por caja eran más rápidas en la base de datos relacional. En cuanto a las medidas subjetivas, Neo4j ofrece una gran cantidad de funcionalidad, soporte de transacciones y numerosas formas de ejecutar consultas, por ejemplo, utilizando Java. El modelo de base de datos es sin esquema y permite adiciones o ajustes sin ningún impacto importante en el modelo de datos. Como un componente de Java es relativamente fácil de implementar. Por el lado, PostgreSQL más PostGIS, son proyectos más maduros con una gran cantidad de funcionalidad, documentación y soporte. En general, esta investigación muestra que, en algunos casos, Neo4j debe ser considerada como una alternativa para tareas específicas. Finalmente, Baas (2012) documenta en una guía en forma de un diagrama de flujo una comparativa si Neo4j-espacial o PostGIS es adecuado para un proyecto específico.

Victoria Urresti, José Miguel

3. METODOLOGÍA Con relación a los proyectos tomados en cuenta para esta investigación y el contexto a tratar (evaluar la viabilidad de geoprocesamiento de datos GPS masivos capturados en 16 países de Latinoamérica desde RDBMS y Sistemas NoSQL espaciales desde servicios OGC onCloud), se planifico ciertas etapas que permitieron realizar dicha evaluación y, con base a los resultados obtenidos, generar un espacio de discusión sobre sí es viable potenciar y/o aprovechar el uso de datos de localización masivos para procesos de gestión en una empresa de logística de transporte.

En este sentido, y de acuerdo con la lectura de proyectos similares, se evidencia que es necesario definir un área de estudio y describir el conjunto de datos geográficos asociados a esta. Dado la estructura, volumen y la periodicidad de captura de datos geográficos - para este caso procedentes de GPS -; según explica Frenoy (2013), se debe realizar una visión general de cada solución de base de datos, de acuerdo con la temática del proyecto, para determinar cuándo una opción es buena o mala para un caso de uso dado.

Además de la visión general, se debe explorar base de datos en la actualidad que cumplen el requerimiento de soporte espacial. En este caso y para dar respuesta a los objetivos de esta investigación, esta metodología se basó en el estudio de McCarthy (2014), el cual define el rendimiento como la medida de eficiencia de funcionamiento de un sistema informático en relación con el tiempo y los recursos disponibles. En consecuencia, se realizó la selección de alternativas tecnológicas ajustadas a un diseño e implementación similar para lograr medir el rendimiento de forma correcta.

Igualmente, McCarthy (2014) encamina su metodología en la realización de un benchmarking o evaluación comparativa que proporcionan un criterio para medir diferentes factores bajo diferentes cargas de trabajo. Para este caso de estudio, este benchmarking planteo un ambiente y consultas geoespaciales básicas para Victoria Urresti, José Miguel

ambos almacenes de datos. Dichas consultas son las mínimas requeridas por una plataforma AVL, como lo son: cercanía distancia, contenencia e intersección espacial.

Por otro lado, debido a que la investigación también se enmarca en una arquitectura en la nube y consumo de datos a través de servicios Web, los aportes de Vijayshree y Patil (2013) y Ranjit et al. (2013) fueron importantes ya que estos propusieron un diseño y desarrollo de servicios bajo REST Spring que es una arquitectura de software para crear servicios distribuidos como la World Wide Web. Debido a que la finalidad no es el desarrollo de servicio sino el aprovechamiento de este, este trabajo se apoya en los servicios de la OGC, que son API's tipo Web Services Geoespacial que facilitan la integración y consumo de datos alojados en servidores de mapas remotos de manera rápida y resumida operando sobre protocolos HTTP de manera clara entre diferentes soluciones tecnológicas entre ellas las basadas en licencia Open Source.

En este orden y apoyándose en los aportes de McCarthy (2014), Vijayshree y Patil (2013) y Ranjit et al. (2013) la metodología se dividió en cuatro etapas fundamentales (Figura 10):

1. Definición de zona e información de estudio. 2. Análisis

requerimientos

selección/diseño/implementación

alternativas tecnológicas. 3. Definición de Ambiente de Bases de Datos y Consultas. 4. Integración y consumo desde servicios OGC.

Victoria Urresti, José Miguel

Figura 10. Diagrama de proceso de investigaciĂłn.

Victoria Urresti, JosĂŠ Miguel

3.1 DEFINICIÓN DE ZONA E INFORMACIÓN DE ESTUDIO Por disponibilidad de datos se seleccionó la zona geográfica en donde Widetech S.A.S. (WT) ofrece servicios de monitoreo satelital a flota de vehículos. Dicha zona abarca los siguientes países: México, Guatemala, El Salvador, Honduras, Nicaragua, República Dominicana, Costa Rica, Panamá, Colombia, Venezuela, Ecuador, Perú, Bolivia, Chile, Paraguay y Argentina (Figura 11).

. Figura 11. Zona de estudio de proyecto, Latinoamérica. Modificado de Wikimedia Commons, 2009.

Victoria Urresti, José Miguel

3.1.1 Zona geográfica Efectiva La zona de estudio como se indicó en el apartado anterior, a grandes rasgos comprendió varios países de Latinoamérica. No obstante, la zona geográfica efectiva fueron los centros poblados y red vial intermunicipal de estos países, en donde la flota de vehículos monitoreada por WT reporta localización.

3.1.2 Caracterización de la Información La información para esta investigación se clasifico de la siguiente manera: información geográfica GPS (almacenado en archivo plano CSV), información geográfica de clientes WT (almacenado en MySQL) e información geográfica para georreferenciación (almacenado en formato geográfico Tab MapInfo33), que es actualizada por el Área de cartografía de WT. A continuación, se describe dicha información:

3.1.2.1 Información Geográfica GPS Esta información correspondía a datos puntuales de localización relacionados con los recorridos de la flota de vehículos, en un área de influencia geográfica entre 5 a 60 metros alrededor de los ejes viales de países mencionados anteriormente. Esta área fluctúa debido a que, una traza o nube de puntos originados a partir de GPS de un solo vehículo puede tener una discrepancia de posición respecto al eje de la vía, además que la precisión y la calidad de la señal GPS al momento de la captura puede ocasionar dicha discrepancia.

La información estaba compuesta por los siguientes atributos: coordenada geográfica (longitud, latitud), IMEI34, fecha UNIX, velocidad, error de posición y rumbo al momento de la captura. En la Figura 12, se observa una representación gráfica de 450.000 ubicaciones, entre 7:00 a 10:00 GMT – 5, procedente de dispositivos GPS instalados en aproximadamente 1,200 vehículos que reportan

MapInfo es software de escritorio de sistema información geográfica, utilizado principalmente para el mapeo y análisis de localización. 34 IMEI; se refiere identidad internacional dispositivo móvil Victoria Urresti, José Miguel

cada 30 segundos a la plataforma Web.

Figura 12. Representación de 450 mil ubicaciones aprox. de Flota Vehicular Reportadas en 3h.

3.1.2.2 Información Geográfica de Clientes WT Esta información correspondía a datos tipo punto (llamado puntos de interés) y polígono (llamado zonas) que describen capas de interés para el cliente WT: parqueaderos, cajeros automáticos, bodegas, bancos, zonas de abastecimiento, Victoria Urresti, José Miguel

estaciones de combustible, peajes, áreas industriales etc. Actualmente esta información es usada, en el módulo de mapas, módulo de monitoreo y reportes de la plataforma Web de monitoreo de satelital de WT, para apoyar la toma de decisión en los procesos operativos de cada cliente, como, por ejemplo: verificar entrada o salida a lugares en particular, monitorear el cumplimiento de itinerarios, brindar sitios de referencia que oriente a conductores, vigilar la ubicación del vehículo etc.

3.1.2.3 Información Geográfica para Georreferenciación Esta información correspondía a capas geográficas puntuales que almacenaban información para georreferenciación vial y se dividía en dos conjuntos de datos. El primer conjunto eran pares de puntos ubicados al 20 y 80 % de la longitud total de cada segmento de vía. En contexto, correspondía a información de intersecciones viales, que además de estar representado por latitud y longitud indican el nombre de la vía y la vía interceptora más cercana, por ejemplo, un par de intersecciones para un mismo segmento de vía puede tener las siguientes descripciones: “Bogotá, Chapinero CL 70 – CR 12 A”, “Bogotá, Chapinero CL 70 – CR 13” este tipo de puntos son usados por los conductores en tiempo real (a través de aplicación móvil) y los usuarios operadores (a través de plataforma Web) para conocer el nombre o dirección vial por el cual transita el vehículo en un centro poblado. El segundo conjunto, son puntos ubicados cada 250 metros sobre vías fuera de los centros poblados (carreteras interdepartamentales o intermunicipales). En contexto, correspondía a información de kilometraje vial, que además de estar representado por latitud y longitud, indican los 2 centros poblados que conecta la vía y nombre de la misma, por ejemplo, un punto de kilometraje de una carrera entre dos municipios puede tener la siguiente descripción: “Vía Bogotá – Mosquera (Col) Km 2.5” (el valor numérico “2.5” está dado por la longitud misma de la carretera de acuerdo con la ubicación del punto de kilometraje). Este tipo de información tiene igual uso que las intersecciones viales. Para el momento de recopilación de la información se contó con 644.098 puntos y 69.470 zonas de interés y 7.828.988 puntos correspondiente a intersecciones viales y kilometraje. Es importante agregar, que las operaciones espaciales que relacionan las capas Victoria Urresti, José Miguel

de clientes o georreferenciación versus localizaciones GPS se le delega solo al cliente de la plataforma; no existe con ninguna comunicación con algún servicio Web o base de datos.

3.2 ANÁLISIS DE REQUERIMIENTOS En esta etapa se definió los requerimientos necesarios para lograr los objetivos y alcances planteados para esta investigación, dado que este proyecto está dentro del ámbito ingeniería de software fue necesario establecer funcionamiento, restricciones y comportamiento que debe tener el servicio de geoprocesamiento en Cloud Computing con sistemas NoSQL y RDBMS, que de acuerdo con Vijayshree y Patil (2013) es indiferente al caso de estudio. Para ello se describieron dos tipos de requerimientos; funcionales y no funcionales, que a continuación se describen:

3.2.1 Requerimientos no Funcionales del Sistema Se especificaron las propiedades del sistema, tales como restricciones del ambiente y desarrollo, dependencias de plataformas, integridad y seguridad. Estos requerimientos se encuentran detallados en la Tabla 1. Tabla 1. Listado de Requerimientos No Funcionales del sistema

Nombre Naturaleza Pruebas Concurrencia Cliente/Servidor Open Source

Integridad

Descripción Web Services. Desde Ambiente Web. Debe permitir el acceso concurrente. Debe seguir el modelo arquitectónico cliente/servidor. Debe ser desarrollada mediante aplicaciones gratuitas, de código Open Source con licencia GNU GPL35. Debe ofrecer garantías en la integridad de los datos almacenados.

GNU GPL. se refiere a Licencia gratuita Pública General de GNU de copyleft para software y otros tipos de proyectos, dicha licencia garantiza a los usuarios finales la libertad de usar, estudiar, compartir (copiar) y modificar el software (Stallman, 1992). Victoria Urresti, José Miguel

Flexibilidad Eficiencia Documentación

Debe poder adaptarse a nuevos requisitos funcionales. Debe ser eficiente en tiempos de computación. Debe disponer de una documentación extensa y adecuada, tanto para usuarios como para futuros desarrolladores.

3.2.2 Requerimientos Funcionales del Sistema Al mismo tiempo, se definieron una serie de requerimientos funcionales, que establecen los lineamientos de operatividad que el servicio debe ofrecer a un usuario. Estos se detallan en la tabla 2. Tabla 2. Listado de Requerimientos Funcionales del sistema

Nombre Datos Consulta Validación

Prototipo Visor Cartográfico

Descripción Debe recuperar datos alfanuméricos y geográficos de una base de datos espacial. Debe realizar consultas espaciales Debe permitir validar si la geometría editada cumple las reglas topológicas mínimas de la base de datos espacial. La interfaz Web de prueba debe ser sencilla e intuitiva. Debe de disponer de controles que permitan la interacción con la información espacial.

3.3 SELECCIÓN

ALTERNATIVAS

TECNOLÓGICAS

SISTEMAS NOSQL/RDBMS 3.3.1 Definición de Software Geoespacial Una vez se establecieron los requerimientos funcionales y no funcionales se definió las tecnologías que cumplieran dichos requerimientos. Esta selección dependió de una parte teórica y empírica. La parte teórica consistió en un proceso de exploración y revisión bibliográfica identificando investigaciones similares, estándares en desarrollo y la facilidad de integración entre las diferentes alternativas. Victoria Urresti, José Miguel

En particular para la tecnología NoSQL la revisión fue exhaustiva, debido a que, para el desarrollo metodológico, era la menos conocida. De acuerdo con Frenoy (2013), las bases de datos orientadas al almacenamiento tipo documento utilizan codificaciones como XML o JSON; este último formato se adaptaba muy bien al formato de entrada o salida dentro de la plataforma Web de WT que hace recepción datos GPS. Además, maneja una representación de datos sencilla, fácilmente comprensible desde una perspectiva humana y que de acuerdo con la estructura que se almacena en la plataforma no es compleja. Por otro lado, la selección de la tecnología NoSQL debía tener un soporte de datos geográficos. Tal y como indica Baas (2012), los siguientes proyectos NoSQL admiten soporte de datos espaciales: CouchDB con GeoCouch, Neo4j con el complemento Neo4j-Spatial, MongoDB con geohashing. De este último se tenía un conocimiento básico por dicha razón, la curva de aprendizaje no era tan grande a comparación de las demás opciones, por lo anterior, se seleccionó MongoDB 3.0 siguiendo las consideraciones para su puesta en marcha en un ambiente Amazon Linux (ver Apéndice A). La parte empírica consiste en experiencias profesionales relacionadas a la implementación de almacenes de datos y tecnologías de la información geográfica. En este sentido, se optó por las siguientes tecnologías: PostgreSQL como base de datos relacional, PostGIS como extensión espacial (su instalación se especifica en el Apéndice B); Geoserver como servidor espacial; en la actualidad única tecnología que permite la creación de almacenes de datos desde MongoDB (ver procedimiento de instalación en el Apéndice C), Openlayers como cliente Web para la fase de pruebas de consumo de servicios OGC, y Amazon EC2 AWS como servidor de alojamiento. Se debe indicar que el componente que permite crear almacenes de datos desde una base de datos MongoDB, no está soportado por Geoserver en su presentación para usuarios finales. No obstante, existe un complemento para habilitar este soporte; el procedimiento para habilitar esta capacidad se indica en el Apéndice D. Victoria Urresti, José Miguel

3.3.2 Descripción de Entorno Hardware La implementación, despliegue y pruebas de servicio de geoprocesamiento en la nube se realizó alojando en una máquina virtual de Amazon EC2 con sistema operativo Ubuntu GNU/Linux. De acuerdo con Amazon (2015), las especificaciones técnicas de la máquina fueron una instancia m3. large36 procesador Intel Xeon E52670 v2, 2 vCPU37 y 15 Gb. en memoria.

3.4 DEFINICIÓN DE AMBIENTE EN BASES DE DATOS A continuación, se procedió a almacenar los datos descritos en el apartado 3.1.2 para cada base de datos seleccionada. Para lo anterior se realizó las siguientes actividades:

Preparación de datos: Los datos procedentes de formato MySQL y MapInfo se manipularon con sistema de referencia WGS84. Seguidamente se definieron entidades geográficas con base a cada capa de información y asimismo estructuras de atributos asociadas, tal como se presenta en el Apéndice E. Adicionalmente, los datos fueron revisados para detectar errores de orden geométrico, tabular o duplicidad. Aprovechando las ventajas funcionales de PostgreSQL, se hizo la depuración con esta base de datos (Apéndice F). El tamaño total de datos tuvo una cuota de almacenamiento en disco de 20 GB comprimido.

Vale la pena agregar que las bases de almacenamiento usadas por WT al momento de iniciar la investigación tenían ciertas limitaciones. MapInfo no dispone un componente directo de interoperabilidad o un canal de comunicación, como, por ejemplo, Web Services con el cual se pueda comunicar la plataforma Web WT y los datos. Por otro lado, MySQL no disponía del módulo espacial que permitiera la interpretación geométrica u operaciones geográficas; por dicha razón solo eran

Documentación Amazon, Tipos de instancias de Amazon EC2 (Amazon, 2015). vCPU; se refiere a unidad de procesamiento central (CPU) física asignada a una máquina virtual (VM) 37

Victoria Urresti, José Miguel

usados para guardar la información que posteriormente era exportada a formato tabular como CSV y KML para ser cargada en los mapas y listados dentro de plataforma Web.

Exportación de datos. Para exportar la información recopilada de Mapinfo y MySQL a cada base de datos, se convirtieron los datos en archivos CSV y GeoJSON (un archivo por cada capa de información) para PostgreSQL y MongoDB respectivamente, para ello se utilizó la herramienta de conversión ogr2ogr38. Para PostgreSQL se hizo un paso adicional, después de tener obtener los datos en CSV, se usó terminal psql39 para ser exportados a tablas PostgreSQL.

Integración de datos en tiempo real. Para la captura de los datos futuros, procedentes de señales GPS, se creó una tarea programada Python que interactúa con el Sistema Códec40 GPS de WT, y que se ejecuta cada 30 segundos con el fin de almacenar la última posición de cada vehículo en un tiempo determinado.

Modelos de datos e Índices. Debido a la cantidad de datos a manipularse se usaron índices espaciales; para PostgreSQL se realizó indexación de árbol R permitiendo organizar los datos en objetos multidimensionales y garantizar el acceso a estos de forma rápida sin necesidad de buscar en cada fila, adicional se implementó en la infraestructura de PostgreSQL GiST41 (PostGIS, 2014), mientras que en MongoDB se usaron sus índices espaciales mediante la encoding de hash geográfico en la parte superior de la estructura de indexación MongoDB B-Tree (MongoDB, 2015).

ogr2ogr; herramienta de línea de comandos que convierte un origen de datos definido Ogr en otro origen de datos Ogr 39 Psql; terminal interactiva de la base de datos PostgreSQL que permite construir, publicar y ver resultados de consultas de la base de datos 40 códec es un programa hardware capaz de codificar o decodificar una señal o flujo de datos digitales 41 GiST, es el acrónimo de Búsqueda Generalizado en árbol (del original en inglés: Standard for Generalized Search Tree). Victoria Urresti, José Miguel

3.5 PANORAMA DE CONSULTAS E IMPLEMENTACIÓN Teniendo la disposición final de los datos y la arquitectura en los almacenes, se formuló un conjunto de consultas no espaciales y espaciales, descritas en la Tabla 3, tal y como sugirió McCarthy (2014) en su investigación, para establecer la viabilidad de uso de ambos sistemas de base de datos, para posteriormente ser accedidas por medio de servicios de OGC. Estas consultas se definieron para una operación de logística y rastreo de vehículos para Latinoamérica teniendo en cuenta una carga real de datos diarios desde un SIG Web. Tabla 3. Puntos de referencia para consultas geoespaciales

Consulta

MongoDB

PostgreSQL42

Descripción

Inserción

db.collection.ins ertMany()

insert into table()

Crea un documento o registro geométrico en la base de datos.

Actualización

db.collection.upd ateMany()

update table set

Actualiza un documento o registro geométrico en la base de datos.

Borrado

db.collection.del eteMany()

delete from table

Borra un documento o registro geométrico en la base de datos.

Distancia min./max.

db. collection.find $maxDistance $minDistance

ST_DWithin + Order by distance

Busca la distancia mínima o máxima de un elemento geográfico dentro de una cercanía definida.

Cercanía

$nearSphere

ST_Closest Point

Especifica unas geometrías para el que una consulta geoespacial devuelve los elementos del más cerca a más lejos (en MongoDB solo funciona para puntos).

Intersección geométrica

$geoIntersects

ST_Intersect s

Selecciona documentos o geometría (MongoDB/PostgreSQL))

PostgreSQL hereda las funciones geográficas una vez se utiliza una plantilla espacial de la extensión PostGIS Victoria Urresti, José Miguel

cuyos datos geoespaciales se cruza con un objeto especificado.

3.5.1 Niveles de la Arquitectura Implementada Posteriormente se realizó el desglose general de toda la arquitectura, en relación con la Figura 13. De abajo hacia arriba, está el nivel físico que estaba constituido por la red y hardware (este nivel no fue manipulado; se usó la infraestructura con las configuraciones iniciales encontradas). El nivel de servicios Cloud que se encargó de gestionar de forma dinámica los recursos con base al servicio SaaS, continua el nivel de geoprocesamiento tiene como función la ejecución de tareas de procesamiento en paralelo incluyendo: programaciones de tareas y gestión de datos espaciales, el nivel de servicio que es el contenedor de los servicios geoespaciales OGC publicados en Geoserver tales como WMS, WFS, y WFS-T y por último el nivel más alto el de aplicación corresponde a la interfaz de usuario y los servicios de información espacial el cual fue delegado a OpenLayers.

Victoria Urresti, José Miguel

Figura 13. Arquitectura Lógica del sistema

3.5.2 Integración y consumo desde servicios de OGC En esta sección se profundiza sobre el nivel de la aplicación y de servicio. De acuerdo con lo planteado en la arquitectura, se tuvo un modelo de almacenamiento de datos, comunicación de ordenadores y provisión de servicios y aplicaciones sobre Amazon EC2. En dicho modelo se pueden identificar tres capas (Figura 14): la capa de aplicación que constituye el cliente Web que realiza las solicitudes de consulta y recepción de las respuestas del servicio, capa de servicio encargada de procesar las solicitudes tomando como insumo los datos almacenados en la capa de persistencia y la capa persistencia que se encarga de que los datos sobrevivan en los almacenes de datos.

Victoria Urresti, José Miguel

Figura 14. Arquitectura general de interoperabilidad en sistemas RDBMS y NoSQL.

La capa de cliente (Openlayers) es la responsable de la interacción entre los usuarios, servicios de geoprocesamiento y datos espaciales a través de servicios OGC (WMS, WFS, WCS etc.). De igual manera, se creó unos formularios de consultas espaciales y de filtros espaciales.

La capa de servicio (Geoserver) debe definir las directrices para que la capa de aplicación accediera a las funcionalidades y servicios OGC. En esta capa, se consultó los almacenes de datos MongoDB y PostgreSQL. Esta capa fue desarrollada de acuerdo con el patrón de arquitectura MVC con el propósito de separar la lógica de negocio de la lógica de presentación y de control de flujo de la aplicación. Las solicitudes recibidas desde la capa de aplicación son manejadas por el controlador del servicio en cuestión y a su vez redirige al modelo responsable. El servicio verifica si los atributos necesarios están completos y si tienen los valores correspondientes. En el caso que las solicitudes sean inválidas se genera la correspondiente excepción de servicio que se retransmite en un formato JSON y esto sucede para cualquier tipo de solicitud desde el prototipo de prueba.

Con respecto a los tipos de servicios implementados desde los dos almacenes de datos, se llevaron a cabo las versiones 1.3.0 y 1.1.0 de los servicios WMS y WFS, Victoria Urresti, José Miguel

respectivamente. La implementación del protocolo WMS incluye sólo las operaciones obligatorias (GetCapabilities, GetMap y GetFeatureInfo). Para el protocolo WFS se incluyó las operaciones GetCapabilities DescribeFeatureType GetFeature y Transational. Adicional para implementar estos servicios, no se utilizó ningún intermediario, es decir que, se delegó dicha gestión solo al servidor de mapas Geoserver sin necesidad de manejar tareas programadas o complementos adicionales.

Para el caso de una solicitud a la capa de servicio, por ejemplo, a partir de una operación GetMap en un servicio WMS, Geoserver se encarga de recibir y de obtener los límites geográficos y capa geográfica de interés especificada por la capa de la aplicación. Posteriormente este identifica el repositorio de datos y se solicita a la capa de persistencia el envío de datos en formato de salida GeoJSON que la capa aplicación, finalmente convierte en una imagen georreferenciada que es renderizada en mapa digital en un ambiente Web.

Dado las características de MongoDB se utilizó 3 instancias (que contenían la misma cantidad de datos): una instancia principal y dos instancias secundarias. Se optó por este tipo de arquitectura porque evita puntos de fallo, que de acuerdo con la investigación Frenoy (2013) "asegura una buena disponibilidad y consistencia de los datos, por ende, es muy recomendable usar conjuntos de réplicas" (p. 22).

La instancia principal controló todas las operaciones de escritura en el conjunto de las réplicas y controló las modificaciones directas en los datos. Las instancias secundarias cumplieron el rol de manejar operaciones de lectura. Desde un punto de vista técnico es posible escalar esta arquitectura añadiendo nuevos servidores, que, aunque es una ventaja, no obstante, deja la limitación que el conjunto de réplicas simples no se pudo escalar frente a una creciente cantidad de datos. Según Frenoy (2013), frente a esto es necesario desplegar una arquitectura compartida, sin embargo, no se realizó porque no era un alcance de la investigación.

Victoria Urresti, José Miguel

3.6 IMPLEMENTACIÓN DE EXPERIMENTOS Y PROTOTIPO WEB Para esta parte de la investigación se definieron dos experimentos, el primer experimento probo el rendimiento de carga y la capacidad de consulta concurrente y espacial con los datos, el segundo experimento evaluó el comportamiento de interoperabilidad entre las bases de datos espaciales, servidor de mapas y cliente cartográfico Web.

3.6.1 Experimento 1: Análisis a nivel almacén de datos Para este experimento se tomaron localizaciones GPS en tres conjuntos de datos delimitados por los siguientes territorios: Colombia, Suramérica y Latinoamérica. Estas localizaciones se originaron un lunes en la mañana, para un lapso de 3, 5 y 9 horas (Tabla 4), jornada laboral activa dentro una operación logística de WT se caracteriza por un tráfico constante de datos. Tabla 4. Datos GPS capturados en diferentes lapsos de tiempo.

Z. Geográfica

cuota en 3h. (GB)

cuota en 5h. (GB)

cuota en 9h. (GB)

Colombia

0.320

0.56

1.05

Suramérica

0.855

1.5

2.2

Latinoamérica

2.6

10.5

GB: Gigabyte

Teniendo como base los conjuntos de datos, se plantearon tres escenarios dentro de este experimento:

El escenario 1 consistió en construir consultas de inserción de datos teniendo en cuenta cada conjunto de datos, prescindiendo de alguna capa o tecnología intermedia. Así pues, para Mongo DB se planteó una consulta que permitiera la inserción de múltiples localizaciones (que a nivel base de datos se denomina documentos) dentro de colección de datos llamada “hist_gps”, por ejemplo, en el fragmento de código (Fragmento 1) se definió un documento o localización GPS y sus respectivos atributos, seguidamente se utilizó el método insertMany() para Victoria Urresti, José Miguel

realizar la inserción de dos localizaciones, sí la operación es correcta, el atributo “insertedIds” del objeto respuesta retorna el número de localizaciones insertadas. //La colección hist_gps tiene documentos con la siguiente estructura: { _id: ObjectId("563237a41a4d68582c2509da"), cpid: 4.667100, cplatitude: 4.667100, cplongitude: -74.095329, cpdatetime: ISODate("2016-11-01T11:30:15Z"), cpvelocity: 48, cpname: "Av. Calle 63", cpdirection: "60" } //El siguiente ej. utiliza db.hist_gps.insertMany()para insertar documentos que no contienen el campo _id: try { db.hist_gps.insertMany( [ {cpid: 358300053188118, cplatitude: 4.667100, cplongitude: 74.095329, cpdatetime: ISODate("2016-11-01T11:30:15Z"), cpvelocity: 52, cpname: "Av. Calle 63, Bogota", cpdirection: "230"}, {cpid: 356300053188098, cplatitude: 3.416495, cplongitude: 76.527888, cpdatetime: ISODate("2016-11-01T11:34:05Z"), cpvelocity: 40, cpname: "Calle 14, Santiago de Cali", cpdirection: "20"} ] ); } catch (e) { print (e); } //La operación devuelve el siguiente documento: { "acknowledged": true, "insertedIds": [ ObjectId("562a94d381cb9f1cd6eb0e1a"), ObjectId("562a94d381cb9f1cd6eb0e1b") ] } Fragmento 1. Inserción de múltiples localizaciones GPS en MongoDB

Es importante agregar que MongoDB no dispone un lenguaje a diferencia de PostgreSQL con SQL. Alternativamente, como se pudo apreciar se usaron métodos que permitieron realizar cada una de las operaciones mediante objetos JSON como parámetro. Este tipo de consulta es bastante lógica y los documentos se Victoria Urresti, José Miguel

almacenaron en BSON43 que es una representación binaria de los datos.

Por otro lado, para PostgreSQL se construyó una consulta similar, para la inserción de múltiples registros en la tabla o entidad space.hist_gps teniendo en cuenta los campos de dicha tabla, por ejemplo, en el fragmento 2 se puede observar como mediante la declaración SQL insert into se realiza la inserción de 3 registros o localizaciones GPS en la entidad de históricos GPS. /*consulta básica de inserción sobre entidad "historicos_gps" en base de datos relacional postgres*/ INSERT into space.hist_gps ("CpId", "cpLatitude", "cpLongitude", "cpDateTime", "cpVelocity", "cpName", "cpDirection" ) VALUES /*inserción de 3 registros*/ (358300053188118,4.655668, -74.110667, 2016/11/01 11:30:15',42,'location233','15'), (352300053188208, 4.663721, -74.068335, 2016/11/01 11:30:15',42,'location234','35'), (350300453188118,4.655668, -74.110667, 2016/11/01 11:30:15',42,'location235','190'); Fragmento 2. Inserción de múltiples localizaciones GPS en PostgreSQL

Las operaciones de inserción ejecutadas para ambos almacenes de datos se hicieron con un solo cliente usando un solo procesador o proceso.

El escenario 2 consistió en simular consultas concurrentes (procesos simultáneos), similares a las manejadas por la plataforma WT. Hay que anotar que, las solicitudes de los usuarios se llevaron a cabo mediante un tipo de comunicación asíncrona para una cuota de datos en el lapso de 5 horas. Para ello al igual que el escenario 1 se involucró datos de localización GPS y se hicieron operaciones de actualización y borrado. Con relación a MongoDB se construyeron las respectivas consultas, utilizando método deleteMany para realizar borrado de múltiples localizaciones, por ejemplo, 43

BSON; es un formato de intercambio de datos usado principalmente para su almacenamiento y transferencia en la base de datos MongoDB Victoria Urresti, José Miguel

en el fragmento 3, se realiza una consulta que borra localizaciones con fecha de reporte mayor o igual "2016-08-01T08:20:00Z", sí la operación es correcta el atributo “deletedCount” del objeto respuesta retorna el número de localizaciones borradas. //La operación siguiente elimina todos los documentos donde la fecha de reporte sea mayor o igual a "2016-08-01T08:20:00Z" try { db.hist_gps.deleteMany( { "cpDateTime" : { $gte : new ISODate("2016-08-01T08:20:00Z") }} ); } catch (e) { print (e); } //La operación devuelve: { "acknowledged" : true, "deletedCount" : 352 } Fragmento 3. Borrado de múltiples localizaciones GPS en MongoDB

Para PostgreSQL se construyó una consulta similar, para borrado de múltiples registros en la tabla o entidad space.hist_gps, de acuerdo al fragmento 4 se observa como mediante la declaración SQL Delete se realiza el borrado de relaciones o localizaciones GPS con fecha de captura mayores o iguales a '201602-01 10:04:09.811'. /*consulta básica de borrado entidad "historicos_gps" en base de datos relacional postgres*/ DELETE FROM space.hist_gps WHERE "cpDateTime" >= '2016-02-01 10:04:09.811'; Fragmento 4. Borrado de múltiples localizaciones GPS en PostgreSQL

De igual manera se construyó la consulta de actualización de múltiples documentos y localización para MongoDB a través del método UpdateMany, por ejemplo, en el fragmento 5, se realiza la actualización de localizaciones en donde la velocidad reportada al momento de captura es menor o igual 15 km/h.

Victoria Urresti, José Miguel

//La operación actualiza todos los documentos donde la velocidad es menor o igual a 10. try { db.hist_gps.updateMany( { cpvelocity: { $lte: 15 } }, { $set: { "Review" : true } } ); } catch (e) { print(e); } //La operación devuelve: { "acknowledged" : true, "matchedCount" : 245, "modifiedCount" : 245 } Fragmento 5. Actualización de múltiples localizaciones GPS en MongoDB

Finalmente, para cerrar las pruebas del escenario 2 se construyó la consulta de actualización para PostgreSQL, por ejemplo, en el fragmento 6. Se realiza mediante la declaración SQL Update la actualización de las relaciones o localizaciones en donde la velocidad al momento de la captura era mayor o igual a 15 km./h. /*consulta básica de actualización entidad "historicos_gps" actualiza las relaciones donde la velocidad es menor o igual a 10*/ UPDATE space.hist_gps SET "review" = TRUE WHERE "cpVelocity" >= 15; Fragmento 6. Actualización de múltiples localizaciones GPS en PostgreSQL

Con respecto al escenario 3 se realizó consulta de las localizaciones GPS, para el lapso de 9 horas, versus las capas geográficas bases definidas por la investigación: información de clientes (entidad puntos de interés y zonas), información para georreferenciación (entidad intersecciones y kilometraje).

En este orden, se construyeron las siguientes consultas espaciales, de acuerdo, a un servicio real que pueda requerir la plataforma WT. Para la primera consulta se buscaba verificar el número de zonas de cliente que interceptan con la ubicación geográfica de un vehículo determinado, la segunda consulta buscaba retornar las Victoria Urresti, José Miguel

intersecciones o kilometrajes más cercanos a la posición real de un vehículo determinado y la tercera consulta consistía en retornar los puntos de interés a una distancia mínima y máxima de la ubicación geográfica de un vehículo determinado.

Suponiendo que se tiene una localización geográfica para un vehículo en longitud: -99.136450; latitud: 19.446901 (Zona de operación: Ciudad de México) en determinado tiempo; la consulta en el MongoDB para retornar las zonas interceptadas con dicho vehículo se plantearía tal como parece en el fragmento 7, en donde, a través del método find() en la colección cpzones se espera encontrar cinco zonas del cliente con identificador 43 (cpid) que interceptan con la ubicación del vehículo definida en el objeto JSON point usando el operador geoespacial "$geoIntersects". //definicion de objeto point point= {type: "Point", coordinates: [-99.136450, 19.446901]}; db.cpzones.find({ "geo": { "$geoIntersects": { "$geometry": point } }, "cpid": 43 }).limit(5) Fragmento 7. Consulta de intersección espacial sobre MongoDB

Una consulta con la colección cpzones que retorne un resultado exitoso tendría objetos JSON por cada zona interceptada con la localización del vehículo. { "_id" "562a94c381cb9f1cd6eb0e50", "cpId": 43, "cpName": "name_827", "cpWKT": {"type":"Polygon","coordinates":[[99.15693052922409834,19.43942573405322705],[ 99.15282242699193205,19.45417449452607173],[ -99.1499938975861852, 19.45727240768475497],[ -99.11430055032312225 ,19.4489888572821954],[ -99.12009230101109836, 19.42083825510114536],[ -99.15450607544774186

Victoria Urresti, José Miguel

,19.42561981671562776],[ -99.16386716086201147, 19.42353209263043112]]}, "cpType": "", "cpTypeGeom": 2, "cpRadio": 100, "cpUserId": "", "cpDateTime": "", "cpStatus": "t", "cpColor": "FF0000", "cpCity": "Mexico D.F", "cpAddress": "MX - Palacio de Bellas Artes" } Fragmento 8. Respuesta de consulta de intersección espacial en MongoDB

De igual forma, se planteó la respectiva consulta de intersección espacial sobre PostgreSQL,

para

esto

implementó

función

ST_Intersects

st_GeomFromText teniendo de referencia el identificador del cliente al cual pertenece la zona y vehículo (Fragmento 9). Una consulta exitosa con coincidencia arrojaría una relación por cada zona interceptada con la localización del vehículo. /*se retorna el número de relaciones o zonas que interceptan con la localización lat, long de un vehículo */ SELECT r."cpId", r."cpName", r."cpWKT", r."cpGeom", r."cpType", r."cpTypeGeom", r."cpRadio", r."cpUserId" FROM space.cpzones r WHERE ST_Intersects( st_geomfromtext('POINT(-99.110446 19.453831)',4326) ,r."cpWKT") AND r."cpId" = 43; Fragmento 9. Consulta de intersección espacial sobre PostgreSQL

Seguidamente se construyó la consulta dos, para realizar la búsqueda de las intersecciones o kilometraje más cercanas a la localización geográfica de un vehículo. Tal como aparece en el fragmento 10, para MongoDB se utilizó el método find con el operador geoespacial "$nearSphere" para encontrar las 15 intersecciones o kilometraje más cercanas a la ubicación del vehículo (objeto point), del mismo modo, en PostgreSQL se utiliza la función espacial ST_ClosestPoint para retornar la misma cantidad de intersecciones o kilometraje cercanos al vehículo. Victoria Urresti, José Miguel

//Consulta sobre Base de datos MongoDB //definicion de objeto point point= {type: "Point", coordinates: [longitude, latitude]}; db.intersections.find({ "geo": { "$nearSphere": { "$geometry": point } }, "cpid": 43 }).limit(15) /*Consulta sobre Base de datos PostgreSQL*/ /*FUNCTION st_closestpoint(geometry, geometry); */ SELECT r."cpId", r."cpName", r."cpWKT", r."cpGeom", r."cpType", r."cpTypeGeom", r."cpRadio", r."cpUserId" FROM space.cpintersections r WHERE ST_ClosestPoint( ST_GeomFromText ('POINT ('||r."cpLongitude"||' '||r."cpLatitude"||')',4326), ST_GeomFromText ('POINT (-75.706101 4.814463)',4326) ) LIMIT 15; Fragmento 10. Consulta espacial de cercanía para MongoDB y PostgreSQL

Finalmente se construyó la consulta tres para realizar la búsqueda de los puntos de interés a una distancia mínima y máxima a una localización geográfica de un vehículo. Tal como aparece en el fragmento 11, para MongoDB se utilizó el método find

los

operadores

geoespaciales

"$nearSphere",

$minDistance"

$maxDistance", para encontrar los puntos de interés entre una distancia máxima y mínima a la ubicación del vehículo (objeto point), del mismo modo, en PostgreSQL se utiliza la función espacial ST_DWithin para retornar la misma cantidad de intersecciones o kilometraje cercanos al vehículo teniendo en cuenta la ordenación de distancias a partir de la función ST_Distance.

Victoria Urresti, José Miguel

//Consulta sobre Base de datos MongoDB point = { type : "Point", coordinates : [ -73.120994, 7.121569 ]}; db.cppoints.find( { "location": { "$nearSphere": { $geometry": point, $minDistance": 0, $maxDistance": 250 } }, "cpid":103 } ) /*Consulta sobre Base de datos PostgreSQL*/ SELECT DISTINCT ON (r."cpId") r."cpId", ST_Distance(r.centroid, ST_GeomFromText ('POINT (-75.706101 4.814463)',4326)) as dist FROM cppoints r WHERE ST_DWithin(r.centroid, ST_GeomFromText ('POINT (-75.706101 4.814463)',4326), 250) ORDER BY r."cpId", ST_Distance(r.centroid, ST_GeomFromText ('POINT (-75.706101 4.814463)',4326)) LIMIT 5;

Fragmento 11. Consulta de distancia esférica para MongoDB y PostgreSQL

3.6.2 Experimento 2: Interoperabilidad a través servicios de OGC Para este experimento se construyó un prototipo Web usando OpenLayers, con el fin de evaluar la interoperabilidad entre las bases de datos espaciales. La comunicación entre el contenedor de aplicación Web y el servicio de mapas fue transparente, al estar alojadas bajo la misma infraestructura y bajo el mismo dominio las solicitudes entre cliente y servicio no infringía ninguna política de seguridad. Para el prototipo se definieron unas herramientas de edición cartográfica como las son de inserción, modificación, borrado, cercanía e intersección para comprobar la capacidad de geoprocesamiento consumiendo datos desde ambas Victoria Urresti, José Miguel

bases de datos. Las solicitudes se realizaron a partir de AJAX y el primer operador implementado fue el GetCapabilities esto con la finalidad de verificar los metadatos, operaciones y parámetros soportados sobre cada servicio

Figura 15. GUI de Prototipo de digitalización cartográfica Web

Una vez se identificó los operadores a implementarse se dispusieron vistas dentro de la GUI44 para consumir una serie de funcionalidades; se crearon paneles de gestión de capas WMS a entidades tanto de Mongo como de PostgreSQL para representarlas en un contenedor de mapas y panel de encendido y apagado de las mismas (Figura 15. A), herramientas de filtrado para obtención de geometrías (B), control para recuperar atributos en particular (C), controles de edición (D).

GUI; es un programa informático con interfaz de usuario, utiliza un conjunto de objetos gráficos para representar la información y acciones disponibles en la interfaz Victoria Urresti, José Miguel

4. RESULTADOS A continuación, se describen los resultados obtenidos para cada uno de los experimentos plateados para esta investigación.

4.1 Experimento 1: Análisis a nivel almacén de datos Para el experimento 1. Análisis a nivel almacén de datos como se indicó se plantearon 3 escenarios de implementación. De acuerdo con el escenario 1. Tabla 5 (columna 3 y 4), se obtuvieron los tiempos en milisegundos que requirió MongoDB y PostgreSQL para insertar localizaciones obtenidas en el lapso de 3 horas para los 3 conjuntos de datos (Colombia, Suramérica y Latinoamérica) de manera estática. Tabla 5. Tiempo requerido para carga de datos de territorio Colombia

Z. Geográfica

núm. de GB. en 3h. T.R.A.P (ms)

T.R.A.M (ms)

Colombia

0.320

4,023

3,239

Suramérica

0.855

6,092

4,201

Latinoamérica

2.6

19,820

7,920

T.R.A.M: Tiempo de almacenamiento requerido en PostgreSQL; T.R.A.P: Tiempo de almacenamiento requerido en MongoDB: ms.: milisegundos

Para el escenario 2, se tuvo de referencia los datos obtenida en un lapso de 5h, para realizar consultas de actualización y borrado con una concurrencia de: 50, 100 y 300 usuarios; en dicha prueba se obtuvo resultados que se ilustran en la Figura 16. Dicha Figura, grafica la relación de número de usuarios concurrentes vs tiempo en segundos que tarda cada almacén de base de datos, PostgreSQL en barra color azul, MongoDB en color naranja, para actualizar o borrar localizaciones obtenidas a partir de señal GPS correspondiente a solo Latinoamérica en el lapso de 5h.

Victoria Urresti, José Miguel

Figura 16. Tiempos de consulta de actualización y borrado concurrente

Para el escenario 3, como se planteó en el capítulo anterior se realizaron diferentes consultas espaciales involucrando las localizaciones GPS (obtenidas en un lapso de 9 horas) y la información geográfica de clientes y georreferenciación; separados en tres conjuntos de datos (Colombia, Suramérica, Latinoamérica).

De acuerdo con la Figura 17, se puede observar que para la consulta de distancias (dato GPS vs. intersecciones), PostgreSQL en el set 1, tuvo un tiempo de respuesta menor que MongoDB; en el set 2, MongoDB supera PostgreSQL por muy poco, y para el set 3 MongoDB nuevamente supera PostgreSQL, pero esta vez la diferencia en tiempos de respuesta es considerable de casi 50 segundos.

Con relación a la consulta de cercanía (dato GPS vs puntos de interés), PostgreSQL en el set 1, también tuvo un tiempo de respuesta menor que MongoDB; en el set 2, MongoDB supera PostgreSQL por casi 50 segundos, y para el set 3, MongoDB supera PostgreSQL, igualmente por casi un minuto.

Victoria Urresti, José Miguel

Por otro lado, para la consulta de intersección espacial (dato GPS vs. zonas), PostgreSQL en el set 1, tuvo un tiempo de respuesta menor que MongoDB pero solo de 2 segundos; en el set 2 y 3, MongoDB supera PostgreSQL tiene un rendimiento de respuesta significativa de 65 y 123 segundos respectivamente.

Figura 17. Tiempos de consultas espaciales datos GPS vs. entidades

4.2 Experimento 2: Interoperabilidad a través servicios de OGC Con relación al experimento 2. de interoperabilidad a través servicios OGC, se adaptó al cliente OpenLayers para consumir los servicios y se añadieron las capas geoespaciales (puntos de interés, zonas, intersecciones, y localizaciones GPS; dos por cada almacén de datos), para realizar peticiones con diversas operaciones desde cliente. Las operaciones realizadas fueron GetCapabilities, GetMap en el servicio WMS y GetFeature en los servicios WFS y WFS-T. Una demostración de Victoria Urresti, José Miguel

comportamiento y consumo se describe en el Apéndice G. Para el caso de un servicio WMS, cada vez que se seleccionaba una capa renderizada en el mapa, OpenLayers utiliza la operación GetCapabilities para obtener la lista de capas disponibles para consumo, como, por ejemplo, para el pintado de una capa vectorial que representa la entidad de puntos de interés de un cliente en una ciudad en particular (Figura 18).

Figura 18. Renderización de entidad POI desde prototipo Web

De igual modo comprobó el funcionamiento de la operación Transation del WFS desde PostgreSQL y MongoDB, se pudo realizar edición de entidades para la creación, actualización y borrado, por ejemplo, en la Figura 19, se puede observar que se realiza una edición geométrica y tabular (a través de un formulario) de una geometría tipo línea desde el prototipo.

Victoria Urresti, José Miguel

Figura 19. Operación de Edición WFS-T a entidad desde prototipo Web

Victoria Urresti, José Miguel

5. DISCUSIÓN En este capítulo se desarrolla el espacio de discusión, bajo tres aristas; rendimiento computacional, funcionalidad espacial e interoperabilidad al implementar las dos alternativas de base de datos.

Con relación al rendimiento computacional se tiene que, en el Experimento 1, las pruebas de carga en el escenario 1 fueron menores en tiempo en MongoDB. PostgreSQL tiene tiempos de respuesta mucho mayor cuando el conjunto de datos es más grande. En la práctica, las operaciones en tablas o sistemas relacionales son O(n)45, esto quiere decir, que los tiempos de procesamiento aumentan a medida que se llega a muchos miles o decenas de miles de registros. Esto es evidente en el conjunto de datos a gran escala, por ejemplo, Latinoamérica, y dado las diferencias de tiempo entre los diferentes conjuntos de datos; se deduce que en un lapso mucho mayor el rendimiento seria mucho menor, hasta el punto de que puede producirse un cuello de botella en el manejo de las solicitudes. Además, PostgreSQL no es compatible con procesos múltiples, esto es una debilidad frente a sistemas NoSQL. En MongoDB, la velocidad de importación es constante, sin grandes momentos de congestión o desaceleraciones con el uso de memoria en máquina sin mayores fluctuaciones.

Para el escenario 2, que consistía en la ejecución de consultas concurrentes, el tiempo de respuesta para MongoDB es mucho menor que para PostgreSQL. Para PostgreSQL aumenta a medida que el número de usuarios es mayor, las relaciones fueron: 8s./50 usuarios, 12s./100 usuarios y 18s./300 usuarios. Los tiempos de respuesta para MongoDB, aumentan de forma imperceptible, las relaciones fueron: 0.45 s./50 usuarios, 1.35 s./100 usuarios y 2.40 s./300 usuarios.

Con lo anterior se deduce que MongoDB para operaciones básicas creación, lectura, modificación y borrado desde un cliente o de varios (de manera concurrente), muestra mejor rendimiento a diferencia de PostgreSQL. Esto es

O(n); notación, que indica el orden de crecimiento de alguna cantidad en función de n.

Victoria Urresti, José Miguel

debido a que almacena los datos en documentos, incluso no tiene necesidad de crear operadores on-the-fly para obtener un mejor rendimiento. Esto es una ventaja de rendimiento sobre todos los RDBMS y es evidente con el aumento de la escala de conjunto de datos. Por otro lado, la capacidad de sharding de MongoDB aumenta esta ventaja de rendimiento en el caso de conjuntos de datos grandes. PostgreSQL que opera en el modelo transaccional ACID mantiene la consistencia y aislamiento lo cual lo hace más lento a diferencia de las reglas BASE usadas por MongoDB.

Con relación a la funcionalidad espacial en el escenario 3, las consultas sobre geometrías tipo punto responden más rápido que para las geometrías polígonos esto es indiferente a la base de datos, y es debido a que, el tiempo de computo requerido para realizar operaciones geométricas es directamente proporcional a la complejidad de la geometría (dado por su extensión geográfica y número de nodos que la compone), en este sentido, un punto es una geometría simple. Por otro lado, para MongoDB, el comportamiento se refleja diferente; el tamaño del conjunto de datos no juega un papel crucial debido a que esta base de datos no realiza tantas validaciones topológicas como lo hace PostGIS.

Adicionalmente el rendimiento de PostgreSQL en conjunto de datos pequeños e independencia de geometría no conlleva tiempos tan altos. No obstante, esto cambia con una cantidad mayor de datos. Se puede determinar que, para el conjunto de datos 1 (Colombia), PostgreSQL funciona mejor cual que sea el tipo de geometría.

Como se pudo observar, en los resultados obtenidos para cada uno de los experimentos comprueba que soluciones NoSQL y relacionales gestionan información geográfica desde un contexto de Big Data e interoperabilidad, aunque MongoDB Spatial no admite los estándares OGC la implementación Geoserver mitiga esta debilidad en este sistema NoSQL.

Dado la diferencia funcional entre las dos bases de datos con relación a Victoria Urresti, José Miguel

operaciones espaciales, en la metodología se definió un contexto común, que evitará eliminar ítems de comparación dentro de los experimentos. Actualmente PostGIS tiene un catálogo de funciones espaciales mucho más amplio que MongoDB Spatial que permite que una aplicación SIG sea más robustas o con mayor cantidad de herramientas de análisis espacial, y también fue evidente en las investigaciones relacionadas a este proyecto, en donde MongoDB es usado en industria de SIG que requiere servicios espaciales con enfoque simplemente de georreferenciación o lectura de datos.

Además de analizar y discutir de forma crítica los resultados a continuación, se responden las preguntas de investigación planteadas al inicio de este documento:

«PI - 1» ¿Qué ventajas y desventajas conlleva de realizar procesos de geoprocesamiento a través de servicios OGC y almacén de datos NoSQL? Como se puede inferir del desarrollo de la investigación, un almacén de datos NoSQL tiene como ventajas la capacidad de partición para el manejo de grandes volúmenes y la rapidez en la captura/recuperación de datos, como desventajas tiene limitaciones para consultas y operaciones espaciales avanzadas y la dificultad para inter-operar con tecnologías geoespaciales orientadas ofrecer servicios geográficos con base a estándares promulgados por OGC. Actualmente MongoDB es la única solución NoSQL que puede interactuar con un componente tipo servidor de mapas, por ejemplo, Geoserver, a comparación de PostgreSQL y su extensión PostGIS que proporciona una amplia documentación y puede inter-operar con librerías, clientes y servidores de carácter geoespacial.

En el futuro, las soluciones NoSQL difícilmente reemplazarán los almacenes relacionales, ya que ambas cumplen diferentes beneficios en mayor o menor medida dependiendo a las características del proyecto: volumen, variabilidad y consistencia en los datos; rendimiento requerido en la captura y procesado de datos, o la disponibilidad de una infraestructura grande o pequeña. Para este estudio -según los alcances definidos y los tipos de bases de datos elegidas- es viable dichas soluciones en principio, aunque pueden existir limitaciones a largo Victoria Urresti, José Miguel

plazo si se requiere implementar funcionalidades más especializadas en manipulación de información vectorial.

«PI - 2» ¿Es posible tener un control de grandes bancos de datos geoespaciales implementando las nociones de la Big Data? Basado en el procedimiento metodológico de esta investigación, sí es posible tener dicho control de grandes bancos de datos. En lo que respecta a las soluciones relacionales, se han esforzado en mejorar es aspecto de ahorro de recurso/energía y escalabilidad para Big Data, no obstante, se evidencia en la metodología y resultados que aún las aplicaciones Web modernas no se acoplan de forma ideal a las soluciones relacionales a comparación de las NoSQL, que son ágiles y se comportan de forma ideal para aplicaciones construidas en la nube y que exigen alta disponibilidad y velocidad.

«PI - 3» ¿Existen sistemas de almacenamiento de datos vectoriales geográficos sin límite de esquemas, número/tamaño de entidades que mitigue el problema del control de grandes volúmenes de datos? De acuerdo con la respuesta de la pregunta anterior, tanto una solución relacional y NoSQL pueden responder a esto, en particular las soluciones de base de datos escogidas en esta investigación. MongoDB tiene una ventaja ya que puede ser particionada a diferencia de PostgreSQL. Aunque PostgreSQL no tiene límite explícito de tamaños de datos y número de esquemas, por lo menos recomendado en su documentación, se observa en los experimentos realizados, que a mayor tamaño en las entidades geográfica o número de registros en cada entidad tiende a incrementar el tiempo de respuesta en cada consulta y es indiferente a si es una consulta espacial o no espacial.

«PI - 4» ¿Cuál es el costo-beneficio de construir una herramienta SIG en la nube para procesos de procesamiento en Web? En etapa de selección de alternativas y definición de arquitectura se reconoció que una solución en la nube y adicional, tecnologías Open Source de carácter en SIG son una excelente opción para cualquier tipo de trabajo, ya que económicamente solo se paga por el almacenamiento que se utilice, además, de que no es necesario la instalación de Victoria Urresti, José Miguel

dispositivos físicos de almacenamiento en oficinas, lo que reduce los costos de tecnología informática y alojamiento. Básicamente, dicha alternativa es rentable dado que el mantenimiento en la copia de seguridad y la replicación de datos y la compra de dispositivos adicionales de almacenamiento se convierte en una responsabilidad de un proveedor del servicio.

Victoria Urresti, José Miguel

6. CONCLUSIONES La manipulación de datos geográficos vectoriales a gran escala, desde el punto de vista de, cuota de almacenamiento y velocidad de captura, con la metodología propuesta de implementación estándares de publicación OGC consumiendo RDBMS o NoSQL en Cloud Computing Services fue viable y eficaz. Como se amplió el capítulo de discusión, el uso de datos GPS y operaciones no tan complejas hizo factible la metodología, debido a que el contexto de soluciones de localización y monitoreo satelital que abordo la investigación, permitió sopesar las diferentes alternativas tecnológicas implementadas sin sacrificar drásticamente la calidad o potencial de estas soluciones, teniendo claro que la rapidez de captura, funcionalidad espacial y consistencia en datos tienen mayor o menor beneficio según los objetivos que se tengan a corto y mediano plazo.

Particularmente, se evidencia que para volúmenes grandes de datos geográficos se crean cuellos de botella en PostreSQL-PostGIS. La principal causa es la necesidad que tiene este almacén de transcribir cada consulta para poder ser ejecutada, y cada consulta compleja requiere además de un nivel de ejecución aún más complejo, lo que constituye un punto de entrada en común, que ante muchas peticiones puede saturar el sistema de alojamiento. A nivel de interoperabilidad las pruebas de funcionamiento de las solicitudes de WMS y WFS mediante un almacén de datos NoSQL y Relacional demostraron que funcionan satisfactoriamente.

Los servicios web geoespaciales posibilitan la integración de sistemas informáticos desplegados en plataformas incompatibles y la manipulación de estructuras de datos espaciales de diferentes formatos. Por lo tanto, fue posible migrar desde aplicaciones de escritorio y aplicaciones web propietarias a sistemas abiertos que proporcionan servicios de geoprocesamiento y producción de geoinformación bajo demanda.

Agregando a lo anterior, el uso de un intermediario (Geoserver) fue clave al momento de realizar procesos de comunicación a través de servicios geoespaciales, dicho intermediario tiene la capacidad de administración de Victoria Urresti, José Miguel

almacenes de manera asistida, posibilitando la interoperabilidad entre los dos tipos bases de datos espaciales de manera sencilla y transparente. Según la exploración de dicha tecnología se pueden esperar mejoras a futuro dado la cantidad de patrocinadores, desarrolladores y usuarios que cobijan a esta tecnología Open Source.

Con respecto a las capacidades de escalabilidad de computación en la nube, este método puede proporcionar servicios más eficientes y de bajo costo. La escalabilidad es muy beneficiosa para las compañías pequeñas y organizaciones de investigación o investigadores individuales que tiene recursos limitados, ya que ayuda a reducir los costos de hardware, y la configuración de los mismos, lo cual es a menudo una carga adicional para las actividades de investigación.

Se debe tener en cuenta que, las necesidades de gestión de la geoinformación dependerán del área científica y de investigación, para el caso de estudio de esta investigación se crearon consultas e interfaces para satisfacer ciertas necesidades específicas. Por lo tanto, para un experto involucrado en cualquier área que requiera funcionalidades SIG, es inevitable no especificar las necesidades de geoinformación y los geoprocesos relacionados que lo producen, para tener claridad que tipo de solución o procedimiento se adapta a sus requerimientos.

Finalmente, aunque los resultados se deben tener en cuenta para su análisis, como punto de partida para precisar limitaciones y alcances de un futuro proyecto, se debe ser cuidadoso en estar actualizado a la aparición de tecnologías geoespaciales o mejoras en las tecnologías implementadas en esta investigación, que expongan un panorama más amplio acerca de la rentabilidad de usar o no una arquitectura en la nube, o qué tipo de base de datos espacial se adapta de mejor a la lógica de negocio o investigación que se desea abordar.

Victoria Urresti, José Miguel

7. REFERENCIAS Acens Company (2014). Bases de Datos NoSQL. Qué Son y Tipos Que nos Podemos Encontrar, disponible en: https://www.acens.com/wpcontent/images/2014/02/bbdd-nosql-wp-acens.pdf [consultado 24 05 2016]. Amazon (2015). Tipos de instancias de Amazon EC2, Página oficial, disponible en https://aws.amazon.com/es/ec2/instance-types/ [consultado 15 02 2017]. Amazon

(2014).

What

Amazon

EC2?,

Página

oficial,

disponible:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html [consultado 14 03 2016]. Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I. (2010). A view of cloud computing. Commun, ACM, disponible en: http://cacm.acm.org/magazines/2010/4/81493-aview-of-cloud-computing/pdf [consultado 7 04 2016]. Baas, B. (2012). NoSQL spatial – Neo4j versus PostGIS, Universidad de Utrecht Facultad

Geociencias,

páginas

115, disponible

en:

http://www.gdmc.nl/publications/2012/Neo4j_versus_PostGIS.pdf [consultado 15 03 2016]. Ballatore, A., Tahir, A., McArdle, G., Bertolotto, M. (2009) A comparison of open source geospatial technologies for web mapping, International Journal of Web Engineering and Technology, Volumen 6 Issue 4, pp. 354-374, disponible en: http://eprints.maynoothuniversity.ie/2784/1/comparison_open_source_geospatial_t echnologies__Ballatore_Tahir_McArdle_Bertolotto_2011.pdfcomparison_open_source_geospat ial_technologies_-_Ballatore_Tahir_McArdle_Bertolotto_2011.pdf [consultado 0707 - 2017]. Bravo (2015). Availability versus Consistency, Deconstructing Big Data Adventures with NoSQL, Big Data and Data Science, disponible en: http://bigdatablog.com/availability-versus-consistency [consultado 13 - 03 - 2017]. Browne

(2009).

Brewer's

CAP

Theorem,

disponible

en:

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem [consultado 2302 - 2017]. Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., Schmidt, C. (2008). GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON), disponible en: http://geojson.org/geojson-spec.html#introduction Victoria Urresti, José Miguel

[consultado 20 02 2017]. Chee B.J., Franklin C. (2010). Cloud Computing: Technologies and Strategies of the

Ubiquitous

Data

Center.

CRC

Press,

disponible

en:

http://www.itfront.cn/attachment.aspx?attachmentid=999 [consultado 25 08 2017]. Cugler, D., Oliver, D., Evans, M., Shekhar, S., Medeiros, C. (2013). Spatial Big Data:

Platforms,

Analytics,

and

Science,

GeoJournal,

disponbile

en:

http://www.spatial.cs.umn.edu/geojournal/2013/geojournal.pdf [consultado 25 06 2017]. Dean, J. y Ghemawat, S. (2008). Mapreduce: simplified data processing on large clusters.

Communications

the

ACM,

disponible

en:

http://static.googleusercontent.com/media/research.google.com/es//archive/mapre duce-osdi04.pdf [consultado 24 02 2016]. Enciclopedia Británica (2014). Definition of database, Enciclopedia Britannica Inc. Disponible en: https://www.britannica.com/technology/database [consultado 07 03 2016]. Frenoy, R. (2013). Design and implementation of a NoSQL solution on a Software as a Service platform, Institutionen för datavetenskap Department of Computer and Information

Science,

disponible

en:

http://www.diva-

portal.org/smash/get/diva2:667511/FULLTEXT01.pdf [consultado 15 07 2016]. Furquet, C. (2016). Estudio Y Análisis De La Certificación Y Diseño De Un Sbas (Satellite Based Augmentation System) Para Aeropuertos/Heliódromos, (proyecto de fin De Grado, Universidad Politécnica de Valencia, España), presentación, disponible en: http://slideplayer.es/slide/11654087/ [consultado 14 02 2017]. García, D. A. (2008). Sistema GNSS (GLOBAL NAVIGATION SATELLITE SYSTEM), (Proyecto Fin de Carrera, Universidad Autónoma de Madrid, España), disponible: http://arantxa.ii.uam.es/~jms/pfcsteleco/lecturas/20080125DavidGarcia.pdf [consultado 23 02 2017]. García, O. (2012). SOA - Introducción a los Servicios Web, disponible en: http://www.elclubdelprogramador.com/2012/01/16/soa-introduccion-a-losservicios-web/ [consultado 02 05 2016]. Gonzalo, M. (2013). Los datos masivos (o Big Data) son el nuevo oro. El Diario, disponible

en:

http://www.eldiario.es/turing/Big-data_0_161334397.html

[consultado 20 03 2016]. Victoria Urresti, José Miguel

GSA (2016). What is GNSS?, disponible en: https://www.gsa.europa.eu/europeangnss/what-gnss, The European GNSS Agency, [consultado 01 02 2017]. Hesham, E. y Mostafa, A. (2005). Arquitectura avanzada de la computadora y procesamiento paralelo, John Wiley & hijo. ISBN 978-0-471-47839-3, disponible en: https://books.google.ee/books?id=7JBu6D5Q7kC&pg=PA63&dq=parallel+architectures+scalability&hl=et&sa=X&ei=bQZ tUtTKC6SO4gT27oC4Ag&ved=0CC4Q6AEwAA#v=onepage&q=parallel%20archit ectures%20scalability&f=false [consultado 01 02 2017]. Huang, Q., Yang, C., Benedict, K., Rezgui, A., Xie, J., Xia, J., Chen, S. (2013). Using adaptively coupled models and high-performance computing for enabling the computability of dust storm forecasting. Int. J. Geogr. Inf. Sci. 2013, 27, 765–784. Johnston,

(2014).

Archivo:

Cloud

computing-es.svg,

disponible

en:

https://es.wikipedia.org/wiki/Archivo:Cloud_computing-es.svg Kalan, M. (2014). An Enterprise Architect's View of MongoDB, disponible en:http://www.slideshare.net/mongodb/an-enterprise-architects-view-of-mongodb40882393 [consultado 01 06 2016]. KB's Data Scientist (2012). How is scalability achieved?, [Blog], disponible en: https://hadoop4usa.wordpress.com/2012/04/13/scale-out-up/ [consultado 30 05 2017]. Leafletjs (2016). Página Oficial del proyecto, Ejemplos Leafletjs, disponible en: http://leafletjs.com/examples/geojson/ [consultado 01 05 2016]. López, J. R. (2011). El modelo relacional, Licenciatura en Documentación: Bases de

datos

documentais,

Universidad

Cataluña,

disponible

en:

http://docencia.lbd.udc.es/bdd/teoria/tema2/2.3.1.-ElModeloRelacional.pdf [consultado 25 06 2017]. Mabrouck (s.f.). GIS Tools For Hadoop, internet y redes sociales, ESRI Inc., disponible en: http://www.esri.es/es/noticias/consigue-grandes-respuestas-graciasal-big-data--gis-tools-for-hadoop/. Maged, M., Moreira, J. E., Shiloach, D. y Wisniewski, R. W (2007). Scale-up x Scale-out: un estudio de caso utilizando Nutch / Lucene, Simposio Internacional de Procesamiento Simplificado IEEE 2003, disponible en: http://ieeexplore.ieee.org/document/4228359/?reload=true&arnumber=4228359 [consultado 01 02 2017]. McCarthy, C (2014). Does NoSQL have a place in GIS? - An open-source spatial Victoria Urresti, José Miguel

database performance comparison with proven RDBMS, The University of Edinburgh,

disponible

en:

https://www.era.lib.ed.ac.uk/handle/1842/10353?show=full

[consultado

2016]. McKee, L. (2014). OGC History (detailed). OGC. disponible en: http://www.opengeospatial.org/ogc/historylong [consultado 02 02 2016]. Mell, P. y Grance, T. (2011). The NIST Definition of Cloud Computing: Recommendations of the National Institute of Standards and Technology, NIST (National

Institute

Standards

and

Technology),

disponible

en:

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf [consultado 05 10 2016]. MongoDB (2015). Hashed Indexes, Documentación Oficial MongoDB, disponible en: https://docs.mongodb.com/v3.0/applications/geospatial-indexes/ [consultado 21 03 2017]. NGA (2004). Its Definition and Relationships with Local Geodetic Systems, National Geospatial-Intelligence Agency: NGA, disponible en: http://earthinfo.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf [consultado 13 09 2016]. NosoloSIG (2014). Información geográfica y Big Data, disponible en: http://www.nosolosig.com/articulos/275-informacion-geografica-y-big-data [consultado 21 03 2016]. OGC (2015). OGC Catalogue Service. OGC. disponible en: http://www.opengeospatial.org/standards/cat [consultado 02 02 2016]. Pérez, J. (2016). Oracle Cloud: Transformando los modelos de IT a "Database as a

Service

(DBaaS)",

Oracle

Corporation,

diponible

en:

http://www.oracle.com/technetwork/es/articles/cloudcomp/oracle-cloud-dbaas2877305-esa.html PostGIS (2014). Chapter 4. Using PostGIS: Data Management and Queries, disponible

en:

http://postgis.net/docs/manual-

2.1/using_postgis_dbmanagement.html#gist_indexes [consultado 15 05 2016]. Pritchett, D. (2008). Base: An acid alternative, ACMQueue, 6(3), 48-55. disponible en: http://queue.acm.org/detail.cfm?id=1394128 [consultado 03 02 2017] Quadro, F. (2016). You know the OGC standards?, [Blog], disponible en: https://www.linkedin.com/pulse/you-know-ogc-standards-fernando-quadro [consultado 20 10 2016]. Victoria Urresti, José Miguel

Ranjit, S., Nagai, M., Rittaporn, I., Ajjanapanya, T., Hilding, F., Witayangkurn, A., Shibasaki R. (2013). GPS Enabled Taxi Probe’s Big Data Processing for Traffic Evaluation of Bangkok Using Apache Hadoop Distributed System, disponible en: http://www.rsgis.ait.ac.th/rsweb_image/RSGIS_Photo_records/2014_Records/201 4-08/sarav_ATRANS/AYRF14-060.pdf [consultado 07 04 2016]. Reuter, A., y Härder, T. (1983). Principles of transaction-oriented database recovery,

Computing

Surveys,

disponible

en:

https://web.stanford.edu/class/cs340v/papers/recovery.pdf [consultado 09 02 2017] Rigaux, P., Scholl, M. Voisard, A., (2002). Spatial Databases with Application To GIS, 2nd ed. San Francisco: Morgan Kaufman, disponible en: http://goo.gl/3on3t2 [consultado 12 04 2016]. Rouse, M. (2015). NoSQL (No Solo SQL), disponible en: http://searchdatacenter.techtarget.com/es/definicion/NoSQL-No-Solo-SQL [consultado 24 05 2016]. Shadura, A. (2010). Relationship between clients/servers and OGC protocols, documentación Oficial Geoserver, disponible en:https://commons.wikimedia.org/wiki/File:GeoServer_GeoNetwork_with_web_ap p.svg [consultado 19 06 2017] Social Media Research Foundation (2012). Data mining: key to surveillance – and modern science…, disponible en: http://whyfiles.org/2013/mining-data/ [consultado 20 06 2016]. Snijders, C., Matzat, U. y Reips, U. D. (2012). Big Data: Big gaps of knowledge in the field of internet science International Journal of Internet Science Stallman (1992). Free Software Free Society: Selected Essays, GNU Press, páginas: 22-23. Strauch, C. (2013). NoSQL Databases, Stuttgart Media University, disponible en: http://www.christof-strauch.de/nosqldbs.pdf [consultado 1 04 2016]. Van der Meulen, R. (2015). Gartner Says Emerging Markets Drove Worldwide Smartphone Sales to 15.5 Percent Growth in Third Quarter of 2015, Inc Gartner, disponible en: http://www.gartner.com/newsroom/id/3169417 [consultado 05 04 2016] Vijayshree D. y Patil R. (2013). Web Service Application to Access Climate Data from Cloud using Spring Framework International Journal of Science and Research (IJSR),

Volumen

Victoria Urresti, José Miguel

septiembre2015,

disponible

en:

https://www.ijsr.net/archive/v4i9/SUB158069.pdf [consultado 25 03 2016]. Voorhis, D. (2015), Codd’s Twelve Rules, Department of Electronics, Computing & Mathematics,

University

Derby,

disponible

http://computing.derby.ac.uk/c/codds-twelve-rules/ [consultado 14 02 2016]. Widetech (2016). Widetech s.a.s | Tecnologías de geolocalización, rastreo satelital, monitoreo remoto e innovación móvil - Bogotá - Colombia, disponible en: www.widetech.co/es/ [consultado 04 11 2016]. Wikimedia Commons (2010). General Structure of a Relational Database, Wikimedia,

disponible

en:

https://commons.wikimedia.org/wiki/File:RDBMS_structure.png Wikimedia Commons (2009). Map Romance Latin America, Wikimedia, disponible en: https://commons.wikimedia.org/wiki/File:Map-Romance_Latin_America.svg

Victoria Urresti, José Miguel

APÉNDICE A. Instalación MongoDB en Amazon EC2 El procedimiento a continuación descrito es para la instalación de MongoDB en Amazon Linux desde paquetes. rpm y sólo es compatible con sistemas de 64 bits.

Paquetes: MongoDB tiene un repositorio oficial, dicho repositorio contiene los siguientes: • mongodb-org. Es un metapackage que instala automáticamente los siguientes paquetes. • mongodb-org-server. Este paquete contiene el mongod daemon y la configuración asociada init scripts. • mongodb-org-mongos. Este paquete contiene los mongos daemon. • mongodb-org-shell. Este paquete contiene el mongo shell. • mongodb-org-tools. Este paquete contiene las siguientes herramientas: mongoimport bsondump, mongodump, mongoexport, mongofiles, mongooplog, mongoperf, mongorestore, mongostat, mongotop.

Configuración del sistema de gestión de paquetes Crear el archivo /etc/yum.repos.d/mongodb-org-3.0.repo para instalar directamente MongoDB, usando yum. Vea lista de repositorios [mongodb-org-3.0] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodborg/3.0/x86_64/ gpgcheck=0 enabled=1

Instalación de paquetes de MongoDB y herramientas. Se debe especificar cada paquete de componentes de forma individual e indicar la versión al nombre del paquete: sudo yum install -y mongodb-org-3.0.13 mongodb-org-server-3.0.13 Victoria Urresti, José Miguel

mongodb-org-shell-3.0.13 mongodb-org-mongos-3.0.13 mongodb-orgtools-3.0.13

Para evitar actualizaciones no deseadas se debe anclar el paquete, para esto se debe incluir la directiva exclude al archivo /etc/yum.conf: exclude=mongodb-org,mongodb-org-server,mongodb-org-shell,mongodborg-mongos,mongodb-org-tools

Ejecución de MongoDB La instancia de MongoDB almacena sus archivos de datos por defecto en /var/lib/mongo y de registro en /var/log/mongodb, además, en la instalación crea por defecto cuenta de usuario llamada mongod. Iniciar MongoDB. Para iniciar el proceso de mongod46 se debe ejecutar el siguiente comando: sudo service mongod start

Verificar el inicio correcto de servicio MongoDB. Para verificar que el proceso de mongod se ha iniciado exitosamente se debe buscar en var/log/mongodb/mongod.log la siguiente línea [initandlisten] waiting for connections on port 27017

Detener MongoDB. Para detener el proceso mongod se debe ejecutar el siguiente comando: sudo service mongod stop

mongod; es el proceso daemon principal para MongoDB, se ocupa de las peticiones de datos, gestiona el acceso de datos y realiza operaciones de gestión de fondo Victoria Urresti, José Miguel

APÉNDICE B. Instalación PostgreSQL-PostGIS en Amazon EC2 El procedimiento a continuación descrito es para la instalación de PostgreSQL + PostGIS en Amazon Linux desde paquetes .rpm y sólo es compatible con sistemas de 64 bits. Inicia sesión para la instancia vie SSH, cambie a usuario root y no incluyen los paquetes de PostgreSQL por defecto de los repositorios de Amazon: sudo su nano /etc/yum.repos.d/amzn-main.repo

Agregar la siguiente línea al bloque [AMZN-main]: exclude=postgresql*

Luego se añade la misma línea para el repositorio de actualizaciones [AMZNupdates] nano /etc/yum.repos.d/amzn-updates.repo

A continuación, se instala PostgreSQL 9.3 cd ~/ wget http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/pgdgredhat93-9.3-1.noarch.rpm rpm -ivh pgdg-redhat93-9.3-1.noarch.rpm yum install postgresql93 postgresql93-server postgresql93-devel

Instalación Soporte PostGIS Geoespacial Para la instalación de PostGIS para PostgreSQL, previamente se instalaron las siguientes dependencias GEOS , Proj4 , JSON-C , GDAL. sudo yum install gcc make gcc-c++ libtool libxml2-devel libpng libtiff # cambio al directorio home

cd ~/ # descarga y instalación de GEOS

wget http://download.osgeo.org/geos/geos-3.4.2.tar.bz2 tar xjf geos-3.4.2.tar.bz2 cd geos-3.4.2 Victoria Urresti, José Miguel

./configure make make install # descarga y instalación de Proj.4

cd ~/ wget http://download.osgeo.org/proj/proj-4.8.0.tar.gz tar xzf proj-4.8.0.tar.gz cd proj-4.8.0 ./configure make make install # descarga y instalación de GDAL

cd ~/ wget http://download.osgeo.org/gdal/1.10.1/gdal-1.10.1.tar.gz tar -xvzf gdal-1.10.1.tar.gz cd gdal-1.10.1 ./configure make make install # descarga y instalación de libreria JSON-C

cd ~/ wget https://s3.amazonaws.com/json-c_releases/releases/json-c0.11.tar.gz tar -xvzf json-c-0.11.tar.gz cd json-c-0.11 ./configure make make install # descarga y instalación de PostGIS

cd ~/ wget http://download.osgeo.org/postgis/source/postgis-2.1.2.tar.gz tar -xvzf postgis-2.1.2.tar.gz cd postgis-2.1.2 ./configure --with-pgconfig=/usr/pgsql-9.3/bin/pg_config --withgeosconfig=/usr/local/bin/geos-config --withgdalconfig=/usr/local/bin/gdal-config make make install # actualización de librerias

echo /usr/local/lib >> /etc/ld.so.conf ldconfig

Finalmente se creó una base de datos plantilla con soporte espacial Postgis con los siguientes comandos: createdb -U postgres template_postgis createlang -U postgres plpgsql template_postgis psql -U postgres -d template_postgis < /usr/share/pgsql92/contrib/postgis-2.1/postgis.sql psql -U postgres -d template_postgis < /usr/share/pgsql92/contrib/postgis-2.1/spatial_ref_sys.sql

Victoria Urresti, José Miguel

APÉNDICE C. Instalación Geoserver y Apache en Amazon EC2 El procedimiento a continuación se realiza para la instalación de Geoserver en Amazon Linux y sólo es compatible con sistemas de 64 bits. Instalar Apache HTTP Server y Apache Tomcat con la siguiente línea de comando sudo yum install httpd httpd-devel tomcat6

Descargue el archivo Web de GeoServer y muévalo al directorio webapps de Tomcat. más información en instalación geoserver cd /home/ec2-user/ wget http://sourceforge.net/projects/geoserver/files/GeoServer/2.7.1/geo server-2.7.1-war.zip unzip geoserver-2.7.1-war.zip sudo chown tomcat:tomcat geoserver.war sudo mv geoserver.war /var/lib/tomcat6/webapps/

Instalar mod_jk Mod_jk es un módulo Apache para conectar un servidor Web Apache a Tomcat. Esto nos permite acceder a aplicaciones Web en Tomcat a través del servidor HTTP Apache a través del puerto 80. luego de instalar mod_jk se actualizó la configuración del Servidor HTTP Apache y se creó un archivo workers.properties para que Apache HTTP Server y Apache Tomcat puedan comunicarse vía mod_jk cd /home/ec2-user mkdir mod_jk cd mod_jk wget http://mirror.nexcess.net/apache/tomcat/tomcatconnectors/jk/tomcat-connectors-1.2.40-src.tar.gz tar xzf tomcatconnectors-1.2.40-src.tar.gz cd tomcat-connectors-1.2.40-src/native ./configure --with-apxs=/usr/sbin/apxs make sudo make install

Configurar de servidor HTTP de Apache sudo vim /etc/httpd/conf/httpd.conf

Insertar en archivo httpd.conf las siguientes líneas: # Load mod_jk module # Update this path to match your modules location LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so # Where to find workers.properties # Update this path to match your conf directory location (put workers.properties next to httpd.conf) JkWorkersFile /etc/httpd/conf/workers.properties # Where to put jk shared memory # Update this path to match your local state directory Victoria Urresti, José Miguel

or logs directory JkShmFile /var/log/httpd/mod_jk.shm # Where to put jk logs # Update this path to match your logs directory location (put mod_jk.log next to access_log) JkLogFile /var/log/httpd/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the timestamp log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # Send everything for context /geoserver and /geoserver/* to worker named geoserver_worker (ajp13) JkMount /geoserver/* geoserver_worker JkMount /geoserver geoserver_worker

Creación de worker.properties sudo vim /etc/httpd/conf/workers.properties

insertar en archivo worker.properties las siguientes lineas: # Define the list of workers that will be used worker.list=geoserver_worker # Define geoserver_worker worker.geoserver_worker.port=8009 worker.geoserver_worker.host=localhost worker.geoserver_worker.type=ajp13

Iniciar Apache HTTP Server y Apache Tomcat Para este paso todo está instalado y configurado queda iniciar Apache HTTP Server y Apache Tomcat con el siguiente comando: sudo /sbin/service httpd start sudo /sbin/service tomcat6 start

Verificación de servicios. Con un navegador Web en la barra de búsqueda indique la dirección IP y luego teclee enter, Debería ver una página de bienvenida de Apache. Con un navegador Web en la barra de búsqueda indique la dirección IP / geoserver y luego teclee enter. debería ver la página de administración de GeoServer.

Victoria Urresti, José Miguel

APÉNDICE D. Instalación soporte de MongoDB en Servidor Geoserver Procedimiento de instalación: ● Descargar el complemento desde siguiente repositorio https://github.com/spidasoftware/mongodb-geoserver

Figura 20. Listado de repositorio de complemento Mongo-Geoserver

● Se mueve el comprimido groovy.jar que lo compone el Driver java de mongo y el mongodb-geoserver jar a la siguiente ruta /WEB-INF/lib ● A continuación, se reinicia el servicio de Geoserver para capacitar al servicio almacenes de datos desde MongoDB.

Figura 21. Componente de MongoDB habilitado en Geoserver

Victoria Urresti, José Miguel

APÉNDICE E. Estructura de los datos Este apéndice proporciona información sobre la estructura de datos usados en la investigación, los atributos alfanuméricos y geográficos fueron almacenados de forma idéntica tanto en la tecnología NoSQL como RDBMS.

1. space.cppoints: puntos de interés de cliente 2. space.cpzones: polígonos de interés cliente 3. space.intersections: puntos que describen información de nomenclatura vial a 20% y 80% de longitud de segmento/vértice para centro poblado o puntos de kilometrajes que describen cada kilómetro de tramo de vía entre centro poblados cada 200 m. 4. space.hist_gps, elementos provenientes de dispositivos GPS instalados en las flotas que administra la plataforma de rastreo. Tabla 6. Atributos de entidades Zonas y puntos de interés

Atributo

Tipo

Nulidad

Descripción

CpId

Integer

Identificar de la entidad geográfica

cpName

String

nombre que designó cliente al punto o polígono

cpWKT

String

Descripción de geometría en formato

cpType

Integer

clasificación de punto/polígono creada por Widetech

cpTypeGeom

Integer

Tipo de geometría

cpRadio

Integer

Radio de influencia de elemento en metros

cpUserId

Integer

Usuario al que pertenece el punto o polígono

cpDateTime

Timestamp

Fecha de creación de feature de interés

cpCodePostal

String

Código postal

cpStatus

Boolean

Estado del punto o polígono (activo /inactivo)

cpCity

String(100)

Ciudad a la cual pertenece la intersección de vía

cpAddress

String(500)

Dirección vial ejemplo: CL 70 # 9 - 87

cpIdOld

Integer

Identificador similar al descrito en MySQL

Victoria Urresti, José Miguel

100

Tabla 7. Atributos de entidad Intersecciones

Atributo

Tipo

Nulidad

Descripción

cpId

integer

Identificar de la entidad geográfica

cpAddress

String

Dirección vial ejemplo: CL 70 # 9

cpWKT

String

Descripción de geometría en formato

cpCity

String

Ciudad a la cual pertenece la intersección de vía

cpRegion

String

Región a la cual pertenece la intersección de la vía

cpCountry

String

País a la cual pertenece la intersección de la vía

Tabla 8. Atributos de entidad localizaciones GPS

Atributo

Tipo

Nulidad

Descripción

CpId

Integer

Identificar de la entidad IMEI

cpLatitude

Double

distancia angular entre la línea ecuatorial y el punto de localización del vehículo o persona

cpLongitude

Double

distancia angular entre el meridiano que se tome como 0° y el punto de localización del vehículo o persona

cpDateTime

Long

Fecha de captura GPS en UNIX

cpVelocity

Integer

Indica la velocidad de capturada por GPS para esa localización

cpName

String

Nombre de la localización

cpDirection

String

Dirección de movimiento o rumbo en la trayectoria del histórico GPS

Victoria Urresti, José Miguel

101

APÉNDICE F. Tareas de Depuración de datos Se identificó que existía un problema de duplicidad de los datos para la investigación y que manualmente era imposible cuantificar para el área de estudio (Latinoamérica) Los datos en bruto sin ninguna depuración implicaban a nivel de base de datos, redundancia de datos, aumento de cuota de almacenamiento y aumento en los tiempos de consulta lo cual podría interferir y producir interpretaciones erróneas en los resultados de rendimientos, por dicho motivo se procedió a realizar una depuración a nivel de base de datos: Se optó por agrupar las geometrías idénticas asumiendo el campo geom como un campo string. El query implementado fue el siguiente: --Create table puntos sin duplicación CREATE TABLE space.intersectionscleansed ( id serial NOT NULL, geom geometry(Point,4326), "NAME" character varying(155), CONSTRAINT intersectionsduplicate_pkey PRIMARY KEY (id) ) WITH (OIDS=FALSE);

---- only keep one point from duplicates INSERT INTO space.intersectionscleansed(geom, "NAME") SELECT geom, MAX("NAME") AS Cant FROM space.intersections GROUP BY geom HAVING COUNT(*) > 1;

-- obtener solo puntos uniques INSERT INTO space.intersectionscleansed(geom, "NAME") SELECT geom, MAX("NAME") AS Cant FROM space.intersections GROUP BY geom HAVING COUNT(*) =1;

Victoria Urresti, José Miguel

102

Creación de Campo Geométrica El campo "cpGeom" es el campo geométrico que reconoce la entidad en base de datos en forma geométrica, sistema de coordenadas geográfico y topología. "cpGeom" en la entidad space.cpzones se actualizo a partir del campo "cpWKT" de la siguiente manera: UPDATE space.cpzones SET "cpGeom" = ST_GeometryFromText("cpWKT", 4326) WHERE "cpTypeGeom" = 3 AND "cpWKT" IS NOT NULL AND length(regexp_replace("cpWKT", '[^,]+', '', 'g')) > 2;

Se debió controlar que el string en "cpWKT" fuera un array de coordenadas ya que según se pudo verificar existían esa inconsistencia desde la base datos MySQL origen. Con respecto a space.cppoints la actualización del "cpGeom" se realizó teniendo las siguientes consideraciones, sólo se actualizaron las coordenadas validadas para el sistema de referencia geográfico EPSG: 4326, para ello se crearon dos columnas lat y lon para realizar una validación correcta de la siguiente manera: ALTER TABLE space.cppoints ADD COLUMN lon DOUBLE PRECISION; ALTER TABLE space.cppoints ADD COLUMN lat DOUBLE PRECISION; UPDATE space.cppoints SET lon= r.lg, lat= r.lt FROM ( SELECT replace(a[1],'POINT(','')::double precision lg, replace(a[2],')','')::double precision lt, "cpId" id FROM ( SELECT regexp_split_to_array("cpWKT", ' '), "cpId" FROM space.cppoints ) as dt(a)) r WHERE r.id = space.cppoints."cpId";

Victoria Urresti, José Miguel

103

APÉNDICE G. Demostración de WFS Transaccional Este la siguiente petición muestra tipo de feature solicitado dentro del almacén de datos llamado Colombia capa editiondata http://192.168.10.87:8080/geoserver/wfs?service=wfs&version=1.1.0&request=De scribeFeatureType&typename=Colombia:editiondata <xsd:schema xmlns:Colombia="http://www.colombia.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://www.colombia.com/"> <xsd:import namespace="http://www.opengis.net/gml" schemaLocation="http://192.168.10.87:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd"/> <xsd:complexType name="editiondataType"> <xsd:complexContent> <xsd:extension base="gml:AbstractFeatureType">

El documento descriptor XML WFS-T construido para proceso de edición de datos El servidor responde con siguiente documento de capabilities: <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="0" name="type" nillable="true" type="xsd:int"/> <xsd:element maxOccurs="1" minOccurs="0" name="label" nillable="true" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="0" name="geom" nillable="true" type="gml:GeometryPropertyType"/> <xsd:element maxOccurs="1" minOccurs="0" name="fecha" nillable="true" type="xsd:dateTime"/> <xsd:element maxOccurs="1" minOccurs="0" name="digitizer" nillable="true" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="1" name="revisado" nillable="false" type="xsd:boolean"/> <xsd:element maxOccurs="1" minOccurs="0" name="roadid" nillable="true" type="xsd:int"/> <xsd:element maxOccurs="1" minOccurs="0" name="idarea" nillable="true" type="xsd:int"/> <xsd:element maxOccurs="1" minOccurs="0" name="oneway" nillable="true" type="xsd:boolean"/> <xsd:element maxOccurs="1" minOccurs="0" name="cat_road" nillable="true" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="0" name="type_geometry" nillable="true" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="0" name="color" nillable="true" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="0" name="postal" nillable="true" type="xsd:int"/> <xsd:element maxOccurs="1" minOccurs="0" name="name_geometry" nillable="true" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="0" name="fow" nillable="true" type="xsd:int"/> <xsd:element maxOccurs="1" minOccurs="0" name="fc" nillable="true" type="xsd:int"/> <xsd:element maxOccurs="1" minOccurs="0" name="postcode" nillable="true" Victoria Urresti, José Miguel

104

type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="editiondata" substitutionGroup="gml:_Feature" type="Colombia:editiondataType"/> </xsd:schema>

A continuación, se presenta el documento XML de petición de update WFS transaccional enviado por el cliente. <wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs" service="WFS" version="1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd http://www.colombia.com/ http://192.168.10.87:8080/geoserver/wfs/DescribeFeatureType?version=1.1.0&amp;;typen ame=Colombia:editiondata_test"> <wfs:Update typeName="feature:editiondata_test" xmlns:feature="http://www.colombia.com/"> <wfs:Property> <wfs:Name>geom</wfs:Name> <wfs:Value> <gml:LineString xmlns:gml="http://www.opengis.net/gml" srsName="EPSG:4326"> <gml:posList>-74.08834 4.641019999999979 -74.0888104662704 4.641448222633883</gml:posList> </gml:LineString> </wfs:Value> </wfs:Property> <wfs:Property> . </wfs:Property> <wfs:Property> . </wfs:Property> . <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc"> <ogc:FeatureId fid="editiondata_test.2600059" /> </ogc:Filter> </wfs:Update> </wfs:Transaction>

A continuación, se presenta el documento XML de respuesta WFS de transacción recibido por el cliente y enviado por el servidor <?xml version="1.0" encoding="UTF-8"?> <wfs:TransactionResponse xmlns:Colombia="http://www.colombia.com/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1.0" xsi:schemaLocation="http://www.opengis.net/wfs http://192.168.10.87:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd"> <wfs:TransactionSummary> <wfs:totalInserted>0</wfs:totalInserted> <wfs:totalUpdated>1</wfs:totalUpdated> <wfs:totalDeleted>0</wfs:totalDeleted> </wfs:TransactionSummary> Victoria Urresti, José Miguel

105

<wfs:TransactionResults /> <wfs:InsertResults> <wfs:Feature> <ogc:FeatureId fid="none" /> </wfs:Feature> </wfs:InsertResults> </wfs:TransactionResponse>

Victoria Urresti, JosĂŠ Miguel