[Go-essp-tech] Extending the DRS syntax to observations

Fri Jan 28 10:01:35 MST 2011

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=0ArrcdEATH6R8dDJEYUstbnpaSmpZTVh6OVZpOEl5SUE&hl=en&authkey=CNbh2t0P#gid=20 
>> <https://spreadsheets.google.com/ccc?key=0ArrcdEATH6R8dDJEYUstbnpaSmpZTVh6OVZpOEl5SUE&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-observations-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
>>
>>
>>
>>
>> -- 
>> Sébastien Denvil
>> IPSL, Pôle de modélisation du climat
>> UPMC, Case 101, 4 place Jussieu,
>> 75252 Paris Cedex 5
>>   
>> Tour 45-55 2ème étage Bureau 209
>> Tel: 33 1 44 27 21 10
>> Fax: 33 1 44 27 39 02
>>
>
>
> -- 
> Sébastien Denvil
> IPSL, Pôle de modélisation du climat
> UPMC, Case 101, 4 place Jussieu,
> 75252 Paris Cedex 5
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110128/5c6283b1/attachment-0001.html 