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
COPYRIGHT
Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
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.
- 1. Introduction
- 2. References
- 3. Terms and definitions
- 4. Conventions
- 5. Overview
- 5.1. Requirements
- 5.2. Use Cases
- 5.3. Approaches
- 5.3.1. Feature input source translation
- 5.3.2. Raster input source translation
- 5.3.3. Styling approach
- 5.3.4. Style and symbology encoding
- 5.3.5. Raster tile encoding
- 5.3.6. Integration Use Case experiences
- 5.3.7. Integration obstacles
- 5.3.8. Encoding Obstacles
- 5.3.9. Process Obstacles
- 5.3.10. Interoperability Experiment Outcomes
- 5.4. Proposed style encoding extension
- 5.5. Proposed hierarchical layer/raster extension
- 6. Status Quo & New Requirements Statement
- 7. Solutions
- Appendix A: Data Mappings from GDB to SQLite
- Appendix B: Symbology Encoding
- B.1. History
- B.2. Examples
- B.2.1. Contour Styling
- B.2.2. Examples of symbology generated for Layers found in VECTOR_3330_Benicia_7_5_Min.gdb
- B.2.3. BureauofLandManagement
- B.2.4. CellGrid_7_5Minute
- B.2.5. Elev_Contour
- B.2.6. FishandWildlifeService
- B.2.7. GagingStation
- B.2.8. GU_NativeAmericanArea
- B.2.9. IntermittentNHDArea
- B.2.10. IntermittentNHDWaterbody
- B.2.11. LANDCOVER_WOODLAND
- B.2.12. NHDArea
- B.2.13. NHDFlowline
- B.2.14. NHDLine
- B.2.15. NHDPoint
- B.2.16. NHDWaterbody
- B.2.17. Struct_Point
- B.2.18. TNMDerivedNames
- B.2.19. Trans_RailFeature
- B.2.20. Trans_RoadSegment
- B.2.21. trans_roadsegment_ntdnofs
- B.2.22. Trans_TrailSegment
- B.2.23. Wetlands
- Appendix C: UML Models for Symbology Extension
- Appendix D: Converter WPS Description
- Appendix E: Revision History
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.
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.
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.
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.
ogcdocs, testbed-12, topographic, GeoPackage, styles, styling, vectors, symbology, portrayal
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:
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 :
-
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
-
Shaded Relief WMTS tiles are located at: http://basemap.nationalmap.gov/arcgis/rest/services/USGSShadedReliefOnly/MapServer/WMTS/1.0.0/WMTSCapabilities.xml
-
Wetlands tiles derived from: http://107.20.228.18/arcgis/services/Wetlands/MapServer/WMSServer?request=GetCapabilities&service=WMS
-
Imagery tiles derived from: http://isse.cr.usgs.gov/arcgis/services/Orthoimagery/USGS_EROS_Ortho/ImageServer/WMSServer?request=GetCapabilities&service=WMS
-
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.
7.1.2. Resulting GeoPackage
The result of the conversion process yields a GeoPackage with the following table of 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:
-
There is no formal tile matrix set proposed for individual UTM zones.
-
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.