Update... It looks like there are at least two different kinds of logic around sidecar/sibling files.
My Rasterio VSI plugin currently implements only open, tell, seek, read, write, and close. The mandatory methods. I can see GDAL probing for .aux and .AUX files. But not .aux.xml files for some reason that I don't understand. The dataset I'm exposing through this VSI plugin has a .ovr file, but there's no attempt to find it. It looks like .aux.xml and .ovr require VSI sibling files and/or readdir support, but that .aux file support does not? I'm deducing this from the behavior of the system. It would be hard to figure it out just by reading the code. On Fri, Feb 16, 2024 at 8:29 AM Sean Gillies <sean.gill...@gmail.com> wrote: > Thanks for the tip, Thomas! > > On Thu, Feb 15, 2024 at 9:45 AM thomas bonfort <thomas.bonf...@gmail.com> > wrote: > >> Hi Sean, >> I believe/recall this is very driver dependent. Some drivers will look >> for their sidecars in the provided sibling files list returned by >> VSISiblingFiles, whereas others will unconditionally try to open well-known >> sidecar names they will have computed from their own name. IIRC I added >> VSISiblingFiles so that some vsi backends (namely object storage based >> ones) could explicitly return an empty list of sibling files in order to >> prevent drivers to emit a subsequent Readdir() (which might break drivers >> that require sidecar files to work, but speeds up those where sidecar files >> are optional and not used in a cloud-storage environment (namely cogs) ) >> >> On Tue, Feb 13, 2024 at 6:12 PM Sean Gillies via gdal-dev < >> gdal-dev@lists.osgeo.org> wrote: >> >>> Hi all, >>> >>> It's not clear to me from reading >>> https://gdal.org/user/virtual_file_systems.html if VSI sidecar and >>> sibling file lookup works in general, by design, or whether it's an >>> implementation detail of the standard VSI filesystems ("vsizip", "vsicurl", >>> etc.). >>> >>> More specifically: if I have a "/vsipyopener/foo.tif" object, do drivers >>> always look for other files at paths precisely relative to that one? Does >>> this vary among drivers? >>> >> > > -- > Sean Gillies > -- Sean Gillies
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
