1. Encoding Standard

1.1. 1.2.1

1.3. Unfiled

  • ❏ [Open tickets](https://github.com/opengeospatial/geopackage/issues)

  • ❏ Tile Matrix Set - waiting for further movement from OGC. The OAB approved releasing a draft standard for an open comment period but the commencement of this period was delayed.

  • ❏ Requirements Classes - this would provide consistency with other standards and make capabilities and requirements easier to organize.

  • ❏ Versioning of extensions. There is not currently a clear way to update extensions and maintain reverse compatibility. The SWG took a look at this issue and decided to delay action, but the time may come where further action is necessary.

1.4. Tiled Gridded Coverage Extension

This was released as a [separate document](http://docs.opengeospatial.org/is/17-066r1/17-066r1.html) so that it could be maintained separately. There are no plans to produce another version but this could change. * [x] [Update the names of the tests in the ATS (change "elevation" to "coverage")](https://github.com/opengeospatial/geopackage-tiled-gridded-coverage/issues/43)

1.6. Standards Revision Process

The process has been working well. We have been able to produce new revisions of the standard roughly every year. Individual changes are managed through [Github Issues](https://github.com/opengeospatial/geopackage/issues) and [pull requests](https://github.com/opengeospatial/geopackage/pulls). The process for creating a new GeoPackage revision is as follows:

  1. Create a release notes document.

    1. Reserve an [OGC document number](https://portal.opengeospatial.org/?m=public&subtab=request&tab=1)

    2. Create a GitHub repository by duplicating an existing repository (e.g., https://github.com/jyutzler/ogc18-024)

  2. Make one or more changes.

    1. Open a GitHub issue.

    2. Commit the GitHub pull request. This causes the [working version](http://www.geopackage.org/spec/) of the standard to be updated.

    3. Create a release notes entry. Administrative changes get a line in a table. Substantive changes get a more detailed description.

  3. When the SWG is satisfied that there are enough contents for a change, the SWG moves to approve the release. After that, do the following:

    1. Mark a [GitHub release](https://github.com/opengeospatial/geopackage/releases)

    2. Produce a revision system notes is created

  4. OGC approves the revision. For corrigenda, this is basically a rubber-stamp process by the TC. For a minor release, the process is more detailed.

    1. OAB Review

    2. Public Comment Period

    3. Adjudication of public comments

    4. TC vote

1.7. GitHub Pipeline

We have a pipeline to manage our [GitHub content](https://github.com/opengeospatial/geopackage).

  • ✓ The gh-pages branch gets published to geopackage.org.

  • ✓ The pipeline will automatically convert any Markdown to HTML.

  • ✓ Every time a change is made to the master branch, the pipeline generates spec/index.html on the gh-pages branch from the contents of the spec directory on the master branch.

  • ❏ Migration to AsciiDoc will allow us to improve the presentation of the various geopackage.org pages. Does the pipeline automatically convert AsciiDoc to HTML like it does with Markdown? Does AsciiDoc support inline checkboxes on bullets?

2. Outreach and Education

Like any other capability, GeoPackage requires outreach so that members of the geospatial community understand the format and how it can be used as an enabling technology for challenges they are trying to meet. Some ways that we perform outreach include the following: * http://geopackage.org * Social media * Public appearances * Public articles

2.1. Data

We want people to be able to find relevant data in the GeoPackage format quickly and easily. We are not seeing as much public data published in the GeoPackage format as we would like.

2.2. Implementations

The [implementations page](http://www.geopackage.org/implementations.html) provides a curated list of organizations that have indicated GeoPackage support. (This is completely different from the [OGC-maintained list](http://www.opengeospatial.org/resource/products/stats).) There is still more work to be done to indoctrinate GPKG as a solution. * [ ] [ATAK](https://atakmap.com/) * [ ] others

2.3. Guidance

Guidance informs potential users of the format, making it easier to use it appropriately and with as little unnecessary effort as possible. This area will continue to evolve. It is difficult to get people to write useful documentation but we will use whatever we can get.

2.4. Online Standard

We want users to be able to find and use the standard as quickly and easily as possible. People appear to be happy with what we have here.

2.5. Blog Postings

I occasionally post articles on http://geopackage.blogspot.com. These tend to be more process and management-based than technical.

3. Verification and Validation

3.1. Executable Test Suite (ETS)

This is software that allows the user to load a GeoPackage and receive a report on any standard compliance issues. It is currently built on top of the OGC TEAM Engine.

3.1.1. Adoption

Currently the ETS is in beta. We would like it to become official so that we can maintain proper lists of compliant software implementations. * [x] GitHub * [x] [Beta Site](http://cite.opengeospatial.org/te2/about/gpkg12/1.2/site/) * [ ] Three implementations * [x] Esri * [x] NGA/BITS * [ ] ??? * [ ] OGC approval

3.1.2. Maintenance

3.2. Interoperability Suite

This is software that allows the user to load a GeoPackage. It will report both standard compliance issues and interoperability issues that fall outside of what can be governed by the standard. We do not currently have an advocate for this activity.

3.3. Implementations list

OGC maintains a list of [registered implementations](http://www.opengeospatial.org/resource/products/compliant). These can be self-selected, but organizations who have gone through the full certification process are identified appropriately.

3.4. Interoperability Tests

This section describes activities where representatives of software development teams get together and attempt to prove the interoperability of their software with files produced by other groups.

3.4.1. [Geospatial to the Edge Plugfest](http://www.opengeospatial.org/projects/initiatives/geoedgeplugfest)

This activity is focused primarily on National System for GEOINT (NSG) profiles but it also addresses some infrequently explored parts of the standard.

4. Future Capabilities

4.2. OWS Context

Image Matters has indicated interest in this. It would allow Context files to be stored in GeoPackages. A context can represent a single common operational picture. This would allow for a separation of GeoPackage data and its presentation. * [x] Proof of concept * [x] [Discussion Paper](http://docs.opengeospatial.org/dp/18-037r1/18-037r1.html) * [ ] Dependency on updated portrayal standards (style encoding) * [x] Community Extension * [ ] Interoperability Experiment or other test activity * [ ] Draft Standard

4.3. Tiled Vector Data

Through the [Vector Tiles Pilot](http://www.opengeospatial.org/projects/initiatives/vt-pilot-2018), OGC is developing interoperable solutions for tiled vector data. There are five (small) proposed extensions as part of this effort: 1. Vector Tiles 1. Mapbox Vector Tiles 1. GeoJSON Vector Tiles 1. OWS Context (see above) 1. Vector Tiles Attributes (extends Related Tables Extension)

  • GeoPackage Vector Tiles Extensions Engineering Report

  • ✓ Draft posted to pending

  • ❏ TC adoption

  • ❏ OGC Publication

  • Vector Tiles Pilot (focusing on portrayal)

  • ❏ Consensus development

  • ❏ Draft ER posted to pending

  • ❏ TC ER adoption

  • ❏ OGC ER Publication

  • Next steps?

4.4. 3D Tiles

Compusult has indicated interest in an extension based on 3D Tiles, which is now an [OGC Community Extension](https://portal.opengeospatial.org/files/?artifact_id=79136). It should be fairly straightforward to implement this in GeoPackage, although SWG members may have differing points of view on implementation details. * [x] Proof of concept * [x] Presentation to GPKG SWG * [x] [Community Extension](http://www.compusult.net/html/OGC/3DTile_GeoPackage_Ext_Draft.html) * [ ] Interoperability Experiment * [ ] Draft Standard

4.5. Multi-resolution vector data

Compusult has presented this idea, but it is unclear whether there is any need to standardize it. Maybe a community extension and/or article will be sufficient? * [x] Proof of concept * [x] Presentation to GPKG SWG * [ ] Community Extension * [ ] Interoperability Experiment * [ ] Draft Standard

4.6. Concepts with no advocate

  • styling / symbology (does this now fall under OWS Context?)

  • point clouds (this may come for free with 3D tiles)

  • non-SQLite implementations

  • compression

  • synchronization / replication

  • 4D / augmented reality