2

I use arcgis 10.1 (arcinfo licence) with arcsde to connect to a SQL Server database. The initial dataset has around 100k polygons (used for land registration, having a resolution that is around 1cm and using an MTM projection). Many geoprocessing operations were made on the dataset to build several related layers (copy / paste / split / merge / join, etc.). Note: I never did any polygon simplification/generalization that would change the shape or amount of vertices in the polygon layers.

At the end of these operations I made a topology (1mm tolerance) between my initial dataset (rank #1) and the final dataset (rank #5) using the "Area Boundary must be covered by boundary of" rule to see if I landed back on my feet. I expected errors only on the polygons that I had modified. However, I got many (several thousand) errors on parts that I had not modified. The symptoms are always the same: they always affect polygon arcs. The width of the sliver/gaps is always between 0,01mm and 10mm. Vertices between my layers are always identical (looking at 1:1 zoom with X,Y coordinates) but the path between vertices is changed for some unknown reason. I have enclosed a few pictures to show the problem (the zoom pictures are at 1:1 zoom). Any idea about what could have happened and how to correct this? The main constraint is that the initial layer must remain unchanged (for legal reasons).

I have tried to change the tolerance of the topology to 1cm - it does solve 50% of my problem, but at the expense of the initial layer being slightly modified (I made an intersection between the original layer and my "initial" layer and they revealed many small changes).

I have also tried the automated "snap" tool using "Edges" and "Vertex" options, but almost nothing was changed (probably because the vertices are already in the right place. Only the arcs between vertices have problems).

sliver_gap_1 sliver_gap_1_zoom sliver_gap_2 sliver_gap_2_zoom

  • You might press legal department for a definition on what "must not be changed" means. Point out to them that if a professional surveyor's hard copy paper map is considered a legal and definitive record (likely), then the digital representation of that line has some corresponding fuzziness (the width of the pen mark is likely larger than the majority of difference you're seeing). There's a difference between "precision" (number of decimal points) and "accuracy" (degree of correspondence to real world). – matt wilkie Sep 1 '15 at 21:21
  • Pushing precision/accuracy proviso aside, hearing there are still problems with vertex coordinates changing in unedited parts of the feature class is worrisome. In the past we called this "coordinate drift" and "shifting". Here's my notes on it from a dozen years ago: old.yukongis.ca/oldsite/DataShiftOnEdit.html, with links to some long and heated threads in the Esri forums. I would ensure both of your feature classes are contained in the same Feature Dataset before editing and see if that helps (it forces identical coordinate systems and spatial domain). – matt wilkie Sep 1 '15 at 21:28
  • Thanks for the link - it might explain the issue I am having since I did transfer intermediate layers to another geodatabase and then, after doing some more editing, bring them back into the initial geodatabase/dataframe. One note however: the vertex coordinates have not changed. Only the arc between vertex has changed! – lavaman Sep 3 '15 at 12:25
2

The Integrate tool will fix small gaps in the data, but be very very very careful when using this tool on SDE data it will overwrite the existing features in the dataset with no undo.

To use this tool properly:

  • Backup your SDE data: either as XML workspace document, Geodatabase feature class (file or personal - use copy/paste), Shapefile or your current SDE backup.
  • Try it on a copy of the data first: Copy the data into a file geodatabase and run the Integrate tool with as small a tolerance you can, then test the results to see if the errors are fixed.
  • Check some of the finer areas for collapse, if there are collapsing polygons decrease your cluster tolerance and try again on a fresh copy.
  • Run it on the SDE data: Hint, use the results tab in ArcCatalog, double click on the test that produced satisfactory results and then change the data. This will ensure that exactly the same parameters that have been proven to work will be applied in SDE.

The integrate tool can save days of work but when used reclessly it can make weeks of work from days of work to fix... always have a backup when using this tool; I have learned the hard way what happens if the cluster tolerance is too large - in most cases it's quicker to delete the data and start again than to try to fix overzealous clustering.

  • Integrate doesn't meet the requirement that "the initial layer must remain unchanged" as it modifies all participating layers. As far as I know the only way to do this now in the Esri ecosystem is to go all the way back to arcinfo-workstation and coverages. (I'd love to be proven wrong.) – matt wilkie Sep 1 '15 at 20:53
  • vote on allowing Integrate to use read-only layer(s): ideas.arcgis.com/ideaView?id=087E0000000CwSrIAK – matt wilkie Sep 1 '15 at 21:59
  • Good idea @mattwilkie. I'll add my vote to that. Previously (many years ago) we had a job that required on feature class to be absolutely static (to match the clients existing data) and the rest (our edits) to integrate to it - I ended up writing a snap tool in C# to ensure that the requirement was met; I could have saved myself 3 days work if the integrate tool allowed 'static' or 'reference' layer(s). – Michael Stimson Sep 1 '15 at 22:21
  • If you still have it hanging around that custom snap tool might have life left! I found this question looking for a way faster than using the Map Topology Align Edge and/or Edit Reshape Feature tools. – matt wilkie Sep 2 '15 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.