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-----
