[Go-essp-tech] Extending the DRS syntax to observations
Bryan Lawrence
bryan.lawrence at stfc.ac.uk
Mon Jan 31 02:42:32 MST 2011
Hi Folks
Sorry I've come late to this discussion.
I've got just two simple points to make (for now).
Firstly, I think this activity (organising observational data to support
CMIP5) is not the same as cmip5 itself. Sooner or later things break in
the DRS heirarchy doing this, and so I think it would be helpful to all
consumers if this was dealt with at the top level of the DRS.
Additionally, remember obs are timeless, models are not. This data will
be useful beyond cmip5 (e.g. cordex). So I recommend *not* shoehorning
all the obs data under cmip5 in the DRS.
The DRS allows you to define new activiites, and I'd do so, something
like obs4models or (if you must) cmip5obs ....
Otherwise I'm fine with the approach.
Secondly, wrt to Steve's list below: there is of course swath data as
well ... but otherwise I rather agree that 3 and 1 can be handled the
same.
Cheers
Bryan
> Glad this topic has come up, because it is closely related to the
> editorial issues about "what do we mean by "observation" that I
> floated yesterday. (Luca -- I will hold off making edits until
> there's a group resolution.) Arguably there are 3 categories of
> observations, rather than 2:
>
> 1. remote sensed (grids)
> 2. in situ "stations" (time series and profiles)
> * there are also some potentially important collections of
> trajectory-based obs -- e.g. surface ocean carbon flux
> cruise measurements. Should these be considered?
> 3. in situ gridded products (important and simple to use for
> climate model evaluations)
> * ocean examples: ICOADS, World Ocean Atlas
> * terrestrial examples: ?? (there must be lots of em, no?)
>
> As of yesterday I envisioned that #3 could be folded into the Wiki
> description of #1 by merely making some editorial changes. Agree?
> ==============================
>
> On 1/28/2011 8:19 AM, Sébastien Denvil wrote:
> > Hi all,
> >
> > I would suggest to create separate table for station data and
> > remote sensing data. Also for remote sensing data we will need
> > separate table depending on frequency (monthly or daily or ....).
> >
> > Within a cmor table you can define the following value (in day).
> > This value is used by cmor to check that your time axis is
> > increasing the way it should.
> > approx_interval: 30.000000
> >
> > regards.
> > Sébastien
> >
> > On 28/01/2011 16:31, Palanisamy, Giri wrote:
> >> Hi Luca...
> >>
> >> Good question. So for, we have only added the variables from
> >> Observational station data. We can either make this table common
> >> for both station data and remote sensing data, or create separate
> >> tables.
> >>
> >> Also, the obsSites is still an early draft, and probably needs
> >> more use cases before it can be used.
> >>
> >> Thanks!
> >>
> >> Giri
> >>
> >> *From:*go-essp-tech-bounces at ucar.edu
> >> [mailto:go-essp-tech-bounces at ucar.edu] *On Behalf Of *Cinquini,
> >> Luca (3880)
> >> *Sent:* Friday, January 28, 2011 7:41 AM
> >> *To:* Renata McCoy
> >> *Cc:* go-essp-tech at ucar.edu; Sébastien Denvil; climate-obs;
> >> Lynnes, Christopher S. (GSFC-6102)
> >> *Subject:* Re: [Go-essp-tech] Extending the DRS syntax to
> >> observations
> >>
> >> Hi Renata and Giri,
> >>
> >> thanks for the spreadsheet, we should encourage all people who
> >> will be providing obs to CMIP5 to take a look and add their
> >> contribution.
> >>
> >> I do have a question: the obs table is now called "obsSites". Is
> >> this meant to also include remote sensing datasets, or just
> >> station data ? Should we have a collection of CMOR obs tables ?
> >>
> >> thanks, Luca
> >>
> >> On Jan 27, 2011, at 3:51 PM, Renata McCoy wrote:
> >>
> >>
> >>
> >> Hi All,
> >>
> >> The spreadsheet for developing the observational CMOR table
> >> controlled variables list is on google docs :
> >>
> >> https://spreadsheets.google.com/ccc?key=0ArrcdEATH6R8dDJEYUstbnpaS
> >> mpZTVh6OVZpOEl5SUE&hl=en&authkey=CNbh2t0P#gid=20
> >> <https://spreadsheets.google.com/ccc?key=0ArrcdEATH6R8dDJEYUstbnp
> >> aSmpZTVh6OVZpOEl5SUE&hl=en&authkey=CNbh2t0P#gid=20>
> >>
> >> Everyone with the url can modify it, so maybe we need to use
> >> colors to indicate what is being changed. We need to define the
> >> temporal and spacial (pressure, or height) axes somewhere.
> >>
> >> The observational table itself is in a tab named 'obsSites' (you
> >> may need to scroll to see it or use navigational arrow in the
> >> tabs menu to see more tabs). It's mostly a copy of cfSites but
> >> with modification for the obs. specifications. This is just a
> >> beginning, we will be adding more variables, as needed, please do
> >> add the variables that your data requires. Notice that all the 2D
> >> variables from Amon are part of this table, with the modification
> >> in time cell method (which now allows instantaneous (time:point)
> >> and time average (time:mean) measurements with any time average
> >> interval).
> >>
> >> Thanks to Giri for setting it up!
> >>
> >> Greetings,
> >>
> >> Renata
> >>
> >> On Jan 27, 2011, at 1:06 PM, Sébastien Denvil wrote:
> >>
> >>
> >>
> >> Hi all,
> >>
> >> yes I think as well those attributes can describe the nature of
> >> the link between raw measurement and used product.
> >> Taking an example I know:
> >>
> >> - CALIPSO-GOCCP is derived from Calipso L1/NASA products (NASA
> >> Langley ASDC - CALIPSO Data Sets).
> >> - A piece of code is applied on L1 product to produce an
> >> information directly comparable with gcm outputs (and COSP
> >> package).
> >> - This piece of code and the underlying reasoning have clear
> >> identifier and references (doi).
> >>
> >> -- source (a string description of a specific source of the
> >> measurement)
> >>
> >> Calipso L1/NASA products (NASA Langley ASDC - CALIPSO
> >> Data Sets).
> >>
> >> -- source_datastream (file datastream identifier with the
> >> version)
> >>
> >> Code version used to compute derive product
> >> (svn/cvs/git/... version or code identifier)
> >>
> >> -- source_url (a reference url for the source data)
> >>
> >> http://climserv.ipsl.polytechnique.fr/fr/cfmip-observatio
> >> ns-3.html
> >>
> >> -- source_doi (a citable reference describing in deep detail
> >> methodology used behind the scene)
> >>
> >> H. Chepfer, S.Bony, D. M. Winker, G. Cesana, JL.
> >> Dufresne, P. Minnis, C.J. Stubenrauch, S. Zeng, 2009 :
> >> "The GCM Oriented CALIPSO Cloud Product
> >> (CALIPSO-GOCCP)", J. Geophys. Res., 105, D00H16,
> >> doi:10.1029/2009JD012251,
> >> http://www.agu.org/journals/jd/jd1005/2009JD012251/
> >>
> >> Thinking about that it could be good to add as well a citable
> >> reference in the global attribute. I'm sure all observational
> >> dataset will have one. Just a suggestion.
> >>
> >> Regards.
> >> Sébastien
> >>
> >> On 27/01/2011 20:52, Cinquini, Luca (3880) wrote:
> >>
> >> Hi Renata,
> >>
> >> these attributes seem like a good idea to me. It is
> >> beyond what the models have, but the nature of these
> >> observational data is that they come from some other
> >> data...
> >>
> >> thanks, Luca
> >>
> >> On Jan 27, 2011, at 12:45 PM, Renata McCoy wrote:
> >> Hi Chris, Luca,
> >>
> >> It could also be a requested attribute of a variable. I propose
adding the following attributes (CMOR table specified attribute) for each
variable:
> >> -- source (a string description of a specific source of
> >> the measurement)
> >>
> >> -- source_datastream (file datastream identifier with the
> >> version)
> >>
> >> -- source_url (a reference url for the source data)
> >>
> >> Greetings,
> >>
> >> Renata
> >>
> >> On Jan 27, 2011, at 11:26 AM, Cinquini, Luca (3880) wrote:
> >> Hi Chris,
> >>
> >> good question. My feeling is that this information is
too complex to be encoded as part of the file names or directory
structure, and should probably go into two places:
> >> o The tech note that is associated with each dataset
> >>
> >> o Perhaps, a global attribute that is encoded in the
> >> netcdf files themselves (which can be harvested and
> >> displayed on the web interface)
> >>
> >>
> >>
> >> What's your opinion ?
> >>
> >>
> >>
> >> thanks, Luca
> >>
> >> On Jan 27, 2011, at 12:08 PM, Lynnes, Christopher S.
(GSFC-6102) wrote:
> >> Luca,
> >>
> >> Where do you make visible the information that those
> >> files were generated by the AIRS processing software
> >> version 5.2.2, or alternatively that it is Collection
> >> 5 AIRS and not Collection 3 AIRS? These distinctions
> >> are rather critical w.r.t. the content of the data...
> >>
> >> The values for the various
> >> fields<agency>,<mission>,<instrument>
> >> and<processing level> would need to be selected
> >> from a controlled vocabulary similar to the one
> >> established for models.
> >>
> >>
> >>
> >> Any comment or insight on the matter is
> >> appreciated.... The idea is to try to finalize
> >> the specification relatively quickly, let's say a
> >> couple of weeks, so that we can start preparing
> >>
> >> and publishing these observations into the CMIP5
> >> archive.
> >>
> >>
> >>
> >> thanks in advance,
> >>
> >>
> >>
> >> Luca
> >>
> >> --
> >>
> >> Dr. Christopher Lynnes NASA/GSFC, Code 610.2
> >> phone: 301-614-5185
> >>
> >> _______________________________________________
> >> GO-ESSP-TECH mailing list
> >> GO-ESSP-TECH at ucar.edu <mailto:GO-ESSP-TECH at ucar.edu>
> >> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
> >
> > Tour 45-55 2ème étage Bureau 209
> > Tel: 33 1 44 27 21 10
> > Fax: 33 1 44 27 39 02
> >
> >
> > _______________________________________________
> > GO-ESSP-TECH mailing list
> > GO-ESSP-TECH at ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848;
Web: home.badc.rl.ac.uk/lawrence
More information about the GO-ESSP-TECH
mailing list