MapOSMatic

Maxime working on his TypeMatrix Dvorak keyboard, editing OCitySMap code with vim

We’re early in the morning of day 3 of this MapOSMatic hackfest, everybody is still asleep, so it’s time to do a little wrap-up on what has been done yesterday :

• Maxime and David have continued their work on refactoring the OCitySMap module and extending it to support the new level of map customization that we will offer. So far, the map generation is working again, together with the overlayed grid, with a much, much better Python code, that will hopefully allow us and other contributors, to add more features more easily than in the past. Today, they will continue their refactoring work with the street index generation.
• Gaël has continued and completed his work on the slippy map user experience improvements. The user now draws a rectangle to define the area to be rendered, and we immediately check whether the area is too big to be rendered by MapOSMatic.
• Éric has continued his experimentation of the ReportLab PDF library and its Platypus page layout engine, but finally came to the conclusion that while the automatic page layout engine is nice, it doesn’t provide enough control on the layout to generate a street index similar to the one we’re doing today.
• Pierre has worked on different small but important improvements:
  • in the page corresponding to a particular rendering, add a link to the corresponding location in OpenStreetMap so that an user can easily check the current status of a particular area
  • in the results provided by our Nominatim proxy, add information about the size of each administrative boundary. This will allow us to no longer limit the selection of administrative boundaries to level 8 boundaries while still preventing the user from rendering too large areas.
• I’ve worked on finishing the Map Creation Wizard that allows to select the different parameters for a map. It is now feature-complete, the code has been cleaned up, even though it still need some more polishing, especially on the presentation side, which will done later by Maxime, our CSS expert.

Last, but not least, the import of the planet database has completed on our new server that should start hosting the official MapOSMatic.org website in a couple of days or weeks. With a better CPU, two times the amount of RAM and four times the amount of disk of the previous server, it should provide a more scalable hosting solution for the coming months.

Today, work will continue with a first integration of the different improvements, the rest of the OCitySMap refactoring, experiments on Cairo for the booklet generation, improvements on the street index generation, experiments on rendering Wikipedia pages, final details on the wizard, and more.

Stay tuned for tomorrow updates !

Notes on new MapOSMatic features

As we announced during our talk at State Of The Map, we are currently having a hackfest during which we’ll try to improve MapOSMatic in various directions until Sunday. After a startup phase yesterday evening with the arrival of all participants and the preparation of working setups of MapOSMatic/OCitySMap, the hard work has started today.

We’ve spent the whole morning discussing the design of the improvements to MapOSMatic we’d like to implement during this hackfest. The following topics have been discussed :

• Better adaptation of MapOSMatic results to printed maps, in terms of format. To solve this, what we intend to do is that once the user has selected a geographic area (either from bounding box or through the name of an administrative boundary), we’ll offer a selection of suitable paper sizes, from a list of standard formats. Obviously, the range of paper formats available for a given area will be limited by the size of the area: the bigger the area is, the larger the paper size will have to be. Once we know the paper format choosen by the user, we will adjust the geographic area to fill the complete paper area, in a way that of course guarantees that the complete originally selected area is visible. If a lot of paper space is available compared to the size of the geographic area, we might even increase the zoom level to provide additional map details.
• Customization of the rendering layout. Instead of our current single layout with the map on one side and the street index on the other side, with the same size as the map, we will offer three rendering layouts : a plain layout (just the map, no index), a map with an index (the index being on the same side as the map) and a booklet layout (where the map and the index is split in several pages, for easy printing on A5/A4/US letter paper formats)
• Customization of the stylesheets. To begin with this, we will just provide a choice between a pre-selected set of Mapnik stylesheets. Offering the ability to use a custom Mapnik stylesheet is relatively complex in terms of security issues (Mapnik stylesheets contain SQL requests), so we decided to keep the choice inside a limited list. Of course, we’d like to see people contributing additional Mapnik stylesheets.

After the design discussion, we’ve written a few Python lines of code to define the new interface between MapOSMatic (the web frontend) and OCitySMap (the rendering backend), so that different sub-teams could work separately on these modules. And then, the implementation work started, in different areas :

• Major refactoring of OCitySMap, to prepare the addition of the new features. The OCitySMap code, while relatively short, was pretty ugly in various areas, so a refactoring was more than needed. Hopefully, it should allow us in the next few days to add features without too much pain
• Work on the OpenLayers slippy map to improve the user experience for the selection of the geographic area. Now, the full area visible on the slippy map will not be area selected by rendering. Instead, the user has to draw a rectangle of the area to render, and this rectangle remains visible on the map so that the user can adjust the area as needed.
• Work on the creation map process in the MapOSMatic web front-end by switching to a wizard-like procedure. This is needed since we will now have additional steps to configure the different aspects of the map before rendering it. This involves quite a bit of Javascript, JQuery, CSS and OpenLayers…
• Experimentation on the ReportLab PDF rendering library to generate the index, as it would probably be much easier to use than our manual index rendering code directly using Pango and Cairo.

More about our work tomorrow !