3

In ArcGIS Desktop 9.3.1, when connecting to a WMS layer, the server sends to ArcGIS the supported CRSs (coordinate reference systems) as a list of EPSG codes.

I wonder how ArcGIS (ArcMap and ArcCatalog) recognize the coordinate reference system name and related parameters for each EPSG code in the list sent by the server, because I need to add one missing EPSG code -> coordinate reference system correlation in ArcGIS in order to workaround a bug that occurs in the following scenario:

when the server returns an EPSG codes list in which the first EPSG code is not recognized by (does not match any coordinate system name known by) ArcGIS

[EPSG list returned by the server in the GetCapabilities command replay]

<CRS>EPSG:6706</CRS>
<CRS>EPSG:4258</CRS>
<CRS>EPSG:25832</CRS>
<CRS>EPSG:25833</CRS>
<CRS>EPSG:25834</CRS>

[Layer Properties / Source / Data Source excerpt from ArcMap]

Supported Coordinate System(s):
 EPSG:6706   - 
 EPSG:4258   - GCS_ETRS_1989
 EPSG:25832  - ETRS_1989_UTM_Zone_32N
 EPSG:25833  - ETRS_1989_UTM_Zone_33N
 EPSG:25834  - ETRS_1989_UTM_Zone_34N

then ArcMap fails to draw the layer, even changing the data frame coordinate system in one of the others (both from the Data Frame Properties or from the Change Coordinate System dialog).

  • ArcGIS 9.3.1 has been in Retired support status for over four years. It hasn't received a new patch in over five and a half. There isn't any way to make old software recognize new coordinate system codes. – Vince Dec 12 '17 at 12:52
  • Dear @Vince, I know ArcGIS 9.3.1 is not yet supported by Esri, but I'm not asking them to fix this bug, but a way to improve/update ArcGIS 9.3.1 by my self. I think your statement about the impossibility "to make old software recognize new coordinate system codes" is incorrect: in fact some old GIS software allow the user to update the EPSG CRS parameters matching list just adding the new one to e.g. a csv or db file. – Andrea Giudiceandrea Dec 12 '17 at 16:06
  • 1
    Projection codes are part of the ArcGIS binaries. New EPSG data can't be added by end users. It takes a service pack or patch to replace the projection engine DLL to add a new EPSG code, and it's six years too late for 9.3.1 – Vince Dec 12 '17 at 16:22
  • 2
    There's a back-door for adding custom objects to the projection engine. It would probably work to add a new GCS and datum with custom WKIDs, but not with the EPSG WKIDs. To get EPSG:6706 (RDN2008), you need at least 10.3.1. – mkennedy Dec 12 '17 at 18:40
  • @mkennedy That sounds like the answer to me... – Dan C Dec 14 '17 at 15:59
2

As I understand from further research following the useful comments by @Vince and @mkennedy, the answer to my first question "How does ArcGIS Desktop match WMS EPSG codes with ESRI CRS names and parameters?", is: by the Projection Engine library that is located in the "bin" sub directory of ArcGIS install dir.

PE Library provides map projection and datum transformation support and also stores the predefined names and parameters for datum, gcs, pcs, spheroids, units... (see here and here).

I can also partially answer now to my second question about how to add missing coordinate systems and related parameters. In fact, as stated in the @mkennedy comment, there is a "back-door" for adding custom objects to the projection engine. The procedure manual is deeply buried in the old Esri Developer Network doc pages, but is still there, in the ArcSDE® 9.3 Developer Help chapter "Using Persistent User defined Objects" (for reference, macro names defined in pedef.h include file are here).

Following the linked procedure I succeeded in adding the custom DATUM "D_RDN2008" and the related GEOGCS "GCS_RDN2008", but @mkennedy was right: it seems impossible to make ArcMap recognize and match the new geographical coordinate system (assigning it the EPSG code 6706) with the same EPSG code present in the WMS GetCapabilities response as supported CRS/SRS (although I found it's possible to assign it an EPSG code already present in PE library to successfully modify it).

datum file in PEOBJEDITHOME path:

DATUM,206132,"D_RDN2008",PE_S_GRS_1980

geogcs file in PEOBJEDITHOME path:

GEOGCS,6706,"GCS_RDN2008",206132,PE_PM_GREENWICH,PE_U_DEGREE

Anyway, for now I found a workaround for the bug described in my question: using a web proxy or a man-in-the-middle https capable web proxy (like in my case, because the WMS is served over HTTPS) it's possible to intercept and modify (or rewrite) on the fly the GetCapabilities response sent by the WMS.

In my case, I simply need to make sure the proxy deletes the first line (<CRS>EPSG:6706</CRS>) of the WMS layer supported coordinate systems list in the response sent by the server.

It works for me: the Layer Properties / Source / Data Source from ArcMap for that WMS layer now reports only

Supported Coordinate System(s):
 EPSG:4258   - GCS_ETRS_1989
 EPSG:25832  - ETRS_1989_UTM_Zone_32N
 EPSG:25833  - ETRS_1989_UTM_Zone_33N
 EPSG:25834  - ETRS_1989_UTM_Zone_34N

and the layer is now finally showed in the map without problems.

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.