There is a significant lag in the time between I enter a value in the Attributes menu and it actually accepting that value, going through the whole ordeal of redrawing everything, and being done with it to move on. In my street centerlines, I have four rows: L_ADD_TO, L_ADD_FROM, R_ADD_TO, R_ADD_FROM. I put in one value and I've typed this post while I'm waiting to add another one. This has not been an isolated incident and I've been dreading updating my centerlines since I started migrating to Pro because I have a lot of updates this year.
I've also encountered a similar lag issue when entering traverses that are more than just four lines. Drawing creek meanders is far far slower than in ArcMap, for instance, where there can easily be 15+ calls. It appears that Pro is checking through every single line I've entered as soon as I enter another one and it's simply inefficient.
I see this, too. Is your Pro fabric a file-based geodatabase, or a published service? I've noticed most of my lag time comes from the quality of the service connection.
@jcarlson it's in a file geodatabase on a network server. I can shave a little bit of time if I abandon all of the symbology that I used to use for easily identifying what streets need ranges input but I still end up having to sit and wait for the "Updating attributes" window to close. It might only be 10 seconds or whatever, but when I have several dozen streets to do? It really adds up between 4 fields and multiple segments for each street.
The traverse problem as been especially infuriating, as I clearly recall being able to breeze through keying calls for a huge creak meander in ArcMap's parcel fabric but now it easily takes three times as long. Same network location, same file geodatabases, etc.
Yikes! That sounds really drastic.
One thing that may help a bit is turning off the Attribute Pane's Auto Apply setting, then it applies the four field updates in one go. But there's clearly something else at work here...
Right? I've gone through the basic troubleshooting steps. Tried remaking everything and I'm pretty sure it's not an issue on my end.
I'm going to try turning off auto apply though, as nice of an idea that feature was.
You could also turn on the Monitor (Ctrl + Alt + M) and see if there are specific events that seem to be taking longer than others. Not all of it's super comprehensible, but if it escalates to Support call, you can share the diagnostic log with them.
Oh wild, thank you for the tip. This might help?
Hopefully! I was having some weird lagginess once, and looking at the Monitor helped identify that it was coming from some repeated licensing / sign-on status calls.
It sounds like there are two distinct parts to this idea.
The issue with Traverse if over here https://community.esri.com/t5/arcgis-pro-ideas/pause-auto-commit-during-traverse-in-pro/idi-p/936677 I'd encourage you to vote and comment as needed.
Thank you
yeah, I voted and all that. the comment on it was from last year and apparently there's no traction on this problem yet.
This sounds more like a bug that needs to get fixed than an idea for an enhancement. At least this is how the development team has been addressing it. We expect responsive data entry for all editing operations.
We have made some improvements in ArcGIS Pro 2.8 and will continue to work to improve the lag time.
Which version of ArcGIS Pro are you using?
Did you try to move the file geodatabase frm the network drive to your local machine to see if this is caused by a network issue?
Please submit a technical support case whenever you encounter an issue that falls short of your expectations.
Thanks,
Amir
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.