WikiProject Cleanup

From OpenStreetMap Wiki
(Redirected from Wiki maintenance tasks)
Jump to navigation Jump to search

Broom icon.svg

WikiProject Cleanup is an on-going project to help develop and maintain a clear, well written, linked and accessible wiki providing a wide variety of information to support the OpenStreetMap project. This project provides a largely invisible but vital support to the project by ensuring that all content created on the wiki by numerous individuals on many subjects in many languages integrates into a coherent whole. Well... that's the dream anyway!

Goals of project

The main goals of this project are to help the OpenStreetMap wiki be as accessible, clear, and useful to both mappers and regular users of OpenStreetMap. A few ways to accomplish this is to present article information a way that both increases compliance with the guidelines and follows the rules of article content organization, both of which are worth reading before doing anything mentioned here. It is also important when doing any editing to keep in mind the objectives of this wiki, which are listed below. In general, pages that need certain types of cleanup or re-organization are tagged with a range of Wiki labels in the articles themselves. These labels not only serve the purpose of inviting people to talk about the articles on their discussion pages, they also help categorize them if editors with similar goals in mind want to do "Wiki Cleanup Drives" as a team. Finally, be aware that renaming, moving, or deleting any page can upset other editors. Therefore, before editing any page, especially majorly, it can be better to discuss your edit first the page which is to be changed before you do it. You can also discuss how to change pages generally in the guidelines and rules pages sited above, along with on the Wiki Help discussion pages.

Objectives of Wiki

The OpenStreetMap wiki has these main objectives in relation to OpenStreetMap:

  • Provide background information about OpenStreetMap, including its goals over time and their progress.
  • Give new OpenStreetMap contributors information on how to use properly the various mapping tools and tags that are available to them.
  • Act as a hub for various mapping groups around the world. So, they have a place to co-ordinate and plan mapping events with each other.
  • Give support for people other than contributors, who want to use data and software related to OpenStreetMap, without directly contributing to it.
  • Aide developers in knowing what related software exists and their proper use.
  • Be a place for people to propose new tags and discuss how to use them properly.
  • Help foster a dynamic and creative environment. That way there be can new types of content and things will continue to evolve to meet new challenges.

Tag and key articles

Main article: Creating a page describing key or value


Tag documentation (pages with "Tag:" and "Key:" prefixes) can be very controversial. If you have any doubt, do not hesitate to ask other mappers to share their knowledge and opinions. The tagging mailing list is a good place, but you can ask also elsewhere, especially about more minor and local issues. We cannot expect all mappers to participate in wiki editing or wiki discussions, so asking outside the wiki is often a good idea. Many mappers choose not to edit the wiki.

However if you prefer to avoid discussions and debates... there are actually all sorts of simple edits we can make to clean up tag documentation and make it more consistent, without getting into any debates! Every tag should at least have some words of description. There are three different places where a description appears, at the top of the main page about the tag, in the right-hand template of the tag page, and in the table on the key page. For this simple task, find tags which are missing a description in any of those places, and copy the description from the other places. Most commonly this seems to be copying the description from the key page to the other two.

Any unnecessary differences between the three descriptions for a tag should also be reconciled. The three descriptions need not be identical, although normally they should only differ if the description on top of the main tag page is a little longer. Often descriptions have been improved or updated, but only in one of the three places. Use your judgment to eliminate the older descriptions. If you find a frequently used key that has no description page at all, check whether the key already has documented and/or more common alternatives. If that isn't the case, write a description page for the key to improve our documentation. Make sure that you understand what the key means, though! When there is any doubt, discuss your intentions beforehand.

You can identify undocumented keys because they have no link from the key to the wiki in the Map Data view. There is also a list of the commonest undocumented tags at Taginfo.


Main article: Creating a page describing key or value#Image

Some tags have photos which show up on Map Features (added to the key page tables) but without any image on the tag page itself. Where there is no image at all on the tag page, it makes sense to set the main image of the tag (appearing in the template) to be the same image as seen on the key table. This is easy and requires no judgment or writing ability at all! Similarly it makes sense to use the image from the tag documentation in another language.

Where tag pages have no image (and check there's no image on the key page already) we need to find an image to illustrate the tag. Although we can just pull in any image from Wikimedia commons, it may be preferable to use mapping photos. What does this thing really look like while you're out mapping?

Tag documentation pages that have no image set and display a generic image instead are listed in Category:Feature pages with missing images. Pages referring to images that do not exist are listed in Category:Pages with broken file links.

If you find a frequently used key that has no description page at all, check whether the key already has documented and/or more common alternatives. If that isn't the case, write a description page for the key to improve our documentation. Make sure that you understand what the key means, though! When there is any doubt, discuss your intentions beforehand. You can identify undocumented keys because they have no link from the key to the wiki in the Map Data view. There is also a list of the commonest undocumented keys at Taginfo.

Page length issues

A lot of pages have problem with their length.


A stub is an article which is too short to provide enough information on its subject. In order to identify stub articles, place {{stub}}, or {{tag stub}} if it is related to a tag, on any page that only contains a short description. An article stops being a stub once more sections are added to it. In order to stub articles that need improving, see Category:Stubs.

Short pages

Special:ShortPages lists pages which have very little content. In fact towards the top of the list they have zero content. Many of these are caused by wiki editors mistakenly believing that this is a good procedure for deleting the page. They should be labelling the page using Template:Delete, but often a redirect would be more appropriate than a delete anyway. You may need to check the articles history, and do some searches to figure out the best page to redirect to. In cases where there is some short content on a page, normally this should be expanded to included more description and linkage to higher level concepts / place pages etc (Wiki guidelines#Linking) All of which requires a bit of effort to figure out what's going on with the page. Also you may want to add a {{stub}} label.

Template issues

Use standards whenever possible

There are technical means which ease the page editing and ensure a consistent appearance :

Address block

(the default data for most of the cases) It sometimes can be added via special template, but it makes editing page harder, customizing of order/formatting of entries impossible and makes harder to mention tags specific to a given object. It is also dubious whatever mentioning for example website=* for every single object is even useful - every single object may have website, is it actually useful to keep mentioning it?

Automatic tables

(To show the usage of related values and link to them)

LOADING TAG LIST... (If you do not see this tag list, you need to enable JavaScript)
This table is auto-generated. See Template:Taglist for a documentation on it.

Automatic galleries

To give examples for different values of the tag or key. Note that galleries should be used only in cases where it is actually useful and adds information. OSM Wiki is not a place to collect pretty images on various topics. See for example Tag:surface=paving_stones page where gallery is used to confirm that various paving stones are using the same main tag. On the other hand adding gallery of beautiful cities to Tag:place=city would not be a helpful edit as it would not help in using this tag.

Add or remove default sort keys

The {{DEFAULTSORT:sortkey}} directive changes the order that pages are displayed in wiki categories (but not the text of the link).

Default sort keys that can be used

A default sort key can be used if there is an accented letter or letters in the title of the page, to sort ignoring the accent rather than at the end of the alphabet. If the page has a genuinely distinct sort key add the |defaultsort = no parameter to the {{Languages}} template (not needed for the JA: namespace where it is implicit because almost all pages whose title has been translated to Japanese need a different sortkey by transliterating the title to phonetic kanas rather than the orthographic title).

Default sort keys to be avoided (sometimes)

Mediawiki automatically ignores namespaces known to this wiki installation when it sorts categories. In addition, the {{Languages}} template adds a default sort key consisting of the page name without the language prefix. You shouldn’t put a redundant {{DEFAULTSORT:sortkey}} statement that is the same as the page name because it breaks category sorting if the page is ever moved or the markup is copied into a translation with a different name so it is worth removing if there is one. An actual example was the category Category:ES:Buildings which was moved to Category:ES:Edificios but was still sorted under B in categories. On the opposite, you'll need a different sort key when the default one computed cannot work reliably (for example if there are some accents in the translated name, breaking the sort order: all sort keys are made to be adjustable according to the rules of the language in which the page is written: removing sort keys is not a solution when in fact you must change them for another one, which is not simply the same as the page name, even if the language code prefix is dropped).


There are multiple issues related to links that can use fixing. When fixing links, it is generally a good idea to not edit talk or user pages. Even if they contain links that can be updated or removed.

Dead ends

Special:DeadendPages lists pages which are a dead end - they do not link to any other wiki page! Wiki pages should be well linked (Wiki guidelines#Linking). As every page should start with a few sentences introducing the topic in broad terms, it is often possible to drop in some links to related concepts there. Dead end pages may be completely missing an introduction, so you need to figure out what the page is about in order to write a sentence or two including links. There is no prioritization of this task.

Internal links

Many pages still refer to pages describing services that are no longer available. Versions of the Main Page, Map features and Beginners' guide in some languages do this. Some of these make sense for the historical record but many are misleading.

External links

Some links point to services that are now offline. weblink search

Protocol-relative URLs

Some OSM websites are now available with  HTTP Secure. Links to these sites should be changed to protocol-relative, beginning with // instead of http://, for instance // Note that they must be enclosed with [ ]. Protocol-relative URLs should not be used when the site cannot be accessed with https or provokes a warning message from browsers. Links to these sites can be changed:

  • (links)
  • (links), some can be changed to internal links or {{fullurl:}}
  • (links)


Creating categories

Special:WantedCategories lists categories which are in use, but where the category page has not been created with a description. The list is ordered by how many pages are using the category. For categories with 5 or more members, it would seem sensible to create a category page. To do this you will need to write a few clear sentences explaining what the category is. Often these most wanted categories are caused by use of a template, so you may need to understand what the template represents. This investigation may reveal that a template is in fact not sensible, or needs redesigning, so a different solution presents itself. This will also present an opportunity to choose a different name for the category before you create the category page.

Adding category to pages

Many articles need the associated categories added to them.

Mobile applications

Considerable cleanup effort has already gone into the documentation of mobile apps, the root of which can be found at Software/Mobile. The pages per operating system there (particularly Android and iOS) have long lists of apps with a wiki page per app. This is good way to organise this, giving plenty of space for developers and users to share ideas and describe apps from an OpenStreetMap perspective, but some of these pages remain as unloved stubs.

Basic placeholder description

In accordance with Wiki guidelines#Introduction, ensure every app page has at least a single sentence in the main part of the wiki page. This might simply state "'''name of app''' is an [[Android]] app {{stub}}". This is better than no content at all.

Features description

Going beyond this, write a description of the app based on a quick look at the website and try to figure out the most interesting features from an OpenStreetMap perspective. Going beyond that you might install the app on your phone, and try to figure out exactly how you make use of the relevant features (How do you get to see OpenStreetmap? How do you record tracks/add bugs/make edits) and upload some screenshots. Ideally the app developer themselves would do some of this, but in many cases the app developer is unaware of, or not interested in being involved in the OpenStreetMap wiki. Descriptions on our wiki should generally be positive. We always like people building OpenStreetMap apps even if they're not well polished! (Go give them good appstore reviews for the same reason!) However we should probably stop short of copying sales pitches stuffed with weasel words from their websites, and we can flag "limitations" of the apps in our wiki pages, particularly if this is done in the spirit of feedback encouraging developers to make improvements. Going beyond this, there are lots of basic defining features of apps, the details of which are captured in the templates on the right (to feed into the summary tables). That's working well. The information should also be written out in a slightly more longhand way in the page content itself.

References to defunct services and software

See also Category:Discontinued software

General page maintenance

Beginners' guide

A full list of subcategories of issues is available in Category:Cleanup. The top three priorities are to:

A few german users started to refactor the guide from scratch. It's bad that this will exclude international folks from the very first start, but hey someone is doing the job and I will try to assist and keeping an eye on the I18n aspects :) Please see DE talk:Beginners' guide --!i! This user is member of the wiki team of OSM 14:37, 26 January 2013 (UTC)
I restructured the page and moved out the content describing the various applications of OSM. I left the content giving instructions on how to use OSM by oneself, but there was actually not much such content. There is much more instructive pages in this wiki which could be made accessible by Using OpenStreetMap. --Cantho (talk) 04:02, 5 February 2014 (UTC)
I started cleaning up the guide. See Talk:Beginners'_guide#Guide_2017_cleanup. -- SwiftFast (talk) 07:53, 2 May 2017 (UTC)

Historical content

Since the start of the project, a lot of information were entered into this wiki. Some of it is outdated and can be safely removed, but other information still has some relevance. Examples include imports, proposals, and software with impact to OpenStreetMap. Such content is archived in the wiki which means that it is still there but clearly marked as historical.

Import information usually does not need any special handling. The documentation provides some information about the start and the end and since there are no continuous imports, one can conclude if the import is still ongoing.

Proposals are usually also dated but readers tend to overlook such information and confuse a proposal with the current tagging practice. To avoid confusion and unintentional tagging, proposals are archived.

Lastly, there are a variety of pages that contain historical content only. Examples include Yahoo! Aerial Imagery and API v0.3. In those cases, the whole page is marked as a historical artifact. This is done as follows:

{{Historic artifact start
 | about = What is the page about?
 | impact = How did this content impact OpenStreetMap?
 | reason_historic = Why is it considered historic?
 | capture = When was the content below updated for the last time?

Public transport

OpenStreetMap in the Media

Other Stuff

February 2011 (UTC)

Completed tasks

A partial list of completed tasks can be found at WikiProject Cleanup/Completed tasks, while many other cleanup tasks go unrecorded. If you have helped in the past, thank you!