<p dir="ltr">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.</p>
<p dir="ltr">I believe that there is merit in providing a higher level api.</p>
<p dir="ltr">Just my two pennies worth... as a programmer... working for a GIS company.</p>
<p dir="ltr">Regards<br>
Damian</p>
<div class="gmail_quote">On 28 Mar 2015 09:47, "Peter Halls" <<a href="mailto:p.halls@york.ac.uk">p.halls@york.ac.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Even and Daniel. I see the logic behind the arguments.<br>
<br>
The stand-alone utilities are probably the most heavility used<br>
GDAL/OGR code. Once these have been subsumed into internal function<br>
calls, do we continue to provides the stand-alone utilities?<br>
Programming seems to be a cyclic requirement: 5-10 years ago the<br>
clamour was solely for press and go stand-alone utilities; today there<br>
are possibly more programmers - or, at least, the programmers have<br>
become more vocal. I've seen several such cycles over my career.<br>
<br>
I am not saying that the proposal is a bad idea, rather I am seeking<br>
to test the proposal such that we continue to commit our scarce<br>
resources where there is greatest benefit.<br>
<br>
<br>
Best wishes,<br>
<br>
Peter<br>
<br>
<br>
On 27 March 2015 at 20:08, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>
> Peter,<br>
><br>
>> Maybe I've missed the point (through over familiarity with GDAL/OGR?)<br>
>> .... but these utilities were originally branded as 'worked examples'<br>
>> of how to use the substantive libraries to perform well understood<br>
>> operations from which usage of the libraries might be readily<br>
>> understood. Each utility is itself a commented set of function calls<br>
>> to the relevent GDAL libraries.<br>
><br>
> There is non trivial logic involved in some of the utilities (e.g. ogr2ogr)<br>
> and people have the choice between :<br>
> - doing a system call ("ogr2ogr ...."), but this isn't practical to deal with<br>
> progress report, cancellation, or operating on in-memory datasets<br>
> - copy&pasting the source code of the utility in their own code, and<br>
> "librarify'ing" it to remove exit(), etc...<br>
> - learning the GDAL/OGR API to do their own custom processing chain. More<br>
> powerfull but longer learning curve<br>
><br>
> So the interest of the project would be to make life easier for people using<br>
> the first 2 bullets (and I can tell you that there are a lot of people hitting<br>
> those 2 bullets)<br>
><br>
>> Why is there a need to duplicate this<br>
>> in turning the utilities into function calls which then, in turn, must<br>
>> be called by new stand-alone utilities?<br>
>> There has to be a loss of<br>
>> efficiency in sunch a process.<br>
><br>
> I don't think there will be a loss of efficiency<br>
><br>
> Instead of ogr2ogr.cpp being currently<br>
><br>
> int main(...)<br>
> {<br>
> complex_code<br>
> }<br>
><br>
> you would have (very schematically)<br>
><br>
> ogr2ogr.cpp:<br>
><br>
> int main(...)<br>
> {<br>
> ogr2ogr_options = parse aguments()<br>
> return ogr2ogr(ogr2ogr_options)<br>
> }<br>
><br>
> and libgdalutils_ogr2ogr.cpp :<br>
><br>
> int ogr2ogr(ogr2ogr_options)<br>
> {<br>
> complex_code (moved from currently existing main)<br>
> }<br>
><br>
> Even<br>
><br>
> --<br>
> Spatialys - Geospatial professional services<br>
> <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
<br>
<br>
<br>
--<br>
----------------------------------------------------------------------------------------------------------------<br>
Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit (PRDU)<br>
Department of Politics, University of York<br>
<br>
Snail mail: PRDU, Derwent College, University of York,<br>
Heslington, York YO10 5DD<br>
This message has the status of a private and personal communication<br>
----------------------------------------------------------------------------------------------------------------<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>