Re: [cf-satellite] cf-satellite prototype beta

NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.

 On 8/24/2010 1:07 AM, Martin Raspaud wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

At the danish and swedish meteorolical institutes, we have implemented the
prototype suggestion.

We have two points we would like to discuss here:

- - Wavelength: we find it necessary to add the minimum and maximum wavelength
(spectral range) to the metadata. We think it is not enough just to specify one
wavelength for a band.

i think this is the same as a coordinate bounds, see section 7.1:

http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#cell-boundaries

- - Geolocalization: we have quite a lot of data that is easily represented on a
grid, but the CF-convention requires the grid of lons and lats to be calculated.
This is of course highly inconvenient for fixed grids (from a data storage and
transfer perspective). We suggest adding a proj-string (proj.4 string
definition) and an area-extent option in the convention for grids. To us, it
makes a lot more sense than maintaining a list of accepted pre-defined grids in
the convention.

1) there are a set of accepted projections in appendix F :

http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#appendix-grid-mappings

does your data fall into one of those. if not, can you describe?

proj-4 strings are an alternate representation, which have been discussed in the past on the CF list. you can include them, of course, but they are not currently part of the CF spec.

2) the question of having to include calculated lat/lons has also been discussed many times. I have advocated making these optional, but my opinion has not prevailed (yet). The Netcdf-Java software does not require them as long as a projection (grid_mapping) is specified. Other software may not know how to deal with the projections, so thats the argument for including.

Best regards,

Martin Raspaud, Adam Dybbroe (SMHI)
Esben Stigård Nielsen, Kristian Rune Larsen, Lars Ørum Rasmussen (DMI)


Tom Whittaker skrev:
We would like to suggest the following as a "starting point" that we
can refine toward the goal of agreeing on a "basic" set of metadata
and structure.  It is an example of a multi-banded image structure
that contains navigation on a point-by-point basis, and provides for
linear calibration.  The variable "names" are not critical, but the
"standard_name" should be used by applications to identify the
quantity.

(In the following, most of the numbers are just samples....to make it
more readable...)

dimensions:
        x = 5304 ;
        y = 2438 ;
        band=16

variables:
        float lat(y, x);
                lat:standard_name = "latitude" ;
                lat:units = "degrees_north" ;
                lat:valid_range = -90.f, 90.f ;

        float lon(y, x) ;
                lon:standard_name = "longitude" ;
                lon:units = "degrees_east" ;
                lon:valid_range = -180.f, 180.f ;

        int band(band);

        double time;
                time:long_name = "Nominal time of image";
                time:units="s since 1990-1-1 0:0:0";

        string bandname(band);
                bandname:standard_name = "band_name" ;

        float offset(band) ;
                offset:standard_name="linear_calibration_offset";

        float scale(band) ;
                scale:standard_name="linear_calibration_scale_factor";

        float wavelength(band);
               wavelength:standard_name="radiation_wavelength";
               wavelength:units="micron";

        string units(band);
                 units:standard_name="band_units";

        short ImageData(band, y, x) ;
                ImageData:coordinates = "band lat lon" ;
                ImageData:valid_min = 1s ;
                ImageData:_FillValue = 0s ;
                ImageData:missing_value = 0s ;

and for people who want/need to use a table look-up for calibration --
instead of the "linear_calibration..."
variables, we would use:

         float lookup(band, 256);
              lookup:standard_name="calibration_lookup_table";


As Russ Rew pointed out, if there is only one band, it would be
possible to dimension the Data as (y,x) but have the coordinates
attribute contain "band".


tom
(with help from Tom Rink and Kaba Bah)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMc2/IAAoJEBdvyODiyJI4w0wIAIw5QsZO9r3qmDnZLCz1ot7h
+ws9qbrxklIfIxN7vuaSxTedonv++ulc9E90LVqyxKcOn/e8GM5XGSREjw8CAVhk
8PynsvvfHnjI5y3yZchoIy/znIt7bgTtGtTA6Ll+zgk3M5QxuFSC+jonfLk1EWzJ
KFR6+Vtb64aztmBFYaKkvvOyUC0Xr/kVX7y+5K4sclHbQQaOSxO67yX1BdpWWPAX
hXWWuLuLUZQNNwzi5o6FgQ2jom4mUxhZu/xbjeSl4fyehCgcw1TnE9BQ1aikTSaZ
dIxTGI7gbHNARglIp2f7npaR6/yvCx5jQKf5SqgHQBSmyG2TTmzsxbokLACrsd8=
=w/WO
-----END PGP SIGNATURE-----


_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: 
http://www.unidata.ucar.edu/mailing_lists/

  • 2010 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the cf-satellite archives: