Although I haven’t done much on mod_tile recently, I am currently the maintainer of the project (for a lack of anyone else). So I would be very much interested in working with you to get this done.

Changing the format of the config file is an interesting question. The current one is definately rather limited and particularly with respect to the (nested) storage backends is limiting and lacking. So moving to a more expressive / hierarchical format is possibly a good idea. A json or yaml format would probably be the way to go in that case as that seems to be what most people use these days. On the otherhand, that would break backwards compatibility and people would have to re-write their config files in order to upgrade.

Nevertheless, at this point it might be worth doing it though, particularly if the config file could automatically be upgraded.

With regard to which library to use, I am not sure. I haven’t looked at any other ones and which are advantages and disadvantages they have.

Given it is a fairly small and simple piece of functionallity, using an “as standard library” as possible would be good to ensure it isn’t hard to install that dependency on most platforms.

I would love to see mod_tile in debian as well and I think it would be very useful to make it easier for people to install their own tileserver.

I have done something like you suggest for Ubuntu in my PPA, but it doesn’t fulfill the more stringent criteria of getting it into the official repositories. Partly it was due to the fact that the package install scripts did too much magic to simplify the standard set up, but yes the issue with iniparser also remains an issue to get it into debian. As I understand debian doesn’t want to include a iniparser package in its repository, iniparser would have to be replaced with something else in mod_tile/renderd.

Would this be something you are willing to help with? That would be great!

Even though “diversity” might not explicitly be mentioned in the documents, I believe that diversity has always been a core defining principal of OpenStreetMap and the wish to have an appeal to as broad a community as possible.

It starts with the decision to use a free form textual tagging system to describe the semantics of the data. By using this instead of the more traditional fixed form attributes, the system was from the get go designed to make sure it can cater for all diverse interests and that there are no limitations to expanding to new diverse usecases and interestes. For the same reason, OSM has no approval process for new tags and anyone can just start using the tags. Not even a democratic approval process could guarantee this same form of diversity, as 51% of the community could otherwise prevent expansion to more diverse uses. This decision has caused OSM quite a bit of greaf and there have been a number of initiatives to try and lock down tagging . But the principle of free tagging and the chance of diversity has always been upheld with the strongest of support!

Another key aspect in the structure to support diversity is that OSMF was set up to be as weak as possible, explicitly stating it should “support but not control” the community to ensure that there is no central organisation that could stifle diversity by pushing things in a specific direction. Anyone can do pretty much anything, what ever their background, what ever their interests. Furthermore, it has also always been a core belief to try and divest everything down to the local level as much as possible, to respect cultural and regional diversity.

So imho both on the technical and organisational level OSM has done a huge amount from the get go to ensure diversity and that no group or use case is excluded or discriminated against. The principal of diversity has and always will be one of OSMs defining principles and its key to success.

However, OSM as a project has a very “libertarian” view of diversity (do-ocracy). There is no pro-active drive towards diversity and it is up to the “minorities” to engage in the project. This is perhaps why OSM might not have been as successful on the third level, the social level, to achieve the dirversity it was set-up to cater for.

In short all of the pre-requisits for supporting huge diversity are imho there, what it needs are more passionate volunteers to help in active outreach programs to draw in new diverse members of the community.

You can export the notes in a bounding box in various formats via the API. Hopefully one of them (e.g. gpx format) should be usable by your devices.

To do this you need to use the following URL:

http://api.openstreetmap.org/api/0.6/notes?bbox=0.1,0.1,0.2,0.2

with the bbox= parameters adjusted to represent the area you want to export from.

If you want to export it in gpx format, then use the following URL: http://api.openstreetmap.org/api/0.6/notes.gpx?bbox=0.1,0.1,0.2,0.2

http://api.openstreetmap.org/api/0.6/notes.json?bbox=0.1,0.1,0.2,0.2

if you want the notes in json format

As always, one can interpret statistics in different ways… ;-)

If one assumes a roughly linear scaling, and Germany currently adds around 1% of addresses in 3 months, then it will still take about 20 years to add all addresses! And this is in Germany which is by far the most active community on a larger scale. Other countries aren’t doing nearly as well.

So one can probably uses those numbers quite convincingly to argue for address imports where there are good sources available. ;-)

Nevertheless, it is good to see that there is progress being made on the topic. One way or the other

What happens to cars that enter into a oneway street that has noexit? Either you are allowed to drive in both directions (in which case the oneway tag would be wrong), there is a valid exit, or you are not allowed to drive into that road at all. (Or the traffic planner in your city is mad and/or has a hatred for cars… ;-))

Wikipedia show boundary outlines of geocoded objects in their articles. They use the OSM data for this through the WIWOSM project ( http://wiki.openstreetmap.org/wiki/WIWOSM )

To see it, you go to a geocoded article like https://en.wikipedia.org/wiki/Hamburg and then click on the globe in the upper right hand corner, at which point you should see a red polygon highlighting the extent (boundary) of an object.

If you go to e.g. the german Wikipedia, it is even shown on the familiar mapnik map.

For this to work, however, you need to add the wikipedia tag to the osm object, which is also now used in nominatim to determine the importance / ranking of search results.

Unfortunately due to technical problems the wikipedia-osm db is a bit (roughly a month) out of date, but hopefully soon, it should be updated daily again.

10% for MOBAC might not sound that much, but then take 5 of those apps (e.g. NaviComputer, OpenMaps,...) and you are already at 50% of total traffic. Also don't forget, it is only that low because of all the throttling mechanisms that are already in place.

Of cause, it would be nice to offer more tiles to various mobil apps, as it is one of the main ways for people to use and benefit from OSM, however, it is just not feasible with the current hosting and donations.

The admins have already been fairly lenient with what they allow and have pushed the possibilities to a maximum by only starting to block scrapers when it became necessary due to resource constraints.

As we are more and more hitting these limits, we need to find more sustainable ways to use to use the data without inconveniencing the end users. But hopefully new apps will be developed to meet those needs.

Good PR work is imho quite essential for the growth of OSM communities and whether the community has succeeded in getting good press coverage can perhaps be an important determining factor in its success in getting the critical mass. Currently press coverage is rather lob sided towards a few countries ( http://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media ). If the CWG (or any other group) could help increase press coverage, that would be great.

With respect to Wikipedia, I also think there is a lot of potential in a collaboration with them, helping both projects out. The buy-in from wikipedians however, seems to differ substantially by country. If you go to e.g the geohack on the German Wikipedia, you will see that OSM is the top entry there. More over, if you go to a geolocated article on the German Wikipedia (e.g. http://de.wikipedia.org/wiki/London ), you will see a link "Karte" in the top left corner. If clicked, an OpenStreetMap map will appear directly embedded in the Article. The same is true for the Russian Wikipedia, the Italian one and a few others. Other language wikipedia's could easily activate this feature too (http://de.wikipedia.org/wiki/Hilfe:OpenStreetMap/en) if they have local support. I think there are plans to enable this in the en-wiki as well, but it would likely need to move off of their toolserver and onto their production cluster.

There are thoughts to move the integration of OSM into wikipedia further than just tiles, but as with most volunteer efforts, they too have limits to software developers and admins to devote to this, which means things progress slower than one might hope. Already the wikipedia toolserver with its OSM rendering database has been quite successful in allowing more people to create their own thematic stylesheets. However, dealing with 100s of stylesheets isn't trivial so things haven't always been entirely smooth.

Es sollte eigentlich auf dem Nokia 5800 funktionieren. Welches .jar file hast du denn verwendet? Funktioniert eine der vorkonfiguriereten Karten auf http://apmon.dev.openstreetmap.org/GpsMid/index.shtml ?

Das Programm GpsMid ( http://gpsmid.sourceforge.net/ ) sollte das koennen und funktioniert auf dem Nokia 5800.

Zum einen kann man damit "Wegpunkte" abspeichern die man dann anschliessend in OSM einpflegen kann.

Zum anderen beherscht GpsMid aber auch das direkte hochladen von POIs nach OpenStreetMap (so lange man die online version von GpsMid verwendet und die editier funktion einkompiliert hat) wobei es dafuer einer Internetverbindung auf dem Handy bedarf.

It should be back now after maintenance and hopefully nice and speedy again.

An initial attempt was made a while ago [1] to port OSB to the rails_code, but it was never finished or functional and development in it is currently dormant. So if anyone wants to pick up the code [2] and finish it (or indeed start from scratch), I am sure a lot of people would be very happy and hopefully some would be willing to help along with specific problems.

A PHP script with a MySQL backend on a third-party server would also not be totally impossible, if done well and as long as the frontend is written in rails. After all Namefinder and Nominatim work(ed) like that. But such a solution would be harder to convince the admins to deploy as it would mean more administrative trouble, which unfortunately is already somewhat of a limiting factor.

[1] http://openstreetbugs.dev.openstreetmap.org/
[2] http://git.openstreetmap.org/rails.git/shortlog/refs/heads/openstreetbugs

Es gibt noch zusaetzlich einen automatischen "Platform status" auf http://toolserver.org/~apmon/OSM_healthoutput_current.txt welcher auf einem anderen Server liegt.

Der Zusammenhang zwischen Tiles und Wiki ist, das beide durch den gleichen (reverse) Proxyserver laufen. Dieser ist glaube ich wegen ueberlastung ausgefallen, ich weis aber auch nicht wirklich genaueres.

@Harry. Depending on what you do, it isn't all that bad to write a very basic editor. For example I created a basic POI collector into GpsMid quite quickly. You basically just need to (de)serialise a bit of XML and send it to a website. You can also get and send individual objects to the API. And as long as the API still supports basic HTTP auth, that part isn't difficult either.

However, you should be well aware of what limitations such a simple editor might have and what problems it may cause if it doesn't support the full complexity of the OSM data.

The OSM inspector routing layer started as Germany only sometime in March I think and was extended to cover the EU in early September ( http://neis-one.org/2010/09/19/routing-view-eu-2010-09/ )

Unfortunately it seems according to current statistics ( http://neis-one.org/2010/11/16/routing-view-eu-2010-11/ ) the UK is the buggiest country in this respect, with only a few bugs fixed since the launch of the routing view.

That is despite with Apps like Skobbler, NavFree, MapFactor, MapDroyd and several others, there are now hundres of thousands of unsuspecting people in the UK alone actually using OSM data for routing! (at least if you believe claims from those companies) A bit scary to be honest... ;-)

Given that imho a full out Front Page redesign is unlikely to happen in the next year or two, I am not sure if liking new features to this is the best idea, for either cause...

Regarding routability: Given that most data in the US is imported it might not be such an issue there, but in Europe connectivity seems to be somewhat problematic. OSM inspector routing view is quite a nice tool to spot these errors ( http://tools.geofabrik.de/osmi/?view=routing&lon=-1.79370&lat=52.26412&zoom=7 ). Unfortunately it is currently only available for Europe, so perhaps MapQuest could host a world wide version of it?

However, more than actual bugs, imho routing suffers from lack of data and particularly addition of specific routing related tagging like maxspeed and turn restrictions. So to improve the data, more people would need to care about these tags, rather than "just" having good tools to spot problems.

Perhaps the biggest incentive to ensure that the data is good for routing would be to include a routing engine into the OSM main page. Then people could, e.g. once they have added their village, try it out and see if they can route to the place they mapped and notice if it returns odd routes and fix it straight away.

So integrating something like http://nroets.dev.openstreetmap.org/demo/index.html?lat=51.51832&lon=-0.11715&zoom=16&layers=B000FTFTTT&v=motorcar&adj=recommended&markers=!51.51511%2C-0.1193!51.51816%2C-0.11535 and exposing a lot more people to routing with OSM data would hopefully be a big step forward in ensuring high data quality for routing!

As lyx sais, generally the name tag is in the local language, so for Qatar presumably in Arabic. Adding the name:en tags in addition would be great though as it allows for map rendering in various languages like the wikimedia example http://toolserver.org/~osm/locale/ that allows you to switch between the different languages.

Reaching out to other members of the community can sometimes be a bit difficult if there is no mailinglist or forum yet, although you can always ask to create a new one.

Otherwise, (depending on your motivation and time... ;-)) you might be able to try and recruit new mappers in the area. For example it is sometimes possible to write a small article about OSM in a local newspaper, or specialist magazine that might have an interest in OSM, such as a cycling magazine, a tech blog or the expat newsletter.

Oh, silly html parsing. it cut of the <1m in the above comment. so lets try again:

Yes as mentioned, there are going to be some false positives, but my impression has been that the fast majority of the <1m reports one can be fairly confidant that they truely are bugs. For example http://tools.geofabrik.de/osmi/?view=routing&lon=-3.19580&lat=51.54010&zoom=15&overlays=unconnected_major1,unconnected_major2,unconnected_major5,unconnected_minor1,duplicate_ways it is quite clear that the mapper hadn't realised that ways need to be connected and it is imho quite safe to simple connect all of them without too much worry of false positives. But yes, in other areas it is not as clear, and one should always err on the side of caution.

@emj, Yes as mentioned, there are going to be some false positives, but my impression has been that the fast majority of the <1m reports, I'd be very confident that they are truely bugs. For example, if you look at http://tools.geofabrik.de/osmi/?view=routing&lon=-3.19580&lat=51.54010&zoom=15&overlays=unconnected_major1,unconnected_major2,unconnected_major5,unconnected_minor1,duplicate_ways it is kind of obvious that this person hadn't realised that ways need to be connected and one can simple connect them without too much worry about false positives.

@Pink Duck, yes it would be nice to be able to mark false positives, but it in a fully automatic reporting that gets rerun every day or so, it is hard to keep track of which errors belong to which "ignore". However, I think it supports the "noexit" tag on nodes for ways that aren't connected.