Skip to content

GSoC 2024 ideas

Jump to bottom Edit New page
Alexander Borsuk edited this page Mar 30, 2024 · 8 revisions

Google Summer of Code 2024 Ideas

Learn more about the GSoC program, stipends, and terms on the official website. Don't forget to send us your proposals before April 2.

Please find below the preliminary list of ideas we would like to explore during this season of Google Summer of Code 2024. The list is not comprehensive. Please feel free to suggest any new ideas and features. GitHub issues or major features can be used for inspiration. Keep in mind that you can also implement only a part of some complex feature. Please join the community to ask questions and discuss ideas.

You can apply to the program here.

Please check all documentation and try to fix some Good first issues to get the project feeling before applying to GSoC. We are looking for motivated developers who can get complex but interesting tasks done.

Proposals

  • We expect students to deeply understand the task and all related issues.
  • We're a small team working on Organic Maps in our free time. We expect that you can work and do your own research independently, and we are ready to provide help and feedback on any uncertainties or discovered issues.
  • Your proposal should have as much information about you, as possible. Please send us your CV, link to your LinkedIn, or other portfolios.
  • The proposal should show us that you understood the task correctly, and estimated/mentioned all related subtasks and issues.
  • The proposal should show us that you can finish the task in the given time. We favor those who can get things done.
  • Any contributions outside of the GSoC scope are welcome. We plan to grow and build the best maps in the world. And we rely on our community to reach this goal.

Consolidate and normalize Planet's elevation data

This task is a pre-requisite to the refactoring of the elevation data in Organic Maps that will allow moving forward with the 3D terrain model. Detailed elevation data is required to implement hillshades and better-quality isolines for hiking and cycling.

There are many sources of elevation data of different quality: SRTM (that is used now in OM), some countries have published their data, and there are also many points and tracks with precise elevation from GPS in OpenStreetMap.org and in other sources.

This project aims to consolidate and normalize the elevation data, to create a quality and detailed enough base for the next steps. The expected results are:

  • Appropriately chosen base/normalized format for the data with fast-read access
  • A number of scripts/tools/binaries to extract and normalize elevation data from different sources (see references below)
  • Appropriate documentation

Estimation: intermediate complexity, 175 hours

Required skills: Large data processing

Mentors: @biodranik, @vng

References:

Satellite imagery support (1) - Prepare imagery data

There are many sources of satellite imagery data of different quality with different licenses. This task is about researching these sources, documenting them, creating necessary tools/toolchains to get/update the data, and normalizing/preparing the data to be served to our worldwide users.

Estimation: intermediate complexity, 175 hours

Required skills: Large data processing

Mentors: @biodranik

References:

Satellite imagery support (2) - Render satellite imagery layer

This task is about downloading, caching, and rendering existing satellite imagery tiles in Organic Maps iOS/Android application. As a result, a user can optionally enable or disable the satellite imagery layer in Organic Maps while seeing other map objects on top of it.

Estimation: hard complexity, 175 hours

Required skills: C++, ideally also some OpenGL/Metal/Vulkan and networking experience

Mentors: @biodranik @vng

References:

The Track Recorder for Android

The ability to record tracks is one of the most asked features of our community. Previous versions of the app had a background track recorder activated in the Settings menu. This recorder has stopped working on Android 8+ due to new background restrictions introduced in the system. This project is about creating a new, full-featured track recorder that can work in the background and save recorded tracks to the Bookmarks and Tracks dialog.

The definition of done:

  • A user can start and stop the recording of his movements.
  • A track is recorded in the background even when a device is locked.
  • A user can see that the track is recorded, and can always pause/resume/stop it.
  • The battery is not drained quickly, so users can finish their journey.
  • A recorded track is displayed on the map and added to the Bookmarks and Tracks.

Estimate: intermediate complexity, 175 hours

Required Skills: a bit of C++ for the core part, Java for the UI part

Mentors: @rtsisyk

References:

The Track Recorder for iOS

The ability to record tracks is one of the most asked features of our community. Organic Maps for iOS already has a "Recent track" feature activated in the Settings menu. It is limited in time and is unreliable as the system may kill the app at any time. This project is about creating a new, full-featured track recorder that can work in the background and save recorded tracks to the Bookmarks and Tracks dialog.

The definition of done:

  • A user can start and stop the recording of his movements.
  • A track is recorded in the background even when a device is locked.
  • A user can see that the track is recorded, and can always pause/resume/stop it.
  • The battery is not drained quickly, so users can finish their journey.
  • A recorded track is displayed on the map and added to the Bookmarks and Tracks.

Estimate: intermediate complexity, 175 hours

Required Skills: a bit of C++ for the core part, Swift/Objective C for the UI part

Mentors: @biodranik

References:

GeoJSON Format Support

Organic Maps already has good interoperability with KML/KMZ formats and supports GPX import. Users can export their bookmarks to use in other applications. Bookmarks and tracks created by other applications, such as Google Maps, can be imported into Organic Maps as well.

This project aims to add support for GeoJSON. GeoJSON has been widely adopted by modern tools and platforms, such as uMap, which is a popular online companion for Organic Maps. Internally, Organic Maps keeps bookmarks and tracks in KML format, so the proper implementation should do the appropriate conversion.

The definition of done:

  • Users can import and export bookmarks and tracks in GeoJSON format
  • Imported bookmarks and tracks are properly displayed on the map and in the Bookmarks and Tracks dialog

Estimation: intermediate complexity, 90 hours

Required Skills: C++

Mentors: @vng, @biodranik

References:

GPX export Support

Many users want to export their bookmarks and tracks in GPX format. This become more important after implementing route saving and sharing.

GPX is a popular format for many other apps. The goal of this task is to allow users exporting GPX in the same way as they are exporting bookmarks and tracks now using KML/KMZ

Check existing implementation and tests for GPX import and KML import/export to better understand the issue.

The definition of done:

  • Users can export bookmarks and tracks in GPX format
  • Exported bookmarks and tracks are properly displayed when imported to Organic Maps and other popular apps

Estimation: intermediate complexity, 90 hours

Required Skills: C++

Mentors: @vng, @biodranik

References:

Save built route and export it in KML

Users are asking us to save built routes to use them later or to share them with other users/to other devices.

Internally, all data (bookmarks and tracks) is already stored in KML format. Built routes should be saved in a similar matter, with the ability to provide necessary directions. This task requires testing in different use cases.

Check existing implementation and tests for KML to understand the issue better.

The definition of done:

  • Users can save routes in KML
  • The saved route is displayed on the map
  • The saved route can be seen in the Bookmarks and Tracks dialog
  • The saved route is properly exported to and then imported to other apps that support KML

Estimation: intermediate complexity, 90 hours

Required Skills: C++

Mentors: @vng, @biodranik

References:

Waterways Navigation and Routing (rivers, lakes, seas)

According to publicly available information, there are more than 2 million kilometers of waterways. Seas, rivers, and lakes are used by kayakers, fishermen, and locals. Before a trip, especially a multi-day trip, it is important to plan a route, taking into account stops for rest and meals, overnight stays, refilling drinking water, refueling a motorboat, etc.

We suggest adding the ability to build routes and navigate waterways to the app. There is already an offline routing engine implemented in Organic Maps. It should be extended or carefully updated to support navigation over waterways.

The definition of done:

  • It is possible to build a route on the water by setting start, end, and optional intermediate points
  • It is possible to navigate on the water and see the current position and the remaining time/distance

Note: A production-ready UI requires Android and/or iOS development skills. It is possible to implement only the core features in C++ and leave all app/UI integration for other contributors.

Estimate: hard complexity, 350 hours

Required Skills: C++, algorithms, OpenStreetMap data structures

Optional skills: Android, iOS

Mentors: @vng

References:

Alternative Routes

Organic Maps has turn-by-turn walking, cycling, and car navigation with voice guidance. The primary limitation is that only one route variant is provided by the planner. This project is about adding support for alternate routes.

Organic Maps uses a custom two-side A* algo for offline routing that should be improved by building more than one route using different criteria/weights.

The definition of done:

  • A user can choose from more than one alternative route while planning the trip by selecting a route on the map.
  • Each route uses different criteria: the fastest one, the shortest one, with fewer (left) turns, etc.

Estimate: hard complexity, 350 hours

Required skills: C++, algorithms, OpenStreetMap data structures

Mentors: @vng, @biodranik

References:

Public Transport Support

There are many possible subtasks in this important and complex task. For example:

  • Display route numbers from OSM on the map when a bus/tram/train stop is selected
  • Extend Subway Preprocessor written in Python to also produce tram, bus and other transport types data in addition to already supported subways/metro/light-rails.
  • Display bus/tram routes from OSM on the map in addition to currently displayed subway/metro/light-rail routes
  • Build a public transport route offline using not only subways/metro but also trams/buses and other types of transport from OSM
  • Match external GTFS schedules data with existing OSM data
  • Build (offline) routes taking real-time schedules into account
  • Efficiently collect and pre-process GTFS and other Public Transport data on a server for mass client distribution and CDN caching
  • Efficiently transfer, cache and use in offline pre-processed schedules data in C++ client code of Organic Maps

Currently, the app only supports subways in major cities. You can finish implementing the experimental feature of GTFS public transport and use it inside the Organic Maps app. It includes all transit types defined by GTFS specification: bus, train, ferry, aerial lifts of different kinds, trolleybus, and much more. This project is about getting a general-available version of the app with the support of some or all GTFS public transport types. The biggest challenge is to properly map GTFS data to OSM data.

There are different ways to approach this important task, and different areas of its implementation (server-side, client-side, map data generator). Please check all related issues first to have a better understanding.

The definition of done:

  • New kinds of public transport (bus, train, ferry, aerial lifts, etc.) are available at least in one city or region.
  • The public database for that city is constantly updated in an automated manner by using a script.
  • The same approach/architecture can be later scaled and used for any other worldwide region or city.
  • An easy-to-use GTFS feed validation tool for transport agencies and OSM editors is an alternative good outcome of this task.

Estimate: hard complexity, 350 hours

Required skills: Python, C++, GTFS, any other necessary tool/technology to make a scalable service (Rust? Golang?)

Mentors: @vng, @biodranik

References:

3D terrain and hillshades support in the core

Currently, isolines are stored as linear features. It limits their usage and takes up a lot of disk space. Some regions do not have isolines because of their significant file size overhead. After implementing a function to get an altitude at any point, it should be possible to draw a beautiful 3D terrain with hillshades, generate dynamic isolines when necessary, and generate an elevation profile for any route in the World.

One of the possible implementations is to store a surface triangulation in mwm map files in a compact format. It can be created from SRTM and other open elevation data (we already have it downloaded).

It may also be worth taking a look at other app implementations if they have a compact storage format for isolines.

The definition of done:

  • Elevation data is stored in a compact format, compared in size or less than the current isolines data.
  • The new format is either embedded inside mwm files instead of the isolines section or downloaded in parallel as a separate file for easier map updates.
  • It should be possible to instantly get an altitude at almost any coordinate in the World.
  • Ideally, an updated dynamic isolines generation/displaying is also implemented.
  • Ideally, a hillshades algorithm is also implemented.
  • OSMand has already implemented that feature, some ideas can be checked in their open-source implementation.

Estimate: hard complexity, 350 hours

Required skills: C++, algorithms

Mentors: @vng, @biodranik

References:

Improved OpenStreetMap editor

Organic Maps allows adding or editing POIs on the map even offline, and uploading all edits directly into OpenStreetMap when the connection is available again. One of the main project missions is to improve the data quality in OpenStreetMap by filling the gaps and keeping information up to date. This goal is reachable by providing an easy-to-use tool that helps anyone (even your granny) to improve the map data for everyone.

There are a lot of issues and features related to Editor in Organic Maps.

Some advanced ideas:

  • Add missing road speed limit info and other important traffic signs or turn restrictions
  • Add speed cameras and traffic lights
  • Upload recorded tracks to OpenStreetMap to draw missing roads later, or directly draw roads using the recorded data
  • Recognize street names or road signs using a camera
  • An easy way to map public transport stops and routes

The definition of done:

  • There is no hard definition yet, feel free to offer your idea

Estimate: can be any, depending on the task/area

Required skills: C++ or iOS/Android for the UI-related tasks

Mentors: @biodranik

References:

Other Ideas

Please check GitHub Issues for inspiration and let us know. Please be realistic in terms of Organic Maps product focus and complexity.

Add a custom footer
Add a custom sidebar
Clone this wiki locally