Select to view content in your preferred language

Why is my data not transforming to WGS84 as expected?

543
2
Jump to solution
03-06-2019 04:26 PM
RobBlash
Frequent Contributor

I have data in NAD 83 State Plane NJ ft which was published as a hosted feature service from ArcGIS Pro 2.2. Before publishing I specified the transformation to WGS84 (NAD_1983_To_WGS_1984_5)


I am passing line centroid coordinates from that HFS (in WGS84) to a Survey123 survey. The points in the Survey123 hosted feature service (which is in WGS84) do not overlay the line as expected when viewed in ArcGIS Online (with an Esri basemap). There is a shift of ~3 ft.

If I bring all of the data into Pro and set the transformation to None everything lines up. However, when I set the above transformation in the Pro map I see the shift. I'm starting to suspect the centroid coordinates are to blame. I need to do more testing to see if I can narrow it down. For now, I'm asking here to see if anyone has encountered this before.

0 Kudos
1 Solution

Accepted Solutions
RobBlash
Frequent Contributor

Unfortunately we need to keep the data in State Plane so that's not an option. I did resolve the issue, it was due to the coordinates passed to Survey123. A combination of different workflows by different users (impacting the transformation of WGS84 coordinates) along with some unexpected rounding issues caused the shift.

Thanks for the suggestion.

View solution in original post

0 Kudos
2 Replies
AdamEversole1
Esri Contributor

Hi Rob, 

Is it possible to get the Feature Class and the Map to have matching Coordinate systems prior to publishing. When the systems match no transformations would not be necessary.  

Let me know if this suggestion helps or not.

- Adam

RobBlash
Frequent Contributor

Unfortunately we need to keep the data in State Plane so that's not an option. I did resolve the issue, it was due to the coordinates passed to Survey123. A combination of different workflows by different users (impacting the transformation of WGS84 coordinates) along with some unexpected rounding issues caused the shift.

Thanks for the suggestion.

0 Kudos