[gdal-dev] Interesting debugging log from FileGBD driver

[Even Rouault]

Hi Andrea,

> I'm looking at a performance issue rendering a very large ESRI File
> geodatabase, and in the logs I see:
> 
> CPLQuadTree: Estimated spatial index tree depth: 20
> CPLQuadTree: Falling back to max number of allowed index tree levels (12).
> 
> Wondering if this might be a reason for slow data extraction, 

I wouldn't think so. The maximum depth of 12 should be large enough.

> and if there
> are settings to make it us the full
> quadtree depth? The environment is also a multi-threaded (multiple threads
> reading from the file at the same time), this could also be a cause.

What is slow exactly ? The first time you do a spatial filtering (which is 
expected, since it requires to do a full scan of the file, because the driver 
doesn't know how to use the on-disk spatial index), or later spatial filtering
operations with the connection still opened (which should be fast normally) ?

> The file in question is massive, so OpenFileGDB does not seem like an option

Yep, still hoping that someone will manage to reverse engineer those last 
missing bits of the format.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com