<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-----Original Message-----<br>From: Frank Warmerdam [mailto:<a href="mailto:fwarmerdam@gmail.com">
fwarmerdam@gmail.com</a>]<br>Sent: Thursday, August 18, 2005 2:24 PM<br>To: Norman Barker<br>Cc: <a href="mailto:gdal-dev@lists.maptools.org">gdal-dev@lists.maptools.org</a>; <a href="mailto:galeon@unidata.ucar.edu">galeon@unidata.ucar.edu
</a><br>Subject: Re: [Gdal-dev] RE: GDAL netcdf convention CF support<br><br><br>On 8/18/05, Norman Barker <<a href="mailto:nbarker@rsinc.com">nbarker@rsinc.com</a>> wrote:<br>> [Norman Barker]<br>><br>> Hi,
<br>><br>> this is a really exciting announcement. I have run ncdump on my netcdf file<br>> and checked the variables, and gdalinfo picks up the lat, lon, and ozone<br>> vars ok. It puts the z-levels in bands within the data file which is ok
<br>> since that was the way that we had done it with geotiff. It has lost the<br>> information attaching the band level to an atmospheric height. Even if this<br>> was a comma separated index string it would be useful. It has also lost
<br>> the Time dimension stamp within the file. Again is this could just be a<br>> metadata tag that would be great.<br><br>Norman / Denis,<br><br>I agree that attaching the dimension value(s) unrolled as bands as<br>
band metatadata would be desirable.</blockquote><div><br>
I could write the metadata such as <br>
<br>
GDALInfoBands = "times X isobaric (2 x 19 )"<br>
</div><br>
Gdal order the bands in the following way:<br>
<br>
band time isobaric<br>
------ ----- ---------<br>
1 1 1<br>
2 1 2<br>
... .... ....<br>
19 1 19<br>
20 2 1<br>
21 2 2<br>
... ... ...<br>
38 2 19<br>
<br>
<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I would like to help wrap this into MapServer WCS if possible, if I am<br>> missing something with my comments above please let me know. This is great
<br>> though, is has caused great excitement in our office!<br><br>Are you interested in having GDAL write netCDF files so that<br>MapServer can return netCDF files? As far as I know, there is no<br>support for creation/writing in the generic netcdf module in GDAL but
<br>it seems like it might not be that hard to implement.<br><br><snip><br><br>Ideally
having MapServer return netCDF would be a nice to have, but as we have
discussed before about 3D BBOX + parameters (and this is an aim of OGC
GALEON), there is little to differentiate between a geotiff and a
netCDF file (or any banded file) when implemented this way (2D + bands
for the z-level). If we could access netCDF through
MapServer in an ND sense it would be different, I hope this is
something we can work through in GALEON. It is still
possible to make a very workable WCS with 2D + bands though, and I am
interested in a way to keep the metadata within the file.<br><br>However
most of the work (for example when you have 40TB of data as our domain
user does!) is in the conversion, so having gdal and hence MapServer
read CF netCDF is a major plus (really good!), and makes using
MapServer WCS even easier.<br><br>This is great though, I am compiling up MapServer with this new GDAL as we speak!<br><br>Hats off to Denis and Frank!</blockquote><div><br>
Thanks a lot for the Kuddo!! The driver should work for more than 4 dimensions, but I have not data to check it. <br>
If you can provide me with 5D or 6D data, I could test the netcdf
driver. The number of bands grows a lot with 4D data, the RUC.nc
test file provided by GALEON has about 296 bands....<br>
<br>
Denis<br>
P.S. I will check in an new version of netcdfdataset.cpp, I found an error in the program this morning.<br>
<br>
</div><br></div><br>