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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
