For the last six months I have been working on the project to add generalization support to osm2pgsql. This project was funded by the German Ministry of Education and Research (and organized by the Prototype Fund). Many thanks to them for giving me this opportunity!

Several of the generalization algorithms I am working on are based on tiles. They collect all features inside a tile boundary and do something with them. This means that whenever something changes, we have to figure out which tiles are affected and re-process them. Luckily a very similar functionality is also needed for generating lists of tiles that need to be re-rendered. And support for that has been in osm2pgsql for a long time. We just need some additions to be able to re-purpose that code.

Large waterways such as rivers and canals are important features on small scale maps. This is the fourth problem I wanted to work on described in this blog post.

Many maps show built-up areas of cities and other settlements in a different color on scales where you can’t show individual buildings. This gives the viewer an immediate idea on where the landscape is more urban and where it is more rural. This is the third problem I wanted to work on described in this blog post.

Most maps need little symbols and labels for settlements like cities and towns. Of course you can’t put all settlements on the map, so you have to select those you want to show. For that you need to “rate” the places in some way, so that you can show only the more important ones. And then you want to show a “reasonable” selection of places, not too many so the map isn’t too crowded, not too few to make the map look empty.

Like any project, the generalization project I am working on has its share of experiments. Not everything you try out will work in the end, or is fast enough, or actually needed, etc. These experiments often don’t end up in the progress reports or final reports, but without them we can’t create something new. I want to talk about three experiments related to raster data in PostgreSQL/PostGIS, one successful, one failed and one where the outcome is still open.

Maps almost always have lots of large and often complex polygons showing lakes, forests, urban areas, countries and so on. On a small scale map all you are going to see of some of these polygons is a few colored pixels. For that you don’t need the detailed data.

I want to write a bit about the processing architecture of osm2pgsql and how I plan to extend it to help with generalization.

In cartography you often have to find points that “represent” a polygon in some way, the exact outline of the polygon isn’t important, you just need a single position somewhere on that polygon, for instance to draw an icon there. In OpenStreetMap points of interest are sometimes modelled as polygons (usually building outlines) for example. A similar problem is finding a labelling point of a polygon, that is the point where to put the name label of a forest or a lake or a country.

To start the OSM generalization project I decided to look at some specific generalization problems with a wide variety of use cases and challenges, and with different types of solutions. It is obvious that I can’t implement every algorithm out there and solve every generalization problem, but I can take a sample of typical problems with different solutions and try to implement them. This should hopefully give us a better understanding of the problem space and a basis on which we can build later.

OpenStreetMap data is often incredibly detailed and the generated maps look amazing. But there is a problem for maps in smaller zoom levels/on smaller scales: There is often too much detail. Maps become slow to render and cluttered, the important information is hard to see. To solve this the map data needs to be generalized.