This page attempts to list such items with a summary and description, maybe with an indication of whether they are mainly research or development. However it should be noted that OpenStreetMap development moves fast. These ideas could be out of date (please be bold in editing this wiki page to remove ideas which are already implemented) Any students/organisations using this list would be well advised to join the OpenStreetMap talk and dev mailing lists to get a better idea of what is really required. It would also be a good idea to "claim" a project by marking it with student name and institution so that work is not duplicated unnecessarily.
Database geospatial investigation
Investigate geospatial extensions for databases
The current OpenStreetMap database does not use any special extensions designed to make geospatial data easy and quick to use. Investigation should be made into database support of geospatial objects, how this would integrate with the OSM data, and what performance gains could be achieved. Can the OSM database be restructured to improve access speeds?
Make OpenStreetMap more wiki-like
The OpenStreetMap project is styled as a "wiki for maps". However it is currently quite difficult to spot changes, undo them and to go "back in time" for particular roads/nodes/areas in the map. API v0.6 introduced change sets which opens up many possibilities for enhancements in this area. This project should investigate how to make use of the API change set information to create new interfaces as part of the Openstreetmap website and/or the editors for managing edits. These could be used by the community to patrol and keep the data clean.
Make OpenStreetMap easier to use when not on the Internet
Mapping with OpenStreetMap currently requires frequent access to the Internet. This project should investigate ways of off-line mapping. For example one may go away for six months and map the local area - this mapped data should then be able to be merged into the OSM database (which may already contain some of the newly mapped data) when the person returns. Do you trust the newer uploaded data if the older existing data looks more accurate (maybe according to uploaded GPS traces or the number of nodes)?
Make OpenStreetMap easier to use when not on the Internet
Currently the easiest way to use OSM is via the web interface. However this requires Internet access. The proposed project is to make it possible to use OSM off line. Today one possibility is to download an OSM file with JOSM then load it up in Maperitive to work off line, unfortunately Maperitive is in beta. This process is cumbersome and needs to be made more user friendly. Could the off line cached file be updated with just the updates in the same way that JOSM only sends the changes that have been made? Could we give the user more control over what is rendered in a user friendly way?
- Traffic Signals: Create a concept how the map features need to be extended to gather needed information to
use the map for visually impaired persons. See GLOSA
- Develop a software (and if needed a hardware) to make interesting entries in the map accessible for
visually impaired persons (traffic lights with sounds, cinemas where movies with additional audio descriptions are shown, dogs for the blind training sites etc). See LoroDux/Requirements
- Obsolete: Can be done by iPhone and Android Screenreaders.
Develop a software (and if needed hardware) to create an acoustic output that can be easily used for walking navigation and public transportation navigation for blind persons.
- Develop a software and a hardware to render a tactile output of the map that can easily be
used by blind persons to plan routes for walking and using public transportation. See HaptoRender
- Develop a software (and if needed hardware) to create a tactile output of the map that can easily be used
by blind persons to get an overview of a city, country, island etc. See HaptoRender
- Help to develop a concept to guide blind persons over a crossing with traffic signals. See GLOSA
- Take any OSM routing software for a speaking device (iphone / Android) and make it accessible for blind persons.
- Make a concept how blind persons can use a mobile OSM editor. Code it.
See also Category:Disabilities
- Contact Lulu-Ann (Germany) for projects about making the map accessible for blind users and mappers.
Optimize expiring rules
If you take a look on expiring process and rendering of dirty tiles on different zoom levels you will see three things:
- It cost you more to render lower zoom level (z= 11-14) than higher zoom levels (z= 15-18) in standard styles
- At lower zoom level you have more objects per metatile, so you have a higher probability that you have a change in data-base in this area
- At lower zoom level the probability is lower that a change in the database is really visible for a user
So it would be a nice research project to analyse this three effects with statistics methods and find a way to optimize the expiring rules to get the best results on a server with limited power. All three effects should be able to quantify, so e.g. for the last effect count the pixel the have change during the rerendering process (compare old and new metatile) .
- Expected results: Beside a good formular it should give simple rule like: Update z=11-12 all 2 months, z=13-15 weekly, and z=16-18 at each change.
- Background: We could need this knowledge on toolserver.org where we render a lot of different styles.
- Contact: Kolossos
OpenStreetmap and simple features access
OpenStreetMap (OSM) as a free, dynamically-grown project over the years has acquired some singularities, which do not conform to worldwide accepted and approved standards like the simple features (SFA; also called ISO 19125) of OGC ( http://www.opengeospatial.org/standards ). This hinders the utilization of OSM-data volume for third party applications. Interfaces have to be developed or modified. Acceptance and distribution of OSM-data suffers. Especially areas and relations afford problems. ( see https://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Simple_Features ).
It would be helpful to research empirically how far the collection, expostulation and preparation of data in OSM could be optimized according to simple feature access with a view to the voluntarily mapping ordinary person, who needs an easy to use mapping scheme integrable in tools like JOSM or iD, and also considering that a migration of all the existing data is possible if necessary.
Supplementary it would be helpful to get an easy understandable essay declaring simple feature, its elements, their usage and definitions with graphic examples.
- Contact: hurdygurdyman (German conversation preferred, English possible)
Sector mapping with Bing - complete the world
Setup a database which stores all the information which sector of the world is marked as complete mapped according to Bing.
This used to exist: QualityStreetMap
But it hasn't been developed since 2014
Divide the whole world into very small sectors (like a chess board). For every sector you can set a comment and some marks, what and when is was completed (landuse, buildings, streets, trees, POIs or whatever). You can also make comments to already finished sectors to proof that they were checked by an other person. With the database we can assure, that every part of the world get mapped at least one time and can find parts of the world, which never were touched by a mapper.
It's also good to divide the work into smaller parts and see how the world becomes mapped sector by sector until every sector is completed. If we get new satellite sources, we can also assure that date of the new pictures gets integrated everywhere and not only on spots where some mappers are randomly working at.
- Contact: Tric (German conversation preferred, English possible)
Automated Tests for routing validation
Generally it is not easy to say what is a "correct" routing result. But for QA it would already be helpful to find routing differences between actual and older data.
The tests should be insensitive against
- minor position changes of nodes.
- addition or deleting nodes, causing minor changes to the course of a way.
- changes of tags.
- splits or joins of ways.
- new ID (by remapping of way because of the license change)
We need at least one routing algorithm (perhaps with a standardized API). The routing result is normally a list of ways. This is leading into a list of nodes (lat/lon). The comparison works as follows: draw a thin line using the list of result points from the first routing. Draw a second line with background color and a with of let's say 50 meters using the points of the second route. If pixels (from the first line) are left, the routing differs "too much". To find "shortcuts" the check should be repeated with changed roles (first draw the second route as the thin line and then the first route as the thick line).
The test cases could be initialized with random start and end points. Differences has to be checked manually. A different route could be either worse, so the reason must be found and the OSM data has to be corrected, or the the new route is better and the new route must replace the old one in the test suite.
If the routing algorithm changes, these test suite can also be used to find different behavior by using the same OSM data on old and new routing algorithm.
- Contact: mdk (German conversation preferred, English possible)
Evaluation of Traffic Lane Detection with OpenStreetMap GPS Data
The original text can be found here.
In 2010, Yihua Chen and John Krumm have published a paper at ACM GIS about “Probabilistic Modeling of Traffic Lanes from GPS Traces“. Chen and Krum apply Gaussian micture Models (GMM) on a data set of 55 shuttle vehicles driving between the Microsoft corporate buildings in the Seattle area. The vehicles were tracked for an average of 12.7 days resulting in about 20 million GPS points. By applying their algorithm to this data, they were able to infer lane structures from the given GPS tracks.
Adding and validating lane attributes completely manually is a rather tedious task for humans – especially in cases of data sets like OpenStreetMap. Therefore it should be evaluated if the proposed algorithm could be applied to OpenStreetMap data in order to infer and/or validate lane attributes on existing data in an automatic or semiautomatic way.
In the first step, the algorithm of the mentioned publication should be reimplemented and tested. Afterwards it should be tested how many traces in a region are needed to obtain a certain level of confidence and quality.
If GPS data obtained from OpenStreetMap can be used to provide reasonable results, the algorithm should be integrated into a JOSM-Plugin so that the result of the algorithm can be displayed as an overlay on the current data. Features for this plugin could be:
- Detect regions with enough data coverage so that the algorithm can be applied
- Option for filtering relevant traces: simple filter criteria could select traces based on their speed so that for example data obtained by pedestrians is not included (Pedestrians hopefully never follow lanes directly!).
- Apply the algorithm along selected roads or – if it is fast enough – fully automatically.
- Display the results of the algorithms in an overlay (in the JOSM plugin) to the user so that he can decide with one click, if he wants to assign the detected lane attributes to the given road.
The aim of the work should be a runnable demo application which could be submitted to according conferences. Depending on the novelty of the resulting technique (which need not be a simple reimplementation of the mentioned paper), a scientific paper could also be strived for.
- Contact: locked (German/English)
Build a letterbox/post box collection times scanning algorithm
Using pictures of letterbox labels, the algorithm should use OCR to detect the collection times of a letterbox/postbox.
Probably one scanning algorithm/image segmenter would be needed for each operator.
This would likely need to use OpenCV or some similar computer vision library.
Ideally, a mobile app would be developed that
- Enables the user to take a photo to be scanned, then
- reads the collection times from the photo, optionally reperforming the photo-taking to refine the results if they are not correct
- this should also guess the operator of the box
- optionally lets the user do manual corrections to the collection times and/or operator
- queries the OSM database (through overpass api, or similar) to check if a node with amenity=post_box exists at the GPS location of the phone (use buffering to account for uncertanity in GPS location and OSM data accuracy)
- if multiple nodes exist the user should be able to select the correct one
- checks whether the collection times in the database are the same as those read from the photos
- uploads the new collection times if they are different from those in OSM data
- sets collection_times:lastcheck to the current date and time, independent of any collection times change (because even if the times are similar you just performed a check, this should be reflected in the OSM dataset)