Define Datum Transformation with ArcGIS Server

1567
4
Jump to solution
06-11-2018 08:16 AM
AlessandroValra
Occasional Contributor III

With the JS API (v. 4.7) I am creating a view which has a spatial reference RDN2008 (EPSG: 6706).

I am using this WMS as basemap, which is in this very coodinate system: https://wms.cartografia.agenziaentrate.gov.it/inspire/wms/ows01.php.

When I import some mapservers in 102100 (or 3857) to use as my operational layers, they are placed in the right location, except a big shift when zooming in details. This is due to the lack of Datum Transformation.

This is one of the mapservers I am using: OT_Demo/ReteAcqua (MapServer).

In ArcMap, I can import both the services (the basemap in 6706 and the mapserver in 102100), have the Data Frame SR set to 6706 and then I can define the transformation "RDN2008_To_ETRS_1989_1 + ETRS_1989_To_WGS_1984". This way, the operational layers match the basemap as I'd like (no shift).

These are basically two consecutive transformations to my understand:

  • RDN2008_To_ETRS_1989_1 with WKID 6710
  • ETRS_1989_To_WGS_1984 with WKID 1149

I found these same two Transformations in the ArcGIS REST API, at this page: Datum transformations—ArcGIS REST API: Services Directory | ArcGIS for Developers.

Is there a way to controlo which (if any) Datum Transformation the REST API is doing?

How can I possibly use one or two consecutive as in my case?

It seems not even ArcGIS Online can handle this correctly (it actually reads the WMS used as basemap in 4258, which is one of the options to get the WMS, and no transformation (I see this from the browser dev tools)).

If that matters, I am using an ArcGIS Server 10.3.1 but I also have access to a 10.6 although I have not tested this there yet.

Thanks in advance for any suggestion.

0 Kudos
1 Solution

Accepted Solutions
MelitaKennedy
Esri Notable Contributor

RDN2008 is functionally equivalent with  ETRS89 / WGS84. There shouldn't be a large offset even if there's no transformation being used. Could it be in Monte Mario or Roma 1940 instead?

The parameters of EPSG:6710 and EPSG:1149 are zeroes, so no shifts should occur.

View solution in original post

4 Replies
AlessandroValra
Occasional Contributor III

Ok, for some strange reason, it does not work in ArcMap anymore, or at least, it does only sometimes.

Like if when I define the transformation, it does not transform anything, and the list of possible transformation methods get messed up and list duplicated values, and some that weren't there before applying  the transormation are now magically listed...

I am talking about the DataFrame: Coordinate System tab -> Transformations -> last drop down menu.

Well, I really hope I can solve this strange problem in ArcMap, but especially that I will be able to overlap the two services correctly in AGS.

0 Kudos
MelitaKennedy
Esri Notable Contributor

RDN2008 is functionally equivalent with  ETRS89 / WGS84. There shouldn't be a large offset even if there's no transformation being used. Could it be in Monte Mario or Roma 1940 instead?

The parameters of EPSG:6710 and EPSG:1149 are zeroes, so no shifts should occur.

AlessandroValra
Occasional Contributor III

Wow, just realized it, thanks! I saw it in the docs at https://downloads2.esri.com/support/TechArticles/geographic_transformations_1031.pdf (why are they listed as transofrmation if actually there's nothing to transform?).

Mmm, that's strange though, as the official documentation of the WMS I am trying to use as basemap officially states that its SR is 6706, but it can be requested in different EPSG (4258, 25832, 25833, 25834). So basically I think the shift is not eventually not caused by the lack of a Datum Transofrmation but it is indeed a shift due to the way the service has been drawn originally.

Nevertheless, I swear I saw it overlapping properly in ArcMap for a while defining the transformations as I said, although I am now aware that this does not really make sense since the parameters are zeroes!!!....

Well, I am fine with the answer, thank you so much for clarifying.

0 Kudos
MelitaKennedy
Esri Notable Contributor

Hi Alessandro,

I call these "bookkeeping" transformations. The transformation/pipeline only sees that input/output GCS are different and can differentiate when a transformation could be skipped and when it's really necessary, so there are "null" and "parameters-are-zeroes" transformations to make the pipeline/algorithm work smoothly and efficiently.

Melita