Changes between Version 62 and Version 63 of SummerOfCode

Timestamp:

Feb 17, 2015, 6:00:20 PM (9 years ago)

Author:

Robert Coup

Comment:

--

SummerOfCode

@@ -106 +106 @@
 Possible mentor/co-mentor: Trent Hare (thare at usgs.gov) and Jay Laura (also usgs)
 
+'''4. Tool(s) for performance profiling and option tuning'''
+
+Some [http://trac.osgeo.org/gdal/wiki/ConfigOptions 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`. Creating a structure that future measurements and options can fit into
+in future will be an important design issue, and this project will require digging deep
+into the implementations of various settings & caches used by GDAL.
+
+In terms of reporting possibly something along the lines of MySQLTuner ([https://www.thomas-krenn.com/en/wiki/MySQL_Performance_Tuning example output]). 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`).
+
+Skills:
+  * programming skills needed - C/C++
+  * difficulty level - hard
+
+Possible mentor/co-mentor: Robert Coup (robert.coup at koordinates.com)
+
+'''5. Promoting VSI'''
+
+The virtual filesystem (VSI) functionality in GDAL ([http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip vsizip, vsicurl], [http://erouault.blogspot.co.nz/2012/05/new-gdal-virtual-file-system-to-read.html vsimem, vsisubfile], etc) 
+is pretty cool, and is useful for a lot of things
+outside GDAL. Look 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 possibly
+creating a FUSE implementation that maps onto the VSI code (ala. `mount -t
+vsi /vsizip/vsicurl/http://example.com/foo.zip foo/`).
+
+Skills:
+  * programming skills needed - C/C++
+  * experience with build, test, CI, packaging tools
+  * difficulty level - moderate
+
+Possible mentor/co-mentor: Robert Coup (robert.coup at koordinates.com)
+
+'''6. OpenFileGDB Write support'''
+
+The existing [http://www.gdal.org/drv_openfilegdb.html OpenFileGDB] driver doesn't implement writing, but is more
+stable for reading than the [http://www.gdal.org/drv_filegdb.html proprietary ESRI driver] in most cases.
+
+This project would aim to add some level of write support to the OpenFileGDB
+driver. The primary goal would be so it can create files that the OpenFileGDB 
+driver can read again, and the secondary goal would be to improve compatibility
+so that ArcGIS itself can read the files. 
+As Even describes it, [http://erouault.blogspot.co.nz/2013/10/filegdb-format-reverse-engineered.html reverse engineering] 
+and black box testing isn't always fun, but it is a great skill to have and
+there'd be as much software & support & test data as we can get:
+
+> 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 ;-)
+
+Skills:
+  * programming skills needed - C/C++
+  * some experience with reverse engineering of file formats/protocols
+  * difficulty level - hard
+
+Possible mentor/co-mentor: Robert Coup (robert.coup at koordinates.com)
+
 == 2014 Ideas List ==
 '''1. Automatic Geo-referencer'''[[BR]]