Google Summer of Code/2025/Project ideas
Jump to navigation
Jump to search
This page lists a number of ideas for potential Google Summer of Code 2025 projects. 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 OSM developer community are encouraged to identify ideas for projects, and indicate whether they would be willing to act as a mentor for a GSoC contributor attempting the project, using the GSoC idea template.
Participant project ideas
GSoC contributors can base their application on one of the ideas below, but we also encourage potential GSOC contributors to come up with their own ideas for projects around OpenStreetMap software. Do you have a pet annoyance you want fixed? A feature you think should be implemented? If you believe you are capable of implementing it and it fits within the time constraints and the GSOC eligibility criteria feel free to bring the idea forward.
Please get in touch with the organizers (at gsoc-orga@openstreetmap.org) as soon as possible if you want to work on something not listed here, so that we can make sure you get the best support possible. We would suggest supplying the same information as in the templates below, if you don't have a potential mentor it may be possible for us to find one for you.
General
|
Suggested By
Summary
The 3D Model Repository (3DMR) is a website which lets users upload openly licensed 3D models and link them with OSM data. Renderers such as OSM2World can use this to create 3D scenes of real-world locations.
The goal of this project is to improve the 3DMR by adopting glTF as the format for 3D models, and to upgrade the codebase to current versions of Django and Oauth. In addition to these essential updates, the project would be an opportunity to improve the website UI and API.
Mandatory skills
Python
Useful skills
Django, JavaScript, 3D graphics
Length
350 hours
Difficulty
medium
Possible Mentors
Notes
As a minimum requirement for applicants, we expect you to set up a local copy of the existing codebase on your own prior to submitting your application so you have a starting point for your work.
|
|
Suggested By
SimonPoole
Summary
Produce a prototype repository and API for temporary road closures and similar for use in OSM (navigation) apps that supports user submitted data, at least one prototype integration in an OSM Navigation app is expected.
Mandatory skills
Postgres/SQL, languages suitable for prototyping for an UI and an API
Useful skills
having a brain
Length
350 hours
Difficulty
advanced
Possible Mentors
SimonPoole
Notes
The assumption is that the API will deliver the information in OpenLR format and that data entry can either be via an extension to an app, or a web UI. For an implementation of OpenLR and matching to OSM data see https://github.com/FraunhoferIVI/openlr Contribution guidelines for projects that I mentor contribution guidelines https://github.com/simonpoole/GSOC/blob/main/guidelines.md
|
|
Suggested By
Yug, Kheera.
Summary
In 2024, we collaborated with a French local museum and mayoral office to laboriously created an interactive and multimedia map displaying historic regional languages toponyms to visitors.[1;2] Building upon this experience and prototype, we want to develop an user friendly UX pipeline combining Open Street Map online editor, Wikimedia Lingua Libre, Wikimedia Commons and Leaflet.js. It should streamline translations of places names on OSM and retrieval of those on Lingua Libre in order to create all necessary data for such interactive multimedia maps of regional names. Museum currators would then use our open source web service with specific url parameters to display to their visitors the interactive maps of their region and language, on the model of this prototype. This tool would bring lesser resourced languages speakers to contribute to both OSM POIs localisation-translation efforts and Lingua Libre/Wikimedia. Optionally, offline variation could be explored.
References
Mandatory skills
OSM API, Django for Lingua Libre, MediaWiki, Leaflet.js.
Useful skills
IOT/Arduino.
Length
350 hours
Difficulty
medium
Possible Mentors
Yug, Kabir Singh
Notes
|
Searching
|
Suggested By
Summary
OpenStreetMap registers names of streets, POIs and places usually in the local language. Larger features like cities or states have translations into other languages but simple POIs like restaurants or hotels often have the local name only. That means that it is quite possible that when searching in OSM data, results are returned that are not only in an unknown language but also in an unknown script, making it impossible to read. Transliteration solves this problem by transfering an unknown script into one the user knows an can read. For this project we want to add transliteration to results of the search engine Nominatim when there are a results that the user may not be able to read.
Mandatory skills
Python
Useful skills
knowledge of a non-Latin script or the willingness to learn basic reading of one during the project
Length
175 hours
Difficulty
medium (some research is expected and smaller road blocks that need to be solved independently)
Possible Mentors
Lonvia, mtmail
Notes
The map on openstreetmap.de shows transliterated names. Have a look especially at Asia and compare with the standard map on [1]. The code for the localisation of the German map can give some useful pointers to libraries for transliteration.
Comments
Please also see the general hints for contributing to Nominatim for GSOC at User:Lonvia/GSoC_2021_Nominatim_Projects.
|
|
Suggested By
Summary
When users search places, they often like to use category words ("hotels in Berlin", "Eiffel tower bus stop", ...). Nominatim has limited support for such category searches. It defines Nominatim/Special_Phrases which are detected in the search query and then used to filter the results. The manually curated lists in the wiki are rather tedious to keep and duplicate other community-maintained lists. For this project, you should explore the tagging presets of the ID editor. The presets contain an extensive list of category names for OSM tags with many translations. The goal of this project is to make these terms searchable with Nominatim. Given that the editors and search engines have very different goals, this will not be a straightforward translation. You will have to experiment and research how category words are used in search, which may include thinking about into simple linguistic problems in a multi-lingual setting.
Mandatory skills
basic understanding of OSM tagging including some experience with editing OSM data, basic Python
Useful skills
SQL(Postgresql, Postgis)
Required experience
intermediate
Length
175 or 350 hours
Difficulty
medium to advanced
Possible Mentors
Lonvia, mtmail
Notes
This idea can be either done as a shorter 175h project concentrating on extracting and using simple category words from ID's presets. This would be of medium difficulty. At a length of 350h, students can dive more deeply into the search algorithms for categories and improve them to also find subcategories ("vegan restaurants").
Comments
Original issue at [2]. Please also see the general hints for contributing to Nominatim for GSOC at User:Lonvia/GSoC_2021_Nominatim_Projects.
|
Routing
|
Suggested By
Summary
The router relies on a preprocessing step to build a graph from OSM data. This graph tile build is a multiphase process that takes around a day to run on modern hardware. There are a number optimization experiments we can try to bring the overall build time down. More info here: https://github.com/valhalla/valhalla/issues/5099
Mandatory skills
familiarity with c-like languages
Useful skills
multithreading, performance profiling, knowledge of graph structures
Required experience
novice
Length
175 hours
Difficulty
moderate
Possible Mentors
Notes
Comments
Experimentation is encouraged, we should pull whatever threads look to be most promising in our experiments.
|
|
Suggested By
Summary
Ferrostar is a rust based cross-platform turn-by-turn navigation SDK. Ferrostar works with multiple routing engines and using tools like Mozilla's UniFFI and TSify, integrates with modular UI for native iOS, Android and a web PWA (thanks to GSOC 2024!).
But not all navigation goes according to plan! If we could record the inputs from a navigation session (GPS etc.), and the new state after each update, we can “see through the user’s eyes” when something goes wrong. The contributor will help build such a session logging and snapshot testing tool. In addition to the backend (Rust), the contributor will also build a frontend integration for at least one platform (Native iOS or Android, or Typescript web components).Mandatory skills
Rust; some mobile or web
Useful skills
Most work will be in Rust, but there will also be some work in a frontend platform of your choice (iOS, Android, Web); you don’t need to be an excellent frontend designer or anything, but some existing knowledge will help.
Length
175 hours
Difficulty
medium
Possible Mentors
 Ian Wagner (on osm, edits, contrib, heatmap, chngset com.) and Jacob FieldingNotes
|
iD editor
|
Suggested By
@tordans
Summary
Similar to the QA Layers in iD, add a MapRoulette integration to see and resolve tasks. The UI can be mostly backported from Rapid. However, the underlying code will likely need to be changed to fit into the iD architecture. More at https://github.com/openstreetmap/iD/issues/10758
Mandatory skills
JavaScript, D3
Useful skills
Working with APIs in JavaScript, OSM mapping experience
Required experience
intermediate
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
-
Comments
-
|
|
Suggested By
@tordans
Summary
Backport the improvements for Sidewalk mapping from Rapid to iD and modify them based on community feedback. More at https://github.com/openstreetmap/iD/issues/10757 and https://github.com/openstreetmap/iD/issues/10743
Mandatory skills
JavaScript, D3, strong OSM mapping background
Useful skills
-
Required experience
advanced
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
-
Comments
-
|
|
Suggested By
Summary
The goal of this project would be to implement a user interface widget which should a) provide a better visual interpretation of already mapped Key:opening_hours (for example in the form of a time table), b) checks for the validity of the contents of the tag, and c) allow to more easily add or modify such information. The widget should be able to take the most common formats into account and allow a fallback to show the full tag content for more complex situations.
Mandatory skills
JavaScript
Useful skills
Experience with the D3.js framework, OSM tagging/mapping workflows, and iD development
Required experience
intermediate
Length
90 or 175 hours
Difficulty
medium
Possible Mentors
Notes
This project could be extended to 175 hours by enhancing the functionality of the widget also to UI fields for tags with temporal conditions.
|
|
Suggested By
@tordans
Summary
iD has many options that can be toggled during a mapping session. The concept of a "kbar" (https://kbar.vercel.app/) provides an alternative way to reach those options. This would allow power users to quickly change settings without adding keyboard shortcuts to each setting (and memorizing them). See https://github.com/openstreetmap/iD/issues/8801 for more
Mandatory skills
JavaScript, D3
Useful skills
-
Required experience
advanced
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
-
Comments
-
|
|
Suggested By
you!
Summary
Do you have a feature that you think would be a good fit for iD and would like to get it implemented? Does it fit into a time frame between 90 to 350 hours? Is it somewhat self-contained (i.e. does not require to change too many different parts of the iD editor at the same time)? Does it improve the usability/accessibility of the iD editor, does it add more improve mapping workflows, data validations, localization features and/or performance? If the answers to most questions are yes, please be welcome to put in your own idea as a project proposal for the iD editor!
Mandatory skills
JavaScript, D3, OSM mapping
Useful skills
UI/UX, …
Required experience
advanced
Length
90, 175 or 350 hours
Difficulty
hard
Possible Mentors
Notes
-
Comments
-
|
Vespucci
|
Suggested By
SimonPoole
Summary
Develop a solution to extract text from a captured image or directly from the camera. The captured text should either be able to be used as a tag value, or to generate a set of tags that can be directly applied to an osm object. It is mandatory that this only uses resources available on device.
Mandatory skills
Java or Kotlin
Useful skills
gradle, experience with Android development
Length
350 hours
Difficulty
medium to challenging
Possible Mentors
SimonPoole
Notes
The successful candidate will need to have access to a suitably powerful Android device. Googles MLkit might be a potential starting point for text recognition. Note that the use of models and code that cannot be distributed on open terms is not possible. Vespucci repo: https://github.com/MarcusWolschon/osmeditor4android , contribution guidelines https://github.com/simonpoole/GSOC/blob/main/guidelines.md
|
Every Door
|
Suggested By
Summary
Many people have asked for photos in Every Door. They need to be of two kinds: photo notes, and pictures of OpenStreetMap objects. The former may be probably attached to OSM notes and share the StreetComplete infrastructure, while the latter must use Panoramax and add relevant tags. There will be an authentication hurdle, probably related to sharing OAuth tokens. This might also involve collaborating with MapComplete author on their instance.
Mandatory skills
Flutter + Dart
Useful skills
UX design, Riverpod
Required experience
intermediate
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
The Every Door code base is currently undergoing a major refactoring, so it's unclear how easy or hard this would be. But with an experience in basic app design this should be not very hard.
|
|
Suggested By
Summary
Every Door has grown into a big application with a lot of moving parts. Modifying it is sometimes risky, which leads to bugs not patched for a long time. Some little things are covered with tests, but there are absolutely no widget tests, and data tests are also largely missing. Here we need to cover with tests three main areas: providers, field widgets and classes, and helper classes.
Mandatory skills
Flutter + Dart, QA
Useful skills
Riverpod
Required experience
high
Length
350 hours
Difficulty
medium
Possible Mentors
Notes
This is not a front-facing tasks: the app won't get better from your work. But it hardens the foundation for future improvements. You need to have some experience in planning and writing tests, and reading flutter code.
|