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

[Even Rouault]

Le mercredi 18 février 2015 09:34:51, Dmitriy Baryshnikov a écrit :
> 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.

That could be generallized to any datasource that has read-only and write-only 
capabilities but no real editing capabilities (i.e doesn't support 
SetFeature() and DeleteFeature()). Would likely be done though a coupling 
between the memory datasource and the real driver.

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

Mosts sound like usefull additions but perhaps not be substantial enough taken 
individually.

> I didn't add this to the ideas page as this is the topic for discuss.
> 
> Best regards,
>      Dmitry
> 
> 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,
> > 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 :)
> > 
> > 
> > 
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

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