Hello all
The Open Geospatial Consortium (OGC) had a meeting in Dublin last week.
Below is a report of some discussions that caught my attention. Of
course this is only a small part of what has been discussed, and a
report from someone else would highlight different aspects. Of course
this report is probably not error-free, since I may have misunderstood
some aspects.
Content:
* OpenAPI for REST interfaces
* Web Processing Services (WPS)
* Coverage
* Coordinate Reference Systems (CRS)
* Calendar Well Known Text (WKT)
* NetCDF, HDF and GRIB
* Smart Cities
* Mobile Location Services (MLS)
* Moving Features
* Marine Spatial Data Infrastructure
* Agriculture
* Planetary
OpenAPI for REST interfaces
A discussion about API started at OGC about one year ago and is making
progress toward a white paper publication. In this discussion, the "API"
term cover programming languages features like Java interfaces, but also
the API of popular JavaScript libraries and the syntax of
requests/responses when communicating with a web server using the REST
approach. There is a proposal to express a subset of OGC specifications
- which could be named /OGC API Essentials/ - according the /OpenAPI
initiative/ (OAI) specification from the Linux Foundation [1]. Defining
the /OGC API Essentials/ could be part of a /OWS Common/ revision (OWS
defines a common base to many OGC standards). /OGC API Essentials/ could
also be defined in collaboration with W3C /Spatial Data on the Web
Working Group/.
I plan to start a separated thread about API when the OGC white paper
will be available on-line. Comments received before July 31th will be
addressed in version 2 of the white paper, to be presented in next OGC
meeting in Orlando (Florida).
[1] https://openapis.org/
[2] https://www.w3.org/2015/spatial/wiki/Main_Page
Web Processing Services (WPS)
The 52thNorth open source project is experimenting an adaptation of
their WPS server for experimenting the REST approach. In current
proposal the requests sent to the server can be:
* A HTTP GET for getting information about available operations.
* A HTTP POST for starting a processing.
* A HTTP DELETE for cancelling a processing.
The server responses are in JSON instead than XML. Currently the JSON
structures are derived directly from XML schemas, but future versions
may take some freedom. They were also some discussions about SOAP
bindings, but current focus seems to be more toward REST. An engineering
report is planned, maybe for next meeting in September.
An other topic is about how to chain many operations. WPS 1.0 used the
/Business Process Execution Language/ (BPEL), but some issues were
reported against this approach (e.g. notification mechanism, lack of
SOAP). Consequently WPS 2.0 omits operation chaining. In order to bring
back operation chaining in a future WPS version, one possibility may be
/Business Process Model and Notation/ (BPMN) 2.0 defined by the /Object
Management Group/. BPNM defines not only a language, but also a
graphical representation of that language for non-developers. BPNM
defines also (if I understood right) a rollback mechanism for undoing
previous operations if something fails in the chain. Compatibility with
BPEL will need to be considered given that WPS 1.0 implementations use
it. A best practice paper is planned, maybe for next meeting in September.
Coverage
Reminder: "GMLCOV" has been renamed "CIS" (Coverage Implementation
Schema). To be more specific, CIS 1.1 = (compatible evolution of GMLCOV
1.0) + (GML 3.3). That CIS 1.1 specification would be mirrored at ISO as
the ISO 19123-2 specification. The existing ISO 19123 specification
would become ISO 19123-1. This numbering scheme would be equivalent to
what we have in metadata:
* ISO 19115-1 is the abstract metadata model.
* ISO 19115-3 is the XML encoding of above abstract model.
Likewise we would have:
* ISO 19123-1 as the abstract coverage model.
* ISO 19123-2 as the XML encoding of above abstract model. Would be
equivalent to CIS 1.1.
The CIS 1.1 specification adds irregular grids support and interpolation
information in rangeType. We add a discussion saying that the
definitions of DiscreteCoverage versus ContinuousCoverage need to be
clarified. The discussion was that DiscreteCoverage is not that much
about whether an interpolation function is defined or not, but about
whether interpolation makes sense at all. For example in a map of postal
codes, interpolation make no sense - so we have a DiscreteCoverage. But
having no interpolation does not means that the coverage is discrete.
The phenomenon may be continuous, but we may be missing data for doing
the interpolation.
There is a proposal to represent coverages in the JSON format
(applicable only to relatively small images) for use with JavaScripts in
client browsers. This could be understood as a kind of NetCDF format
translated into JSON for JavaScript convenience. More information on
http://covjson.org.
We also had a reminder of the various ways to express a CRS in a URL
(from OGC 1-135r2):
* http://www.opengis.net/def/crs/EPSG/0/4326
* http://www.opengis.net/def/crs?authority=EPSG&version=0&code=4326
*
http://www.opengis.net/def/crs?authority=OGC&version=1.3 &code=AUTO42003&UoM=m&CenterLongitude=-100&CenterLatitude=45
*
http://www.opengis.net/def/crs-compound? 1=http://www.opengis.net/def/crs/EPSG/0/4326 &2=http://www.opengis.net/def/crs/OGC/0/AnsiDate
Coordinate Reference Systems (CRS)
The new group is thinking about how to take in account the plate
tectonic movements (because today's measurements are now accurate enough
for making those movements significant) without complexifying too much
the model for those who don't need such accuracy. Current CRS
definitions use /static datum/. Taking in account plate tectonic will
require the introduction of /dynamic datum/ in the model.
A related issue is that while many users just said that their
coordinates are "in WGS84", there is actually 6 realizations of WGS84:
WGS84(Transit), WGS84(G730), WGS84(G873), WGS84(G1150), WGS84(G1674) and
WGS84(G1762). So we need to define a mechanism allowing to use "WGS84”
as an undifferentiated group of all above-cited realisations for those
who do not need high accuracy, while allowing to specify the exact WGS84
realization for those who need to.
An other discussion was about how to represent ellipsoidal heights with
projected CRS. In the ISO 19111 model, heights above ellipsoids are
handled in a special different than all other kind of heights (geoidal,
orthometric, barometric, /etc/). Representation of other kind of heights
are already well defined, and the case of ellipsoidal height in a
geographic CRS is also defined. But there is a hole for the ellipsoidal
height in a projected CRS.
The meteorological and oceanographical communities use extensively
pressures as a measurements of vertical positions. The ParametricCRS
class can represent such barometric heights, but current ISO 19111-2
specification does not provide indication about how to relate a
ParametricCRS (for example in kPa units) to a VerticalCRS (for example
in metre units). In the oceanographic case, the relationship does not
vary significantly with time and may be representable with the current
ISO 19111 model by using a Transformation class together with the new
InterpolationCRS element introduced in WKT 2. I got the task of writing
a "best practice" paper this summer showing how it can be done. But in
the meteorological case, the relationship vary with time. How to handle
the time-varying aspect is not yet determined; we may try to use the
above-cited dynamic datum.
We also discussed about a recent change in the EPSG database, in which
the abbreviation of longitude axis has been changed from "long" to "lon"
in order to avoid confusion with the "long" data type found in
programming languages. Some peoples said that this change broke existing
applications and consequently was an incompatible change. But in my
opinion, the issue is not on the EPSG side since axis /abbreviations/
are not a controlled vocabulary. It is actually very clear by reading
ISO 19111 and WKT 2 specifications that "lat" and "lon(g)" are not
standard abbreviations. Rather than abbreviations, axis /names/ or axis
/directions/ are more controlled vocabulary. In my opinion, the broken
applications should not have used abbreviations as a kind of identifiers
in the first place since there is better alternatives. Anyway, the
agreement was to encourage the use of version numbers in a urn like
"urn:ogc:def:crs:EPSG:8.2:4326" (in that example the EPSG version number
is 8.2) and clarify what is the default value when the version number is
omitted (namely, the latest available version).
Calendar Well Known Text (WKT)
This working group aims to expand the CRS Well Known Text 2 format with
the ability to define a point in time with respect to a particular
calendar. The current WKT specification allows to specify a time axis
based on the Gregorian calendar as used by ISO 8601. But climatologists
also need unusual calendars, for example with years of 360 days. There
is also issues about how to manage the leap seconds. If I understood
correctly, ISO 8601 is always relative to "ISO recognized Gregorian
calendar", which include leap seconds. But Most softwares ignore leap
second, resulting in errors of a few seconds. Furthermore we know only
one year in advance if a particular year in the future will have a leap
second. One possibility explored by the working group is to define a
calendar without leap seconds, but with a string syntax that would fail
to parse as an ISO 8601 date in order to avoid confusion.
NetCDF, HDF and GRIB
A review of conventions related to NetCDF include:
* NetCDF-CF: models for encoding multidisciplinary geosciences data.
* NetCDF Attribute Convention for Dataset Discovery: can be mapped to
ISO 19115-2. NOAA GEO-IDE provides a crosswalk.
* NetCDF-U: for representing uncertainty in data.
* NetCDF-LD: for Linked Data - in proposal stage. The idea is to use
the "context" array concept form JSON-LD and maps it onto variables
in NetCDF files.
* EO NetCDF conventions: EO = Earth Observation.
* ncML: a XML representation of NetCDF metadata. Approximatively the
header information from a NetCDF file.
* ncML-GML: an extension of ncML based on GML grammar.
Some peoples have expressed interest in serving GRIB2 files from Web
Coverage Server (WCS). A GRIB3 file is under discussion outside OGC. A
version 2 of /Climate and Forecast (CF) Metadata Conventions/ is also
under discussion outside OGC (current version is 1.6). Another
discussion was about creating a new working group for the HDF format.
The process would be similar to the work done for NetCDF in the past few
years, and would result in the adoption of HDF as an OGC standard.
Smart Cities
The discussion are not yet technical. The basic idea is that the way we
live, work, use energy, transportation and other resources will change
significantly because of innovations in "smart cities". Innovations
include changing how transport is managed, improved patient flows in
hospitals, flood planning, /etc./ Making a static models of a city is
"easy". But maintaining a city model, and having a dynamic model taking
sensor information in account is harder. This task involves a mix of
topics addressed by many other OGC working groups (security, big data,
sensor web, mobile location, land & infrastructure, emergency &
disaster, /etc/). The work of the Smart Cities group will be to identify
which existing standards are useful for "smart cities" use cases, verify
that they are consistent with each others and identify gaps.
Two related efforts are the European Espresso program [1] and ISO 30145
Information technology — Smart City ICT Reference Framework.
[1] http://espresso-project.eu/
Mobile Location Services (MLS)
The Open Geospatial Consortium (OGC), the InLocation Alliance (ILA) and
i-locate (a project funded by the European Commission) did a survey
about the use of indoor Location Base Services (LBS) in market. This is
a rapidly evolving market with hight growth. The survey targeted both
client organizations and technical suppliers. Surprisingly, the largest
group of respondents where from the health sectors (e.g. hospital
clinics) and care services for ageing people. Culture and entertainment
(which we though would be first) came only next. The most popular
features of interest were real time positioning and indoor navigation
and guidance (other, less popular, features include interaction with the
environment, provision of contextualised information, etc.). An accuracy
of about one meter is considered sufficient by the majority.
The survey identifies a need for concerted use of multiple positioning
technologies at once, which justify the standardisation effort. Peoples
wish tools for automatic configuration of location infrastructure. The
OGC IndoorGML is the most well-known standardization initiative among
the respondents (some other initiatives are OMA MLS and ISO/IEC
24730-21:2012).
Moving Features
Current moving feature specifications include a XML encoding [1] and a
CSV encoding [2]. Two new encodings were presented: a binary one
(NetCDF) and one based on GeoJSON. The NetCDF encoding is at draft stage
and would not be an OGC standard. It is rather a "best practice" paper
summarizing how to use existing NetCDF conventions, in particular the
"/Discrete Sampling Geometries/" chapter of /Climate and Forecast (CF)
Metadata Conventions/ [3] together with the /Attribute Convention for
Data Discovery/ (ACDD) [4]. That NetCDF binary encoding offers more
compact files and better performances than XML or CSV text files, but at
the cost of less flexibility. For example the proposed NetCDF encoding
would store only points along trajectories, while the CSV and XML
encoding allow more complex geometries. We plan to implement those
moving feature encoding in Apache SIS as an experiment, and report the
results to next OGC meeting.
A GeoJSON extension has also been presented. Compared to the other
encodings (XML, CSV, NetCDF), the proposed GeoJSON encoding has one
additional feature: the possibility to specify the polynomial to use for
interpolation between two time steps. The proposed approach seems
flexible enough for representing for example an object which, during its
displacement along a trajectory, does also a rotation on itself.
[1] http://docs.opengeospatial.org/is/14-083r2/14-083r2.html
[2] http://docs.opengeospatial.org/is/14-084r2/14-084r2.html
[3]
http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#discrete-sampling-geometries
[4] http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery
Marine Spatial Data Infrastructure
Two standards used in offshore industry are the Seabed Survey Data Model
(SSDM) published by IOGP and the S-57 and S-100 standards published by
the International Hydrographic Organization (IHO). The new OGC marine
working group aims to favorize interactions between those standards.
S-57 is for nautical charting for safety of navigation and S-100 is for
a wider community (not just navigation). Features to standardize include
a mix of bathymetric grid, sediment, sea bed, /etc./ For example the
group is interested not only about the depth of water below the vessel,
but also about whether the mud is solid or liquid. Mud boundary changes
with flowing water, and the speed the vessel is travelling needs also to
be taken in account. The group wants to discuss the content of a
conceptual model for a Marine Spatial Data Infrastructure taking those
kinds of aspects in account.
Meteo and ocean
The Meteo and ocean group has completed a "best practice" paper for
"Ensembles of Forecast Data". A new Web Map Server (WMS) dimension is
introduced: ENSEMBLE_MEMBER. An /ensemble member/ is a single element of
an ensemble forecast. An /ensemble forecast/ is a set of forecasts for
the same times and locations. This new attribute is targeted at
specialists (most peoples will only use the /ensemble product/, which is
some kind of aggregation of all elements in an ensemble forecast).
Agriculture
The agriculture group wants to address soil data interoperability with
development and testing of a new Soil Markup Language, a GML compatible
encoding for soil features. This is proposed by the International Union
of Soil Sciences (IUSS). In addition to OGC meetings, the group will
have a face-to-face meeting at SciDataCon in Denver in September 2016.
The specification should allow monitoring of spatial and temporal
variations at different depths (0-10 cm, 10-20 cm, /etc./) and evaluate
scenarios for the future through simulation.
Some standards already exist (ISO 28258, EU-INSPIRE soil data
specification, eSoterML, ANZSoilML), but are diverse, restricted in
scope and do not cover all the goals expressed in the OGC meeting. A
comparison of those specifications is available in the meeting slides.
The OGC agriculture group aims to reconcile those standards in one
broadly applicable specification, in collaboration with IUSS and Fao
Global Soil Partnership. Elements of existing OGC standards (Observation
& measurements, GeoScience) will be reused when applicable.
An important aspect will be the measures of uncertainty. Note that other
OGC groups also worked on this aspect, like the uncertainty aspects for
NetCDF.
Planetary
Coordinate Reference Systems (CRS) for extraterrestrial planets has been
defined [1]. The intend is have accurate data to support robotic and
human missions. There is a need to support huge data sets (e.g. 1TB for
Kaguya lunar mosaic).
[1]
https://github.com/USGS-Astrogeology/GDAL_scripts/tree/master/OGC_IAU2000_WKT_v2
