As just stated on the Fossgis Hackingweekend at the Linuxhotel in Essen… “I’m mapping the year of constrcution for a (huge) number of houses. I’m looking for a way to visualize this on the map”.

Likely multiple solutions exist, but how to do this with libosmscout?

At the start of the weekend this was not yet possible. Small discussion with another developer (not at the weekend) showed, that a general approach was needed, as colouring of ways based on attributes has also interesting use cases (hint: colour of metro lines).

Libosmscout implements tag and value combinations as features. All possible features of an object type (configurable during import) are flag in a bit set, if an concrete object has the feature.

The value of an feature is implemented as simple class that must offer serialization and deserialization methods.

So first we write a new Feature implementation that parses the start_date and year_of_construction tags. The new Feature will have two int attribute for the start and end year. Investigation of the actual tag values show and creation time can be an time interval, for our needs the year however is enough. Depending on the use case other implementation could be possible, too.

We need to do some string parsing to get most of the possible variants of the tag values parsed. Mapper: Please do not be to creative ;-)

Afterwards we add the possibility to register style processors into the rendering pipeline. The processor has a simple interface. It gets the list of feature values and the style as defined by the style sheet. It returns either the original style or a (cache) new style instance. Processors are registered by type.

Next step is to implement a simple processor for the type building. The processor checks if the construction year feature is available and the year between 1800 and 2020. In this case it return a red fill style, with the actual brightness depending on the age. Older buildings get darker red.

See the result:

… See full entry

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.

… See full entry

The end of the year (And the start of a new one, as I did not finish this article in time ;-)) is a good time to review the progress of libosmscout in the year 2015. As with likely every project at the end of the year one has the feeling, much more should have been done and there is even more left to be done in the next year - the more project time passes the more time is required to finish the project.

A retrospective is a good approach to correct this feeling and move things into a more objective perspective. After writing down all the things achieved in 2015 I’m of the opinion, that 2015 was a good year for libosmscout :-)

What happened in 2015?

Bug fixes: As always 2015 brought a number of important bug fixes. Things didn’t work or broke - we fixed it.

Code cleanup and C++11 only: We did a huge number of code cleanups. Libosmscout is now C++11 only, requiring recent C++ compilers. On the other hand C++11 allowed us to (unconditionally) use things like unordered_map/set, lambdas, auto, range-based for loops and most important std::shared_ptr. Code got simpler and readable because of this. Using std:.shared_ptr allowed us to drop our own custom reference counting solution.

“Feature”-feature: Long planed and finally realized in 2015: The “Feature”-feature. Features allow the application developer to evaluate its own OSM attribute combinations, inject resulting data into the database and retrieve them back during rendering. Libosmscout itself now uses features to map attribute information into the database. Obvious candidates for further custom Attribute are for example : ele, wikipedia links or similar. Features also allow you to add custom labels and the rendering of multiple labels.

… See full entry

Following some of the advices from this blog entry (namely points 1, 3 and 4) and to enabled realization of more points from the list, we now have automatic builds on commit of the libosmscout sources.

You can thus now find automatic builds for Linux and OS X using clang and gcc at Travis CI. You can find builds for Visual Studio 2015 and MinGW/MSYS2 at Appveyor.

Using these cloud based external continuous integration provider enables the project now to regularly check, if things compile under all supported platforms.

It will enable us to make some rudimentary tests, too. And it might – if resource limitations on the CI platforms allow – enable us even to even offer build products in future.

If some important platform is still missing, please tell me. I’ll see if it can be integrated either at Appveyor or Travis CI (Android would be my next choice).

The use of above providers already allowed me to streamline the autoconf files and remove some of the conditional compilation code, without breaking any of the platforms.

By the way: Libosmscout since 2015 now unconditionally requires a C++11 supporting compiler. The support does not need to be 100% complete, however required features are (possibly incomplete):

• (u)intXX_t, unordered_map, unordered_set
• long long and unsigned long long
• Thread support (atomics, mutex, condition variables, thread, async)
• Chrono support
• Lambda
• Some C++11 specific new header for interfacing C

Currently the current version of all supported compilers (gcc, clang, Visual Studio 2015) support all required features.