The "Longitude Rotation" transformation method in ESRI PE

[phaarnes]

Hi,

I have a question regarding datum transformations that utilize the "Longitude_Rotation" method. According to the ESRI PE database, the Longitude rotation transformation method and the respective "Longitude_Offset" parameter are supported.

Method
latestWkid: 9601
ESRI name: "Longitude_Rotation"

Parameter
latestWkid: 100051
ESRI name: Longitude_Offset

However, it seems that you are not using this method properly. All the transformations defined by this method lack the "Longitude_Offset" parameter. It appears you have implemented a workaround by simply modifying the datum of the CRSs. Despite this, I see that the transformation is correctly handled by ArcGIS Pro and other such applications, producing correct results.

For example, consider the transformation NTF (Paris) to NTF (1) (EPSG:1763).

In the ESRI_PE database, this transformation is listed with the authority "EPSG." Therefore, I would expect it to comply with EPSG standards, which it currently does not.

It goes from:
NTF (Paris) to NTF.

According to EPSG, this means a datum shift from:
Nouvelle Triangulation Francaise (Paris) to Nouvelle Triangulation Francaise
("Nouvelle_Triangulation_Francaise_(Paris)" → "D_NTF")

These datums are based in Paris and Greenwich, respectively. However, in the ESRI_PE database, this transformation is defined between the same datum D_NTF (EPSG:6275)

I see that you have changed the datum of the geographic CRS NTF (Paris) (EPSG:4807) from "Nouvelle_Triangulation_Francaise_(Paris)" to "D_NTF." Presumably, you are handling the origin shift by modifying the datum of the source CRS.

For it to be compliant with EPSG, the ESRI WKT for this transformation should be:

GEOGTRAN["NTF_Paris_To_NTF",GEOGCS["GCS_NTF_Paris",DATUM["Nouvelle_Triangulation_Francaise_(Paris)",SPHEROID["Clarke_1880_IGN",6378249.2,293.466021293627]],PRIMEM["Paris",2.33722914764581],UNIT["Grad",0.0157079632679489]],GEOGCS["GCS_NTF",DATUM["D_NTF",SPHEROID["Clarke_1880_IGN",6378249.2,293.466021293627]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],METHOD["Longitude_Rotation"],PARAMETER["Longitude_Offset",2.33722917],OPERATIONACCURACY[0],AUTHORITY["EPSG",1763]]

My questions are:

1. What is the reason for stripping of the parameter and not using the method properly? Could it be that the ESRI projection engine did not initially support this transformation method and it was added at a later stage?
2. Will this be corrected so that these transformations comply with the EPSG definitions?

[melitakennedy]

Hi Per,

There are a few things going on here. We did base the projection engine's data model on EPSG's but it was back around 1998-2000. We were much more cavalier about the choices that had been made in the EPSG data model. We didn't like the much more specific projection parameters and already had many projections that were not in EPSG, so we used a more streamlined set, and generally our own WKIDs.

At that point, the longitude rotation method was being used for prime meridian changes only. It seemed strange to give an explicit rotation value. If the prime meridians are different, then you can use the PM values to calculate the offset and handle any unit changes as well. Later, ISO included the prime meridian into the datum object and EPSG followed after. We always worry about compatibility between software versions so we didn't make that change. In Esri's data model, a prime meridian is a member of a GeoCRS/GEOGCS, not of the datum.

[phaarnes]

Hi Melita!

Thank you for your response.