History

Google Summer of Code 2014

List your Google Summer of Code 2014 Ideas Here!

Ideas from previous years are available at corresponding pages:

OSGeo GSoC 2014 Page

Possible [co]mentors, please add yourself to list below and to description on idea you want to mentor:
  • Alexander Bruy
  • Martin Isenburg
  • Paolo Cavallini
  • Martin Dobias
  • Bo Victor Thomsen (but please read the "aber dabei" contained in the proposal)
  • Pirmin Kalberer
  • Luciene Delazari
  • Henrique Firkowski

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

My Project

Proposed by: Anonymous
Possible mentor:

  • Create cool stuff
  • Make QGIS better

OSM download & style

Proposed by: Paolo Cavallini
Possible mentor: Paolo Cavallini

  • Add OSM styling and symbols to QGIS (several styles already available, they must be unified and improved)
  • Make all the process (dowloading and styling) smooth, activated by a single button

See:

Unified address search

Possible mentor: Paolo Cavallini

Several plugins exist for searching addresses. The aim here is to unify them ,and make the plugin modular, so other geolocation engines can be added easily.
See http://lists.osgeo.org/pipermail/qgis-developer/2013-December/029928.html for a discussion.

LiDAR support for QGIS

Proposed by: Alexander Bruy
Possible mentor: Martin Isenburg

Lidar data in LAS format are increasingly widespread. It would be good to have support of this format in QGIS. It can be implemented as separate data provider, for data processing tasks it is better to implement corresponding Processing plugin.

See also discussion in developers list.

Unified topology editing

Proposed by: Alexander Bruy
Possible mentor:

Currently QGIS editing tools have very limited topology support, this leads to some issues with geometry editing. It would be good to have unified topology editing tools and also geometry simplification that preserves topology.

We currently have next digitizers in QGIS:
  • a pseudotopological one, based on rules, that works on most editable vector formats
  • a fully topological one, limited to GRASS.

There is also initial support for PostGIS topology via DB Manager extension.

The idea is to unify all this tools, i.e. digitizing in full topology, then saving in simple feature (shapefile, PostGIS, SpatiaLite etc.) or in topology (GRASS, topological GML) as appropriate. This will eliminate redundancy, provide a more consistent editing environment, improving the quality of digitized data. It should be built as an improvement of the existing pseudotopology digitizer.

See also #3483 and this discussion

Create a unified "Add Data" dialog

Proposed by: Alvaro Huarte
Possible mentor:

Currently the user is confronted with a wide variety of buttons and menus to load a layer. I think the user experience would be better, and interface less cluttered, if only one "Load layer" button was present, then choosing the type (raster/vector, grass/ogr/postgis ecc.) in a dialog.

See this discussion for more details:

Edit Régis Haubourg: also note old discussions and mockups from Nathan : [[http://osgeo-org.1560.x6.nabble.com/Clarifying-access-to-non-geographical-datas-td4986567.html#a4987225]]

It also offers a first step to develop a CAD/GIS converter using a comfortable GUI, an independent application or integrated into QGIS application.

Ideas:

Better MapServer suite integration (style export & more)

Proposed by: Vincent Picavet
Possible mentor:

[Please note: possibly superceded by http://plugins.qgis.org/plugins/rt_mapserver_exporter/]

Mapserver is a great map rendering engine, which has a specific symbology language. The integration between QGIS and MapServer could be greatly improved. The following items are important to have in that sense :

  • Export QGIS project to MapFile with corresponding symbology
  • Live editing of MapFiles inside QGIS with rendered layer in QGIS too
  • Controlling a Mapserver instance from within QGIS
  • Publishing MapServer WMS and TinyOWS WFS services from a QGIS project
Initial work :

This work may imply working on the MapServer Suite project in addition to QGIS

More styling languages

Proposed by: Vincent Picavet
Possible mentor:

Among GIS or cartography tools, various languages coexist to describe the symbology for vector layers. Being able to use these languages inside QGIS would be great.
Among the languages used, implementing the following ones would be of major interest :
  • CartoCSS : used in tilemill, Carto (CartoCSS to Mapnik XML converter)
  • SimpleStyle-spec : used on GitHub for geoJSON rendering
  • MapFile : used in MapServer Suite

QGIS CAD-oriented editing tools unification

Proposed by: Vincent Picavet
Possible mentor:

Nowadays the geometry editing tools in QGIS are mainly GIS oriented. Various projects exist to add to these basic tools a set of geometry editing tools oriented towards CAD, namely CADTools, ImprovedPolygonCapturing, NumericalInput, CADInput, Autotracing...
A unification and integration effort is needed to get all those tools integrated into QGIS core, so as to have a coherent and exhaustive set of CAD-oriented geometry editing tools.

See this discussion for more details :

http://osgeo-org.1560.x6.nabble.com/Cad-Input-for-QGIS-prototype-td5100047.html

QGIS Schematization Plugin

Proposed by:
Possible mentor: Luciene Delazari / Henrique Firkowski

In the current version there are few tools for generalization (Dedicated to line simplification). It would be a great improvement to have some functions to create schematic maps, for example:

  • Simplify lines - input data will typically contain redundant vertices. These are removed by application of a suitable line simplification algorithm (in our case the Douglas-Peucker algorithm). For example building on the QGIS generalize plugin
  • topology - ensures that original map and derived schematic map are topologically consistent i.e yopology of the network is preserved during the schematization process.
  • angular - if possible, edges should lie in horizontal, vertical or diagonal direction.
  • minimum edge length - if possible, all edges should have length greater than some minimum length.

In future, we can add more functionalities by adding constraints on Rotation, Clearance, Displacement etc.

Make QGIS more tablet friendly

Proposed by: Bo Victor Thomsen, bvt (at) aestas (dot) dk
Possible mentor: Bo Victor Thomsen (Needs a co-mentor. I can help with the detailed specification of the project, Python parts and "guinea pig" work, but by my C++ is to rusty). Marco Bernasocchi (available as co-mentor) marco (at) opengis (dot) ch

I know several people (including myself) that uses QGIS on a windows tablet for field surveing work in conjunction with an external GPS.
It works OK, but with some relatively small changes to QGIS you could have a immensely better user experience:

  • Possibility to define larger icons than 36 (pixel/points ?) that is the current limit in "settings-->options" dialog
  • Some corrections to the basic user interface when using large point sizes for menu text
  • A more flexible GPS module.
  • Some example startup.py to define the simplified user interface

I know, that there is some ongoing work to redesign QGIS to a phone friendly interface and I'm aware of Nathan's work with a completely new interface some time ago. But I think we have a 5%-95% situation: 5% work on the existing normal QGIS interface gives us 95% of the desired outcome and can elevate QGIS from "good enough" to "very good" on a tablet.

Add GeoPackage support and make it the default output spatial format across QGIS

Proposed by:
Possible mentor: Larry Shaffer, larrys (at) dakotacarto (dot) com

The newly defined GeoPackage open standard has great potential and QGIS has the opportunity to be at the forefront of its adoption. IMO, it should be used to completely replace all standard outputs that currently dump to shapefile. The shapefile format is antiquated and should only be supported as an import/export format for legacy reasons.

Integration with and implementation in QGIS would include:

  • Create a core provider, similar to spatialite (while GeoPackage could be leveraged through the proposed GDAL support, having it be a first class provider is ideal)
  • Implement standard output-to-GeoPackage routines for C++ and Python usage, so it's easy for anyone to dump a vector layer to the format, regardless of whether in core or in a PyQGIS plugin.
  • Replace all places in current C++ and Python code where shapefiles are the standard output with dumping to memory layers or GeoPackage.
  • Investigate and implement any new features that leverage the GeoPackage format's embedded raster tiles storage.
  • Possibly look into using the format to store all standard aspects of a project, i.e. project file, styles, symbols, rasters and vectors.

Store QGIS symbolization in GeoPackage files

Proposed by: Pirmin Kalberer
Possible mentor: Pirmin Kalberer

Adding symbolization information to GeoPackage files would make exchanging geospatial information (data and maps!) much more convenient.

From Martins All-in-one Projects proposal:
Currently QGIS project files are XML files that contain all the project settings and links to resources: map layers, symbols etc. Often it would be useful to put everything (including data of map layers) into one project file. When copying/moving project files to other people, it is necessary to manually collect all required files and update the project file. This is even more complicated when working with map layers from databases, web services or temporary (in-memory) data.

This GSoC project would add QGIS specific tables with project/style information and needed data like SVG symbols to GeoPackage files. It should be possible to open a QGIS project including data from this file. An OGR driver is already implemented. Reading rasters and tiles from GeoPackage has to be implemented.

Integrate QT Designer into QGIS GUI

Proposed by: Pirmin Kalberer
Possible mentor: Pirmin Kalberer

QT designer is a very powerful tool for creating custom forms for feature data display and entry. Currently QT designer has to be installed and started as an external program. QT Creator, an open source IDE, shows that embedding QT designer is possible. Calling QT designer directly from QGIS would make using QT designer much easier for QGIS users. Creating a default UI for a given layer as starting point for custom forms would also save a lot of work.

Better integration of DB rasters

Proposed by: Pirmin Kalberer
Possible mentor: Pirmin Kalberer / Marco Hugentobler

Raster data stored in DB's like PostGIS or GeoRaster (Oracle) are supported data sources in QGIS based on GDAL drivers. Currently, additional plugins or Python code is needed to add QGIS layers with these raster types. A proper integration in QGIS (Browser, "Add layer"-dialogs, DB Manager and additional Layer properties) whould make it much easier for average QGIS users using DB based rasters.
If time permits, QGIS could be extended with support for "preferred scales". Since raster data (DB-, file based or tile services) loads faster and has no artefacts at their original scale, this would generally improve performance and usage of QGIS with raster data.

Processing framework improving

Proposed by: Alexander Bruy
Possible mentor: Alexander Bruy

Processing framework already integrated into QGIS and provides many algorithms. But there are many issues to solve:
  • threading support. Some work was done some time ago, but implementation was too complex and unstable. We need more robust solution.
  • better handling of outputs. Currently Processing has very limited support for saving files in different formats(there is no way to set additional options like in QGIS "Save as" dialog, saving in formats other than shapefile is a bit tricky, etc)
  • GUI review and improvements. Processing still needs some polishing: all dialogs should be as small as possible, we should use Qt Designer ui files where possible, it is necessary to implement full i18n support (make all strings translatable). Another topic is icons for algorithms and outputs in modeler, more user-friendly way to reconnect algorithms and outputs in modeler etc.
  • testing framework. As Processing is complex and contains many algorithms it is important to develop testing infrastructure to allow developers quickly find bugs and broken functionality.

Feature-based Map Algebra for PostGIS and QGIS

Proposed by: Xingong Li
Possible mentor: Xingong Li

Map algebra (or cartographic modeling) operations provide powerful tools for analyzing and manipulating geographic data in the raster data model both in commercial and open source GIS software. This project, which is based on the research by French and Li, will extend these operations to the vector data model and make them available in PostGIS and QGIS. It will be implemented primarily using the Python programming language.