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; } } }

Domain Resolution and Tolerance - Anomalies

DanielSteuber

Hey all,

So I've noticed increased sluggishness with multiple feature classes in specific datasets within our SDE database regarding being drawn on screen. If I export/import them into another dataset, they will load quick and efficiently. It would be nice to avoid this as the overall solution as I would have to go through and fix a lot that links back to them via the existing pathways.

The one common denominator I've found is the Domain Resolution and Tolerance tab will have some crazy figures on the slow loading dataset offenders. Is there ANYWAY to correct this without going through and starting over with new datasets? Is that even a possibility for a cause of my sluggishness problem to begin with? They were not always this way, which leads me to hope that since they were changed, they can be changed again(?). We're currently in the middle of a billing system upgrade that touches our GIS and it would not surprise me if something was messed with. I've gone through and compressed the database already, no dice.

That being said, please, talk to me like I'm 8 years old as I'm not a specifically formally-educated GIS guru and you're not going to hurt my ego hahaha See attached for some screenshots of good and bad dataset Domain Resolution and Tolerance tabs. Thanks in advance if you can offer any advice on this!

Bad Dataset.PNG

Good Dataset.PNG

JanelleShank_0-1713900977061.png

KaitlynM_0-1713900899522.png

Trouver plus de publications taguées avec

Geoprocessing

Enterprise geodatabase

Databases

Accepted answers

All comments

DS_GIS

Hello,

Out of curiosity have you been running database maintenance steps such as: Rebuild Indexes, Analyze Datasets, and Compress database?

I have had services become quite sluggish and these steps will increase the efficiency of the database along with the services within.

Sincerely,

Danielle

DanielSteuber

Hey Danielle, thanks for the quick response. So I had analyzed the datasets and compressed the database, but I had not tried rebuilding the indexes. I'm going through now and will respond when I've hit them all. On some preliminary checks in SSMS, I am finding some significant fragmentation so here's hoping that's all it is! I'll pop back in here when I'm done with the findings/results. Thanks!

DanielSteuber

Update: Nope, no dice on the rebuilding being the solution. Still the same sluggish response from those datasets. But hey it needed to be done regardless, so more thing to try checked off the list anyways!

DS_GIS

I'm so sorry to hear that! I've had quite a few different services with issues being sluggish and found that this was the solution. Out of curiosity, did you connect to the SDE as the system admin so you could include the system tables when you ran those steps?

Another thing I just considered, are any of the services in this SDE published to a server? Or are they only worked on within the SDE? Also, do you have versioning applied to this dataset?

DanielSteuber

So I'm in as the admin, no issues there. All feature classes are registered as versioned.
You did hit on something I had in the back of my mind though and I did a little investigating. Yes these feature classes are published as services on our separate GIS Webserver that connects to this main SQL Server. We do this for access to Collector/Field Maps on our iPads, but there really aren't that many people on it at once. Maybe 6-8 maximum at a time, and I still get the slow responsiveness when I kick people off, or disconnect the WebServer entirely from the network. Other features that are published on the Webserver outside of the datasets I talked about previously seem to be fine as well, so I don't think that specifically is the issue. Very strange indeed.... Thanks for the ideas!

VinceAngelo

I'm getting HTTPS errors on your file links. If you put the parameters in the question as text, then no one would need to download an image for the definition of "crazy."

Yes, spatial reference tolerances can have an impact on the compression algorithm used to store geometry, but only when using Esri's ST_GEOMETRY storage (you haven't specified the RDBMS or geometry storage type, either).

Yes, correcting the feature dataset spatial reference generally requires a complete reload of all the feature classes, and replacing a feature class spatial reference generally requires recreating and reloading the feature class.

- V

BasuMathapati

I too looking a solution for the comment you mentioned :

...found is the Domain Resolution and Tolerance tab will have some crazy figures..

Did you find a better way to create a fresh dataset\feature class and set these figures right ?

I observed domain values sets out automatically while creating FD or FC, is that efficient ? but those domain values are too wide than my area of interest where I'll be creating my features.

Feature Extent can be recalculated, but what about these 'Domain, Resolution & Tolerance' tab ?

Any one has any solution ? come across this ? or should we simply ignore these domain values ?

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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