Dear All,
We would like to announce that we have a real-time OGC Web Map Service available for our MSG CPP
products. See
http://msgcpp.knmi.nl/ for more info. You can view the data online in the web portal
which uses this Web Map Service. Note that the content will be updated in the coming weeks, it is
not yet formally released.
We converted the original data to NetCDF with the Climate and Forecast conventions, we used the mail
discussion regarding this topic as input. We would like to thank everybody for their remarks.
These are the new standard names we use (besides the already existing):
- angle_of_rotation_from_solar_azimuth_to_platform_azimuth (degree): "The angle of rotation between
the solar azimuth angle and the platform azimuth angle";
- effective_radius_of_cloud_condensed_water_particles_at_cloud_top (m): "Particle effective radius
for both liquid and ice water particles";
- thermodynamic_phase_of_cloud_water_particles_at_cloud_top (status_flag liquid, ice and mixed):
"The thermodynamic phase of particles at the top of the cloud";
(I thought that these names were accepted in this list, but I can not find them in the standard name
table?)
We also use the following standard name to indicate the time of each pixel observation relative to time:
- time_offset (s): "Time of observation relative to time"
A complete overview of the file metadata is available here:
http://msgcpp.knmi.nl/data/MSGCPP_ncdump_2012-01-23_0001.html
We also have some sample files to try out at
http://msgcpp.knmi.nl/mediawiki/index.php/Testdata
Please feel free to try them out. An FTP service will be available when the final version is ready.
We are struggling with finding the correct CF projection parameters for this data. The data is in
satellite view projection, with the current settings we see a slight shift in IDV at the borders of
the disc (internally we use proj4_params, which is not a CF standard):
char projection ;
projection:proj4_params = "+proj=geos +lon_0=0.000000 +lat_0=0 +h=35807.414063 +a=6378.169
+b=6356.5838" ;
projection:long_name = "Projection information" ;
projection:grid_mapping_name = "vertical_perspective" ;
projection:latitude_of_projection_origin = 0.000000f ;
projection:longitude_of_projection_origin = 0.000000f ;
projection:perspective_point_height = 35807416.000000f ;
projection:height_above_earth = 35807.414062f ;
projection:false_easting = 0.000000f ;
projection:false_northing = 0.000000f ;
projection:EPSG_code = "none" ;
Has anyone a suggestion regarding this issue? When opening these files in IDV you should set the
"Data Source Type" to "Image Files (GINI)", otherwise you will have to wait a bit. When you open the
variables latitude and longitude you will see that there is a slight shift which increases near the
borders.
Please let me know what you think!
Thanks,
Maarten
On 02/03/2011 08:18 PM, tim.nightingale at stfc.ac.uk wrote:
> Hello All,
>
> I would love to see a time coordinate offset. Another use could be
> for rastered data, such as that generated by some scanning satellite
> instruments, where the along-track time stamp and the across-track
> time offsets can be separated. In these cases the time and time_offset
> variables could have completely different indices:
>
> dimensions:
> i = 40000; // along-track index
> j = 1000; // across-reack index
> variables:
> double time(i) ;
> :standard_name = "time"
> ...
> double delta_t(j) ;
> :standard_name = "time_offset" ;
> :ref_coordinate = "time" ;
> ...
> double pixel(i,j)
>
>
> on the assumption that pixel_time(i,j) = time(i) + delta_t(j). This
> would be somewhat more efficient than the conventional:
>
> dimensions:
> i = 40000; // along-track index
> j = 1000; // across-track index
> variables:
> double time(i,j) ;
> :standard_name = "time"
> ...
> double pixel(i,j)
>
> for storage space and would be a natural use for a coordinate offset.
>
> I'm not completely clear how any of the offset schemes should couple
> the coordinate/coordinate_offset pair to the :coordinates attribute of
> subsequent data variables, as both the data variable and coordinate
> offset would refer upwards to the base coordinate. Should we:
>
> a) trust the reading software to identify any associated offsets for
> a coordinate variable? (What happens if there's more than one?)
>
> b) add :coordinate_offsets attributes or similar to data variables,
> listing all relevant coordinate offsets, in analogy to the
> :coordinates attribute? (To avoid possible ambiguity/duplication,
> should we then leave out the corresponding :coordinates entry, as
> the offset :ref_coordinate attribute identifies this for us?)
>
> c) where appropriate, include the coordinate offset, and not the base
> coordinate, in the :coordinates attribute, as the reading software
> can then work its way unambiguously up the chain of references?
> (You could conceivably also have offsets of offsets of coordinates,
> with delta_delta_t:ref_coordinate = "delta_t", and so on!)
>
> d) something else?
>
> Regards,
>
> Tim.
>
> --------------------------------------------------------------------
> Tim Nightingale
> RAL Space
> STFC Rutherford Appleton Laboratory
> Harwell Oxford
> Didcot Phone: +44/0 1235 445914
> OX11 0QX Fax: +44/0 1235 445848
> United Kingdom Email: tim.nightingale at stfc.ac.uk
> --------------------------------------------------------------------
>
>
>
>
>
>
>
>
> On 03/02/2011 12:20, "Bentley, Philip" <philip.bentley at metoffice.gov.uk>
> wrote:
>
>> Hi folks,
>>
>> I wonder if there isn't a more generic pattern sitting behind these
>> proposals. On the assumption that people are likely to want to use
>> similar offsets for other coordinate variables - e.g. x_offset,
>> y_offset, z_offset, lat_offset, lon_offset, and so on - would there be
>> any merit in specifying the more general-purpose standard_name of
>> 'coordinate_offset', which would then be used in association with a new
>> attribute called, say, 'base_coordinate' or 'ref_coordinate' (comparable
>> to Jonathan's proposed 'relative_to' attribute) which would define the
>> reference/datum coordinate variable?
>>
>> Then, in CDL, we'd have something like...
>>
>> variables:
>> double time(time) ;
>> :standard_name = "time" ;
>> ...
>> double delta_t(time) ;
>> :standard_name = "coordinate_offset" ; # or just plain "offset" ?
>> :ref_coordinate = "time" ;
>>
>> ...
>>
>> (In some cases, of course, the time coordinate might be a scalar
>> coordinate, in which case the dimensions of the above two variables
>> would be different).
>>
>> Adopting an approach along these lines would seem to confer the
>> advantage of avoiding a proliferation of standard names of the form
>> 'X_offset'. That said, however, there are probably some CF nuances that
>> I've not thought of :-)
>>
>> Regards,
>> Phil
>>
>>> -----Original Message-----
>>> From: cf-metadata-bounces at cgd.ucar.edu
>>> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of plieger
>>> Sent: 03 February 2011 09:14
>>> To: Jonathan Gregory
>>> Cc: CF metadata
>>> Subject: Re: [CF-metadata] MSG CPP standard name for
>>> time_offset_of_observation / pixel_delta_time
>>>
>>> Dear Jonathan,
>>>
>>>> Do you think the standard name alone is sufficient? Proposing a new
>>>> attribute is more work than proposing a standard_name,
>>> since it means
>>>> amending the CF standard. I can see there could be value in a
>>>> relative_to attribute, but it might be an unnecessary
>>> complexity. I wonder what you and others think.
>>>
>>> The standard name alone is sufficient for our case. I agree
>>> with you that we should not add unnecessary complexity to the
>>> CF standard. I think we will use the standard name 'time_offset'.
>>>
>>> Best regards,
>>> Maarten
>>>
>>>
>>>
>>> On 02/02/2011 05:15 PM, Jonathan Gregory wrote:
>>>> Dear Maarten
>>>>
>>>> What you write about pixeltime as an aux coord var (y,x) and your
>>>> ncdump look sensible to me. I think that's all fine.
>>>>
>>>>> The standard_name time_offset (s) seems good to me. In the
>>> long name
>>>>> we can add an explanation that this variable deals with the time
>>>>> offset for each pixel.
>>>>
>>>> OK. So that is a definite proposal for a new standard name.
>>>>
>>>> Do you think the standard name alone is sufficient? Proposing a new
>>>> attribute is more work than proposing a standard_name,
>>> since it means
>>>> amending the CF standard. I can see there could be value in a
>>>> relative_to attribute, but it might be an unnecessary
>>> complexity. I wonder what you and others think.
>>>>
>>>> Best wishes
>>>>
>>>> Jonathan
>>>>
>>>
>>>
>>> --
>>> Maarten Plieger
>>> KNMI, R&D Information and Observation Technology, De Bilt
>>> (t) +31 30 2206330
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Maarten Plieger
KNMI, R&D Information and Observation Technology, De Bilt
(t) +31 30 2206330
Received on Mon Jan 23 2012 - 10:00:36 GMT
