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 <[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 -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
