Things To Do

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Things To Do
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Baso Minangkabau · bosanski · brezhoneg · català · čeština · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · português do Brasil · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 吴语 · 粵語 · 中文(繁體)‎ · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް

This page is aimed at people with programming skills who are (relatively) new to OSM. We will try to give you an overview where we stand on various technology "fronts", what our current issues are, and how you might be able to help.

Note that in addition to the more general tasks listed here, there are always lots of bugs, issues, and enhancement requests for current software in our trac Bugtracker, which you're welcome to work on. See Accounts if you need an account to commit changes to trac.

See also Develop for a collection of developer resources in this Wiki.

See Top Ten Tasks for a high priority which development tasks which will really help the project (but which often require more working knowledge of OSM)

System Overview

Main article "Component overview"

At the (technological) heart of the OSM project is the database server running PostgreSQL, and the Protocol interface implemented in Ruby on Rails; An API through which applications can read and write data. Direct SQL access is not provided, but in regular intervals a Planet.osm dump of the current (not historical) data is created for read-only access.

Maps are usually displayed using the "slippy map" technique, where pre-rendered 256×256 pixel bitmaps are placed alongside each other using JavaScript (OpenLayers framework) to make a nice-looking, zoomable and pannable map. Tiles are rendered for zoom levels 0 (one tile covers the whole world) to 17 (world covered by 417 tiles). We have two major renderers — a fast, database-backed C solution named Mapnik and a distributed, community rendering effort called Tiles@Home which uses a set of XSLTs called Osmarender. Each of them has certain strengths and weaknesses. There are also export scripts for generating Garmin maps or creating PostScript directly, as well as some scripts that do fancy stuff with pre-rendered tiles.

Our two main editors are an offline Java editor named JOSM, for which lots of "third party" plugins are available and which most people are using for intensive data work, and Potlatch, which works on-line and is a very user-friendly Flash application aimed primarily at the casual mapper. There are other editors as well, plus a multitude of import scripts for various data sources.

Project co-ordination and documentation is done by the Wiki you're reading, plus a "trac"/SVN system for source version control and trouble ticket management. In addition to that, we have a number of mailing lists. A large portion of "insider discussion" is also going on IRC, where many core developers hang out. (See Contact)

The project has no programming language preference. All major scripting languages — Perl, Python, Ruby, JavaScript — as well as Java and C are all heavily used. Being "open" we of course lean towards languages that match the philosophy but we're not religious about it. (So if you want to do cool stuff in Visual Basic, go ahead!)

Things To Do with the Main Website

Task: SVG Export

If you try to use the front page Export feature to get SVG and use it in Inkscape, it would be more convenient to have the SVG image divided into layers such as "Buildings", "Water", "Forest", "III. class roads" to enable the user to change its style. This requires to change mapnik to put all similar map features into following structure:

<g inkscape:label="Buildings" inkscape:groupmode="layer" id="Buildings">

Additionally, it would be nice to clip all the SVG paths to fit the selected area. See also

Task: Exporting to Adobe Illustrator

Add an option to the 'Export' feature on the front page to download an Adobe Illustrator file (.ai), see Exporting to Adobe Illustrator.

Things To Do with the Data

What country is something in?

Quite a lot of OSM data needs to be interpreted in context. highway=trunk, for example, will have a different default speed limit in the UK than it will in France.

To aid processing of this data, we need a library/webservice that (given a lat/long) uses OSM data to find out, at least, which country it's in. (Ideally, it should cope with other administrative units, e.g. county, city.)

People who are working on this: roland.olbricht

solved problem?

Things To Do with the Database

Task: Satellite API Instances

The ability to have an offline instance of the database and API, able to resync/replicate (2-way) with the main database.

See Satellite API Instances

Task: Tree of Areas

Determine all closed areas from the database, then form a tree of areas contained in each other. For example: Europe > Germany > North Rhine Westfalia > Cologne Autotag GPX tracks with this hierarchy.

(hope you don't mind I edited this page directly)

I have written a GMaps API wrapper in PHP for a recent project, which returns structured hierarchical data about political areas and populates a database with it, including id, name, lat/long, post code number etc. There is a standard called xAL (eXtensible Address Language), which has been inclued as XML namespace into KML. So - hmm - I think the names (probably not the lat/long's) are public domain. One other thing is: We should use the name in the main language of the parent country - "Nordrhein-Westfalen" instead of "North Rhine Westfalia". GMaps API results depend on your Browsers language. So it's the best case to use the language of the country. At first we have to discuss the basics, then we (hope I get some helpers) can start to fill the database.

Task: Split multiple GPX tracks

There are areas where I can hardly see the GPX track which I uploaded because the area is covered by hundreds of long straight GPX lines. I suppose they are created by multiple GPX tracks. If I record a track in London and continue later in Paris, there will be a line from London to Paris. A small piece of software should be able to check GPX tracks and if a distance between two points is much bigger than the distances between the neighbour points, the track should be divided.

Things To Do with Map Displays in general

POI layers

The ever-growing list of Map Features inevitably creates a clamour for these details to be rendered on the map. However, rendering absolutely everything is the enemy of good cartography, and will result in a map that looks like a bollocks.

At the same time, there are those who believe the POIs we do show (e.g. pubs) detract from the main purpose of the map and make it unusable in some circumstances.

One answer is for POIs (Points of Interest) not to be included in the default cartography. Instead, they would be available in layers that the user could turn on and off.

Relevant skills:

  • OpenLayers (the JavaScript behind our slippy map)
  • Rails coding
  • Potentially, some PostgresSQL knowledge (should this be integrated with the osm2pgsql/Mapnik cycle?)
  • Awareness of performance issues (if done badly, this could utterly boggle any server)
  • Some design knowledge might be helpful, but not essential - there are already some good icons in SVN (in particular, the superb svg-twotone set)

Future refinements could include collision avoidance (so two POIs don't appear at the same spot) but this wouldn't be necessary for a first release.

see already made solution here:

Other suggestions

Feature proposal: Renderer (software) which produces an animated map (fly over). Output shall be DirectX/OpenGL or a video file (MPEG, AVI, ...). OpenGL is preferrable for its cross platform appeal. Glosm and others, Vector_tiles#WebGL

Feature proposal: A way to navigate a program as proposed above by positioning a handheld device: The view should be as if it was a camera above a map, in that position. (Something written in german about this idea is on this userpage.)

Feature proposal: Speech bubbles like Google Maps, i.e. click on an icon (e.g. church) an you get a bubble with additional information. Probably requires new tags to store that information.

Feature proposal: Search the SRTM data for southeast slopes to create a shading layer. This might be included as bottom layer to maps giving the user an idea about the surface shape.

Feature proposal: Add a scale line on the border of the map, to provide a mean of visually estimate distances

Things To Do with Mapnik

Things To Do with the JOSM editor

JOSM is our Java-based offline editor. JOSM has its own trac and SVN system where you'll find a number of bugs and enhancement requests. Generally, JOSM follows the policy to put as much functionality as possible in plugins, and provides a very clear and open interface making the development of plugins easy.

Things To Do with Potlatch

Potlatch C Extensions

Unlike the rest of the OpenStreetMap API, which uses XML, Potlatch communicates with the server using two binary formats: AMF (Actionscript Message Format), for ways and nodes, and SWF (ShockWave Flash), for GPS tracks.

This has several advantages: reduced bandwidth (they are compact formats), improved performance and simpler coding.

At present, the binary formats are packed by the pure Ruby controllers, amf_controller.rb and swf_controller.rb. But since Ruby's string handling is not the fastest, it may be possible to further improve performance by creating new Ruby extensions in C, which the controllers would use to pack the data.

(Note that there are already AMF and SWF-writing libraries in existence — WebORB for Rails, and Ming, respectively — but both implement a far greater set of features than is needed for OSM, and may also have licence/installation issues in an OSM context.)

Skills required: Knowledge of C and Ruby extensions.

One might start with... The existing code for amf_controller.rb and swf_controller.rb will illustrate what is required.

Whom to talk to: Richard is a Potlatch developer and knows most about the internals of the two formats. Tom Hughes is a sysadmin and has already written a C extension for another part of the site (quadtiles).

People who are working on this: rdittrich

ActionScript 3

Ultimately Potlatch should probably move from its current ActionScript 1 to ActionScript 3 (although haXe might also be a contender...). The rewrite would be a pretty huge task to take on single-handed but might be achievable with several developers working in tandem.

Work has begun on this project in the form of Potlatch 2.0; Please see and for further details.

Things To Do with other editors

Things To Do with routing

Community Communications

Beginners' documentation

OSM beginners' documentation is unfocused, cluttered, and outdated. The existing Beginners' Guide wholly concentrates on JOSM, which is to some extent teaching people to run before they can walk, and is arranged in an unfriendly, hard-to-navigate hierarchy which makes it difficult to print or follow. Improved documentation could be written on the wiki but could also be done in conjunction with editor developers, so that it can be presented contextually.

Overall Wiki Maintenance

Main article: WikiProject Cleanup

A lot of people have got involved editing the wiki, and putting it to various uses. That makes it a successful wiki on the one hand, but also rather a dire mess on the other. WikiProject Cleanup is a project to tidy up, and move towards a more coherent organisation (while recognising that a wiki will always be a little bit chaotic)

The wiki way is to "be bold", get stuck in and make the improvements, although some of the major restructuring that is necessary will also have the potential to upset people who have strong ideas of their own.

Please do feel free to "be bold". We don't need to use this page to nominate somebody who is "in charge" of the wiki content. People who make consistently good wiki edits, and show respect for other people's work will gradually become more "in charge" in so far as they gain trust and respect, which will allow them to make more sweeping changes. That's the way a wiki community works. Note that this means you shouldn't dive in and immediately start renaming wiki pages here there and everywhere. (See Wiki Help#Some general guidelines)

Wiki clean-up should also be a collaborative process. Please read the WikiProject Cleanup page, and join in with the related discussions.

You might also gain some kudos for figuring out nifty uses for templates, parser functions and other "state-of-the-art" MediaWiki features to solve some wiki problems. On the other hand features such as templates can be over-used (this page is perhaps an example of that!) While they can be used to good effect, this must be balanced against the consideration that they almost always make wiki editing less simplistic, which is bad for wiki newbies.

If you have ideas for technical improvements to the wiki (beyond the wiki editing which anyone can carry out) e.g. extensions to install, take a look at Wiki#Technical Wiki Details

Mapping Guidance

Many many questions on the mailing lists are about "how do I map this-and-that". The Wiki does have lots of information about that, mainly on the Map Features page, but often it is out of sync with today's reality, and it does not provide enough guidance. OSM is free and open and all, and everybody can tag anything they want, but most mappers really want to be taken by the hand and told how exactly to map what they see on the ground to achieve the best rendering results — a sort of "best practices", with tips for complex road junctions and all that.

Many people use the Proposed Features page and discussions linked from there to explain how they are currently mapping certain real-world situations, and in fact standards may be created on these pages without every finding their way into the main Map Features page.

So this area is something that definitely needs a hand to sort through it all and tell our new mappers how to get the most out of their work.

Skills required: This task could ideally be done by someone with some mapping experience and/or exposure to new mappers, as he or she will know the important issues first-hand.

One might start with... A first try for complex junctions with pictures got posted on the OSM forum.

Whom to talk to:

There are no takers yet for this task. Click on the "edit" link at the top of this task description and add your Wiki username to the "takers=" field if you want to start working on this task!

Machine Readable Feature List

People are developing tools to make mapping easier. Many of these tools need to know which tags are "allowed" (everything is allowed, strictly speaking, but you will normally want to use the same tags everybody uses), and whether they apply to nodes or ways, and maybe even what their common misspellings are. Currently, all these tools — for example Maplint, the Validator Plugin for JOSM, or the prefabricated JOSM application preferences (dropdown boxes) — have their own lists compiled by the respective authors. It may be worthwile to examine ways to extract a machine-readable list of tags from the Wiki, making the Wiki the authoritative source on commonly used tags and values.

Skills required: This task would probably require considerable MediaWiki experience and maybe also some scripting (a.k.a. Bot), but you do not have to be an OSM insider to go about that.

One might start with... You would best start by identifying and contacting the people currently keeping lists of allowed tags and values, and inquire about their requirements and whether they would be happy to use an auto-generated list from the Wiki.

Update: The maplint test not-in-map_features is auto-generated from the wiki by a Perl script. It might be a good idea to factor out the wiki-parsing from the maplint-xslt-generator into a separate module though.

Whom to talk to:

People who are working on this: See: Machine-readable_Map_Feature_list