[gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

[Homme Zwaagstra]

Hi Even,

On 09/09/15 10:04, Even Rouault wrote:
> Hi Homme,  > >>  From my point of view anything that makes the new API feel less 
like a >> wrapper >> around a system call is great: passing expensive 
objects like datasets and >> enabling progress functions is important.  
Hopefully this would also mean >> passing objects as cutline layers for 
gdalwarp and also clipsrc for ogr2ogr >> (including geometry objects for 
the latter?). > > Yes, 
https://lists.osgeo.org/pipermail/gdal-dev/2015-September/042512.html > 
 > """ > - a few setters can be added, for example, to set a progress 
function. Or > possibly auxiliary objects,  like the cutline layer for 
gdalwarp. > """

Great!

>>  >> The idea of an option structure parsed from an array of strings 
sounds >> nice and >> easy to work with.  Is the option structure 
intended to be created for >> each call >> to an utility, or is it 
envisaged it can hang around and be reused (and >> modified)? > > 
Hopefully it should be reusable. It means that we must be careful not to 
 > modify it during a particular execution of the utility. > >> I.e. 
will the API include the ability to retrieve options >> already >> set 
in the option structure, and set specific options? > > I'm not sure 
about getters. The idea would also be to minimize the number of > 
setters to just what is not possible through strings. > The idea being 
that when the utility syntax is extended, for example something > that 
was a particular case is made more generic, we don't necessarily want to 
 > give too much visibility on the field members of the option structure 
(as > raised in 
https://lists.osgeo.org/pipermail/gdal-dev/2015-August/042472.html )

Ok, if reusing the option structure the client code (or API wrapper) can 
keep
track of what has previously been set if it needs to.  In terms of unsetting
options, will passing NULL to the relevant setter do the trick, or do we 
need to
re-create the structure in that case?

>> If so how will  >> options >> that can be set multiple times like `gdal_translate -b` 
be set at the C >> level >> (i.e. what would your python example of 
`options = gdal.TranslateOptions(); >> options.bands = [ 1, 2, 3 ]` look 
like in C)? > > char* argv[] = { "-b", "1", "-b", "2", "-b", "3", NULL 
}; > GDALTranslateOptionsParse* psOptions = GDALTranslateOptionsNew(argv);

Thanks,

Homme

> Even  >


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150909/e9ca582f/attachment.html>