> > 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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
