Ian Barrodale wrote:
Please see lower down for our response to John's comments of yesterday.
At 03:25 PM 2/12/2007, John Caron wrote:
Ian Barrodale wrote:
Hi All:
Based on your feedback (John and Ted), we've been talking and have
an interesting project idea - brought up today by Peter.
If we were able to put GRD database support into the Java netCDF
library and use THREDDS and TDS to serve data, we may also be able to
provide gridded data reprojection support.
What do you think of this idea please? Some details follow below.
If a grd:// URL was allowed to contain a bit of spatial reference text
so that not only did it specify the database server, login info, database
name, and variable name, but also the projection and its parameters
(sort of like an OPeNDAP subset specification) then the GRD could
reproject any of the gridded data (including satellite swath data such
as from a POES satellite) to a projection of the user's choice. The
spatial reference text could be tacked onto the grd:// URL in the records
returned by THREDDS according to some number of pre-specified
projections that we create.
Such a capability would help to support users like Dave Foley and
Roy Mendelssohn (copied) who have expressed an interest to us in
storing unmapped satellite data in a spatial database, as well as
other groups such as the NOAA/NESDIS CLASS archive. According to Peter,
the NOAA CoastWatch technical group has been talking for years about
how nice it would be to be able to pull unmapped satellite data out
of CLASS
in a user- specified projection rather than having to create mapped
products.
Have a great weekend.
Regards,
Ian
====================
Its a very interesting possibility. The core question is, *how does
the user specify the reprojection?*
The Current Plan is:
A special database table would be populated with a list of "projections
of interest" and the geographic extents to which they should be applied
(either expressed as a GRDBox or as a lat-lon rectangle). The THREDDS
catalog would then be populated with an entry for each grid paired up
with each projection whose geographical extent overlapped the grid. As a
refinement, the "projection of interest" table could also include a list
of table names so that certain projections were only applied to grids
from certain tables.
This means that the burden of specifying the set of "projections of
interest" would be on the administrator of the database. If the interest
is present, we could provide a variation of our map projection applet
(see http://www.barrodale.com/projectionDemo/index.html ) that allowed
trusted external users to interactively define projections and their
regions of interests, in essence, removing even this burden.
We welcome any comments on this Plan of course.
Regards,
Ian
Hello all:
Certainly this plan will work when there are a reasonable number of
projections. This allows the user transparent access of the data using the
netcdf API.
I would like to clarify/amplify my answer to the following question in the
context of using TDS:
2) How does the I/O SP architecture determine the I/O SP for a given
file:// <file://\> style URL? How would it know to handle a grd:// URL
differently?
Lets suppose that you hava a dataset with logical name "SatMet" with 3 projections, so perhaps we name these
"SatMet/proj1", "SatMet/proj2", "SatMet/proj3". If you were serving these up through
opendap, the URL would look something like:
http://server:port/thredds/dodsC/barrodale/SatMet/proj1
now we need to map "barrowdale/SatMet/proj1" to your dataset.
We are adding a way for implementors to do this, called a DatasetSource
(preliminary doc is at
http://www.unidata.ucar.edu/projects/THREDDS/tech/reference/DatasetSource.html
; note this is still experimental)
you could implement something like:
public class BarrodaleDataSource implements thredds.servlet.DatasetSource {
HashMap hash = new HashMap();
public boolean isMine(HttpServletRequest req) {
String path = req.getPathInfo();
return path.startsWith("/barrodale/");
}
public NetcdfFile getNetcdfFile(HttpServletRequest req, HttpServletResponse
res) throws IOException {
String path = req.getPathInfo();
path = path.substring("/barrodale/".length());
String databaseURL = (String) hash.get(path);
if (databaseURL == null) {
res.sendError(HttpServletResponse.SC_NOT_FOUND);
return null;
}
return new BarrodaleNetcdfFile(req.getRequestURI(), databaseURL);
}
private class BarrodaleNetcdfFile extends NetcdfFile {
BarrodaleNetcdfFile(String location, String databaseURL) throws IOException {
super( new BarrodaleIOSP(databaseURL), null, location, null);
}
}
}
public class BarrodaleIOSP implements IOServiceProvider {
...
}
This is in the context of servlets, something similar can be done on the
client. We may end up doing both with a common mechanism. I thought it would be
useful to give a concrete possibility.
John
