topic Re: Issue with snapping and performance speed in Data Management Questions

Issue with snapping and performance speed

AngelaHansen — Fri, 06 Jan 2012 17:49:30 GMT

Hi All,

We have been encountering problems lately while editing (using 10 sp 2). The speed of ArcMap while editing slows to a crawl, and snapping will not work (unless classic snapping is enabled).

I was wondering if anyone else has encountered this issue?

Thanks,
Angela

Re: Issue with snapping and performance speed

RhondaGlennon — Fri, 06 Jan 2012 18:19:10 GMT

Do you have a basemap layer (created either by Add Data > Add Basemap Layer or New Basemap Layer in the table of contents) in your map? We have found that sometimes large features in basemaps can cause snapping performance issues. If so, try turning off the basemap and seeing if snapping improves.

Please contact Esri Support so an analyst can work with your data and help us resolve issues like this.

Re: Issue with snapping and performance speed

RichardFairhurst — Fri, 06 Jan 2012 18:37:01 GMT

Hi All,

We have been encountering problems lately while editing (using 10 sp 2). The speed of ArcMap while editing slows to a crawl, and snapping will not work (unless classic snapping is enabled).

I was wondering if anyone else has encountered this issue?

Thanks,
Angela

This is always a problem in all version of 10 I have used (SP3 currently) and I find it virtually unusable. If the spatial index of a layer is not operating correctly it make editing nearly impossible. Since we went from Oracle to SQL Server our parcel layer's spatial index does not work correctly which makes editing nearly impossible if the new snapping environment is on, since that layer is our biggest. But the same problem occurs if there are a large number of layers in the map. The more layers and the larger number of features in the layers has a huge effect on snapping performance with the new snapping environment. I have not tried experimenting with adjusting snapping tolerances, but that would be one place to start. Other than that contact Tech Support as suggested above.

Re: Issue with snapping and performance speed

TylerBoyle — Thu, 26 Jan 2012 16:04:49 GMT

I also had this issue while editing. Make sure all of the data in your map is in the same projection. ArcMap will warn you which layers have a different projection than the data frame when you start editing. After I did this my editing jumped to near instant speed and snapping worked like a charm.'

Hope this helps,

Tyler

Re: Issue with snapping and performance speed

MikeMacRae — Thu, 26 Jan 2012 21:34:29 GMT

I've had the same performance issue too. Usually only with large file size datasets. I've had issues with snapping. The only work around I've found was to start a new ArcMap, ad the editing layer as the only layer and edit from there. That fixes my snapping issue, most of the time, my performance issue. This may not be workable for you though. ESRI, please fix!

Re: Issue with snapping and performance speed

KalvanHone — Thu, 29 Mar 2012 17:05:38 GMT

I am experiencing similar performance issues with snapping in ArcGIS 10 SP4.

I've been searching for information on how the snapping environment works as it appears to require caching of all potential snapping geometry into memory when starting an edit session, but this thread is the only information I've found talking about performance issues.

My observations are similar. The fewer layers in the map document, the better editing/snapping experience. The smaller the files, the better the snapping experience. Switching to the classic snapping environment provides no boost in performance. I didn't test snapping using files in different projections/coordinate systems, but I think the comment regarding indexing is right on.

The biggest breakthrough came when I loaded only two layers in ArcMap and tested snapping to a 150Mb parcel shapefile and ArcMap fell on it's face and was excruciatingly slow with no snapping ability. Snapping on the same parcel file loaded into file geodatabase...very fast with no problems. Snapping performance on the same parcels loaded into SDE is somewhere in between. I can open a map document with several SDE layers (including parcels), start an edit session, and although ArcMap performance does not slow down noticeably, the interactive snapping does not appear regardless of which features over which I hover! I then walk away from my computer for 15 minutes, come back, and the interactive snapping magically starts working beautifully.

Please do not point us to help documentation on how to use snapping or another blog on how to effectively use the simple, flexible, and great new snapping environment. Someone please provide better detail on what ArcMap does to enable snapping when an edit session is started please so we can find work-arounds to these snapping performance issues.

Thanks.

Re: Issue with snapping and performance speed

Anonymous User — Fri, 30 Mar 2012 16:06:22 GMT

As a generalization, snapping works by loading features into a snapping cache which is then evaluated against the cursor position. If you have a feature that has a lot of vertices such as the US coastline, a county boundary or the void between tax parcels (if you model this) then it takes time to load the entire feature into the cache. This is the largest performance bottleneck in the process.
Classic snapping and the new snapping work the same way, the difference being that you specify the layers in classic.

In addition to the basemap options for snapping in 10.1 we have also changed the feature loading algorithm, such that its faster than classic snapping for the same layers.

Re: Issue with snapping and performance speed

KalvanHone — Fri, 30 Mar 2012 16:45:25 GMT

Thanks for your response Sean. This confirms my suspicion of a snapping cache for which I could find no documentation. Can you please provide more detail on the feature loading algorithm?
For example:
Is this performance bottleneck related to issue NIM069319 fixed with SP3?
At what point is the feature loading algorithm called/started?
Does the feature loading algorithm load features into the snapping cache for the entire layer, or just what is inside the visible extent, or some combination thereof?
Does the feature loading algorithm load features into the snapping cache for only the layers visible in the table of contents, or visible and non-visible alike, or those layers in the editable workspace, or some combination thereof?
Does the feature loading algorithm take advantage of field indexing?
Would it make sense for the user to have some control over certain options in the Editor Options dialog on how the feature loading algorithm behaves?

Thanks again.

Re: Issue with snapping and performance speed

Anonymous User — Fri, 30 Mar 2012 22:14:00 GMT

>Is this performance bottleneck related to issue NIM069319 fixed with SP3?
No, that was a separate issue. The recent performance change was made to 10.1 only.

>At what point is the feature loading algorithm called/started?
Snapping is evaluated every time you move the mouse with a tool that has snapping enabled. This includes most of the editor tools and some outside such as the measure tool. Features are loaded as needed by the snapping environment. There's a bit more info in the developer help.

>Does the feature loading algorithm load features into the snapping cache for only the layers visible in the table of contents, or visible and non-visible alike, or those layers in the editable workspace, or some combination thereof?
All visible layers in the TOC that make sense (eg. not raster, annotation etc) are snapping candidates. Since its layer based it will also respect definition queries, scale thresholds etc.

>Does the feature loading algorithm load features into the snapping cache for the entire layer, or just what is inside the visible extent, or some combination thereof?
Features near the mouse location are loaded. Keep in mind a feature can extend way off the visible extent and this is one of the performance hits that we improved. Large complex features are the main problem here.

>Does the feature loading algorithm take advantage of field indexing?
It takes advantage of the spatial index and the arcmap feature cache if they are present. Performance improvements will vary here.

Re: Issue with snapping and performance speed

KalvanHone — Tue, 03 Apr 2012 14:16:46 GMT

Thanks again for your reply Sean. The link you provided to the SDK documentation answers my remaining questions.

Re: Issue with snapping and performance speed

JeffAzevedo — Thu, 02 Aug 2012 15:24:29 GMT

10.1 snapping is basically unusable 😞

*After doing a quick test exporting the same data from our SDE to Shapefiles, everything works fine?

Re: Issue with snapping and performance speed

JeffAzevedo — Thu, 02 Aug 2012 16:12:00 GMT

I talked to tech support and they had me make a new mxd and import my layerfiles from my old (10 or 9.3.1) mxd into the new 10.1 mxd. This fixed all of my snapping problems.

Also, they made me aware of a current 10.1 bug that changes your map's coordinate system after you add in certain basemaps (mine was when I added in Bing Aerial basemap). so check your maps coordinate system and make sure it is the same as your data. This will cause your snapping to be slow or unusable also.

Thanks for the reply.

We don't have any older files to use, so I saved a blank MXD (10.1) and added the same features back in (ArcSDE 10.1) and it worked fine, until I added another feature. So the original test of Subdivisions & Centerline features now snap very well, but when I added our streets, it's back to poor performance. Very strange.

Any chance you are using MSSQL 2008 with the Spatial Data types?

Re: Issue with snapping and performance speed

JeffAzevedo — Thu, 02 Aug 2012 16:50:56 GMT

I think it has something to do with SDE's and not the vertices count, because I can export the Streets feature to Shapefile, and it works perfectly.

Re: Issue with snapping and performance speed

JeffAzevedo — Tue, 14 Aug 2012 16:52:38 GMT

This might help others using MSSQL 2008.

(Our problems revolved around very slow snapping, measure tool and any queries)

The SQL Spatial types have impaired our performance greatly. When running the same problematic features as SDEBinary, in the same Dataset, our performance issues are gone. Is this a fix for all using MSSQL 2008? I can't say that for sure, but it definitely has made a big difference on our data.

If you are running a similar setup. Simply copy and paste a feature into the same Dataset, and change the keyword to SDEBinary. If you don't see SDEBinary, you may be setup where the Binary option is your default. You could check DBTune to see the default "GEOMETRY_STORAGE", ours is set to "GEOMETRY".

Good luck.

Re: Issue with snapping and performance speed

RyanMacVeigh1 — Wed, 12 Sep 2012 21:25:24 GMT

>Is this performance bottleneck related to issue NIM069319 fixed with SP3?
No, that was a separate issue. The recent performance change was made to 10.1 only.

>At what point is the feature loading algorithm called/started?
Snapping is evaluated every time you move the mouse with a tool that has snapping enabled. This includes most of the editor tools and some outside such as the measure tool. Features are loaded as needed by the snapping environment. There's a bit more info in the developer help.

>Does the feature loading algorithm load features into the snapping cache for only the layers visible in the table of contents, or visible and non-visible alike, or those layers in the editable workspace, or some combination thereof?
All visible layers in the TOC that make sense (eg. not raster, annotation etc) are snapping candidates. Since its layer based it will also respect definition queries, scale thresholds etc.

>Does the feature loading algorithm load features into the snapping cache for the entire layer, or just what is inside the visible extent, or some combination thereof?
Features near the mouse location are loaded. Keep in mind a feature can extend way off the visible extent and this is one of the performance hits that we improved. Large complex features are the main problem here.

>Does the feature loading algorithm take advantage of field indexing?
It takes advantage of the spatial index and the arcmap feature cache if they are present. Performance improvements will vary here.

Is the snapping cache cache in memory or on disk? If it�??s on disk what is its location? We have a client with a very restrictive environment and they are experiencing the same issues as others here. I think it could be caused by insufficient privileges to the directory of the snapping cache.

Re: Issue with snapping and performance speed

Anonymous User — Thu, 13 Sep 2012 15:22:04 GMT

The snapping cache itself is in memory. The slowest part of the process is getting the features from disk into it.

Re: Issue with snapping and performance speed

StevenChamberlain — Wed, 12 Dec 2012 16:40:26 GMT

I think it has something to do with SDE's and not the vertices count, because I can export the Streets feature to Shapefile, and it works perfectly.

I had a similar issue as other users in this thread, and in working through it noticed that if the layer I'm editing is in a different workspace than the one I wanted to snap to (2 FCs in 2 separate File GDBs...), it seemed to work much faster...so I wonder if its not so much an issue of format (i.e. SDE vs. Shapefile), but instead an issue of the editable workspace...

Just wanted to add my $.02 in hopes it may help...

Re: Issue with snapping and performance speed

MelissaJohnson — Mon, 25 Feb 2013 20:22:25 GMT

I have horrible trouble with snapping being slow and jerky. I am cutting polygon features. This is with both classic and new snapping and have adjusted the snapping tolerance. One other thing I have noticed is that the Control - V to show vertices also is flaky. You sometimes have to hold the button down for a long time or try several times to get the vertices to show up, and even then they don't always all appear. It is really annoying. Sounds like there are a lot of folks having issues with it. Hope it get fixed in the next service pack!

Re: Issue with snapping and performance speed

Joeysmith — Mon, 25 Mar 2013 08:14:22 GMT

That fixes my snapping issue, most of the time..

Re: Issue with snapping and performance speed

chelseasteed — Mon, 24 Jun 2013 02:00:04 GMT

I was having the same problem with snapping and editing slowing to a crawl. I remembered having an issue with trace a while back and a previous forum workaround/suggestion was to fix the spatial index which in that case had become corrupted for some reason. So I decided to check the properties of the feature I was trying to snap to in ArcCatalog and saw there was no spatial index. Remedied that and now snapping is fully operational again. Not sure why the spatial index sometimes becomes corrupted (I'm not tech savvy) and new to Arcmap but it was a simple fix that worked for me. Hope this helps