User:Zverik/TTT 2017 Draft

From OpenStreetMap Wiki
Jump to navigation Jump to search

This page list the top tasks on which the Engineering Working Group, with the help of many OpenStreetMap members, would really like your development help. Please contact the group 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.

Old page: Top Ten Tasks.

The Tasks

Moderation Queue

OpenStreetMap website, including diaries, the map, user notes and other services, often seens spam or abuse in various forms. Currently people are reporting it to admins via IRC channels or by mail. With the increase of contributors, we need a better way.

The work on moderation queue, which is basically a "Report" button next to everything, started in 2014. It should present to admins a queue of all reports from every service on OSM website, allowing them to ignore or act on a report.

Andy Allan has been working on it since July, and maybe he might use your help.

Localized map rendering

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

Most raster and vector tiles use only local names, from name=* tags. It may flatter some local mappers, but in many countries it results in misunderstandings and even uselessness. For example, in countries with many official languages, mappers often dispute on which should be used for labels. And if you don't know Chinese, you'll have a hard time browsing the map of China.

Please find a way to display the map in a user's language, but without taking too many resources. Ideally this should be applicable to the main osm-carto style, but can also be a third-party style fast enough to get on the osm.org website.

OAuth Login To Wiki

  • What's involved: PHP and OAuth.
  • Who can you talk to: EWG
  • What's being done already: nothing.

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.

Please write a plugin for MediaWiki to sign in and to register using OAuth. This plugin may already exist, but it will need configuring and testing. Additionally, already registered users need a simple way of linking their accounts to OSM logins. And maybe a visible link in the interface to show a link to OSM profile, and vice-versa, from OSM profile to OSM wiki.

Bonus task: add OAuth sign in to the OSM Forum. It already uses ids from the OSM database, but it would benefit from signing in with a single button click, instead of typing a password. Source code for the forum is on the OSM github.

OSM API deleted items call

Working with deleted objects in OSM API is pain. There is only one way to retrieve a deleted object: to get the full history and then retrieve the specific, last but one, version. You cannot see what has been deleted in an area. You cannot revert a deleted way or relation easily. Deleted objects have no geometry and no API.

For Potlatch 1, there was an AMF method to retrieve deleted ways in a bounding box. There is no alternatives in the API 0.6. Currently the only other way to find deleted items is to use a third-party WhoDidIt service.

What is needed:

  • A way to render a deleted object on the website (see the PR above).
  • An API call to retrieve deleted nodes, ways and possibly relations with their deleted dependencies.
  • A simpler workflow for restoring deleted objects, possibly from the web interface.

List of changeset discussions for a user

  • What's involved: Ruby on Rails
  • Who can you talk to: EWG
  • What's being done already: see issues 842, 1148 and this pull request

Currently it requires third party websites to find changeset discussions one participated in. Like the Pascal's. You have a list of diary comments on the profile page, but not changeset discussions you've participated in, or comments to OSM notes. Github has a ticket and patch, which must require some polishing and testing.

Automatic Welcome Messages

  • What's involved: Ruby on Rails or anything else
  • Who can you talk to: EWG
  • What's being done already: manual welcoming

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 absent, and lack a human touch. Because of that, mappers in Belgium, Spain, Russia, and some other countries track first edits by mappers and send them private messages manually. These messages personally welcome a user and offer them a selection of useful country-related links.

The task is to automate this, maybe adding regional automatic welcome messages to the Rails port itself. The key is to wait for the first edit: it is often made in a user's region. Then we know their country, and if a welcome message is configured for that country or even a region, it is sent to a user.

Note: this task is controversial, so maybe make it more manual. Like, make it easier for people to welcome mappers, but not send automatic messages based on region or language. Mappers worry that people would get spam instead of personal connection. Please consult with the community or at least with EWG and CWG before starting the work.

Area datatype

  • What's involved: Ruby on Rails, C++, SQL, Java, etc
  • Who can you talk to: EWG
  • What's being done already: nothing

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 leads to many errors. For example, you cannot easily decide if a closed way is a ring or a circle. An area datatype would solve this, removing multipolygon relations and making the geometry model of OSM closer to other GIS.

The task is very hard, and considered "a holy grail of OSM" by many. It would require a database migration, support in the website and all editors, a [temporary] methods to convert data to API 0.6 on the fly, testing, and so on. It may be too complex for a single person. If you want to try, please read Area/The Future of Areas page for some hints.

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 OWL website is unusably slow, and in 2017 it is offline. 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 in terabytes, but also speed and user experience. It should render the last 10-20 changesets for given filtering options in a second for thousand users at once, and the resulting map should not be too messy.

Clickable POIs on the frontpage

  • What's involved: Mapnik, JavaScript
  • Who can you talk to: EWG
  • What's being done already: this research and the query tool

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,

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 major drawback for the current Overpass solution is that requests are slow (>1 sec is slow), the server chokes on too many requests, blocking a user, and there is no link between displayed and queried features. Displaying a popup panel immediately after clicking on an icon, and even highlighting icons on hover would drastically improve the user experience. See Google Maps for an example.

That depends on which of the two productive servers your request ends up, compare to the lz4 server instance with consistent <1s response time: http://overpass-turbo.eu/s/w9w. Also we could much more simplify the query for your use case, replacing "around" by a bounding box, and only query for nodes and ways (leaving out relations). The server also doesn't choke, that's intentional rate limiting to avoid abusing resources. Mmd (talk) 13:04, 13 February 2018 (UTC)

Pedestrian and bike routing on areas

  • What's involved: algorithms
  • Who can you talk to: EWG
  • What's being done already: see this issue for many links to code and papers

Despite the ability to map pedestrian squares as areas, routing in OpenStreetMap is still done on ways. It is understandable, having a set of edges is simpler than calculating a route over an area with a complex boundary. All the popular route engines represented on the OSM website cannot route over pedestrian areas.

This task can be implemented using any pedestrian router that fulfils the inclusion criteria for osm.org, either existing or a new one. It does not need to do the conventional car routing. The only requirement is to be relatively fast when published on the OSM website.

Note: this task is controversial. Some consider it important, because routing on areas is useful, some think that it would encourage mapping routable squares and disadvantage many routers. Because when you have a single working routing engine that understand areas, mappers will stop mapping highway lines over pedestrian squares, since it has been proved to be possible to route without these. All routers who cannot do that will be disadvantaged.

See Also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:Zverik/TTT_2017_Draft&oldid=1567590"