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 <[email protected]> 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 [[email protected]] On Behalf Of Jonathan > Gregory [[email protected]] > Sent: Monday, 30 July 2012 7:10 PM > To: [email protected] > 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 <[email protected]> ----- > >> Date: Mon, 30 Jul 2012 11:36:19 +1000 >> From: Timothy Hume <[email protected]> >> To: "[email protected]" <[email protected]> >> 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 >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
