Google Summer of Code/2020/Project ideas

From OpenStreetMap Wiki
Jump to navigation Jump to search

This page lists a number of ideas for potential Google Summer of Code 2020 projects. Students can base their application on one of these ideas, or on an idea of their own if they prefer.

JOSM editor core

See tickets tagged with gsoc-candidate in trac

JOSM editor plugins

PT_Assistant plugin

PT_Assistant plugin
Suggested By
Summary
Further development of public transport plugin, with focus on usability for unexperienced users
Skills Required
Java
Difficulty
Medium
Possible Mentors
Polyglot, michael2402
Notes
Comments
PT Assistant was developed over the past 4 summers as a GSoC project. I'm compiling a list of outstanding issues here: User:Polyglot/PT_Assistant. The focus this year will be on code cleanup and better integration with core and JOSM's interface. This will be a great learning experience for a student who has the necessary foundation in Java programming.

Indoorhelper plugin: BIM Import

indoorhelper plugin: Additional feature - Import of BIM data
Suggested By
Summary
The idea of this project is to extend the existing JOSM Plugin "indoorhelper" by an import feature for Building Information Modelling (BIM) files. With this import feature it will be possible to convert BIM modelled indoor data to OSM.
Skills Required
Java programming
Difficulty
Medium
Possible Mentors
Notes
Example BIM files will be provided by the mentors.
Comments

Wikipedia and Mapillary plugins

Extend Wikipedia plugin for Wikidata + Add functionality to add point data to Mapillary plugin
Suggested By
Summary
User interface for working with Wikidata
Skills Required
Java
Difficulty
Medium/Hard
Possible Mentors
Polyglot
Notes
The Wikipedia plugin has basic support for wikidata at the moment. I would like a user interface which compares tags/properties. In case the mapper is importing data into OpenStreetMap, it could help create Wikidata entries for these POIs as well, suitably referenced. There is a WDTK Wikidata Toolkit written in Java, which can probably be used (it was added to JOSM last year) and there is this interface: Sophox, which might be useful and another one from Edward Betts: PDF, video
Comments
Suggested demo of coding ability: extend wikipedia plugin or create a separate plugin and add a layer with nodes for wikidata entries which have coordinates. When such a 'node' is clicked, show a dialog with the properties of the Wikidata item. For the Mapillary plugin, refer to this blog entry: [1]

Geosearch engines

Search suggestions for osm.org
Suggested By
Summary
Providing suggestions while typing in a query in the search box is a standard feature of online maps. OSM's main search engine Nominatim cannot be used for generating such suggestions because it cannot handle partially written words. Full text search engines like elastic search are much better suited for that job. The goal of this project is to set up a database for search suggestions for osm.org. This database must be derivable from the Nominatim database, regularly updatable, be able to handle arbitrary languages and small enough to run alongside the Nominatim installation on nominatim.openstreetmap.org. A possible starting point is the Photon project which creates an elastic search database from Nominatim and therefore already fulfils part of the requirements.
Skills Required
Java, SQL(Postgresql, Postgis)
Difficulty
Hard
Possible Mentors
lonvia, mtmail
Notes
Comments
Please note that this year we only accept students for the Nominatim projects that already have proposed a pull request for the Nominatim software. This may be PRs for code, improvements to the documentation or new tests. For more information, see User:Lonvia/GSoC_2020_Nominatim_Projects.


Not sure this is hard. Take a look at the Lucene Finite State Automata. Basically you pour text in it, and it will produce a very speedy solution. Google it or try for instance https://blog.burntsushi.net/transducers/ Kodapan (talk) 09:46, 29 February 2020 (UTC)
Postcode parsing through pattern matching
Suggested By
Summary
Nominatim can extract postcodes from OSM data and later detect those in the search queries. It currently does not know about the common formats of a postcode for each country. The goal of this project is to extend Nominatim, so that it can detect official postcode formats and use them to improve the search.
Skills Required
Python, PHP, SQL(Postgresql, Postgis)
Difficulty
Wizard
Possible Mentors
lonvia, mtmail
Notes
Comments
Please note that this year we only accept students for the Nominatim projects that already have proposed a pull request for the Nominatim software. This may be PRs for code, improvements to the documentation or new tests. For more information, see User:Lonvia/GSoC_2020_Nominatim_Projects.
Extracting QA reports from Nominatim
Suggested By
Summary
Nominatim contains OSM data in a processed form that allows to discover a lot of inconsistencies. The goal of this project would be to identify possible sources of inconsistencies and write and automatic extraction tool that exports the possible errors to a json file suitable for Osmoscope.
Skills Required
JavaScript, SQL(Postgresql, Postgis), some mapping experience with OSM
Difficulty
Medium
Possible Mentors
lonvia, mtmail
Notes
Comments
Please note that this year we only accept students for the Nominatim projects that already have proposed a pull request for the Nominatim software. This may be PRs for code, improvements to the documentation or new tests. For more information, see User:Lonvia/GSoC_2020_Nominatim_Projects.
Interface for reporting search bugs for Nominatim
Suggested By
Summary
We'd like to have an interface where people can report search results that they think to be wrong. The website would need to record the relevant parts of the search query and ask the user for the expected results. Reporting should work for forward and reverse geocoding requests. The reports should be collected in a database and then compiled into a test suite, for example using https://github.com/geocoders/geocoder-tester. If there is enough time, the project might also include a facility to regularly run the tests and report results in a dashboard.
Skills Required
JavaScript, Python, basic SQL
Difficulty
Medium
Possible Mentors
lonvia, mtmail
Notes
Comments
Please note that this year we only accept students for the Nominatim projects that already have proposed a pull request for the Nominatim software. This may be PRs for code, improvements to the documentation or new tests. For more information, see User:Lonvia/GSoC_2020_Nominatim_Projects.

3D and indoor rendering

Simple Indoor Tagging support for OSM2World
Suggested By
Summary
While OpenStreetMap is already used to map the world in three dimensions, this is usually still limited to the outdoors. By making use of Simple Indoor Tagging, the OSM2World renderer would be able to create seamless indoor and outdoor 3D worlds. The goal of this project is to add basic multi-level floor layouts, involving rooms and walls, doors and windows, elevators, staircases and other indoor features, into OSM2World's 3D buildings.
Skills Required
Java, basic understanding of 3D graphics fundamentals
Difficulty
Medium
Possible Mentors
Notes
The application should note any previous experience with 3D APIs or engines. This knowledge is not strictly required, but makes the project easier.
Comments

OSM Website

Centralized Changeset comment manager (merged with messages?)
Suggested By
Summary
Today it's quite cumbersome to follow changesets comments: The only place where one can keep track on them is by using HDYC website, which is not that user frindely. The purpose of this idea would be to add a kind of forum-like or webmail-like interface in a user profile to list all changesets where the user has published a comment and all changesets by the user which have been commented, with a basic read/unread mechanism. I even think that it could be merged with the profile inbox/messages feature to have everything interconnected in one single place.
Skills Required
Ruby, HTML, JS, CSS
Difficulty
High
Possible Mentors
TBD
Notes
Additional explanatory notes
Comments
You should discuss your proposal with the Rails port project maintainers in detail even before applying. Otherwise there's a very high risk that your contribution will not be considered at all for a later merge.
Improve notification and messaging system on the website
Suggested By
Summary
Skills Required
Ruby on Rails, API basics
Difficulty
Medium
Possible Mentors
None yet
Notes
The OpenStreetMap website has a mechanism that sends you emails when people message you or comment on your changeset. This should include other notification means including the built in messaging system.

This is a suggestion copied over from the 2018 ideas.

See https://github.com/openstreetmap/openstreetmap-website/issues/908 and https://github.com/openstreetmap/openstreetmap-website/pull/1431 for some background.

Work on this should include integration with the microcosm group and event managing system and should consider adding login notification and similar (including API support) for important announcements from the OSMF and operations to the users.
Comments
You should discuss your proposal with the Rails port project maintainers in detail even before applying. Otherwise there's a very high risk that your contribution will not be considered at all for a later merge. Also note that Microcosm is still in development at this time and will most likely not be finished during the GSoC 2020 timeframe.

Osmose-QA

Osmose-QA Web analysis studio
Suggested By
Summary
Osmose-QA provides feedback as issues from OSM data to contributor. It has a part for QA and an other for merging open-data into OSM. The result provides advice to contributors. As time passes there are more rules to write and fix and more open-data available to possibly integrate new data. Nevertheless to contribute the analysis set, it still requires to setup an Osmose-QA instance locally and it is not simple and easy. It is required to write and test new analysis or simply contribute to existing one. The idea is to have a Docker environment setup on server and available on the web through a web interface à la Jupyter. Allowing anyone to tweak the code, write new analysis and test it without requiring to install a local Osmose-QA instance. The goal is to ease the work of contributor to the Osmose-QA code.
Skills Required
Web frontend (JS, Python or other), DevOps (Docker)
Difficulty
Medium
Possible Mentors
Notes
Comments

iD editor

iD - Allow mappers to better use more imagery sources
Suggested By
Summary
iD is limited to using only tile-based and certain WMS layers. Mappers in many areas would be able to access better imagery if you helped improve this.
Skills Required
JavaScript, basic knowledge of geographic projections, basic knowledge of OpenStreetMap.
Difficulty
Medium
Possible Mentors
Stereo
Notes
The editor layer index contains imagery sources and their shapes. Currently, iD only shows tms and some wms layers.
  • WMS sources that don't support the "standard" web mercator projection should be reprojected, like OpenLayers does.
  • WMTS_endpoint and WMS_endpoint, like this one should be shown as a folder or hierarchy.
  • It should be possible to add more than one custom layer, and add them as overlays, not only as background layers.
  • It should be possible to toggle layers on or off, reorder them, or adjust their opacity. See for example how QGIS or JOSM do it.
  • The JOSM imagery index supports a few tokens that ELI doesn't have, like {srid}. iD should support these tokens too.
Comments
A similar idea found no takers in 2018, but the iD programmers have done some work on the 2018 ideas since then, and the idea has been updated.