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

[Ari Jolma]

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.

Ari

>
>
> Opinions ?
>
> Even
>
>
>> Hi Frank,
>>
>> I was one of the original people who argued against the "array of strings"
>> approach...
>>
>> On 27 August 2015 at 02:26, Frank Warmerdam <warmerdam at pobox.com> wrote:
>>> I clearly should have been commenting sooner.
>> Several months ago :p
>>
>>> I am concerned that having messy structures of options for each
>>> program is going to complicate maintaining the actually commandline
>>> programs, and that it will still be a fragile and complicated point of
>>> entry as commandline arguments evolve over time.
>> The commandline tools eventually become string-parsing and wrapping of the
>> corresponding library tool - I'm not sure that makes it fragile &
>> complicated? Means that the library-ified apps are *at least as*
>> flexible/expressive/powerful
>> as the command-line tools.
>>
>>> I'd prefer if the approach had just been to embed the main()'s in a
>>> library and to still pass the exact same vector of arguments (in the
>>> char **argv format) to these functions instead of shelling out a
>>> program.
>> That kinda defeats the whole point - a huge array of complex string-ified
>> arguments is what we're all doing at the moment, wrapped in an subprocess
>> call. Some options take multiple arguments in multiple strings, others take
>> multiple arguments in single strings, it's massively confusing. And we all
>> have big pipelines of chained gdalwarp/gdal_translate/etc code...
>>
>> What we were striving for was to make it distinctly *better*:
>>
>>     - progress/logging/error handling
>>     - options that accept geometries or SRS or in-memory datasets without
>>     having to re-serialize them and/or utilise tempfiles
>>     - easily applying the same operations over multiple datasets
>>     - configuration option defaults
>>
>>> I would love to be able to replace many places where I shell out to
>>> run gdal command line programs with a library call with essentially
>>> the same arguments.
>> Sure, so it should be straightforward to do that *as well*, though besides
>> in-memory data (as you mention) you're getting very little benefit.
>>
>> Rob :)