Evaluación del tiempo de respuesta de un geoservicio utilizando una base de datos híbrida y distribuida

Web mapping services provide information directly to users and other software programs that can consume and produce information. One of the main challenges this type of service presents is improving its performance. Therefore, in this research, a new geoservice integrated into GeoServer was developed, called GeoToroTur, with an OWS implementation of vector layers that consumes the information from a hybrid and distributed database that was implemented with PostgreSQL and MongoDB, making use of ToroDB for document replication. This geoservice was evaluated by executing geographic and descriptive attribute filter queries. Based on the results, we can conclude that the response time for GeoToroTur is shorter than that for Geoserver.Los servicios de cartografía Web proporcionan información directamente, no sólo a los usuarios, sino también a otros programas de software que pueden consumir y producir información. Uno de los principales retos que presentan este tipo de servicios es mejorar su rendimiento. Por ello, en esta investigación se desarrolló un nuevo geoservicio integrado a GeoServer, denominado GeoToroTur con una implementación OWS de capas vectoriales que consume la información de una base de datos híbrida y distribuida que fue implementada con PostgreSQL y MongoDB haciendo uso de ToroDB para la replicación de documentos. Este geoservicio fue evaluado mediante la ejecución de consultas geográficas y de filtro de atributos descriptivos. Los resultados obtenidos permiten concluir que el geoservicio GeoToroTur tiene un menor tiempo de respuesta que Geoserver

Implementation of a prototype web application development framework for a non-relational storage engine that allows the mapping of objects

El desarrollo de software bajo el paradigma de Programación Orientada a Objetos está confrontado por un modelo de almacenamiento de datos de tipo relacional ampliamente aceptado por la industria desde hace casi treinta años. Lo anterior, plantea dos escenarios diferentes para modelar la estructura de la información: para almacenarla (base de datos) y/o tenerla en memoria (objetos), lo que conlleva a que los desarrolladores de software traten de mitigar a través de conversiones entre tipos o utilizando herramientas intermedias como el mapeo de objetos relacional, lo cual traen ventajas y desventajas sobre el proceso de desarrollo, el rendimiento de las aplicaciones y la mantenibilidad. Con las consideraciones anteriores, se propuso desarrollar una implementación de software que permitiera almacenar los objetos de la aplicación bajo un motor de almacenamiento no relacional o NoSQL, para lo cual se selecciono MongoDB que gracias a su estructura dinámica de documentos basada en el formato JSON se adapto a las definiciones de los objetos. El formato de documentos (Json) utilizado por el motor de datos MongoDB permitió almacenar los objetos definidos por los usuarios del Framework de tal forma que en una sola entidad se tiene organizada toda información, y no se segmenta como en el modelo de datos relacional, se respeta la definición inicial del objeto modelado, a partir de esta premisa, consideramos que se debe generar en mejoras de rendimiento de acceso a los datos, ya que la información estará ubicada en una misma colección.Universitat Oberta de Catalunya UOCRESUMEN 10 INTRODUCCIÓN 14 1. REVISIÓN BIBLIOGRÁFICA O MARCO TEÓRICO 17 2. PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACIÓN 29 3. OBJETIVOS PLANTEADOS 34 4. MÉTODO DE INVESTIGACIÓN 35 5. RESULTADOS DE LA INVESTIGACIÓN 37 5.1. Actividades 37 5.4. Funcionamiento del Framework. 42 5.5. Diseño e implementación del Framework 42 5.5.1. Casos de Uso 44 5.5.3. Diagrama de Paquetes 48 5.5.5. Interfaz grafica de usuario 50 6. ANÁLISIS DE LA INFORMACIÓN 57 6.1. Herramientas de tipo mapeo objeto-relacional (ORM) 57 6.2. Conceptos de Bases de Datos NoSQL 61 6.3. Framework desarrollado 63 7. CONCLUSIONES 65 8. RECOMENDACIONES Y TRABAJOS FUTUROS 67 9. REFERENCIAS BIBLIOGRAFICAS 68MaestríaSoftware development under the Object-Oriented Programming paradigm is confronted by a relational-type data storage model widely accepted by the industry for almost thirty years. The above raises two different scenarios to model the structure of the information: to store it (database) and / or have it in memory (objects), which leads software developers to try to mitigate through conversions between types or using intermediate tools such as relational object mapping, which bring advantages and disadvantages to the development process, application performance and maintainability. With the above considerations, it was proposed to develop a software implementation that would allow the application's objects to be stored under a non-relational or NoSQL storage engine, for which MongoDB was selected that thanks to its dynamic document structure based on the JSON format I adapt to the definitions of the objects. The document format (Json) used by the MongoDB data engine allowed to store the objects defined by the Framework users in such a way that all information is organized in a single entity, and it is not segmented as in the relational data model, The initial definition of the modeled object is respected, based on this premise, we consider that it should be generated in performance improvements for data access, since the information will be located in the same collection.Modalidad Presencia

Interoperability between the StraboSpot graph database and GIS software– A Malpais Mesa Use Case

Geographic Information Systems (GIS) have been used by field geoscientists for decades to digitally collect data with several benefits: observations can be made in the field at a map independent scale while using multiple basemaps, the burdensome task of digitizing handwritten field notes and maps back in the office is eliminated, and the use of global positioning systems (GPS) has led to more precisely located observations. Despite the numerous advantages of using GIS in the field geosciences, the lack of agreement upon a standard schema for relational database management systems used in GIS along with new geospatial technologies and the popularization of mobile applications has led to the development of a novel geologic data management system, StraboSpot. StraboSpot consists of a mobile application available for Android and iOS devices for data collection and an online graph database for data storage, management, and sharing. The issue of schema creation has been solved with the development of a lexicon through contributions from the structural geology and tectonics, sedimentology, petrology, and microstructural communities and the utilization of a graph database for storage, which is schema-less by definition. Users of StraboSpot can collect, store, and share their geologic data, making it an all-in-one solution for geoscientists to publish their data using open source techniques. Data is stored in a users’ StraboSpot account which can hold multiple StraboSpot projects consisting of multiple datasets containing Spots. A Spot is a point, line, or polygon containing a set of observations over a user-defined spatial extent. The spatial extent of a Spot can be in real world coordinates (when set using maps or georeferenced aerial imagery), pixel coordinates (when set using a photo) or other systems as needed. Tags, “sticky-note”-like categories, can be used to conceptually group Spots. StraboSpot does not have the cartographic and analysis tools found in a GIS, so it became necessary to establish connections between StraboSpot and commonly-used GIS software, ArcGIS and QGIS. GIS connections – an ArcMap Add-In and QGIS Plug-In – have been designed and programmed which have download and upload capabilities with StraboSpot. Download or upload of a StraboSpot project and dataset occurs through deserialization/serialization and parsing of JSON (Java Script Object Notation) and GeoJSON transferred between the GIS and StraboSpot’s graph database via RESTful communications. I traveled to Malpais Mesa, Inyo County, CA in October 2016, accompanied by two other University of Kansas students working on StraboSpot, to beta test StraboSpot’s mobile app. Malpais Mesa was chosen due to the complexity of the area – it is situated in the Eastern California Shear Zone and the westernmost range of the Basin and Range province – which would adequately test for bugs in the mobile application and create robust StraboSpot data which I then used in the development of the GIS connections. Most importantly, it was an excellent location to compare the geoscientist’s workflow with the capabilities and structure/interface of StraboSpot. The interoperability between StraboSpot and the GIS connections provides users with a user-friendly and seamless method of downloading data collected in the field, performing various analyses such as running topology, and then uploading the “cleaned up” data for further use in StraboSpot. Geoscientists will also be able download all their StraboSpot data and create professional map products using the cartographic layout tools in GIS. The raw data behind those map products will be easily shared through StraboSpot leading to greater transparency, reproducibility, and reuse of geologic data

Banco de dados geográfico utilizando NoSQL Cassandra : estudo de caso em um sistema de informação geográfico com participação popular

Trabalho de Conclusão de Curso (graduação)—Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2016.O Sistema de Informação Geográfica é uma ferramenta muito importante em diversas áreas de pesquisa. Entretanto, junto com a atual plataforma que a Internet oferece, o volume de dados gerados por usuários comuns está cada vez maior e, com isso, vem a necessidade de novas soluções para o armazenamento de dados geográficos, estruturados e não estruturados de uma maneira mais eficiente, de tal forma que o usuário possa ter condições de participar voluntariamente das solicitações de uma determinada aplicação. Este trabalho propõe a utilização do banco de dados NoSQL Cassandra para armazenamento de dados geográficos e utilização em Sistema de Informação Geográfico com Participação Popular.The Geographic Information System is a tool very important in several research areas. However, together with the curent platform that the Internet offers, the amount of data that commun users generate are becoming bigger, then comes the need of new solutions to store geographical, unstructured and structured data in a more eficient way that allow users to voluntarily participate of a request for a given application. This work purpose the Cassandra database to store geographical data and usage in Public Participation Geographic Information System

GeoDrill : uso de SQL para integração de fontes de dados espaciais heterogêneas com ou sem esquema.

Com a evolução da web e dos sistemas de informação, as organizações têm obtido dados dos mais diversos formatos, estruturas e tipos, podendo-se destacar os espaciais. Devido aos dados apresentarem características distintas, estes acabam sendo mantidos em fontes de dados heterogêneas, sendo assim necessário investir cada vez mais em soluções que possam integrar e analisar estes dados de diferentes fontes. Algumas destas soluções conseguem analisar o componente espacial dos dados, no entanto, essa análise dos dados espaciais é limitada pelo tipo de dados ou funções espaciais suportadas. Neste trabalho, é abordado o problema da integração de dados espaciais de fontes de dados heterogêneas, com ou sem esquema, utilizando linguagem SQL. Este é um problema em aberto na área de integração de dados espaciais, pois as soluções existentes apresentam inúmeras limitações, a exemplo da linguagem de consulta utilizada, os meios para acesso a dados, as tecnologias que podem ser integradas, as funções disponibilizadas e os tipos de dados espaciais suportados. Visando solucionar esse problema, desenvolveu-se a solução GeoDrill, uma extensão do Apache Drill que dá suporte a todas as funções espaciais padronizadas pela OGC (Open Geospatial Consortium), através da linguagem SQL, podendo realizar consultas em dados com ou sem esquema. Para validar a capacidade de integração dos dados no GeoDrill, foi desenvolvido um experimento para analisar as funcionalidades e o desempenho do mesmo. A solução GeoDrill foi capaz de realizar a integração dos dados espaciais de fontes heterogêneas, apresentando-se como uma alternativa para a resolução de parte das limitações existentes na área.With the evolution of the web and information systems, organizations have obtained data of various formats, structures and types, specially the spatial one. Due to different characteristics presented in data, such data have been stored in heterogeneous data sources. Therefore, it is needed to increasingly invest in solutions that can integrate and analyze these data from different sources. Some of these solutions can analyze the spatial component of data; however, this analysis of spatial data is limited either by the data type or spatial functions supported. In this work, the problem of spatial data integration from heterogeneous data sources is addressed, either with or without using schemas, using SQL language. This is an open issue in the area of spatial data integration, since existing solutions present many limitations, such as the query language used, the ways to access data, the technologies that can be integrated, the available functions set and the spatial data types supported. Aiming at solving this problem, the GeoDrill solution was developed, which is an extension of the Apache Drill that supports all standard spatial functions provided by the OGC (Open Geospatial Consortium) through the SQL language. The GeoDrill can perform queries on data with or without schema. In order to validate the capacity of GeoDrill to integrate data, an experiment was conducted to analyze its functionalities and performance. The obtained results indicate the GeoDrill solution is able to integrate spatial data from heterogeneous data sources. Hence, it appears to be a suitable alternative for solving part of the existing limitations in this research field