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

Huge Feature Class load slowly in Arcmap & Server

ElieRizk

i have big layer of LV electrical lines (~1.2 million records)
If the layer is stored in a filegeodatabse or SDE, it loads very slow in arcmap or in the web application (takes around 10 s to display all features)
- i tried to recalculate the index nothing changed
- create new index again nothing changed
- minimize the number of fields

if i export the layer to shapefile it loads very fast (2 s) in ArcMap

any feedback on the above?

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

ElieRizk

Thank you all for your responses.

I monitored the layer's loading in Arcmap according to the tips you provided, it is definite that my data is spatially fragmented. I did not reorganize the data yet, but when I tried the below steps:

1- Clear the layer's Metadata in ArcCatalog
2- Delete the existing spatial index
3- In ArcCatalog, I removed the layer from its existing data set to a new empty data set, where I set the extent of the new data set to be that of the layer
4- Rebuild the spatial index

After applying the above, performance improved from ~12 seconds at scale 5000 to only 2 seconds with labeling (around 6000 features load at this zoom scale) . I think that the first step done was the main step in improving the performance. I still have to reorganize my data to get optimal performance

MarcoBoeringa

1- How can I tell if my data is spatially fragmented or not?

The short answers are:
1) By observing the character of the returned rows
2) Reorganize the table with an ORDER BY query
3) No, the index isn't the problem.

To supplement the bold comment: do the returned features while in the process of being displayed in ArcMap pop-up randomly all over the screen (sign of spatial fragmentation!), or do they draw from one side of the screen to the other (direction arbitrary) or, more logically, in blocks / groups of features in close proximity to each other (data spatially structured, less fragmentation), e.g. when the data has been added to the table on for example a neighbourhood-by-neighbourhood or county-by-county basis.

3- Doesn't spatial index help in this case?

Not much, if the data is all over the place in terms of spatial location, to extract a single view in ArcMap, ArcGIS will need to do an almost full table scan (or at least pick specific record data from everywhere in the table) in the table to get your data, which is less efficient than reading large blocks of grouped data. You really need to restructure the data in this case, as Vince suggested, especially if the Feature Classes contain massive amounts of records.

VinceAngelo

Using the "Search Forums" box above with the terms "spatially fragmented" returned
a dozen threads, most of which answered all three questions.

The short answers are:
1) By observing the character of the returned rows
2) Reorganize the table with an ORDER BY query
3) No, the index isn't the problem.

- V

ElieRizk

I tried to do my research about spatially fragmented data but did not get answers.

1- How can I tell if my data is spatially fragmented or not?
2- And if yes, What are possible solutions for this case?
3- Doesn't spatial index help in this case?

Thanks again for your response.

VinceAngelo

Changing indexes will not improve the performance of a full table scan query (since,
with any luck, the index isn't being used; if your layer envelope is misconfigured,
indexed access will slow full table scan performance). Multi-level indexes will
usually hurt performance on layers with a normal distribution of feature extents.

If you have scale dependency set so that only a small portion of the table is being
displayed and it's still slow, one possibility is that the data is spatially fragmented
(neighboring features are nowhere near one another in the table, causing wasted
I/O to read pages and ignore most of the data). Changing indexes will not help
in this situation either, since the inefficiency is inherent to the table organization.

- V

ElieRizk

Thanks for your reply.

In the MXD, I have set scale dependency for this layer to turn on at scale 5000 only.

The main issue here is that it is taking the same time (~10 seconds) to render 6000 features at scale 5000.

I have another poly-line layer with +200,000 features and it is working fine.

Only this Electrical lines layer presents performance issues. I tried the multilevel spatial index, I tried to remove all fields, nothing changed.

VinceAngelo

Ten seconds is actually pretty fast to render 1.2 million features. As a rule, scale
dependency should be set so that layers with more than 100k features are not
rendered until less than 50k features would be displayed.

- V

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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