POST
|
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.
... View more
02-09-2017
10:09 AM
|
0
|
0
|
938
|
POST
|
Also, I want to know exactly what is causing this issue. It matters for data integrity.
... View more
10-07-2016
02:11 PM
|
0
|
2
|
938
|
POST
|
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.
... View more
10-07-2016
02:06 PM
|
0
|
0
|
938
|
POST
|
My strategy is to make sure there are unique ID's in the feature you want to update, even if you have to make a temp attribute. run an intersect. join the new feature to the old one using the unique ID and calculate the attribute based on the joined attribute that has the correct info cause it was intersected. For poly to poly intersects, I convert the one I need to update to a point first again... unique ID is the key.
... View more
08-25-2016
12:12 PM
|
0
|
0
|
990
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|