DOCSLIB.ORG

Geospatial Artificial Intelligence

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Geospatial Artificial Intelligence Geospatial Artificial Intelligence An introduction to pipelining for automated geospatial analysis, modelling and AI Simon D. Wenkel March 30, 2019 DRAFT 6 Selecting file formats Some of the biggest questions we have to ask ourselves when we start a geospatial project is what file formats do we want to use. There are many out there and some have their specific advantages for certain niches. GDAL/OGR [1] lists 96 vector formats and 155 raster formats. That is a lot to choose from. Comment 6.1 Utilizing normal files and databases for geospatial data In theory we could use any kind of file or database to store geospatial data as long as we know how we stored it and how the projection is linked to coordinates. Since the same coordinates will lead to different positions for different projections this can be dangerous and therefore is not recommended. However, we can see this often especially with text files and if they are not documented properly we end up with a big mess. 6.1 Databases vs. single files First, we have to decide on whether we want single files or a real database to store our data. The main challenge with geospatial data stored in single files is that we end up having multiple files that make a “single” file. If one of them is lost or not copied correctly we may are doomed if this is an essential one. The big advantage of using single files to store geospatial data is that if we manage to copy them correctly everyone can work with them without having deep knowledge on setting up databases. Moreover, we can to risky things such as editing them manually with non- geospatial tools. This is not recommended but there are some special applications for it. Another disadvantage of single files is that their size is limited by the file system of the device they are stored on. There are still many devices in use that are formatted with FAT32 (with LFS) which limits file sizes to 4 GB. We could use real databases to store our geospatial data. They have the advantage that it they are accessedDRAFT via centralized APIs and if set up correctly it is much easier to collaborate with other team members. Another big advantage of them is that they usually offer basic data operations on a database level which is usually more optimized for performance than our geospatial software tools. If we are working with Preview - ©Simon D. Wenkel (https://www.simonwenkel.com) - p. 27 6 Selecting file formats really big datasets and/or enjoying slow network connections we can save ourselves a lot of time to transfer the data to our workstation, perform our calculations and transfer them back to the server. However, setting them up correctly especially if for complex cases and in certain corporate environments can be challenging. Furthermore, it is difficult to exchange them with external people since they either have to be dumped and converted or have to been shipped as a snapshot or third parties require access to the api which can be challenging depending on company culture and security. Comment 6.2 Databases vs. single files Shipping functioning databases can be challenging especially if data sizes are really big. Databases such as POSTGIS offer the big advantage to perform calculations on a database level and therefore save a lot of time. Therefore, we should: • ship single files, if file sizes are reasonable • ship databases, otherwise. If we are working on smaller projects especially if we are the only ones involved we will safe time with single files in the short-term especially if we have never used databases before and safe a lot of time with databases in the long-term. 6.2 Single files If we decide to use single files as basis for our analyses then we encounter the most common: • Shapefile (Chapter 6.2.1) • Keyhole Markup Language [KML] (Chapter 6.2.2) • Geotiff (Chapter 6.2.3) • x,y,z textDRAFT files (Chapter 6.2.4) • Geopackage (Chapter 6.2.5) Preview - ©Simon D. Wenkel (https://www.simonwenkel.com) - p. 28 6.2 Single files Comment 6.3 Metadata security flaws In the field of GIS and more general data science cybersecurity is neglected often. In our case it is less about securing workstations and servers itself but the amount of information of our systems we publish/ship accidentally. Automatic generated metadata may not only contain useful data such as the process how analyses were done but absolute file paths and therefore a lot of information on our systems and workflow as well. This seems to be more common with desktop GIS and less in the way we are working here. Nevertheless, we should clean our metadata if we ship it to increase computer security. 6.2.1 Shapefile The shapefile format is developed by ESRI with the main purpose of exchanging vector features between ArcGIS and non-ArcGIS users. Therefore, it is compatible with a lot of software even CAD software packages. It can store only one feature type and one layer. As defined by the shapefile whitepaper [2], it requires the following files to work: .shp # stores feature geometry .shx # spatial index of feature geometries .dbf # dBase containing all attributes We will experience often that we have 7 files instead of 3. The other two files are commonly: .shp.xml # metadata in xml form .prj # text file containing the projection .qpj # additional projection information by QGIS .sbn/.sbx # spatial index of features to speed up spatial queries Depending on what software we are using we may end up with more files: .ain/.aih # attribute index of active fields .atx # attribute index for dBase file .cpg # specifies character encoding of the dBase file .fbn/.fbx # similarDRAFT to .sbn/.sbx for read-only features .ixs # geocoding index for shapefiles (read/write) .mxs # similar to .ixs but for ODB format .qix # quadtree spatial index Preview - ©Simon D. Wenkel (https://www.simonwenkel.com) - p. 29 6 Selecting file formats The main disadvantage of shapefiles is that we may end up with unusable data if one of the essential files is not included and perhaps the projection is missing. This happens far more often then it should. 6.2.2 Keyhole Markup Language (KML) When dealing with single file geospatial data we have to mention KML - the Keyhole Markup Language [3]. KML is famous because it is one of the few filetypes that are readable and writable by Google Earth. Therefore, it sometimes used to store GPS tracks instead of using the GPS Exchange Format (.gpx). There are two kinds of files of KML: .kml # keyhole markup language document .kmz # zipped keyhole markup language document 6.2.3 Geotiff The shapefile equivalent for raster data is Geotiff. The Geotiff file [4] is similar to a standard tiff image file however it extended a bit to store information on georefer- encing. Hence, we only need one file: .tif # georeferenced TIFF file containing the raster Nevertheless, there might be more files for a single raster. We may encounter MapInfo or ESRI world files that store information on georeferencing instead of embedding it directly. Further, we may have our xml metadata files again: .aux.xml # PAM (Persistant Auxiliar Metadata) .ovr # storing pyramid layers of the raster .tab # MapInfo file .tif.xml # contains metadata .twf/.tifw/.tiffw/.wld # ESRI world file 6.2.4 x,y,z text files We can think of x,y,z text files as csv files (comma separated values) that look a bit like this: 0,0,0,'Amsterdam',123,'foo' ... Without specialDRAFT (manual) processing it can only be used for points and therefore they are often used to ship DEMs (Digital Elevation Models). The main problem is that they have to be accompanied by metadata to know which projection has to be assigned to it after importing. Preview - ©Simon D. Wenkel (https://www.simonwenkel.com) - p. 30 6.2 Single files 6.2.5 GeoPackage (GPKG) GeoPackage is a single file that can store multiple vector features and rasters. Accord- ing to the current specifications [5] it is a container for a SQLite database with some degree of similarity to SpatiaLite. However, unlike SpatiaLite it is a pure storage format and not a database that allows certain (optimized) operations on a database level. It is designed to store data and leaves the processing to other software. Comment 6.4 Geopackage is the default file format for QGIS 3 Geopackage is used as the default file format for QGIS 3 [6]. Let us hope that it will lead to wide spread usage of GeoPackage in times of “open data policies” in Europe. This could remove the battle with incomplete shapefiles and geotiffs. 6.2.6 GeoJSON GeoJSON [7] is the abbreviation of Geographic JavaScript Object Notation. It is an geospatial extension based on the JSON format and therefore aims at web applica- tions. It is a rather simple format that uses WGS 84 coordinates that are written as decimal degrees. It supports the following geometry types: • Point, MultiPoint • LineString, MultiLineString • Polygon, MultiPolygon Code 6.1 GeoJSON example This is the example from the GeoJSON homepage (http://geojson.org/). 1 { 2 "type": "Feature", 3 "geometry":{ 4 "type": "Point"DRAFT, 5 "coordinates":[125.6, 10.1] 6 }, Preview - ©Simon D. Wenkel (https://www.simonwenkel.com) - p. 31 6 Selecting file formats 7 "properties":{ 8 "name": "Dinagat Islands" 9 } 10 } 6.3 Databases In terms of geospatial databases, we mainly run into SQL (Structured Query Lan- guage) databases meaning that we are dealing with relational databases. Relational databases were introduced by Codd [8] and have standardized termi- nology describing a “table”: • Row: tupel/record • Column: attribute/field • Table: relation One of the biggest advantages of real databases is the usage of native database tools to perform queries and some analyses directly on the database without transferring data from a database to our workstations and do the calculations there.
Load more

Recommended publications
  • Understanding and Working with the OGC Geopackage Keith Ryden Lance Shipman Introduction
    Understanding and Working with the OGC Geopackage Keith Ryden Lance Shipman Introduction - Introduction to Simple Features - What is the GeoPackage? - Esri Support - Looking ahead… Geographic Things 3 Why add spatial data to a database? • The premise: - People want to manage spatial data in association with their standard business data. - Spatial data is simply another “property” of a business object. • The approach: - Utilize the existing SQL data access model. - Define a simple geometry object. - Define well known representations for passing structured data between systems. - Define a simple metadata schema so applications can find the spatial data. - Integrate support for spatial data types with commercial RDBMS software. Simple Feature Model 10 area1 yellow Feature Table 11 area2 green 12 area3 Blue Feature 13 area4 red Geometry Feature Attribute • Feature Tables contain rows (features) sharing common properties (Feature Attributes). • Geometry is a Feature Attribute. Database Simple Feature access Query Connection model based on SQL Cursor Value Geometry Type 1 Type 2 Spatial Geometry (e.g. string) (e.g. number) Reference Data Access Point Line Area Simple Feature Geometry Geometry SpatialRefSys Point Curve Surface GeomCollection LineString Polygon MultiSurface MultiPoint MultiCurve Non-Instantiable Instantiable MultiPolygon MultiLineString Some of the Major Standards Involved • ISO 19125, Geographic Information - Simple feature access - Part 1: common architecture - Part 2: SQL Option • ISO 13249-3, Information technology — Database
    [Show full text]
  • "The Global Spatial Data Infrastructure Association - Advancing a Location Enabled World"
    GSDI and IGS Newsletter, Vol. 4, No. 2 News from the GSDI Association and the International Geospatial Society Vol. 4, No. 2, 2014 "The Global Spatial Data Infrastructure Association - Advancing a Location Enabled World" ASSOCIATION NEWS Association since 2010. Within local conservation circles he was primarily known for co-directing, with his partner GSDI Association Board Member Mark Becker Dies of 30 years Lori Charkey, the Bergen Save the Watershed in Tragic Accident Action Network (Bergen SWAN).” The GSDI Association learned of the tragic death of CIESIN Associate Director Mark Becker at the age of 53, on 26 February 2014 in a multi-vehicle accident on the New York State Thruway in Woodbury, NY. Mark was the GSDI Board member representing ‘GSDI Related Global Initiatives’ and was a valued member of the GSDI Outreach and Membership Committee, where his input and insight will be much missed by his colleagues at the Association. Below is an extract from the tribute to Mark from CIESIN. “In his 15 years at CIESIN Mark made contributions that will be felt for a long time. He began his CIESIN career in Mark Becker leading a teacher training workshop for the February 1999, and was soon appointed head of the CHANGE Viewer mapping tool. Pictured behind him is Geospatial Applications Division. … In many ways he Amy Work, IAGT, who helped develop the tool. Palisades, helped bring GIS to Columbia, as manager of the GIS New York, July 2013. Source: CEISIN Service Center and ESRI site license. He helped install many of the early GIS labs on campus and helped train See the full tribute to Mark on the CIESIN website at many of the people who operated them.
    [Show full text]
  • MASTERARBEIT Archiving Digital Maps with Geopackage and Vector
    MASTERARBEIT Archiving Digital Maps with GeoPackage and Vector-tile Dissemination Ausgeführt am Department für Geodäsie und Geoinformation der Technischen Universität Wien unter der Anleitung von Univ.Prof. Mag.rer.nat. Dr.rer.nat. Georg Gartner, TU Wien und Dipl.-Ing. Dr. Markus Jobst, Bundesamt für Eich- und Vermessungswesen Dr.-Ing. Christian Murphy, TU München durch Yunnan Chen Schulwinkel 4, Stuttgart 28.03.2019 Unterschrift (Student) i MASTER’S THESIS Archiving Digital Maps with GeoPackage and Vector-tile Dissemination Conducted at the Department of Geodesy and Geoinformation Technical University Vienna Under the supervision of Univ.Prof. Mag.rer.nat. Dr.rer.nat. Georg Gartner, TU Vienna and Dipl.-Ing. Dr. Markus Jobst, Federal Office of Metrology and Surveying Dr.-Ing. Christian Murphy, TU Munich by Yunnan Chen Schulwinkel 4, Stuttgart 28.03.2019 Signature (Student) ii Statement of Authorship Herewith I declare that I am the sole author of the submitted Master’s thesis entitled: “Archiving Digital Maps with GeoPackage and Vector-tile Dissemination” I have fully referenced the ideas and work of others, whether published or unpublished. Literal or analogous citations are clearly marked as such. Vienna, 28.03.2019 Yunnan Chen iii Acknowledgements The last two years in the International Cartography M.Sc. programme have been such a special journey. This master’s thesis could not be accomplished without the supports of many people. First, I would like to express my sincere gratitude and appreciation to my first supervisor and the deputy head of Information Management Department at Austrian Federal Office for Metrology and Surveying, Dr. Markus Jobst, who has been providing marvelous guidance, ideas, support, and suggestions in the last few months.
    [Show full text]
  • OGC Environmental Data Standards for Monitoring and Mapping
    OGC Environmental Data Standards for Monitoring and Mapping LANDCARE RESEARCH – Alistair Ritchie Research Data Architect/Engineer | Informatics Team MANAAKI WHENUA 2 P A G E INTRODUCTION • What is the OGC and WSMA*? • Earth science (and Agriculture) Working Groups • When one bureaucracy isn’t enough – the OGC and ISO and W3C • Overview by example – OGC Soil Data Interoperability Experiment LANDCARE RESEARCH – • Coming soon – a peak over the horizon • Why participation is valuable for New Zealand MANAAKI WHENUA * Why So Many Acronyms A p r i l 1 8 3 P A G E THE OPEN GEOSPATIAL CONSORTIUM (OGC) • ‘The Open Geospatial Consortium (OGC) is an international industry consortium of over 529 companies, government agencies and universities participating in a consensus process to develop publicly available interface standards.’ From: http://www.opengeospatial.org/ogc • New Zealand members: LANDCARE RESEARCH – − Hawkes Bay RC, Horizons RC, Land Information NZ, Manaaki Whenua, Ministry for the Environment, NIWA • Consensus driven specification of standards for: − the behaviour and implementation of data services (interoperable communication protocols) − data formats (geography mark-up language; GeoPackage) MANAAKI WHENUA − the structure of data describing real world things (hydrological features, observation and sampling data, aviation data …) − best practices for applying and using standards − policies and tools for testing and endorsing compliance with the standards • Standardisation by innovation and doing − heavy emphasis on large scale Testbeds
    [Show full text]
  • Open Geospatial Consortium (OGC)
    ® OGC activities for UAS ANSI UAS Standardization Collaborative Meeting George Percivall CTO, Chief Engineer Open Geospatial Consortium Copyright © 2017 Open Geospatial Consortium The Open Geospatial Consortium Not-for-profit, international voluntary consensus standards organization; leading open innovation for geospatial data • Founded in 1994 • 525+ member organizations • 100 innovation initiatives • 48 Open Standards • 230 OGC certified products • Thousands of implementations • Enabling access to 100K+ datasets ® OGC Copyright © 2017 Open Geospatial Consortium NASA and US Forest Service UAS • Ikhana UAV with multispectral sensor • Fire intelligence to management teams • Web access to geospatial processing via open standards ® Source: Ambrosia, G., Sullivan, D., Buechel, S., GSA Special Paper 482 , 2011 OGC Copyright © 2017 Open Geospatial Consortium DHS - Incident Management Information Sharing (IMIS) IoT Pilot Drone Operator Display OGC Standards Used in IMIS IoT Pilot • Sensor Observation Service • Sensor Planning Service • SensorThings • Web Processing Service • Catalog • OWS Context • Web Feature Service • Web Map Service Live demonstrations in multiple sites in 2016 ® https://www.dhs.gov/publication/incident-management-information-sharing-imis-internet-things-iot-extension-engineering OGC Copyright © 2017 Open Geospatial Consortium OGC Sensor Web Enablement Standards SWE Standards for Discovery and Tasking Sensors; Access and Process Observations • Sensor Model Language (SensorML) • Observations & Measurements (O&M) • Sensor Planning
    [Show full text]
  • October 2012 OGC TC Meetings 出國報告
    出國報告（出國類別：其他） October 2012 OGC TC Meetings 出國報告 出國人員：莊國煜、葉采芳 派赴國家：Korea/Souel 出國期間：101 年 10 月 06 日至 101 年 10 月 10 日(莊國煜)/ 101 年 10 月 13 日(葉采芳) 報告日期：101 年 11 月 09 日 摘 要 在 October 2012 OGC TC Meetings 標準會議在南韓首爾召開，會議從 10 月 07 日開 始，於 10 月 12 日結束，與會人數約兩百多人，包含各國的政府單位、民間企業公 司、非營利組織及大學等各類代表；我方將派遣兩位人員參與會議，分別為莊國煜和 葉采芳。主要任務主持 Open GeoSMS SWG，了解 OGC SWE DWG、KML2.3 SWC 、SensorML SWG 標準制定之進度及狀態，並參與 SWE for IoT SWG、Business Value Committee 與 Mass Market DWG 等相關會議。 技術貢獻： 本次會議完成 2 人次出席會議(出國報告 1 份)，規畫人才培育 2 人。 會議解說： OGC 定期的會員大會，每年有四次，分別於三、六、九、十二月舉行。會員大會又 分為 Technical Committee Meeting 和 Planning Committee Meeting 兩類，本計畫將參加 針對技術部分的 Technical Committee Meeting 類，其中 Technical Committee Meeting 包含 Standard Working Groups (SWG) 與 Domain Working Groups (DWG)兩大類型會 議，SWG 會議主要針對特定標準進行主題與文件討論，而 DWG 會議多偏向針對主 題性應用之討論與分享。我方除了參與 SWE 相關之 SWG 會議外，亦參與討論並分 享於 SWE 或 Open GeoSMS 實作經驗或應用概念。此次派出兩位成員出席，其能充 分掌握 OGC SWE 與標準認證相關標準發展狀況與已實作應用情境，並推廣與分享 Open GeoSMS 於商業化應用與急難救助團體合作情形。 1 與會成員與工作分配 成 員 任 務 參與 KML 標準制訂及與相關組織討論標準制訂議題 主持 Open GeoSMS SWG 更新標準文件進度及討論議題 莊 國 煜 於 Asian Forum 分享整合式救災平台方案 (880771) 瞭解 Mass Market 相關組織發表標準應用於實際情境及經實際應用提 出建立標準的需求。 瞭解 Business Value Committee 相關組織發表討論議題及標準應用 參與並瞭解 SWE 的標準制訂進度及與相關組織討論標準制訂議題 葉 采 芳 主持 Open GeoSMS SWG 更新標準文件進度及討論議題 (A00011) 於 EDM DWG 及 Mass Market DWG 分享整合式救災平台方案 瞭解 SWE for IoT SWG 相關組織發表討論議題及標準應用 2 目錄 摘 要..............................................................1 一、 會議名稱......................................................4 二、 參加會議目的及效益............................................4 三、 會議時間......................................................4
    [Show full text]
  • SSI - Bulk Data Transfer (GML Streaming)
    Open Geospatial Consortium Approval Date: 2013-01-18 Posted Date: 2012-12-07 Publication Date: 2013-03-26 Reference number of this document: OGC 12-097 OGC URI: http://www.opengis.net/def/doc-type/per/OWS-9-bulk-data-transfer-gml Category: Public Engineering Report Editor(s): Jeff Harrison OGC® OWS-9 Engineering Report - SSI - Bulk Data Transfer (GML Streaming) Copyright © 2013 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/legal/. Warning This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. ® Document type: OGC Engineering Report Document subtype: NA Document stage: Approved for public release Document language: English i OGC 12-097 Abstract This document provides a description of the Bulk Data Transfer investigations related to Geography Markup Language (GML) streaming and feature data transportation implemented in the OGC OWS-9 test bed. This document extends the concept of Bulk Data Transfer to the dissemination of large payloads consisting of geospatial data sets and/or collections of data sets between machines that are connected via a network. This document also describes the delivery of large payloads consisting of geospatial data sets and/or collections of data sets to SpatiaLite/SQLite to store the data for use by mobile applications.
    [Show full text]
  • Introduction to Open Geospatial Standards
    ® Introduction to open geospatial standards Steven Ramage, SASNet Fellow, Advisory Committee UBDC [Urban Big Data Centre, University of Glasgow] OGC Global Advisory Council [Open Geospatial Consortium] 20 September 2016 Glasgow, Scotland Agenda Part I 1. The challenges of interoperability 2. Business value of open standards Part II 3. Technical approach for implementing standards 4. The open standards global community Part III 5. Standards policy and industry resources 6. Participate in the standards process Standards are like parachutes: they work best when they're open. Mary McRae, OASIS What is the OGC? Confluence of policy, technology, legal and governance issues underpinning interoperability. Open geospatial standards development and more… Copyright © 2012 Open Geospatial Consortium OGC Standards • Technical documents that detail interfaces or encodings; • Software developers use these documents to build open interfaces and encodings into their products and services; • These standards are the main "products" of the OGC and have been developed by OGC members to address specific interoperability challenges. Copyright © 2016 Open Geospatial Consortium The Open Geospatial Consortium Not-for-profit, international voluntary consensus standards organisation leading development of open geospatial standards Middle South Africa East America 1% 6% 1% Founded in 1994 500+ industry, government, academic, Asia Europe research and NGO members worldwide Pacific 39% 17% Social and technical forum to align interests N. in standards and best practices
    [Show full text]
  • Esri Support for Open Geospatial Standards
    April 2020 ArcGIS Is Open Esri Support for Open Geospatial Standards Copyright © 2020 Esri All rights reserved. Printed in the United States of America. The information contained in this document is the exclusive property of Esri. This work is protected under United States copyright law and other international copyright treaties and conventions. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system, except as expressly permitted in writing by Esri. All requests should be sent to Attention: Contracts and Legal Services Manager, Esri, 380 New York Street, Redlands, CA 92373-8100 USA. The information contained in this document is subject to change without notice. Esri, the Esri globe logo, The Science of Where, ArcGIS, ArcIMS, ArcMap, Geoportal, Spatial Database Engine, SDE, ArcWeb, ArcSDE, ArcExplorer, esri.com, and @esri.com are trademarks, service marks, or registered marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products or services mentioned herein may be trademarks, service marks, or registered marks of their respective mark owners. Esri Support for Open Geospatial Standards Table of Contents Executive Summary ..................................................................................... 4 How Esri Keeps ArcGIS Open and Interoperable ...................................... 4 Support for OGC .........................................................................................
    [Show full text]
  • Geopackage Data Format for Collaborative Mapping of Geospatial Data in Limited Network Environments
    The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W1, 2016 International Conference on Geomatic and Geospatial Technology (GGT) 2016, 3–5 October 2016, Kuala Lumpur, Malaysia GEOPACKAGE DATA FORMAT FOR COLLABORATIVE MAPPING OF GEOSPATIAL DATA IN LIMITED NETWORK ENVIRONMENTS M. H. Rashidan, I. A. Musliman , A. A. Rahman Department of Geoinformation, Faculty of Geoinformation and Real Estate, Universiti Teknologi Malaysia, 81310, Johor, Malaysia - (ivinamri, alias)@utm.my KEY WORDS: Collaborative Mapping, GeoPackage, Mobile GIS, Field Data Collector ABSTRACT: With the growth of technology in earth and space science informatics has led to the revolution in a wide range of geospatial practice. Nowadays collaborative mapping has become a new hot spot, following mobile and web GIS. This paper explores the potential use of GeoPackage for collaborative mapping of geospatial data in limited network environments. GeoPackage is a data format that open-standard, platform-independent, portable, and self-describing. This paper focus on the implementation of GeoPackage in mobile application for field data collection. A mobile application was developed that implements the GeoPackage data format as an internal database to provide support for offline mapping. The developed mobile application demonstrates that vector and raster data can be stored in a single data format, which reduces the device storage consumption. The details of how GeoPackage data contribute to mobile GIS to achieve collaborative mapping in limited network environments are discussed. The findings show that the GeoPackage data format has great potential to improve existing mobile GIS applications. 1. INTRODUCTION Many mobile GIS (proprietary or open source) were developed by large group of companies and non-profit agencies offer mobile 1.1 Collaborative Mapping applications which support for outdoor mapping works.
    [Show full text]
  • OGC Testbed-17 Call for Participation (CFP)
    OGC Testbed-17 Call for Participation (CFP) Version 1.20 - 22 March 2021 Table of Contents 1. Introduction. 2 1.1. Background . 2 1.2. OGC Innovation Program Initiative . 2 1.3. Benefits of Participation . 2 1.4. Master Schedule . 3 2. Technical Architecture . 4 2.1. Sensor Integration . 5 2.2. Moving Features from Digital Motion Imagery. 7 2.3. Web API for Aviation . 11 2.4. Data Centric Security Across OGC APIs and Federated Clouds . 16 2.5. Federated Cloud Analytics . 20 2.6. Model Driven Standards . 22 2.7. COG & Zarr: Specification & Evaluation . 25 2.8. Attracting Developers: Lowering the entry hurdle for OGC Web API experiments. 28 2.9. OGC Features and Geometries JSON . 34 2.10. Geo Data Cubes . 38 2.11. Compliance Interoperability & Testing Evaluation (CITE) . 44 3. Deliverables Summary . 47 4. Miscellaneous . 52 Appendix A: Testbed Organization and Execution. 54 A.1. Initiative Policies and Procedures . 54 A.2. Initiative Roles . 54 A.3. Types of Deliverables . 54 A.4. Proposal Evaluation . 56 A.5. Reporting . 57 Appendix B: Proposal Submission . 58 B.1. General Proposal Submission Guidelines. 58 B.2. Questions and Clarifications . 60 B.3. Proposal Submission Procedures . 60 B.4. Tips for New Bidders. 64 Appendix C: Abbreviations . 67 Appendix D: Corrigenda & Clarifications . 68 D.1. Corrigenda Table . 68 D.2. Clarifications Table . 68 D.3. End of Clarifications Table (convenience link). 77 1 Chapter 1. Introduction The Open Geospatial Consortium (OGC) is releasing this Call for Participation (CFP) to solicit proposals for the OGC Testbed-17. The Testbed-17 initiative will explore eleven tasks, including Application Programming Interface (API) development, Features and Geometries JSON, Aviation, CITE, Geo Data Cubes, Sensor Integration, Moving Features from motion imagery, Security, Federated Cloud Analytics, COG & Zarr, as well as Model Driven Standards.
    [Show full text]
  • OGC Innovations for NASA New Observing Strategy
    ® OGC Innovations for NASA New Observing Strategy George Percivall CTO, Chief Engineer Open Geospatial Consortium [email protected] ® OGC Copyright © 2020 Open Geospatial Consortium ® Using location, we connect people, communities, technology and decision making to create a sustainable future for us, our kids and future generations • By specializing in making location more Findable, Accessible, Interoperable and Reusable • Via a proven collaborative and agile process combining Comprehensive standards, innovation and partnerships global community- driven forward- looking expertise in Communities- Partnerships location Tech & Market & Alliances Domains Process for Standards & Innovation OGC® Millions of Geospatial Datasets on >200K Servers ® Web Map Service (WMS) OneGeology.Org Web Map Tile Service (WMTS) OpenIOOS.Org Web Feature Service (WFS) Web Coverage Service (WCS) KML, GML, GeoPackage GeoTIFF, NetCDF, HDF CityGML http://oos.soest.hawaii.edu/pacioos/voyager/news/2013/ DigitalGlobe Eurocontrol Emergency / Disaster Management Meteorology, Hydrology, Ocean Monitoring ® Aviation Flight Information / Safety OGC Source: GeoSeer spatial data search engine: https://geoseer.net ® SENSOR WEB ENABLEMENT OGC® Sensor Web Requirements ® • Quickly discover sensors and sensor data (secure or public) that can meet my needs – location, observables, quality, ability to task • Obtain sensor information in a standard encoding that is understandable by me and my software • Readily access sensor observations in a common manner, and in a form specific to
    [Show full text]