Opened 3 years ago

Last modified 3 years ago

#172 new defect

Inaccurate statement in "OGC WKT Coordinate System Issues" page

Reported by: desruisseaux Owned by: cf-conventions@…
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: Cc:


The release of ISO 19162 in 2015 has made some statements in the "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:


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 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 Geographic while the second part talks about GEOCCS with a C as in Geocentric. 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.

Change History (5)

comment:1 Changed 3 years ago by jonathan

Dear Martin

Thanks for making these proposals. I do not have the right expertise to comment on the content, but what you've written looks clear to me. I think this page is a useful resource and it should be kept correct and up-to-date, so I support your proposal. I also suggest you add your name to the end of that document, and that "I" should be replaced by "we" throughout.

I hope others with more expertise than me will have a look.

Best wishes


comment:2 Changed 3 years ago by desruisseaux

Hello Jonathan. Thanks for your replay. Do I edit the Wiki page directly? (edition seems open to anyone without login requirement).


comment:3 Changed 3 years ago by jonathan

Dear Martin

Since this is a defect ticket and no-one objected, we assume everyone agrees it should be done. Thanks for offering. Yes, as far as I understand, you can edit the page directly. If you could add a note to the wiki page with your name and the date you made the changes and a link to this ticket, it would provide a history that might be useful in future.

Possibly this page should be converted to a GitHub markdown page - but for the moment it hasn't been. It was simply copied from the trac wiki when the CF convention was moved into GitHub.

Best wishes


comment:4 Changed 3 years ago by desruisseaux

Done - changes described above have been applied to, and uses of "I" have been replaced by a more neutral form or by "GDAL/OGR" when I think that it describes the choice that Frank did for the library he maintained. The wiki text has been opportunistically reformatted to Markdown in this process.

comment:5 Changed 3 years ago by jonathan

Thanks a lot, Martin. That's very helpful. Jonathan

Note: See TracTickets for help on using tickets.