9

Does anyone know the precise list of differences between ESRI WKT and OGC WKT projection format strings?

I know there are various tools to help convert from ESRI WKT to OGC WKT, including GDAL utilities and various website services. But my question is not of a practical kind, I simply want to understand the formatting/syntax differences that these services make use of. Previous Stackexchange questions have only talked about the difference in specific examples or about the tools and services available.

Even if you just know one difference it would be great if you could just post it. From my own experience there should only be a small handful of differences. The differences i know of are:

  • most text items in esri definition uses underscore where ogc uses space.
  • the text defining the datum in esri wkt is same as ogc wkt except it starts with "D_".
  • sometimes the text identifiers for some predefined PROJCS, PROJECTION, GEOGCS, and DATUM are written differently (eg "NAD83" in one being "North_American_1983"). I guess the only way to know which identifiers are spelled differently would be to have a list or lookup table, so please name any that you know are different.
  • the various PARAMETER text values are all the same, except ogc has each word upper titlecase whereas esri has everything lowercase. However, i have seen cases where this rule hasnt been used, does anyone know if titlecase actually matters when it comes to software trying to load them?
  • the type of UNIT is spelled upper titlecase in ogc and lowercase in esri, eg "Degree" vs "degree". In some cases i have seen ogc being spelled as both "meter" and "m" for "Meter" and in other cases with french spelling "metre". Anyone know what the correct convention is for these or any other unit type for both formats?
6

I don't have such a list, but going through the GDAL code will guide you:

https://svn.osgeo.org/gdal/trunk/autotest/osr/osr_esri.py

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri.cpp

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri_names.h

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrspatialreference.cpp

  • 1
    Basically ESRI make it up as they go along :-) – Ian Turton Jan 10 '15 at 17:05
  • 1
    @iant Having been the first to implement a code library around the EPSG specifications, they hardly had a choice. – Vince Jan 12 '15 at 3:30
  • 2
    We were probably second--as GeoTIFF spec was available at the time too. @iant there are several things I would do differently if we built a new Esri projection engine! – mkennedy Jan 12 '15 at 19:54
  • okay, so a lot of it seems to be very ad hoc, special case handling. in fact, judging from the linked documents there are hundreds of lines of code of special cases in name-differences and so on. all due to different software implementations and probably lack of agreed upon standards a the time :p – Karim Bahgat Jan 31 '15 at 23:49
  • It would help a lot if ESRI and GoeoTiff would always add the EPSG code number to the WKT projection string. QGIS creates an extra .qpj file for shapefiles to save this setting. – AndreJ Feb 1 '15 at 7:27
8

You've caught a lot of the differences. Esri never adopted the WKIDs for the map projection algorithms or parameter names so those are all different. We didn't agree with how carefully defined the parameter definitions are. Ours are more generalized.

We don't support TOWGS84 nor some of the newer keywords.

When we compare strings (names), we ignore the underscores, the GCS_ and D_, and case. That may not be true in other parsers. Our parser is strict on the names, but we've added some synonyms and now maintain lists of names from various vendors for comparisons.

The original coordinate system specification from OGC didn't get specific when it came to names of objects. There's a new OGC/ISO specification, "Geographic Information - Well Known Text for coordinate reference systems standard," making its way through the process towards standardization. It's much more specific about what the names should be (match EPSG registry!). It will be quite exciting implementing this standard in the future.

Disclosure: I work at Esri, am a member of the subcommittee that maintains the EPSG registry, and was a member of the CRS WKT 2.0 draft committee.

  • Wow, that's really interesting, especially hearing some of the inside info from someone who has been part of decision-making. The new OGC ISO specification sounds very promising, do you think it is likely that more of the major GIS vendors and data formats will begin to converge towards using it? Unfortunately I suspect some of the old differences will continue to persist as long as the older data formats remain popular (eg shapefile, geotiff). – Karim Bahgat Jan 31 '15 at 23:47
  • You're saying you're not supporting TOWGS84, but how can things work at all without that? If the WKT uses unknown names (i.e. an user-defined projection/datum), the coordinate system cannot be properly set up when the datum shift is ignored. Or am I missing something? – PMF Oct 2 '15 at 8:23
  • Most of the best transformations use grid files not a 3 or 7 parameter method. A bunch of transformations don't use WGS84 either. It's a very limited solution. We late-bind instead...pick/set a transformation at the time of transformation. – mkennedy Oct 2 '15 at 13:56
  • If it's unknown to the system, use the create custom geographic transformation tool. The new CRS wkt also covers transformations. Coming Arron to a software near you! – mkennedy Oct 2 '15 at 13:59
0

As a potential starting point for a list of differences it might help to see my new PyCRS package, where I have attempted to create a class for each crs element, parameter, and datum/ellips/proj name, along with their esri_wkt vs ogc_wkt spelling. I have also specified how I see the parsing differences in terms of the wkt structure as a whole in the _from_wkt() function in the parser.py submodule. I hope that with user contributions these differences can be further added to and/or corrected.

https://github.com/karimbahgat/PyCRS

0

On January 4, 2018 Esri created a GitHub repository with EPSG-Esri equivalents in different formats: json, txt, csv...

Esri Projection Engine Database Documentation

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.