Community

Feature Service Spatial Reference in Pro

564
2
07-13-2022 09:23 PM
Status: Needs Clarification
DavidGifford
by
Occasional Contributor

In Australia we are moving to a new datum, GDA2020. The previous datum, GDA94, was for all intents and purposes identical to WGS84 so if the user forgot to set a transformation the data would still align. With GDA2020 there is an approximate displacement of 1.8m, so in order to reduce risk it's important that as much of our Australian data is in GDA2020 as users aren't infallible when it comes to setting transformations.

Easy I thought, just create a new feature service in GDA2020 with the transformations already built in, so that the SDE source layers (in WGS84) will be available in GDA2020. As the SDE source layers are global, they need to be kept in WGS84 so can't be transformed to GDA2020. This is where things unravel.

As shown below, ArcMap will honour the GDA2020 service spatial reference for both map and feature services. Pro will honour the GDA2020 service spatial reference for the map service.

DavidGifford_0-1657771627248.pngDavidGifford_1-1657771716173.png

Pro will not honour the GDA2020 service spatial reference for the feature service, instead it uses the source spatial reference WGS84.

DavidGifford_3-1657772497661.png

So feature services in Pro is the anomaly when it comes to spatial reference. This anomaly appears to be "as designed" by Esri Inc, as recorded in this bug https://my.esri.com/#/support/bugs/BUG-000134342. The alternate solution is to reproject the data source, which is not practical. Strangely the status is non-reproducible.

So my ArcGIS Idea is to have Pro use the service spatial reference like it does for map services, instead of the source spatial reference. Or at least provide the option of using either service spatial reference or source spatial reference.

 

Tags (1)
2 Comments
RussellBrennan
by Esri Contributor
‎09-26-2022 06:54 AM
Status changed to: Needs Clarification

Hi David, 

As you state the behavior you are describing is expected. The intention of using the source spatial reference in Pro is to avoid adding overhead (aka reprojection) to query requests by default. We report the actual (source) spatial reference of the data which means users are more informed when reprojection is occurring. This is especially informative when multiple layers are published from different spatial references. You are correct that this is a difference in the way Pro handles the spatial reference when compared to ArcMap.

Pro will treat feature layers (from feature or map services) as individual datasets rather than as maps. This means that the published map spatial reference is not used by default instead we use the source spatial reference as you describe.

Are you able to set the spatial reference of the published map after adding these layers? If you do this, you can set the Pro map's spatial reference to your desired GDA2020 and the transformations you authored should be used. You can do this after adding the data to the map or you can set your Map and Scene properties such that GDA2020 is the default rather than using the 'first operational layer'. 

DavidGifford
by
‎09-26-2022 10:13 PM

Hi Russell

Pro 2.9.3 treats layers from feature and map services differently.

  • In a map service it will use the map service CRS
  • In a feature service it will use the layer source CRS.

For example if I add the same GDA2020 map service (with layer data source WGS84) to Pro as a map service and feature service, it will read the layers from the map service as GDA2020 and the layers from the feature service as WGS84. I can check this by setting the transformation method in Pro to "none", and the data no longer overlaps.

So maybe to make the experience consistent in Pro, this idea should be "Make all map services use the layers source CRS" so that when a map service is added to Pro, it uses the CRS of the layer and not the service.