I've started to disagree with the featured tile layers on openstreetmap.org. First, whoever makes the decisions decided to feature Tracestrack Topo, which is broken when HTTP Referer header is disabled, therefore it doesn't work in Librewolf by default, and neither does in KDE Marble. There's already OpenTopoMap, which although has no bathymery, the lowlands don't appear flooded at Z1 to Z8. Way odd for a company from the Netherlands to make their home country look so ugly, but it's even more apparent at the Caspian sea. The Z9 to Z11 of Tracestrack Topo are quite nice, though. The Z12 to Z19 are however too similar to the default Carto, and buildings are gone until Z15 inclusive, which makes it less usable.
Secondly, they removed my favorite ÖPNVKarte, which was miles better than Thunderforest's. Supposedly it was months out of date, but the only out of date thing important for me were some missing tram line extensions, which started to pop up quite frequently considering how long it takes to legally build anything in Czechia, to the point it's easier to do it illegally and bulldoze it years later when you finally actually have to. Prague Metro has been the same since 2015, and I don't ride buses if there are rails. I have paper maps 20 or even 100 years out of date, a few months is nothing.
In August 2025, 2 vector tile layers have been featured, Shortbread (MVT) and OpenMapTiler (PBF). However I now have an 5120x1440 ultrawide monitor, which is wider than the HTML canvas can handle, so it's blurry. Shortbread is like F4map and tries to respond to dark mode with a simple luminance inversion, which Deluminate extension can do on all tiles, so there's always 1 tile layer sticking out like a sore thumb, aside from Transport Dark which is an actual dark variant. OpenMapTiler is basically a vector version of Carto. The zoom is still discrete.
I've been collecting other tile layer URLs, as far as they were working, also stealing some API keys with them from the F12 devtools, originally intending to make a beefed up version of montage.sh from OpenTopoMap to scrape all tiles at all zooms to stitch together and print various territories to avoid relying on my phone's rapidly depleting battery, given the need to increase brightness. But I've discovered that this bugged and clumsy children's toy digital globus KDE Marble can import those tile layer URLs and project them onto the globe, so there goes the silly Mercator Greenland and Siberia exaggeration. Printing the view is supported too, and just like with web maps, 4K display is recommended for A4, as 2160 px * 2.54 cm/in / 17.3 cm = 317 DPI. Do not confuse KDE Marble with Marble Maps, which is a differnet app with buggy UI (you can't exit settings, you have to restart), that doesn't support importing custom tile URLs.
I have intentionally omitted US-focused layers, yet kept European focused ones. As a European, I don't really care about the USA, for I am not likely to set foot in there unless public transit gets decent (see ÖPVNKarte and OpenRailwayMap), and American OSM data is not quite up to the European levels of quality. There will always be better data for the US on proprietary American maps, like Bing Maps, Google Maps, Yahoo Maps etc., just as there is better data for China on Baidu and for Russia on Yandex. OSM is mainly a European project with some activity in the 3rd world as per humanitarian efforts, and especially Central European cartography has a strong tradition oriented towards topographic maps, most clearly exemplified in OpenTopoMap and on mapy.cz Tourist map. North Americans care mostly just about roads and streets, and a nice complex and rich map for hiking and biking in the nature will overwhelm them. This is also why I stopped using "basic" Google Maps. They were too bright, bland, and simple, compared to OSM Carto, at least in European cities. Instead I use Google Earth, and the 3D imagery improves steadily.
While Google Earth Pro can be made to display tile overlays too, the 3D terrain and buildings interfere heavily, and besides being proprietary, it requires perfectly functioning 3D graphics, which wasn't the case with Intel GMA on Linux, and may not be necessarily the case with nVidia. It occasionally crashes with SIGABRT. For viewing flat 2D tiles on a globe, KDE Marble consumes much less resources, and with a hybrid tile layer looks quite close to Google Earth. Also there are multiple projections to choose from, even Azimuthal to appease Discworld LARPers, but Gnomonic is the best for determining Qibla.
There are however some limitations. Non-Mercator projections aren't that smart with regards to reading the file header and assume the dimensions from the config file, which defaults to 256x256, which needs to be edited manually. Non-power-of-2 sizes do seem to work, but are omitted to reduce clutter except Yandex Labels 10x, that is 2560x2560, which was the largest offered size. The tiles are somewhat blurry at the standard density, however the font size of some of those tiles is now at least properly readable, and it's not like y'all don't have 8K Big Brother telescreens already while I'm there on a 5K ultrawide. Also, the projections maintain the same pixel density for a given zoom, so when actually specifying their correct resolution, they look actually less detailed, except HERE, which corrects for this by providing a zoom level 1 deeper for 512x512 tiles. If the size is kept declared as 256x256, the Mercator projection detail increases as intended, but other projections display patchwork. Possibly on Hi-DPI monitors the base size looks unreadably tiny or Marble respects DPI settings and adjusts the target pixel density. Furthermore, Bing uses some sort of quadtree index, which is way above the capabilites of {x} {y} {zoomLevel} placeholders and reminds me of INTERCAL mingle operator. Some tile providers may also use the correct ellipsoidal Mercator projection formulas instead of spherical misinterpretation of WGS84 data (namely Yandex), shifting things alongside a merididian by up to 40 km. Webcator is in fact so shitty that the US DoD NGA said it sucks and the popularity of it is dangerous, and EPSG long refused to assign a SRID to it, therefore it works better than China's offical coordinate scrambling algorithm GCJ-02 and its bespoke Baidu BD-09 variation (which also seems to use some weird tile indexing). Also, the default zoom range only suffices up to zoom 19. Some tilesets, namely the ESRI World Imagery, go up to zoom 23 (not everywhere), Voyager/DarkMatter/Positron go up to 20 with 8x making it effectively 23, and Yandex Labels go up to 21 with 10x making it effectively 24.25. However expanding the zoom range causes the view to glitch to a different position when zooming too quickly too deep.
Editing of the imported tile layers properties is very clumsy. There is no GUI for it. You have to manually edit XML in $XDG_DATA_HOME/marble/maps/earth/${mapname}/${mapname}.dgml , $XDG_DATA_HOME being usually ~/.local/share , ~ being usually /home/$(whoami) , therefore full path is most likely /home/$(whoami)/.local/share/marble/maps/earth/${mapname}/${mapname}.dgml . If you somehow still use that spyware proprietary software bootloader, then %LOCALAPPDATA%\.marble\data\maps\earth\%mapname%\%mapname%.dgml , %LOCALAPPDATA% being usually %HOMEPATH%\AppData\Local , %HOMEPATH% being usually %HOMEDRIVE%\Users\%username%, and %HOMEDRIVE% being usually C:, therefore the full path is most likely C:\Users\%username%\AppData\Local\.marble\data\maps\earth\%mapname%\%mapname%.dgml. Note that ancient versions of Windows NT use "Application Data" for AppData and "Documents and Settings" for Users, as to make sure the MAX_PATH limit of 260 is hit more often.
Deleting hard disk cache from the GUI doesn't work properly on these custom indexed tile layers, you have to delete all numbered directories manually. This can be achieved by a bash one-liner:
for Z in {1..24}; do find "$1" -type d -name "$Z" -exec rm -rf {} + ; done
Also don't delete the ${mapname}/0/0/0.png file. The default cache validity is a year, which seems quite long, but there is also a size limit configurable from the GUI, which is to be reached instead. The providers shouldn't be spammed with tile requests repeatedly, and new motorway stretches usually open in December or around election time.
With all these bugs mentioned, I have taken a look at KDE's bug tracker, but it seems pretty dead there. The last version seems to be from 2023 or 2016 depending on whether the about box is invoked from the map context menu (the library), or the top bar menu (the GUI). Finally a Qt6 port (January 2025), but the copyright year has remained the same, so very likely it's mostly that experimental branch upstreamed with some maintenance work performed.
Here is the link to the tile layers, finally:
https://drive.google.com/file/d/1mKJGLWdU5LI7Eh-YENAM_DV0R3_RTB1C/view?usp=drive_link
Extract this archive into ~/.local/share/marble/maps/ or %LOCALAPPDATA%\.marble\data\maps\ , so that the earth directory in the archive merges with the earth directory already present there. Depending on your distribution, actual path may differ. Preferrably, restart KDE Marble. Some tile layers don't work on the outdated Windows version from 2015, mainly the high DPI and non PNG8 or JPG ones. Possibly it has to do something with missing filename extension, as the tiles end with a mere dot due to URL rewrites containing none, but for the love of Allah, please stop using such shitty operating systems where a file name ending in a dot is a problem.
Licensing note: There are some proprietary tile layer URLs included with some low zoom pre-cache tiles. These are provided for evaluation, comparison, personal, or private use. Don't use them in any situation where you wouldn't use the Webcator projection. Especially don't abuse those with API keys included in them. I was too lazy to fill in attribution text, for what is essentially a sophisticated URL collection. Usually the provider is included in the name.
There is no warranty, tile providers may start Referer and Origin checking or even stop providing the tiles altogether, KDE Marble may freeze, SSD may lock to read-only mode due to cache thrashing exhausting write cycles (there are a lot of small files being downloaded), Internet bill may force you to declare bankruptcy, tyrannical government may prosecute you for using foreign maps with wrong borders (see Yandex which removed them), you may simply dislike the appearance of some tiles or presence of some tile layers, and so on and so on.
Last updated on 2025-10-01 (ISO), 01.10.2025 (Central-East Europe), 10/01/2025 (USA), 2025\01\10 (US-occupied Middle East).
Tile layers available from the "store" or shipped by default:
Included tile layers (bold works on the old 2015 ₩i₦₫o₩$ version):
Excluded tile providers due to too nosy HTTP header checking:
Appendix - Size table:
Useful for determining processing and render limitations. For DimPixels and Pixels, standard density is assumed. For RawBytes, a 4-Byte (32-bit) color format like ARGB8 or A2RGB10 or R11G11B10 is assumed. Ocean tile ranges (70 % of Earth) can be optimized by hardlinking to a single ocean tile. NTFS, ZFS and XFS seem to be better than ext4 and FATs, but ReFS, btrfs and bchachefs are even better.
SI PREFIXES IN THE TABLE BELOW ARE BINARY!
z 2^z 2^(2z) 2^(z+8) 2^(2z+16) 2^(2z+20)
Zoom DimTiles Tiles DimPixels Pixels RawBytes Comment
0 1 1 256 64K 256K single tile
1 2 4 512 256K 1M quarterglobes/čtvrtkoule
2 4 16 1K 1M 4M like Blue Marble 2005
3 8 64 2K 4M 16M chessboard
4 16 256 4K 16M 64M
5 32 1K 8K 64M 256M
6 64 4K 16K 256M 1G may work as wallpaper
7 128 16K 32K 1G 4G 32b viewers limit
8 256 64K 64K 4G 16G Tiles = DimPx; FAT32 sg
9 512 256K 128K 16G 64G expensive GPU VRAM
10 1K 1M 256K 64G 256G exFAT single dir limit
11 2K 4M 512K 256G 1T ext4 sg dir (no largedir)
12 4K 16M 1M 1T 4T
13 8K 64M 2M 4T 16T 8.3 name single dir limit
14 16K 256M 4M 16T 64T FAT32 total files
15 32K 1G 8M 64T 256T
16 64K 4G 16M 256T 1P NTFS sg,FAT32 per,ext4 Σ
17 128K 16G 32M 1P 4P OpenTopoMap
18 256K 64G 64M 4P 16P ÖPNVKarte & OSM DE
19 512K 256G 128M 16P 64P OSM Carto
20 1M 1T 256M 64P 256P CycloOSM & HOT & OSM FR
21 2M 4T 512M 256P 1E exFAT per, ThunderForest
22 4M 16T 1G 1E 4E
23 8M 64T 2G 4E 16E ESRI World Imagery
24 16M 256T 4G 16E 64E ZFS per dir, 64b viewers
25 32M 1P 8G 64E 256E
26 64M 4P 16G 256E 1Z 8.3 name limit
27 128M 16P 32G 1Z 4Z
28 256M 64P 64G 4Z 16Z
29 512M 256P 128G 16Z 64Z
30 1G 1E 256G 64Z 256Z
31 2G 4E 512G 256Z 1Y
32 4G 16E 1T 1Y 4Y NTFS per dir & total, XFS
Appendix - Scale table:
Actual scale depends on the latitude. Formula for the denominator in "1:m":
m=eqcircum*COS((deg+min/60+sec/(60^2))*pi/180)/(2^(zoom+8)/(100*dpi/2,54))
where:
* deg, min, sec is the latitude in sexagesimal degrees (decimal sucks),
+ The Tropics being at 23°26' in 2045 and 27' in 1927,
+ The (Ant)Arctic Circle being at 66°34' in 2045 and 33' in 1927,
* pi is 3.14159265358979323846264338327950288419750...,
* zoom is the zoom level or base 2 log of number of tiles per side,
* dpi are dots per inch, the display or print density, assumed 96.
Meaning, 1 unit of your silly length measure on the map corresponds to m units of your silly length measure in the real world.
SI PREFIXES IN THE TABLE BELOW ARE DECIMAL!
1:... 23°26' 66°34' π/12 π/6 π/4 π/3 5*π/12
z Dim96DPI Equator Tropic ArcticC 15°lat 30°lat 45°lat 60°lat 75°lat
0 67.733m 591.659M 542.861M 235.292M 571.498M 512.391M 418.366M 295.829M 153.133M
1 135.467m 295.829M 271.430M 117.646M 285.749M 256.196M 209.183M 147.915M 76.566M
2 270.933m 147.915M 135.715M 58.823M 142.875M 128.098M 104.591M 73.957M 38.283M
3 541.867m 73.957M 67.858M 29.411M 71.437M 64.049M 52.296M 36.979M 19.142M
4 1.084 36.979M 33.929M 14.706M 35.719M 32.024M 26.148M 18.489M 9.571M
5 2.167 18.489M 16.964M 7.353M 17.859M 16.012M 13.074M 9.245M 4.785M
6 4.335 9.245M 8.482M 3.676M 8.930M 8.006M 6.537M 4.622M 2.393M
7 8.670 4.622M 4.241M 1.838M 4.465M 4.003M 3.268M 2.311M 1.196M
8 17.340 2.311M 2.121M 919.109k 2.232M 2.002M 1.634M 1.156M 598.174k
9 34.679 1.156M 1.060M 459.554k 1.116M 1.001M 817.121k 577.792k 299.087k
10 69.359 577.792k 530.137k 229.777k 558.104k 500.382k 408.560k 288.896k 149.543k
11 138.718 288.896k 265.069k 114.889k 279.052k 250.191k 204.280k 144.448k 74.772k
12 277.436 144.448k 132.534k 57.444k 139.523k 125.096k 102.140k 72.224k 37.386k
13 554.872 72.224k 66.267k 28.722k 69.763k 62.548k 51.070k 36.112k 18.693k
14 1.110k 36.112k 33.134k 14.361k 34.881k 31.274k 25.535k 18.056k 9.346k
15 2.219k 18.056k 16.567k 7.181k 17.441k 15.637k 12.768k 9.028k 4.673k
16 4.439k 9.028k 8.283k 3.590k 8.720k 7.818k 6.384k 4.514k 2.337k
17 8.878k 4.514k 4.143k 1.795k 4.360k 3.909k 3.192k 2.257k 1.168k
18 17.756k 2.257k 2.071k 897.567 2.180k 1.955k 1.596k 1.128k 584.154
19 35.512k 1.128k 1.035k 448.784 1.090k 977.309 797.970 564.250 292.077
20 71.024k 564.250 517.712 224.392 545.023 488.655 398.985 282.125 146.039
21 142.047k 282.125 258.856 112.196 272.512 244.327 199.492 141.062 73.019
22 284.094k 141.062 129.428 56.098 136.256 122.164 99.746 70.531 36.510
23 568.188k 70.531 64.714 28.049 68.128 61.082 49.873 35.266 18.255
24 1.136M 35.266 32.357 14.024 34.064 30.541 24.937 17.633 9.127
25 2.273M 17.633 16.179 7.012 17.032 15.270 12.468 8.816 4.564
26 4.546M 8.816 8.089 3.506 8.516 7.635 6.234 4.408 2.282
27 9.091M 4.408 4.045 1.753 4.258 3.818 3.117 2.204 1.141
28 18.182M 2.204 2.022 876.531m 2.129 1.909 1.559 1.102 570.463m
29 36.364M 1.102 1.011 438.265m 1.064 954.404m 779.267m 551.025m 285.232m
30 72.728M 551.025m 505.578m 219.133m 532.249m 477.202m 389.634m 275.513m 142.616m
31 145.456M 275.513m 252.789m 109.566m 266.125m 238.601m 194.817m 137.756m 71.308m
32 290.912M 137.756m 126.395m 54.783m 133.062m 119.300m 97.408m 68.878m 35.654m
You could print all zoom 5 tiles on a B0 paper at roughly 200 DPI as a world map poster. Given it's a crappy version of Mercator, it's only useful as a decoration.
I don't think there's a formatting option in LibreOffice Calc to display these decimal humanized values. Maybe 591M659 would be more intuitive than 591.659M, which is equivalent to 591659k, but I want to leave some decimals. Zoom 30 is deeper than 1:1 even at equator. Obviously, the axial tilt and equatorial circumference of other celestial bodies is different. Since Earth is the largest rocky planet, 16 zoom levels will generally suffice for the other 3, Galilean moons may not need more than 12, and dwarf planets may be content with 8. May not work with odd-shaped asteroids.
No comments:
Post a Comment
Barely anyone comments, so I don't moderate. Free advertising, I guess.