As last year I participated at the 2. OSM Sommercamp at the Linux Hotel in Essen, Germany. Plan was to do some development for libosmscout.

The master plan for this year was already there, and as part of this I wanted to concentrate on caching of data in the MapPainter thus improving the performance of the render. Since a few days before I got some hints regarding possible performance problem in the label layouter I wanted to take a look at that first. Another topic was creation of simple HTML pages during the import process to dump all those findings about (possible) mapping errors that were detected during import.

Simple results first: The creating of HTML was already prepared before so at the SommerCamp the main task was to go through all the warnings and errors created during the import and convert them to the new API. At the end of the Sommercamp most stuff now was dumped to the HTML pages, too. A quick scan shows that for small imported regions most error occur because of some clipping problems, for larger region a fair amount of error are either due to libosmscout not knowing some types of objects or actual mapping problems. Next step would be some central server that builds libosmscout regularly and imports *.osm.pbf files people are interested in getting results for. While we do have central Travis and Appveyor builds the memory demand during import is likely too high to run imports there.

Next I improved MapTileCache so we now have a nice data structure that allows a renderer to use it for caching “things” (which could be handles, measurement result,…).

After that I took a look at the label layouter. In fact there was some O^2 algorithmic deficiency (how could that happen!?). Since I planed that anyway and to try to improve the API to the rest of the renderer I moved the layouting to its own class and at the same time removed the O^2 problem.

During testing I found some mysterious performance effect. While scrolling through the map, map rendering suddenly got much, much slower. After much analysing, dumping of ids, the cause was clear.

1. Libosmscout does some heavy work trying to merge ways in cases where they have the same attributes. Longer way mean, simpler routing graph, less data overhead.
2. On the other hand since some time libosmscout now does repetitive contour label rendering on ways (before that the contour labels was just rendered once on each way segment, independent of its length).
3. For detecting if a way should be rendered or not we use simple bounding box clipping.

Result: For the river Rhine for the nordrhein-westfalen import we generated a very long way (from Bonn up to the the german border in the north). The style sheet defines a contour labels for this. The effect bounding box for the river did go to the right up to Essen (where the Rhine is not visible, but because of the snake like meandering the bounding box still was there). So somewhere around Essen we started to render contour labels for the whole of the Rhine. Labels that were actually not visible on the resulting map. During the Sommercamp I fixed this by defining an upper limit on the way merging. Since the problem occurred after the Sommercamp again for some ferry line Lukas fixed this again with a more general approach by explicitly splitting ways again after merging.

Label rendering is now faster than before. Though we still need some geometric solution to further reduce the overhead.

Finally time was spend to eat some cake at the 12. birthday of OSM :-)