Thank you Martin this is a great report!

I'm CC'ing Ted Haberman from HDF Group who is likely interested in
this conversation and may be attending the OGC meeting after our
NASA ESDSWG meetings in Greenbelt end tomorrow by noon-ish.

I'm also CC'ing the NASA ESDSWG Geospatial WG that will be interested
in the below.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-5th floor
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]>
Reply-To: "[email protected]" <[email protected]>
Date: Tuesday, March 25, 2014 6:21 PM
To: Apache SIS <[email protected]>
Subject: Report on OGC meeting (1/2)

>Hello all
>
>An OGC meeting is going on right now in Arlington. The meeting is not
>yet over, but there is a summary of some points discussed so far:
>
>Web Coverage Services (WCS)
>-------------------------------------------------
>A specification mapping GeoTIFF tags to standards elements (ISO) has
>been adopted recently. Such GeoTIFF-ISO mapping is similar to the
>NetCDF-ISO mapping defined by NOAA. Apache SIS already implements the
>NetCDF-ISO mapping [1], we should also implement the GeoTIFF-ISO mapping
>using that document. Note that this specification is not about the
>GeoTIFF format itself, however there is some talk about whether OGC
>should also write a specification for it. In the current state, the
>community maintaining the GeoTIFF specification is somewhat informal.
>
>Other data specification under work are NetCDF and JPEG2000. The
>NetCDF-ISO mapping currently implemented by SIS is based on NOAA
>documentation. If OGC defines formally the mapping in a specification,
>we should probably update SIS accordingly.
>
>Above paragraphs are about "data". On the "services" side, recently
>adopted specifications extending the core are:
>
>- CRS
>- range subsetting
>- scaling
>- interpolation (often used together with scaling, but not necessarily)
>
>The meteorological-oceanographic working group said that the CRS and
>range subsetting extensions worked well for them. However an Earth
>Observation and meteorological-oceanographic profiles of WCS may still
>be needed for other reasons, to be discussed in the "MetOcean" section
>below in this email.
>
>A public wiki is at [2].
>
>
>
>Transactional Web Coverage Services (WCS-T)
>-------------------------------------------------
>WCS-T 2.0 is a rewrite of WCS-T 1.4 without upward compatibility - the
>changes are major. WCS-T purpose is to insert, update and delete WCS
>coverage offerings. Specification for insert and delete operations are
>done, update operation is in progress. The difficulty for the update
>operation is to specify the criterion for determining if an update is
>allowed or not (e.g. replacing a 3-banded image by a 1-banded image
>should probably not be allowed).
>
>
>
>Web Processing Service (WPS)
>-------------------------------------------------
>A WPS 2 specification is under way. WPS 2 improvements compared to WPS 1
>are:
>
>  * Better support for process discovery
>  * Improved execution management (long running processes, ability to
>    delete a running job)
>  * Better support for synchronous / asynchronous execution
>
>A specification draft for public comment is expected by the end of April.
>
>
>
>Meteorological-oceanographic group (MetOcean)
>-------------------------------------------------
>MetOcean discussed about the extensions they wish to bring to WCS.
>Rational for extensions are related to data shapes: GRIDS, time series,
>cross sections, point collections (e.g. observations), vertical profiles
>(e.g. ascents), trajectories. The group emphases on the needs for
>sub-settings on the 4 axes, probably 5 axes in the future where the
>fifth axis would be "ensemble" (e.g. probability, discussed below).
>Keeping in mind that MetOcean uses two time axis (forecast time, model
>run reference time), we have a potential for 6 dimensional coverages.
>The group emphases also on slice, trim and sub-setting operations (e.g.
>trim X, trim Y, slice Z = horizontal view).
>
>Some extensions needed:
>
>  * Slice and trim requested in other CRS than the source data CRS.
>  * Want to advertise validity times for coverage data availability.
>  * Challenge: create 3D/4D grid from irregular grids with missing data.
>  * Needs to group coverages by collections (other amount of coverages
>    is unmanageable) with their own metadata. Note that the need to
>    define collection of coverages is probably a wider than the MetOcean
>    domain. Generalization will be investigated.
>  * Custom WCS operations: DescribeCoverageCollection,
>GetCorridorCoverage.
>
>An OGC document is hoped for the end of this year.
>
>The group provided some patterns of data extraction. For example
>extracting vertical profile data for a trajectory (marine example:
>sonar) = trim operation expressed in the CRS of the trajectory. The
>group had a discussion about vertical CRS of the kind "pressure in hPa
>relative to a changing datum (a pressure surface)". The action for now
>is to take a closer look to ISO 19111-2 (parametric CRS). I think that
>Apache SIS too should take a closer look to ISO 19111-2.
>
>The MetOcean group presented "ensemble forecasts": producing more than
>20 parallel forecasts based on original observations in order detect
>"butterfly effect". Some statistical numbers of interest are quartile
>values, decile values, 95% and 5% percentile values, mean and mode. Open
>question is: can those needs be adressed by the NetCDF-Uncertainty
>extension?
>
>The MetOcean group has a projects on GitHub [3] providing the following
>resources:
>
>  * World weather symbols, as SVG or PNG files.
>  * WMO Regional Associations GeoJSON.
>  * WMO core metadata profile 1.3. They provide an application
>    performing validation for a profile of ISO 19115 metadata.
>
>The last point is related to Apache SIS, since we implement ISO 19115. I
>will create a "Provides a meterological profile of ISO 19115" JIRA task.
>Since I think there is an other Apache project related to climate, maybe
>there is an opportunity to contact each other here?
>
>
>
>Big data
>-------------------------------------------------
>Big data has been defined as the analysis on multi-dimensional arrays of
>size several orders of magnitude above engine's main memory. A
>discussion working group has been formed for investigating possible
>issues with OGC specifications for achieving this goal. Chairs have been
>nominated. As a side note, the European Space Agency (ESA) organizes a
>conference on big data from space on November 12-14th, 2014 in Fracati,
>Italy.
>
>
>
>Moving features
>-------------------------------------------------
>A reference implementation named "Mobmap" has been shown. This
>implementation run on Chrome browser and uses CSV files (points only) as
>inputs. They were discussion about using NetCDF as a more efficient
>binary storage format, but there is a difficulty in complying to the
>NetCDF "trajectory" convention. An alternative could be to take some
>liberties regarding the NetCDF trajectory convention, but this is
>something that peoples would prefer to avoid.
>
>The specification had only minor editions, and now includes the use case
>provided by Nadeem Anjum on this mailing list. A final version of Moving
>Feature specification is expected for December.
>
>They were an interesting discussion about JSon being - as surprisingly
>as it may seem - more verbose than XML for data like the Moving Feature
>ones, because of massive repetition of keywords. I'm not a JSon expert
>so I can not elaborate...
>
>
>
>CITE Tests (Team engine):
>-------------------------------------------------
>The "Team engine" is the testing framework at OGC. It is different than
>the "GeoAPI-conformance" module that we use for Apache SIS. OGC is
>working on making Team Engine easier to use - currently it has been
>reported that an expert needs 2.5 hours to configure and run tests. It
>is too early for Apache SIS to use Team Engine, since we do not yet
>implement web services. When we will start looking at CITE, ideally I
>would like to see if some CITE-GeoAPI integration are possible.
>
>
>
>Miscellaneous
>-------------------------------------------------
>Some related initiatives mentioned in the meeting are:
>
>  * Integrated Ocean Observing System (IOOS) [4]
>  * Integrated Justice Information System (IJIS)
>  * WMO Climate Data Management System Specification (CDMS)
>
>They were also a mention about recent and coming discussion in other
>organizations about whether we should keep leap second. The
>International Atomic Time (TAI) currently differs from Coordinated
>Universal Time (UTC) by 35 seconds due to leap seconds added in the last
>decades. Some organizations want to suppress leap seconds. No decision
>has been taken yet. Of course the decision does not depend on OGC, but
>opinions are collected.
>
>OGC is still experimenting ways to publish their specification as web
>pages. A prototype is available for the GeoPackage specification.
>However there is not yet a policy for allowing external projects - like
>Apache SIS - to provide links to a stable anchor of OGC specifications.
>For example if Apache SIS wants to link to a specific clause of an OGC
>specification, whether this will be possible is still an open question.
>
>    Martin
>
>
>[1]
>http://sis.apache.org/apidocs/org/apache/sis/storage/netcdf/AttributeNames
>.html
>[2] http://external.opengeospatial.org/twiki_public/CoveragesDWG/
>[3] https://github.com/OGCMetOceanDWG
>[4] http://www.ioos.noaa.gov/
>

Reply via email to