[gdal-dev] Formalizing GDAL "file name" syntax in an RFC?

[Even Rouault]

Sean,

It is far from obvious to me to find a universal pattern that would fit 
existing and future use cases. If we would find a universal syntax, 
there would be the problem of deciding what to do with code that doesn't 
match it: support only new way (breaking external code),  or supporting 
both old and new ways (additional complexity in our code base)

How would we deal with the existing practices which are very diverse ? 
Examples:

- True filenames (most of the drivers)

- Database based drivers:

PG:"dbname='databasename' host='addr' port='5432' user='x' password='y'" 
(Postgis vector) PG:"[host=''] [port=''] [dbname='' [user=''] 
[password=''] [schema=''] [table=''] [column=''] [where=''] [mode=''] 
[outdb_resolution='']" (Postgis raster, consistent with previous one) 
MYSQL:dbname,user="userid",password="password",host=x,port=y 
OCI:username/password at host_name:port_number/service_name:MY_SCHEMA.MY_VIEW georaster:<user>{,/}<pwd>{,@}[db],[schema.][table],[column],[where]
georaster:<user>{,/}<pwd>{,@}[db],<rdt>,<rid>

- Web services (some of them also accept plain filenames that are .xml 
files describing the service and parameters)

WMS:http://demo.opengeo.org/geoserver/gwc/service/wms?SERVICE=WMS&VERSION=1.1.1&
                             REQUEST=GetMap&LAYERS=og%3Abugsites&SRS=EPSG:900913&
                             BBOX=-1.15841845090625E7,5479006.186718751,-1.1505912992109375E7,5557277.703671876&
                             FORMAT=image/png&TILESIZE=256&OVERVIEWCOUNT=25&MINRESOLUTION=0.0046653459640220&TILED=true" 
(note the mix of pure WMS GetMap request query parameters + GDAL 
specific properties TILESIZE, OVERVIEWCOUNT, MINRESOLUTION)

WCS:http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?VERSION=1.1.0&coverage=BGS_EMODNET_CentralMed-MCol
WFS:http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap OAPIF:https://www.ldproxy.nrw.de/rest/services/kataster
WMTS:http://maps.wien.gv.at/wmts/1.0.0/WMTSCapabilities.xml,layer=lb
( layer= is GDAL specific)


- Raster subdatasets (whether to surround filename with double quotes is 
driver specific)

NITF_IM:{image_number}:{filename}
NITF_TOC_ENTRY:{product_type}_{chartname}_{scale}_{somenumber}_{anothernumber}:GNCJNCN/rpf/a.toc
ECRG_TOC_ENTRY:{product_name}:{disk_name}:{scale}:{filename}
GTIFF:{directory_number}:{filename}
GTIFF:off:{directory_offset}:{filename}
GPKG:{filename}:{tablename}
netCDF:{filename}:{variable_name}
HDF5:{filename}:{dataset_path}
ZARR:{filename}  (mostly when filename is /vsicurl/ and we don't have a 
ReadDirectory() API)
ZARR:{filename}:{path_to_array}
ZARR:{filename}:{path_to_array}:{third_dim_index}[:{fourth_dim_index}[:{fifth_dim_index}...]]

- Other syntax

vrt:// connection string 
(https://gdal.org/drivers/raster/vrt.html#vrt-connection-string) . e.g.  
vrt://my.tif?bands=3,2,1

Do you have also /vsi syntax in mind ?

Even

Le 14/09/2023 à 17:14, Sean Gillies a écrit :
> Hi all,
>
> In https://github.com/OSGeo/gdal/pull/8155#issuecomment-1704923263 I 
> think I see (for the first time?) the beginning of a specification of 
> the syntax for GDAL "file names". I think it would be helpful if there 
> was an RFC for this.
>
> I'm sure a lot of applications construct GDAL file names without much 
> understanding of what's correct or incorrect. A formal spec could help 
> make it more likely that anyone can construct a valid filename on the 
> first try.
>
> A stretch goal for the RFC could be to come up with a syntax that is 
> sufficiently general that authors of new format drivers don't have to 
> create their own new idiosyncratic file names.
>
> -- 
> Sean Gillies
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230914/fcdfc63b/attachment-0001.htm>