Top Ten Tasks

From OpenStreetMap Wiki
Jump to navigation Jump to search
Top Ten Tasks - Other languages

These are the Top Ten Tasks that the Engineering Working Group would really like your development help on, and there is no order of priority. Please contact the respective maintainers and System Administrators if you want to join the development, and you are not sure where to start. Otherwise do proceed straight to programming and making pull requests.

The tasks

Localized map rendering

  • What's involved: CartoCSS or Vector Tiles
  • Who can you talk to: dev mailing list or EWG
  • What's being done already: see below for a list.

OSM often contains the name of a feature in multiple languages, but only one of these names is visible on the Standard tile layer and many other raster and vector tiles. This can result in misunderstandings and severely impact the map's usefulness for visitors unfamiliar with the local script.

The goal is to allow the user to see names localized in their preferred language(s), based on Accept-Language headers or optionally an explicit language selection. However, this needs to be made possible without taking too many resources. While this should ideally be applicable to the main osm-carto style, a third-party style fast enough to get featured on the osm.org website would also be useful.

Previous work:

OAuth login to wiki

Active users in OpenStreetMap have two logins: one for the website and one for this wiki. These are not linked in any way, except for a userbox. And this is obviously a frustration for novice users: registering is hard.

Many services in the OSM ecosystem already support logging in as an existing OSM user account via OAuth. The two notable exceptions are the Wiki and the Forum. While the latter at least allows use of an existing OSM account through an alternative mechanism, the wiki requires separate accounts. Implementing OAuth support for the wiki would lower the barrier for mappers to get involved with the wiki, and make life for many members of the OSM community just a little bit more convenient.

The goal is to find a technical solution, such as a plugin for MediaWiki, allowing users to sign in and to register using OAuth. Such a plugin may already exist, but it will need configuring and testing. Additionally, already registered users need a simple way of linking their wiki and OSM logins, and the interface should automatically display two-way links between the profiles.

An unresolved issue that would need to be tackled is whether there should be a harmonization of user names, as wiki and osm.org usernames are currently not a 1:1 match.

Bonus task: Add OAuth sign in to the OSM Forum. Source code for the forum is on the OSM GitHub repository. -> obsolete once Forum will be replaced by Discourse.

Note: Needs to be aligned with move to OAuth2 in https://github.com/openstreetmap/openstreetmap-website/issues/1408

See also:

  • OAuth - starting point for reading up on OSM's OAuth implementation
  • Account - overview of the different types of accounts in the OSM ecosystem
  • OAuthAuthentication extension lets your wiki delegate authentication to another wiki that is running Extension:OAuth

OSM API deleted items call

  • What's involved: Ruby on Rails
  • Who can you talk to: Matt
  • What's being done already: AMF call and this pull request

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 used to be an implementation of an undelete feature in Potlatch 1 which leveraged custom code in the rails port to obtain this data. This Rails code has been completely removed in the meantime. Also, this implementation may not be suitable for large-scale use and attention will have to be paid to ensure that the queries run efficiently. Currently the only other way to find deleted items is to use the third-party WhoDidIt service.

There's also a more recent patch by Frederik Ramm, which is also not in a state to be merged (yet).

List of changeset discussions for a user

Despite being a relatively recently added feature of osm.org, many communities have adopted changeset discussions as part of their communications with fellow mappers. There are still some limitations in the user interface offered on osm.org, though: Currently it requires third party websites such as Pascal's to find changeset discussions one participated in. Users can find a list of diary comments on the profile page, but not changeset discussions they've participated in, or comments to OSM notes.

GitHub has a ticket and patch. However, some issues raised in the GitHub issue need to be addressed first before merging is possible.

Better tools for welcoming new users

  • What's involved: Ruby on Rails or anything else
  • Who can you talk to: dev mailing list or EWG
  • What's being done already: see list below

When a user registers to OpenStreetMap, they see a welcome page outlining what OSM is and where to get help. The contents are quite generic, with many channels (especially local ones) absent, and lack a human touch.

Many mappers are putting an admirable effort into filling that gap by welcoming new users from their area to the OSM community, as this kind of local human contact is often considered the best way of helping beginners feel at home in OSM. These messages tend to be written in the local language. They can involve giving feedback to new users' changes (especially those using the review_requested=yes changeset tag), but also just sending a friendly welcome mail, offering a point of contact to the local community, sharing experience with local data sources and imagery, and/or inviting users to local user groups, regional mailing lists or forums.

Developers can help encourage this kind of grassroots community building by providing tools that make it easier to notice and contact new users joining a local community.

Existing tools include:

Area datatype

  • What's involved: Ruby on Rails, C++, SQL, Java, etc.
  • Who can you talk to: dev mailing list or EWG
  • What's being done already: mostly conceptual work, see Area/The Future of Areas for some background and thoughts on the issue

OpenStreetMap has three data types: nodes, ways and relations. Areas, lacking a dedicated type, are modelled with either ways or relations. This is often ambigous and needlessly hard to understand, creates problems for software development, and makes it hard to detect common errors in our map data (especially for larger polygons).

A native area datatype would solve this, but despite widespread support for the idea, it has not been implemented so far. The task is very hard due to the number of tools affected by it, and considered "a holy grail of OSM" by many. It would require a database migration, support in the website and all editors, a (temporary) means to convert data to API 0.6 on the fly, testing, and so on. It is likely too complex for a single person. If you want help, please read Area/The Future of Areas page for some hints.

Different members in the development community estimated the total effort in a range of several years. Some even questioned if this is feasible at all.

Improved activity/history tab

  • What's involved: Ruby on Rails or anything else
  • Who can you talk to: Matt, Paweł Paprota
  • What's being done already: OWL

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 solved for some this problem by integrating with the main website to create a more interactive History tab (see beta). As of 2015, the OWL website was unusably slow, and as of 2018, it is no longer online. Currently, there is no good way for listing changesets actually affecting a given area.

To solve this, you have to mind not only the database size, which will be measured in terabytes, but also speed and user experience. It should render the last 10-20 changesets for any given filtering options in a second for thousands of simultaneous users, and the resulting map should not be too messy.

Clickable POIs on the frontpage

  • What's involved: Mapnik, JavaScript, or possibly an alternative technology stack
  • Who can you talk to: dev mailing list or EWG
  • What's being done already: this research and the query tool

One of the areas where other map providers score 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,

Another option is to use Mapnik UTF-8 grids as an alternate renderer for mod_tile, so UTF-8 tiles are created, then re-use the provided examples.

The goal is to get clickable POIs on the osm.org frontpage. Additional UI features such as highlighting icons on hover could drastically improve the user experience.

Note: these days, Vector Tiles would probably cover those requirements more or less out of the box.

Pedestrian and bike routing on areas

  • What's involved: algorithms, routing engines
  • Who can you talk to: dev mailing list or EWG
  • What's being done already: see list below

The goal of this task is to implement correct distance calculation and connectivity across plazas (including to inner rings of multipolygons), and visual display of the resulting route.

Plazas and squares are a prominent feature of pedestrian networks and have been mapped as highway=pedestrian/footway/... + area=yes for a long time. Still, none of the routing engines included on osm.org currently support this feature, which leads to mapping for the router and undersells the data quality of OSM.

This feature can be implemented using any pedestrian router that fulfils the inclusion criteria for osm.org.

Previous work:

Completed or deferred tasks

Here is a small list of some older tasks that got either finished or deferred. The EWG will try to keep this list current and add new tasks to the list above as they see fit.

See Also

  • Develop - the main OSM development portal
  • Bugs - links to various bug tracking lists
  • Research/Ideas - for ideas on scientific research
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Top_Ten_Tasks&oldid=2307562"