Google Summer of Code/2017/Project Ideas
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
|
Suggested By
Summary
Add 'Groups' functionality to openstreetmap.org, providing a way for mapping communities to organise and communicate
Skills
Rails; OSM community knowledge
Difficulty
Medium
Possible Mentors
None yet
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.
|
|
Suggested By
Summary
Sometimes you want to (y) someone's contribution
Skills
Rails; OSM community knowledge
Difficulty
Medium
Possible Mentors
None yet
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.
|
Suggested By
Summary
Finish off cgimap-ruby and update OpenStreetMap-Website to use it
Skills
Ruby; C++
Difficulty
Medium
Possible Mentors
None yet
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
|
|
Suggested By
Summary
Add more read-only API calls to cgimap
Skills
C++, PostgreSQL
Difficulty
Medium(Easy if proficient in Ruby and C++)
Possible Mentors
Paul Norman, Komяpa, 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
|
|
Suggested By
Summary
Add data-modifying API calls to cgimap
Skills
C++, PostgreSQL
Difficulty
Medium(Easy if proficient in Ruby and C++)
Possible Mentors
Paul Norman, Komяpa, 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
|
|
Suggested By
Summary
Change the website to rely on API calls instead of directly accessing the database
Skills
Javascript, Ruby
Difficulty
Hard
Possible Mentors
Paul Norman, Komяpa
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.
|
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
PHP, SQL(Postgresql, Postgis)
Difficulty
High(Medium if good in algorithms)
Possible Mentors
lonvia
Notes
|
|
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
PHP, SQL(Postgresql, Postgis)
Difficulty
Medium
Possible Mentors
lonvia
Notes
The existing wikipedia extract script can be found here: https://github.com/openstreetmap/Nominatim/blob/master/utils/importWikipedia.php
|
|
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
PHP or Python, SQL(Postgresql, Postgis)
Difficulty
High
Possible Mentors
Notes
See also
|
|
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
PHP, some SQL(Postgresql, Postgis)
Difficulty
Medium
Possible Mentors
Notes
See also
|
3D
|
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
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
|
|
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:
There is no existing support for OBJ as an input format. The student is therefore tasked with the following:
Skills
Java
Difficulty
Medium
Possible Mentors
Notes
The application should note previous experience with 3D-modeling tools (if any).
|
JOSM
JOSM is an OpenStreetMap editor that allows users to input data into our database. See https://josm.openstreetmap.de/.
|
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
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.
|
|
Suggested By
Summary
-
Skills
Java
Difficulty
Medium
Possible Mentors
Notes
The student will need to get acquainted with the code of the PT_assistant and Road_signs 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 map edits and code improvements.Comments
|
Public Transport
|
Suggested By
Summary
To increase a number of public transport routes in OSM, we need a simple to use web-based editor. It would need to download stops and route relations, edit tags and relation members, keep nodes connected to ways, know about stop positions and platforms. See this write-up. The criteria for finished work will be a functioning and error-free web editor for stops and route relations. Way editing is not required (though it would be an interesting problem).
Skills
JavaScript (+leaflet, +packaging, +xml processing, +some framework), HTML+CSS, OSM data model
Difficulty
Medium
Possible Mentors
Notes
|
libosmscout
|
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
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).
|
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
Web, git, general programming knowledge, social competence
Difficulty
Hard(technically medium, socially hard)
Possible Mentors
Notes
Comments
This is an interesting idea for sure and worth pursuing in some form, but as "twisting the arms of the relevant developers" might be hard to do online (:-)) and as it's socially hard (as stated in the difficulty above) an important step for a student is to talk to the three major projects using presets right now (JOSM, iD and Vespucci). The student would have to talk to each project in advance to get hold of their expectations to see if this project is feasible. There is also some prior art attempts at this here. This has to happen before the application phase as the proposal's project plan should consider the project's feedback. -Mikel
|
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
Web, Rails, Databases, general programming knowledge
Difficulty
medium
Possible Mentors
None yet
Notes
Comments
check out OpenAerialMap for the imagery sources at least
−
|
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
Web, Databases, GIS, general programming knowledge
Difficulty
Hard
Possible Mentors
None yet
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.
−
|
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
Web, Databases, general programming knowledge
Difficulty
Hard(moderate to difficult depending on approach)
Possible Mentors
Gardster
Notes
−
|
In/Outdoor positioning without GPS for Android
|
Suggested By
Summary
When no GPS signal is available mobile devices typically draw upon databases of mobile cell and wifi signal strength measurements to determine a rough position of the device. Using such services has a large privacy impact and for that reason there are multiple 3rd party data gathering efforts (for example https://location.services.mozilla.com/ ) and for Android, a replacement of the OS included system: https://github.com/microg/android_packages_apps_UnifiedNlp The problem with UnifiedNlp is that it doesn't really work for non-Nerds and requires trade-offs that most people are unlikely to make, if you can get it to work at all on a non-rooted Android device, however there is no reason that instead of trying to replace the system location services, apps couldn't use UnifiedNlp plugins directly if a library was provided that allowed such integration.
The other aspect of this issue is that, while there are multiple open apps that allow automatic collection, indoors you are unlikely to have GPS reception and the location data is likely to not make sense. But there is no reason that such location information could not be gathered manually by indicating the position on an OSM map, or suitable aerial imagery (perhaps even including the current building level). It should be possible to add such functionality to one or more of the existing data gathering apps, for example https://github.com/mozilla/MozStumbler (that already has a map display based on OSM). Where is the tie in to OSM? See https://github.com/MarcusWolschon/osmeditor4android/issues/273 an expected deliverable would be integration of an UnifiedNlp based positioning system in Vespucci. Bonus points for automatic level detection in vespuccis indoor mode.Skills
Android, general programming knowledge
Difficulty
Medium
Possible Mentors
SimonPoole
Notes
−
|
Alternative Ideas
Please note that while these look interesting and there are possible mentors attached, implementing these ideas may result in unforeseen issues. If you choose one of these ideas, please participate actively in the community bonding process, research the background and get an understanding of how your project would integrate into the OpenStreetMap ecosystem.
|
Suggested By
Summary
Get rid of all the supplementary tools that visit main OpenStreetMap database. Make it all API calls. Make them fast.
Skills
ruby; SQL
Difficulty
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
|
|
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
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
−
|