In the sinister depths of a fellowship of the underground cartographers, known for its dark secrets, two veteran system administrators, Hat-trick and Springbok, had laboured tirelessly to maintain a cursed digital infrastructure for years. Their expertise was revered, their work likened to the dark heart of the company’s success.

On a moonless night, a group of overconfident, so-called dunkrugers challenged Hat-trick and Springbok. These individuals were unaware of the malevolent forces that dwelled within the servers, but their arrogance led them to believe they could control the sinister systems.

Ignoring the administrators’ chilling warnings, they recklessly invaded the server room, meddling with cables and initiating occult-like configurations. Their actions unleashed a torrent of unholy chaos as servers crashed, forbidden data was consumed, maps started to lie, and the very essence of the system unravelled.

… See full entry

Be careful with when working with Microsofts automatically identified buildings in RapID. Microsoft is apparently using its misaligned imagery therefore buildings are misaligned.

Check geometry with correctly aligned imagery before uploading.

Here is an example of two microsoft buildings (marked with arrows):

“Cartographic generalization, or map generalization, <…> is a core part of cartographic design.”

Yet it is quite often unknown or understood incorrectly/partly. This article has a pretty good description of generalisation, it’s purpose, history and main operators with some examples of where OSM-Carto is missing generalisation.

https://en.wikipedia.org/wiki/Cartographic_generalization

In December of 2021 a bi-annual International Cartographic Conference was held in Florence, Italy.

Because of Covid it was a mixed conference, however ~200 people (my estimation, I do not have an official number) have attended on site (with many more participating on-line).

OpenStreetMap was mentioned a lot. This is a good thing, but… the only good thing. It was always mentioned just as a data source. And it seems everybody is taking for granted that OSM data while being heterogenic in saturation is at least in schema (tagging) a consistent thing and slowly smartly evolving, rather than eroding. Nobody new or even expected that schema in OSM can be changed by anybody, even people who have absolutely no clue in Cartography/GIS. And this is not only a possibility, but a reality.

… See full entry

I would like to share a beautiful (and of course useful) as always Daniel Huffmans article on edges:

https://somethingaboutmaps.wordpress.com/2021/06/01/on-edges/

Such small details make such a large impact.

When preparing geodata for smaller scales, you need generalisation algorithms. Douglas-Peucker and Visvalingam-Whyatt algorithms are usually used for lines (polygons). Unfortunately those are mathematical/geometrical algorithms which do not take into account cartographic requirements.

Wang–Müller algorithm tries to do exactly that - generalise lines (of natural objects) according to cartographic requirements, such as saving or even exaggerating characteristic features.

Original Wang–Müller article has a quite concise description of the algorithm and as there is no open source implementation of this algorithm (to my knowledge) it is impossible to use this algorithm in wider scale and there are a number of unanswered questions on how some particular aspects should work.

A student of Vilnius University, Motiejus Jakštys, has done a perfect job - he has not only implemented the main part of Wang–Müller algorithm using open technologies, but also described the algorithm in his paper, which you can find here:

https://github.com/motiejus/wm/blob/main/mj-msc-full.pdf

Besides describing the algorithm itself (in more detail that original paper), this paper also includes recommendations on values of parameters to use on different scales, a lot of pictures as well as propositions for future work on finishing and refining the open implementation.

… See full entry

Problem

Once in a while discussion arises in OpenStreetMap: which polygon to render above which. For example we have a large forest and then a lake inside it. What to do? Render water above the forest! Cool! But wait, we have a small island covered with trees in that lake, so rendering water on top of the forest hides that island. What to do? Render forest above the water!… Oh wait…

And you can change water and forest to a lot of others: residential, industrial, meadow, wetland, you name it.

The point is that this cannot be solved by deciding “what has to be rendered above/below what” (well not fully). But if you decide which objects may or may not intersect, which objects must always be covered by which etc. - then you have better described ontology. Then you cut holes in forest/water example above to get not only a correct rendering, but also an often forgotten - correct analysis (for example calculation of water/forest area).

… See full entry

Lithuanian address cadastre information was opened in October last year. We started importing the data to OSM straight away. Most (90-95%) of addresses could be imported automatically (taking care of existing addresses, putting address on a building when there is only one candidate, removing any excess addresses). Remaining addresses were added semi-automatically using JOSM remote control. This increased the number of addresses from 300 thousand to 1.1 million.

Here is a video of the progress: https://www.youtube.com/watch?v=Eebl0xxT-nM

But we quickly found out that importing addresses is the least difficult part. We have a number of QA rules in Lithuania, including:

• When there is an address with a street S, the way with such name must exist in vicinity
• When there is an address with a city C, it can only be in admin boundaries of city C

… See full entry

The British Cartographic society has published a short free book about Cartography. It gives and overview of the purpose of cartography and it’s main principles. Quick but very worth read for all mappers.

You can find it here:

https://f0155d17-53eb-490a-9dcc-52cbf565c50d.filesusr.com/ugd/583f72_3075f98310fb4b159a6bfad636b97643.pdf

Point symbols need generalisation as much as any other type of object, because in small scales they also start competing for the space on the map. Usually (in popular internet maps) the most primitive way of point generalisation is chosen: points are classified, priorities are assigned to classes and then lower priority point is simply not rendered if a point with the higher priority is already rendered in the same space. If there is more than one point with the same piority in the same spot - result is even worse - decision is random.

Such solution is of course not ideal. There are a number of ways to generalise points: displacement, aggregation, symbol combination etc. Only one option, which was chosen for Lithuanian river map, will be described in this entry.

Initial situation is that sometimes rivermap points are so close one to another, that one of them is removed or they overlap:

… See full entry

Videos of BalticGIT, SOTM Baltic 2020 are on-line:
http://straume.lmt.lv/lv/video-saraksts/Baltijas-GIT
SOTM Baltic was held in auditorium DELTA

Allan Mustard’s presentation „I’m Tired of Getting Lost!“ can be seen in auditorium ALFA (part 1) or you can watch the same presentation in last years NACIS2019:
https://www.youtube.com/watch?v=JpHLulm-Wq4

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:

… See full entry

… See full entry

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:

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.

… See full entry

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:

… See full entry

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: