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 <[email protected]> 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 [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
