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

[Even Rouault]

Le samedi 28 mars 2015 10:47:32, Peter Halls a écrit :
> Thanks, Even and Daniel.  I see the logic behind the arguments.
> 
> The stand-alone utilities are probably the most heavility used
> GDAL/OGR code.  Once these have been subsumed into internal function
> calls, do we continue to provides the stand-alone utilities?

Yes, of course, this was actually implied by my pseudo code ;-)

> Programming seems to be a cyclic requirement: 5-10 years ago the
> clamour was solely for press and go stand-alone utilities; today there
> are possibly more programmers - or, at least, the programmers have
> become more vocal.  I've seen several such cycles over my career.
> 
> I am not saying that the proposal is a bad idea, rather I am seeking
> to test the proposal such that we continue to commit our scarce
> resources where there is greatest benefit.
> 
> 
> Best wishes,
> 
> Peter
> 
> On 27 March 2015 at 20:08, Even Rouault <even.rouault at spatialys.com> 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
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

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