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

[Even Rouault]

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 arguments evolve over time.

Is your concern that adding a new switch could cause some members of the 
option structure to be removed ?

> 
> 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 was one of the initial idea, but I remember a few people pointed that 
they would prefer an approach with explicit options over the string approach. 
Also, if done strictly like that and also embedding dataset names, we would 
loose the possibility of working with GDAL MEM & OGR Memory datasets for 
example.

One another advantage of the approach of Faza's work is that if you want to 
set a spatial filter (for ogr2ogr) and have already a OGRGeometryH, you can 
assign it to the OGR2OGROptions structure (making it then more powerful than 
currently where you can only pass a rectangle. Althoug we could also make the 
-spat switch to recognize a WKT geometry)

The option structure also contain (at least that's the plan) progress 
functions for progress report / cancellation.

Would the addition of what I mentionned in my previous answer to Kurt, ie a 
function to fill the option structure from the option part of the string 
(excluding dataset names) would be a possible compromise ?

So, they are several possible approaches:

1)

char* args[] = {"-outsize", "150%", "150%", NULL }
options = GDALTranslateOptionsParse(argv);
( and possibly also with a helper to split a single string :
papszArgv = CSLFromCommandLine("-outsize 150% 150%");
options = GDALTranslateOptionsParse(papszArgv);
)

GDALTranslateOptionsSetProgress(options, pfnProgress, pProgressData);
or
options->pfnProgress = pfnProgress;
options->pProgressData = pProgressData;

outDS = GDALTranslate("out.tif", inDS, options)

The question would be if we expose the content of the options structure to 
client code or not.

2) If not, we could as well do:

outDS = GDALTranslate("out.tif", inDS, papszArgv, pfnProgress, pProgressData);

3) and if we drop the possibility of working with GDAL MEM & OGR Memory 
drivers,

error_code = GDALTranslate(papszArgv, pfnProgress, pProgressData);

There's the special case of GDALInfo() where returning a string, especially in 
JSon format, rather than outputing on stdout, is definitely an advantage, so we 
might still want to have ret_string = GDALInfo(papszArgv)

> 
> I'd also have (as usual) preferred this to be embedded in libgdal.so
> so there weren't additional library layers to keep track of.  We are
> clearly a "kitchen sink" style library - lets own that. :-)

OK, I've not a strong opinion on that. That'd be easy to go back on the single 
library approach.

> 
> 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.
> 
> PS. One benefit of built-in "programs" is that I can do things like
> invoke gdal_translate on an in memory data by using the right name for
> it since it is in the same process space.

Ah you mean /vsimem/ datasets. Yes they would work with the "string approach". 
Above, when I mentionned in-memory datasets, I thought to datasets of the GDAL 
MEM & OGR Memory drivers that you can only create but not open with a name.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com