Hi Martina,
This is very helpful. As you say, my example falls within 'Section
profile data'.
Thanks,
Alejandro
On Thu, 2009-09-17 at 08:55 +0200, Martina Stockhause wrote:
> Hi Alejandro,
>
> maybe it is worthwhile to have a look at the "section" definition of the
> proposal for Point Observation Measurements (Trac #37): *section*: a
> collection of profiles which originate along a trajectory. This
> definition seems to be quite close to your satellite track explanation.
> **
> A lot of additional information and examples can be found on the
> accompanied wiki
> (https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions).
>
> Best wishes,
> Martina
>
>
> Bryan Lawrence wrote:
> > Hi Alejandro
> >
> >
> >> This is a satellite track. Model data will be sampled along this
> >> satellite track, and the data will be stored as a 'curtain' of vertical
> >> profiles, with each point defined by (lon,lat,time).
> >>
> >
> > I suspected as much :-)
> >
> >
> >> This coordinate is defined in the MIP tables for CMIP5
> >> but the standard name is missing (the MIP name is 'location'). My
> >> understanding is that all CMIP5 variable and coordinate names have to be
> >> mapped to CF standard names, but I'm not 100% sure about this. I will
> >> find out whether a standard name is always required.
> >>
> >
> > Well, currently, I think "the official position" might be that standard names
> > are only for physical variables, but this is a rather interesting and important
> > special case ...
> >
> > ... and in the absence of a convention extension which covers this
> > properly, the following is my gut feeling:
> >
> > In terms of information content it's just a special case of a timeseries of
> > station data, but where the word "station" is inappropriate, what we've
> > actually got is the subsatellite_location
> >
> > Example 5.4
> > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s04.html
> > suggests that one doens't need standard names for the variables
> > for the station list, and my gut feeling is that we probably don't
> > from a CF point of view for this example either.
> >
> > It become a CMIP5 issue. I suspect for this instance we just need
> > to agree the CMIP5 long name which is more useful than
> > "location", and I think it should probably be something like
> > subsatellite_location (and we probably need which satellite
> > in the metadata too).
> >
> > But none of the above is authoratative :-)
> >
> >
> > (Which MIP table are you looking at? Can you give me the
> > context, perhaps in offline email, this is of some interest to me for
> > a number of reasons.)
> >
> > Bryan
> >
> >
> >
> >
> >
> >> Cheers,
> >>
> >> Alejandro
> >>
> >> On Wed, 2009-09-16 at 09:49 +0100, Bryan Lawrence wrote:
> >>
> >>> Hi Alejandro
> >>>
> >>>
> >>>> This is going to be used as the horizontal
> >>>> dimension for a stream of atmospheric vertical profiles (e.g.
> >>>> temperature(position,height)). It will be an index running from 1 to N
> >>>> (number of profiles). Then, the variables [latitude(position),longitude
> >>>> (position),time(position)] will give the geographical position and time
> >>>> of the profiles. Is there any CF standard name suitable for this?
> >>>>
> >>> this is really a special case of the observational data issue.
> >>>
> >>> we have this with profiles from flights, ships etc, intersections between observations on the ground and swaths overhead etc ...
> >>>
> >>> So, in this case, is there an intrinsic meaning (as Jonathan is implicitly asking)? What
> >>> does this position actually mean?
> >>>
> >>> Bryan
> >>>
> >>>
> >>> On Wednesday 16 September 2009 08:58:54 Jonathan Gregory wrote:
> >>>
> >>>> Dear Alejandro
> >>>>
> >>>> Ah, I see. No, I don't think there is a standard name for that. If the index
> >>>> had some meaning e.g. if it was a standardised station number, a standard name
> >>>> could indicate that. If it is purely an index with no intrinsic meaning, I am
> >>>> not sure that it would add any information to give it a standard name. What do
> >>>> you think? In a sense, I would say that the variable exists only because it is
> >>>> not possible to construct the netCDF file without it. All you're really
> >>>> interested in is its dimension.
> >>>>
> >>>> Cheers
> >>>>
> >>>> Jonathan
> >>>> _______________________________________________
> >>>> CF-metadata mailing list
> >>>> CF-metadata at cgd.ucar.edu
> >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>>
> >>>>
> >>>
> >>>
> >
> >
> >
> >
>
--
------------------------------------------------------------------
Dr Alejandro Bodas-Salcedo Earth Observation Research Scientist
Met Office Hadley Centre
FitzRoy Rd Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 886113 Fax: +44 (0)1392 885681
E-mail: alejandro.bodas at metoffice.gov.uk http://www.metoffice.gov.uk
See our guide to climate change at
http://www.metoffice.gov.uk/climatechange/guide/
------------------------------------------------------------------
Received on Thu Sep 17 2009 - 02:44:16 BST
