#172: Inaccurate statement in "OGC WKT Coordinate System Issues" page
 Reporter:  desruisseaux    |      Owner:  cf-conventions@…
     Type:  defect          |     Status:  new
 Priority:  medium          |  Milestone:
Component:  cf-conventions  |    Version:
 Keywords:                  |
 The release of ISO 19162 in 2015 has made some statements in the
 System-Issues OGC WKT Coordinate System Issues]" page to become outdated.
 A few statements are also erroneous. To make the page more up to date, I
 propose the following changes:

 = Introduction =

 I propose to replace the first paragraph by the following paragraph. I use
 quote for distinguishing proposed texts from discussion. Of course feel
 free to modify e.g. for fixing English:

 > This document is intended to discuss some issues that arise in
 attempting to use OGC Well Known Text (WKT) descriptions of coordinate
 reference systems, especially with implementations based on older WKT
 specifications. It discusses various vendor implementations and issues
 between three sources of WKT specifications:
 > * the original "Simple Features" specification (ie. SF-SQL 99-049);
 > * the newer Coordinate Transformation Services (CT) specification
 (01-009) which fixes some ambiguities in the original specification (e.g.
 regarding units of measurement) and defines an extended form of WKT;
 > * the ISO 19162:2015 specification, also known as "WKT 2".

 = WKT implementations =

 I propose to add to the list:

 > * !GeoTools - can read and write either the SF or CT style of WKT.
 > * Apache SIS - can read and write the SF, CT or ISO 19162 style of WKT.

 = Projection parameters =

 I propose to replace the first paragraph by:

 > The Simple Feature specification does not list a set of projections and
 the parameters associated with them. This leads to various selection of
 parameter names (and sometimes projection names) from different vendors
 who based their implementation on that oldest specification.
 > The Coordinate Transformation Services (CT) 1.0 specification lists a
 few projections and parameters. Please try to adhere to the projection
 names and parameters listed there when formatting a WKT 1 definition. For
 projection and parameters not listed in the CT specification, the
 [http://geotiff.maptools.org/proj_list/ GeoTIFF Projections List registry]
 provides a list of WKT bindings in usage. That list also tries to relate
 the projections to the GeoTIFF, EPSG and PROJ.4 formulations where
 > The ISO 19162 specification tries to fix the projection and parameter
 names issue by recommending to specify the EPSG (or other authority) code
 with all projections and parameters. This is possible because EPSG codes
 exist not only for Coordinate Reference Systems, but also for datum, axes,
 operation methods, parameters, ''etc.''

 I suggest to remove the paragraph starting with "One other issue is that
 the CT specification does explicitly list parameters for the Transverse
 Mercator …". I verified in EPSG registry, and the CT definition seems in
 agreement. Also I do not see conflict between the tables and the examples
 in the same specification.

 = Datum names =

 I suggest to replace the last paragraph (beginning with "The short
 result") by:

 > The short result of this is that recognizing and comparing datum between
 different Simple Features implementations require the use of heuristic
 rules and a table of datum aliases.

 = Units of PRIMEM =

 The first bullet point is wrong. The quoted specification text does not
 have an error in it, because the first part talks about `GEOGCS` with a G
 as in Geo__g__raphic while the second part talks about `GEOCCS` with a C
 as in Geo__c__entric. Admittedly the G and C letters look very similar,
 which caused this confusion. I suggest to replace the first bullet point
 by the following:

 > * The CT 1.0 specification (7.3.14 PRIMEM) says ''"The units of the
 longitude must be inferred from the context. If the PRIMEM clause occurs
 inside a GEOGCS, then the longitude units will match those of the
 geographic coordinate system. If the PRIMEM clause occurs inside a GEOCCS,
 then the units will be in degrees."'' Note that while the GEOGCS and
 GEOCCS keywords look very similar, they are not the same (the forth letter
 is a G in one case and a C in the other case). As a rule of thumb, the
 prime meridian in WKT 1 shall be expressed in the same units than the
 latitude and longitude axes of the enclosing coordinate reference system.
 This rule can be applied in the geographic CRS case (GEOGCS), but can not
 be applied in the geocentric case (GEOCCS) since the axes are in meters;
 consequently the angular unit is fixed by the specification to degrees in
 that later case.

 I suggest to add the following point at the end (after the Oracle case):

 > * ISO 19162:2015 recommends to explicitly specify the PRIMEM unit for
 avoiding confusion. However if the unit is omitted, then ISO 19162
 confirms the CT 1.0 interpretation (prime meridian in units of the
 enclosing geographic CRS). In other words, the above "Cadcorp way" is the
 standard approach for writing WKT 1 definitions that are compatible with
 WKT 2 / ISO 19162.

 = Sign of TOWGS84 Rotations =

 I suggest to add the following paragraph at the end of the section:

 > ISO 19162:2015 removes any TOWGS84 support. One problem of TOWGS84 is
 that it encourages the use of WGS 84 as a "pivot" datum, with every datum
 shift operations defined in terms of that datum. This is not always
 desirable. For example in the transformation from Martinique 1938 to
 RGAF09, any operation passing through WGS 84 will inject errors in the
 results. The use of TOWGS84 as a pivot system is named ''early-binding
 approach'' in EPSG and GIGS guidance notes, as opposed to the recommended
 ''late-binding approach''. For users who really want the early-binding
 approach, ISO 19162 replaces TOWGS84 by a new keyword, BOUNDCRS, which
 resolves the sign issue by specifying explicitly which operation method to

Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/172>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Reply via email to