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: [email protected] 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 <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Sunday, March 15, 2015 at 5:38 PM To: Apache SIS <[email protected]> Cc: "Geotoolkit.org" <[email protected]> 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/ >
