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

[Kurt Schwehr]

+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?
- Is it possible to have an optional ptr to an error return?  This would
make thread safety easier.  Or is that *bUsageError?
- 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.
- Can we get away from 0/FALSE and TRUE/1 for bools in in C++.  e.g.
psOptions->bQuiet

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



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150826/3737cb1e/attachment.html>