Jonathan, thank you for your reply.
On Fri, Dec 30, 2011 at 10:06 AM, Jonathan Gregory
<j.m.gregory at reading.ac.uk> wrote:
> Dear Etienne
>
> Thanks for your posting of 13 Dec and apologies again for slow reply.
>
>> => In light of all this, ?could we add datum_name, datum_code and
>> towgs84 to grid_mapping?
>
> I think we should call it horizontal_datum_name (since there are also vertical
> datums).
Datum is sort or a synonym of horizontal datum and datum_name is more
compact but horizontal_datum_name is more accurate, so whatever you
feel is best is ok with me.
> We also need various other names to store the strings which are used
> in WKT: the projected coordinate system, geographic coordinate system,
coordinate system names are indicative, but what would be their use in
grid_mapping if they are not authoritative (other than allow to
represent a WKT string in CF grid_mapping)?
> reference ellipsoid and prime meridian all have names in your WKT strings.
> If these names are valuable, we should define attributes for them too. Are
> these names standardised, or are they just user-readable information (like
> netCDF long_names)?
libgeotiff and GDAL/OGR include csv files (with information mostly
from EPSG databases) with the names for ellipsoid and prime meridians.
The process is described here:
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README .
The EPSG database can be found at
http://www.epsg.org/ .
Unfortunately there are a few standards that are used and different
vendors use slightly different naming schemes.
I would suggest the CT 1.0 spec as implemented by OGR and Cadcorp,
Have a look at
http://home.gdal.org/projects/opengis/wktproblems.html
>
> Yes, we need towgs84, and also prime_meridian_longitude (as well as its name).
There is already longitude_of_prime_meridian, so we could add
name_of_prime_meridian or prime_meridian_name .
towgs84 should be an array of float or double, with 3,6 or 7 values.
>
> My only reservation is about including the code and authority in grid_mapping.
> I am concerned about this because it is redundant information if the mapping
> is fully described by the other attributes. There is a danger that it might be
> inconsistent with those attributes e.g. the mapping might claim to be EPSG
> 4618 but differ from the proper definition of that mapping in some way. Then
> applications would behave differently according to which definition they
> followed. This is the same kind of concern as I have (in ticket 69) about the
> possible inconsistency of WKT and grid_mapping if both are stored in the file.
If we adhere to a single spec which has a clear mapping between code
and datum name (e.g. CT-1.0 as implemented by OGR and Cadcorp), then
there is no need for an authority code.
>
>> 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
>
> That would be the best solution, in my opinion. I am encouraged by this.
Good! We can try and see if adding missing parameters to the CF spec
would resolve the need to have the entire WKT string.
As it seems consensual that WKT would be optional then it seems
reasonable to add the missing parts to the CF spec to map a WKT string
to a grid_mapping definition.
>
>> with some exceptions where the parameters are not 100% compatible
>
> I hope that we will be able to resolve these differences, as detailed in your
> exchanges with John. Have you yet been able to obtain a trac username, so that
> you can open a ticket to correct defects in grid_mapping definition and propose
> new ones?
I have a trac username and enough information to propose fixes to the
CF spec and docs. All is missing is the time to do it!
I would also like to add the following information to CF: proj.4
string as well as WKT representation for all the projections. Should
this be added to a separate wiki or incorporated into the CF document?
>
>> > 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.
>
> The definition of the WKT keywords isn't helpful, unfortunately. The document
> linked to the CT website doesn't say anything I can find about what values they
> can take. I suppose we should postpone consideration of vertical reference
> systems until someone comes forward with a specific use case. In fact, that
> information might belong better with the CF vertical coordinate, like
> formula_terms, rather than in the grid_mapping.
that sound fine.
>
> Best wishes and happy 2012
thanks, to you also! Etienne
>
> Jonathan
Received on Sun Jan 01 2012 - 19:35:16 GMT
