Jonathan, regards
On Thu, Jan 5, 2012 at 5:15 AM, Jonathan Gregory
<j.m.gregory at reading.ac.uk> wrote:
> Dear Etienne
>
> To summarise so far: the new parameters required are
>
> horizontal_datum_name
> towgs84 (an array of float or double, with 3,6 or 7 values)
For precision issues, towgs84 parameters should be stored in double
precision (see CS_WGS84ConversionInfo in CT document), sorry about the
confusion.
Also a clarification from the CT document: "Sometimes, only the first
three or six parameters are defined. In this case the remaining
parameters must be zero".
> prime_meridian_name
It may be clearer to use name_of_prime_meridian (as it is similar to
longitude_of_prime_meridian), but I understand it does not respect the
naming convention of other *_name parameters
> reference_ellipsoid_name
> projected_coordinate_system_name
> geographic_coordinate_system_name
>
>> 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)?
>
> I think that would be their only use. As far as CF is concerned, they would
> be unstandardised descriptive names, like long_name. I understand from your
> email and from http://home.gdal.org/projects/opengis/wktproblems.html that
> the names of datums are not effectively standardised, but I don't think it's
> the job of CF to standardise them.
Parameters other than datum are standardised by EPSG, so that could be
the authority. I could collect the information into a wiki entry for
reference.
It may not be worth the effort to add them to the standard names
though, as you suggest.
Perhaps the CF convention could suggest or mandate the use of one
naming convention (EPSG or OGR/CadCorp).
In my view the EPSG datum names and codes can be seen as a standard,
as they are published and freely available.
If the CF spec for datum (name or code) is not clear, how can datums
be uniquely identified?
I think that we have to choose a naming convention or use EPSG codes
to overcome the possible confusion.
As the possible values of DATUM keyword is potentially ambiguous, I
believe that a code is in order to fully describe it. I would propose
to add a new variable such as horizontal_datum_code (e.g. EPSG:6618),
which is optional and supplements horizontal_datum_name.
The potential conflicts with horizontal_datum_name, towgs84 and
*ellipsoid* could be resolved following CT section 11 "Referencing
objects by ID versus Value" and (i.e. code takes precedence over name
as well as towgs84 and reference_ellipsoid). However, it would be
mandatory to include all values that are part of the datum.
>
>> 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.
>
> Yes, I agree. Is the above sufficient for the moment? If so we could proceed
> to propose it as a trac ticket.
I think we can proceed with a ticket, in order to add the variables
outlined above and try to finalize the discussion about named datums
(and optional datum codes) as well as valid values for the parameters.
>
>> 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 sympathise. It will be useful when you can do it. If the changes to be made
> are simply mistakes or ambiguities to be resolved in the document, they could
> be proposed as defect tickets rather than modifications to the standard.
I have identified issues with 3 projections (minor modifications to
the definitions for 2, and minor remarks in the spec for 1), I guess I
should file a ticket for each.
>
>> 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?
>
> Do you mean a table which gives the equivalences between the parameters as
> specified by grid_mapping, WKT and proj.4 for each of the projections? That
> would be a very useful resource, I expect. I would suggest that it should not
> be part of the CF standard document, but on a wiki.
Yes. However, I found that including the links to
http://www.remotesensing.org/geotiff/proj_list causes confusion
because there is no information on the mappings between CF and proj.4
and wkt parameters.
All relevant information should be in the same place (in the CF
document or wiki), to remove any confusion.
I will prepare a wiki page with all necessary information and then
file a ticket, if that is ok.
Many thanks Jonathan!
Etienne
>
> Best wishes
>
> Jonathan
Received on Sat Jan 07 2012 - 17:31:07 GMT
