<div dir="ltr">Hi all,<div><br></div><div>I'm not entirely clear on the signatures of the new functions. Are we considering new functions that would be called with a single string argument like this?</div><div><br></div><div>  ogr2ogr('-of "ESRI Shapefile" example.shp example.json')</div><div><br></div><div>From my perspective this would be sort of a disaster. Instead of using features of our programming languages to handle function arguments (good), we'd be formatting strings (bad). It's much better to have this:</div><div><br></div><div>  ogr2ogr('example.json', 'example.shp', of='ESRI Shapefile')</div><div><br></div><div>Why? Your compiler can then catch trivial errors at compile time if you're using a statically typed language. Your Python linter (for example) can warn you about whether you're calling the function properly or not if you're using a dynamic language. Not to mention that there are many different ways to generate strings in programming languages. Python has some fast ones and some slow ones. I'm concerned that introducing functions with a single string argument, while a shortcut now, increases the number of dumb string munging questions and cost of support over time.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 2:08 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter,<br>
<span class=""><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>
</span>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>
<span class=""><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>
</span>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>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>