MapOSMatic

By far the most important feature request we got, and the one we also consider the most important is to get world-wide support in MapOSMatic, and not only support for France. A large number of people volunteered to help us in translating and adapting the necessary parts of MapOSMatic. However, at the moment, we haven’t reached the point where the issue is on country-specific adaptations and translations.

Two weeks ago, David Decotigny started the import of planet.osm.bz2 into a new PostgreSQL database, so that we could start experimenting world-wide support. The import took around 4-5 days, and completed with a 75 GB PostgreSQL database.

Then, David worked on getting daily diffs applied to the database, so that we can keep it up-to-date with the contributions made on OpenStreetMap. Unfortunately, applying each daily diff takes around 9 hours on our server, which means that 9 hours per day, our server would be busy updating the database, something we don’t consider sustainable. Moreover, we tried to use MapOSMatic concurrently with the daily diff update and it did not work. See David’s email on the MapOSMatic list for further details.

At the moment, we are considering two solutions :

• Having two servers, used alternatively. But that means paying two dedicated servers all year long, which cost quite a lot for a non-profit project like MapOSMatic, and is quite annoying to maintain.
• Understand why the daily diff application process with osm2pgsql is so slow, and see if optimizations are possible. These optimizations would benefit to the entire OpenStreetMap community by allowing more people to play with OpenStreetMap data. Anyone having some PostgreSQL optimizations skills and some free time would definitely help in this area. I think we can provide an access to the server and database for testing purposes to motivated people.

Until this issue has been solved, we unfortunately won’t really be able to start with adding country selection support in MapOSMatic. Some people suggested to restrict ourselves to Europe, but Europe is only a third (in size) of the whole world, and no diffs are provided for Europe (even though they could probably be generated using osmosis). And getting to the whole world is more exciting !

Since the public announcement of MapOSMatic that took place on September 10th, we did a small number of improvements :

• Due to the very high number of rendering requests we had on the announcement day, we had to implement a redirection mechanism. This redirection mechanism redirects the user to an existing rendering when such a rendering already exists for the given administrative city. Of course, this mechanism does not apply to bounding box renderings
• Add a check to make sure that the given bounding box was more or less in France. We had a small number of renderings done on an area outside of France, and the result was obviously empty, since our database is only loaded with OSM data for France at the moment. The check is not perfect (France is not exactly rectangular) but at least prevents rendering requests in Turkey or in the US
• Improve the log messages we got from the rendering daemon, so that failed renderings can be investigated
• Fix a bug that was causing some of the failed rendering, when the user selected an administrative city and finally decided to fall back to bounding box selection before validating the rendering
• Fix the bug that was causing most of the rendering problems, which was due to a not-robust-enough code to compute the city area. The current code still isn’t perfect (there are really strange unclosed city areas), but at least the renderings do not fail anymore

We’ve also received a large number of very interesting proposals and bug reports, don’t hesitate to join us to improve MapOSMatic !

Welcome to news.maposmatic.org, the news pages for MapOSMatic !

Please also visit wiki.maposmatic.org for documentation, info, and stuff !