+1 to Even's explanation on why this would be a very welcome addition.
We should also add to the requirements a refactoring of the "complex
code" to structure the messages/information that is currently output to
stdout by the command-line utilities so that the calling program can
interpret and present that info to the end user in a meaningful way.
Daniel
On 2015-03-27 4:08 PM, Even Rouault wrote:
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
--
Daniel Morissette
T: +1 418-696-5056 #201
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
