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

[Peter Halls]

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?
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



-- 
----------------------------------------------------------------------------------------------------------------
Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit (PRDU)
                     Department of Politics, University of York

Snail mail: PRDU, Derwent College, University of York,
                Heslington, York YO10 5DD
This message has the status of a private and personal communication
----------------------------------------------------------------------------------------------------------------