<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Even,<br>
<br>
On 09/09/15 10:04, Even Rouault wrote:<br>
<span style="white-space: pre;">> 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, <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/pipermail/gdal-dev/2015-September/042512.html">https://lists.osgeo.org/pipermail/gdal-dev/2015-September/042512.html</a>
>
> """
> - a few setters can be added, for example, to set a progress function. Or
> possibly auxiliary objects, like the cutline layer for gdalwarp.
> """</span><br>
<br>
Great!<br>
<br>
<span style="white-space: pre;">>>
>> 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 <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/pipermail/gdal-dev/2015-August/042472.html">https://lists.osgeo.org/pipermail/gdal-dev/2015-August/042472.html</a> )</span><br>
<br>
Ok, if reusing the option structure the client code (or API wrapper)
can keep<br>
track of what has previously been set if it needs to. In terms of
unsetting<br>
options, will passing NULL to the relevant setter do the trick, or
do we need to<br>
re-create the structure in that case?<br>
<br>
<span style="white-space: pre;">>> 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);</span><br>
<br>
Thanks,<br>
<br>
Homme<br>
<br>
<span style="white-space: pre;">> Even
></span><br>
<br>
<br>
</body>
</html>