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

[Sean Gillies]

Hi all,

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?

  ogr2ogr('-of "ESRI Shapefile" example.shp example.json')

>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:

  ogr2ogr('example.json', 'example.shp', of='ESRI Shapefile')

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.


On Fri, Mar 27, 2015 at 2:08 PM, 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150401/c20ac291/attachment.html>