Report from December OGC meeting

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

Hello all

An OGC meeting happened in Taiwan about 2 weeks ago, with about 80
attendees. Below is a summary of some points discussed during the
meeting. I cover only a few points for which I'm more familiar; much
more are discussed during OGC meetings. As usual, this email reflects
only my understanding and may contain errors.


    GeoAPI

GeoAPI 3.0.1 has been voted by lazy consensus (i.e. we asked if they
were any objection and waited a few weeks). OGC will release this update
after OGC staff have verified that it qualifies as a bug fix release.
The purpose of this release is to replace JSR-275 dependency by JSR-363
(Unit of Measurement API). For Java developpers, their
"javax.measure.unit.Unit" import statements will need to be changed to
"javax.measure.Unit". Strictly speaking this is an incompatible change,
but this change come from a GeoAPI dependency rather than GeoAPI itself.
Furthermore we do not have much choice since we are not supposed to use
JSR-275 anymore.

Apache SIS 0.3 to 0.7 implements GeoAPI 3.0.0 (with the legacy JSR-275
dependency). Support for GeoAPI 3.0.1 is target for Apache SIS 0.8. Note
that GeoAPI 3.0.1 will not contain any new API. In particular all the
work done on the GeoAPI 3.1 and 4.0 branches will continue to wait for
future discussion.

More generally, the OGC discussion paper about API (not just GeoAPI;
that discussion paper focuses more on REST API) is now public for comments:

https://github.com/opengeospatial/api_whitepaper


    Metadata

ISO 19115-3:2016 (the XML representation of the metadata model behind
GeoAPI and Apache SIS) has been published in August this year [1]. For
Apache SIS, this will require at least revisiting the JAXB binding of
all classes in the org.apache.sis.metadata.iso.* packages.

A minor amendment is under discussion for ISO 19115-1:2014 (the
conceptual model, independent of XML or Java representations).

We had a review of existing metadata standards, in particular:

  * ISO 19115 (used as GeoAPI / Apache SIS conceptual model) and other
    ISO standards
  * Dublin Core (used as Apache Tika conceptual model)
  * (GEO)DCAT (an extension of W3C Data Catalog Vocabulary)

A DCAT-Geospatial working group is formed. Its goal is to improve the
publishing of metadata as linked open data and improve integration of
metadata in search engines. The target audience is metadata experts
(Geo, EGOV & open data, archive), linked open data experts, search
engine experts and professional data users. Approaches for integrating
metadata and semantic web technology will be explored in collaboration
with W3C. Among the problems to resolve, two of them are:

  * How can we prevent serious loss of metadata when using a single
    standard?
  * How can we present data in an understandable & useful way without
    making it to complicated?

A "best practice paper" would be written. The initial paper scope
include a REST API.

[1] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=32579


    Referencing by coordinates (CRS)

Discussion continue on "dynamic datum". This was initially trigged by
the need to take in account tectonic plate movements, but may
opportunistically be used for parametric datum based on atmospheric
pressure (important for meteorological and oceanographical data
exchange). We also had a talk about definitions of planetary CRS (for
Venus, Jupiter, etc.), but this discussion is less advanced than dynamic
datum.

The Architecture Board presented an updated policy about axis order. We
are still facing the problem that a lot of software use for example
"EPSG:4326" as a (/longitude/, /latitude/) CRS despite the authoritative
definition given by EPSG, which is (/latitude/, /longitude/). A key
point of the updated policy is that if a format wants to use a different
axis order than the authoritative one, then that change must be obvious
by reading the metadata without the need to refer to an external
specification. For example a format could use an identifier like
"EPSG:4326;axisOrder(lon,lat)" (example only - not an official syntax),
but "EPSG:4326" alone would be incorrect for anything which is not
(/latitude/, /longitude/). An example of format which is compliant with
this approach is KML 2.3 (annex B). An example of format which is
currently not consistent with this policy is GeoJSON. I think that
PostGIS database would not be compliant neither.


    Moving features

The NetCDF encoding document has been changed from "best practice"
category to "discussion paper" and has been voted. The reason for this
change is that we have not yet completed the implementation experiment.
We use the UCAR library as the reference implementation, but we are also
exploring an alternative implementation in Apache SIS in order to verify
that moving features can be supported without the need of non-standard
attributes (current UCAR library seems to require an additional
_CoordinateAxisType attribute).

The GitHub repository for Moving Feature JSON encoding is now public
[2]. This specification is actually more than what the title suggests,
since it also cover dynamic properties (properties with values that
change with time) and some interpolation mechanisms that go beyond the
Moving Feature core specification. This specification contains also a
REST API, but I think that this API has been developed independently of
the work described in the "JSON-LD schemas" section below.

We also had an update on "Moving Features Access", which describe an API
for doing operations on a set of moving features (add, remove, /etc/).

[2] https://github.com/opengeospatial/mf-json


    JSON-LD schemas

OGC specifications have a conceptual defined using UML, and a
representation of those UML in XML. For example ISO 19115-1 defines a
conceptual model for metadata and ISO 19115-3 specifies how to represent
those metadata in XML. The use of JSON as an alternative to XML is
relatively recent at OGC. We had an engineering report about the use of
formal rules for transforming UML to JSON. Part of this work will be
integrated in version 1.1 of the OGC Coverage Implementation Schema (CIS).


    Meteo-ocean

OGC 16-086r2 \u2014 Web Map Services (WMS) with Ensembles of Forecast Data \u2014
is now an official OGC Best Practice. This document got contributions of
many agencies including Deutscher Wetterdienst (Germany), Ministry of
Infrastructure and the Environment (Netherlands), M�t�o-France,
Meteorological Service of Canada, UK Met Office, US Air Force
Directorate of Weather, /etc./ The final publication is in progress.

The meteorological and oceanographical communities use a profile of the
Web Coverage Service (WCS) specification, for better support of
4-dimensional data. This profile has been updated to latest version of
WCS specification, which is WCS 2.1.

We had presentation about GRID Edition 2 format and OpenDap protocol.
They are not OGC standards, but widely used in meteorological and
oceanographical domains.


    Spectrum

This new working group is about the geospatial aspects of
electromagnetic waves emitted by devices. Given that the amount of such
devices is increasing rapidly, there will be interference. A standard
model would be useful for reducing the risk of interference, but also
useful for understanding possible biological impacts and health risks of
emissions.

The group had a discussion about temporal aspect. The model may requires
nanosecond precision, e.g. for supporting measurement of flash of
lightnings.


    External standards to be adopted or extended

GeoRSS [3] may become an OGC standard. This request come from the US
Federal Geographic Data Committee (FGDC). The original GeoRSS developers
agree.

Another external standard that may be adopted by OGC is LAS 1.4, a file
format for the interchange of 3-dimensional point cloud data. LAS is
used for data collected by some sensors like LiDAR.

Open mHealth is a standard for exchange of health data, but OGC members
propose to create a new working group for integrating more information
relevant to an ageing population, leveraging OGC SensorML among others.
According United Nations, the number of people 65 and older is projected
to triple by mid-century with a majority of people older than 50 in
Japan, South Korea and Germany. The proposed working group (AHA-ML -
Active and Healthy Aging Mark-up Language) would try to improve the
exchange of information regarding psychophysical conditions.

[3] http://www.georss.org/

Re: Report from December OGC meeting

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

I just realized, a public version of the closing plenary slides are
available there:

    https://portal.opengeospatial.org/files/?artifact_id=72228

At the end of the week, each working group summarize their discussion in
a few slides, together with the actions they decide to do. The closing
plenary slides is the assembly of those slides.

    Martin