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

[Even Rouault]

> 
> In an ideal world, I would prefer a nice clean algorithms library that is
> orthogonal to the command line and parsing. The utilities then simply
> consist of parsing and calling this library. I would also prefer the
> library to be broken down in to a set of orthogonal lower-level primitives
> and the higher-level algorithms built from these.

Well, if I'd classify the content of what is in the apps/ source tree of GDAL, 
I'd say there are :

* Heavy wrappers with lots of options on top of existing API to accomodate for 
various workflows :
- gdal_translate: wrapper of GDALCreateCopy() and the VRT API
- gdalwarp: demo of the C++ warping API
- ogr2ogr: yes admitedly a lot of stuff, that use the OGR API. At the API 
level, there's some "competition" with the CopyLayer() API that lags behind 
all the advanced options of ogr2ogr. I guess defining some pipeline / chaining 
of operations could make sense on the paper, although there's a lot of nasty 
logic to deal with. Some switches have effects both on layer and field creations 
and on each feature.

* Thin wrappers over API :
- gdal_contour: wrapper of GDALCountourGenerate()
- gdaladdo : wrapper of GDALBuildOverviews()
- gdal_rasterize: wrapper of GDALRasterizeGeometries()

* Algorithms implemented in the utilities :
- gdalbuildvrt
- gdaldem
- nearblack
==> would really benefit to be librarified

* In the UNIX pipe philosophy:
- gdallocationinfo
- gdaltransform
==> not sure if they're worth being librarified

* Informational utilities
- gdalinfo ==> makes sense as a library function with the json output
- ogrinfo ==> less obvious. or perhaps just the metadata as json
- gdalsrsinfo / testepsg ==> probably not worth being librarified

I can understand the aim of orthogonal algorithms, etc.. but I'm not 
completely clear on how that would translate in code ;-)

Even

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