Data Uploaded, Edited and Exported from AGOL is Reprojected (incorrectly)

[MalcolmMeyer]

We used Collector to digitize sidewalks in the field. The lines were drawn on the map using the editing tools - meaning the GPS location was not used. The original data (File Geodatabase) was in NAD 83 Ohio SP South (ESRI:102723) when uploaded. On the AGOL map, the sidewalk lines line up with the imagery. However, when exported as a FGDB, downloaded and opened in ArcMap and viewed with 1ft ortho imagery, the data is incorrect. It looks as though it has been reprojected. The screenshot below shows the AGOL data - BLUE - direct from the AGOL Feature Server service and the exported data - YELLOW - (exported from AGOL) on a Leaflet map, using the ESRI imagery basemap layer, the same imagery that is used the AGOL maps.

Also, if I export the data from AGOL as geojson, I get again different results. Currently it is unclear how I can get my data out of AGOL without drastically impacting its spatial accuracy. Maybe I can reproject it in ArcMap, or change the projection?

Any idea what is going on here?

[MalcolmMeyer]

This is a very serious issue as we have planned to use Collector for our highly accurate infrastructure asset collection program. The sidewalk collection was our experiment. Needless to say the results of the experiment are not good.

[MichaelDavis3]

I'd consider projecting your data to WGS84 prior to uploading to AGOL - then reprojecting the results back to state plane after you pull the results back down.  That way you can control the transformations being used.

Just a thought.

[MalcolmMeyer]

WGS84 or Web Mercator?

[MichaelDavis3]

We generally keep our database in WGS84 and then publish the map services in Web Mercator, but you might go right to Web Mercator if you want to keep it simple.

[MalcolmMeyer]

So it looks like exporting to GeoJson keeps the file in WGS84. Then you can open that geojson file in QGIS and export to shapefile form there. This gives better results. Red is geojson-to-shapefile, yellow is the exported FGDB. The FGDB is off by sometimes three feet.

Wow.

[LiseTremblay]

We are having the same problem. It started the beginning of September for us. We published data, collect it using a app (edit and smart edit tools), field check it using collector, and when we bring the data back down it shifts when we republish it. We collected data for several months without an issue. now.... my life is hell. It is like the edit environment adds records in WGS but exports the data back with a NAD83 state plane prj even though the data hasn't been moved or transformed.

This is a big problem. Help. I even tried converting the data and publishing it as WGS and projecting after I pull it back down and it still shifts. 

For the record WGS = the WGS84 aux sphere projection that ESRI suggests, and the NAD83 is state plane feet, North Carolina. I was using short hand above.

[LiseTremblay]

Also, I want to know exactly what is causing this issue. It matters for data integrity.

[MikeOnzay]

Did you discover and / or resolve this issue?

[LiseTremblay]

Yes. Publish the data as state plane both the data and the map layer. When you leave the data as state plain but have the map layer in WGS like ESRI suggests, there is a conversion that happens that causes a dataset to move when you bring it back out of the cloud cause WGS and State plain are incompatible.