Report of OGC meeting in Louvain

[Martin Desruisseaux <ma...@geomatys.com>]

Hello all

An Open Geospatial Consortium (OGC) meeting was held last week in Leuven
(Belgium). A consolidated set of Closing Plenary slides (325 slides) is
available at [1]. Below are my personal notes, covering only a small
fraction of the meetings.


    OGC web API

OGC communicates a lot about API recently, but this is actually web API
(based on REST), not Java/C++/Python API. In this email, I will use the
term "web API" for what OGC calls "API". Some news are:

  * An OGC hackathon was held in London in June 20-21 to advance the
    development of OGC web API specifications.
  * A "whether on the web" API is under progress.
  * An OGC web API catalogues working group is created. The current
    catalog specification uses legacy web protocols. The goal is to
    propose a specification for end of 2020.

We also had a face-to-face meeting between OGC and W3C during two days.
The meeting minutes are published at [2].

On a related note, OGC will migrate from GitHub to GitLab because of the
cost of private repositories. Public repositories will stay on GitHub.


    Marine Limits and Boundaries

The French National Institute of Geographic Information (IGN) has
published a list of standards and formats to be legally enforced in the
French administration ([3] - in French). This list include the status
(recommended, retired, etc.), levels (technical, semantic, etc.),
categories (transport, service, etc.). This document is a collection of
metadata about standards. Some information hard to get that are provided
by this document are relationship between standards (profiles,
implementations), differences between versions, classification of the
standard (format, protocol) etc.

The maritime domain has some specific standards defined by the
International Hydrographic Organization (IHO). The above-cited list of
standards will be updated for covering them. Another work under
consideration - pending volunteer availability - is an upgrade of the
Geopackage format in order to store vector data defined by IHO S-100
standard. This work can be experimented on GitHub [4]. We note that IHO
S-100 has multiple parts (model, encoding, registered, definitions and
conventions) and harmonizing S-100 with OGC standards would be a large work.

Vector tiling for IHO S-57 data are considered. Vector tiling are small
sections of geospatial data cut into roughly square objects. Currently
they are used mostly in web mapping but use cases are slowly widening.
Some advantages are: small size of data transferred, separation of
styling from source data, allows interaction with underlying data,
possible to combine multiple scales of data into one feed and let
rendering solution decide what to display. The most common specification
is MapBox PBF, which may be officially adopted by OGC.


    Emergency and disaster

Since 1980 in USA, disasters have cost $1.6 trillion and almost half of
those losses came during the four most expensive years: 2017, 2005, 2012
and 2018. OGC is doing a pilot program to demonstrate how data standards
help decision makers gain perspectives into social, economic, and
environmental issues related to disasters. One issue is that some users
are overloaded with data (too much information) during disasters.

United Nations Committe of Experts on Global Geospatial Information
Management (UNGGIM) aims to be a body for global policymaking in the
field of geospatial information management. It includes participation of
OGC, ISO and IHO. There work includes input from the "Sendai framework
for risk reduction (2015 - 2030)" and others. They published a "Guide to
the Role of Geospatial Standards" [5].


    Earth observation (EO)

In a previous report of OGC meeting, I reported the OpenEO effort for
building a non-web API (e.g. a Python API) for accessing geospatial data
on the cloud. OpenEO has the same goals than GeoAPI (the OGC interfaces
implemented by Apache SIS). In this meeting, other efforts with
apparently similar goals have been presented: EO Exploitation Platform
Common Architecture (EOEPCA), which provide (among others) programmatic
interfaces. They define a data access protocol as a layer of abstraction
between various data formats and the processing framework (an approach
similar to org.apache.sis.storage.DataStore class for example). The
application can be packaged as a docker image, but not necessarily.
Their approach is inspired by Google Earth Engine, ArcGIS and openEO.

Another apparently similar project is EOPEN, a platform for big data
processing and analytics using multiple sources of data and multiple
processing resources. They provide an automated service builder
framework for designing workflows graphically in order to reduce the
time and effort to create processing facilities.

On the more general topic of Observation and Measurement, the revision
of ISO 19156 standard (also OGC abstract specification 20) is making
progress in incorporating the comments received from call for comments.
An example of comment is a request to make the sampling strategy
explicit in the model. The model is also receiving technical revisions
based on implementation experiences. As with many OGC/ISO standards,
there will be an abstract model and one or many encoding based on the
abstract model. The encoding can be GML (Geographic Markup Language) or
JSON for example, but the current proposal is to start with GML. The
revision is still open for change requests, with a cut-off date before
next OGC meeting in September.


    Geospatial Data Cube community practice

A "Geospatial Data Cube Community Practice" paper is being drafted and
will go to public request for comments. From the abstract, "Data cubes
for geospatial information provide the means to integrate observations
and other types of geospatial data for use in multiple applications
through simplified access and efficient analytics. This Community Best
Practice defines requirements for a Core Geospatial data cube
infrastructure and guidelines for enhancements to the basic." The
document gives a series of requirements for data cubes, for example:

  * A Geospatial Data Cube shall provide metadata for the user that
    defines the provenance of all source data, data preparation methods
    applied and data structure of the cube.  Where applicable the
    metadata shall be defined in accordance with ISO 19115.
  * A Geospatial Data Cube shall support analytics on all domain axes
    alike, irrespective of spatial or temporal nature of the dimension.
  * A Geospatial Data Cube shall allow efficient trimming and slicing
    along any number of axes from a data cube in a single request by the
    user.
  * A Geospatial Data Cube shall not allow requests that require
    excessive resources.
  * A Geospatial Data Cube service interface for data access shall be
    compliant with OGC Web Coverage Service (WCS).

There is also a discussion about direct access to files through
libraries such as GDAL. During the meeting we had a discussion about
executing code using file access mode (instead of WCS) on a distant
server using Jupyter console. With technologies like Jupyter, users do
not need to send a Docker image (for example) in order to execute custom
code on a remote server. Not all OGC members are aware of this way of
working, and current draft does not mentions it. We may expand the draft
with a new chapter for covering this case.


    GeoAI (Artificial Intelligence)

This is a new working group created at OGC. An example of use case is
"map matching": place GPS (or other device) position at their "right"
location in a model (street map, indoor map, etc). The challenge is that
devices may not be accurate enough and report a position way outside the
street or room. An artificial intelligence can use the trajectory data
for guessing better. Another use case come from Taiwan: using images
from cameras showing cars passing during heavy rain periods, an
artificial intelligence can estimate the level of water in a street by
observing the car tires and raises alert when the street should be closed.

The group had a discussion about streaming content recognition, i.e.
turning video into structured information for easier further analysis. A
test bed is ongoing using TensorFlow.


    Moving features

A public GitHub repository has been created for publishing examples
(data and code) [6]. Its currently contains small example file in CSV
encoding. Since Apache SIS can read those files, we could add a code
example there.

The netCDF encoding (a "best practice" paper) has been published [7].
This paper is not a standard since it contains nothing new; it merely
summarizes key elements from existing CF-conventions for encoding moving
features in a netCDF file.

The JSON encoding specification, which currently has the "best practice"
status, is in the process of being upgraded to the "OGC standard"
status. The draft is available at [8]. Note that this encoding
specification actually contains material not found in other moving
features specifications ("core", XML, CSV, netCDF), for example for
specifying interpolations.


    GeoTIFF

GeoTIFF 1.1 [10] public review process is completed and the document is
in the process of being submitted as an OGC standard. Compared to the
current GeoTIFF 1.0 specification (defined outside OGC), GeoTIFF 1.1
cleanups the annexes citing EPSG codes (some tables in previous
specification are wrong, especially regarding vertical CRS). The GDAL
project has a set of small files (~300 bytes) in GeoTIFF 1.1 format that
may be used for testing [11].

An official MIME type is proposed for registration to IANA. The current
proposal is image/tiff;application=geotiff (pending approbation).


    Coordinate Reference System (CRS)

ISO 19111:2019 (the abstract model) has been published in January or
February this year. This standard is also published as an OGC document
[9]. The PROJ library (version 6) completed their upgrade to this new
standard, which is a major upgrade given that their previous API was
following a very different model. The new PROJ version does not require
anymore the use of WGS84 as a pivot system. As an example of the need to
remove pivot system requirement ("early binding") in implementations, it
has been pointed during the meeting that WGS84 has an accuracy of 5
meters at best in Chile. GeoAPI and Apache SIS are still implementing
the previous ISO 19111:2007 model. But since that model was already
avoiding the pivot system issue, the work needed for upgrading those
libraries is smaller. The Well Known Text representation is defined in a
separated standard (ISO 19162:2019) to be published soon. The status of
ISO 19162 in PROJ/Apache SIS is the same than for ISO 19111.

The structure of EPSG database will get some modifications to
accommodate the new standard. The new EPSG database will be expanded
with new elements from ISO 19111:2019 (dynamic datum, point motion
operations, geoid-based CRS, etc.) except parametric CRS (e.g. vertical
measurements based on pressure) and temporal CRS. The reason is that
EPSG committee chooses to limit its scope to topics that they master
well. A related discussion happened regarding PROJ plan to include
definitions from other sources like the international astronomical
union. Given that implementation of map projection formulas designed for
Earth may not work for celestial bodies with high eccentricity, would it
be safe to have open source projects incorporate definitions of CRS that
they can not handle accurately? My personal opinion is that, because of
PROJ popularity, there is a risk that PROJ results are interpreted as
authoritative by a majority of users, while actually a close examination
of accuracy implication may not have been conducted. In Apache SIS, we
found that map projection formulas based on series expansions loose
their centimetric accuracy when the eccentricity exceed 0.10 ~ 0.16
(depending on the formulas). For comparison, WGS84 eccentricity is about
0.082.


    Varia

  * A new Portrayal working group has been approved in May. Portrayal is
    part of the rendering process for showing a map on screen. The group
    aims to define a framework to address 2D, 3D and n-dimensional
    portray. New 3D symbology encodings are proposed, introducing new
    symbolisers and rendering mechanisms like SurfaceSymbolizer.
  * OGC conducts many "test beds", but we had a discussion about Test
    Bed results being interpreted as solutions by peoples outsides OGC,
    while actually they are only experiments.
  * Web Coverage Service specification has been affected by a change of
    axis abbreviations in the EPSG database (some argue that is was an
    incompatible change, but my personal opinion is that it was rather
    an error in the Web Coverage standard to rely on abbreviations).
    This has been fixed by relying on axis order instead, which is a
    more reliable approach provided that implementations obey to axis
    order declared in EPSG database.
  * Web Feature Services add a default CRS (outside EPSG namespace) for
    three-dimension coordinates with (longitude, latitude, height) axis
    order.
  * A discussion about managing changes in a widely implemented legacy
    standard is open at [12].

Martin

[ 1] https://portal.opengeospatial.org/files/?artifact_id=84732
[ 2] https://www.w3.org/2017/sdwig/meetings/f2f-4.html
[ 3] http://references.modernisation.gouv.fr/sites/default/files/Referentiel_General_Interoperabilite_V2.pdf
[ 4] https://github.com/kusala9/mGpkg
[ 5] http://ggim.un.org/meetings/GGIM-committee/8th-Session/documents/Standards_Guide_2018.pdf
[ 6] https://github.com/opengeospatial/movingfeatures
[ 7] http://docs.opengeospatial.org/bp/16-114r3/16-114r3.html
[ 8] https://ksookim.github.io/mf-json/
[ 9] http://docs.opengeospatial.org/as/18-005r4/18-005r4.html
[10] https://portal.opengeospatial.org/files/83583
[11] https://github.com/OSGeo/gdal/commit/509383e3139e7e47f561b673b92593660bdb0d52
[12] https://github.com/ogcscotts/TC-Meeting-topics/issues/99