<div dir="ltr"><div>+1</div><div><br></div>The utilities are used by a lot of folks who cannot have compilers loaded on their computers for security reasons.<div><br></div><div>Doug</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 28, 2015 at 6:06 AM, Damian Dixon <span dir="ltr"><<a href="mailto:damian.dixon@gmail.com" target="_blank">damian.dixon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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<span class="HOEnZb"><font color="#888888"><br>
Damian</font></span></p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 28 Mar 2015 09:47, "Peter Halls" <<a href="mailto:p.halls@york.ac.uk" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div><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><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Doug Newcomb</div><div>USFWS</div><div>Raleigh, NC</div><div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div><div>---------------------------------------------------------------------------------------------------------</div><div>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.</div></div>
</div>