OpenStreetMap Carto - my thoughts on development (part 2)

Posted by kocio on 28 August 2018 in English (English)

First part was about why dense (well mapped) areas should be treated better than outdoor/rural areas. Today I will discuss rendering objects according to their size.

There are many types of maps and one of the most important property is their preferred use. OSM Carto has no special goals of this kind, it is meant to be general style. Unfortunately, it's harder to develop because of this.

Putting all the things on the map according to their "importance" is misleading, because without clear goal it's hard to tell what system should we apply to show some items more prominently than the others. In practice it seems that people tend to think mostly like "I want to find x" or "it was always like this". But finding is better done by apps and we show many object types, so sticking to the old solutions will just highlight lack of clear rules eventually.

So - what could be the universal property of objects that we could use on the map? I think this is their size.

In a matter of fact, it is used a lot already. We use initial zoom levels to not show benches at the world level, because then the map would look more or less like this:

screenshot_2018-08-28 amenity bench tagi openstreetmap taginfo

Of course, it is not always clear what size are we talking about. For example building can be as small as a shed or as big as a factory. But at least we know that there are no buildings of the size of a country.

What helps in a lot of cases is typical size and typical usage.

Sometimes we have a special hint, like with monuments and memorials, supermarkets and convenience shops or rivers and streams. They are just defined as big/small objects, so it's easier to render them properly, because it's the mapper who takes the bigger part of responsibility. But most of the time we have to check that for example beach resort is typically quite big area and act accordingly.

There is also second type of hints: typical usage. That means that if object A can be a part of some other object (B), we should render A later then B, even if that's not clear looking at their size alone. That's the case of towers and castles for example - in general height is useful direct hint how early towers should be rendered. We could do the same with defensive towers, but they (and city gates) are frequently a part of the castle. So it makes sense to always show them later, because when we see the castle, we can initially skip all the details. They will be visible when we zoom in - that means when we're interested in more details. The castle is a generalization for all these elements and showing defensive towers from the same zoom level would break this generalization and make visual noise.

Look at this example on z15-z17. You could also notice that the castle has no name label initially (z15) - it's typically smaller than town and because of that it shouldn't be too loud:

screenshot_2018-08-28 openstreetmap screenshot_2018-08-28 openstreetmap 1 screenshot_2018-08-28 openstreetmap 2

Of course there are single, standalone defensive towers and city gates around the world. But it's safer to show them at least one step later than castles, because they can be a part of such castle and we don't know it just by looking at tags.

There are also some other hints - for example hierarchy of objects. This is the case of rendering quarters: we can just observe that they are higher level objects than neighborhood and lower than suburbs, and we're basically done with the subject, even if don't know their typical size or typical usage.

So please, mind the size...

Comment from giggls on 30 August 2018 at 09:17

We are talking about "Topographic isolation" here. This attribute is usually used in rendering of important peaks only, but is also applicable to other kinds of POI.

We will likely want to render a restaurant located in the middle of nowhere already on a low zoomlevel while we will not want to do this in the middle of a big city where restaurants are very close beside each other.

This can be done using st_distance and st_dwithin on postgis but the queries are somewhat expensive.

Comment from kocio on 30 August 2018 at 10:32

I guess this comment is rather for previous article, because it was about urban/rural distinction. How does it relate to this entry?

Comment from giggls on 30 August 2018 at 12:36

I read both of them consecutively thus did not differentiate between the parts I have been commenting about.

Comment from dieterdreist on 31 August 2018 at 11:35

Christoph pointed in the osm-carto repository to this related issue which was closed #1884 in 2015 after discussing the ‘typical size’ beats everything concept.

Comment from Adamant1 on 31 August 2018 at 14:08

Dietereist, I think you or Christoph pointed out that the consensus approach broke down long ago somewhere did you not? So if its not that or this, what other approach would there be to deciding these things? Although this way of doing things has its flaws, I agree with the general sementiment by Kocio that its at least better then factionalism, arguing, and things never moving forward. I think people around here need to step out of their own way. If not this way, what other option can acomplish that?

Comment from kocio on 31 August 2018 at 14:11

Typical size is just one hint I wrote about. There is also relative size, typical usage etc.

Login to leave a comment