Fwd: [Tc] OGC Seeks Comments on NetCDF Enhanced Data Model Extension Standard

6 views
Skip to first unread message

Steve Foreman

unread,
Jun 6, 2012, 3:18:21 AM6/6/12
to wmo-i...@googlegroups.com
Hi everyone

we may need to put in a coordinated response to this. Please send comments to this Group so that Jeremy and Simon can decide whether we need a WMO response to the proposal.

Thanks

Steve

---------- Forwarded message ----------
From: <anno...@opengeospatial.org>
Date: 1 June 2012 16:40
Subject: [Tc] OGC Seeks Comments on NetCDF Enhanced Data Model Extension Standard
To: t...@lists.opengeospatial.org, p...@lists.opengeospatial.org



FOR IMMEDIATE RELEASE

Contact: in...@opengeospatial.org

*OGC Seeks Comments on NetCDF Enhanced Data Model Extension Standard*

June 1, 2012 - The Open Geospatial Consortium (OGC®) membership
seeks comments on an OGC candidate standard, the Network Common Data
Form (NetCDF) NetCDF Enhanced Data Model Extension Encoding Standard.
This document specifies an extension to the existing OGC Network
Common Data Form (NetCDF) Core Encoding Standard version 1.0.

The OGC netCDF encoding supports electronic encoding of geospatial
data, specifically digital geospatial information representing space-
and time-varying phenomena. NetCDF (network Common Data Form) is
widely used internationally to communicate and store many kinds of
multidimensional data, although it was originally developed for the
Earth science community. The netCDF data model is particularly well
suited to providing data in forms familiar to atmospheric and oceanic
scientists: namely, as sets of related arrays. NetCDF was developed
and is maintained and actively supported by the Unidata Program Center
(http://www.unidata.ucar.edu <http://www.unidata.ucar.edu/>
) of the University Corporation for Atmospheric Research (UCAR).

The netCDF classic data model has previously been established as the
core OGC CF-netCDF standard. With this extension to the core standard
for the enhanced data model, complex data structures can be
represented very easily, allowing for more efficient programming. In
performance-critical applications, the enhanced model provides
significant benefits. Moreover, if existing HDF5 (Hierarchical Data
Format, release 5) applications that depend on groups, user-defined
types, unsigned types, or strings produce or use these data, the
netCDF enhanced data model is required. The recently introduced
candidate NetCDF Enhanced Data Model Extension Encoding Standard is
the latest step in a longer-term plan for establishing CF-netCDF as an
OGC standard for binary encoding, which will enable standard delivery
of data in binary form via several OGC service interface standards,
including the OGC Web Coverage Service (WCS), Web Feature Service
(WFS), and Sensor Observation Service (SOS) Interface Standards.

The candidate OGC Network Common Data Form (NetCDF) NetCDF Enhanced
Data Model Extension Encoding Standard and information about
submitting comments on this document are available at
http://www.opengeospatial.org/standards/requests/88
. The public comment period closes on July 1, 2012.

The OGC is an international consortium of more than 445 companies,
government agencies, research organizations, and universities
participating in a consensus process to develop publicly available
geospatial standards. OGC Standards support interoperable solutions
that "geo-enable" the Web, wireless and location-based services, and
mainstream IT. OGC Standards empower technology developers to make
geospatial information and services accessible and useful with any
application that needs to be geospatially enabled. Visit the OGC
website at http://www.opengeospatial.org/contact.
_______________________________________________
Tc mailing list
T...@lists.opengeospatial.org
https://lists.opengeospatial.org/mailman/listinfo/tc

All OGC members are strongly encouraged to maintain a subscription to this list.



--
__________________________________________________
Dr Steve Foreman
Chief, Data Representation, Metadata and Monitoring
World Meteorological Organization
 



The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.
SAVE PAPER - Please do not print this e-mail unless absolutely necessary

Eizi

unread,
Jun 10, 2012, 10:53:18 PM6/10/12
to wmo-i...@googlegroups.com
Hi Steve,

I see no response.  I hope that's not only because we're busy.

For me the request for comment seems to be faithful description of current data model in NetCDF 4.  So those who are actually using NC3/4 should have no comment.

Thus the question is whether we, the operational meteorology, have comment.  I have none.

Roughly speaking it's definition of array and numeric types.  Concepts described in this doc, for example variable or dimension, is only building blocks of higher-level business logic or modelling.  The netcdf community has maintained their own one called CF conventions, and OPAG-ISS is working on another one called metce.  In that level there is need for harmonization, sorry about not fulfilling expectation by CBS (what I did actually is only joining discussion in CF-metadata and speak for operational meteorology regarding some standard names).  Anyway that doesn't relate to lower level structure, such as XML or, in this case, netCDF.  Their layer designs are so good.

Historically a practical weakness of the data model of netCDF 3 was lack of array of variable-length string.  But it is already augmented by NC 4.  And interoperability with GRIB doesn't require such thing.

If the doc were proposing new MIME type to be registered to IANA, we should pay some attention.  But indeed the doc is only describing de facto practice.

Best Regards,
Eizi
Reply all
Reply to author
Forward
0 new messages