I agree with your conclusions, to summarize:
1. One could use TDS with NcML to create multiple views of the same dataset to acheive what you want on the server. NcML is useful for modest amounts of metadata manipulation.
2. WCS provides reprojection/resampling capabilities (note TDS/WCS does not provide this), which for some applications is more useful but quite different than what we are talking about, namely providing multiple sets of coordinate values for the unmodified data.
Also extending CF to allow these multiple sets in the same file seems like a good idea to me. Im my view, the lack of an explicit coordinate system (or grid mapping) object makes things slightly more complicated. Once you have one, allowing more than one seems natural.
Bert Jagers wrote:
> Hi Steve,
>
> So the OGC community has (at least so far) decided that explicit
> translations between coordinate reference systems do not belong
> inside of their data representations.
>
> This doesn't surprise me. GIS systems should be able to convert between
> different coordinate reference systems. I would not worry about reading
> netCDF files containing lat/lon coordinates into a GIS package. I was
> more thinking of all the other tools that are used. For instance MATLAB
> won't do automatic on the fly conversion between coordinate reference
> systems. Although, with MATLAB you can either use The MathWorks' or Rich
> Pawlowicz's mapping toolbox to do the conversion manually once you have
> figured out what the appropriate transformations are. Several other
> visualisation program's, however, are neither GIS product nor are they
> as programmable as MATLAB. For such programs it would be good to have
> the appropriate coordinate data already in the file.
>
> CF has already gone one step beyond this (and adds value in doing
> so). But I believe that keeping CF "lean and mean" will pay off
> over the long term, so we should carefully consider alternative
> solutions outside of CF before adding further complexity to the
> standard. (Sorry if I'm sledge hammering this point.)
>
> I agree, lean and mean is best in general.
>
> [some TDS and NcML information]
>
> Okay, all immutable data is stored only once. Separate grid files for
> local coordinates. Local TDS server required to combine the files based
> on NcML XML file. I will investigate this line further, but that will
> take some time.
>
> If it is local files that your community really needs, and the
> service-oriented aspects of TDS do not add any value, then (as you
> have said) you don't need OPeNDAP. In fact, there is plenty of
> richness in the netCDF utilities that already exist (e.g. nco), so
> that you can create German and Dutch flavors of your files using
> nothing but simple scripts to do the same things that are described
> from TDS above. No changes to CF are required. And it would not
> be a particularly messy data management task.
>
> Thanks for the information. I will have a look at the NCO tools.
>
> In the footnote I was assuming that the theoretical discussion was
> of grid objects that described both horizontal and vertical and
> files that mixed 2D and 3D spatial grids. There are plenty of
> subtleties in the vertical, too, particularly for hybrid coordinate
> models. Sorry for opening up this distracting point.
>
> I agree that grids in the vertical direction are far from trivial. It
> seems that keeping horizontal and vertical coordinates separated as much
> as possible (maybe have anisotropic grid objects).
>
> Thanks for your patience with this process - Steve
>
> Thank you for your comments and ideas.
>
> Best regards,
>
> Bert
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Dec 15 2006 - 16:12:52 GMT
