Craig, > True, but that does eliminate ambiguity in the URL, and does so in a > well-known way. > > Does the current scheme use any encoding?
No > How would you escape text in > option values that might use `=` and `,` etc? Or are there guaranteed to be > no freeform-text options in these paths? Currently, given the supported set of options and values, yes. In case of future ambiguity, yes, we'd need to define some escaping rules. > > > > Tangential, but related: I've also just discovered the 2.2+ curly-brace > syntax for vsizip/vsitar paths, which allows nested archives: That's a side effect. The main motivation was that there are .tar or .zip files in the wild that for good or wrong reasons have non standard extensions. > > /vsizip/{/vsizip/{/path/to/outer.zip}/path/to/inner.zip}/file.shp > > > The curly braces are a definite improvement on the ambiguous older syntax > for these paths. However, we noted the nesting order looks inside-out, and > thought it would have been more intuitive to put the path *inside* the > > archive in the braces. i.e. nesting would look like: > > /vsizip//path/to/outer.zip/{/vsizip//path/to/inner.zip/{file.shp}} Hum, that doesn't seem really better to me, and I can't see how that could be implemented. / vsizip//path/to/inner.zip/{file.shp} couldn't be succesfully resolved by the vsizip VFS since / path/to/inner.zip isn't a regular file itself. /vsizip/{/vsizip/{/path/to/outer.zip}/path/to/inner.zip}/file.shp is really closer how it works internally, and is close to function-like syntax f(g(h(x))) where you start evaluating the most internal member. So you have /vsizip/{something}/file.shp, which means we'll expose a file handle, for a file.shp in a zip archive accessed through "something" "something" happens to expand to /vsizip/{/path/to/outer.zip}/path/to/inner.zip which means we will return a file (that happens to be itself a zip, but at that stage, only /vsizip/ {something}/file.shp cares that is a zip), that is in a zip file /path/to/outer.zip, which happens to be a regular file. > > Of course, this latter syntax was added in 2.2, so perhaps that ship has > already sailed. Yes Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev