Top Ten Tasks

From OpenStreetMap Wiki
Jump to: navigation, search

These are the Top Ten Tasks that the OSM System Administrators would really like your development help on, there is no order of priority. Task 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.


Contents

OpenStreetBugs/notes integration


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 branch to try and integrate this for some time. There is also an instance of it running on the dev-server to see the current status of the work.

Currently, the "server" component of the branch is in good shape, but the "frontend" part needs to be updated and polished. Most of the work here requires reviewing and cleaning the existing code. For example, using a templating engine such as [1] or returning pre-formatted HTML for the note pop-ups.


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!".


Internationalization / localization of PL2


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.


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.


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:


Clickable POIs on the frontpage


One of the (few) 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.). OSM's rich metadata would greatly benefit from this functionality, exposing our depth of coverage beyond what is possible with two-dimensional cartography. But thus far there has not yet even been a significant proof-of-concept, let alone an implementation that will scale up to osm.org.

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.

Examples:


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.


OWL-powered activity/history tab


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.

OWL is a bit of software, currently running on the development server but soon to move to dedicated hardware, which assigns changes to tiles for a more accurate footprint of changes. The history tab needs to be updated so that it can use OWL as a source of data, and give more accurate results.


Routing backend


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

See also Things To Do for other development ideas.

Retrieved from "http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks"
Personal tools
Namespaces
Variants
Actions
site
Toolbox