For the last 2-3 weeks I have been back and forth between Hexagon and ESRI's local distributor in Puerto Rico to solve a problem. To date, however I have precious time and don't see a solution in the horizon. This was my workflow:
1) I used GIS online services from NOAA (https://storms.ngs.noaa.gov/storms/maria/index.html#7/18.056/-64.824) to georeference an image in ArcMap.
2) In ArcMap I exported the file to produce an .img. In ArcMap the Current Coordinate System reads (WGS_1984_Web_Mercator_Auxiliary_Sphere;
WKID: 3857 Authority: EPSG; Projection: Mercator_Auxiliary_Sphere: False_Easting: 0.0, False_Northing: 0.0, Central_Meridian: 0.0, Standard_Parallel_1: 0.0, Auxiliary_Sphere_Type: 0.0, Linear Unit: Meter (1.0).
3) I opened the .img file in Erdas Imagine and this software assigned the Pseudo Mercator projection with an EPSG 3857.
4) I processed the .img in Erdas Imagine to calculate the gndvi and then opened it in ArcMap. This image is not falling in the right place, and worse it is being rotated. When I look into current Coordinate System it reads (Pseudo_Mercator; Authority: Custom; Projection: Stereographic_North_Pole: false_easting: 0.0; false_northing: 0.0; central_meridian: 0.0; standard_parallel_1: 0.0; Linear Unit: Meter (1.0); Geographic Coordinate System: GCS_WGS_1984
Hexagon says "We are continuing to explore this issue, but we think that ArcMap could be lacking an entry in their projection equivalency tables. Everyone calls “standard” projections by different names, which is why using EPSG codes are becoming popular. ERDAS IMAGINE and Esri ArcMap may support the exact same projection, but we call it Bill and they call it Terry. In ERDAS IMAGINE we have an equivalency table which says that if you see Terry, treat it as Bill. But ArcMap may not have an equivalency saying what to do if they see Bill, so when Bill occurs they don’t know what to do with it."
ESRI says "I wanted to inform you that EPSG provides an international standard for all things having to do with map projections. Hence, Esri follows the European Petroleum Survey Group (EPSG) recommendations for the format for projection files. Erdas does not.If the user wishes to process the imagery in Erdas, the projection definition is going to change. However, the only solution, for now, would be to redefine the projection for the data using the Spatial Reference installed in ArcGIS Desktop."
Hexagon says "When Esri refers to “ESPG recommendations” we believe they actually meant “IOGP recommendations”. The IOGP maintains the EPSG Dataset. The EPSG as an organization went defunct in 2005. We were not aware that the IOGP makes “recommendations for the format for projection files”. Can we get a reference to such recommendations? Perhaps they meant “text” instead of “files”, specifically Well-Known Text (WKT) which is not a standard controlled by the IOGP, but rather an ISO standard. The EPSG Registry referenced from the epsg.org website gives the information for code 3857 in the file “epsg-org-3857.jpg” (attached to this ticket)."
And that same registry delivers the following WKT:
PROJCRS["WGS 84 / Pseudo-Mercator",
DATUM["World Geodetic System 1984",
CONVERSION["Popular Visualisation Pseudo-Mercator",
METHOD["Popular Visualisation Pseudo Mercator",ID["EPSG",1024]],
PARAMETER["Latitude of natural origin",0,ANGLEUNIT["degree",0.01745329252]],
PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.01745329252]],
And this is the PE string (ESRI’s Projection Engine string format) that we are receiving from ESRI’s PE library and which is saved in the original image file:
Perhaps these “recommendations for the format for projection files” advise renaming Pseudo Mercator to “Web_Mercator_Auxiliary_Sphere” as well as calling the CONVERSION METHOD a PROJECTION and using "Mercator_Auxiliary_Sphere" for that piece of data instead of “Popular Visualisation Pseudo Mercator”? We doubt it, but we were able to figure out what ArcGIS meant.
So in summary, we think that Esri’s answer reflects frustration at the ever present challenge in our industry of trying to be inter-operable among a multitude of data formats and representations. We have felt that frustration as well and it just so happens that this time ESRI was caught short because this is one unhandled case among thousands of correctly working variations that ESRI has been counting on GDAL to handle on its behalf.
Submitting an update to GDAL would take some effort and unfortunately that doesn’t immediately provide a resolution. GDAL then has to issue a release that incorporates the fix and then ESRI needs to pick up that release and then ESRI needs to release either a patch or an update for ArcGIS that contains the updated GDAL. That is not going to be a quick process.
ESRI says ""I will get back to you at the earliest after performing the required testing and research at my end. Due to the incompatibility of projections between Erdas and Esri at the moment this may take a while."
I don't have a clue of what is going one - can somebody help?