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

[Damian Dixon]

There are a lot of GIS specialists and geographers who are not programmers
that use the tools to convert or query gis data before using within a
commercial gis tool.

I believe that there is merit in providing a higher level api.

Just my two pennies worth... as a programmer... working for a GIS company.

Regards
Damian
On 28 Mar 2015 09:47, "Peter Halls" <p.halls at york.ac.uk> wrote:

> 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
>
> ----------------------------------------------------------------------------------------------------------------
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150328/94a889a8/attachment-0001.html>