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