Kicking off the Holy Roman Empire OHM project (Are you nuts?!? Yes, please join in!)

[Minh_Nguyen]

@Alphathon

The size of the labels at the moment is really just a bit too big for even medium-small countries like the Netherlands; really small countries like Liechtenstein or even worse the 19th-century Thuringian states just get lost under the text. It would be a shame to totally change it though as I do like the label style when applied to larger entities (e.g. France or the Austrian Empire).

We have the technical capability to vary the font size, font weight, or letter spacing by the country’s size. From what I’ve seen, print atlases often vary the text style like this, if a little less than they do it to city labels. But this would still depend on deleting the label nodes, since those nodes don’t have any information on them about how much area the country covers.

@Alphathon

It might also be a bit better if the borders themselves were a bit less “sharp”/“dense” – they go very quickly from dark to light and almost look like anti-aliasing is too low. I suspect this is a result of multiple pieces of the same geometry overlaid on top of each other – I don’t really know how the renderer handles it, but it does seem to make darker borders when two or more entities share the same boundary (or at least it used to).

We were rendering redundant boundary lines until last week. Now we should be deduplicating coincident lines. Please double-check that this is working correctly. We might not be deduplicating boundary lines that are in different administrative levels, so this might affect regions that are comprehensively mapped at multiple levels.

Another change is that we now render boundary ways as lines, whereas before we’d only render boundary relations. This could be convenient for treaty lines between otherwise undefined territories. But it might also result in darkened lines if a boundary way is redundantly tagged with boundary=administrative.

@Alphathon

might also be worth looking at whatever system is used to simplify the geometry at different zoom levels. Given the complexity of some of these boundaries (example embedded below), if the “simplifier” (or whatever you’d call it) can’t simplify that down adequately it’s no wonder the borders look messy. Other than that the only thing I can think of is somehow manually defining zoomed-out geometry or tagging using a role to tell the renderer to only use it when zoomed in (e.g. outer_complex).

So far, we’ve focused on simplifying the geometries only to an imperceptible extent. Vector maps do tend to simplify more aggressively for performance reasons, though the effect usually leaves borders looking jagged. The changes last week included switching to a different simplification algorithm that preserves more topology, so we might be able to simplify more aggressively. I’d recommend opening an issue with any examples you feel best illustrate the need for further simplification, so we don’t end up simplifying counterproductively.

@Alphathon

There could also maybe be abbreviated forms for some names that display if the “full” label is too much bigger than the geometry (where appropriate). For example, at a far out zoom (e.g. 2) the UK could display, well, UK, at maybe 3–5 United Kingdom, and any closer United Kingdom of Great Britain and Northern Ireland. If I were making a static map I’d probably be tempted to use multiple text sizes for the latter, e.g. United Kingdom of Great Britain and Northern Ireland, but I don’t know how that could be tagged and would very much be “tagging for the renderer”.

This could be the distinction between name=*, short_name=*, and official_name=*. It would be straightforward to expose these keys in the tiles for styling purposes, at least for a very limited selection of languages. Unfortunately, MapLibre lacks a mechanism to try a variety of labels to see which one would fit. The only workaround I can think of requires duplicating layers, which has performance implications, but it might be a good tradeoff if we can get enough boundaries tagged with short names.

@Alphathon

These territories are small and many are (geometrically) quite complex so without colours and/or labels they become an unintelligible mess. Crucially though they are all (apart from Massa & Carrara) attached to moderately larger states, and whatever is done has to work on these exclaves as well as it does microstates.

We see a much milder version of this problem in modern countries like the U.S. that have a mix of very large and very small clusters of subdivisions. A traditional print map would use indices to a legend, as in your example, or offset labels with leader lines. Unfortunately neither approach has crossed over into interactive digital cartography. It would be really cool if OHM would be the ones to make a substantial contribution towards a solution to this problem.

@Alphathon

Something else I’ve noticed: several of the labels in those embedded maps are different than when viewed on the website. They seem to be using English translations (presumably taken from name:en) rather than the standard native text in name, which for several of those states is abbreviated, e.g. “Principality of Waldeck” shows as “Fsm. Waldeck” (for “Fürstentum Waldeck”) on the website but not when embedded. If that is different I do wonder if anything else differs between the site and the embedded version.

The embed site automatically switches to name:*=* based on your browser’s preferred language setting, falling back to name=*. We’re working on bringing that functionality to the main site too.

The other difference is that the embed site uses the 1-based zoom levels that are common in vector maps instead of the 0-based zoom levels common in raster maps. For backwards compatibility, the main site is using 0-based zoom levels. We might want to make sure the sharing option adjusts the zoom level accordingly when generating the URL.