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

[Ari Jolma]

On 07.09.2015 21:54, Even Rouault wrote:
> Le mardi 01 septembre 2015 23:00:37, Ari Jolma a écrit :
>> On 01.09.2015 16:34, Even Rouault wrote:
>>> 2)  Variant of 1). With some Python magic on **kwargs it can be automated
>>> to redirect on 1) mem_ds = gdal.Translate('', src_ds, bands = [1,2,3],
>>> format = 'MEM', progress = my_progress_method)
>>>
>>>
>>> * Other binding languages.
>>>
>>>
>>> - Perl: apparently possible
>> Yes it is. Being a non-typed high level language it is possible and IMO
>> preferable to be able to give the options in a key-value list (hash)
>> where the keys are well known strings and the values are understandable.
>> However, the C API need not do this but it should allow it.
> Would the approach I suggested for the Python bindings, i.e you would build a
> list of options with the current syntax of the utilities from the Perl key-
> value list sound reasonable ?
>
> 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, I've not read the RFC 
nor this thread with much attention.

Regards,

Ari