Hi Timothy,
Disclaimer: I am the author of ticket #80, and also the maintainer of
the netcdf/cf driver in the GDAL geospatial library (
http://gdal.org)
On Mon, Jul 30, 2012 at 10:34 PM, Timothy Hume <T.Hume at bom.gov.au> wrote:
> Hi Jonathan,
>
> Thanks for the help. I can see that option 80 is probably better, but option 69 is a lot easier for software developers to bolt onto existing NetCDF files. Most of the people I talk to don't see why anyone is interested in anything other than latitudes and longitudes on a spherical Earth; all the stuff about shape of the Earth etc is irrelevant to their needs. The truth is, because most of the NWP data I use is on a rather coarse grid, the grid mapping information is not that important; two coordinate variables with the longitudes and latitudes is sufficient for most purposes.
You are right that for many cases, latitude/longitude are sufficient,
and there is no need to get picky about geodesy when you have a 2deg
grid. However, when you are dealing with projected coordinate systems
you absolutely need to define the coordinate reference system (CRS).
Hence the need to include all the needed parameters that are missing
in the CF spec currently.
I fail to see how ticket #69 and 80 are different from this point of
view - both ways require knowledge of CRS representations.
If you look at the provided examples, it is quite straight-forward to
translate to/from CF and WKT.
>
> Therefore, the path of least resistance is option 69 (with all its potential pit falls); I think option 80 will be too much, and a lot of data writers will simply decide to add no grid mapping information at all, a worse situation than option 69.
Actually ticket #80 is the path of least resistance - in terms of CF
- because it uses most of existing CF descriptors. Ticket #69
introduces the entire WKT structure which is very different - although
admittedly a better-known standard.
And the adoption of ticket #69 has been hampered by quite a few
differences in opinion, and the most important barrier is the need to
reconcile any inconsistencies between the CF definitions (which take
precedence) and the WKT definitions.
Your approach (basically that proposed by ticket 69) is the same that
many have been using for some time, and unfortunately there is no way
of knowing if "other software" can read this, as it is not standard.
For example, the GDAL library (gdal.org) has been using this approach
in order to export netcdf files and read back the complete WKT
definition - because if you use CF-only strings you loose things like
datum and TOWGS84 transformation patterns.
But it's unlikely other programs do not read it as there is no
"standard" tag for the WKT string in the CF syntax.
And the approach is not really satisfactory, because I had to re-write
conflict-detection and it is not 100% reliable.
My advice as to which format use depends on who will use the data (and
what software will be used), if you want it published and conform to a
standard, you should wait for the CF standard to be upgraded. If you
want something more pragmatic and immediate, embed the WKT string
which would be more readily supported by "others". There are a number
of examples (e.g. NARRCAP project) of organizations publishing their
RCM grids with complex CF metadata.
What do you need to represent that is not in the CF-1.6 standard?
Regards,
Etienne
>
> Cheers,
>
> Tim Hume
> Bureau of Meteorology
> ________________________________________
> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory [j.m.gregory at reading.ac.uk]
> Sent: Monday, 30 July 2012 7:10 PM
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] How to include EPSG codes or WKT information in a CF file [SEC=UNCLASSIFIED]
>
> Dear Tim
>
> There are two open CF trac tickets that relate to this issue, proposing to
> add new conventions to store OGC information in different ways in CF. Ticket
> 80 https://cf-pcmdi.llnl.gov/trac/ticket/80 proposes several new attributes
> which correspond to WKT elements that currently do not have grid_mapping
> equivalents. Ticket 69 https://cf-pcmdi.llnl.gov/trac/ticket/69 proposed to
> add an attribute to record the WKT information without translation. Personally
> I prefer the former because I am concerned about duplication and possible
> inconsistency of information, but please have a look at the tickets and form
> your own view, and add comments if you like. So the answer to your question
> is that there is not yet a CF standard way to do it, but there will be.
>
> Best wishes
>
> Jonathan
>
>
> ----- Forwarded message from Timothy Hume <T.Hume at bom.gov.au> -----
>
>> Date: Mon, 30 Jul 2012 11:36:19 +1000
>> From: Timothy Hume <T.Hume at bom.gov.au>
>> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
>> Subject: [CF-metadata] How to include EPSG codes or WKT information in a CF
>> file [SEC=UNCLASSIFIED]
>>
>> Hi,
>>
>> I am adding grid mapping information to my NetCDF files. My data are on a lon-lat grid on a spherical Earth. I can put in the standard CF attributes, grid_mapping_name etc, but also want to include the EPSG and WKT codes to help software applications that might want these. I have not been able to find out how this is done in NetCDF-CF, so am using this format:
>> =
>> int crs ;
>> crs:grid_mapping_name = "latitude_longitude" ;
>> crs:earth_radius = 6371007.0 ;
>> crs:prime_meridian = 0.0 ;
>> crs:epsg_code = 4047 ;
>> crs:wkt = "GEOGCS[\"Unspecified datum based upon the GRS 1980 Authalic Sphere\",DATUM[\"Not_specified_based_on
>> _GRS_1980_Authalic_Sphere\",SPHEROID[\"GRS 1980 Authalic Sphere\",6371007,0,AUTHORITY[\"EPSG\",\"7048\"]],AUTHORITY[\"EPSG\",\
>> "6047\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4047\"]]" ;
>>
>> What do other people do when including this extra grid information?
>>
>> Cheers,
>>
>> Tim Hume
>> Centre for Australian Weather and Climate Research
>> Bureau of Meteorology
>> Melbourne
>> Australia
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> ----- End forwarded message -----
> _______________________________________________
> 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
Received on Mon Jul 30 2012 - 20:10:25 BST
