Please, if we bring CF semantics in, let's expand them along the way
to be more... semantically interoperable. (I'll be trying to engage
or start a few TRAC discussions in the CF community to move that along.)
Re "Isn't it just a way to get an OGC stamp of approval on legacy
systems", the value may be more obvious if we reword that question as
"Will it be useful for the NetCDF specification(s) to be approved and
managed by a formal standards body such as OGC?" (Every time I see
"legacy system" I feel like NetCDF is being called a dusty relic, or
something more unattractive.)
I think if NetCDF advocates and OGC do it right, this could help both
quite a bit, and the community as well. (NetCDF through external
review and clarifications, and OGC by embracing and associating with a
larger set of geo-enabled specifications. For example.) It might even
increase the rate at which integrative capabilities are developed and
communities are connected.
Of course, it could go the other way too. I hope the expectations and
processes are made clear at the beginning of the process, so everyone
goes in with their eyes open.
John
On Aug 26, 2009, at 9:06 AM, Robin, Alexandre wrote:
Hello,
IMHO it makes complete sense to bring CF semantics to OGC as this
part hasn't been completely addressed anyway, plus it is probably
reusable with other encodings such as GML application profiles and
SWE Common.
I fail to see however why it is necessary to bring the NetCDF binary
format and API to OGC just to work on it. I am not sure I understand
what everybody gains in bringing this to the OGC. Isn't NetCDF
already a standard in its own communities? Why do these communities
need OGC? Isn't it just a way to get an OGC stamp of approval on
legacy systems?
One can also see the NetCDF API as just another API like GDAL,
geotools, JAI, etc... I think enabling the NetCDF API to make use of
OGC encodings and web interfaces (in addition to NetCDF and DAP for
instance) would bridge a HUGE gap without requiring NetCDF to become
an OGC standard itself.
I know integrating read/write capabilities to/from SWE Common could
be done 100% transparently for existing users of software relying on
the NetCDF API. Integrating some aspects of remote access via WCS or
SOS could also be done pretty nicely I believe.
Regards,
-------------------------------------------------
Alexandre Robin
Spot Image, Web and E-Business
Tel: +33 (0)5 62 19 43 62
Fax: +33 (0)5 62 19 43 43
http://www.spotimage.com
Before printing, think about the environment
-----Message d'origine-----
De : wcs-2.0.swg-
bounces+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx [mailto:wcs-
2.0.swg-bounces
+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx] De
la part de John Caron
Envoyé : mardi 25 août 2009 20:16
Cc : Unidata GALEON; wcs-2.0.swg
Objet : Re: [WCS-2.0.swg] [galeon] CF-netCDF standards initiatives
Robin, Alexandre wrote:
Hi Steven,
I understand that you don't have time to spend in OGC however if non
of the major players are involved in the process and keep pushing
their own legacy formats instead then for sure our standards are
doomed...
You know NetCDF is not the only one. The military has NITF and a
bunch
of STANAG standards, meteorology people have their own, navigation
has
NMEA, etc... All of them are heavily used throughout their
community and
required great investments. Some of them actually deal with
coverages,
ocean or atmospheric data so they do overlap with NetCDF earth
science
focus. So which ones do we pick?
Its true that NetCDF is just another legacy file format. But its also
true that NetCDF is a *general-purpose* scientific data format,
that is
not specific to meteorology, climate research, or any earth science
discipline. In this sense it is different from NITF or NMEA, or
GRIB or
BUFR, or any domain specific format. This is an important distinction
which is both a strength and weakness for transporting binary data.
(BTW, the file format hadnt changed in 15 years, when a few years
ago we
added one variation to allow sizes to exceed 2 Gb. So there are now
exactly two variations of the "netCDF classic file format". Note
that im
not talking about netCDF-4/HDF5 format, which has many variants.)
None of this is all that important, as Bryan rightly point out. The
hard
stuff is the semantics.
_______________________________________________
WCS-2.0.swg mailing list
WCS-2.0.swg@xxxxxxxxxxxxxxxxxxxxxxxx
https://lists.opengeospatial.org/mailman/listinfo/wcs-2.0.swg
_______________________________________________
galeon mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
---------------
John Graybeal
Marine Metadata Interoperability Project: http://marinemetadata.org
graybeal@xxxxxxxxxxxxxxxxxx
