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

Dmitriy Baryshnikov bishop.dev at gmail.com
Wed Feb 18 00:34:51 PST 2015

Hi all,

the most of ideas (http://trac.osgeo.org/gdal/wiki/SummerOfCode) are 
marked as moderate/hard.

There are some simple task as:
1. Editing GeoJSON. By now there is a write support but it's something 
special as I cannot edit GeoJSON in QGIS.
2. WMS/TMS. There is no support for subdomains i.e. 
http://${a,b,c}.tile.openstreetmap.org/${z}/${x}/${y}.png. Also it'll be 
nice to have progress indication and support to cancel executing RasterIO.
3. Editing GPX - by now the driver support only write to new file and if 
one open points (trk_pnt) the output will be waypoints (wpt). The 
usecase is to get GPX from GPS tracker, fix the track and upload back to 
GPS tracker.
4. Cmaking the estimate drivers apps and etc.
5. Also addition to #5 in list - new VSI sources (7z, RAR, ssh/scp/sftp)

What do you think, can this be the topic for GSoC?
I didn't add this to the ideas page as this is the topic for discuss.

Best regards,

18.02.2015 02:10, 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, 
> memory/threading/options, and possibly per-format options -- for GTiff 
> things like tiling, interleaving, overviews, GTIFF_VIRTUAL_MEM_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 :)
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150218/1c8e740c/attachment-0001.html>

More information about the gdal-dev mailing list