Hello Bryan,
what you indicate is an item we will cover with our WCS server. It makes use of
our rasdaman (raster data manager) middleware to store n-D rasters in a
standard relational database. While import is from netCDF files, output can be
in any of the supported formats, like TIFF, BMP, HDF, VFF, etc. In the
underlying query language, rasql, this is simply accomplished by applying the
appropriate coder in the query:
select vff( rasterExpr )
from MyRasterCollection
would first evaluate the raster expression rasterExpr and then encode the result in vff,
provided of course the format can hold the result structure. Hence, by decoupling ingest
and retrieval from the transfer format we achieve "data independence" (in the
database community's sense) from data exchange formats. This technique is operational
since long in our WMS acting as a query translator from WMS into rasql, and we are
following the same approach now with WCS.
Regards,
Peter
Bryan Lawrence wrote:
Hi Ben
I'm intrigued to know why you would want to put satellite data (which
presumably starts in HDF or something similar) in NetCDF for an
*interoperability* experiment based on OGC protocols?
If the existing data format wont support an OGC server, then an approach based
on converting to NetCDF and using Stefano's middleware and taking part in
Galeon makes perfect sense ... However, if you have data which could be
served up directly by an alternative WCS implementation then I would have
thought you and the Galeon community would both benefit by showing how these
differing data host formats can be served up *together* using OGC protocols.
Of course it makes perfect sense to be involved using that data which starts
life in NetCDF as well ...
(Note the major assumption that someone has a good way of serving up the
satellite data via a WCS).
As a side issue, can anyone confirm that CF has a good way of encoding
satellite scenes?
Regards,
Bryan
