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 *******************************************
cf-satellite archives: