OpenFileGDB: add support for reading .spx spatial index file #2771
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Credits to QGIS.org Grant program 2020 for sponsoring this work, and to @nyalldawson for his help in the reverse engineering.
Results on a version from of few years ago of the nz-primary-parcels.gdb dataset, featuring 2 484 646 polygons, 773 MB:
"ogrinfo -spat 174.949909 -41.143842 175.684529 -40.594600 -al -so -noextent" (thus counting the number of features intersecting the spatial filter), which returns 81 046 polygons, nows runs in 400 ms with this PR and the OpenFileGDB driver, vs 6.7 s before (full scan), vs 890 ms with the FileGDB driver (with FileGDB SDK 1.5). All figures given with debug builds, and on a hot run (so with most pages cached by the OS). Interactive display of this dataset in QGIS with the OpenFileGDB driver is as fluid as with the FileGDB one. Comparing behaviour of OpenFileGDB and FileGDB drivers with strace shows that they read a similar amount of data in the .spx file.