Hi Norman:
Norman Barker wrote:
Hi John,
thanks for the mail, I hope you are well. I have answered your
questions inline below, please ask more if you
want. We are treating this very much as learning, knowledge sharing
exercise.
Q. netcdf files - are you assuming CF conventions for georeferencing?
A. We are, and we aren't. The only place where are input files aren't
CF compliant is the timestamp, and we
have placed the format of this in an external properties file so we
can change it. Our input files are CF compliant apart from this
Q. multiband geotiff - what did you map into the multiple bands?
A. We have mapped the vertical dimension (geoZ) of the netCDF file
into the bands. Using the describeCoverage
RangeSet elements we were able to put a lookup between the bands,
0,1,...27 to the actual z-levels values from
the netCDF file, and our client shows meaningful values rather than
band numbers. I can send you parts of the
describeCoverage XML if you like when I am in back in the office.
is there any information in the geotiff as to the meaning of the bands?
Q. do you pregenerate the geotiff or generate on the fly?
A. We pregenerate the netCDF file because we have used Java and
MapServer is in C. However you make an interesting point, I wonder by
using python whether I could hook an 'on the fly' conversion using
your libraries?
I am a bit confused. Arent the original data in netcdf, and you are
generating geotiff from them?
Q. do you use "data sample" geotiff format, or greyscale or ??
A. We use 16bit floating point geotiff format, so the values of the
netCDF file are preserved. This is the same format as USGS use for
DEM geotiffs.
Do you mean 32 bit? i didnt know there was a 16 bit IEEE floating point
format.
Q. Can you handle a request that has multiple times and/or vertical
levels?
A. We can handle a request that has multiple levels no problem, since
it is possible to request different
bands of a geotiff using MapServer WCS, so our client converts from
the metadata description in describeCoverage of the z-levels to the
band numbers before making the request, so it can ask for &bands=1,4,5,6
say. We can only request a single time, since it is one geotiff file
per time. However the describe coverage
lists the temporal dimension correctly (as per the WCS spec) and the
Key Value pair added to the request is
&time=YYYY... It would be good to be able to request multiple times,
and perhaps zip them up before downloading to the client. However for
the display, downloading per single timestep gives a more interactive
feel.
ok, thanks for the info!
Norman Barker