nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue with snapping and performance speed

AngelaHansen

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

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

CherylCollins

I'm using ArcMap 10.4. Pulling all the files I was using into a feature dataset in a file geodatabase solved the problem for me.

DavidMajor

This was also the solution for us, thanks!!! We have SQL 2008 R2 and ArcGIS 10.3.1. I did just loke Kevin mentioned, copied and pasted the feature classes into the same dataset, and changed the keyword to SDEBINARY. Then I deleted the old feature classes, renamed the new ones. I also used the batch create spatial indexes since those were gone, but the attribute indexes copied over fine.

I also noticed that this improved the performance when SELECTING features, especially annotation.

David

TuanVu_Huu

Dear Angela,

I also face with this problem when editing with snapping enable. if we use snapping window can help but really not convenience to work because whenever edit each layer have reset up snapping window.

Do esri help with this issue?

thanks,

JoeRhodes

Snapping problems with 10.2.2 also, especially after getting a new computer with Windows 8.1 upgrade. So to summarize:

No joined tables

No reprojected layers

No large data sets (too many vertices)

Not too many layers

Tweek your SQL spatial types

Work in a clean MXD

Build spatial indexes

Work from shape files or file geodatabases.

WOW! Seems simple enough. Just change your entire workflow.

I know, cynical.

BernardMcDermott

A coworker is experiencing the same issues with snapping. It's not everyday, it does not occur at a specific point in her editing, workflow or methods. But when it does happen it is VERY time consuming. It has never happened to myself unless I turn on my Address Points file, that is short lived though. We all connect to same server and have our own PGB versions.

In using parcel editing every day we rely on snapping for virtually every move. We don't use the parcel editing tools specifically. We use our standard construction tools for line, polygon, etc and draw them based on surveyor entries on their plats, maps and surveys. So if there is a starting point from an intersection we begin by snapping there and use the Traverse tool to run the bearings, distances and see if it closes.

Any help would be great.

Bud

Tonyalmeida

I too have encountered this issues.

I also noticed that when adding certain layers to TOC snapping fails also.

... it sucks.

OutagamieGIS

Snapping does not work for me either. I am on 10.2.2.

I had to create a new mxd and that fixed the snapping issues for me.

OutagamieGIS

Snapping does not work for me either. I am on 10.2.2.

WeisenGao

I have been encountering problems lately while editing (using 10.1 sp1). The speed of ArcMap while editing slows to a crawl, and snapping will not work

I was wondering if anyone else has encountered this issue?

RichardFairhurst

I am having same issues, if I have a layer with a table join, snapping does not work, but once join is removed it works fine.
Very annoying to have to add and remove constantly.

You can add an unjoined copy of the layer to the map so that you don't have to break and recreate the join all the time. Just turn the unjoined snapping layer on and off if it messes up your cartography. I tested this workaround and it works. Either way, I can reproduce the fact that the join causes snapping to fail on the actual joined layer so I will report it to ESRI on Monday.

JasonLyon

I am also seeing issues with snapping to any layer that is joined to a table in ArcMap 10.2. Removing the join makes snapping to that layer work again, and adding a join to any layer disables snapping to that layer.

I am having same issues, if I have a layer with a table join, snapping does not work, but once join is removed it works fine.
Very annoying to have to add and remove constantly.

JohnMorley

I am also seeing issues with snapping to any layer that is joined to a table in ArcMap 10.2. Removing the join makes snapping to that layer work again, and adding a join to any layer disables snapping to that layer.

Just installed 10.2 and I am experiencing snapping problems also. Snapping works fine unless I try to snap to a layer that is joined to a table. Is anyone experiencing the same problem? Is there a solution besides 'unjoining' the table?

KevinHigh

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.

We were having very poor performance since upgrading from 10.0 to 10.1 and this was the solution. An easy way to see your geometry storage type is to check the auto shape and length fields in a polygon feature class. If you are seeing "SHAPE.STArea()" and "SHAPE.STLength()" then you are using the SQL spatial type. The SDE Binary spatial type will show "Shape.area" and "Shape.length." I pulled copies of a few feature classes (duplicates, but one using SQL spatial and the other using SDE spatial) into an MXD and the difference between the two sets was staggering. Draw times with the SDE were four times faster than draw times with SQL. Snapping was not working with SQL, but worked perfectly with SDE.

This is all on our publication database that is made up of handful of replicas. When we upgraded to 10.1, the default geometry storage type was change to SQL and then we recreated the entire pub database, so all feature classes were then using the SQL geometry. It only affected feature classes that were created since the upgrade. After making the changes Tesla described above and recreating the pub database, our problems disappeared!

Hopefully this helps some of you.

SherryLufkin

Just installed 10.2 and I am experiencing snapping problems also. Snapping works fine unless I try to snap to a layer that is joined to a table. Is anyone experiencing the same problem? Is there a solution besides 'unjoining' the table?

dartonCharles

Hello everyone,
I've been having a serious issue after i upgraded from 10 to 10.1. The speed of the software decreased significantly when editing. If i had to select a line it would take a long time to show and its not because of my machine because it was recently upgraded as well. Also my snapping doesnt seem to work at all even though i turn all the options on. Arcmap is really slow in 10.1 for me so i dont know if anyone has a solution for this. I can really use some help please.

chelseasteed

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

Joeysmith

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

MelissaJohnson

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!

StevenChamberlain

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...

Anonymous User

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

RyanMacVeigh1

>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.

JeffAzevedo

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.

JeffAzevedo

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.

JeffAzevedo

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?

JeffAzevedo

10.1 snapping is basically unusable 😞

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

KalvanHone

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

Anonymous User

>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.

KalvanHone

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.

Anonymous User

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.

KalvanHone

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.

MikeMacRae

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!

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.