[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