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

[Dmitriy Baryshnikov]

Hi Even,

I agree with you that this may not be enough for GSoC. OK, let's take 
this into account next time.

Best regards,
     Dmitry

18.02.2015 12:50, 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