<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi all,<br>
<br>
the most of ideas (<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/gdal/wiki/SummerOfCode">http://trac.osgeo.org/gdal/wiki/SummerOfCode</a>)
are marked as moderate/hard.<br>
<br>
There are some simple task as:<br>
1. Editing GeoJSON. By now there is a write support but it's
something special as I cannot edit GeoJSON in QGIS.<br>
2. WMS/TMS. There is no support for subdomains i.e.
<a class="moz-txt-link-freetext" href="http://$">http://$</a>{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.<br>
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.<br>
4. Cmaking the estimate drivers apps and etc.<br>
5. Also addition to #5 in list - new VSI sources (7z, RAR,
ssh/scp/sftp)<br>
<br>
What do you think, can this be the topic for GSoC? <br>
I didn't add this to the ideas page as this is the topic for
discuss. <br>
<pre class="moz-signature" cols="72">Best regards,
Dmitry</pre>
18.02.2015 02:10, Robert Coup пишет:<br>
</div>
<blockquote
cite="mid:CAFLLRpJgS+JiDz5xfC2vTVX6HxkrcRRWe_wcynW=2C9ShzR3CA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
</body>
</html>