[gdal-dev] ogrtindex, gdaltindex feature request

[Scott]

The whole, new GTI format got by me until Michael Sumner mentioned it on 
slack, which I visit extremely rarely. (Thanks Michael). I've been doing 
it in an entirely different way. The feature request is based on that.

The feature request is this:

    gdaltindex -co GDALINFO=mymeta catalog.fgb *.tif
or
    ogrtindex -co OGRINFO=mymeta catalog.fgb *.shp

This says, create an attribute in the .fgb file called 'mymeta' and 
populate it with the equivalent of 'ogrinfo -json' or 'gdalinfo -json'. 
Or perhaps:

    gdaltindex -co GDALSTATS=mymeta catalog.fgb *.tif

Which is equivalent to 'gdalinfo -json -stats -hist'

I've been doing this as a 2 step process, but it would be really cool to 
have it all integrated. I have many raster/vector files of different 
formats in a single catalog.gpkg and catalog.fgb. I can easily filter 
any by bbox, type or stats.

Why?

If you're grabbing your data from an .fgb file on S3/web server without 
an intermediate server or service, using a bbox, it's painless to get 
exactly the data you need. Further, you have access to all the 
attributes, stats, min, max, stddev for filtering *before* you request 
the actual data.

If you don't like cloud native or .fgb and want to access your data via 
an API, create your catalog as a .gpkg. Create custom attributes for 
filtering and indexes on those attributes, json meta data, etc, and 
throw it behind an API.

With a catalog.gpkg you can have all your rasters/vectors in the same 
catalog.gpkg and ogr2ogr to an .fgb. Anytime you update/upsert your 
.gpkg, recreate the .fgb.

As awesome as STAC is, it's becoming increasingly complex and very slow 
with large data sets. Compare that to an -sql query on a single 
catalog.gpkg (particularly with spatialite).

If you've made it this far, thanks for listening!

Scott

-- 
www.postholer.com