Testbed-12 GeoPackage US Topo Engineering Report

Publication Date: 2017-05-12

Approval Date: 2017-01-26

Posted Date: 2016-11-02

Reference number of this document: OGC 16-037

Reference URL for this document: http://www.opengis.net/doc/PER/t12-B004

Category: Public Engineering Report

Editor: Robert Cass

Title: Testbed-12 GeoPackage US Topo Engineering Report

Testbed-12 GeoPackage US Topo ER (16-037)

COPYRIGHT

WARNING

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.

LICENSE AGREEMENT

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.

Table of Contents

1. Introduction
2. References
3. Terms and definitions
4. Conventions
- 4.1. Abbreviated terms
- 4.2. UML notation
5. Overview
6. Status Quo & New Requirements Statement
- 6.1. Status Quo
- 6.2. Requirements Statement
7. Solutions
Appendix A: Data Mappings from GDB to SQLite
- A.1. Naming and Organizing Layers Created from the GeoDatabase Source
Appendix B: Symbology Encoding
- B.1. History
- B.2. Examples
Appendix C: UML Models for Symbology Extension
Appendix D: Converter WPS Description
Appendix E: Revision History

Abstract

This OGC Engineering Report documents the outcome of the US Topo experiment. The focus of the US Topo experiment was to generate GeoPackages by combining USGS Topo Map Vector Data Products ^[1]; and the Topo TNM Style Template ^[2]. The output GeoPackages will contain both features and instructions for styling these features as well as orthoimagery, shaded relief raster tilesets, national wetlands raster tilesets and elevation data derived from USGS provide 1/9 arc second elevation imagery. The process used to generate the GeoPackage is explained. Problems and obstacles encountered decoding the source product and styles and converting these artifacts to a GeoPackage are explained with recommendations for improvements. Additionally, the experience applying the generated GeoPackage in two use cases proposed for this testbed will be evaluated. The introduction of symbolization for vector features will be articulated as a proposed extension for GeoPackage. Any issues related to encoding the TNM style template using the extension are documented.

Business Value

GeoPackage is an open standard with an established extension mechanism. Using an extension to express a method of styling features will test the extension mechanism and advance the work of the GeoPackage SWG regarding the inclusion of at least one form of styling information in a GeoPackage.

Technology Value

This ER will provide a useful perspective for the GeoPackage SWG membership as they develop methodologies for encoding styling information and feature collections. This ER may also be relevant to efforts of working groups that advance the definition of symbology and approaches to styling that were also encountered in Testbed-12.

How does this ER relate to the work of the Working Group

This ER is relevant to the GeoPackage SWG because it addresses the need for symbolizing features in a GeoPackage. Methods for storing styles and evaluating styles are presented in this ER that will inform the pursuit of style encoding standards for GeoPackage.

Keywords

ogcdocs, testbed-12, topographic, GeoPackage, styles, styling, vectors, symbology, portrayal

Proposed OGC Working Group for Review and Approval

GeoPackage SWG

1. Introduction

1.1. Scope

This OGC Engineering Report describes the processes and constructs used and challenges encountered while encoding USGS topographic feature data, shaded relief and orthoimagery tiled data in GeoPackage format. This Engineering Report will also detail the encoding schema for the data and styles used. Additionally, this Engineering Report will describe prototype GeoPackage extensions for storing styles and hierarchical feature classes. This OGC® document is applicable to the work of the GeoPackage SWG as a means of advancing the development of a method of encoding styles for vector features to meet Use Case 5 from OGC 15-122r1. Additionally, this document is applicable to readers interested in encoding datasets and styles like the ones addressed in the document.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name	Organization
Robert Cass	Compusult Ltd.

1.3. Future Work

It is expected that this document may result in changes in other documents. Additionally, this document provides recommendations for improved approaches to encoding the required data sources in a GeoPackage that bring the produced geopackage closer in alignment to the pdf maps that the USGS currently produces.

1.4. Foreword

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.

2. References

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® WPS 2.0 Interface Standard, 2015-10-05, http://docs.opengeospatial.org/is/14-065/14-065.html
OGC® GeoPackage Encoding Standard, 2016, http://www.geopackage.org/spec/
OGC® Web Map Service, 2006-03-15, http://portal.opengeospatial.org/files/?artifact_id=14416
OGC® Web Map Tile Service Implementation Standard, 2010-04-06, http://portal.opengeospatial.org/files/?artifact_id=35326
GDAL Geospatial Data Abstraction Library, 2016, http://www.gdal.org
SpatialLite, 2016, https://www.gaia-gis.it/fossil/libspatialite/home

3. Terms and definitions

For the purposes of this report, the following terms and definitions apply.

3.1. GeoPackager

computer software that uses input data sources to create a GeoPackage containing an encoding of those input sources

3.2. raster tile

rectangular piece of a larger tile mosaic or matrix intended to be viewed between certain map scales that is encoded in a raster format

3.3. symbology

electronic encoding of all the information required to correctly visually portray a geographic feature

3.4. style

electronic encoding of all the symbologies used to visually portray geographic features that also maps these symbologies to features

3.5. filter

boolean clause used to evaluate the data attributes of a feature to determine what symbology will be used to portray this feature

3.6. OGC Web Processing Service (WPS)

The term OGC Web Processing Service (WPS) describes a service instance of an OGC WPS server. A WPS is a container for one or many processes. The capabilities of a WPS contain the list of services which are hosted by the WPS. Each process is further described by the Process Description.

3.7. Stylesheet

A set of encoded instructions that determine how to render geographic features on a computer screen. The stylesheet is used to organize features into layers and to define rules that use the attributes of these features to determine how to physically represent these features using drawing instructions such as color, line width, fill patterns etc. A well known example of this sort of stylesheet is OGC Styled Layer Descriptor.

4. Conventions

None.

4.1. Abbreviated terms

API Application Program Interface
TNM The National Map
USGS United States Geological Survey
WMS OGC Web Map Service
WMTS OGC Web Map Tile Service
WPS OGC Web Processing Service
SE Symbology Encoding
SLD OGC Styled Layer Descriptor
CR Change Request
GDB an ESRI © file geodatabase ^[3]
GDAL Geospatial Data Abstraction Library ^[4]
MXD ESRI ArcMap map document ^[5]
SVG Scalable Vector Graphics ^[6]

4.2. UML notation

Most diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 06-121r9].

5. Overview

5.1. Requirements

The requirements for this testbed-12 activity were:

Document all problems and obstacles with using the USGS Topo Combined Vector Product to create the GeoPackage.
Test a workflow and document all problems and obstacles with encoding the GeoPackage with standard USGS US Topo Map symbology as defined in the Topo TNM Style Template.
Document the process used to convert the USGS Topo Combined Vector Product data to GeoPackage format (so that USGS can reproduce the GeoPackage format) must be recorded in the ER.
Document the process used to encode GeoPackage data with US Topo Map symbology as defined in the Topo TNM Style Template (so that USGS can reproduce the encoded symbolized GeoPackage format) must be documented.
Document the process for end users using the Use Cases described. Include any obstacles or limitations to the end users.

5.2. Use Cases

In a briefing presented to the GeoPackage Standards working group on Nov. 10th, 2015 by Randy Gladish of Image Matters LLC ^[7], use cases for styling and symbolization were articulated. Two of these use cases; UC4 and UC5 are addressed in the USGS Topo experiment.

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 the symbolization for a feature. The relevant rules for the style will either 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. The USGS Topo experiment is designed to generate discussion regarding the implementation of UC5. The implementation created for the testbed will also expose an alternate method of styling within the OGC and it may be useful to provide the findings to spur more work developing and extending current styling methodologies or developing new ones.

5.3. Approaches

The processing of any GDBs will be done by a conversion engine. One publicly exposed interface is a web accessible GUI that users can use to define GDB and OGC Web Map Tiling Service (WMTS) datasources. When a user prompts for the creation of a GeoPackage, the conversion engine will combine these datasources in combination with parameters such as Area of Interest (AOI), scale zoom levels and stylesheet to generate the required GeoPackage.

An additional interface will be a WPS providing clients the ability to programmatically follow the same flow.

5.3.1. Feature input source translation

Translation is performed using GDAL ogr2ogr which is a tool that translates various vector feature formats into other vector feature formats. The end result is a Spatialite database that can be worked with directly to query and encode into a GeoPackage. Feature classes in the FileGDB are directly translated to feature tables in the GeoPackage. Features are stored in a geographic projection.

5.3.2. Raster input source translation

Raster data is harvested directly using a WMTS/WMS client to populate a raster tile pyramid with tiles from online USGS tile and WMS sources. These include a shaded relief server and an imagery server. Tiles are provided in Web Mercator projection (EPSG:3857) ^[8]. This may prove to be less effective than providing the data in the correct UTM projection that the cell data should be viewed in.

Additional elevation data will be encoded in the GeoPackage produced using 1/9 arc second elevation data products directly available for download.

5.3.3. Styling approach

The approach to styling uses a stylesheet that includes:

Filter rules for selecting features for symbology application.
Appropriate matching of styles and scale denominators
The definition of layers, and layer drawing order

5.3.4. Style and symbology encoding

Style encoding according to UC4 is performed by mapping a set of symbologies directly to a feature type. Multiple symbologies can be applied to a single feature depending on scale and the creation of compound styles.
The symbology encoding instructions such as line width or color are encoded in JSON in a single column in the table.

5.3.5. Raster tile encoding

For the purposes of the experiment, raster tiles are encoded in a standard GeoPackage tile pyramid based on the Web Mercator tile matrix set.

5.3.6. Integration Use Case experiences

A State Geologist intends to produce a 24,000-scale map using base map data and symbology in a US Topo Map design and layout. The Geologist will use ArcGIS to create the map and will add her own geologic data layers to the base data. The base data will be downloaded in the OGC GeoPackage and the US Topo Map specified symbology will be encoded with the GeoPackage.
A County Emergency Manager would like to obtain symbolized base map data in a US Topo Map design to support an evacuation exercise. The Emergency Manager does not have any sophisticated GIS software. He has an iPad that he takes into the field with him and would like to be able to use a map-like display and query the attributes of the data. In addition, he would like to be able to display a hillshade and local imagery along with the map display.

5.3.7. Integration obstacles

UTM projection v. Spherical Mercator. The data in the USGS FileGDBs is intended to be viewed in the correct UTM projection for the cell area. However, source data for hill Shading and orthoimagery is provided by WMTS services whose tiles are in Web Mercator.
New methods for styling, storing generalized geometries and display hierarchies for views of a layer are all prototypical and are not defined in the current GeoPackage standard. To conform to the TNM template, these extensions to the GeoPackage standard are required, but will only be supported by client software capable of rendering this display.
The requirement to create and maintain a proprietary stylesheet to support the proper creation of the GeoPackage can be a stumbling block as it requires extra training. The automatic generation of such a file is difficult as the proper tools are not available to generate this file. The ESRI MXD file is not readable. Therefore the stylesheet must be created manually.

5.3.8. Encoding Obstacles

Determining symbology for display at different scales required a best guess. This is due to the fact that different scale ranges requiring different symbologies for the same feature is not part of the TNM template.
Font sets are collections of encoded glyphs that are used by computer programs to display letters or icons. Styling approaches using Esri tools often use Unicode symbols from Esri supplied fontsets to create icons on the map. These symbols needed to be converted to images because the style system used in the experiment did not support this approach.
SVG symbols should be used; instead, png symbols were created using screen shots of current symbology in ArcGIS
There was no existing way to represent layer "hierarchies" as expressed in the TNM template.
Some sophisticated filter expressions that exist in Esri tools are not supported directly e.g. "T" & Mid([PLSSID]. 5, 3)
Font translation is tricky depending on the supported platforms.
Contour lines have a polygon "z" shape. There is no way of preserving this in the stored geometries based on the GeoPackage design.
Esri layer groupings in the MXD file allow for multiple "views" of the same feature class to appear as "layers" in a client. In ArcMap, symbology can be assigned at this level. This was not supported in GeoPackage. Solutions to get around this are the creation of sub feature classes at the GeoPackage level; essentially a materialized view of the data or the merging of multiple styles under a single layer. Ultimately, in order to maintain the 1:1 mapping of feature classes to GeoPackage features, separate feature layers were created for each "view".

5.3.9. Process Obstacles

There were no significant process obstacles.

5.3.10. Interoperability Experiment Outcomes

While generated GeoPackage and the WPS service instances used for creating them were available early in the experiment, no client or service providers volunteered to participate in interoperability work despite invitations during telecons. Generated GeoPackages were visualized successfully in Compusult clients and new approaches for styling that were developed during the testbed were adopted by Compusult. Our best guess is that the nature of the symbology representation presented a challenge to GeoPackage clients that could not be met during the testbed. In the future, we recommend that the thread architects advocate for interoperability partnerships early in the testbed, so that there is at least one partnership per component.

5.4. Proposed style encoding extension

There are 2 aspects to the proposed style extension that are documented. One is the style encoding, the other is the relation of styles to the database. A style encoding consists of the symbology to be used at a particular scale, and in the case of dynamic styling, the filter expression used to evaluate a feature’s symbology based on its attributes. The encoding will be documented in Symbology Encoding.

5.5. Proposed hierarchical layer/raster extension

The Testbed-12 thread participants decided that the layer hierarchy not be expressed in the production of GeoPackages for this experiment.

6. Status Quo & New Requirements Statement

6.1. Status Quo

Currently, there is no method for encoding the styles used for feature portrayal in a GeoPackage.
Currently, the USGS has topographic data and its portrayal specification is encoded in a particular format, arcmap/geodatabase.
Currently, the USGS provides topo data as well as contextual imagery and shaded relief in a combined PDF product.

6.2. Requirements Statement

USGS requires that their topographic data be encoded in a GeoPackage. Additionally, the style for that data must be encoded in the GeoPackage according to the cartographic design used for US Topo maps
USGS requires that supporting orthoimagery and shaded relief be encoded as raster tiles in the GeoPackage
To support the USGS requirements, a GeoPackage extension must be created to support styling the stored vector features.
Some OGC members have requested that elevation data be packaged in the GeoPackage as well.

7. Solutions

7.1. Targeted Solutions

In order to achieve the immediate goals of the for Testbed 12, the following solutions were adopted:

Encoding of topographic data and supported data in GeoPackage using the GeoPackage Converter WPS
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.
Encoding of shaded relief and orthoimagery provided by WMS/WMTS using the Compusult GeoPackage Converter WPS.
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.
Elevation data for supporting the 7.5' x 7.5' quad to be encoded in a tile pyramid in the GeoPackage using a GeoPackage Elevation Extension that was prototyped during an interoperability experiment ^[9].
All data to be placed in Web Mercator to support available tile sets for shaded relief.

7.1.1. Converter WPS

In order to make the conversion of stock USGS data to a GeoPackage encoded product, a WPS was designed and delivered to perform two basic tasks:

Register data sources which provide the base data that will be encoded in the GeoPackage. The following data sources were used :
1. A Geodatabase provided by USGS as an example dataset for the Testbed 12 area of interest is: https://prd-tnm.s3.amazonaws.com/StagedProducts/Vector/GDB/VECTOR_27656_Mare_Island_7_5_Min.zip
2. Shaded Relief WMTS tiles are located at: http://basemap.nationalmap.gov/arcgis/rest/services/USGSShadedReliefOnly/MapServer/WMTS/1.0.0/WMTSCapabilities.xml
3. Wetlands tiles derived from: http://107.20.228.18/arcgis/services/Wetlands/MapServer/WMSServer?request=GetCapabilities&service=WMS
4. Imagery tiles derived from: http://isse.cr.usgs.gov/arcgis/services/Orthoimagery/USGS_EROS_Ortho/ImageServer/WMSServer?request=GetCapabilities&service=WMS
5. Intersecting elevation products provided by the USGS such as: https://prd-tnm.s3.amazonaws.com/StagedProducts/Elevation/19/IMG/ned19_n37x50_w122x00_ca_sanfrancisco_topobathy_2010.zip
Combine registered data sources over an area defined by the bounds of the named GDB.

The WPS operations are described in Converter WPS Description

A simple client was created to use the WPS and demonstrate the call/response flow. It is located at http://ogc-tb12fo.compusult.net/wes/WPSClient.jsp.

The screenshot below shows the client with some requests and responses inline as the client executes the creation of a GeoPackage.

Figure 1. WPS Client Example

7.1.2. Resulting GeoPackage

The result of the conversion process yields a GeoPackage with the following table of contents :

Table 2. Table GeoPackage Contents
table_name	data_type	identifier	description
ned19_n38x25_w122x25_ca_sanfrancisco_topobathy_2010	2d-gridded-coverage	ned19_n38x25_w122x25_ca_sanfrancisco_topobathy_2010.tiff
GPKG8caeccd6_5595_48a4_b09e_6666a799817f	tiles	USGSShadedReliefOnly
GPKG76332686_db49_43ef_aa08_b61864ee8686	tiles	Imagery
GPKG6758ae81_f0c7_406d_9965_60c1a2304351	tiles	Wetlands
LANDCOVER_WOODLAND	features	Woodland	Woodland
NHDArea	features	Perennial NHDArea	Perennial NHDArea
IntermittentNHDWaterbody	features	Intermittent NHDWaterbody	Intermittent NHDWaterbody
IntermittentNHDArea	features	Intermittent NHDArea	Intermittent NHDArea
Wetlands	features	NWI Wetlands w/ US Topo Symbology	NWI Wetlands w/ US Topo Symbology
NHDWaterbody	features	Perennial NHDWaterbody	Perennial NHDWaterbody
Elev_Contour	features	Contours	Contours
NHDPoint	features	NHD Points	NHD Points
GagingStation	features	Gaging Station	Gaging Station
NHDFlowline	features	NHDFlowline	NHDFlowline
NHDLine	features	NHDLine	NHDLine
GU_PLSSTownship	features	Township/Range	Township/Range
GU_PLSSSpecialSurvey	features	GU.GU_PLSS SpecialSurvey	GU.GU_PLSS SpecialSurvey
GU_PLSSFirstDivision	features	Section	Section
Trans_RoadSegment	features	Census Roads	Census Roads
trans_roadsegment_ntdnofs	features	USFS Roads	USFS Roads
Trans_TrailSegment	features	Trail	Trail
Trans_RailFeature	features	Railroad	Railroad
Trans_AirportRunway	features	AirportRunway	Airport Runway
GU_StateOrTerritory	features	State or Territory	State or Territory
GU_CountyOrEquivalent	features	County or Equivalent	County or Equivalent
GU_Reserve	features	National Cemetery	National Cemetery
NationalParkService	features	National Park Service	National Park Service
DepartmentofDefense	features	Department of Defense	Department of Defense
ForestService	features	Forest Service	Forest Service
FishandWildlifeService	features	Fish and Wildlife Service	Fish and Wildlife Service
GU_NativeAmericanArea	features	NativeAmerican Lands	Native American Lands
BureauofLandManagement	features	Bureau of Land Management	Bureau of Land Management
TNMDerivedNames	features	Structures from GNIS	Structures from GNIS
Struct_Point	features	Structures	Structures
Trans_AirportPoint	features	AirportPoint Labels Only	AirportPoint Labels Only
reQziqrD_cOst_hMDi_Dxpp_1XlPFPgUMlnr	features	TNM Derived Names	TNM Derived Names
CellGrid_7_5Minute	features	7.5_min Cells	7.5_min Cells

7.1.3. 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, we 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.

7.2. Alternatives considered

Regarding encoding of style information in the GeoPackage itself, the OGC SLD/SE standard was considered. However, this did not meet the requirements this Testbed activity. We were not aware of any other efforts and decided therefore to use the JSON based in-house approach developed by Compusult. This approach is described in UML For Symbology Encodings.

7.3. Recommendations

Having reviewed the GeoPackage output and comparing it to the available PDF maps that are provided by the USGS, and based on the experiences of this testbed, the following recommendations for encoding USGS Topo Data and supporting raster data as a GeoPackage are:

Encode all required data in proper UTM projection for the quad in question. For the testbed, the data was encoded in EPSG:3857, which is not ideal for the purpose. There are two main reasons this approach was adopted:
1. There is no formal tile matrix set proposed for individual UTM zones.
2. Supporting data sources were only available in EPSG:3857.
Ensure that supporting data sources are available in the desired projections as much as possible to ensure data quality. If the USGS provides the sources, they have control of the provenance and quality of the data.
Rigorous Quality Assurance needs to be done to ensure that the imagery and elevation products are accurately re-projected to the targeted projection
Data for non-critical datasets should be provided by WMS in order to provide UTM projected information. Primary examples would be wetlands and shaded relief data.
USGS provides metadata documents for the elevation and GDB products. A format for these metadata documents should be provided so that the metadata can be put in the correct place in the GeoPackage. Metadata for basemap data produced by web services should be provided for this purpose as well.
WMTSes for source data will require larger scales to provide functionality parallel to pdf products. If this is not possible, WMS services should be made available for harvesting the data at these scales.
It would be beneficial for the USGS to provide a WCS interface that can be used to extract elevation data clipped to the bounds and correct coordinate system for the desired 7.5’x7.5' area. Currently a producer needs to clip and convert the elevation data provided in the zip file from the USGS. Providing this service will allow the USGS to control the quality of the elevation data provided in the required coordinate system.
In order to ease the development of styles based on all possible feature types and permutations, it would be a good idea to have a set of test data available that conformed to all possible style cases to verify that all the style encodings rendered correctly. Without this reference dataset, to prove all style rules, a producer would need to find sample data from across all available datasets.
It was noticed that the layer bounds for the Shaded Relief layer in the WMTS did not correspond to the bounds of its tile matrix. This should be fixed.

7.4. Styling Examples

The following screenshots show examples of styled topographic feature data displayed in the Compusult GOMobile Client.