[gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

Even Rouault even.rouault at spatialys.com
Thu Aug 27 00:54:09 PDT 2015


Hi Kurt,

> +1 from a non-voting person.  It will definitely make testing a lot cleaner
> / easier without having to run a separate binary to get most of the testing
> done.  There is also an enormous amount of python code that runs os.system
> / subprocess.  That code is very error prone / a pain to maintain.
> 
> General thoughts / questions:  (I only skimmed, so apologies for dumb
> comments)
> 
> - Will this stuff be thread safe?

It should. Normally all static stuff from program code is supposed to have been 
removed

> - Is it possible to have an optional ptr to an error return?  This would
> make thread safety easier.  Or is that *bUsageError?

The functions will emit CPLError(). *bUsageError is a flag mainly to be used by 
the command line utilities to display the usage message in case conflicting 
options have been set.

> - If the argument parsing to options data structure was also a part of the
> library, we could test the arg parsing in C++ without having to shell out
> to a program.

Ah you mean something like :

options = GDALTranslateParseOptions("-outsize 150% 150%");
outDS = GDALTranslate("out.tif", inDS, options)

Hum yes maybe that could ease the conversion, but that would also put in stone 
the current syntax of the utilities at the library level.

> - Can we get away from 0/FALSE and TRUE/1 for bools in in C++.  e.g.
> psOptions->bQuiet

The API is intended to be C callable, so bool isn't possible as a type.

Even

> 
> -kurt
> 
> On Wed, Aug 26, 2015 at 12:56 PM, Kyle Shannon <kyle at pobox.com> wrote:
> > On Wed, Aug 26, 2015 at 1:55 PM, Even Rouault
> > 
> > <even.rouault at spatialys.com> wrote:
> > > Le mercredi 26 août 2015 21:44:10, Kyle Shannon a écrit :
> > >> Hi,
> > >> 
> > >> On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault
> > >> 
> > >> <even.rouault at spatialys.com> wrote:
> > >> > Hi,
> > >> > 
> > >> > Summer of code 2015 being finished now, Faza's work now include
> > >> > librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr.
> > 
> > Faza
> > 
> > >> > will continue working on some other utilities.
> > >> 
> > >> Which other utilities are being considered?  Has there been any
> > >> discussion or thoughts on this?
> > > 
> > > I think we discussed with Faza about pursuing with gdalbuildvrt.
> > > gdaldem
> > 
> > would
> > 
> > > probably be interesting too. Anyone interested can contribute to the
> > 
> > effort.
> > 
> > >> > We'd be happy to hear about your comments, especially on the API. So
> > >> > speak now please.
> > >> 
> > >> The API looks good to me.
> > >> 
> > >> How does documentation work for utilities now?
> > > 
> > > You mean for the binaries ? Well, it is unchanged. Mainly in
> > > gdal_utilities.dox, and for some of them (gdalwarp at least), in the
> > 
> > .cpp.
> > 
> > >> I guess changes should
> > >> be documented in the *_lib.cpp or *_lib.h and also gdal_utilities.dox,
> > >> similar to how the utilities closely coupled with certain alg/ APIs
> > >> (gdalgrid for example).
> > >> 
> > >> > The overview of the work is there:
> > >> > https://trac.osgeo.org/gdal/wiki/rfc59_utilities_as_a_library
> > >> 
> > >> If I am reading correctly, a separate lib will now be created.  Is
> > >> this to keep the building cleaner? Is there a problem with just adding
> > >> it to the libgdal C API?
> > > 
> > > The idea was to be a bit more modular, and avoid growing the core
> > 
> > library.
> > 
> > >> > I'd like to call for a vote soon as I'd want that to be merged as
> > 
> > soon as
> > 
> > >> > possible, so it gets more widely tested and to avoid increasing
> > >> > merge difficulties.
> > >> > 
> > >> > 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
> > >> 
> > >> Thanks.
> > > 
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
> > 
> > Thanks Even...
> > 
> > --
> > Kyle
> > _______________________________________________
> > 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


More information about the gdal-dev mailing list