Hi Even,
On Wed, 10 Oct 2018 at 15:42, Even Rouault <even.roua...@spatialys.com>
wrote:
> > eg. gdal.Open("/vsis3?ext=.tif/mybucket/mypath/my.tif", ...)
>
> Hum, we should treat the path to the object as a real URL argument then,
> so something like
>
> /vsis3?ext=.tif&object=mybucket/path/to/my.tif
>
If we're splitting it out, should bucket and the object key (S3 uses the
term "key" in it's documentation) be separate parameters?
ie.
/vsis3?bucket=mybucket&key=path/to/my.tif&ext=.tif
/vsis3?bucket=mybucket&key=path/to/my.tif&ext=.tif&ext=.tif.aux.xml
/vsis3?bucket=mybucket&key=path/to/my.tif&ext
> with the path value being URL-encoded if needed (like the similar syntax
> added in 2.3 for /vsicurl/:
>
> https://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsicurl
> )
>
>
Sure.
Are there other options that would be useful per-dataset?
GDAL_READDIR_ON_OPEN is exposed as ?list_dir=yes|no for vsicurl, maybe that
should be added here too?
> >
> > Another alternative would be to have it as an Open Option to pass to
> > gdal.OpenEx(), though they seem designed for driver-specific options
> rather
> > than access-method.
>
> That one would be nice, but tricky. Basically, the config option must be
> set at the time a
> Open() or Stat() action is done, but GDALOpen() has no control on when the
> driver will
> performs such actions. One could presume they will be done by the open
> code of the driver, but
> who knows if a driver might not do deferred access, after the Open()
> method has been
> completed.
Makes sense.
Cheers,
Rob :)
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
