NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: