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

[Newcomb, Doug]

+1

The utilities are used by a lot of folks who cannot have compilers loaded
on their computers for security reasons.

Doug

On Sat, Mar 28, 2015 at 6:06 AM, Damian Dixon <damian.dixon at gmail.com>
wrote:

> 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
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at fws.gov
---------------------------------------------------------------------------------------------------------
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150330/a72c8c07/attachment-0001.html>