[gdal-dev] GSOC 2015 proposal - Integration of cpp GDAL utilities into GDAL core library

[Even Rouault]

Peter,

> Maybe I've missed the point (through over familiarity with GDAL/OGR?)
> .... but these utilities were originally branded as 'worked examples'
> of how to use the substantive libraries to perform well understood
> operations from which usage of the libraries might be readily
> understood.  Each utility is itself a commented set of function calls
> to the relevent GDAL libraries.

There is non trivial logic involved in some of the utilities (e.g. ogr2ogr) 
and people have the choice between :
- doing a system call ("ogr2ogr ...."), but this isn't practical to deal with 
progress report, cancellation, or operating on in-memory datasets
- copy&pasting the source code of the utility in their own code, and 
"librarify'ing" it to remove exit(), etc...
- learning the GDAL/OGR API to do their own custom processing chain. More 
powerfull but longer learning curve

So the interest of the project would be to make life easier for people using 
the first 2 bullets (and I can tell you that there are a lot of people hitting 
those 2 bullets)

> Why is there a need to duplicate this
> in turning the utilities into function calls which then, in turn, must
> be called by new stand-alone utilities?
> There has to be a loss of
> efficiency in sunch a process.

I don't think there will be a loss of efficiency

Instead of ogr2ogr.cpp being currently

int main(...)
{
	complex_code
}

you would have (very schematically)

ogr2ogr.cpp:

int main(...)
{
       ogr2ogr_options = parse aguments()
       return ogr2ogr(ogr2ogr_options)
}

and libgdalutils_ogr2ogr.cpp :

int ogr2ogr(ogr2ogr_options)
{
     complex_code (moved from currently existing main)
}

Even

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