Google Summer of Code/2024/Project ideas
Jump to navigation
Jump to search
This page lists a number of ideas for potential Google Summer of Code 2024 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.
iD editor
|
Suggested By
Summary
Support the display of images from Panoramax instances in a similar manner as for Mapillary, and other street level image sources.
Skills
JavaScript
Length
175 hours (could be extended to 350 hours depending on project goals, see notes below)
Difficulty
medium
Possible Mentors
Panoramax team see https://amicale.net/@cquest/111841579008116097
 Martin Raifer (tyr_asd on osm, edits, contrib, heatmap, chngset com.)Notes
This will need some fleshing out. Potentially support for multiple editors could be done by one student in a large project.
Another way to extend the scope of this project would be to consolidate/refactor the street level imagery support in iD to reduce code duplication (to improve code maintainability) and enhance usability of the widgets.
|
|
Suggested By
Summary
Mandatory skills
JavaScript
Useful skills
Experience with the D3.js framework, OSM tagging/mapping workflows, and iD development
Length
350 hours
Difficulty
medium
Possible Mentors
Notes
Mapping certain attributes such as access restrictions can be quite difficult in iD. Currently, the mapping of access restrictions on roads, barriers, and similar map features can be quite difficult, especially when Conditional restrictions come into play. The goal of this project would be to implement a user interface widget which should a) provide a better visual interpretation of already mapped access restrictions (for example in the form of icons similar to road signs for various situations) and b) allow to more easily add or modify such access restriction situations. The widget should also be able to take regional differences into account, such as differences in real world road signage and/or mapping practices.
Comments
If feasible, this widget should be implemented in a way that can be flexibly applied to other complex mapping situations. This would need to be considered in the planning phases of the project.
|
|
Suggested By
Summary
The OpenHistoricalMap project has a more research-oriented methodology than OpenStreetMap. In OHM, mappers are expected to cite their sources more frequently and more specifically than in OSM. Consequently, OHM's fork of iD displays a very prominent "Sources" field, but this field is currently just a plain text field. The goal of this project would be to enhance or replace this field with one that helps mappers correctly cite multiple published sources using a WYSIWYG interface. Some validation rules should help enforce citation standards.
Mandatory skills
JavaScript
Useful skills
Familiarity with academic citation practices
Required experience
No prior experience with OpenHistoricalMap required, but experience with OpenStreetMap would be a plus
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
This feature would most likely be limited to OHM's fork of iD, but infrastructural improvements may be contributed upstream to OSM's iD. This feature has not been designed; the student will develop their own UI design within the framework of iD's existing fields, incorporating feedback from the mentor and user community.
Comments
This is a popular idea. We welcome proposals for this idea, but you may want to also submit a proposal about one of our other ideas or something original, to improve your chances of getting accepted.
|
|
Suggested By
Summary
The OpenHistoricalMap project focuses on mapping geographical history. Often a feature is known to have existed at some point in the past, but the precise dates of inception and extinction are unclear. OHM adheres to the Extended Date/Time Format standard for representing uncertain dates. OHM's fork of iD includes a plain text field for entering EDTF dates, along with basic validation. However, users must be familiar with the EDTF syntax to use it. The goal of this project would be to design and implement a more intuitive interface for EDTF dates that a layperson would be able to use effectively.
Skills
JavaScript
Required experience
No prior experience with OpenHistoricalMap required, but experience with OpenStreetMap would be a plus
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
This feature would most likely be limited to OHM's fork of iD, but infrastructural improvements may be contributed upstream to OSM's iD. This feature has not been designed; the student will develop their own UI design within the framework of iD's existing fields, incorporating feedback from the mentor and user community.
|
JOSM editor
|
Suggested By
Summary
Further development and bug fixing of PT_Assistant
Skills
Java
Length
350 hours
Difficulty
medium
Possible Mentors
Notes
Comments
PT_Assistant is a JOSM plugin that makes it easier to work on Public Transport itineraries in OpenStreetMap. It also allows to work on cycling/hiking/equestrian routes/itineraries. It doesn't do automatic routing, but it enables the mapper to say where the buses, trolleybuses and trams go, without the need to manually split ways. It also checks the route relations for validity. Are all stops served? Is the vehicle traveling against oneway traffic flow?
|
Valhalla router
|
Suggested By
Summary
The OpenHistoricalMap project has small but growing coverage of historical transportation infrastructure. From a modern perspective, it can be difficult to appreciate reductions in travel time enabled by road development or by the opening of a specific thoroughfare. For this reason, historians often mention how long it used to take to travel from one place to another as context when explaining a sequence of events. An OHM-based router could improve spatial understanding based on how humans actually navigate on the ground, not just from a bird's eye view. Some OSM-compatible routing engines already support time-dependent routing, with caveats; however, a historical router would need to consider whether each edge in the routing graph existed during the specified time period, to avoid anachronistic routes. Additionally, routing profiles could be configured for relevance to historical means of transportation.
Mandatory skills
C++ (assuming Valhalla as a starting point)
Useful skills
OSM analysis, graph search algorithms, Lua
Length
350 hours
Difficulty
hard
Possible Mentors
Notes
Initial exploration on GitHub, discussion with Valhalla developers, advice from the Valhalla developers
Comments
The end goal would be a live service integrated with the OHM website, but we would still be interested in a more tightly scoped project that only runs in a staging environment or locally, as long as it is readily reproducible. This project description assumes Valhalla as a starting point, due to the mentors' familiarity with it, but we would be open to a proposal based on another capable routing engine that the student is already reasonably familiar with.
|
Vespucci editor
|
Suggested By
Summary
Support the display of images from Panoramax instances in a similar manner as for Mapillary, and other street level image sources.
Skills
Java, APIs
Length
350 hours
Difficulty
medium
Possible Mentors
Notes
This will need some fleshing out. Potentially support for multiple editors could be done by one student in a large project.
|
|
Suggested By
Summary
Ferrostar is a cross-platform turn-by-turn navigation SDK which integrates with OSM-based routers like Valhalla and (to some extent) OSRM. The core of the framework is written in Rust, and most of the existing development is focused on iOS and Android. One area that we see as a good summer project is adding support for use in PWAs. This will involve creating JS <-> WASM bindings to the functional core (which has all the core navigation state tracking logic) and building out an MVP user interface in JavaScript using the web Geolocation APIs. While PWAs and web geolocation APIS generally have some limitations, they are much easier / quicker for organizations to adopt as they don't need a team of specialist native developers for each platform. The goal of this project is to have an MVP quality frontend web component which others can adopt. The map rendering may be handled by either MapLibre or Leaflet. An enterprising student will ideally also be able to build some showcase examples demonstrating integration with existing geocoding APIs, as this will encourage further adoption, particularly in contexts like local government which may not have the resources to hire a specialist team. This project will enable them to offer better services to their citizens by leveraging OpenStreetMap. This in turn encourages them to update OSM (I have prior experience coordinating this; see multi-use paths for golf carts in Peachtree City, GA which the local government now maintains as they have built routing on top of OSM using Valhalla for their residents).
Mandatory skills
JavaScript; frontend frameworks (React preferred for maximum reach); some familiarity with binding generation
Useful skills
Rust; WebAssembly
Required experience
Frontend JavaScript experience required; Prior experience with WASM not required, but would be nice
Length
250 hours
Difficulty
medium
Possible Mentors
Notes
Comments
Ferrostar is a fairly new project; we can probably relax the prior contributions requirement.
|
OpenStreetMap Americana
|
Suggested By
Summary
The project aims to enhance accessibility for users with color vision deficiencies (CVD) by developing a plugin for MapLibre vector maps. This plugin will enable dynamic switching between color schemes, making maps easier to interpret for individuals with various forms of colorblindness. Leveraging OpenStreetMap Americana as the base, the plugin will ensure that geographical and topographical information remains clear and distinguishable for all users.
OSM Americana is based on a javascript and typescript implementation of a vector tile based cartography style using the Maplibre style language. A colorblindness plugin can leverage existing functionality for language label switching and map sample previews as existing uses cases for how to integrate with the maplibre library and perform dynamic changes to the map. A student should be comfortable with researching the requirements for CVD implementation and designing a scheme for transforming a normal color vision map into a CVD-friendly scheme. A plugin should allow for both standard, rule-based transformations into CVD color schemes as well as designer-specified transformations. Finally, the project should result in a plugin which can be used in other Maplibre maps by way of a npm package with supporting documentation that other developers can use.Mandatory skills
Web; javascript; general programming knowledge
Useful skills
digital cartography; accessibility; npm packaging
Length
175 hours
Difficulty
medium
Possible Mentors
Notes
Comments
−
|