Publication Date: 2017-05-12
Approval Date: 2017-01-26
Posted Date: 2016-11-16
Reference number of this document: OGC 16-029r1
Reference URL for this document: http://www.opengis.net/doc/PER/t12-A082
Category: Public Engineering Report
Editor: Jeff Yutzler
Title: Testbed-12 GeoPackage Routing and Symbology Engineering Report
Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
This document is an OGC Public Engineering Report created as a deliverable of an initiative from the OGC Innovation Program (formerly OGC Interoperability Program). It is not an OGC standard and 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. However, the discussions in this document could very well lead to the definition of an OGC Standard.
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Introduction
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Routing Requirements
- 6. Routing Solutions
- 7. Symbology Requirements
- 8. Symbology Solutions
- Appendix A: Static Feature Symbology Extension
- Appendix B: Dynamic Feature Symbology Extension
- Appendix C: Revision History
This OGC Engineering Report (ER) describes the results of experiments in OGC Testbed 12 designed to potentially enhance capabilities for symbology and routing  as extensions to the OGC GeoPackage standard. These experiments focused on 1.) methods for providing mounted and/or dismounted (off-road) routing within GeoPackage and 2.) mechanisms for providing user-defined map symbology for features in a GeoPackage structured data store. This ER documents the different approaches considered, design decisions and rationales, limitations, and issues encountered during prototype implementation.
This ER describes proposed solutions for filling two interoperability gaps in the OGC baseline. The first is in off-road routing, where there is currently no interoperable means for sharing routes between systems. The second is in user-defined map symbology, where existing approaches such as Symbology Encoding (SE) have not achieved desired objectives of persisting styling rules and making them available to client applications throughout the enterprise.
This ER proposes a way ahead for the the two topic areas. If these approaches prove to be useful, they will be submitted to the GeoPackage SWG for consideration as official extensions to OGC GeoPackage.
After producing GeoPackage 1.1, the GeoPackage SWG investigated possible extension areas. This ER presents the SWG with proposed approaches for routing and symbology.
ogcdocs, testbed-12, GeoPackage, routing, symbology, styling, cross country, off-road
This OGC® document describes the results of experiments to perform routing and styling on a GeoPackage. It includes a proposed approach for persisting static and dynamic styling information inside a GeoPackage.
This OGC® document is applicable to the OGC GeoPackage Encoding Standard.
1.2. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Image Matters LLC
1.3. Future Work
It is expected that this document may result in new extensions to the OGC GeoPackage Encoding Standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
OGC 16-037, Testbed-12 GeoPackage US Topo ER
OGC 06-121r9, OGC® Web Services Common Standard
OGC 12-128r12, OGC® GeoPackage Encoding Standard 1.1
3. Terms and definitions
For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC 06-121r9] shall apply.
3.1. Abbreviated terms
IDE Integrated Development Environment
iOS an operating system used for mobile devices manufactured by Apple Inc.
MXD file extension for a map document used by ArcMap
OS Operating System
PC Personal Computer
PCL Portable Class Library
SC Secure Digital
SE OGC Symbology Encoding
SLD OGC styled Layer Descriptor
SWG Standards Working Group
The following table describes the sections that will appear later in this document.
5 - Routing Requirements
Description of routing capabilities, status quo, and requirements statement
6 - Routing Solutions
Design decisions needed, alternatives considered, recommendations, and rationales for routing application
7 - Symbology Requirements
Description of symbology capabilities, status quo, and requirements statement
8 - Symbology Solutions
Design decisions needed, alternatives considered, recommendations, and rationales for symbology capabilities
Appendix A - Static Symbology Extension
Proposed GeoPackage extension template for static symbology information
Appendix B - Dynamic Symbology Extension
Proposed GeoPackage extension template for dynamic symbology information
5. Routing Requirements
The purpose of this mobile application is to provide users the capability to view GeoPackages as a source or layer and create routes (excursions) that performs elevation analysis offline or with no wireless connection availability. Included in the application will be a user preferences activity that will allow the user to select pre-designated weighting rules or cost functions that influence route traversal. These options will be categorized and listed based on traversal method (vehicle (various types), walking/hiking, obstacle avoidance preferences (slope planes, geo-political, and hydrographic elements)). Based on the category selected, a single traversal method method will be selected to determine the appropriate algorithm, or combination of, used for route determination including obstacle avoidance constraints preferences.
5.1. Status Quo
There is currently existing functionality in place to determine routing in the form of C++ libraries. Researchers are unaware of any prior work that provides equivalent capabilities in a form that is readily usable in the target computing environments.
5.2. Requirements Statement
There are two target computing environments, PC (using Windows OS) and an tablet/mobile device (using Android OS).
The user will have the ability to import a GeoPackage from their local device (i.e. flash, SD card storage) into the application.
The user may load one or more GeoPackages into the application, where the GeoPackage is considered "active" and can be used to visualize GeoPackage contents, or may be used computationally to perform analysis.
The off-road routing application will apply user-selectable, pre-designated weighting rules to return an acceptable path from an origination point to a destination point.
6. Routing Solutions
6.1. Development Environments
We determined that Visual Studio with Xamarin (C#) was the most suitable IDE because of its support for both target computing environments. This approach enabled us to reuse the portable class libraries (PCL) we developed for each platform (Android, Windows, iOS). Any code not specific to an operating system (UI-related) was placed in a PCL therefore minimizing the need to re-write the same functions per OS targeted. This allowed us to develop libraries that could be used for cross-platform (iOS, Android, Windows, etc.) development with limited platform-dependent restrictions (specifically UI restrictions).
We also made the decision to utilize some open-source projects, such as Mapsui and SharpMap. SharpMap is a web-based mapping application that supports GeoPackage usage and Mapsui is a mobile variant of SharpMap, but does not explicitly support GeoPackages. By integrating the two libraries we were able to create a mobile solution with the ability to render GeoPackage tiles.
6.2. Routing Algorithms
We attempted to import or "wrap" existing routing C libraries in a Xamarin portable class library but were unable to do so. Instead we ported the capabilities into a PCL (from C to C#).
6.3. Just-in-Time Layer Loading
Since the size of a GeoPackage can be quite large, we decided to prevent the application from loading a full GeoPackage into device memory. The fact that a GeoPackage can contain multiple tile, feature, and attribute layers, we decided to only reference a layer when needed. Therefore, layer toggling (only loading layer when a user requests it) is only performed on request to minimize memory and processing. Better handling of the renderable layers will need to be discussed in order to leverage memory-management best-practices in the future.
At the point a route is requested, we determined that the app would be more efficient in processing if we moved the event onto an asynchronous processing thread. Moving this to an asynchronous thread allowed us to notify the user that route processing is still “working” while it retrieves all the data points and calculates the route for displaying.
6.5. GeoPackage Import Source
Further research and analysis is needed on the GeoPackage import source and procedure. Methods researched include PC transfer (requires external functionality), Bluetooth, website download (requires external functionality), and external SD card. For the purposes of this experiment, we imported a GeoPackage from the device’s flash memory.
6.6. Use of TINs
TINs proved to be a better solution than gridded elevation data in most cases because it provides a place to store a preprocessed cost for routes. Gridded elevation data provides node height which is in itself useful, but makes route processing more cumbersome.
6.7. Limitations and Issues
6.7.1. Flexibility of GeoPackage Encoding Standard
The GeoPackage standard is extraordinarily flexible and, as a result, problematic when developer-defined extensions are created. If instances other than features, tiles, and attributes (mentioned in OGC’s Geopackage standard spec document) are used, not all items within the gpkg_contents table would be processed unless they are explicitly programmed for in that particular application. In short, an app that can display/save media information within a GeoPackage may only be able to render data created by that same app, leaving no room for data use outside of that application. This also creates an issue of more than one layer within a GeoPackage not being visible or used to determine route traversal.
6.8.1. TIN Extension
There is currently no standard for TIN or gridded elevation data within a GeoPackage. In order to be able to process elevation data from a TIN, a conversion process has to take place (from GeoTiff-DEM data to node/edge data file format). This process could only be completed on a former developer’s machine given many undocumented libraries of which it contained.
7. Symbology Requirements
Using an extension to express a method of styling features tests the extension mechanism and advances the work of the GeoPackage SWG regarding the inclusion of at least one form of styling information in a GeoPackage.
7.1. Use Cases
The SWG has identified 2 use cases which should be addressed in this ER:
Geometry styling (UC4) - Geometry styles will be applied based on the application of styling directives such as those found in the OGC Style Layer Descriptor (SLD) standard. The output of the interpretation will be a set of symbols/drawing instructions cross-linked to the features they are meant to symbolize. The interpretation rules from the styling will not be carried over.
Feature Type Styling (UC5) - similar to Geometry Styling, this approach relies on the interpretation of a set of styling directives that process feature attributes to determine a symbolization for a feature. The relevant rules for the style will be stored in the GeoPackage to be interpreted at render time, or be pre-rendered into geometry styling. The benefit of maintaining these rules in the GeoPackage is that the symbolization of a feature can be re-interpreted if its attributes change.
7.2. Status Quo
There is currently no interoperable way of exchanging styling information within a GeoPackage. At best, individual vendors have produced their own approaches to solving the styling requirement.
7.3. Requirements Statement
Testbed 12 generated discussion regarding the implementation of use cases UC4 and UC5. The prototype styling implementation created for the testbed exposed an alternate method of styling within the OGC. The findings may be useful to spur more work developing and extending current styling methodologies or developing new ones.
8. Symbology Solutions
Solutions for symbology representation in a GeoPackage are documented in another Engineering Report. As of this writing, this report has a working title of Testbed-12 GeoPackage US Topo ER.
In order to achieve the immediate goals for Testbed 12, the following solutions were adopted:
Encoding of styles from the USGS topographic style template to be used to render topographic data on a client using a style specification system that employs attribute based symbology assignment.
Use of a mobile client to demonstrate offline rendering of vector features and supporting raster data according to use cases
Generation of a new GeoPackage extension to support vector feature styles for rendering derived from symbology encoding that supports re-styling after feature changes.
In addition to the symbology encoding solution, there was a need to store the relations between the features and the symbologies in the GeoPackage. In order to do this, a new extension was designed to accommodate this approach. This structure and use of this extension is detailed in the "UML Models for Symbology Extension" of Testbed-12 GeoPackage US Topo ER.
8.1. Approaches Considered
Two symbology encoding approaches were considered:
OGC Styled Layer Descriptor (SLD) / OGC Symbology Encoding (SE).
A JSON encoding developed by Compusult
While the OGC SLD/SE standard was considered, it was more effective to use the JSON approach as it was already proven to work to accomplish the goals of the Testbed, and there are some benefits to using the JSON symbology encoding. Compusult was not aware of any other efforts and decided therefore to use their JSON based in-house approach. This approach is described in the "Symbology Encoding" appendix of Testbed-12 GeoPackage US Topo ER.
8.1.1. Style Encoding
Style encoding was accomplished through the use of a stylesheet that defined the appropriate symbology for feature layers based on filter criteria and scale. If there is no filter criteria pertaining to a style, the style was generalized for the whole feature type. In the process of styling the features, ancillary tables for the encoded feature types were created to relate individual features to:
A determined symbology based on scale
If required, a rule that determined the symbology based on scale and a rule attribute
In the process of constructing the symbology for a feature type, Compusult determined that there are limitations in that the layer hierarchy defined in the Topographic Map Template could not be followed as there was no way of directly encoding the groups implied in the template. There were two ways the feature data could be encoded as closely as possible to the Feature Classes that appear in the GeoDataBase.
Styles covering all required symbologies and feature types defined by definition queries were merged into a set of styles applied to the single feature class. A good example of this is the group of sub layers derived from the GU_Reserve feature class. On their own in the template MXD, there were the following "sub features" each with an implied style based on a criteria.
In this case, the method employed did not segregate the data into separate feature tables in the GeoPackage. Instead, all features remained in the same base table and were simply styled according to the requirements dictated in the original MXD based template.
The other approach was to generate individual feature tables derived from the query definitions in the TNM template. This was the approach chosen as the user would have similar control over each layer as they would when viewing the data in ArcMap.