Re: [cf-satellite] cf-satellite Digest, Vol 14, Issue 6

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

Morning Tom,

Thanks for your input, I will take a look at it in more detail next week
and get back to you if I have any queries.

Regards,

Pete.

-----Original Message-----
From: cf-satellite-bounces@xxxxxxxxxxxxxxxx 
[mailto:cf-satellite-bounces@xxxxxxxxxxxxxxxx] On Behalf Of 
cf-satellite-request@xxxxxxxxxxxxxxxx
Sent: Wednesday, October 26, 2011 8:00 PM
To: cf-satellite@xxxxxxxxxxxxxxxx
Subject: cf-satellite Digest, Vol 14, Issue 6

Send cf-satellite mailing list submissions to
        cf-satellite@xxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://mailman.unidata.ucar.edu/mailman/listinfo/cf-satellite
or, via email, send a message with subject or body 'help' to
        cf-satellite-request@xxxxxxxxxxxxxxxx

You can reach the person managing the list at
        cf-satellite-owner@xxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cf-satellite digest..."


Today's Topics:

   1. Re: cf-satellite Digest, Vol 14, Issue 1 (Tom Rink)
   2. Re: cf-satellite Digest, Vol 14, Issue 1 (Kenneth Casey)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Oct 2011 10:44:56 -0500
From: Tom Rink <rink@xxxxxxxxxxxxx>
To: Martin Raspaud <martin.raspaud@xxxxxxx>
Cc: cf-satellite@xxxxxxxxxxxxxxxx
Subject: Re: [cf-satellite] cf-satellite Digest, Vol 14, Issue 1
Message-ID: <4EA82AF8.4070203@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi Martin, Peter

On 10/24/11 7:04 AM, Martin Raspaud wrote:
> On 24/10/11 11:55, Peter Miu wrote:
>> Hi,
>>
>> The EUMETSAT Data Centre Archive has developed a SEVIRI MSG15 data sets to 
>> support GSICS.
>> GSICS (Global Space-based Inter-Calibration System) is a WMO and CGMS 
>> initiative to
>> improving and harmonise the quality of observations from operational weather 
>> and
>> environmental satellites of the Global Observing System (GOS).
>>
>> Examples of these SEVIRI MSG15 "GSICS" data sets can be found under the 
>> following EUMETSAT THREDDS server.
>>
>> http://gsics.eumetsat.int/thredds/catalog/msg2-seviri/catalog.html
>>
>> The data sets have been developed using Unidata guidelines for gridded data 
>> i.e. the data sets can be
>> loaded into Unidata tools and they will be geo-located correctly.
>>
>> The organisation of these NetCDF files would be relevant for discussion here 
>> and we (EUMETSAT&  the GSICS partners)
>> are very interested in developing CF conventions applicable for GEO and LEO 
>> satellites.
>>
>> Examples of LEO NetCDF data sets can also be found on the above server.
>>
>> We have started preparing some guidelines for NetCDF, see:
>>
>> https://gsics.nesdis.noaa.gov/wiki/Development/NetcdfConvention
>>
>> For more information on GSICS, please take a look at:
>>
>> http://gsics.wmo.int/
>>
>> http://www.star.nesdis.noaa.gov/smcd/GCC/
>>
>> http://www.eumetsat.int/Home/Main/AboutEUMETSAT/InternationalRelations/CGMS/SP_1226312587804?l=en?l=en
>>
>> If you have any questions, please don't hesitate in contacting me.
> Hi,
>
> First, I have to say that I am by no means a nedcdf nor cf expert...
>
> I also have to say that I am very happy that Eumetsat decided using
> netcdf4, especially with cf conventions.
>
> But here are some things that I was wondering looking at a Seviri file:
>
> - - Why are southMostLine, eastMostPixel, northMostLine, westMostPixel,
> and numberOfChannels dimensions and not attributes ?
> - - How would you deal with the inclusion of the HRV channel ?
> - - Are the longitudes and latitudes values different from what a
> "vertical perspective" with right parameters would provide ? If they do,
> why ? If they don't, why not include a grid-mapping definition ?

We've defined a netcdf structure for the GOES-R ABI (Advanced Baseline 
Imager).
For navigation, similar to SEVIRI, the ABI defines a fixed grid (FGF) of 
equal angle
spaced view angles from an nominal stationary point in space.  The grid 
can be represented
as a cross product of 2 one dimension arrays of the north-south, east-west
views angles in radians.  The VerticalPerspective CF definition won't 
work here
because it's a type of Map Projection which defines the transform x,y 
(kilometers
for instance) <-> (Lon,Lat).  Instead of two 1D arrays of view angles, a 2D
array of computed map projection plane values for the FGF views would
be required which defeats the purpose of defining the navigation
via a transform algorithm.  We didn't want rewrite metadata 
interpretation and
visualization components in the software, so we defined a 
"grid_mapping_type"
for the ABI FGF whose "projection_x,y_coordinate" could be radians 
instead of km.
Effectively a projection (radians, raidians) <-> (lon,lat).  We did this 
by extending,
actually some modification were required,  classes distributed in the 
ncIdv.jar.
See attached netcdf header file.  Another nice advantage to the FGF is that
master lon/lat files don't change, and can be indexed directly if desired.


Another issue relates to defining a mechanism to provide a time-stamp for
a file, ie. time dimension length = 1.  Many data providers will not 
subscribe
to the notion of a 3D variable (time,x,y) with time=1.  I'm not agreeing or
disagreeing, but engineers associated with the GOES-R project said they
would not do this.  So we have a Time(time) variable to hold the nominal
time of the image.


> - - On the cf-satellite list, we have long been discussing "band"s. Did
> you consider using those ?

I think at the very least, the concept of band dimension should be accepted
as a best practice.

> - - Did you consider grouping channels in 3d arrays instead of having them
> separated ?
> - - Could you provide in the file calibration coefficients needed to
> convert radiances to reflectances and brightness temperatures ?

In these files scaled radiances are converted to radiances via the 
scale/offset
variable attributes, and coefficients required to obtain reflectance factor
or brightness temperature are included.  The former happens automatically
through the Java-NetCDF library, though this might not always be desirable.


Tom

> Thanks a lot for making this data available !
>
> Best regards,
>
> Martin Raspaud
> SMHI, Sweden
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Red Hat -http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOpVRaAAoJEBdvyODiyJI4G70IANwTM5v+zH5IFZuKgzcBtc/0
> DyhJxONvdE2ga60D7dU3WAUzi+bmkmXnCzdZj+vFZclIHthmLZLuVPEqj1JRS9RX
> jQ8IUUVzM+8nLcfAYarPLnM2dbOXPGJW7gpKDvgYuGBvrNxQ7Ipn1QQdhngjOJrr
> YuRiFOlPKwMizmVNDGj4CDyphqciU0bHsxztZGwe39Ux0rd+/LlcLh96pGt1cTHt
> 5boI3ftkG0eEwqBfOdnOBTdFM6Zrwi8cxegVueGnfoKLmYfK4z95/38LcqfpbfIw
> gGp7FCZtbB5wlvRHWwDvts5OhHPZLY8Hz3QeKPU5+paEaRK3N9n8HKce5rsJra0=
> =wT2W
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> cf-satellite mailing list
> cf-satellite@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, 
> visit:http://www.unidata.ucar.edu/mailing_lists/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.unidata.ucar.edu/mailing_lists/archives/cf-satellite/attachments/20111026/92866cba/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hdr.txt
URL: 
<http://mailman.unidata.ucar.edu/mailing_lists/archives/cf-satellite/attachments/20111026/92866cba/attachment.txt>

------------------------------

Message: 2
Date: Wed, 26 Oct 2011 11:53:45 -0400
From: Kenneth Casey <Kenneth.Casey@xxxxxxxx>
To: Tom Rink <rink@xxxxxxxxxxxxx>
Cc: cf-satellite@xxxxxxxxxxxxxxxx
Subject: Re: [cf-satellite] cf-satellite Digest, Vol 14, Issue 1
Message-ID: <1E04FBAC-43CB-4CAA-AE62-5FDF5A378856@xxxxxxxx>
Content-Type: text/plain; charset="windows-1252"

Hi All - on this topic alone, I would add that every data producer in the 
GHRSST family does exactly this? all GHRSST-compliant data sets use three 
dimensions, with time=1.  As a server of the data, I can say that not once has 
a user complained either.  As a producer of GHRSST compliant data, I can't 
fathom why anyone would have heartache about it.    GHRSST still has a time 
variable of course, and we have found that including the time dimension in the 
specification has allowed for the production of some higher-level products that 
would not otherwise be possible. For example, if someone wanted to put a whole 
year of daily data into a single file, they could and still remain 
GHRSST-compliant.  None of the operational data producers in GHRSST do this, 
but we've done it for some of the retrospective inter-comparison work.   GHRSST 
uses the time dimension in its L2, L3, and L4 specification.

Ken

p.s. - GHRSST is Group for High Resolution SST, http://www.ghrsst.org.  GHRSST 
Data Specification Version 2.0 is at:

https://www.ghrsst.org/files/download.php?m=documents&f=110930142648-GDS20TechnicalSpecificationsv20.pdf


On Oct 26, 2011, at 11:44 AM, Tom Rink wrote:

> Another issue relates to defining a mechanism to provide a time-stamp for
> a file, ie. time dimension length = 1.  Many data providers will not subscribe
> to the notion of a 3D variable (time,x,y) with time=1.  I'm not agreeing or
> disagreeing, but engineers associated with the GOES-R project said they
> would not do this.  So we have a Time(time) variable to hold the nominal
> time of the image.  

[NOTE: The opinions expressed in this email are those of the author alone and 
do not necessarily reflect official NOAA, Department of Commerce, or US 
government policy.]

Kenneth S. Casey, Ph.D.
Technical Director
NOAA National Oceanographic Data Center
1315 East-West HighWay
Silver Spring MD 20190 USA
+1 301-713-3272 x133
http://www.nodc.noaa.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.unidata.ucar.edu/mailing_lists/archives/cf-satellite/attachments/20111026/a8684324/attachment.html>

------------------------------

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


End of cf-satellite Digest, Vol 14, Issue 6
*******************************************



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