<div dir="ltr">Hi Even,<div><br></div><div>A few comments/ideas:</div><div><br></div><div>1. Integration of cpp GDAL utilities into GDAL core library<br></div><div><br></div><div>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 <i>simpler</i> 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.</div><div><br></div><div>2. Promoting VSI</div><div><br></div><div>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/<a href="http://example.com/foo.zip">http://example.com/foo.zip</a> foo/). I'm happy to mentor/co-mentor this.</div><div><br></div><div>3. OpenFileGDB Write support</div><div><br></div><div>You have a better idea how much work this is, and whether it'd be suitable for a student to attempt?</div><div><br></div><div>4. Tool(s) for performance profiling and option tuning</div><div><br></div><div>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.</div><div><br></div><div>In terms of reporting I'm thinking something along the lines of MySQLTuner - see example output at <a href="https://www.thomas-krenn.com/en/wiki/MySQL_Performance_Tuning">https://www.thomas-krenn.com/en/wiki/MySQL_Performance_Tuning</a>. 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.</div><div><br></div><div>Rob :)</div><div><br></div><div class="gmail_extra"><div class="gmail_signature"></div>
</div></div>