<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello all<br>
</p>
<p align="justify">Last week was the OGC meeting in Barcelona [1].
Below are some points that attracted my attention. Note that the
next OGC meeting will be in Boulder (Colorado) in June.<br>
</p>
<p align="justify">Table of content:<br>
</p>
<ul>
<li>API ad-hoc and GeoAPI</li>
<li>Standard openness ad-hoc</li>
<li>OGC and W3C on GeoSemantic<br>
</li>
<li>Metadata and data preservation</li>
<li>Metadata validation</li>
<li>Coordinate Reference System (CRS)</li>
<li>Moving features</li>
<li>Coverage and GML</li>
<li>Varia<br>
</li>
</ul>
<pre>
[1] <a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/event/1503tcagenda">http://www.opengeospatial.org/event/1503tcagenda</a>
</pre>
<p><br>
</p>
<h3>API ad-hoc and GeoAPI<br>
</h3>
<p align="justify">First, we had a review of current situation: many
Java projects currently derive their API from OGC's XSD files, but
this lead to poor API. The "covariant type" and the "union"
language features were used as examples illustrating the problems.
Next we had a discussion about whether OGC wants to define an API
derived from UML, and (if yes) which kind of API it would be. For
example an OGC's API shall not imply any particular
implementation. This neutrality is possible in Java thanks to
interfaces, but not in JavaScript for example. The discussion will
continue in next OGC meeting.<br>
</p>
<p align="justify">The GeoAPI working group will probably stay in a
"stand by" position, waiting for OGC to clarify their plan. Some
work may continue on GitHub for bug fixes, documentation
clarifications or tests, but no new features would start for now.<br>
</p>
<p align="justify">Note that some other standards (e.g. Moving
Feature version 2) are considering to define an API as part of
their work. I do not know yet if those API could be integrated
with GeoAPI.<br>
</p>
<p><br>
</p>
<h3>Standard openness ad-hoc<br>
</h3>
<p align="justify">The discussion covers two aspects:<br>
</p>
<ul>
<li>How to attract open source communities while preserving
conformance to the standards.</li>
<li>How to maintain OGC standards baseline while supporting
potentially disruptive new technologies. For GeoAPI, this can be
related to the split of development work in a GeoAPI 3.1 and 4.0
branches [2].<br>
</li>
</ul>
<p align="justify">This is an effort underway for 3 years. The
"Ideas4OGC" call [3] is part of this effort. Discussion will
continue in next OGC meeting.<br>
</p>
<pre>
[2] <a class="moz-txt-link-freetext" href="http://www.geoapi.org/snapshot/index.html">http://www.geoapi.org/snapshot/index.html</a>
[3] <a class="moz-txt-link-freetext" href="http://external.opengeospatial.org/twiki_public/Ideas4OGC/WebHome">http://external.opengeospatial.org/twiki_public/Ideas4OGC/WebHome</a>
</pre>
<p><br>
</p>
<h3>OGC and W3C on GeoSemantic<br>
</h3>
<p align="justify">W3C already produced a standard using OGC/ISO
standards: Provenance ontology [4], which is now formally a W3C
standard since April 2013. This standard uses the ISO 19115
"lineage" package, which we support in Apache SIS [5]. This means
that we already have some ground for implementation of W3C's
PROV-O standard if wanted.<br>
</p>
<p align="justify">For the next tasks, OGC and W3C consortium will
work together on the following (among other tasks) [6]:</p>
<ul>
<li>Best practices (where there are too many choices).</li>
<li>Ontology for Gregorian calendar and temporal relationship,
based on Allen's interval calculus. They will seek for
harmonization between OWL-time standard [7] and ISO 19108 [8],
but we do not yet know how. For GeoAPI, this will impact the <tt>org.opengis.temporal</tt>
package (currently in the "pending" part of GeoAPI).<br>
</li>
<li>Spatial data encoding, relation, identity, geometry and API.
They are collecting requirements for an API design (I'm not sure
which kind of API) and currently have more than 25 use cases.</li>
</ul>
<p>More information on the planed work can be found at [9]. OGC and
W3C are considering to hold a GeoSemantic summit which would be
open to anyone (not an OGC-members meeting). The meeting may be
held in June (in which case it would be together with OGC at
Boulder), maybe later - it is not yet sure.<br>
</p>
<pre>
[4] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/prov-o/">http://www.w3.org/TR/prov-o/</a>
[5] <a class="moz-txt-link-freetext" href="http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/lineage/package-summary.html">http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/lineage/package-summary.html</a>
[6] <a class="moz-txt-link-freetext" href="http://www.w3.org/2015/spatial/charter">http://www.w3.org/2015/spatial/charter</a>
[7] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/owl-time/">http://www.w3.org/TR/owl-time/</a>
[8] <a class="moz-txt-link-freetext" href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26013">http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26013</a>
[9] <a class="moz-txt-link-freetext" href="http://www.w3.org/2015/spatial/wiki/Main_Page">http://www.w3.org/2015/spatial/wiki/Main_Page</a>
</pre>
<p><br>
</p>
<h3>Metadata and data preservation<br>
</h3>
<p align="justify">The goal is to establish a digital preservation
metadata model that allows documenting the necessary features to
ensure the durability of the information. They were a discussion
on some existing efforts:<br>
</p>
<ul>
<li>Since 1998: Earth Science Information Partners (ESIP)</li>
<li>Since 2004: Digital Curation Centre (DCC)</li>
<li>Since 2011: Geospatial Multistate Archive and Preservation
Partnership (GeoMAPP)<br>
</li>
<li>Since 2013: Research Data Alliance (RDA)</li>
<li> Open Archival Information System (OAIS)</li>
<li>PREMIS data dictionary</li>
<li>(under development): ISO 19165 - Preservation of digital data
and metadata<br>
</li>
</ul>
<p align="justify">The OAIS standard (also known as ISO 14721) is a
conceptual model; it does not define which attribute to use
exactly. The PREMIS data dictionary is an effort to combine OAIS
and ISO 19115 (metadata) standards to obtain a more concrete
schema, completed with some GeoMAPP ideas. Again, given Apache SIS
support of ISO 19115, if we wanted to address data preservation
issues, maybe PREMIS would be a good entry point. I do not know
however what would be the relationship with the ISO 19165 standard
under development.<br>
</p>
<p align="justify"><br>
</p>
<h3 align="justify">Metadata validation<br>
</h3>
<p align="justify">The CINERGI project (Inventory of EarthCube
Resources for Geoscience Interoperability) provides tests for ISO
19115 metadata objects, which can be run as TestNG tests [10].
There is an overlap between those tests and the one provided by
GeoAPI and used by Apache SIS. However the CINERGI tests are
designed for validating XML files, while GeoAPI conformance module
is designed for validating Java objects. It may be worth to
consider to port or adapt some CINERGI code (they are under Apache
2 license) in order to use their schematron files for validating
our metadata instances. CINERGI seems to execute the following
scripts:<br>
</p>
<ul>
<li><tt>org/opengis/cite/schematron/iso19139_schematron_nil.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkEncodingStandard.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkDataIdentification.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkAggregateInformation.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkLegalConstraints.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkScopeOfXmlFile.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkGeorectified.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkBandValueOfXml.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkMediumOfXml.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkExtendedElementInformation.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkExtentValueOfXml.sch</tt></li>
<li><tt>org/opengis/cite/schematron/checkResponsiblePartyOfXml.sch</tt></li>
</ul>
<p align="justify">However I don't know where to find them (they are
not in GeoAPI). Does anyone has some clues?<br>
</p>
<p align="justify">Note: OGC is using Geotk for some of their tests,
with a note saying that significant chunks of Geotk code is moving
to Apache SIS [11].<br>
</p>
<pre>
[10] <a class="moz-txt-link-freetext" href="https://github.com/opengeospatial/ets-19139">https://github.com/opengeospatial/ets-19139</a>
[11] <a class="moz-txt-link-freetext" href="http://opengeospatial.github.io/geomatics-geotk/">http://opengeospatial.github.io/geomatics-geotk/</a>
</pre>
<p><br>
</p>
<h3>Coordinate Reference System (CRS)</h3>
<p align="justify">The Well Known Text (WKT) version 2 (ISO 19162)
working group has completed his work and has been dissolved. The
WKT 2 implementation is under way in Apache SIS. However WKT 2 has
known limitations on temporal reference systems. In particular,
there is currently no standard way to define the calendar in use.
The intend is not to support the calendars in use in various
cultures (we can use <tt>java.time</tt> or JODA for that
purpose), but rather to support some "scientific" calendars like
the 360-days long years used in climatology, or 365-days long
years without leap years, etc. I think that the discussion will
continue in next OGC meetings.<br>
</p>
<p align="justify">A new topic on the table is a proposal to define
a standard file format for the exchange of gridded geodetic data.
We are currently seeing:</p>
<ul>
<li>More lat-long offset grids (used for datum shifts)<br>
</li>
<li>More geoid and height correction models</li>
<li>More velocity and deformation grids<br>
</li>
</ul>
<p align="justify">But no standard file format exists. NADCON, NTv2,
EGM96, etc. are in common use but not standard. The proposal is to
create a working group in the next OGC meeting for addressing this
issue.</p>
<p align="justify">An other possible next work may be a revision of
ISO 19111 data model. In particular, there is a proposal to refine
compound CRS when a vertical transformation depends on horizontal
parts. For Apache SIS, this may impact the <tt>DefaultCompoundCRS</tt>
class [12] among others.<br>
</p>
<pre>
[12] <a class="moz-txt-link-freetext" href="http://sis.apache.org/apidocs/org/apache/sis/referencing/crs/DefaultCompoundCRS.html">http://sis.apache.org/apidocs/org/apache/sis/referencing/crs/DefaultCompoundCRS.html</a>
</pre>
<p><br>
</p>
<h3>Moving features<br>
</h3>
<p align="justify">The moving feature standard has been completed
and published on February 17th [13]. Current standard focus on XML
and CSV file formats. There is plan to work for a version 2 which
would add a simple binary file format (maybe NetCDF), GeoJSON and
an API for data exchange.</p>
<pre>
[13] <a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/standards/movingfeatures">http://www.opengeospatial.org/standards/movingfeatures</a>
</pre>
<p><br>
</p>
<h3>Coverage and GML<br>
</h3>
<p align="justify">We currently have two closely-related, but still
different, coverage models: ISO 19123 and GML. The GML model is
defined in an OGC standard currently named "GMLCOV", which is
misleading. Despite its name, "GMLCOV" is not really a GML
encoding of ISO 19123 coverages. GMLCOV is an implementation model
for the abstract coverage model defined by ISO 19123. So a better
name for "GMLCOV" may be "Geographic information - implementation
schema for coverages".<br>
</p>
<p align="justify">Work for unifying ISO and GML models started in
2012. The coverages as expressed in GMLCOV has evolved since when
ISO 19123 was originally written (in 2005). So the ISO standard
may need to be review. However it would probably be only a few
small changes to clauses like the description of discrete coverage
- ISO 19123 is not broken. There is a proposal to bring GMLCOV to
ISO, maybe as part 2 of ISO 19123.<br>
</p>
<p align="justify">If I understand correctly, the ISO 19163 standard
("Geographic information - Content components and encoding rules
for imagery and gridded data”) would be a specialization of ISO
19123 for one very common type of coverage data: remote sensing
imagery, together with links to other relevant standards [14]. The
ISO 19163 standard would have at least two parts: 1) content
model, and 2) application to existing formats like GeoTIFF and
NetCDF. I suspect that ISO 19163 will be very important to Apache
SIS when we will start implementing the <tt>org.apache.sis.coverage.grid</tt>
package.<br>
</p>
<p>Other standards worth to note:<br>
</p>
<ul>
<li>ISO 19159: Geographic information - Calibration and validation
of remote sensing imagery sensors and data.</li>
<li>ISO 19130: Geographic information - Imagery sensor models for
geopositioning. This standard is about referencing images taken
from a platform in air or space.</li>
</ul>
<pre>
[14] <a class="moz-txt-link-freetext" href="http://www.isotc211.org/hmmg/HTML/index.htm?goto=1:14:1:4332">http://www.isotc211.org/hmmg/HTML/index.htm?goto=1:14:1:4332</a>
</pre>
<br>
<h3>Varia<br>
</h3>
<h3></h3>
<p align="justify">The meteorological and oceanographic SVG symbols
from the World Meteorological Organisation (WMO) have been
incorporated in gvSig. QGIS will be next.<br>
</p>
<p align="justify">For meteorological and oceanographic needs, a Web
Coverage Service (WCS) extension is needed: the
"DescribeCoverageCollection" operation. It would make easier to
navigate through a large set of data. This operation can be
hierarchical: we may have collections of collections.<br>
</p>
<p align="justify">The Mobile Location Services group mentioned that
a majority of calls to 911 now originate from wireless phones. But
the majority of wireless calls are indoor, and GPS does not give
an accurate position when callers is inside building.</p>
<p align="justify">We had a summary of KML 2.3 changes (to be
submitted to an OGC vote soon):<br>
</p>
<ul>
<li>New geometries: Track (a path over a specified a period of
time) and MultiTracks</li>
<li>New extent: LatLonQuad, which extends the bounding box concept
by specify the 4 corners of the quadrilateral.</li>
</ul>
<p align="justify">We had a presentation of CDB (Common Database),
which is used by flights simulators. There is a proposal to submit
this specification as an OGC "best practice" document for the
simulation community. If I'm understanding right, this
specification is in part a directory structure convention for
finding data needed by flight simulators. The directories contain
images in GeoTIFF or similar open formats, together with metadata
files. In may be of interest to Apache SIS if the directory
structure convention is universal enough for being a good "default
directory structure" that we could offer to users for organizing
their data.<br>
</p>
<p align="justify"><br>
Martin<br>
</p>
<p><br>
</p>
<pre>[ 1] <a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/event/1503tcagenda">http://www.opengeospatial.org/event/1503tcagenda</a>
[ 2] <a class="moz-txt-link-freetext" href="http://www.geoapi.org/snapshot/index.html">http://www.geoapi.org/snapshot/index.html</a>
[ 3] <a class="moz-txt-link-freetext" href="http://external.opengeospatial.org/twiki_public/Ideas4OGC/WebHome">http://external.opengeospatial.org/twiki_public/Ideas4OGC/WebHome</a>
[ 4] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/prov-o/">http://www.w3.org/TR/prov-o/</a>
[ 5] <a class="moz-txt-link-freetext" href="http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/lineage/package-summary.html">http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/lineage/package-summary.html</a>
[ 6] <a class="moz-txt-link-freetext" href="http://www.w3.org/2015/spatial/charter">http://www.w3.org/2015/spatial/charter</a>
[ 7] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/owl-time/">http://www.w3.org/TR/owl-time/</a>
[ 8] <a class="moz-txt-link-freetext" href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26013">http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26013</a>
[ 9] <a class="moz-txt-link-freetext" href="http://www.w3.org/2015/spatial/wiki/Main_Page">http://www.w3.org/2015/spatial/wiki/Main_Page</a>
[10] <a class="moz-txt-link-freetext" href="https://github.com/opengeospatial/ets-19139">https://github.com/opengeospatial/ets-19139</a>
[11] <a class="moz-txt-link-freetext" href="http://opengeospatial.github.io/geomatics-geotk/">http://opengeospatial.github.io/geomatics-geotk/</a>
[12] <a class="moz-txt-link-freetext" href="http://sis.apache.org/apidocs/org/apache/sis/referencing/crs/DefaultCompoundCRS.html">http://sis.apache.org/apidocs/org/apache/sis/referencing/crs/DefaultCompoundCRS.html</a>
[13] <a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/standards/movingfeatures">http://www.opengeospatial.org/standards/movingfeatures</a>
[14] <a class="moz-txt-link-freetext" href="http://www.isotc211.org/hmmg/HTML/index.htm?goto=1:14:1:4332">http://www.isotc211.org/hmmg/HTML/index.htm?goto=1:14:1:4332</a>
[15] <a class="moz-txt-link-freetext" href="http://www.presagis.com/products_services/products/modeling-simulation/free_tools/cdb_api/">http://www.presagis.com/products_services/products/modeling-simulation/free_tools/cdb_api/</a>
</pre>
</body>
</html>