[Gdal-dev] RFC 10: OGR Open Parameters

[Frank Warmerdam]

Andrey Kiselev wrote:
>>  http://www.gdal.org/rfc10_ogropen.html
> 
> Folks,
> 
> What will be the final resolution on above proposal?

Andrey,

I find myself at "-0" on the proposal.  As we discussed in IRC my
main concern is that the approach of an extra options list
substantially complicates opening datasets with required open options
for all the applications.

For instance OpenEV will now need some sort of gui dialogs for open
options.

MapServer has no current mechanism for passing extra open options.  It
is assumed that for OGR datasets the whole dataset name is in the
CONNECTION string.

And this extends to lots of other applications.

Currently we do support creation options when creating files with GDAL
and OGR, but generally these are really optional things and you can produce
a sort of default file without them.  More importantly, I would claim that
the complexity of creation with GDAL and OGR is part of the reason that
there are a lot more applications that can read with GDAL and OGR than there
are applications that can write with them.

On the other hand, the current ad-hoc approach to handling parameters in
the various driver open methods is problematic.  I would like to suggest
that instead we have a "standard" way of packing the filename and open
options into the dataset name, possibly also defining some conventions for
some open options.

For instance we might say that dataset names with embedded options should
always take the form:

OPT:filename[,parm=value]*

And furthermore that normal C quoting and escaping rules be applied as is
done by CPLSEscapeString() with the format type CPLES_BackslashQuotable
described as:

  * CPLES_BackslashQuotable(0): This scheme turns a binary string into
  * a form suitable to be placed within double quotes as a string constant.
  * The backslash, quote, '\0' and newline characters are all escaped in
  * the usual C style.

Actually, as I think about it, we could actually proceed with your
proposal, but extend it to require OGROpen() to know how to "unwrap"
dataset names that appear like the above into a set of name=value pairs
for the options list.  This would give an escape valve for passing
the filename and other open options in applications with no explicit
way of doing this, but it would also allow a fairly clean option list
approach within the drivers, and for application code that can deal
with it easily.

Would you mind if I amended RFC 10 to include this approach?  I'd be
happy to implement the unwrapping aspect.

I'd also suggest then that we should extend this change to GDAL since
similar issues do come up with GDAL drivers.  If this is beyond what
you are prepared to implement for your requirements, I'd be willing to
do the GDAL side.

What do you think?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org