[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does TDS really synthesize CF curvilinear coordinates for GRIB data?



thats seems viable, esp if
1) the 2D coords are not actually created unless requested, and

2) the coordinates attribute is

       coordinates: "time x y z lat lon";

ethan, what do you think? shall we task robb with this?

Steve Hankin wrote:


John Caron wrote:
are you asking this to be done on motherlode, or one of your servers?

we deliberately dont use 2D coordinates because of their size, and because the calculation can be done on the (our) client, which is more efficient.
what is your use case?
For UAF it is on "our own" (many distributed) servers where the primary issue lies. So if it is just a matter of knowing how to turn on the synthesis of the coordinates then we probably have a nice, quick fix.

As to use more general cases -- virtually all non-Java CF clients will likely find these datasets to be lacking in geo-referenced coordinates as-is. I agree with your point that it is more performance-efficient to compute the coordinates on the client. But until the coordinate synthesis capabilities are embedded universally into the netCDF libraries there's a pretty major CF georeferencing void here.

Since clients (like your own) that already have the coordinate-synthesizing capabilities in-built need not request the coordinates from the server, then there seems no down side to turning on the synthesis capabilities on the server. In fact, providing it on both the server and the advanced clients seems the best of all worlds: advanced CF clients remain efficient and less advanced CF clients still continue to get CF-intelligible, geo-referenced versions of the data.

   - Steve



Steve Hankin wrote:
Hi John,

Yes -- this is the Motherlode TDS.

Looking at the first link as an example, it contains a variable, "Polar_Stereographic", whose attributes describe the projection. There are "grid_mapping" attributes that point to it for the relevant dependent variables. So much of the CF compliance work has been done. What remains is for the IOSP to

   1. note that the grid_mapping machinery exists for a particular file
   2. inspect the grid_mapping parameters
   3. synthesize the latitude and longitude coordinate variables
   4. fix up the "coordinates" attributes of the dependent variables so
      that instead of pointing to

        coordinates: "run time y x"

           they point to

coordinates: "run time *my_synth_latitude my_synth_longitude*"

    - Steve

=================

John Caron wrote:
Steve Hankin wrote:
Hi John,

At the NCDC meeting we talked about IOPS's for various binary data formats. I *thought* I heard you say that the recent TDS IOSP for GRIB data would automatically synthesize the CF curvilinear coordinates. When I look at examples like the ones below on Motherlode, I spot only coordinates in kilometers. (polar stereographic and lambert conformal examples listed below)

Did I misunderstand something? What is your recommendation for getting generating the curvilinear (CF) coordinate variables that we need for the UAF project? We don't want to do it manually if it is already a solved problem.

   sorry to trouble you.  I know you're busy - Steve

http://motherlode.ucar.edu:8080/thredds/dodsC/fmrc/NCEP/GFS/Alaska_191km/NCEP-GFS-Alaska_191km_fmrc.ncd.html http://motherlode.ucar.edu:8080/thredds/dodsC/fmrc/NCEP/RUC2/CONUS_20km/surface/NCEP-RUC2-CONUS_20km-surface_best.ncd.html

we dont automatically generate the 2D coords, but we could. the main issue would be to figure out how to tell the GRIB IOSP to do so, ie configuration. Would this be a global setting, or per-dataset? I assume this is coming through a TDS?