Things To Do
|It has been proposed that this page be deleted or replaced by a redirect. (Discuss)|
|This article or section may contain out-of-date information. The information is no longer correct, or no longer has relevance.
If you know about the current state of affairs, please help keep everyone informed by updating this information. (Discussion)
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)
- 1 System Overview
- 2 Things To Do with the Main Website
- 3 Things To Do with the Data
- 4 Things To Do with the Database
- 5 Things To Do with Map Displays in general
- 6 Things To Do with Mapnik
- 7 Things To Do with the JOSM editor
- 8 Things To Do with Potlatch
- 9 Things To Do with other editors
- 10 Things To Do with routing
- 11 Community Communications
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.
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)
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"> ... </g>
Additionally, it would be nice to clip all the SVG paths to fit the selected area. See also
Task: 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
- Nominatim#Reverse Geocoding / Address lookup does this.
- http://global.mapit.mysociety.org is another service doing similar
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.
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
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.
- 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: http://www.lenz-online.de/osm
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
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 http://potlatchosm.wordpress.com/2010/03/19/potlatch-2-vector-background-layers/ and http://old.opengeodata.org/2009/11/30/introducing-a-new-osm-editor-potlatch-2/index.html for further details.
Things To Do with other editors
Things To Do with routing
- Generate route altitude profiles using SRTM data --Sjors 08:45, 1 May 2008 (UTC)
- Routable Garmin maps -- this involves mostly reverse engineering the format more completely, then updating Mkgmap
- Implement a faster map-rendering for Traveling Salesman
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
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