[gdal-dev] Fwd: [SoC] Preparation of ideas pages for GSoC 2015 (deadline: 18th February!)

[Robert Coup]

Hi Even,

A few comments/ideas:

1. Integration of cpp GDAL utilities into GDAL core library

I like the idea, but I'd be tempted to take the approach of eg.
GDALUtilTranslate(...) taking arguments (structs/params/whatever) that
correspond to each command line argument. I don't think it needs
capabilities like path/wildcard/argument interpolation, it'll be called
from code and the calling code is perfectly capable of listing files
properly -- this avoids weird string escaping and all sorts of other
complexity, and makes it *simpler* to use from other code and easier for
language bindings. That approach would mean the utility apps themselves
parse arguments and then call the GDALUtilX() functions and report progress
& results, rather than doing absolutely nothing. But this is all a design
decision for the student I guess. I'd be happy to co-mentor.

2. Promoting VSI

The VSI code is pretty cool, and is actually useful for a lot of things
outside GDAL. I'm suggesting looking at whether an external project could
be a better place for it to live (even if it's just a separate
build/packaging from code that continues to live in GDAL) -- adding tests &
CI, looking at cross-platform issues, documenting vsi_preload.so, making a
library other apps could utilise for the functionality (libvsi?), and
creating a FUSE implementation that maps onto the VSI code (ala. mount -t
vsi /vsizip/vsicurl/http://example.com/foo.zip foo/). I'm happy to
mentor/co-mentor this.

3. OpenFileGDB Write support

You have a better idea how much work this is, and whether it'd be suitable
for a student to attempt?

4. Tool(s) for performance profiling and option tuning

Some GDAL options can have enormous effects on the performance of some
operations, depending on dataset size/complexity/source and all sorts of
other factors. I'm imagining a tuning tool that looks at which
caches/limits are being "hit" (or not) during an operation (eg. a specific
gdalwarp), where time is being spent (IO, CPU, ...) and suggest better
settings for your datasets & host configuration. Maybe this could be
expanded in future to select better "defaults" automatically. I'm thinking
settings like: GDAL_MAX_DATASET_POOL_SIZE, GDAL_CACHEMAX, GDAL_SWATH_SIZE,
VSI_CACHE, GDAL_DISABLE_READDIR_ON_OPEN, OSM_MAX_TMPFILE_SIZE, warp
memory/threading/options, and possibly per-format options -- for GTiff
things like tiling, interleaving, overviews, GTIFF_VIRTUAL_MEM_IO,
GTIFF_DIRECT_IO.

In terms of reporting I'm thinking something along the lines of MySQLTuner
- see example output at
https://www.thomas-krenn.com/en/wiki/MySQL_Performance_Tuning. Maybe
invocation like "gdalwarp --tune ..." but would also be good if usage via
library/bindings could be profiled in the same way and the output dumped
somewhere for later analysis/reporting (eg. "gdaltune my_warp.gdaltune").
I'm happy to mentor/co-mentor this.

Rob :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150218/95ac8b24/attachment.html>