[Benchmarking] Odd results in qix index comparison

[Adrian Custer]

On Thu, 2010-09-02 at 12:21 -0400, Frank Warmerdam wrote:
> Andrea Aime wrote:
> > Can someone have a look into this? Maybe it's just a problem in
> > the shptreevis conversion utility having troubles with the large
> > qix files (the ones I'm using for GeoServer are significantly smaller)
> > 
> > Cheers
> > Andrea
> > 
> > PS: btw, shptreeview is a quite nice utility, thanks for sharing :-)
> 
> Andrea,
> 
> I have determined this is just a bug in shptreevis when translating a
> .qix file with more nodes in the quadtree than there are shapes being
> indexed.
> 
>    http://trac.osgeo.org/mapserver/changeset/10496
> 
> This does raise the question as to why we are bothering to write out nodes
> with zero shapes instead of pre-pruning them and for that matter why the
> mapserver generated .qix files are produced so deep (16 levels) when the
> 8 levels produced by mapserver are plenty.
> 
> Best regards,

Hey Frank,

good work debugging. 

The observation that the qix were of the wrong size is actually how the
issue was discovered. We looked at the file size and tree depth and made
a back of the envelope calculation that the trees, as generated with the
mapserver generator picking the depth automatically, were much too deep.

For example, in the default set, the qix for the
"point-labels-no-geometry" data set is ridiculously large.

-rwxr-xr-x 1 root   root 172M Aug  2 09:53 point-labels-no-geometry.qix
-rwxr-xr-x 1 root   root  21M Aug  2 09:52 point-labels-no-geometry.shp

It seems that the depth parameter is about 20 in this case and, if I
remember right, 4^20 is big compared to the number of features. So it
sounds like the algorithm to determine depth might need some revision as
well.

all the best,
--adrian