11

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?
Improve this question

4 Answers 4

Reset to default
10

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.

Improve this answer
4
  • 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
    Commented Jan 31, 2015 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
    Commented Oct 2, 2015 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
    Commented Oct 2, 2015 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
    Commented Oct 2, 2015 at 13:59
7

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

Improve this answer
5
  • 3
    Basically ESRI make it up as they go along :-)
    – Ian Turton
    Commented Jan 10, 2015 at 17:05
  • 1
    @iant Having been the first to implement a code library around the EPSG specifications, they hardly had a choice.
    – Vince
    Commented Jan 12, 2015 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
    Commented Jan 12, 2015 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
    Commented Jan 31, 2015 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
    Commented Feb 1, 2015 at 7:27
2

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

Esri Projection Engine Database Documentation

Improve this answer
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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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