gdal icon indicating copy to clipboard operation
gdal copied to clipboard

GTI GeoParquet STAC support with Asset HREFs

Open normanb opened this issue 4 months ago • 3 comments

What is the bug?

When using the GTI driver on a STAC GeoParquet catalog it seems that each of the asset HREFs need to be rewritten to use VSI.

e.g.

gdalinfo -OO LOCATION_FIELD=assets.level3.href GTI:landcover
ERROR 4: s3://dea-public-data/derivative/ga_ls_landcover_class_cyear_3/2-0-0/x52/y46/2020--P1Y/ga_ls_landcover_class_cyear_3_x52y46_2020--P1Y_final_level3.tif: No such file or directory
gdalinfo failed - unable to open 'GTI:landcover'.

I don't have a public URI for the catalog, I created a geoparquet catalog from a static JSON catalog.

Steps to reproduce the issue

I used https://github.com/stac-utils/stac-geoparquet/ to write an existing STAC catalog to a geoparquet catalog.

Versions and provenance

GDAL 3.11.3 "Eganville", released 2025/07/12 Ubuntu 24.04

Additional context

No response

normanb avatar Aug 10 '25 00:08 normanb

A quick work around is to use sed before processing to geoparquet.

sed -i 's/s3:\/\//\/vsis3\//g' */*.json

Then with AWS_NO_SIGN_REQUEST=YES and the command gdalinfo -OO LOCATION_FIELD=assets.level3.href GTI:landcover works.

normanb avatar Aug 10 '25 16:08 normanb

Since 3.12, this fix has broken our (non-stac) GTI indexes, by forcefully rewriting our gs:// uris to /vsigs/... , therefore bypassing our VSI handler that handles gs:// uris. I'm not sure what a good fix/workaround can be:

  • disable this rewriting for non stac GTI indexes
  • adding a global config option to disable this rewriting (i.e. for any driver)
  • disable this re-writing by default, but add an open-option to stac+gti, defaulting to true, to activate this rewriting.

tbonfort avatar Dec 10 '25 15:12 tbonfort

  • disable this rewriting for non stac GTI indexes

Done in https://github.com/OSGeo/gdal/pull/13537

rouault avatar Dec 10 '25 16:12 rouault