Re: Meeting about improving the GRD API.

• To: Ian Barrodale <ian@xxxxxxxxxxxxx>
• Subject: Re: Meeting about improving the GRD API.
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Wed, 14 Feb 2007 12:32:58 -0700

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:

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

• References:
  • Re: Meeting about improving the GRD API.
    • From: John Caron
  • Re: Meeting about improving the GRD API.
    • From: Ian Barrodale
  • Re: Meeting about improving the GRD API.
    • From: John Caron