OpenStreetMap

Tomas Straupis's diary

Recent diary entries

Waterbody labels

Posted by Tomas Straupis on 5 October 2019 in English (English)

Labels should intuitively “connect” to their respective object on a map so that map reader could “feel” the stronger connection between the label and waterbody (lake natural=water or reservoir landuse=reservoir). When calculating places for labels in multi-scale (or vario-scale) map, we can distinguish three types of label placement:

  1. Multiple large labels - this is used in large scales where waterbody is so large that a very large label could fit. Usually at that point waterbody is so large that only part of it will be visible to map reader. This means multiple labels could(should?) be placed, trying to calculate the average size of a map view - we would like one and only one label to be visible at one point and as label positions have to be calculated beforehand it is impossible to make precise calculations as maps would be viewed on different devices with different size of map canvas. (There is also an interesting question if such labels should be horizontal or not, if not - how should they be positioned?)
  2. Curved labels - middle scale labels where label can be curved according to the geometry of a waterbody.
  3. Simple labels - small scale labels, where it is no longer possible to have curved labels (as they no longer fit into waterbody) and only simple straight line labels are possible.

Note that type of label depends on a particular scale+waterbody. That is on one scale you could have some waterbodies with large labels, some with curved and some with simple labels. As can be seen here:

Waterbody labels Topographic map of Lithuania

Here you can see a large curved label for lake Želva, smaller curved labels for lakes Gilužis and Trinktinis, and a simple label for lake Lenktinis.

The most interesting are curved labels. While calculating approximate medial axis could look like a good way to get a curve to draw a label on, it has one major disadvantage - you cannot get information on how large your text could be (and what letter spacing you could use). One might think that adding buffer to the line would indicate the possible size of a type, you will still have problems with irregular shape waterbodies, where label should be placed on a side where waterbody is “large enough” for a label (think of a waterbody with a shape of a prolonged triangle).

OpenTopoMap has used a very interesting algorithm to divide a waterbody to squares and then get a curve for a label. You can read about it on Github. This solution can be extended by iterating through different sizes of squares: starting with larger ones - trying to fit large type and then decreasing the size of a square thus trying to fit smaller type. The result of such calculation is seen in the picture above.

Such solution fits most of waterbodies. Even more interesting solutions are required for very irregular shaped waterbodies, say lakes with a shape of U, E etc. Such waterbodies should probable require more than one label placed even in one view as connection between different parts could not be obvious. Note that there is no single accepted cartographic convention if one object should have one label, or it could have more that one label.

Building generalisation: typification

Posted by Tomas Straupis on 7 September 2019 in English (English)

Second step in building generalisation is building typification. We take centroid of a building which is deemed too small for a scale, try drawing a minimal acceptable rectangle (oriented to the nearest road) and check if there would be enough free space between it and other already accepted buildings. If so - typified building is accepted, otherwise it is thrown out. Here is an example of buildings simplified and typified up to 20m: Generalised buildings Here original buildings are gray hashed, yellow ones - simplified buildings which are “large enough” for a scale, purple ones - typified buildings (note that some buildings are gone). This way we can avoid drawing random noise/snow in small scale maps: Building noise And convert them to something which communicates information that there are small buildings: Typified buildings As always, you can look at how this works in topographic map of Lithuania. Typification starts at zoom level 15 (5m), then 10m at zoom 14, 20m at 13 and finally 40m at zoom 12.

Building generalisation: simplification

Posted by Tomas Straupis on 30 July 2019 in English (English)

If buildings are to be placed on a smaller scale maps, they must be prepared: simplified, then typified and finally aggregated/amalgamated.

Building simplification is not the same as line/polygon simplification (done with DP or VW algorithms). When simplifying building, you want characteristic details to remain: for example most buildings have square shapes, that must remain in simplified version.

Example of building simplification:

Building simplification

Here dashed polygon - original building, yellow one - simplified to specified amount.

As you can see square angles have been preserved as well as larger details while smaller details have been removed.

The amount of simplification depends on a resolution of the screen/printer (if a size of a pixel is 10 meters there is no point of trying to depict details smaller than 10 meters) as well as legibility requirements - when too much details is displayed, map reader cannot clearly read the map. If unsimplified buildings are placed on a small scale printed map, they could be visible as some kind of sand or other pattern, not as buildings.

Such building simplification helps not only with the very important criteria in cartography - legibility, but also with some technical details - building polygons have less vertexes, therefore they are rendered faster. While legacy technology of using raster tiles does not suffer too much because of more complex geometries, it is very important with currently used vector tiles - buildings take up much less (sometimes up to 50%) space so are faster to transfer and use less CPU (and battery on mobile) to render them.

You can check the difference in building shape in a live OpenStreetMap topo map (simplification kicks in on zoom less than 14)

Multi-way generalisation (collapse)

Posted by Tomas Straupis on 15 July 2019 in English (English)

When two ways (two railways, or two parts of a motorroad) are close together they start overlapping at some point when going to smaller scale, like railway in this picture: Railway mess

Cartographic fix for this is to make one way instead of two (or more). One of the simplest ways to do that is to create a buffer and then calculate medial axis (standard functionality of PostGIS): Way generalisation (here blue lines - initial ways, black one - generalised)

This way the map is more legible, and for vector tiles - it is smaller - therefore faster to download and gives less load on cpu on client side: Fixed railway Check the change live in the topographic map 13+ - non generalised ways, 12.99- - generalised ways.

NOTE: The same generalisation operation has to be done with roads.

River barrier

Posted by Tomas Straupis on 8 July 2019 in English (English)

Direction of a way representing waterway=dam or waterway=weir is important, because you want to know which side is lower, and which one is higher - it usually the one on the side of landuse=reservoir, but sometimes reservoirs could go in sequences, sometimes with very small separating parts:

Map with a dam