Publication Date: 2017-05-12

Approval Date: 2017-01-26

Posted Date: 2016-10-31

Reference number of this document: OGC 16-038

Reference URL for this document:

Category: Public Engineering Report

Editor: Chris Clark

Title: Testbed-12 NSG GeoPackage Profile Assessment Engineering Report

Testbed-12 NSG GeoPackage Profile Assessment Engineering Report (16-038)


Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit


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 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.


The National System for Geospatial-Intelligence (NSG) GeoPackage Profile defines and tailors the implementable provisions prescribed for the NSG for a GeoPackage based on the OGC GeoPackage encoding standard. The profile provides detailed directions on how to use the clauses, options and parameters defined in the base GeoPackage standard. The goal is to ensure that NSG GeoPackages, GeoPackage SQLite Extensions, and supporting utilities and services fulfill their intended purposes and are fit for use.

The goal of this Engineering Report (ER) is to assess whether requirements as specified in the proposed profile are specific enough to allow for any two independent GeoPackage implementers to produce and consume interoperable NSG GeoPackages. Concerns with the profile are outlined and recommendations for improvement are provided. Thoughts on the viability of the profile approach and guidance on how the profile could apply to Vector Tiling are also provided.

Business Value

The NSG GeoPackage Profile was created to ensure interoperability and usefulness of NSG GeoPackages. Lessons learned from assessing this profile will further this interoperability. The activity also provided possible changes to the core OGC GeoPackage standard. This will make it easier for other organizations to create interoperable and useful OGC GeoPackages, ensuring continued adoption of the standard.

A measure for success of any standard is how many implementers have used the standard to create interoperable software. The NSG Profile of GeoPackage has the potential to bring many more compliant implementations into the fold. Evaluating the profile will ensure these implementations will indeed be more interoperable. The evaluation may also highlight possible changes that the GeoPackage Standards Working Group (SWG) should consider making to the base GeoPackage standard.

Technology Value

This ER will assess how the NSG GeoPackage profile can be used to meet the needs of the NSG community of interest. Requirements identified in the profile may identify areas for improvement to the GeoPackage standard.


assessment, data, feature, geopackage, NSG, ogcdocs, profile, raster, sqlite, storage, testbed-12, tiles, vector

Proposed OGC Working Group for Review and Approval

GeoPackage SWG

1. Introduction

1.1. Scope

This OGC document assesses the validity of the NSG GeoPackage profile to allow for multiple independent GeoPackage implementers to produce and consume interoperable NSG GeoPackages that fulfill their intended purposes and are fit for use.

This OGC document is applicable to GeoPackage implementers that intend for the GeoPackages to be NSG compliant.

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

Chris Clark

Compusult Limited

1.3. Future Work

It is expected that this document may result in changes to the NSG GeoPackage Profile, as well as the OGC GeoPackage standard.

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 06-121r9, OGC® Web Services Common Standard

NOTE: This OWS Common Standard contains a list of normative references that are also applicable to this Implementation Standard.
  • NGA.STND.0051_1.0_GEOPKG, National System for Geospatial-Intelliegence (NSG) GeoPackage Encoding Standard 1.0 Interoperability Standard (2016-07-01)

  • NGA.STND.0051_2.0_GEOPKG, National System for Geospatial-Intelliegence (NSG) GeoPackage Encoding Standard 1.0 Interoperability Standard (2016-09-02)

  • OGC 12-128r11, OGC GeoPackage Encoding Standard 1.0.1 (2015-04-20)

  • OGC 12-128r12, OGC GeoPackage Encoding Standard 1.1 (2015-08-04)

  • OGC 12-163r5, Geographic information - Well-known text representation of coordinate reference systems 1.0 (2015-05-01)

  • OpenGIS 01-009, OpenGIS® Implementation Specification: Coordinate Transformation Services 1.0 (2001-01-12)

  • OGC 06-103r4, OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture Version: 1.2.1 (2011-05-28)

3. Terms and Definitions

For the purposes of this report, the definitions specified in Clause 4 of the Web Services Common Standard [OGC 06-121r9] shall apply. In addition, the following terms and definitions apply.

3.1. geopackage | gpkg

Open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information.

3.2. profile

Set of one or more base standards or subsets of base standards, and, where applicable, the identification of chosen clauses, classes, options and parameters of those base standards that are necessary for accomplishing a particular function.

3.3. vector tile | tiled vector | vectile

Packet of geographic data, packaged into a pre-defined roughly-square shaped "tile" for transfer over the web.

4. Conventions

4.1. Abbreviated Terms

  • CRS - Coordinate Reference System

  • GPKG - GeoPackage

  • ER - Engineering Report

  • NMIS - NSG Metadata Implementation Specification

  • NSG - National System for Geospatial-Intelligence

  • OGC - Open Geospatial Consortium

  • SRS - Spatial Reference System

  • SWG - Standards Working Group

  • WKB - Well Known Binary

  • WKT - Well Known Text

5. Overview

This Testbed 12 ER begins with an evaluation of the NSG GeoPackage Profile dated 2016-09-02 (unless otherwise specified). The evaluation is broken into two parts. The first part evaluates the profile, while the second part evaluates the implications to the GeoPackage standard. Next, we will take a brief look into Vector Tiling and make recommendations on how the profile could apply to the Vector Tiling use case. Finally, we look at the viability of the profiling approach in general.

6. Evaluation

6.1. NSG GeoPackage Profile Analysis

6.1.1. Ad-Hoc File Names

Section 6.1 (File Names) of the NSG GeoPackage Profile[2016-07-01] provides guidance on how to name files so that ad-hoc naming conventions are avoided. Our evaluation suggests that the current section 6.1 does not provide adequate details and will most likely result in ad-hoc naming.

The sample pattern provided "{producer}{data product(acronym)}{geo area coverage (acronym)}{scale(s)}{version}_{date}" fails to indicate what each element should look like and will produce filenames that are difficult to read. For example, using the following values:

producer: CSLT
data product: CDRG
geo area coverage: CA
scales: 1-27
version: 1.0
date: 08-02-2016

This will produce the filename CSLTCDRGCA1-271.0_08-02-2016. As you can see, it is hard to distinguish between the elements. Therefore, providing specific convention rules is a better approach. For example, filenames should:

  • Use _ as the element delimiter.

  • Use - to delimit words within an element.

  • Abbreviations should be used when possible.

  • Elements should be ordered from general to specific detail of importance.

  • End with the extension .gpkg

  • Contain the following elements (if applicable):

    • Producer

    • Data Product

    • Geographic Coverage Area

    • Scale(s)

    • Version

      • Versions should start with V

      • Use - to distinguish between major and minor versions

    • Date or Date-Time

      • Dates should be YYYY-MM-DD.

      • Time should be HH-MM-SS.

A sample pattern could be:

{producer}_{data product}_{geographic coverage area}_{scale(s)}_{version}_{date}.gpkg

Using the values listed above, this will produce the filename CSLT_CDRG_CA_1-27_V1-0_2016-08-02.gpkg. This approach makes it easier to distinguish between the elements that comprise the file name.

6.1.2. Register All Tables

Section 6.2 (Extensions) of the NSG GeoPackage Profile[2016-09-02] indicates that any tables, which are not part of the GeoPackage standard, need to be registered in the gpkg_extensions table. This is a misuse of that table. The gpkg_extensions table is used to indicate that a particular extension applies to a GeoPackage and the standard details how to document these extensions. A GeoPackage may contain tables that are not intended to be part of an extension and can be safely ignored. Application providers commonly store application-specific data in their GeoPackages.

6.1.3. Coordinate Reference Systems Guidance

Section 7.1 (Coordinate Reference Systems) of the NSG GeoPackage Profile[2016-09-02] outlines what CRSs should be used for 2D/3D tiled data and 2D/3D vector data. The technical guidance sections provided in the annexes should indicate how to fill out the gpkg_tile_matrix table for each CRS. Additionally, some guidance on when to choose EPSG 3395 or EPSG 5041/EPSG 5042 would be useful. EPSG 3395 and EPSG 5041 overlap by > 20 degrees in the north and similarly EPSG 3395 and EPSG 5042 overlap by > 20 degrees in the south. Therefore it is not clear which CRS to choose in case of overlap, or if tiles should be generated for both overlapping CRSs.

6.1.4. OGC 12-063 Well Known Text

Section 7.2 (Well Known Text) of the NSG GeoPackage Profile[2016-09-02] specifies that OGC 12-063 Well Known Text representation of Coordinate Reference Systems shall be used for the definition column in the gpkg_spatial_ref_sys table. This requirement will break support for any clients that are currently following version 1.0 or 1.1 of the GeoPackage standard and expect to find OpenGIS 01-009 Well Known Text.

We recommend that the OGC GeoPackagage Encoding Standard 1.1 Registered Extension F.10 (WKT for Coordinate Reference Systems) be used. This extension adds an additional column "definition_12_063" that contains the new OGC 12-063 WKT representation, while still providing an OpenGIS 01-009 WKT representation in the original "definition" column when possible. This extension is a temporary measure that will allow the use of the new WKT representation while maintaining compatibility with existing client implementations. This extension will be removed in the next major version of the GeoPackage standard because the definition column will be updated to support the current version of the WKT specification.

6.1.5. Metadata

Table 20 in Section 7.3 (Metadata) of the NSG GeoPackage Profile[2016-09-02] indicates that the gpkg_metadata table requires an entry with an id of 1. This entry is the NSG Metadata Implementation Specification (NMIS) v2.2 metadata document that is associated with the complete GeoPackage. GeoPackage creators may already be populating metadata into the gpkg_metadata table. This forces them to use the id 1 which is an unnecessary complication. The id can be determined by using a query that joins the gpkg_metadata and gpkg_metadata_reference tables on id where the reference_scope is 'geopackage' and the md_standard_uri is ''. The restrictions on any additional NMIS metadata entry ids should also be relaxed. This change would also require rewording of data validity constraints 18 - 29 in the profile. Additionally there should be data validity constraints added to deal with the case of adding NMIS metadata that describes particular tables or table row, column or row/column values.

In accordance with Table 20 the column "md_scope" should have a value of 'series' or 'dataset'. A similar restriction can be found in Table 22 and Table 25. It is not clear when one value should be selected over the other.

Providing a sample minimal NMIS v2.2 metadata xml in the Annex section would be beneficial. The profile does a good job of explaining what elements / values are required in the metadata specifically related to GeoPackage. However for someone unfamiliar with NMIS metadata it could be difficult to understand what elements and values are required in general.

6.1.6. Data Validity Constraints

In the NSG GeoPackage Profile[2016-07-01] and in accordance with Table 26 ID# 13 and ID# 18, the zoom_level needs to be > 0. We are unclear if this is a typo or intentional. The GeoPackage standard states that zoom_level shall be >= 0. In Annex C, table 30 of the profile, the Zoom Level starts at 0 while in Annex D, table 34 the Zoom Level starts at 1.

In the NSG GeoPackage Profile[2016-07-01] and in accordance with Table 26 ID# 13 and ID# 18, the zoom_level needs to be <= 27. The GeoPackage standard states that zoom_level shall be <= max_level. Our recommendation is to follow the standard and not to cap the possible precision of the data.

6.2. OGC GeoPackage Specification Implications

6.2.1. Remove Extended GeoPackage File Extension Recommendation

According to OGC GeoPackage Requirement 3, a GeoPackage SHALL have the file extension name ".gpkg". However the standard then RECOMMENDs that Extended GeoPackages use the file extension “.gpkx” but this is NOT a GeoPackage requirement.

Inline with NSG Requirement 1, which states that the ".gpkx" file extension SHALL NOT be used to indicate an Extended GeoPackage, we recommend the removal of the .gpkx file extension from the standard for the following reasons:

  • The OGC GeoPackage standard outlines in great detail the extension mechanism. In order for an application to determine what extensions are currently available, the application must open the GeoPackage and query the gpkg_extensions table. It is likely that an application that supports no extensions can still access the GeoPackage without issue, especially if the application accesses a GeoPackage in a read-only fashion and the gpkg_extensions.scope column indicates a value of “write_only”. The presence of the ".gpkx" extension provides no real value. Applications still need to open the GeoPackage to determine if the extensions impose any additional requirements on accessing the data and therefore the ".gpkx" extension serves no purpose.

  • Applications will need to recognize two separate file extensions. There is a distinct possibility that application developers will only support the mandatory ".gpkg" file extension.

6.2.2. Bounding Boxes

Inline with NSG Requirement 24, which states "The (min_x, max_x, min_y, max_y) values in the gpkg_tile_matrix_set table SHALL be the maximum bounds of the CRS specified for the tile pyramid data table and SHALL be used to determine the geographic position of each tile in the tile pyramid data table", we recommend a new requirement in the GeoPackage standard that states the same. Currently we have the following descriptive text "The maximum bounding box (min_x, min_y, max_x, max_y) for all possible tiles in a tile pyramid user data table. All tiles present in the tile pyramid SHALL fall within this bounding box. However, the bounding box MAY be larger than the minimum bounding rectangle around the actual tiles in that pyramid." The issue with this text is that it is not a requirement and it is open to interpretation. For example, a GeoPackage creator may create a GeoPackage containing one tile with no intention of adding any other tiles, and index it as follows:


If a second creator were to take this GeoPackage and try to add another tile to it, they may have to re-index the entire GeoPackage as follows:


The specification requirements should be modified to avoid the potential of having to reindex tiles. If we follow the wording of NSG Req 24, the first creator would have created and indexed the GeoPackage as follows:


If a second creator were to take this GeoPackage and add another tile to it, they would no longer be required to re-index the tiled data:


6.2.3. Remove Minimal Set Of Rows From gpkg_spatial_ref_sys Table

Requirement 11 in the GeoPackage standard provides a minimal listing of rows that shall be contained in the gpkg_spatial_ref_sys table. These rows may not be necessary for the content of the GeoPackage and should therefore not be required. The rows cause issues for possible profiles of the GeoPackage standard because these profiles may restrict the allowed CRSs, this restriction may not include EPSG:4326. Furthermore, since the allowed CRSs are defined, the value of srs_id of -1 for undefined Cartesian coordinate reference systems and the srs_id of 0 for undefined geographic coordinate reference systems will never be required. We recommend updating this requirement so that the gpkg_spatial_ref_sys table MAY contain these entries.

Inline with NSG Requirement 27, which states that the User-Defined Geometry Types Extension SHALL NOT be implemented, we suggest that this Extension be removed from the standard for the following reasons:

  • The geometry encoding is not specified in the extension and therefore a supplemental document explaining the encoding would be required. In the absence of this document, there is no way for an application developer to support this extension and therefore the extension is not interoperable.

  • Multiple developers could implement the encoding of a new, but similar geometry type such as EllipticalCurve in different ways.

  • Existing spatial functions will not work with the new geometry types and could potentially cause errors or skip data if used.

The extensions for Geometry Type Triggers and Geometry SRS ID Triggers should also be removed from the standard, as they directly relate to User-Defined Geometry Types Extension and will no longer be required.

The content contained in this extension and the related extensions would be better suited in an OGC Best Practice document. This document could outline how to create a complete and interoperable User Defined Geometry Type Extension, which also contains the geometry encoding and deals with the issues of existing spatial functions. This would allow two independent developers to create User-Defined Geometry Type extensions that follow the same template and make it easier for clients of the extensions to adopt and be interoperable.

6.2.5. GeoPackage Non-Linear Geometry Types

The Non-Linear Geometry Types extension is similar to the User-Defined Geometry Types extension mentioned above, with one major exception. The extended non-linear geometry types are already defined in OGC Well Known Binary (WKB), therefore a supplemental document is not required to detail the geometry encoding. We see no reason to remove this extension from the standard. However we do recommend dropping GeoPackage Requirement 69.

Complying with Requirement 69 is almost impossible. The requirement states "SQL functions that operate on GeoPackageBinary geometries as specified in other extensions SHALL operate correctly on the non-linear geometries specified in this extension". Implementation of this requirement is almost impossible because the functions could have been loaded via an extension such as SpatiaLite, which cannot be changed and does not support the non-linear geometries. The removal of this requirement will allow for interoperable storage and retrieval of the geometries, while not requiring but allowing existing functions to work with the geometries.

7. Vector Tiling

Vector tiling was developed to be the equivalent of image tiling but for vector data. Vector Tiling has the benefits of tiling, such as caching, scalability and quick retrieval while maintaining the benefits of vector data; the ability to perform analysis, editing and styling of the features directly in the client. The purpose of this section is not to dive too deeply into the details of vector tiling. For OGC Vector Tiling recommendation details please read the OGC Vector Tiling Engineering Report[16-068]. This ER discusses what vector tiling is and how it can be approached. Additionally the OGC Vector Tiling Implementation Engineering Report[16-067] details a prototype implementation of vector tiles in an OGC GeoPackage. This section will outline the suggested changes to the NSG GeoPackage Profile required to support vector tiling.

7.1. Tiles, Features and Vector Tiles

7.1.1. Coordinate Reference Systems

Section 7.1 (Coordinate Reference Systems) of the NSG GeoPackage Profile[2016-09-02] will require minor updates to state that Table 6: Vector Feature Coordinate Reference Systems also be used for Vector Tiles.

7.1.2. Well Known Text

Section 7.2 (Well Known Text) of the NSG GeoPackage Profile[2016-09-02] will not require any changes as no CRSs were added in section 7.1.

7.1.3. Metadata

Section 7.3 (Metadata) of the NSG GeoPackage Profile[2016-09-02] will not require any changes.

7.1.4. Data Validity Constraints

Table 26 in Section 7.4 (Data Validity Constraints) of the NSG GeoPackage Profile[2016-09-02] will require the following changes:

Table 2. Modified Data Validity Constraints
ID Value Constraint Modification


"data_type" column should now allow "features", "tiles" or "vectortiles".


"tiles" and "vectortiles" should follow the same rule.


"tiles" and "vectortiles" should follow the same rule.


"tiles" and "vectortiles" should follow the same rule.


"tiles" and "vectortiles" should follow the same rule.

7.2. Vector Tiles

A new section in the profile will be required for Vector Tiles to specify any NSG Requirements as they relate to the chosen implementation and chosen vector tile format. We recommend that the approach outlined in OGC Vector Tiling Implementation Engineering Report[16-067] be used to support vector tiling in GeoPackage. The approach outlined in the ER would require minimal change as it just reuses the Tiles tables. More research will probably be required before a specific vector tile format is chosen. However the OGC Vector Tiling Engineering Report[16-068] does outline several different options.

8. Viability

Profiles are essentially a restricted subset of a base standard. Where applicable a profile identifies clauses, classes, options and parameters of that base standard and provide rationale for these selections. A well written profile will ensure that any implementations written against the profile will also be compatible with the base standard. Difficulty with ensuring compatibility with the base standard will almost always result in changes being required in the base standard. As an example, the difficulty for the NSG GeoPackage Profile to use OGC Well Known Text[12-063] resulted in the WKT for Coordinate Reference Systems extension being added to the base GeoPackage standard. Furthermore, reviewing the restrictions and detailed directions on how to use the clauses, classes, options and parameters of the base standard will often result in improvements to the base standard. For example, many of the recommendations for changes to the GeoPackage standard in this document were the result of exactly this type of review.

The NSG GeoPackage Profile is a good example of the viability of the profiling approach. The guidance in the profile is specific enough to make it easier for two independent and compliant software implementations to 'plug and play' with each other. The profile creates GeoPackages, which remain compatible with the base standard. Finally, the profile identified and helped address some deficiencies in the base standard.

9. Recommendations

The following section summarizes and classifies the recommendations from the evaluation section. Due to the synergy between the OGC Innovation Program and Standards Program, the draft versions of this document influenced both the NSG GeoPackage Profile and the GeoPackage SWG before the document became final. The pending recommendations represent the items from this document that have not been addressed, while the accepted recommendations are those that have already been applied to the GeoPackage Standard or the NSG GeoPackage Profile. This classification is valid for the date of the last revision of this document.

9.1. Pending Recommendations

  • Recommendations for the NSG GeoPackage Profile dated 2016-09-02

    • Do not require tables that are not part of the core specification to be registered in the gpkg_extensions table. Register All Tables

    • More guidance required regarding how to fill out the gpkg_tile_matrix table for each CRS, as well as when to choose EPSG 3395 or EPSG 5041/EPSG 5042. Coordinate Reference Systems Guidance

    • The WKT for Coordinate Reference Systems extension specified in the OGC GeoPackage Encoding Standard 1.1 should be used to specify OGC 12-063 WKT. OGC 12-063 Well Known Text

    • Do not require a NMIS v2.2 metadata entry with an id of 1. Metadata

    • Provide clarification on when to use 'series' or 'dataset' in Metadata. Metadata

    • Provide a minimal NMIS v2.2 metadata xml in the Annex. Metadata

  • Recommendations for OGC 12-128r12, OGC GeoPackage Encoding Standard 1.1 (2015-08-04)

9.2. Accepted Recommendations

Appendix A: Revision History

Table 3. Revision History
Date Release Editor Primary clauses modified Descriptions

April 15, 2016


C. Clark



September 30, 2016


C. Clark


Draft ER

October 31, 2016


C. Clark


Draft ER

Appendix B: Bibliography

[1] OGC,: OGC Testbed 12 Demonstration. (2016).