Turns out there is a shift in data when using the editing tools (editor menu --> clipping, intersecting) in Arc9. 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:
The former is likely the best option however from an end user perspective none of these options sound very good.
Cheers,
-- DiedreDavidson - 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)
-- MattWilkie - 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.
-- MattWilkie - 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
-- MattWilkie - 05 Apr 2006
Related ESRI Bug ID's
Related Discussion:
| WebForm | |
|---|---|
| TopicCategory | ArcBug |
Comments0