Explore chapters and articles related to this topic
Databases
Published in Ian Foster, Rayid Ghani, Ron S. Jarmin, Frauke Kreuter, Julia Lane, Big Data and Social Science, 2020
Spatial extensions have been developed for many relational databases, e.g., Oracle Spatial, DB2 Spatial, and SQL Server Spatial. We use the PostGIS extensions to the PostgreSQL relational database here. These extensions implement support for spatial data types such as point, line, and polygon, and operations such as st_within (returns true if one object is contained within another), st_dwithin (returns true if two objects are within a specified distance of each other), and st_distance (returns the distance between two objects). Thus, for example, given two tables with rows for schools and hospitals in Illinois (illinois_schools and illinois_hospitals, respectively; in each case, the column the_geom is a polygon for the object in question) and a third table with a single row representing the City of Chicago (chicago_citylimits), we can easily find the names of all schools within the Chicago city limits. select illinois_schools.name from illinois_schools, chicago_citylimits where st_within(illinois_schools.the_geom, chicago_citylimits.the_geom);
A Smart Point Cloud Infrastructure for intelligent environments
Published in Belén Riveiro, Roderik Lindenbergh, Laser Scanning, 2019
The decision support system is constructed over a point cloud DBMS which provides an interface for integrating, updating, and accessing 3D point clouds. In addition, a LOD data structure and indexing scheme are prepared for fast data access by hierarchically subdividing the spatial area or using existing indexes. It provides an access to every component as described in the conceptual model, permits topology featuring (Table 9.2) and allows various modules to be plugged, thus playing the role of a centralized KI module. In addition, point/objects attributes resulting from capture, analysis, simulation or processing stages can be stored. Efficient processing requires a certain data quality that can be ensured by applying knowledge-based filtering and registration methods to the input data. The module was implemented in the open-source PostgreSQL 9.6 DBMS, with the extensions PostGIS and Pgpointcloud activated.
Combination of GIS and SHM in Prognosis and Diagnosis of Bridges in Earthquake-Prone Locations
Published in Fadi Al-Turjman, Smart Grid in IoT-Enabled Spaces, 2020
Arman Malekloo, Ekin Ozer, Fadi Al-Turjman
The proposed SHM-GIS cloud-based system architecture is, therefore, presented in Figure 7.5. The sensory subsystem layer acts as the data acquisition where it collects the data from bridges. The collected information is then transferred to a server via a different form of communication standards such as Wi-Fi, Bluetooth, and cellular and later uploaded on the cloud. Due to the enormous size of the acquired data for any given time history chiefly in the extensive application of bridge monitoring, storage methods need investigation. The issue of big data and storage has led to the creation of different file structure format. Standard file formats for storing large amounts of data are (1) HDF4 (Hierarchical Data Format) and (2) netCDF5 (Network Common Data Format). However, due to the file structure of these formats, they are not ideal in cloud computing. Many alternatives with their strengths and weaknesses are present in Matthew Rocklin (2018) webpage. HDF5 (Hierarchical Data Format version 5) can be an ideal solution in this case for storing multi-dimensional data. Bridge information such as geometry and location, and network description such as highway information and traffic information are stored in an object-related database management system (ORDBMS). PostgreSQL, with the extension, PostGIS for handling spatial data, is the common database management system (DBMS) for SHM applications. PostgreSQL is an open-source DBMS that is well developed and intuitive. The relationship between the sensor data and the structural/network elements is also a one-to-many relation.
A Web-based geo-marketing decision support system for land selection: a case study of Tehran, Iran
Published in Annals of GIS, 2019
Morteza Omidipoor, Mohammadreza Jelokhani-Niaraki, Najmeh Neysani Samany
The GDSS involves the use of Free and Open Source Software (FOSS) technologies based on a client–server architecture to provide a scalable application where the source code is openly shared so that people are encouraged to use and change it and voluntarily improve the design of the land transaction system. The architecture of system consists of three main layers (tiers): data, application logic and presentation (see Figure 3). Data layer includes a Spatial Database Management System (SDBMS) to store the input data, including land parcels and associated attributes defined by sellers as well as criteria values computed by spatial analysis component. After the system requirements analysis, database schema was designed (see Figure 4). Different entities such as land, person, spatial reference, topology, urban facilities (e.g. park, hospital, school, metro line and station, street etc.) and their relations are considered in the schema. The PostGIS, a freely available and Open Geospatial Consortium (OGC) compliant spatial extension of PostgreSQL, was used as SDBMS in the decision support system (Kisilevich, Keim, and Rokach 2013). PostGIS provides the capabilities to store and retrieve spatial data and supports a large number of spatial queries in the database (Steiniger and Hunter 2013; Brovelli, Minghini, and Zamboni 2016). The database schema was employed as the logical model for creating the physical PostGIS-based SDBMS for GDSS.
Context-aware services based on spatio-temporal zoning and crowdsourcing
Published in Behaviour & Information Technology, 2018
Akhlaq Ahmad, Md. Abdur Rahman, Mohamed Ridza Wahiddin, Faizan Ur Rehman, Abdelmajid Khelil, Ahmed Lbath
PostgreSQL/PostGIS: We used open source software to implement a mashup of services such as users’ current location, old trajectory and POIs and stored them in the PostgreSQL database. To implement a navigation service or to find the nearest POIs, we extracted Open street map data of Saudi Arabia and stored them in the PostGIS database. The PostGIS database supports spatial queries on top of the PostgreSQL. Specifically, we used pgrouting to support the open source navigation service. For any enquiry by the user, the application server reads one’s location and executes a spatial query in the PostgreSQL database by providing the output at the user’s front-end interface.
CityGML goes mobile: application of large 3D CityGML models on smartphones
Published in International Journal of Digital Earth, 2019
Christoph Blut, Timothy Blut, Jörg Blankenbach
Nevertheless, SpatiaLite represents a strong solution for storing CityGML data. Just as Oracle Spatial and PostGIS, it is capable of utilizing spatial indices, which are crucial for fast querying of geometries in large database tables. The spatial index uses the SQLite R*Tree (Guttman 1984; Beckmann et al. 1990) algorithm which employs a tree-like approach in which geometries are represented by their minimum bounding rectangles. It allows attaching multiple databases to a single database connection, enabling them to operate as one. Using this feature, it has the following maximum capabilities (Table 1).