NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ron,
I notice that while some GML objects are used, rather key objects like netcdfGridCoverage are not derived from the corresponding GML objects (e.g. gml:GridCoverage ) and hence would not be recognized as such by GML processing software. Is this intentional?
NcML-GML is an extension of ncML data model; thus, netcdfGridCoverage extends the netcdfType element defined in ncML. More generally, the ncML-GML aims at bringing together netCDF and geographic coverage data models, making them complementary. An important feature of ncML-GML document is that it contains a valid ncML core document, from which you can easily generate a netCDF file.
Another important ncML-GML requirement was to keep the extension as simple as possible, introducing only the geographic coverage metadata supported by our community.
Naturally, this is a progressive process. As we discussed in a previous email, the opportunity to develop a future ncML-GML version which is a GML application is already on the table.
Indeed, ncML-GML version 0.7 is more complete and GML-oriented than version 0.3. Anyway, the starting point and the main motivation for ncML-GML are, respectively: netCDF + conventions dataset and to improve the description of netCDF dataset semantics.
GALEON is an important opportunity to test the interoperability level required and supported by our community.
Cheers, ---Stefano
galeon archives: