[geotk] Report from Barcelona OGC meeting

Sun Mar 15 22:07:19 PDT 2015

Great notes and will try and reply in detail soon

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann at nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


-----Original Message-----
From: Martin Desruisseaux <martin.desruisseaux at geomatys.fr>
Organization: Geomatys
Reply-To: "dev at sis.apache.org" <dev at sis.apache.org>
Date: Sunday, March 15, 2015 at 5:38 PM
To: Apache SIS <dev at sis.apache.org>
Cc: "Geotoolkit.org" <geotoolkit at lists.osgeo.org>
Subject: Report from Barcelona OGC meeting

>Hello all
>
>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.
>
>Table of content:
>
>  * API ad-hoc and GeoAPI
>  * Standard openness ad-hoc
>  * OGC and W3C on GeoSemantic
>  * Metadata and data preservation
>  * Metadata validation
>  * Coordinate Reference System (CRS)
>  * Moving features
>  * Coverage and GML
>  * Varia
>
>[1] http://www.opengeospatial.org/event/1503tcagenda
>
>
>      API ad-hoc and GeoAPI
>
>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.
>
>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.
>
>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.
>
>
>      Standard openness ad-hoc
>
>The discussion covers two aspects:
>
>  * How to attract open source communities while preserving conformance
>    to the standards.
>  * 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].
>
>This is an effort underway for 3 years. The "Ideas4OGC" call [3] is part
>of this effort. Discussion will continue in next OGC meeting.
>
>[2] http://www.geoapi.org/snapshot/index.html
>[3] http://external.opengeospatial.org/twiki_public/Ideas4OGC/WebHome
>
>
>      OGC and W3C on GeoSemantic
>
>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.
>
>For the next tasks, OGC and W3C consortium will work together on the
>following (among other tasks) [6]:
>
>  * Best practices (where there are too many choices).
>  * 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 org.opengis.temporal package
>    (currently in the "pending" part of GeoAPI).
>  * 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.
>
>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.
>
>[4] http://www.w3.org/TR/prov-o/
>[5] 
>http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/lineage/package-
>summary.html
>[6] http://www.w3.org/2015/spatial/charter
>[7] http://www.w3.org/TR/owl-time/
>[8] 
>http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csn
>umber=26013
>[9] http://www.w3.org/2015/spatial/wiki/Main_Page
>
>
>      Metadata and data preservation
>
>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:
>
>  * Since 1998: Earth Science Information Partners (ESIP)
>  * Since 2004: Digital Curation Centre (DCC)
>  * Since 2011: Geospatial Multistate Archive and Preservation
>    Partnership (GeoMAPP)
>  * Since 2013: Research Data Alliance (RDA)
>  * Open Archival Information System (OAIS)
>  * PREMIS data dictionary
>  * (under development): ISO 19165 - Preservation of digital data and
>    metadata
>
>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.
>
>
>      Metadata validation
>
>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:
>
>  * org/opengis/cite/schematron/iso19139_schematron_nil.sch
>  * org/opengis/cite/schematron/checkEncodingStandard.sch
>  * org/opengis/cite/schematron/checkDataIdentification.sch
>  * org/opengis/cite/schematron/checkAggregateInformation.sch
>  * org/opengis/cite/schematron/checkLegalConstraints.sch
>  * org/opengis/cite/schematron/checkScopeOfXmlFile.sch
>  * org/opengis/cite/schematron/checkGeorectified.sch
>  * org/opengis/cite/schematron/checkBandValueOfXml.sch
>  * org/opengis/cite/schematron/checkMediumOfXml.sch
>  * org/opengis/cite/schematron/checkExtendedElementInformation.sch
>  * org/opengis/cite/schematron/checkExtentValueOfXml.sch
>  * org/opengis/cite/schematron/checkResponsiblePartyOfXml.sch
>
>However I don't know where to find them (they are not in GeoAPI). Does
>anyone has some clues?
>
>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].
>
>[10] https://github.com/opengeospatial/ets-19139
>[11] http://opengeospatial.github.io/geomatics-geotk/
>
>
>      Coordinate Reference System (CRS)
>
>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 java.time 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.
>
>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:
>
>  * More lat-long offset grids (used for datum shifts)
>  * More geoid and height correction models
>  * More velocity and deformation grids
>
>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.
>
>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 DefaultCompoundCRS class [12] among others.
>
>[12] 
>http://sis.apache.org/apidocs/org/apache/sis/referencing/crs/DefaultCompou
>ndCRS.html
>
>
>      Moving features
>
>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.
>
>[13] http://www.opengeospatial.org/standards/movingfeatures
>
>
>      Coverage and GML
>
>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".
>
>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.
>
>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
>org.apache.sis.coverage.grid package.
>
>Other standards worth to note:
>
>  * ISO 19159: Geographic information - Calibration and validation of
>    remote sensing imagery sensors and data.
>  * ISO 19130: Geographic information - Imagery sensor models for
>    geopositioning. This standard is about referencing images taken from
>    a platform in air or space.
>
>[14] http://www.isotc211.org/hmmg/HTML/index.htm?goto=1:14:1:4332
>
>
>      Varia
>
>
>The meteorological and oceanographic SVG symbols from the World
>Meteorological Organisation (WMO) have been incorporated in gvSig. QGIS
>will be next.
>
>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.
>
>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.
>
>We had a summary of KML 2.3 changes (to be submitted to an OGC vote soon):
>
>  * New geometries: Track (a path over a specified a period of time) and
>    MultiTracks
>  * New extent: LatLonQuad, which extends the bounding box concept by
>    specify the 4 corners of the quadrilateral.
>
>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.
>
>
>    Martin
>
>
>[ 1] http://www.opengeospatial.org/event/1503tcagenda
>[ 2] http://www.geoapi.org/snapshot/index.html
>[ 3] http://external.opengeospatial.org/twiki_public/Ideas4OGC/WebHome
>[ 4] http://www.w3.org/TR/prov-o/
>[ 5] 
>http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/lineage/package-
>summary.html
>[ 6] http://www.w3.org/2015/spatial/charter
>[ 7] http://www.w3.org/TR/owl-time/
>[ 8] 
>http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csn
>umber=26013
>[ 9] http://www.w3.org/2015/spatial/wiki/Main_Page
>[10] https://github.com/opengeospatial/ets-19139
>[11] http://opengeospatial.github.io/geomatics-geotk/
>[12] 
>http://sis.apache.org/apidocs/org/apache/sis/referencing/crs/DefaultCompou
>ndCRS.html
>[13] http://www.opengeospatial.org/standards/movingfeatures
>[14] http://www.isotc211.org/hmmg/HTML/index.htm?goto=1:14:1:4332
>[15] 
>http://www.presagis.com/products_services/products/modeling-simulation/fre
>e_tools/cdb_api/
>