[cf-pointobsconvention] Should Z Coordinates be required?

[Bob Dattore]

> John Caron wrote:
>>
>> Don Murray wrote:
>>> John-
>>>
>>> John Caron wrote:
>>>
>>>> Well, maybe you're right. I notice that CF currently doesnt require
>>>> vertical coords. But as a visualizing client, how do you display?
>>>> Wouldnt you prefer to insist on something?
>>> No.  We import lots of data point data stored in text files that
>>> only has lat/lon coords.  In the IDV, we plot the data at the
>>> default Z location defined by the user if we don't have a Z 
>>> dimension.
>>> We don't always want to assume 0 for the Z value.
>>
>> Just to be clear: this is not about making assumptions about where 
>> the z value is (sorry i said that earlier), in fact its the opposite: 
>> requiring the data provider to explicitly specify the z position of 
>> point data, in order to be CF compliant.
>>
>> It seems like the possible options are:
>>
>>   1. z coordinate required, with values convertible to height (eg 
>> meters), with a vertical datum (reference surface like "mean sea 
>> level") specified.
>>   2. z coordinate required, with values convertible to height (eg 
>> meters).
>>   3. z coordinate required, with values in any vertical coordinate 
>> system.
>>   4. z coordinate required, may be a "nominal" value (just a string 
>> description)
>>   5. No z coordinate required.
>>
>> I would lean towards 4, but could be convinced of 5 or 3. We should 
>> however recommend the data provider add as much info as possible, and 
>> make sure there is a standard way to do so.
>>
>> Could I ask data providers to chime in : how much z info are you 
>> willing and able to put in your files?
>
> It seems like there are 2 use cases people have in mind:
>
> 1. A data provider is using this Convention to write out data. 
> Presumably the provider is working hard to put quality metadata into 
> their files. I'd really like to encourage (require?) them to put in 
> time, z, x, and y geolocation information. Is there really a case 
> where that information is not available at the raw data writing?
>
> 2. Middleware software is using this Convention as an exchange format, 
> ie rewriting original data into this format. Here, its quite possible 
> that the z coordinate in particular is missing.

The work that our group does falls into this category.  I don't know of 
any point observation data we have that either does not have the 
z-coordinate specified or can be
known from associated documentation.  The hurricane track data that was 
previously mentioned, for example, does not explicitly include the 
z-coordinate, but the format
documentation states that the wind and pressure are valid at the 
surface, so the z-coordinate can be specified during the translation 
from native format to CF-compliant
netCDF.  My opinion is that option 4 is the way to go, with the ability 
to specify "unknown" if z is really not known, but at least data users 
will know that it wasn't unintentionally
omitted, and data providers and translators will maybe be prodded to 
work a little harder to include it.

>
> I like John Greybeal's suggestion to require something, and allow some 
> standard "dont know" string to allow the possibility that its unknown. 
> I realize this is a matter of style, since the effect is the same 
> (unknown Z). Still, I have been watching many people use the 
> CF-compliance checking tools to make sure they have done the right 
> thing. If those tools spit out "missing Z coordinate" message, the 
> writer may be motivated to try to put in some useful info there. We 
> have seen situations where providers, having been told they must use 
> CF, just add the global attribute :Conventions = "CF-1.0". This may 
> pass the compliance tester, but its not useful CF.
>
> Currently CF-1.0 (section 1.3) says "Four types of coordinates receive 
> special treatment by these conventions: latitude, longitude, vertical, 
> and time. Every variable must have associated metadata that allows 
> identification of each such coordinate that is relevant." Arguably, 
> latitude, longitude, vertical, and time are always relevent for this 
> kind of data, and so must exist. In practice we dont require this, our 
> software teases out whether there enough info to georeference a 
> variable. But I think we could (if we wanted) insist on this point 
> more.
> _______________________________________________
> cf-pointobsconvention mailing list
> cf-pointobsconvention at unidata.ucar.edu
> For list information or to unsubscribe,  visit: 
> http://www.unidata.ucar.edu/mailing_lists/


Bob Dattore
Software Engineer/Programmer
UCAR/NCAR/CISL/Data Support Section
Phone: (303) 497-1825
Email: dattore at ucar.edu
Web: http://dss.ucar.edu