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

[Even Rouault]

Robert,

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

Yes the actual design can be solved later.

> 
> 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?),

I've no strong opinion on this. At first sight, this doesn't seem to give 
obvious advantages to the GDAL project itself, but rather constraints.

> and
> creating a FUSE implementation that maps onto the VSI code (ala. mount -t
> vsi /vsizip/vsicurl/http://example.com/foo.zip foo/).

I would be surprised if there aren't already FUSE modules that do http or zip, 
but I haven't checked

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

Hum, that depends on the perseverance of the student to not give up if some 
proprietary software refuse to read its neat generated geodatabase or crashes, 
whereas it can be read with the openfilegdb read side ;-) That said reaching to 
the point where the openfilegdb can read generated files would be a required 
milestone, even if the rest of the adventure is more wild...

> 
> 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").

The idea is interesting and I think many people would welcome such a tool. I'm 
not sure however what is involved to reach the goal. Insert timing 
measurements as you suggest ? But that might not be sufficient to give user 
friendly advice of what to tune and to which values. I'd be afraid this might 
be a difficult subject for a student. That likely involves deep knowledge of 
GDAL internals. But if you have a good feeling on how to accomplish this, why 
not.

> I'm happy to mentor/co-mentor this.

Don't hesitate to write up your ideas on the wiki as time is ticking.

Even

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