He:Things To Do

From OpenStreetMap Wiki
Jump to: navigation, search
שפות זמינות — 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.

סקירה מערכתית

Main article "Component overview"

At the (technological) heart of the OSM project is the database server running MySQL, 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 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!)

דברים שצריך לעשות באתר הראשי

משימה: תרגום

The Webpage is currently only usable by people who know English. But it should be possible to use it with other languages as well.

Skills required: ruby, php, know something about internationalisation (i18n) stuff

One might start with... Look at the svn how the webpage is created at the moment. Ruby support some "gettext" environments, which are easy to use by translators (.po .mo files, you can use kbabel under linux to translate it):

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!

Task: Export/Use tab

There has been much discussion about a new, fourth tab on the main site: Export or Use. This would allow users to easily download or use OpenStreetMap data in popular formats, such as:

  • our own .osm format
  • commonly-used interchange formats (e.g. .pdf, .jpg)
  • GIS formats (e.g. .shp)
  • vector illustration formats (e.g. Adobe Illustrator, .svg)
  • GPS formats (e.g. Garmin)

Much of the work to convert to these formats has been done but only exists in a disparate collection of scripts and libraries. It all needs to be in one, single place, ideally written in Ruby on Rails like the rest of the site. (to continue...)

Skills required:

One might start with... Anyone attempting this should first read the discussion on the mailing lists (subject "export tab") and then probably concentrate on one single and simple format as the first "proof of concept".

Whom to talk to: Changes to the main web site will ultimately go through the hands of Tom Hughes, and he has already done a bit of work on the main web site. Depending on the output format you want to generate, you might want to talk to the people having written existing export tools — for bitmaps generated from tiles, that would be OJW's MapOf or Frederik Ramm's Bigmap script. Vector formats would conceivably be created through 80n's Osmxapi as this has no bounding box size limits, but would also re-use code from existing conversion scripts.

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!

דברים שצריך לעשות עם נתונים

משימה: בדיקת עקביות הנתונים

The Openstreetmap data model currently consists of nodes, segments connecting the nodes, and ways making multiple segments into linear or planar features.

OpenStreetMap does not have strict value and consistency checks for data, which makes many things easier. However, a lot of rubbish accumulates in our database that nobody notices. If you can handle large XML files, you could do a a lot of analyses of the planet file, and find — among other things — segments with unneccessary tags, multiple nodes on the same spot, objects referencing deleted objects, multiple ways running on the same segment (e.g. one segment being used by a lot of ways at the same time), ways consisting of nodes that are only a few metres apart (often created through automatic imports), holes in coastlines, spelling errors in tags, and so on. All these could be determined automatically, but are not at the moment.

We already have some editor plugins (e.g. Validator) and rendering support (Maplint) in place, but these only cover a fraction of what was mentioned above and only make sense when somebody actually works on an area. What we could really use is some comprehensive analysis of the planet file alerting people to "buggy areas", or for some things we could even have automated fixing of things by a robot. Such actions would probably have to be backed by a bit of community decision-making in order not to break something.

Skills required: This task will require some experience in dealing with large amounts of data (you cannot just slurp the planet file into memory and hope to do XPath queries on it — it is too large for that), but other than that is very well suited even for an OSM beginner, and will provide you with a very good idea of what this is all about.

One might start with...

Whom to talk to: For more information/ideas about this task, contact User:Frederik Ramm.

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!

דברים שצריך לעשות עם בסיס הנתונים

דברים שצריך לעשות עם תצוגת המפה באופן כללי

Things To Do with Tiles@Home and osmarender

Osmarender is a renderer based on XSL transformations. An input XML file — containing OSM data — is piped through a complex set of transformations to arrive at an output XML file — containing an SVG vector map. This process requires, in theory, only an XSL transformator and something that can display SVG files. Firefox, for example, does both. So, again in theory, here would be an avenue to directly display OSM data without additional software requirements.

It doesn't work like that in real life for a number of reasons. Firstly, the Firefox implementation of XSLT and of SVG are both not good enough for Osmarender's requirements (nearly everybody uses xmlstarlet/xsltproc as the XSL processor and Inkscape for rendering the SVG files). Secondly, a number of helper programs have evolved around Osmarender which are meanwhile almost a requirement to achieve good-looking maps.

Instead of

OSM-Data → osmarender → SVG → inkscape → display

we now regularly use the tool chain

OSM-Data → close-areas.pl → Data-with-closed-areas → osmarender → SVG → lines2curves.pl → SVG-with-Beziercurves → inkscape or Batik → display

Read more about: close-areas.pl * lines2curves.pl

Osmarender is used as a stand-alone renderer as well as an integral part of tiles@home rendering, and for many has become synonym with tiles@home (you'll find people saying there is something wrong with tiles@home when in fact there is something wrong with osmarender, and vice versa).

Task: Osmarender Maintenance Second-in-Command

There is currently only one person in the whole universe of OSM contributors who understands Osmarender (this person is 80n, the original author) to a degree where he can actually make big changes. Most others are reasonably confident in introducing little layout changes, but would never dare to, say, do a complete overhaul of the way Osmarender uses stylesheets, or search for bugs.

One person being able to work with such an important piece of software is not enough — we all have other things to do from time to time, and it would be very good to spread the osmarender knowledge to a few more people who would actually be able to make complex changes to Osmarender when the need arises.

Skills required: יכול לעזור SVG כדי לעשות זאת. גם נסיון ב XSLTו XSLT ,XSLT צריך לדעת

One might start with... You would probably start by familiarizing yourself with the current Osmarender5 from SVN, generate a few maps, play with styles, maybe pick up some bugs (or find things that just don't look right all by yourself), fix them.

Whom to talk to: You should talk to 80n, who may be able to explain things to you, and who probably has some not-yet-finished ideas himself.

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!

Task: Unified Preprocessor

As described above, there's a number of helper programs doing one thing or another before or after Osmarender is run. There is a consensus that (a) there should be as little of these utilities as possible, and (b) any sort of postprocessing is less desirable than preprocessing (because postprocessors need to make assumptions about the kind of SVG data produced by osmarender, creating an unnecessary dependency).

It would be very nice to have one preprocessor that "does it all", to arrive at a toolchain like this

OSM-Data → preprocesor → polished OSM-Data → osmarender → SVG → inkscape → display

This preprocessor could combine all the extra steps listed above, and could perhaps also take on additional tasks currently handled inside osmarender (notably projection, i.e. the translation of lat/lon values to screen vector units; offloading this from osmarender would allow for a better precision and a choice of projections).

Skills required: This task of course requieres good Osmarender knowledge, and perhaps Perl, because some of the current utilities are done in Perl.

One might start with... Anyone doing this would first have to get a solid understanding of what the various tools do.

Whom to talk to: 80n has written Osmarender and Frollo. Frederik Ramm has done close-areas.pl. Barry Crabtree has done the Bezier Curve hinting.

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!

משימה: תיקון הטקסט

הוא הדרך שבא מטופלים שמות הרחובות Osmarender הדבר שבממש מגעיל במפות

כמו "שים את הטקסט הזה על הדרך הזאת עם הפונט הזה", והוא לא מקבל שום חיווי SVG רק יוצר הוראות Osmarender בגלל ש

לגבי גודל הגופן וכו', הוא לא יודע אם הטקסט יתאים לדרך ואם הוא ידרוס תוויות אחרות בקרבתו. התוצאה מגעילה, בעיקר במצבים בהם כביש מרובה נתיבים, או קצר, או מורכב מהרבה דרכים קצרות. זה משהו שממש צריך לפתור.

שמקצר או מסיר שמות רחובות "beautifier" שיצר את המעבד (Robert Hart) צעד קטן ראשון בכיוון נעשה ע"י רוברט הארט

אם הם יוצאים ארוכים מדי למקום הפנוי להם, אבל פתרון זה עדיין אינו מושלם דיו

. מה שיצריך כנראה פרויקט ענק חדשSVG לא בטוח שהבעיה פתירה בלי לכתוב ממש תוכנה שמממשת

Skills required: A lot of wizardry will probably be required.

One might start with... Start by looking at dense maps and you'll see everything that is wrong here.

Whom to talk to: 80n may have some ideas. Also talk to Robert Hart, look him up in the mailing list archives if there's no wiki page.

People who think this would be good: People who are working on this: gfonsecabr (I am implementing something based on: Frank Wagner and Alexander Wolf, "A Combinatorial Framework for Map Labeling".)

Task: Make tilesGen.pl Multiprocessor Capable

Currently the only way to get tilesAtHome use a multiprocessor/multicore machine effectively is starting multiple clients on one machine, which is not very efficient, to say the least.

Skills required: Perl knowledge, Perl threading and perhaps locking.

One might start with... Start by trying to run tilesAtHome in multiple instances on one machine and see things break.

Whom to talk to: Deelkar

People who think this would be good: People who are working on this: Jocelyn Jaubert

Mapnik דברים שצריך לעשות עם

JOSM דברים שצריך לעשות עם העורך

Java הוא העורך הלא-מקוון מבוסס ה JOSM

משלו, בהם תמצא דיווחים על באגים ובקשות שיפור SVN ו trac מערכות JOSM ל

(הרחבות) plugins היא, בדר"כ, לשים פונקציונליות רבה ככל האפשר ב JOSM המדיניות ב

ואספקת ממשק פתוח ברור ביותר כדי לאפשר פיתוח קל של הרחבות

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 Potlatch developer and knows most about the internals of the two formats. Tom Hughes is sysadmin and has already written a C extension for another part of the site (quadtiles).

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!

Things To Do with other editors

דברים שצריך לעשות עם הוויקי

תחזוקה כללית של הוויקי

Main article: WikiProject Cleanup

A lot of people have got involved editing the wiki, and putting it to various uses. That makes it a successfull 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 coherant 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 poeple'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 immediatly start renaming wiki pages here there and everywhere. (See Wiki Help#Some general guidelines)

Wiki cleanup 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#Ideas for technical improvements

הנחיות מיפוי

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 he wants, 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.

An attempt at a comprehensive guide to mapping has been made in Feature Index, but has been largely abandoned by its original author. Many people also 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:

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!