<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
On 08/09/15 16:28, Even Rouault wrote:<br>
<span style="white-space: pre;">>>> For example, let's say the user calls gdal.Translate("format" => "GTiff",
>>> "src_win" => [100,400,50,50] ) (this is probably not valid Perl syntax,
>>> but hope you got it !), and you would call GDALTranslateOptionsNew(list)
>>> where you would build list = { "-format", "GTiff", "-src_win", "100",
>>> "400", "50", "50", NULL }
>>
>> Geo::GDAL->Translate("format" => "GTiff", "src_win" => [100,400,50,50] )
>>
>> would be valid. The argument system sounds reasonable. However, why not
>>
>> $dst_dataset = $src_dataset->Translate("format" => "GTiff", "src_win" =>
>> [100,400,50,50] )
>>
>> i.e., apply the method on an object and get an object, as the command
>> line utility conceptually does? Also, the command line uses "-of", which
>> the method could also accept - the method could perhaps accept a longer
>> version "--output_format" too. I'm just wondering,
>
> Well, I'd say that can be a per-binding choice (and that depends on utilities.
> For example gdalwarp can accept several input datasets). My fundamental question was if my
> proposal <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>
> was OK at the C API level so as to be able to build upon it.</span><br>
<br>
From my point of view anything that makes the new API feel less like
a wrapper<br>
around a system call is great: passing expensive objects like
datasets and<br>
enabling progress functions is important. Hopefully this would also
mean<br>
passing objects as cutline layers for gdalwarp and also clipsrc for
ogr2ogr<br>
(including geometry objects for the latter?).<br>
<br>
The idea of an option structure parsed from an array of strings
sounds nice and<br>
easy to work with. Is the option structure intended to be created
for each call<br>
to an utility, or is it envisaged it can hang around and be reused
(and<br>
modified)? I.e. will the API include the ability to retrieve
options already<br>
set in the option structure, and set specific options? If so how
will options<br>
that can be set multiple times like `gdal_translate -b` be set at
the C level<br>
(i.e. what would your python example of `options =
gdal.TranslateOptions();<br>
options.bands = [ 1, 2, 3 ]` look like in C)?<br>
<br>
Hopefully not too many questions!<br>
<br>
Best regards,<br>
<br>
Homme<br>
<br>
</body>
</html>