Data Shift On Edit

Turns out there is a shift in data when using the editing tools (editor menu –> clipping, intersecting) in ArcGIS 9. This is because it uses the single precision of the data frame rather than that of your dataset.

From the sounds of the ESRI Knowledge Base it has a work around by doing your editing inside a personal geodatabase and setting your precision to double, however I don’t believe that it is possible to do in a shapefile.

So for us there are three options:

  • do any geoprocessing in Arcview 3.X (which doesn’t have this precision issue)
  • do the geoprocessing in ArcMap and clean the data in ArcInfo Workstation (if boundary follows river or physiographic feature this may not line up)
  • create all new data as personal geodatabases and set the precision etc. to double (I do not have much knowledge of geodatabases so this option will have a learning curve)

The former is likely the best option however from an end user perspective none of these options sound very good.

Cheers,

— Diedre Davidson – 19 Nov 2004

As of v9.1 this bug still exists:

“Thank you for contacting ESRI Canada Technical Support. In regards to your question about CQ00176597, unfortunately it is still listed as a known limit. There are a few other documented CQ documents related to this problem with other Geoprocessing tools and ArcSDE layers and some of them suggest that the possible fix is to happen in ArcGIS version 9.2. This is a known limitation with shapefiles, ArcSDE layers and geometry. It is a precision issue.”

Note that I have observed geometry shifing in personal geodatabases as well (I still have some more testing to do though to be sure I didn’t screw up in some other way). I think the only safe way to edit in a pgdb is to ensure all feature classes are contained within a single feature dataset.

Later:

Thanks to Ray Carnes on the ‘shifting, shifting, shifting’ thread below I’ve determined that putting all feature classes within a single feature dataset does cause all layers to be remain coincident — at least for the import stage. We’ll see what happens with edits over time.

The root cause is that when simply importing a new layer into a pgdb the spatial domain and precision is different everytime, and therefore the snapping grid is different. ESRI:27335

Note that setting a cluster tolerance of 1cm (0.01) is NOT the same as spatial domain precision of 1cm (100). The former ensures that there are no vertices WITHIN 1cm of each other (A is 2.4 thefore B must be 3.4 or 1.4), while the latter does the same AND ensures that coordinates themselves fall on even cm boundaries (A is 2.0 therefore B must be 3.0 or 1.0)

— Matt Wilkie – 10 Feb 2006

For clarity, there are two problems being discussed here. The first is the real and unavoidable bug that when editing shapefiles in ArcMap certain operations cause the geometry to shift. The second circumstance of coordinate shifting within personal geodatabases is avoidable by ensuring all layers share the same spatial domain and precision.

— Matt Wilkie – 13 Feb 2006

Another twist to this issue: “… are not able to snap a GDB polygon vertex to a shapefile vertex. Sure, when you move the vertex it ‘snaps’, and displays coincident with the .shp vertex, but sure enough, when you ‘Finish Sketch’, it hasn’t truly moved. It can only get ‘so-close’, and that’s it.” — brought to light by Justin Wolff on the SHIFTING! thread

— Matt Wilkie – 05 Apr 2006

Related ESRI Bug ID’s

  • CQ00176597 – Merging two adjacent polygons in a shapefile results in a shift. This is a known limitation with shapefiles and geometry. It boils down to a precision.
  • CQ00191714 – polygons in shapefile shift when two poly gons are merged together. This bug deals mainly with the issue of ArcSDE layers converted to shapefiles. Once user tries to merge the shift is evident. New numbers are NIM001077. NIM000450
  • CQ00188395 – Merging polygons in State Plane Oregon South NAD83 results in a slight shift.
  • CQ00195084 – Dissolve Produces Small Shift of Polygons.

Related Discussion:

Leave a Reply

Your email address will not be published. Required fields are marked *