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

[Even Rouault]

Le mercredi 01 avril 2015 17:24:47, Sean Gillies a écrit :
> 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.

Sean,

The latest orientation while discuting with Robert & Faza would drop the 
single string approach in favor of function arguments, with a minimal list of 
arguments for the required arguments, and put the others in a dedicated option 
structure.

See:
https://github.com/fazam/gdal/commit/a0979a621b0041d25a9d628430b5f1dd2c967fb5#commitcomment-10173885

Even

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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com