Report from OGC meeting

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

Hello all

An Open Geospatial Consortium (OGC) meeting was hold in Nottingham last
week. The agenda is at [1]. Below is some items that caught my
attention. Please note that everything written in this email reflect
only my understanding. There is always a possibility that I
misunderstood some points.

Content of this email (this is only a small subset of the topics
discussed in such meeting):

 1. Openness
 2. Big data
 3. Coverage
 4. Web Map Service (WMS)
 5. General architecture
 6. Application Programming Interface (API)
 7. Coordinate Reference System (CRS)
 8. Temporal WKT for calendars
 9. Moving features
10. Geoscience
11. Meteorology
12. Health and poverty
13. Transportation


    1. Openness

OGC is updating some of their procedures. If the revision is approved,
then among other changes the Domain Working Groups (DWG) would be open
by default, and restricted to OGC members only if the group explicitly
request it. Non-OGC peoples would be able to register to mailing lists
and participate to virtual conferences. They could come to face-to-face
conferences if they register for the meeting. This may be significant
for the Apache foundation if some projects want to participate to the
DWG. Examples:

  * Apache Open Climate Workbench could be interested in OGC Meteorology
    & Oceanography DWG.
  * Apache cTAKES could be interested in OGC Health DWG.
  * Apache Clerezza could be interested in OGC Geosemantics DWG.

For making them more attractive, they were a talk about repackaging OGC
standards in a more implementer-friendly way [2]:

  * Quick introduction and overview for decision makers.
  * Easy start for developers including examples, code snippets, demo
    data, tutorial.
  * Hyperlinks.

OGC will test this approach with the Geopackage standard, which is
already developed openly on GitHub.


    2. Big data

In geographic information, big data are in sensors, rasters (see the
"Coverage" section below) and models (among others). There is many
facets to big data, but not yet a general agreement on the issues. There
is a sense of this working group that they should produce a white paper.

Note from Martin: do we have an opportunity here to invite Apache folk
from other projects to come at an OGC meeting for sharing their
experience with big data? (see the "Openness" section above).


    3. Coverage

The coverage abstract specification is currently ISO 19123. After its
revision, that specification may be renamed ISO 19123-1. This would
leave room for ISO 19123-2, which would be the XML encoding of the
abstract specification. That XML encoding is currently defined by OGC
Coverage Implementation Schema (previously known as GMLCOV). This is a
similar pattern than what is applied on metadata (ISO 19115-1 as the
abstract model, ISO 19115-3 as the XML encoding).

The coverages are distributed on the web by the Web Coverage Service
(WCS) specification. But there is currently no service for distributing
coverages as tiles (such tiling can improve performance a lot). Tiling
exists for Web Map Service (WMS) - which is about visualisation - but
not for Web Coverage Service (WCS) - which is about data. Some common
concepts may be shared, but this is not yet determined. A main
difference is that WMS is mostly two-dimensional while WCS can be
/n/-dimensional, both in its domain (input) and range (output). It was
also noted that W3C has a data cube definition, but I do not know yet
how it fits in this picture.

Participants seem to have consensus on saying that remote sensing users
do not want interpolation of WCS data. Note that it does not necessarily
mean no interpolation at visualisation time (WMS).


    4. Web Map Service (WMS)

Considering that XML is loosing some popularity, some members want:

  * A GetCapabilities written in JSON.
  * A GetMap as REST if possible.
  * A GetMetadata for maps, possibly using JSON-LD.
  * A GetFeatureInfo in JSON.

During the meeting, the group started a draft. The work seems to be in
an early stage.


    5. General architecture

XML usage is reducing while JSON is rising. Many OGC working groups are
doing JSON on their side (see the "API" section below). In order to
ensure consistency, the OGC Architecture group plans to elaborate a
document on JSON OGC best practice or policy.

Interesting note from the British Geological Survey on the needs for
standards: 50% of all project overruns in the construction industry in
the UK are caused by unforeseen ground conditions. The problem is
partially due to lack of standard, or the lack of standard usage. Users
of standards want direct access to geological models, and want
integration of city models with geological models.


    6. Application Programming Interface (API)

The ad-hoc meeting was well attended (maybe 20 peoples). The relevance
of Java API at OGC was difficult to defend in the age of XML dominance,
but the recent rise of JSON and mobile platforms makes more apparent the
need for alternatives. It is now easier to present some OGC standards
like Web Map Service (WMS) as an "API for the web platform", thus
opening the door to other platforms. However the discussions have shown
that not anyone have the same understanding of what
"implementation-(in)dependent API" means. For example things are seen
differently by UML modellers and Java developers. Some of the issues
were pointed as cultural differences. We agreed on the need to write a
white paper summarizing the API discussions so far.

The current trend seems strongly in favour of an API based on JSON, with
XML staying a big player. In this picture, request for a Java API still
in minority. However a Java API could benefit from a momentum for other
API. One possible approach could be, if OGC chooses to create a new "API
Domain Working Group" (this is only a supposition - no OGC member had
made this request yet), then the current GeoAPI project could become a
subgroup of that API DWG.

For Apache SIS, this discussion is of high importance as long as SIS's
PMC chooses to rely on GeoAPI interfaces. We are stick to GeoAPI 3.0
interfaces on trunk (we take more liberties on the development
branches), which will not evolve before OGC activity on GeoAPI restarts.
However it seems to me that the discussion is progressing, and we have
workaround on SIS's trunk in the meantime.


    7. Coordinate Reference System (CRS)

The Well Known Text (WKT) version 2 specification [3] was published this
year, and Apache SIS 0.6 is among the first implementations to support
it. The only other implementation that I'm aware of is the ESRI
prototype [4] in C++. However support by some major commercial vendors
is expected in 2016.

The current Geopackage specification [5] mandates the old WKT 1 format
as specified in OGC 01-009 specification (note: Apache SIS can
read/write that WKT format too). One migration path considered by OGC is
to define a Geopackage extension which would mandate WKT 2, and at some
point in the future retrofit that extension into the core specification.
This would be possible because WKT 2 is designed in such a way that an
OGC O1-009 compliant WKT is also a legal WKT 2 string. Note however that
many popular softwares (both open source and commercial) are *not* OGC
01-009 compliant, since they have a different interpretation of the unit
of measurement in some cases. This may cause some compatibility problems
with those softwares until they migrated to WKT 2, but I don't see any
easy way to avoid that.

Future work of the CRS working group was also discussed. Some possible
works are (nothing sure yet):

  * Dynamic datum (datum that varies with time).
  * Better support of some kind of heights or depths like "sigma levels"
    (used in meteorology and oceanography).

I have learn in this meeting that there is actually 6 versions of the
WGS84 datum. We currently do not distinguish them (neither does the EPSG
database). But there is a possibility that in the future, this need may
happen.


    8. Temporal WKT for calendars

This new working group is an initiative of some peoples from the
meteorological community. This group will work on time representation
based on calendars which are not Gregorian. The ISO 19108 ("temporal
schema") standard already gives a general model, so this working group
would focus on Well-Known Text (WKT) representation. This is of
particular business value for the climate science community using
360-days long year in numerical models. This work may be done as an
extension of existing OGC/ISO standards. An example of issues faced by
this group is the fact that most computer software (including the Java
language) are based on no-leap second calendar.

For this group, Calendar ≠ TemporalCRS, because "time stamp" ≠ "time
coordinate". A coordinate system axis is continuous ("second 5" happen
exactly 1 second after "second 4"), while a time stamp does not make
such guarantee: it just said that "second 5" happen after "second 4". In
terms of levels of measurement [6], a Calendar is an /ordinal scale/
while a TemporalCRS is an /interval scale/. The distinction become more
obvious when talking about geological times, where we can sometime said
"event A occurred before event B" without providing accurate dating for
those events.


    9. Moving features

Moving features is defined by ISO 19141:2008, and OGC now have XML and
CSV encoding specifications. The next work will be to define a simple
binary format, possibly (but not necessarily) based on NetCDF. Section
9.3 of CF-convention [7] seems of particular relevance. For Apache SIS,
the work would be:

  * Verify if the interfaces in the org.opengis.feature package meet the
    need of moving features.
  * If above interfaces need to be modified, update the
    org.apache.sis.feature package accordingly.
  * If NetCDF is considered a suitable binary format, experiment its
    support in the Apache sis-netcdf module.

We also had in Nottingham an other session, named "Point cloud". While
"Moving features" and "Point cloud" where two independent sessions, I
wonder if the binary encoding for Moving Feature and the "point cloud"
could share some aspects. A "point cloud" is a little bit similar to
raster data: sampling nature, huge volumes, relatively static.
Participants of the "point cloud" session said that:

  * /n/-dimensional point clouds can also cover moving object point data
    in a (x,y,z,t) (id) series.
  * Specific files in this domain are sub-optimal. Workaround exits, but
    would be like building our own Relational database.

The is an OSGeo "point down initiative" [8], but it does not seem very
active at this stage.


    10. Geoscience

GeoSciML (www.geosciml.org) version 3.2 uses many OGC standards. There
is some talks about the possibility to propose version 4 as a full OGC
standard. A join working group would be formed between OGC and CGI-IUGS
(commission for the management and application of geoscience information).


    11. Meteorology

The "Coverage Collection Extension" proposed standard defines how a Web
Coverage Service (WCS) server may group its offered coverages into
uniquely identified collections and how information about those
collections is provided. Each member coverage within a Coverage
Collection shares similar characteristics such as provenance. A Coverage
Collection may contain other Coverage Collection, thus enabling
coverages to be grouped in arbitrarily nested sets. This proposal is
open for public comments [9].

On a related topic, they were a discussion on "Ensembles" (it is not yet
clear to me what is the difference between "coverage collection" and
"ensemble"). The participants agreed on the need to identify simple
products through name: arithmetic mean, standard deviation, quartiles.
Products that need parameters are deferred to a later version.

A paper about "Trajectory" will be submitted for public comments. I'm
not yet sure, but I think it is about sampling data along
non-rectilinear segments. This gives an impression of similarity with
ISO 19141:2008 (Moving Features), but apparently there is enough
differences for a separated paper.


    12. Health and poverty

The health group discussion was in part about linking geographical data
statistically while protecting privacy. This is basically joining
tabular data with boundary data using the Table Joining Service (TJS) -
a straightforward use of a common identifier in the tabular data and in
the geometries. We had a demo using EOROSTAT data. Some other
presentations were:

  * Impact of Weather and Climate on Human Health - a United Nations
    response (by Met Office).
  * United Nations Committee of Experts on Global Geospatial Information
    Management (UN-GGIM) - integration of statistical and geospatial
    information.
  * Global Framework for Climate Services (GFCS) - a join project
    between the World Health Organization (WHO) and the World
    Meteorological Organization (WMO).

One issue raised in the talks was the weak links between the research
and operations communities of weather/climate and the health community.


    13. Transportation

There is plan to form a maritime working group focused on maritime
navigation. Noting that there is already an Aviation working group,
whether the two groups should be merged into a single "Transportation
working group" is an open question. This could even include walking
(through the IndoorGML standard).


    Martin


[1] http://www.opengeospatial.org/events/1509tcagenda
[2] http://external.opengeospatial.org/twiki_public/Main/StandardTemplates
[3] http://docs.opengeospatial.org/is/12-063r5/12-063r5.html
[4] http://github.com/Esri/ogc-crs-wkt-parser
[5] http://www.geopackage.org/
[6] http://en.wikipedia.org/wiki/Level_of_measurement
[7] http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#discrete-sampling-geometries
[8] http://lists.osgeo.org/pipermail/pointdown/2015-February/000000.html
[9] http://portal.opengeospatial.org/files/?artifact_id=64557&version=1