Google Summer of Code/2017/Project Ideas

From OpenStreetMap Wiki
Jump to: navigation, search

This page lists a number of ideas for potential Google Summer of Code 2017 projects. For ideas from previous years see Category:Google Summer of Code ideas. Also check out Research/Ideas (project ideas related to research or academia), Top Ten Tasks (the main issues OSM developers are concerning themselves with), and existing bugs for more problems to solve.

This page's primary purpose is to help to give potential applicants ideas that they can build on to turn into applications for the program. Members of the community are encouraged to identify ideas for projects here, and whether they would be willing to act as a mentor for a student attempting the project.

Students can base their application on one of these ideas, or on an idea of their own if they prefer (Deadline March 25th????? See GSoC timeline)

Processes

If you are thinking of applying for GSoC, please see our Google Summer of Code/Processes page which describes the way that we manage GSoC within OSM, so you know what we expect of students and Mentors.

Project Ideas

This is the list of projects. Please add projects using the GSoC idea template.

Website

Groups
Suggested By
Summary
Add 'Groups' functionality to openstreetmap.org, providing a way for mapping communities to organise and communicate
Skills Required
Rails; OSM community knowledge
Difficulty
Medium/High
Possible Mentors
tbc
Notes
Long-desired improvement to OSM; some prior work has been done but code would be best approached from scratch. Will require good Rails knowledge but most of all an understanding of OSM and a willingness to work within the community.
Comments
Reactions
Suggested By
Summary
Sometimes you want to (y) someone's contribution
Skills Required
Rails; OSM community knowledge
Difficulty
Low/Medium
Possible Mentors
tbc
Notes
Comments
Similar to github. Provide a way to react to changesets, diaries, changeset comments, diary comments, gps traces, and so on. For full party popper emoji, provide an api. The work that's been done on the spam report button can possibly be recycled.


API

Matt Amos' Road to API 0.7 is an overview of proposed changes.

Refactor the DB schema for better usability on our access patterns
Suggested By
Summary
Get rid of all the supplementary tools that visit main OpenStreetMap database. Make it all API calls. Make them fast.
Skills Required
ruby; SQL
Difficulty
Medium/Hard
Possible Mentors
Notes
There are now planetdump tool, Osmosis and website itself that access database via Postgres interface, not via API. This all should be cut off, so that we have API as self-contained thing that can be refactored in a better way. Afterwards artifacts from 2008 can be removed, including the custom tiling indexing, tags being separate table instead of k-v field, etc.
Comments
Tied with most of the other backend changes
cgimap-ruby
Suggested By
Summary
Finish off cgimap-ruby and update OpenStreetMap-Website to use it
Skills Required
Ruby; C++
Difficulty
Medium
Possible Mentors
tbd
Notes
Cgimap-ruby is a project to embed cgimap inside the website. At first this would seem like a strange thing to do, but what it means is that anyone can continue to download and work on the website on their local computer without needing to also run cgimap separately. It's already difficult to get started developing the website, and we don't want to make it any harder.
Comments
Potentially tied with one of the other backend changes
Full cgimap read-only support
Suggested By
Summary
Add more read-only API calls to cgimap
Skills Required
C++, PostgreSQL
Difficulty
Easy/medium
Possible Mentors
Paul Norman, Komяpa, tbd, Gardster
Notes
At the moment, cgimap supports only a few of the available API calls, and none of the ones which aren't 'geographic' such as user details. The support needs to be added here, so that we can start routing all read-only API calls to cgimap and get some confidence that they're all implemented correctly. There's nothing terribly complicated to do here: It's a matter of looking at the Rails code to see what it's doing, writing tests for cgimap to try and cover all the different conditions, then writing the code.
Comments
Good to tie in with cgimap-ruby or write support
Full cgimap write support
Suggested By
Summary
Add data-modifying API calls to cgimap
Skills Required
C++, PostgreSQL
Difficulty
Easy/medium
Possible Mentors
Paul Norman, Komяpa, tbd, Gardster
Notes
A read-only API is all very good for taking the load off Rails and spreading it over database replicas, but it's only half of the answer. The other half is being able to support writing new data to the API. This is going to require some major changes to how cgimap works internally, but could bring some major improvements to upload latency which, at the moment, can sometimes feel quite slow.
Comments
Good to tie in with read support
Make the website use the API
Suggested By
Summary
Change the website to rely on API calls instead of directly accessing the database
Skills Required
Javascript, Ruby
Difficulty
Easy/Medium/Hard
Possible Mentors
Paul Norman, Komяpa, tbd
Notes
At the moment, the website directly accesses the same bits of data as the API, via Rails, from the database. This means the website and API are tightly coupled and it's impossible to change one without changing the other.

It also means it's not simple to implement any sort of caching or replication to make the website faster. This is because the read-write connections that the API uses are indistinguishable from the read-only connections to Rails' internals.

This step might be quite difficult, as there are a number of places in the website where it directly interacts with database objects, for example in the "browse" pages. In some cases, the website is using functionality or data which isn't currently available in any API, for example the next and previous objects for pagination.
Comments
This would need scoping to be specific about what parts of the website are targeted

The different cgimap and API projects are related and if a student wants to pick parts from each project, this is an option.

Nominatim

Nominatim is the geo search engine that powers the search box on the main osm.org site. There are a number of enhancements open that fit into the framework of GSoC.

Improve Postcode handling
Suggested By
Summary
Postcodes are difficult to handle for OSM search engine because the data in OSM is very sparse. There are currently two problems with postcodes: 1) Nominatim works with a postcode set that is once computed during import and never updated. 2) If somebody searches for an address that contains a postcode Nominatim does not know about, no results are returned even when the rest of the address is known to Nominatim. The goal of this GSoC to solve both problems. You should first extract the current postcode data into a separate table and make that table updateable. In the second part you should change the search algorithm so that postcodes in a searchquery can be detected and ignored.
Skills Required
PHP, SQL(Postgresql, Postgis)
Difficulty
Medium/High
Possible Mentors
lonvia
Notes
Comments


Add Wikidata to Nominatim
Suggested By
Summary
Nominatim already uses page ranking of Wikipedia pages to guess the importance of all the places it indexes. Lately OSM data has also gained a lot of wikidata tags which might provide similar information. The goal of this project is to extend the existing wikipedia extraction scripts to also take into account wikidata. The principal aim is to improve the existing importance ranking. As a secondary goal you should investigate if other data from wiki data might be useful as well in order to improve search result.
Skills Required
PHP, SQL(Postgresql, Postgis)
Difficulty
Medium/High
Possible Mentors
lonvia
Notes
The existing wikipedia extract script can be found here: https://github.com/twain47/Nominatim/blob/master/utils/importWikipedia.php
Comments
OpenAddresses for Nominatim
Suggested By
Summary
While OSM is an excellent source for geocoding, it still lacks house number data in many parts of the world. There are now multiple projects that collect house number data from freely available sources, for example OpenAddresses or BANO. Nominatim already makes use of the free Tiger data to improve address search in the US. It would be great if other free sources could be used in a similar way. The goal of this project would be to define a common import format for house number data, write a converter for OpenAddress data and an importer for Nominatim.
Skills Required
PHP or Python, SQL(Postgresql, Postgis)
Difficulty
High
Possible Mentors
Notes
Comments
Improve Reverse Geocoding Algorithm for Nominatim
Suggested By
Summary
Reverse geocoding (getting the address for a given location) in Nominatim doesn't really give the best possible information about a requested location. It searches for the closest OpenStreetMap object and returns address information about it. That leads occassionally to surprising results, in particular in areas with sparse data coverage. The goal of this project to develop and implement a new algorithm for reverse geocoding that better covers the actual position.
Skills Required
PHP, some SQL(Postgresql, Postgis)
Difficulty
Medium
Possible Mentors
Notes
Comments

3D

Web application for sharing 3D-Models to use in OSM-related 3D-Applications
Suggested By
Summary
3D rendering and modelling gets more and more attention in the OSM ecosystem. However, not everything can and should be modelled in OSM itself, when dedicated 3D modelling applications are a better choice. The student is tasked to write a web application that allows uploading and managing 3D models for buildings and street furniture but also for textures to use in OSM. Ideally the website also features comments, a JS based live view of the models and so on.
Skills Required
Web-Engineering
Difficulty
Medium
Possible Mentors
Notes
Applicants should note which language and technology they would use, they should also contact the possible mentors before they apply
Comments
There is a more detailed description at the 3D Model Repository subpage
New features for the OSM importer for Blender
Suggested By
Summary
Blender is a free and open source 3D platform. It supports 3D modeling and rendering as well as many advanced features like animation, simulation, compositing, motion tracking, video editing and game creation.

OSM Importer for Blender 3D is a popular open source (GPL) addon for Blender. Among thousands of users of the addon are professional 3D designers, architects, scientists and hobby 3D modellers. There is a steady demand from the Blender community for 3D models of real world environments. Development of new features for the addon is to strengthen interest in OpenStreetMap amongst huge Blender community.

Possible features for GSoC:

  • Roads and paths (low-polygon and more detailed)
  • Railways (low-polygon and more detailed)
  • Smart materials for buildings
  • Hipped roofs for an arbitrary building outline (Straight Skeleton algorithm)
Skills Required
Good knowledge of Python, vector math
Difficulty
Medium
Possible Mentors
Notes
Exact project scope is to be discussed
Comments
Wavefront OBJ Export/Import for OSM2World
Suggested By
Summary
The 3D renderer OSM2World generates detailed 3D worlds – including buildings, roads, railways and many other features – from OpenStreetMap data. These worlds can be exported, among other things, for use in 3D modeling software. To that end, OSM2World currently has basic support for Wavefront OBJ as an output format. There are, however, some limitations:
  • Advanced features such as multiple texture layers cannot reliably be translated to OBJ.
  • Differences between target software require different compatibility features.

There is no existing support for OBJ as an input format. The student is therefore tasked with the following:

  • Identify differences between OBJ-consuming applications and implement compatibility features in OSM2World.
  • Write graphical and command-line interfaces for OBJ export that let the user selectively enable those compatibility features.
  • Implement import functionality for OBJ models in OSM2World, to allow placing pre-made objects into a scene.
Skills Required
Java
Difficulty
Medium
Possible Mentors
Notes
The application should note previous experience with 3D-modeling tools (if any).
Comments

JOSM

JOSM: New main menu
Suggested By
Summary
Structure the JOSM main menu and make it easier for plugins to add their entries in the right place. See [1].
Skills Required
Java
Difficulty
Medium
Possible Mentors
michael2402 (or someone else on the JOSM team)
Notes
Comments
If you include the time to adjust plugins, this will be enough for a GSoC.
JOSM: Change build system to gradle
Suggested By
Summary
Currently, JOSM and it's plugins are built using an ANT script. Dependency handling would be simplified a lot if we switch to gradle.
Skills Required
Java, Groovy, Gradle
Difficulty
Hard
Possible Mentors
Notes
Comments
Do not underestimate this. JOSM has a lot of special build steps that need to be re-written and tested. Fixing the dependencies and changing the plugins is not an easy task.
Further improvement of several plugins; PT_Assistant, Mapillary, Traffic_signs
Suggested By
Summary
-
  • Last year the PT_Assistant plugin was created, it can easily be extended to also validate and help correct Walking and Cycling route relations from within JOSM.
  • 2 years ago the Mapillary plugin was created, several improvements are possible.
  • Rework the traffic_signs plugin, so some tags get set on the node representing the sign pole, while others get set on the way/node affected by the sign.
Skills Required
Java
Difficulty
Medium
Possible Mentors
Notes
These are a few smaller discrete projects that, together, will be enough work for a GSoC project. The student will need to get acquainted with the code of those 3 plugins and show understanding by showing how they will improve it. Candidates shouldn't be afraid to get their hands 'dirty' by downloading them and making modifications/improvements on their local computers before GSoC starts.

I'm always available for Hangout sessions to explain how they work at the moment and where they could be improved. Then we'll need to have followup sessions where you can show your ability to work on the code. Candidates with good OpenStreetMap edits created using JOSM and its plugins will get extra credit. Mapping on OSM is the only way you can understand the needs of your fellow mappers. If you find issues with other plugins, I'm open to suggestions for improving those (additionally or instead of the ones proposed by me).

This means you will already be spending quite a lot of time before GSoC starts and there are no guarantees we'll be able to select you. Of course, we hope you'll also stay on board after GSoC ends, making edits and code improvements.
Comments
libosmscout: Implementation of a OpenGL ES renderer
Suggested By
Summary
libosmscout already has implemented renderer based libagg, cairo, DirectX, Qt. An OpenGL (ES) renderer is badly missing as a fast render engine targeting desktop and mobile devices
Skills Required
C++, OpenGL, OpenGL ES
Difficulty
Hard
Possible Mentors
Notes
Comments
libosmscout already offers all the code required to load tile data and get notified if loading of these data has been finished. It also offers Style sheets to get information about the (currently 2D) visualisation of the retrieved objects. What is missing is the actual OpenGL (ES) code to fill the render pipeline and render the resulting stage and code for simple interaction (moving, zooming).

GPS improvement

DGPS@home
Suggested By
Summary
Improve your GPS signal by correcting it with information from a GPS fixed to your balcony and share information online. See [2] (German)
Skills Required
Web, Database, Mobile Phone/Android
Difficulty
Medium (maybe Hard concerning GPS receiver programming on Android)
Possible Mentors
Notes
Applicants should contact the possible mentors before they apply
Comments

Unified Preset Management System

Unified Preset Management System
Suggested By
Summary
Most OSM contrbutors add and edit object properties based on predefined templates, so called "Presets". There are currently two preset systems in wider use, the iD system and the JOSM system (used by JOSM and vespucci). Likely there are further app specific ones. Besides the obvious duplicate effort issue, having two systems leads to fragmentation in tagging, for example using different expressions for the same real world object/concept (multiply that by the differing translations), using different tag combinations for the same objects, varying level of detail in tagging and so on.

Both systems further suffer from being difficult for non-developers to contribute to and are in general becoming difficult to manage. Further problems are quality assurance and tracking actual in use tagging.

The project would result in a single unified preset repository (defining the technical implementation would be part of the project) that would minimally allow maintainers to add/modify/delete new presets, generate application specific preset configuration files and have support for preset search and life cycle management.

As this project only makes sense if the major editor applications actually use the end product, substantial social skills in twisting the arms of the relevant developers will be required.
Skills Required
Web, git, general programming knowledge, social competence
Difficulty
technically medium, socially hard
Possible Mentors
Notes
Comments

Third Party Source Management System

Third Party Source Management System
Suggested By
Summary
While OSM revolves around personal, on the ground survey, there is no denying that 3rd party sources are important for OSM, be they aerial imagery, out of copyright maps, geo-referenced images or open data sources.

What OSM however lacks is an integrated system to manage such resources, both from a contributor that is trying to discover which sources are available in a specific area and from an administrative point of view. The later encompasses both documenting that all required steps to determining the suitability for use in OSM have been taken, as contact details for both the sources, the responsible contributors (personal details etc. that need to kept private) and auto-generating attribution.

Both the http://wiki.openstreetmap.org/wiki/Import/Catalogue and https://osmlab.github.io/editor-imagery-index/ implement subsets of the required functionality however do not scale, require dev-knowledge and are not integrated with the main website.
Skills Required
Web, Rails, Databases, general programming knowledge
Difficulty
medium
Possible Mentors
Notes
Comments

OSM Data Store (for mobile devices)

OSM Data Store (for mobile devices)
Suggested By
Summary
There are numerous well known file formats for storing processed OSM data on mobile devices (at least OsmAnd, mapsforge, maps.me) these are however all orientated towards efficient rendering of the data and are not suitable for supporting offline editing.

The deliverables for this project should be a compact file format from which all OSM data can be efficiently geographically retrieved (typically via a bounding box based query), an API for Android and iOS and server side tools to generate extracts in the proposed format for download.

Bonus points for in situ updates of the data.
Skills Required
Web, Databases, GIS, general programming knowledge
Difficulty
difficult
Possible Mentors
Notes
Building on existing implementations/code would be preferred (for example libosmscout might already provide larger parts of the required functionality) however is not required. −
Comments

Support for indoor routing (SIT schema)

Support for indoor routing (SIT schema)
Suggested By
Summary
There is a generally accepted OSM tagging schema for indoor elements and floor plans, SIT (http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging). However while there is a reasonable support for visualisation of such data, there is currently no specific indoor routing support for any of the more popular OSM based routing engines which leads to contributors using stop gap measures (for example adding additional ways in already very densely mapped areas.

The deliverables for this project should be indoor routing support in at least one of the popular online routing engines and one of the open source android/ios apps.

It should be noted that indoor routing over indoor floor areas was already implemented in 2012 (5 years ago) for support of the historic IndoorOSM tagging schema which SIT is loosely based on.
Skills Required
Web, Databases, general programming knowledge
Difficulty
moderate to difficult depending on approach
Possible Mentors
Gardster
Notes
Comments