Skip to content

GeoPackage Strategic Assessment

Jump to bottom Edit New page
Jeff Yutzler edited this page May 28, 2019 · 14 revisions

This document identifies GeoPackage-related capabilities, how well we are doing at achieving those capabilities, and what activities will help us attain them. Ideally this document will help us to identify the highest priority items for future investment. We intend to maintain the document continuously so that it will continue to remain relevant.

Encoding Standard

Generally believed to be in good shape, but regular maintenance continues to be needed.

1.2.1

  • GitHub Version
  • Release Notes
  • SWG Motion
  • TC Vote
  • Publication
  • Press release - none was issued

1.2.2?

Unfiled

  • Open tickets
  • 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.

Tiled Gridded Coverage Extension

This was released as a separate document so that it could be maintained separately. There are no plans to produce another version but this could change.

Related Tables Extension

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 and pull requests. The process for creating a new GeoPackage revision is as follows:

  1. Create a release notes document.
    1. Reserve an OGC document number
    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 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
    2. Produce a revision notes document
  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
  5. OGC publishes the revision
    1. Publication with new "R"
    2. Associated release notes

Extension Adoption Process

  1. Produce a draft standard
  2. SWG motion to recommend to the OAB for public comment
  3. OAB review
  4. Public comment period
  5. Comment adjudication
  6. TC presentation and vote
  7. PC/Board of Directors approval
  8. Publication
  9. Press release

GitHub Pipeline

We have a pipeline to manage our GitHub content.

  • 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?

Outreach

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:

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.

  • data page - currently very sparse
    • New Zealand
    • Minnesota - currently 423 datasets, but a fairly primitive search interface
    • Australian Bureau of Statistics
    • Energydata.info
    • Ordnance Survey
    • NRL
    • http://geoplatform.gov has not prioritized GeoPackage support
  • Social Media - minimal impact so far
  • TC Plenary announcement
  • OGC Meeting Topic
  • Others?

Implementations

The implementations page provides a curated list of organizations that have indicated GeoPackage support. (This is completely different from the OGC-maintained list.) There is still more work to be done to indoctrinate GPKG as a solution.

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.

  • getting started guide - where new developers should look to understand how GeoPackages are organized. This guide now includes information for the core and all adopted extensions. It is getting positive feedback.
  • Community Extensions - this page contains a curated list of all known community extensions
  • Implementation Guide - this page catalogs a taxonomy of GeoPackage capabilities and indicates a set of capability levels for each capability, along with samples aligned to each capability level. This is a relatively new idea and it remains to be seen whether we have the right approach or not.
  • Howto Guide - how to produce certain samples. Is it possible to do this in a way that is vendor agnostic? Maybe the SWG should not be responsible for publishing this.
    • SHP -> GPKG
    • WMS -> GPKG
    • tile pyramid -> GPKG
    • others?
  • Articles for poorly understood extensions
  • Guidance page containing articles for frequently asked questions and non-obvious solutions. Maybe we should also curate a list of public articles. We are starting to see more articles published publicly.
    • Data Modeling
    • Views - we were recently asked about this and we should try to turn something around as quickly as possible

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.

Blog Postings

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

Verification and Validation

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 and is available on OGC's CITE page.

Maintenance

  • GitHub
  • Better reporting
    • Clearer output report
    • Version of file
    • Warnings
  • Integration with Simple Features test
  • Acquire additional samples (ongoing)

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.

Implementations list

OGC maintains a list of registered implementations. These can be self-selected, but organizations who have gone through the full certification process are identified appropriately.

OGC Innovation Program Activities

Future Capabilities

Tiled Vector Data

Through the Vector Tiles Pilot, OGC is developing interoperable solutions for tiled vector data. There are four (small) proposed extensions as part of this effort:

  1. Vector Tiles
  2. Mapbox Vector Tiles
  3. GeoJSON Vector Tiles
  4. Vector Tiles Attributes (extends Related Tables Extension)

There could also be a tie to the OWS Context and Styles extensions (see below).

Activities

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.

  • Proof of concept
  • Discussion Paper
  • Dependency on updated portrayal standards (style encoding)
  • Community Extension
  • Interoperability Experiment or other test activity
  • Draft Standard

Styles Extension

This was discussed during the Vector Tiles Pilot and Vector Tiles Pilot Extension and will be discussed further during the Open Portrayal Framework thread of Testbed 15.

3D Tiles

Compusult has indicated interest in an extension based on 3D Tiles, which is now an OGC Community Extension. It should be fairly straightforward to implement this in GeoPackage, although SWG members may have differing points of view on implementation details.

  • Proof of concept
  • Presentation to GPKG SWG
  • Community Extension
  • Interoperability Experiment
  • Draft Standard

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?

  • Proof of concept
  • Presentation to GPKG SWG
  • Community Extension
  • Interoperability Experiment
  • Draft Standard

Concepts with no advocate

  • point clouds (this may come for free with 3D tiles)
  • non-SQLite implementations
  • compression
  • synchronization / replication
  • 4D / augmented reality
  • application profile
Add a custom footer
Add a custom sidebar
Clone this wiki locally