[gdal-dev] Passing open options along dataset name in a string ?

[Sean Gillies]

Even,

On Wed, Nov 4, 2020 at 3:40 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Sean,
>
> What GDN stands for: GDAL Dataset Name ?
>

Yes. I just made that up on the spot. Think of it as a GDAL or FOSS4G
specific namespace. Until now, GDAL has been using symbols like WFS: and
HDF5: in the global namespace, which causes problems for interoperability.


>
> > The URN or GDN version might look something like the thing below, using
> ?+
> > and ?= [3] to identify vsi and driver option sections
> >
> > gdn:curl:csv:
> >
> example.com/foo.csv?a=1&b=2?+max_retry=5?=autodetect_type=yes&keep_geom_colu
> > mns=no
>
> The http or https protocol should be captured too.
>
> > Bringing a little more order to how we name and address datasets was on
> my
> > todo list at the start of the year, but then 2020 went into a spiral. I
> > don't think rasterio's "zip+s3" etc approach is the best.
>
> I see fsspec has a syntax for chaining filesystems in
> https://filesystem-spec.readthedocs.io/en/latest/features.html#url-chaining


Yes, I recognized this as being a different approach to a similar problem
we have in GDAL: data files that can be accessed with different layers of
optional protocols.


>
>
> Another particularity we have in GDAL is that the dataset name might be
> almost
> anything. Most of the time, it is a regular file path, or some /vsi path.
> But
> sometimes, it can be JSON content (the GeoJSON driver accepts the content
> to
> be directly provided as the dataset name), or XML (VRT, WMS drivers).
> We have also the subdataset syntax "HDF5:foo.hdf:my_variable"
>

Could VRT XML and JSON be exempted? We already have a way to embed open
options in the XML.

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201104/25f26c19/attachment-0001.html>