I have a prj file which is assumed to have a sphere datum (not ellipsoid). here is the prj file:

PROJCS["WGS 84 / Pseudo-Mercator",GEOGCS["Popular Visualisation CRS",DATUM["D_Popular_Visualisation_Datum",SPHEROID["Popular_Visualisation_Sphere",6378137,0]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Mercator"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]

I'm interested in this part of this prj file


I expect the third parameter of SPHEROID as the inverse flattening to be infinity for sphere (a=b) but here esri writes zero for this parameter!

flattening  = f = (a-b)/a                  //=Zero for Sphere
inverse flattening = 1/f = a/(a-b)         //=Infinity for Sphere

Is there any explanation why esri prj files set the inverse flattening to zero for spheres?

  • How should they write infinity?
    – AndreJ
    Aug 27 '16 at 11:59
  • Even if it is hard to find a convention to write infinity they are not allowed to change the meaning of datum. zero inverse flattening can be interpreted as a dot! Aug 27 '16 at 12:18
  • Maybe simply writing "Infinity" was enough as in C# we can read it this way double.Parse("Infinity") also other languages may have similar behavior. If not applicable they may try writing the Flattening (not inverse flattening) as the third parameter of the SPHEROID Aug 27 '16 at 12:21
  • There has been many variants of prj file. I am not sure if this is the most current one epsg.io/3857 but it looks rather different PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.017453292519943295]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]
    – user30184
    Aug 27 '16 at 13:25
  • 1
    @user30184 Yours is the Esri version, OP's is the first EPSG version, or a mix of EPSG and something else.
    – mkennedy
    Aug 27 '16 at 15:05

Esri first proposed the WKT format for OGC around (estimating) 1998 using what we'd already developed in-house. The SPHEROID format has to support both ellipsoids and spheres. It is easier to allow the second numerical value to be a numerical value rather than have it sometimes be a string (yes, I know it's always a string when parsing it) and sometimes a double value.

It also must support multiple languages (we were using C at the time) so using a string might have had to be handled differently for different languages.

We could have set the second value to be the 'b' (semi-minor axis) instead, but for whatever reason we didn't do that.

Disclosure: I work for Esri.

  • 1
    It is not the first time I see esri do something in a strange way and don't have any acceptable reason for his did. another example is using UTF8 as the encoding to store attribute values in dbf file and all who have read the dbf file specification knows just fixed two-length encoding is allowed when writing string values in dbf file to the storage. Aug 28 '16 at 2:52
  • correction: fixed two-byte length encodings Aug 28 '16 at 3:03
  • Shapefiles use the dBase III+ specification, which predated both UTF-8 and UTF-16. "Acceptable reason" is in the eye of the beholder; cutting the already limited field name and widths in half (to 5 and 127) because some characters might be mulibyte seems the unacceptable option to me.
    – Vince
    Aug 28 '16 at 12:58
  • Also not following a documented specification (dbf) is unacceptable option to me. link Aug 29 '16 at 4:28

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.