NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Hi Martin, Thanks for the fast feedback. Before I answer your questions, I would just like to let you know that the EUMETSAT Data Centre is currently planning the implementation NetCDF formats as the common delivery format for all orderable data sets from the Archive. A pilot has already been performed for the level 1B and 2 products from the Metop-A ASCAT instrument and these are available for user feedback under the following URL: http://gsics.eumetsat.int/thredds/ascat.html The ASCAT NetCDF products were also presented to users in this year's EUMETSAT user conference held in Oslo. The development of usable NetCDF formats is our top priority as we want to ensure that all users (novice and expert) can immediately use our data so it is very important that guidelines regarding best practises, filename conventions, CF-Conventions and standards are followed. A Format Advisory Group has been set up at EUMETSAT to discuss these guidelines with a view to publishing them so that users are aware how our data is organised and also to propose updates to the CF-conventions for satellite data as work is needed here (hence the existence of this mailing list! :o) Here are the answers to your questions: - Why are southMostLine, eastMostPixel, northMostLine, westMostPixel, and numberOfChannels dimensions and not attributes ? Apart from the HRV channel, these values remain constant for all channels in the data sets so we can be specify them as global attributes. If the channel arrays store different 'sub-area' then we would need these value to be stored as variable attributes for each channel array. This is not the case for our NetCDF data set i.e. all channel arrays hold the same area for the same time. Note, the NetCDF file follows the Unidata recommendation for identifying the coordinates of the data in the channel arrays (Coordinate System Object Model - Current Encodings). Longitude and latitude arrays exist in the data set and their contents are used to geo-locating the pixel counts for each channel onto a projection. See: http://www.unidata.ucar.edu/software/netcdf-java/CDM/ - - How would you deal with the inclusion of the HRV channel ? We have not implemented the HRV channel in our NetCDF data sets as GSICS does not use this channel for calibration. To implement this channel in our NetCDF data sets, we would just need to add another longitude and latitude array specifying the location of each HRV pixel counts and a 2D array holding the HRV pixel counts. - - 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 ? Not sure what you mean here, perhaps the following explain it: For the pixel count in ch1( y, x ), it is located at latitude lat( y, x ) and longitude lon( y, x ). By assigning the lat and lon as the coordinates system for any channel array, applications know how to geo-locate its contents. float lat(y,x); float lon(y,x); int ch1(y,x); ch1:coordinates="lat lon"; int ch2(y,x); ch2:coordinates="lat lon"; - - On the cf-satellite list, we have long been discussing "band"s. Did you consider using those ? Sorry, I don't know what bands are. - - Did you consider grouping channels in 3d arrays instead of having them separated ? I'm not sure what value a 3D arrays would give to the data. Applications like the Unidata can plot the arrays on top of each other if needed. As mentioned above, we want our data to be immediately usable by all users and by following guidelines, we add values to the data as the contents can be examined and plotted by existing free NetCDF applications without any further processing by the users. - - Could you provide in the file calibration coefficients needed to convert radiances to reflectances and brightness temperatures ? Yes we can add any variable attribute to the channel arrays to support the needs of our users. The power of NetCDF is as long as we don't remove or reorganise any attributes and/or arrays, existing users and applications will not 'break' by the change. The only concern here is we need to ensure that a standard convention is followed for representing measurements that can be stored in different units (e.g. temperature can be stored as Celsius, Fahrenheit, Kelvin, ... ). What unit is used should be based on the needs of the 'core' users and this unit with a standard name should be included in the CF-conventions. Regards, Pete. -----Original Message----- From: Martin Raspaud [mailto:martin.raspaud@xxxxxxx] Sent: Monday, October 24, 2011 2:05 PM To: cf-satellite@xxxxxxxxxxxxxxxx; Peter Miu Subject: Re: [cf-satellite] cf-satellite Digest, Vol 14, Issue 1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 ? - - On the cf-satellite list, we have long been discussing "band"s. Did you consider using those ? - - 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 ? 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 archives: