Hi Even,
On Mon, Nov 2, 2020 at 3:10 AM Even Rouault <even.roua...@spatialys.com>
wrote:
> Hi,
>
> I've heard interest in having the capability of passing a GDAL dataset
> name
> and its open options in a single string, since this is easier for storing.
>
> The syntax could be a JSON serialized string prefixed by GDAL_JSON: to
> avoid
> any ambiguity with drivers that would accept JSON as a connection string/
> dataset name.
>
> So something like:
>
> GDAL_JSON:{"dataset":"foo.csv","open_options":["AUTODETECT_TYPE=YES",
> "KEEP_GEOM_COLUMNS=NO"]}
>
> A "allowed_drivers" member could also be added to reflect the
> corresponding
> argument of GDALOpenEx()
>
> GDALOpen()/GDALOpenEx() would parse this, and process that exactly as if
> it
> was called with the dataset name, open options and allowed drivers put in
> the
> dedicated C arguments. So no change in drivers, just in GDALOpenEx().
>
> If using that syntax, it wouldn't make sense to have both serialized
> options
> and options passed as C-argument together, so a warning would be emitted
> if
> that happened
>
> Thoughts ?
>
> Even
>
We already have a way of passing "open" options for vsicurl:
https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access.
What about reusing that conceptual framework and syntax?
For example:
"foo.csv?AUTODETECT_TYPE=YES&KEEP_GEOM_COLUMNS=NO"
--
Sean Gillies
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
