Jon,
thanks for your answers
On Tue, Dec 13, 2011 at 1:42 PM, Jonathan Gregory
<[email protected]> wrote:
Dear Etienne
Thanks for your helpful email, and sorry for slow response.
Ok you mean that we could add new projections easily to the CF
standard? That's great to know.
Yes, you could do this with a trac ticket, like ticket 72, which proposes to
add the geos projection. See https://cf-pcmdi.llnl.gov/trac/query
I would love to add a trac ticket, but unfortunately my repeated
requests to webmaster to get a trac id have failed... who should I
ask?
I'm not sure I understand your question - do you mean to ask if these
additions to CF would be sufficient to describe most WKT definitions
in pure CF metadata (without the WKT)?
Yes, that's what I mean. I'm interested to know how many other elements of WKT
are used in the cases you deal with.
It seems that
for many applications (especially at the scale most netcdf files are
used for), TOWGS84 parameters are sufficient. A named datum would be
nice, but there are quite a few different ways to identify datums (OGC
vs ESRI).
OK. If they are standardised lists, we could provide attributes to store
them in.
This page is very informative on WKT specifications
http://home.gdal.org/projects/opengis/wktproblems.html
TOWGS84 corresponds to the Bursa Wolf parameters for datum shifts and
is standard in CT 1.0 using (3 or 7 values).
The CT 1.0 standard is relatively simple and fairly complete, I would
suggest that CF should use it to fill the gaps in projection
definitions.
http://www.opengeospatial.org/standards/ct
CT 1.0 WKT stores the datum's name, EPSG code as well as its relation
to the WGS84 datum in TOWGS84.
For example, the full WKT for EPSG:4618 (that uses SAD69 datum) is:
GEOGCS["SAD69",
DATUM["South_American_Datum_1969",
SPHEROID["GRS 1967 Modified",6378160,298.25,
AUTHORITY["EPSG","7050"]],
TOWGS84[-57,1,-41,0,0,0,0],
AUTHORITY["EPSG","6618"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4618"]]
In the DATUM section you see the datum name
"South_American_Datum_1969", EPSG code 6618 and
TOWGS84[-57,1,-41,0,0,0,0]
The Simple Features specification only stores datum_name, which can be
problematic as some vendors (i.e. ESRI) use slightly different datum
names than others (i.e. OGR, CADCorp). I prefer the later as it
follows EPSG datum names more closely.
=> In light of all this, could we add datum_name, datum_code and
towgs84 to grid_mapping?
As maintainer of GDAL's netcdf driver, I see that the only thing
missing in the WKT/CF transformation is named datum (and ideally datum
code and towgs84), then there would not be any need to keep the entire
WKT string - with some exceptions where the parameters are not 100%
compatible (see the link below).
For example, the same EPSG:4618 WKT translates to CF like this:
crs:grid_mapping_name = "latitude_longitude" ;
crs:longitude_of_prime_meridian = 0. ;
crs:semi_major_axis = 6378160. ;
crs:inverse_flattening = 298.249999999996 ;
crs:spatial_ref =
"GEOGCS[\"SAD69\",DATUM[\"South_American_Datum_1969\",SPHEROID[\"GRS
1967
Modified\",6378160,298.249999999996,AUTHORITY[\"EPSG\",\"7050\"]],TOWGS84[-57,1,-41,0,0,0,0],AUTHORITY[\"EPSG\",\"6618\"]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433],AUTHORITY[\"EPSG\",\"4618\"]]"
;
crs:GeoTransform = "-80 0.25 0 -10 0 -0.25 " ;
The spatial_ref is kept for now because CF lacks information on the
named datum. It would be complete if we could have something like:
crs:grid_mapping_name = "latitude_longitude" ;
crs:longitude_of_prime_meridian = 0. ;
crs:semi_major_axis = 6378160. ;
crs:inverse_flattening = 298.249999999996 ;
crs:datum_name = South_American_Datum_1969 ;
crs:datum_code = 6618;
crs:towgs84 = -57,1,-41,0,0,0,0 ;
Perhaps there should be an additional parameter (like datum_authority)
to specify that datum_code is from EPSG, or make it a string like
'EPSG:6618'
Here is a small compilation of the compatabilities between WKT (as
GDAL sees it) and CF-1.5 projections, there are a few
problems/unknowns with some projections:
http://trac.osgeo.org/gdal/wiki/NetCDF_ProjectionTestingStatus
If you identify errors or inadequacies with CF definitions from your detailed
analysis, you could propose they be corrected, again with a CF trac ticket, in
this case as a "defect" rather than an addition to the standard.
I'll look into this when I have the time... and if I can get access to trac!!!
The following page lists WKT parameters:
http://www.geoapi.org/2.0/javadoc/org/opengis/referencing/doc-files/WKT.html
Yes, this is a useful page.
There are a few other parameters like VERT_CS, COMPD_CS and VERT_DATUM
that some users may need.
The VERT_CS and VERT_DATUM appear to be names (in the Newlyn example). Are
these names standardised?
They are part of CT 1.0 , I suggest you take a look at the WKT
keywords. Sorry but I don't know more to comment extensively.
Thank you Jonathan!
Etienne
Best wishes and thanks for your help
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
