topic Re: Spatial Index for st_geometry layers in Data Management Questions

Spatial Index for st_geometry layers

ModyBuchbinder — Thu, 01 Aug 2013 11:59:35 GMT

In Version 10.1 you can no longer set the spatial grids sizes for st_geometry feature classes in Oracle.
In fact you cannot even see what the sizes are.
You must use some other tools like command lines (that are not going to be supported in the coming versions) to deal with the grid sizes.
We have a few questions on the subject.
1) Is the index still base on girds (up to 3 levels)?
2) How the initial size is set when you create an empty layer (by spatial reference?)
3) Is it going to be changed automatically? If we enter the first 1000 line with a length of 1000 meters and then add 1000 other lines with length of 10000 �?? is the grid size going to be changed?
4) Is there any way to check the sizes and should we do it? In 10.0 we found a few feature classes where the system recommendation was far from ideal!
5) Should we rebuild it? Does it change the sizes or just rewriting the index data?

It works just like File GDB but then we do not save big layers for many users in FGDB.

Thanks
Mody

Re: Spatial Index for st_geometry layers

VinceAngelo — Thu, 01 Aug 2013 14:00:58 GMT

I've moved on to 10.2 already, but I can still specify grid sizes when creating a feature class
through the UI (it's now in Environment Settings -> Geodatabase Advanced), and I can still
specify a st_grids parameter in SQL in the CREATE INDEX command.

As to your questions:
1) No change (but you shouldn't ever need three levels)
2) No change (empty layer has a nominal index populated, just the SPIDX_AUTOMATIC setting [0,0,0])
3) No change (you never want an application to change your index without explicitly requesting
such a change, and feature length has no bearing on the proper spatial index size, only data
envelope size, and more importantly, query envelope size)
4) I don't see any way to view the grid sizes, though I expect they're available through Python.
5) No change (You can rebuild the spatial index from the UI or command-line tools, or through SQL)

I've never left spatial index grid size to chance, but I've also never measured any significant
performance difference +/- 200% of the values selected -- By comparison, my testing indicates
that feature class precision makes a *HUGE* difference in performance, so that's what you want
to be sure to customize.

- V

Re: Spatial Index for st_geometry layers

ModyBuchbinder — Thu, 01 Aug 2013 15:10:51 GMT

Hi Vince

Thanks for the answer. Most if it is understood but not all.
I create an empty feature class. It has automatic index.
Then I add 1000 feature with envelope size of 100 meter. Do I need to recalc my grid size? How?
A week later I add 1000 more features that has envelope size of 10000 �?? what should I do?
It does not make a big different with 2000 features but when you have 2000000 features and 50 people is working (display and spatial queries) on this layer it should make a different.

Thanks

Re: Spatial Index for st_geometry layers

VinceAngelo — Thu, 01 Aug 2013 16:24:08 GMT

The automatic calculation of grid sizes is based on the data. A better method is
to calculate indexes based on both the feature envelopes and the mean query size
(which can't be automated). If your table and/or query characteristics change,
then rebuilding the indexes becomes necessary, though under 10k features,
it probably doesn't matter all that much.

The more features you have, the more important getting the indexes right is, but
in my experience, getting the coordref right is the most significant tuning step.
For large tables (over 1m features), spatial fragmentation is the second most
significant aspect of data tuning.

The number of users doesn't change the nature of the table, just the significance
of getting indexes correct.

- V

Re: Spatial Index for st_geometry layers

ModyBuchbinder — Mon, 05 Aug 2013 06:54:57 GMT

Hi Vince

Sorry but we are getting even more confused.
You are writing "feature class precision makes a *HUGE* difference" and "getting the coordref right is the most significant"
Isn't this parameter part of the default information per coordinate system and should not be changed by ESRI recommendation?

Then you write "A better method is to calculate indexes based on both the feature envelopes and the mean query size" �?? even if we know what a better grid size is (even without si_stats) �?? how can we change the grid size to any specific values after the feature class already exists?

Thanks again
Mody