Strangeness - gaps unintentionally created while editing

ChrisDonohue__GISP · ‎10-13-2015

I've been asked to update our City's parcel layer based on changes the County sent us and am noticing gaps being created when editing. This happens both when editing in a Version of the Parcels in SDE and when editing the same data in a File Geodatabase. We are using ArcGIS 10.2.1. with an Advanced License.

For example, one of the updates was a parcel split. Using the County's line layer, I set out to split the parcel. Red lines are the County data and the Green polygons with black borders are the City parcels data. So in this case, the first task is to split into two the left-side polygon to create "Polygon A" and "Polygon B" (currently A and B are one parcel).

NOTE - our data varies from the County's slightly (long story) and that is currently OK, so the task is to modify our data as close as possible based on the County's changes. So we are going to split the parcels (yellow highlighter) but not worry about the fact the county data for the boundary of "A/B" to "Polygon C" is off by 0.0000796 feet.

When I do the split, weirdness results. The original polygon has now been split to "Polygon A" and "Polygon B", but now there is a gap between those two and "Polygon C" (the white space). That was an unexpected outcome.

To do the split, I used the "Cut Polygons Tool" on the Editing Toolbar along with the "Trace", and then spanned the gap well into "Polygon C" with the "Cut". So how come there is a gap there now (the white space)?

The gap is definitely a problem. As part of testing to see what is going on, I tried going one step further and Merging the polygons that I had originally split. The result is they do merge but the gap remains. So it seems unlikely to be a visual thing.

So I'm a bit puzzled. I've done a considerable amount of editing over the past several years but not run into issues like this.

Note that the scale depicted here is very zoomed in (1:0.02). Given that this is happening at this micro level, I almost wonder if the XY Tolerance and Resolution settings are off. Here is what we are using (set same for both the File Geodatabase and SDE Version).

So I guess my question is what is causing this and how do I fix it. I know this can be corrected "after-the-fact" with Topology, but we'd prefer not to create problems on the front end while editing. It almost seems like a setting is off. Any ideas?

Chris Donohue, GISP

ChrisDonohue__GISP · ‎10-15-2015

Update:

Did another round with ESRI Customer Support and were able to replicate the issue this time. We also looked at a line edit I did where the result appeared to be a line overshoot when viewed at a scale more zoomed in than 1:1.

The resulting answer is that due to the micro scale what appears to be errors are essentially visual artifacts due to the extreme scale and not a realistic view.

More explanation from the followup email from Customer Support:

As per our phone interaction, a map scale past 1:1 is a known limitation of our software because at a scale of 1:1, the screen display is equal to the actual distance of objects on the earth's surface (i.e. an inch on your screen is equal to an inch on the ground). When you go past that scale, it may appear that features are overlapping (when in reality) what you are seeing is the actual software resolution tolerance pushed past it's maximum threshold. In essence, the entire screen is only one point (at a map scale of 1:0), which is why your work flow is producing inaccurate results.

So in a nutshell, what you see when zoomed in closer than 1:1 is not an accurate depiction.

Chris Donohue, GISP

View solution in original post

DarrenWiens2 · ‎10-13-2015

Hard to give much help without the data, but you may want to try a Check Geometry to see if there are any problems in the vicinity.

ChrisDonohue__GISP · ‎10-13-2015

I'll give that a shot.

Chris Donohue, GISP

ChrisDonohue__GISP · ‎10-13-2015

The Check Geometry came out clean (no issues).

Here's the data in a File Geodatabase, in case anyone wants to see if they can replicate the issue (please see attached zip file). It includes the "before" and "after" feature classes.

Chris Donohue, GISP

NeilAyres · ‎10-14-2015

At first I thought that this must be the result of some XY tolerance problem.

But then I copied your "before cut" layer, and did the cut again.

But I don't get the shift or the resulting nasty sliver.

Everything looks as it should. But I am editing into your fgdb, not SDE. Perhaps there's something else going on.

Try your side with the data as is now, ie in an fgdb.

ChrisDonohue__GISP · ‎10-14-2015

Thanks for replicating the process. I still get the sneaky suspicion that a setting is off on my end, as it worked fine for you. I'll retry it on my end and see if it still is an issue (probably later today - I have another fire to put out).

Chris Donohue, GISP

BenLeslie1 · ‎10-14-2015

My first guess would be that it's an accidental move as a result of not having set the Sticky move tolerance in:

Editor-->Options-->General

ChrisDonohue__GISP · ‎10-14-2015

Interesting idea. The sticky tolerance is currently set to 20 pixels. I'll play around with that to see it resolves the issue. Running the sticky tolerance up to 1000 should make it immovable (in theory).

Chris Donohue, GISP

ChrisDonohue__GISP · ‎10-15-2015

Update - tried changing the Sticky Tolerance to a high value, but still had the same issue with the gap appearing.

Contacted ESRI Customer Support a short while ago and ran through some ideas. Interestingly, when I tried on-screen to redo the cut, it worked fine and no gap was created (Murphy's Law - when you contact Tech Support, of course the issue doesn't replicate). Still we ran through some ideas on what else to check.

Things checked:

XY Tolerance and Resolution seems reasonable.
Cut process seems reasonable.
All data layers are in same Projection/Coordinate System/Datum.

After I got off the phone, retried the cut with the same data and of course it created the gap again.... DOH! It must be the aura of Customer Support that makes my computer behave when they are present. Maybe the remedy is to get a Customer Support presence installed as a continuous service...

I'll post more if I find a solution.

Chris Donohue, GISP

NeilAyres · ‎10-15-2015

Yep, that's the way. When the man is there it works just fine....