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

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

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

On 08/09/15 16:28, Even Rouault wrote: 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

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

> In terms of > unsetting options, will passing NULL to the relevant setter do the trick, > or do we need to > re-create the structure in that case? The setters should behave nicely hopefully (ie deallocate any previously allocated/duplicated objected, and assign NULL ). If for some reason that

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

On 09/09/15 10:38, Even Rouault wrote: In terms of unsetting options, will passing NULL to the relevant setter do the trick, or do we need to re-create the structure in that case? The setters should behave nicely hopefully (ie deallocate any previously allocated/duplicated objected, and

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

Hi Even, On 09/09/15 10:04, Even Rouault wrote: 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

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

> > 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",

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

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 =

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

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 =

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

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

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

http://www.keittlab.org/ On Tue, Sep 1, 2015 at 8:34 AM, Even Rouault wrote: > Folks, > > I'd wish we can find a solution that satisfy all parties. Here's another > iteration for a possible proposition. > > * C API: > > Principles : > - dataset objects can be passed

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

Folks, I'd wish we can find a solution that satisfy all parties. Here's another iteration for a possible proposition. * C API: Principles : - dataset objects can be passed - the option structure is opaque (should address Frank's concern about exposing too much internal stuff) - the option

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

> > In an ideal world, I would prefer a nice clean algorithms library that is > orthogonal to the command line and parsing. The utilities then simply > consist of parsing and calling this library. I would also prefer the > library to be broken down in to a set of orthogonal lower-level primitives

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

Oh.. https://en.wikipedia.org/wiki/C_(programming_language)#Keywords - C99 added _Bool. Yuck. I thought that C matched C++ with bool. So never mind this comment on bool. - Can we get away from 0/FALSE and TRUE/1 for bools in in C++. e.g. psOptions-bQuiet The API is intended to be C

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

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 warmer...@pobox.com wrote: I clearly should have been commenting sooner. Several months ago :p I am concerned that having messy structures of options

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

Hi Frank, I clearly should have been commenting sooner. 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

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

Hi Kurt, +1 from a non-voting person. It will definitely make testing a lot cleaner / easier without having to run a separate binary to get most of the testing done. There is also an enormous amount of python code that runs os.system / subprocess. That code is very error prone / a pain to

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

On Wed, Aug 26, 2015 at 1:55 PM, Even Rouault even.roua...@spatialys.com wrote: Le mercredi 26 août 2015 21:44:10, Kyle Shannon a écrit : Hi, On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault even.roua...@spatialys.com wrote: Hi, Summer of code 2015 being finished now, Faza's work now

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

Hi, Summer of code 2015 being finished now, Faza's work now include librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. Faza will continue working on some other utilities. We'd be happy to hear about your comments, especially on the API. So speak now please. The overview of

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

Le mercredi 26 août 2015 21:44:10, Kyle Shannon a écrit : Hi, On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault even.roua...@spatialys.com wrote: Hi, Summer of code 2015 being finished now, Faza's work now include librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. Faza

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

Hi, On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault even.roua...@spatialys.com wrote: Hi, Summer of code 2015 being finished now, Faza's work now include librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. Faza will continue working on some other utilities. Which other

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

Even / Faza, I clearly should have been commenting sooner. 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

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

+1 from a non-voting person. It will definitely make testing a lot cleaner / easier without having to run a separate binary to get most of the testing done. There is also an enormous amount of python code that runs os.system / subprocess. That code is very error prone / a pain to maintain.