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

[Even Rouault]

> > 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.

If the gdn: mechanism is a new possibility offered that doesn't exclude 
existing ones (otherwise that would be a pretty big breaking change), we could 
possibly exempt the odd cases I mentioned (or have some quoting/escaping rules 
to enable that payload to be seen as a file), which generally don't need a 
"permanent" way of refering to the dataset like gdn: would offer, since this 
is content often generated programatically or retrieved dynamically.

Covering subdataset would be a more important use case. Something that would 
have to be decided if the way we express subdatasets would be somehow 
standardized or if it would be a black-box string for the gdn: encapsulation. 
For a black-box approach, we would have to define some escaping/quoting rules 
to avoid any potential issue with separators of the gdn syntax. If we decide 
that the subdataset syntax is part of what is standardized by GDN that would 
be a more challenging exercice, because the subdataset syntax varies from 
driver to driver.
Depending on how we design things, that might impact between:
- just GDALOpen() generic code if GDALOpen() decodes the gdn: string to 
decompose it into 'classic' dataset names and open options
- all drivers if the gdn: string would be passed to each GDALDriver::pfnOpen() 
implementation
- intermediate situation if we decide to drop (at least for future drivers) 
per-driver subdataset syntax (which has deficiencies has the quoting rules to 
separate the filename from the non-filename component vary from driver to 
driver, and are most of the time not defined) to come up with something more 
standardized

To help brainstorming, a non-exhaustive overview of a few situations mixing 
driver prefixing, subdataset syntax and open options:

gdalinfo my.tif
gdalinfo my.tif -oo GEOREF_SOURCES=WORLDFILE,PAM
gdalinfo GTIFF_DIR:0:d:\my.tif
gdalinfo EEDAI:my/asset
gdalinfo EEDAI: -oo ASSET=my/asset
gdalinfo EEDAI:my/asset:band1, band2
gdalinfo EEDAI: -oo ASSET=my/asset -oo BANDS=band1,band2
gdalinfo BAG:"data/test_vr.bag":supergrid:0:1
gdalinfo data/test_vr.bag -oo MODE=RESAMPLED_GRID -oo SUPERGRIDS_MASK=YES
gdalinfo HDF5:"d:\foo.he5"://HDFEOS/SWATHS/foo/bar
gdalinfo netCDF:"/vsicurl/http://example.com/my.nc":my_var
ogrinfo "PG:dbname=testdb user=foo"
ogrinfo "mySQL:testdb,user=foo"
ogrinfo OCI:warmerda/password at gdal800.dreadfest.com

GDALOpen() is not even aware that HDF5:bla means that the dataset will be 
recognized by the HDF5 driver

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com