#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
"[https://github.com/cf-convention/cf-conventions/wiki/OGC-WKT-Coordinate-
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
possible.
>
> 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
use.
--
Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/172>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
