Your best bet for this is something like OsmAnd or organic maps, which download countries worth of osm data and make it available offline.

The amount of map data for any reasonable area is going to be too large for a PWA, though it would technically be possible to do with existing map viewers and this format. (Eg maplibre or leaflet)

Thanks. I'm OK with a single layer just showing the outlines of coastlines and regions, including the names of regions. I think a suitable simplified world map could fit all this in SVG.

edit: Initially underestimated so did some calculations below

Key Data Points for Estimate of SVG Size

  - Radius of Earth: 6371 km  
  - Surface Area of Earth: 510e6 km^2  
  - Approximate Number of Countries: 250  
  - Land Area of Earth: 29% of Surface Area = 150e6 km^2

Corrections and Estimations Based on Average Country Size

  - Average Land Area per Country: 150e6 km^2 / 250 = 6e5 km^2  
  - Country Closest to Average Size: Ukraine, with 603550 km^2, or roughly 6e5 km^2  
  - World Resources Institute Measure of Ukraine Coastline: 4953 km, or around 5e3 km

Assumptions for SVG Complexity

  1. Only coastlines matter for the paths.  
  2. Resolution set at 10 meters.

SVG Data Calculations and Estimates

  - Coastline Points for Average Country:  
    - 5e3 km = 5e6 m  
    - Equals 5e5 X,Y points (at 10m resolution)
  - Total Points for All Countries:  
    - 250 countries * 5e5 points = 1.25e8 X,Y points
  - Storage Requirement for Each Point:  
    - 6 figures per coordinate + delimiters = roughly 15 bytes  
    - Total Storage = 1.25e8 points * 15 bytes = ~1.875e9 bytes or about 1.875 GB

Even with a simplified approach, we're looking at an SVG that'd be almost 2 GB, just for coastlines at a 10m resolution. Definitely some hefty complexities in play here.

What about 1000m resolution? 20 megabytes. Much more achievable.

I would expect border length scales with the square root of country area, so smaller countries have disproportionally longer borders than larger ones.

There also must be more countries smaller than the average country than there are larger ones (https://www.worldometers.info/geography/largest-countries-in... confirms that. Ukraine is 45th of 223, or about 20% down.)

So, I guess yours is underestimating the size.

You probably get a better estimate by using the Ukraine to estimate the scaling constant (√603,550km²)÷4953km and then use a list of land areas to estimate border lengths.

I like your refinements! I may take a look at reviewing the estimate later! Thank you for making this contribution, it's really valuable that you share your intuitive statistical knowledge here :)

Countries with coastlines, especially with fjords, have disproportionately longer borders. Scaling constants aren't going to do it for something like Chile.

SVG is kind-of terrible for maps, but you can get pretty small with GeoPackage (read: sqlite). I recently spent a bit too long on exactly this problem and ended up with the following.

116KB - 5MB for country borders

16MB - 52MB for ~50K city/county level borders based on geoBoundaries

The range of sizes depends on how much custom compression/simplification you put into it. The source files are about 10x bigger, but that's already pretty small.

Topojson might be even smaller though.

Check the repo for details /selfplug https://github.com/SmilyOrg/tinygpkg-data

Thank you we forked your repo! What makes you say SVG is kind-of terrible for maps?

Thanks!

Well, mostly that it's text / XML you usually have to parse in full and boundaries are data heavy, so if you have anything more than a world map, I don't see that working very well.

In contrast with the OP or GeoPackage, you can query by tiles/range and only extract the boundaries you need if you're zoomed in somewhere. If you use Tiny Well-Known Binary compression, you can also shrink the data quite a bit while keeping the querying capabilities.

But if you only ever need to render the whole thing, topojson is probably the winner as it cleverly encodes only unique borders once, so it tends to be a lot smaller.

And of course if SVG works for your case, go ahead and use it, it's surely the easiest way to render vector gfx in the browser :)

Thank you for that! I love your analysis. Really appreciate you teaching me more about this. :)

You're welcome!

So, you're still going to be better off with a tiled overview sort of system.

FWIW, I've got an official 900MB geojson of borders from a large unnamed multinational NGO type that's particular about their mapping.

At z=4, or 600m resolution, it's a 2.5MB pmtiles, at z=10 (10m resolution) it's 83M.

That's just the ADM0 borders, adding local borders would obviously increase the size.

I'm a total noob to all this, so I totally get if you can't help--it's not your problem, no worries! But would you be able to share any code to convert this, or any of the data?

I can't share this data, but there are a couple of ways to get started:

1) Just use the overview tiles from the global protomaps dump (OSM source). The getting started guide can walk you through some of it: https://docs.protomaps.com/guide/getting-started but you'd want to use the pmtiles tool to extract the widest zooms from the global dataset.

  pmtiles extract https://build.protomaps.com/20231023.pmtiles overview.pmtiles \
      --maxzoom=4

Then see the intro to pop it in a viewer, or it's a few dependencies and a style sheet and it pops into OpenLayers, Leaflet or MapLibre for a viewer. There may be some extra layers there, but at wide zooms there shouldn't be much data there. (e.g. buildings)

2) If you have/find your own data, use Felt/tippecanoe to convert it.

  tippecanoe -z4 -o overview.pmtiles data.geojson

Thank you! No worries at all, I totally understand. Just thank you for replying!

I really appreciate you showing me how to do that. Thank you very much!

But protomaps is still getting the map data from a CDN, do you mean that the map data would be cached on the device?

Yes. With the tradeoff that it would be radically simplified.