History

Google Summer of Code 2013

List your Google Summer of Code 2013 Ideas Here!

Ideas from previous years are available at corresponding pages:

Use a second level heading for your project idea (see mini-template below).

My Project

Proposed by: Anonymous

  • Create cool stuff
  • Make QGIS better

QGIS for Mobile Phone Devices

Proposed by: Marco Bernasocchi

Last years GSoC for Mobile phone devices (using QML) created the bases for a mobile GUI. This year we should aim at finishing the open work and to improve performance

Main functionality needed:

  • Performance improvements
  • Better Digitizing / Editing
  • Adapt Offline Editing plugin
  • (Use providers to allow wfs, wms, postgis,...)
Further functionality
  • web map caching of osm tiles the way gvsig mobile does
  • syncing of qgis projects from the desktop to the mobile device maybe in a way similar to qgis cloud pushing
  • seamless connection/no connection mode

Repository and tool (plugin) for sharing styles, SVG symbols, SEXTANTE scripts/models, etc.

Proposed by: Alexander Bruy

There is a need for a central repository (at qgis.org) for all users content (styles, Composer models, SVG-symbols, SEXTANTE models, etc) contributed by community that are ready to be used in QGIS. The users should be able to download and upload individual files to appropriate categories or work with some themes (e.g. traffic, geology, etc). The project would consist of three parts:
  1. implement symbol repository in our Django-based web application
  2. Make a REST API to access all elements
  3. create a plugin in Python for seamless download and upload of data (something like Plugin installer)

Some points to consider:

  • standardized metadata for each file, using Dublin Core or something similar. Potentially multilanguage (e.g. titles/keywords)
  • ability to search for keywords and metadata
  • voting system and comments also may be useful

Feature cache support for vector layers (to speedup rendering)

Proposed by: Alexander Bruy

There is a old patch for feature caching developed by Martin Dobias (#3200). Caching allows to speed up the rendering by not fetching the data from slow datasources on every render and store the features for some time in the memory. It would be nice to review it, improve and integrate into QGIS core.

CRS management improvements

Proposed by: Alexander Bruy

Currently QGIS stores CRS in SQLite database. This approach has some limitations and not very user friendly:
  • there is no easy way to rename CRS
  • users can't reorganize CRS in different groups and subgroups
  • custom CRS handling UI needs some updates: CRS can only be seen one by one, saving is quite unintuitive, parameters of an existing CRS cannot be seen easily, etc
Alternate way is to store CRS in WKT format as files and use directories to group them. Something similar already implemented in ArcGIS. Storing CRS as files will allow:
  • organize CRS definitions by user in any preferred way using ordinal file operations (create directory, copy file, rename file...)
  • simplified CRS sharing (just send file with definition or copy its contents)
  • CRS database can be updated independently from QGIS (like tzdata package in most *NIX distributions)

Also some additional features can be implemented like CRS import from *.prj file or from WKT-definition

Centralize plugins repositories

The central plugin repository does not allow for easy collaboration. It would be great if there was a Git repo for each plugin, with the same rights than the QGis repository plus write access for the author.
Right now, it's the responsibility of each developer to maintain his plugin, and a lot of work is lost when a developer stops maintaining his plugin. Also, sometimes you want to contribute to a plugin, but there's no repository, or no maintainer...
Maybe a very flexible system could be setup where tags/branches could directly be used as stable/experimental versions.

SEXTANTE improvements

Proposed by: Victor Olaya

  • Dynamic link between input and output layers: Given an input layer and an output one resulting of applying a SEXTANTE process to it, it woul be interesting to keep track of the relationship between those layers. That would allow to update the output laayer automatically if the input one changes. First we can just store the information, and let the user manually recompute the layer if there have been changes. In a more advanced stage, we could make QGIS detect automatically which output layers are not 'updated' due to changes in input ones, and warn the user about it or even recompute automatically.
  • WPS plugin for SEXTANTE. The idea would be to adapt the current WPS plugin developed by SourcePole to fully integrate it into SEXATNTE, so the definition of new WPS-based processes is done directly in the toolbox.
  • GUI review and improvements. SEXTANTE is great but it needs some polishing: all dialogs should be as small as possible, we should use Qt Designer ui-files where it makes sense, it is necessary to implement full i18n support (make all strings translatable), use icons for algorithms and outputs in modeler, more user-friendly way to reconnect algorithms and outputs in modeler etc.
  • Threading support. Some work was done by Camilo Polymeris last year, but there are many things to do in this direction.
  • Testing. Whatever the final activity, the student should spend a part of the time developing unit tests for SEXTANTE. Not full time, since that is not the ideaa of GSoC, but it should be considered as a complementary task to develop.

Implement Vector editing/geoprocessing tools like the ones in the Mapinfo 'Object' menu

Proposed by: Alister Hood

  • Port the (Python) analysis code of fTools to the (C++) analysis lib, allowing the tools to be used in C++, Python and UI.
  • Implement a gui to use the tools to edit selected features (fTools currently uses whole layers as input, and produces a new layer as output).
    See http://www.mail-archive.com/[email protected]/msg07974.html