Google Summer of Code/2026/Project ideas

This page lists a number of ideas for potential Google Summer of Code 2026 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.

Note on using AI tools

We recognize that generative AI tools like ChatGPT or Copilot can be a tremendous help when writing code and project proposal texts. However, always keep in mind that they are only tools. They cannot do the work for you. In that spirit, you are welcome to use generative AI tools when preparing your application and during GSoC but you must always ensure that you have read, understood and verified the output. Do not copy and paste ChatGPT answers without thoroughly rereading what it has said. We expect that you will be able to answer questions about the content at any time. Furthermore, when you use generative AI, you must mention the tool(s) you used.

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.

Searching

Nominatim - Categories

Suggested By Lonvia Summary Last year we've introduced the concept of categories to Photon. The goal of this project is to add a similar category support to Nominatim. Mandatory skills Python, basic SQL Useful skills some knowledge of Lua Length 350 hours Difficulty challenging Possible Mentors Lonvia, mtmail Notes The goal of this project to prepare the database structure and processing chain to work with the category concepts. Comments Please also see the general hints for contributing to Nominatim for GSOC at User:Lonvia/GSoC_2021_Nominatim_Projects and make sure you read the rules on AI contributions before submitting any PRs. Also, human-written email is likely to get a higher priority than lengthy AI-assisted pieces.

Nominatim - Improve import performance

Suggested By Lonvia Summary Importing the full OpenStreetMap planet into a Nominatim database takes 3 days by now. This is getting too long. In this project we want to explore some possible changes to how the indexing phase of Nominatim works and measure the impact on performance. Skills Python, basic SQL Length 350 hours Difficulty challenging Possible Mentors Lonvia, mtmail Notes The two main changes I have in mind here: A) Currently the main placex table has a column with the marker what needs to be updated. This means that the table is written more often than necessary. We should move the TODO list in a separate table. B) Indexing is parallelized in a way that the parallel processors all need to write to the same tables getting in each others way. We should distribute the data, so that write contentions is less likely. Comments Please also see the general hints for contributing to Nominatim for GSOC at User:Lonvia/GSoC_2021_Nominatim_Projects and make sure you read the rules on AI contributions before submitting any PRs. Also, human-written email is likely to get a higher priority than lengthy AI-assisted pieces.

Routing

Make closures.osm.ch production ready

Suggested By SimonPoole (simon at osmfoundation.org) Summary closures.osm.ch was started in GSoC 2025, this year we want to integrate it more closely with at least one routing application and tie up some of the remaining loose ends (see the github repo). Mandatory skills python, docker, routing algorithms and knowledge of the implementation language of the target routing app. Useful skills Practical experience using OSM data and contributing. Length 350 hours Difficulty medium Possible Mentors SimonPoole Notes Only applications that fulfill our minimum requirements will be accepted.

Valhalla - Parking Lots

Suggested By Christian Beiwinkel / Valhalla Community Summary We are currently introducing a multi-modal costing called "auto_walk" which combines vehicle and pedestrian routing: directions for driving to the nearest parking lot, followed by walking directions to the destination. This project aims to parse, store and use parking lot data in OSM to mark parking opportunities in the graph. Mandatory skills C++, basic SQL Useful skills Lua Length 350 hours Difficulty challenging Possible Mentors Kevin Kreiser, Nils Nolde, Christian Beiwinkel Notes I'll write a lengthier issue about this in the upcoming days, in the meantime there is [this discussion](https://github.com/valhalla/valhalla/issues/5801)

Valhalla - Make Landmarks prod-ready

Suggested By Nils Nolde Summary We introduced a landmark/POI-based guidance concept (e.g. "Turn right after 50 m before the next Wells Fargo branch") in a previous GSoC. However, it's not ready yet to be hosted on the public instance. This project is aiming at improving performance and fixing some smaller bugs in the POI ingestion so global planet imports become viable, and as a feature publishing a "POI" layer on our vector tiles implementation. Mandatory skills C++, basic sqlite Useful skills Lua Length 175 hours Difficulty medium (for someone with decent C++ skills) Possible Mentors Kevin Kreiser, Nils Nolde, Christian Beiwinkel Notes Profiling the current POI ingestion performance to pinpoint improvable performance sinks and debugging the code will be part of the project.

Valhalla - Make GTFS/public transit prod-ready

Suggested By Nils Nolde Summary We (re-)introduced public transit routing based on GTFS (only for now) in a previous GSoC. However, it's not ready yet to be hosted on the public instance. This project is aiming at making sure that we can host at least a few dozen if not hundreds of GTFS feeds within a reasonable amount of time. Currently it's a fairly open scope and part of the project will be to figure out what's still missing to make that happen, including a GTFS feed downloader/updater. Skills C++ Length 350 hours Difficulty challenging Possible Mentors Kevin Kreiser, Nils Nolde, Christian Beiwinkel Notes This project needs a pretty strong and curious C++ developer.

Valhalla - Enhance Pedestrian Routing

Suggested By Kevin Kreiser Summary Pedestrian routing is becoming increasingly important in modern applications with the tendency toward walkable cities and the rise of alternative navigation modalities such as wearables. This project aims to improve a user's ability to follow a given pedestrian route by enhancing the metadata attached to it. One of the main challenges that arises in pedestrian navigation is the lack attribution for pedestrian only ways. Sidewalks don't have names, park pathways, similarly, don't have names. While we can still give guidance in these situation it is more ambiguous, eg. "turn left". Landmark routing can certainly mitigate these scenarios but its coverage can also be lacking. This project focuses on improving the situation by enhancing the data in the graph by spatially joining metadata from nearby OSM features to the part of the graph where pedestrian attribution is lacking. This may be done by eg. copying road names to unnamed sidewalks that abut them, or by eg. marking nodes as park entrances where area features intersect. Mandatory skills C++ Useful skills spatial/geometric operations Length 175 hours Difficulty medium Possible Mentors Kevin Kreiser, Nils Nolde, Christian Beiwinkel Notes This is an open ended project in the sense that we may discover better opportunities for improvement during investigation and pivot to working on those instead of those already mentioned examples above.

Rendering

Customizable Planetiler Profiles and MapLibre Style Optimization

Suggested By Mike Barry Summary Planetiler is a tool that converts OpenStreetMap data to vector tiles that can be used with web-based mapping libraries like MapLibre GL. There are a few full-featured profiles written in Java with industry-wide adoption like Protomaps basemaps and OpenMapTiles, and a customizable yaml syntax for defining simpler schemas without any code. This project would aim to bridge the gap to make it easier to customize and extend full-featured profiles by letting people add individual yaml layers to an existing Java profile and filter the output to only features needed by a MapLibre stylesheet. Mandatory skills Java Useful skills Experience with Java and API design. Familiarity with frontend development and intrepreters a plus. Required experience Intermediate experience with Java Length 350 hours Difficulty medium Possible Mentors Mike Barry Notes Phases: (1) allow adding layers from a yaml config to any planetiler profile (2) config-driven feature and attribute filtering (3) convert maplibre style(s) to a filter config (3) builds on (1) and (2) and will unlock new workflows where users can iterate on a style against a "raw" tileset then "publish" optimized tiles from it by generating a new tileset using the style as a filter.

The Tileserver Tradeoff Observatory: Automated Performance Measurements

Suggested By Frank Elsinga / MapLibre Community Summary Current benchmarks for tile servers compare "apples to oranges" (e.g., cached vs. uncached responses) or rely on outdated, static snapshots. This leads to misinformation where users choose a server based on theoretical maximums rather than their specific constraints (memory vs. CPU vs. latency). This project aims to build the Tileserver Tradeoff Observatory: an automated system that runs nightly "Performance Labs" in CI. Instead of a simple "speed test," this suite will isolate and visualize specific architectural tradeoffs that a user can choose (e.g., PostGIS vs. PMTiles vs MBTiles, gzip vs. brotli overhead). The results will be published to a self-regenerating "Living Whitepaper" website that educates users on how to configure their tileserver for their specific needs. Mandatory skills Docker & Scripting to set up the isolated test environments Frontend dev to write a nice dashboard providing insights into the tradeoffs Useful skills Basic knowledge of statistics Required experience Intermediate to advanced. Prior experience with web development, scripting and good benchmarking is required. Length 350h Difficulty Medium(Requires systems thinking to ensure benchmarks are scientifically valid and reproducible in a noisy CI environment) Possible Mentors Frank Elsinga Notes Existing state of the art to build upon: https://github.com/FabianRechsteiner/vector-tiles-benchmark

DuckDB Backend for the Martin tileserver

Suggested By Frank Elsinga / MapLibre Community Summary Add first-class DuckDB support to Martin using DuckDB’s spatial extension and native ST_AsMVT / ST_AsMVTGeom functions. This enables efficient vector tile serving directly from analytical, file-based datasets such as GeoParquet/Flatgeobuf, without requiring PostGIS. The project focuses on a clean integration with Martin’s core architecture, useful feature parity with the transactional PostGIS backend, and clear guidance on when an analytical DuckDB backend is the right choice. Mandatory skills Willingness to learn and dive into the rust geospatial ecosystem Useful skills Rust programming skills SQL knowledge Familiarity with geospatial concepts (CRS, tiling, MVT) Ability to read and extend existing backend code Writing tests and technical documentation Required experience Intermediate to advanced. Prior experience with Rust backends or spatial databases is recommended, but not required. Length 350h(Full GSoC project (medium to large scope)) Difficulty Medium(Requires understanding Martin’s internal architecture, spatial SQL, and performance trade-offs between analytical and transactional databases.) Possible Mentors Frank Elsinga Notes Initial focus is on GeoParquet-backed DuckDB databases. Support for additional DuckDB file formats is intentionally limited to keep maintenance costs low and performance predictable. Maybe other formats make sense too to add via this, like GeoArrow or Flatgeobuf. Comments The project emphasizes useful feature parity rather than full PostGIS compatibility. Design quality, documentation, and tests are as important as raw functionality.

Editing

Port iD's tag validation logic and UI to Go Map!!

Suggested By Bryce Cogswell (bryceco) Summary Go Map!! is an iPhone app used to edit OpenStreetMap in the field. The iD desktop editor has a robust set of validation functions that warn mappers when they create or modify an object in a way that is inconsistent with best practices. This project would migrate the logic used by iD (written in JavaScript) to Go Map!! (written in Swift, and with a very different architecture). Mandatory skills Swift, some UIKit. Useful skills JavaScript Length 175 hours Difficulty medium Possible Mentors bryceco Notes This project requires a Mac, with development using Xcode. Comments It may be possible to perform parts of the port using AI, but the two projects have such different architectures that it may be of limited use.

AI extraction of information from camera captured images

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

iD editor: UI for opening hours

Suggested By Martin Raifer 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 175 hours Difficulty medium Possible Mentors Martin Raifer Notes Potentially, this project could be extended by enhancing the functionality of the widget also to UI fields for tags with temporal conditions.

Create a web application for tagging presets

Suggested By Martin Raifer Summary Currently, the presets used in iD and other editors are available in code (as JSON files), outside of their intended use from with the editor. This makes it hard to fully comprehend how they are structured, to see how comprehensive they, are it is hard to debug issues withing the tagging schema. It would be useful to have a dedicated web application that visualizes the presets' data. This would be a tool that would be used by the OSM community to lower the barrier to contribute to the id-tagging-schema repository. Among the properties of the tagging schema to visualize are e.g., the inheritance of fields from other presets, regional variants of a preset/field, translated names, aliases and terms, icons, etc. Mandatory skills JavaScript Useful skills Front end web development & UI/UX experience, OSM tagging/mapping Required experience intermediate Length 175 hours Difficulty medium Possible Mentors Martin Raifer Notes This tool could also provide some parts of the code that are currently directly implemented in iD in form of a library that can act as a "reference implementation" for other consumers of the tagging schema.

Other

Client-side 3D model rendering and editing for 3DMR

Suggested By Tordanik Summary The goal is to enhance client-side rendering of 3d models and add support for editing features to improve the contributor experience at the 3D Model Repository (3DMR). Features delivered should include at least: Replace the current implementation of flat map view with an interactive, on globe rendering of 3D models. Provide an API endpoint for lower-res "thumbnail models", use it to improve site performance Support in-browser model editing (shift origin/rotate/re-scale) during model upload. Mandatory skills JavaScript, Python Useful skills 3D graphics Length 175 hours Difficulty medium Possible Mentors AyushDharDubey, Tordanik, Lonvia Notes A potential contributor would have familiarity/prior experience with 3D model rendering pipelines.