Top Ten Tasks
These are the Top Ten Tasks that the OSM System Administrators would really like your development help on, there is no order of priority. Tasks should only be added by the osm sysadmin team and only 10 tasks should ever be on the list at any one time. For tasks which have already been completed, please see Completed Tasks. Each task should have a relevant contact name alongside it as the contact for assistance with getting involved the task as well as a progress page.
A solution is in particular more useful if it is performant enough to handle the number of visitors on the OSM main page. Please also make a branch of the rails port source tree and implement there the necessary user interface for the main website.
Contents |
Support for multiple languages on help.osm.org
There are two parts to this task. 1) i18n and l10n of the help.osm.org user interface. 2) Create a viable strategy to deal with questions and answers in multiple languages.
1) help.osm.org is based on the OSQA software. To some degree OSQA already supports translating the user interface. It uses the i18n features of Django and can be set to choose the language of the UI based on the users' browser preference. However, this feature is not yet activated on help.osm.org and only a limited number of language translations currently exist. This part of the task would therefore involve working with the operations team to enable OSQA's i18n features, as well as create more translations in different languages.
2) To be able to easily support multiple languages of questions in the same instance of help.osm.org, a good filtering system is needed to restrict questions and answers to the language a given user can understand. Unlike e.g. Shapado, OSQA currently does not support this feature. Therefore this part of the task would require extending the OSQA software accordingly.
Clickable POIs on the frontpage
- What's involved? mapnik, javascript
- Who can you talk to? Matt,Michal Migurski
- What's being done already? Progress
One of the areas where Google Maps scores over OSM is that many POIs on their slippy map are clickable, bringing up a balloon with more details (link to website, etc.).
Mapnik's MetaWriter functionality could provide much of the brainpower for this. Alternatively, User:Komяpa has written an implementation for openstreetmap.by that could be reusable.
Another option is to use Mapnik2 UTF-8 grids as an alternate renderer for mod_tile, so UTF-8 tiles are created, then re-use the provided examples.
POI inspection tool on the frontpage
OSM's rich metadata would greatly benefit from being able to inspect features on a map (whether they are rendered or not), which would expose the depth of coverage beyond what is possible with two-dimensional cartography (and the clickable POIs task above).
A public prototype waits for testing and feedback.
Is using a standard WFS server and implementing GetFeatureInfo requests in OpenLayers out of the question because of the infrastructure reasons? Paweł Paprota 13:19, 15 October 2012 (BST)
Examples:
- OpenStreetMap Беларусь (click any building with POIs inside)
- Overpass API Click Layer for OpenLayers (just click any OSM object) or Overpass API Popup Layer for OpenLayers (more cleaned up)
- [1] which CycleStreets has set up.
- [2], Öpnvkarte.
- OpenStreetBrowser http://www.openstreetbrowser.org/
- OpenLinkMap http://www.openlinkmap.org/
- OpenPOIMap http://www.openpoimap.ch/
Routing frontend
OpenStreetMap data has many use cases. One important use case is routing. In order to encourage more mappers to check that their data is of sufficient quality to allow good routing, we would like to integrate a router into the main page of openstreetmap.org To this end, a routing frontend, fully integrated into the rails port, needs to be develop that can talk to the various different existing routing engines and display the results.
There is some early work in this direction that can be used and built upon. This code can be found in the routing git branch and there is also a demonstration instance to try out the current efforts. As this version is still very rudimentary and doesn't always work well, the task is to extend it and turn it into a well working and user friendly routing front end.
XML deleted items call
Currently, there is no way to get information about items which have been deleted through the API, but this information is important to implementing undelete features in clients.
There is a previous implementation of an undelete feature in Potlatch 1 which used custom code in the rails port to obtain this data. However, this implementation may not be suitable for large-scale use and attention will have to be paid to ensure that the queries run efficiently.
Improved activity/history tab
- What's involved? rails, javascript
- Who can you talk to? Matt, Paweł Paprota
- What's being done already? Progress
The history tab on the front page shows recent changesets in the area displayed. However, due to worldwide changes (often automated edits or bots) it is a well-known problem that many of these changes are uninteresting and merely have bounding boxes which overlap the field of view, no actual changes inside it.
In the end of December 2012 OWL reached beta status and solves this problem by integrating with the main website to create a more interactive History tab (see beta).
Completed Tasks
OpenStreetBugs/notes integration
- What's involved? rails, javascript
- Who can you talk to? TomH,Amm
- What's being done already? Progress
OpenStreetBugs is a tool used to annotate the map with descriptive geographically localized notes and bug reports. It would be useful to have this capability on the front page and there has been a openstreetbugs branch to try and integrate this for some time, now renamed the 'notes' branch. There is also an instance of it running on the dev-server, and a documentation page about the feature.
Internationalization / localization of PL2
- What's involved? flash, translatewiki
- Who can you talk to? Gravitystorm
- What's being done already? Progress
Potlatch 2 is the default editor embedded into the OpenStreetMap site. As such, it is generally the method by which editors are first introduced to the complex task of editing OSM data. This is not straightforward for new users, and would be much easier if the editor was translated into the user's language.
There has been an i18n function in Potlatch 2 for some time, but the upgrade to Flex 4 appears to have introduced many bugs. Possibly there are patches available, and much of the work consists of merging and testing, as well as moving more of the strings into the i18n framework. Furthermore, P2 localization, once properly working, needs to be integrated with translatewiki.net, the platform used for translating other parts of the osm.org website.
ODbL migration tools
The migration to ODbL is coming and, unfortunately, it will probably be necessary to remove some data for which the contributors haven't agreed to the upgraded terms. The extent of the damage this will cause is a source of disquiet for many, and it would be useful to have tools which are able to make this information visually available.
Tools for:
- Viewing what will need to be removed, e.g: like [3].
Deferred Tasks
Potlatch 2 tutorial mode
Potlatch 2 is the default editor embedded into the OpenStreetMap site. As such, it is generally the method by which editors are first introduced to the complex task of editing free-form, topological OSM data. This is not straightforward for new users. One way of helping would be to present a tutorial as an option to new users.
A start on this has been made on a branch, but needs work to add hooks (event listeners) so the tutorial palette can check whether the user has done the tutorial action, write the tutorial(s) themselves, enable a dummy data source (i.e: not the live API) during the tutorial and make a nice splash screen saying "Hey! Try the tutorial!".
It should be noted that having an editor with a tutorial mode is still very much desirable. However, it was the consensus opinion that Flash isn't the technology to be using any more, and effort spent on PL2 tutorial mode might be better spent on a JS-based editor.
Routing backend
The OSRM server is available for use as a backend. Unless the load we put on this server is excessive, it seems unnecessary to continue this task.
There are many routing engines available, each with its own trade-offs of speed, resource usage, flexibility and stability. What is not well understood, as well as constantly changing, is how each of these performs on a planet-wide scale and what resources are necessary to run it.
A possible avenue of approach would be to generalise the interface to all the suitable bits of software and to impartially measure the performance, scalability and (very importantly) resource usage of these and make that information available. For example, a very fast routing engine is not very useful unless it can be regularly updated, preferably in a manner similar to the tile server.
See Also
- Things To Do for other development ideas.
- Contributors functionalities wishlist
