[HN Gopher] MapLibre Tile: a modern and efficient vector tile fo...
___________________________________________________________________
MapLibre Tile: a modern and efficient vector tile format
Author : todsacerdoti
Score : 381 points
Date : 2026-01-26 10:19 UTC (12 hours ago)
(HTM) web link (maplibre.org)
(TXT) w3m dump (maplibre.org)
| ccev wrote:
| MapLibre is an awesome project, their JS library is by far the
| best way to display maps in the browser that I've come across.
| Very excited to eventually switch to this format!
| Humphrey wrote:
| This 100%
| pratio wrote:
| This is interesting. We recently deployed a solution that uses
| pmtiles and it's great.
|
| https://docs.protomaps.com/pmtiles/
|
| afaik, pmtiles uses mvt, let's hope the tooling to convert the
| tiles to mlt also becomes available.
| Humphrey wrote:
| Oh pmtiles is such a simple and innovative solution!
| pratio wrote:
| Yes, Absolutely in love with it. Loading tiles with range
| requests made our application so much faster.
| jtbaker wrote:
| It's very cool! If you want to get higher cache hit rates
| from a CDN or redis etc. and lower the amount of S3 reads,
| you can get set up a proxy to convert `/{z}/{x}/{y}.mvt`
| requests into the byte-range requests:
| https://docs.protomaps.com/deploy/
|
| Brandon has some example code you can lift to dump it into
| a Cloudflare Worker or other platforms on that page.
| pratio wrote:
| Thank you. I'm going to try this on a different project
| that we have. Our current deployment is designed to work
| directly through s3/api gateway which reduces the number
| of moving parts.
|
| We update the tiles frequently, so the setup has been
| amazing for us.
| jarl-ragnar wrote:
| It is. I've found it so useful I created an Elixir library to
| act as a cache in front on a pmtiles file.
| https://hex.pm/packages/ex_pmtiles
| dzogchen wrote:
| PMTiles is actually pretty agnostic to what kind of tiles it
| contains! There is already a PMTiles PR that updates the byte
| that specifies the type of tile to include MLT.
|
| https://github.com/protomaps/PMTiles/pull/596
| pratio wrote:
| Oh wow, thank you, looking forward to this
| thibaut_barrere wrote:
| Neat, as someone integrating PMTiles right now, thank you!
| jamessb wrote:
| PMtiles is often used with MVT tiles, but it can encapsulate a
| variety of tile types: the current spec [1] has defined tile
| types for MVT, PNG, JPEG, WebP and AVIF (plus "Unknown/Other").
|
| [1]:
| https://github.com/protomaps/PMTiles/blob/main/spec/v3/spec....
| pratio wrote:
| Absolutely, we have MVT tiles at the moment, I'm hoping to
| test MLT soon
| maelito wrote:
| I'm building PMTiles through Tilemaker, PMTiles is incredible,
| but sadly it will take a lot of work to produce MLT though
| Tilemaker :/
| Koffiepoeder wrote:
| Had to search a bit, but here's a demo page:
| https://maplibre.org/maplibre-gl-js/docs/examples/display-a-...
| Can be compared with: https://maplibre.org/maplibre-gl-
| js/docs/examples/display-a-...
|
| In that example I saw this in the console:
| before - 2.41+26.29+24.87+71.28+59.2+77.57 - 261.62kb
| after - 2.45+22.4 +22.66+60.6+51.99+77.57 - 237.67kb
|
| So roughly a ~10% compression improvement, neat!
| dzogchen wrote:
| Note that the demotiles style is not really comparable to a
| production basemap such as ones based on the popular
| OpenMapTiles schema. The article linked in the announcement has
| some more findings related to compression ratio.
|
| Also note that lightweight encodings are built into the format,
| and different tiles can even be encoded in a completely
| different way. So you have to use heuristics to find the best
| combination of encodings and often you need to make a trade off
| between tile size and decoding performance. It is still early
| days for MLT, but all this means there are a lot of
| possibilities for optimization. In fact, AWS is again financing
| work on MLT this year, with a focus on optimization.
|
| Lastly, when benchmarking tile size, it is good to look at
| actual usage patterns instead of size of the total tile set.
| Nobody is zooming into a random spot in the ocean, for example.
| ;-)
| twelvechairs wrote:
| Looks great. I wish there was similar advancement for full 3d
| tiles. The only real option at the moment is cesiums 3d tiles
| format which is nowhere near as fast as it could/should be
| QuiCasseRien wrote:
| All links in the top navigation are broken (404).
| dzogchen wrote:
| Sorry about that. Noticed the footnote was broken.
|
| Fixed the footnote, broke all other links. Should be OK again
| when the caches catch up.
| adim86 wrote:
| I find it shocking that a reputable resource such as this is
| still displaying the size of Greenland or Africa wrong (Mercator
| projection) in relation to other land masses in its marketing
| material and documentation, like here. It just brings doubt to
| the whole project, which is a shame considering all the time they
| must have put in. Why show the map that way when majority of its
| users will never use it for nautical navigation?
| https://maplibre.org/maplibre-gl-js/docs/examples/display-a-...
| bottled_poe wrote:
| Accuracy where it matters is why. Do you have a better
| suggestion for projecting a sphere onto a rectangle?
| einpoklum wrote:
| I would not use such strong rhetoric as the GP, but I believe
| they probably mean we should lean towards using the
| Gall/Peters projection, which maintains lengths and areas,
| but not angles.
|
| (There are of course other projections with other interesting
| features; or you could take the same projection but center
| the world differently etc.)
| willtemperley wrote:
| Web Mercator does not preserve angles.
|
| We're currently forced to use a projection that is strictly
| worse than what it was based on, the Mercator projection,
| created in 1569.
|
| Everyone on this thread needs to read this presentation
| entitled "Use Literally Anything But Web Mercator":
|
| https://www.esri.com/content/dam/esrisites/en-
| us/events/conf...
|
| Let's say that a bit louder shall we:
|
| USE LITERALLY ANYTHING BUT WEB MERCATOR.
| ecshafer wrote:
| Why? Why is lengths and areas more important than angles?
| You have to choose one, its essentially arbitrary.
| Personally I find it more useful to know what is parallel
| to what and what is at which angles from what, than some
| size. We have globes, so we know what the "real size" of
| Greenland looks like... this has always been a silly
| argument from the overzealous online looking for right
| wrongs that don't exist.
| willtemperley wrote:
| WEB MERCATOR DOES NOT PRESERVE ANGLES.
| ecshafer wrote:
| I know. But they mentioned Mercator, not Web Mercator.
| willtemperley wrote:
| They were talking about Web Mercator but didn't know they
| were!
| willtemperley wrote:
| This comment is inaccurate! Web Mercator causes such large
| errors in geolocation that the NGA had to issue an advisory
| about it [1].
|
| There is a whole science behind map projections and Google
| ignored it entirely when they created Web Mercator, which was
| a hack to divide the world into a quad tree. It was vaguely
| clever and utterly stupid at the same time.
|
| [1] https://web.archive.org/web/20140607003201/http://earth-
| info...
| willtemperley wrote:
| > Accuracy where it matters is why
|
| Why the downvotes for correcting this laughable statement?
| Web Mercator is well documented as being extremely
| inaccurate.
| mmooss wrote:
| Hi - I understand you feel strongly; your Web Mercator
| input is interesting. I would just focus on the
| intellectually interesting part - people might not get
| it; you can't control that or compel them to.
|
| You've been repeating essentially the same comment,
| writing in all caps (in some comments), complaining about
| downvotes, telling everyone they are idiots one way or
| another. None of those things are likely to be welcome.
| workmandan wrote:
| Web Mercator is the standard projection used on the web, if you
| think the we should use a different projection on the web then
| that's a completely separate argument
| lars_francke wrote:
| Because that's what everyone is used to.
|
| Maplibre supports different projections if you want.
| dzogchen wrote:
| It's on our roadmap to support alternate projections, but as
| you can imagine it's a big project that so far nobody has been
| willing to pay for to implement unfortunately.
|
| MapLibre GL JS does support globe mode.
| https://maplibre.org/maplibre-gl-js/docs/examples/display-a-...
| May we should update our examples to use globe mode when
| showing examples, especially those that show a world map. We
| will take that feedback into consideration!
|
| You can use the Equal Earth projection with a plugin:
| https://equal.bbox.earth/maplibre-americas/
| readyplayeremma wrote:
| MapLibre's globe mode is both fantastic and performant. Also,
| it's literally just the one option to change it, and your
| tile formats/CRS don't need to change either.
|
| It's the easiest way to escape from web mercator projections
| with no real downsides that I have discovered yet. Also,
| there is a built-in control if you want to offer a button to
| toggle between web mercator view, and globe view, since it's
| all just rendering changes.
| techterrier wrote:
| obligatory West Wing: https://www.youtube.com/watch?v=vVX-
| PrBRtTY
| ecshafer wrote:
| This episode never made any sense at all. We already have
| globes for true sizes.
| willtemperley wrote:
| It's actually worse than that because the Web Mercator
| projection is unusable for navigation too - it doesn't preserve
| angles or area! (Angles are nearly preserved).
|
| Well done Google. Slow handclap.
|
| The NGA advised it's likely to cause geolocation errors of up
| to 40km near the poles:
|
| https://www.gpsworld.com/nga-issues-advisory-notice-on-web-m...
| Flatterer3544 wrote:
| You're a bit hasty, for the users that needs mercator
| projections, they should be able to get it, see:
| https://maplibre.org/maplibre-gl-js/docs/API/type-aliases/Pr...
| trgn wrote:
| Web mercator is fantastic map. It's well known of course, so
| very helpful to orient. Plus, its square and easily tile-able,
| which is good for performance. Shapes of countries are
| preserved. Plus, the lines are straight, which works great for
| on screen. Neat and tidy.
|
| Who cares Greenland looks big when zoomed out. "Mercator
| distorts size" is one of those gis-nerd idee fixes, the first
| factoid they learn in class, and it overwhelms all thought.
| mmooss wrote:
| > Who cares Greenland looks big when zoomed out.
|
| You never know - one day, the geography of Greenland could
| matter quite a bit to the rest of the world.
| fragmede wrote:
| Maybe you shouldn't have skipped that class if you don't
| think it's important.
| dan-robertson wrote:
| I'm not sure it's very useful to rehash an argument with very
| tenuous relation to the OP here. The normal reason to use the
| Mercator projection in these situations is (a) it's what people
| are used to and (b) it preserves angles so if you zoom in on a
| street then up will still be north and roads that are at right
| angles in the real world appear to be at right angles on the
| map. The latter property is pretty desirable and hard to
| achieve without doing some weird transition between projections
| as you zoom. This matters more for Europe (and I suppose parts
| of British Colombia) where there is a high population density
| at latitudes that are pretty extreme in much of the world.
|
| I think Apple Maps has a pretty reasonable compromise here of
| transitioning from a globe to Mercator as you zoom, but this is
| a less nice UI with a mouse as you need to click to rotate the
| globe instead of pointing and zooming only. I don't think
| there's anything in this data that would make that unachievable
| - you just need to reproject the vector data a bit as you zoom
| out - but it takes some tricky mathematics to get right and so
| hasn't been done yet.
| willtemperley wrote:
| It's an important discussion because it's abundantly clear
| that almost nobody on this thread has a clue what they're
| talking about.
|
| Web Mercator != Mercator.
|
| I suggest most people on this thread need to go away ask the
| question "What's the difference between Web Mercator and
| Mercator".
| Symbiote wrote:
| For most uses of web maps (navigation on foot, by bicycle
| or by car) the angles seem to be close enough with Web
| Mercator, and the map is zoomed in to a small area so
| there's no concern about the area.
|
| No-one is zooming out the "Find your nearest Tesco" map to
| see Greenland.
| xigoi wrote:
| Not everyone has a spherical monitor.
| mourner wrote:
| You can read more about why most web maps are like this and a
| quest to fix this in this article:
| https://www.mapbox.com/blog/adaptive-projections
| einpoklum wrote:
| I am not familiar with the ecosystem of geographic data and
| mapping as online services. Can someone please explain...
|
| * How this tile format, or the organization behind it, related to
| OpenStreetMap (if it is related at all)?
|
| * Why the need to replace the previous tile format / scheme which
| they mention?
|
| * What challenges such a project faces (other than, I suppose,
| being noticed and considered for adoption)?
| wiredfool wrote:
| 1) It's not. Maplibre is a JS library for displaying map data.
| OpenStreetMap is a collection of map data that is published in
| various formats. Different levels of the stack.
|
| 2) It's an optimization/advancement. There are some pain points
| in the older version that 10 years of experience can fix in a
| newer format.
|
| 3) Attention, funding. Technically, they're at the leading edge
| of open source.
| WorldMaker wrote:
| Additionally to point 2, the older format was created by a
| company (Mapbox) that used to be open source-friendly but has
| recently made a larger pushback against open source and open
| standards, changing the licenses of much of their formerly
| open source work. (The Maplibre JS library itself is a fork
| of that company's previous open source work from its last
| open source drop to keep the work open source.)
| mmooss wrote:
| > There are some pain points in the older version that 10
| years of experience can fix in a newer format.
|
| What were the major pain points? Compression ratio and speed
| seem like two of them. (Thanks for answering the elementary
| questions.)
| usrusr wrote:
| The key info token you'll want to know as someone foreign to
| map topics is that maplibre is a licence continuity fork of the
| formerly open source Mapbox code.
|
| Everything else pretty much derives from this, e.g. yeah, OSM
| did not suddenly go all in on former mapbox stuff only because
| the company started keeping updates behind a paywall, OSM
| continues to be as tool-agnostic as ever.
| maelito wrote:
| Unfortunately, Tilemaker hasn't planned or cannot plan to support
| MLT in the medium-term.
|
| That will leave a significant part of the community out of this
| transition.
|
| See this interesting (and quite heated) discussion :
| https://github.com/systemed/tilemaker/issues/856
| sjg-wet-dog wrote:
| You can always convert after the fact. Just go from MVT to MLT.
| There's a Java based program in the repo.
| willtemperley wrote:
| Another thing worth mentioning is it's very similar to the
| structure of columnar formats like Arrow and Parquet. Anyone with
| familiarity with these formats could build a decoder in a couple
| of days. If they don't use FastPFOR.
|
| I really wish they hadn't used FastPFOR. It's a research library
| and has an incredibly opaque algorithm:
|
| https://ayende.com/blog/199523-C/integer-compression-underst...
| ltbarcly3 wrote:
| "Modern" is such a silly way to advertise things.
| xigoi wrote:
| Although the word is overused, hindsight can be a huge
| advantage in design.
| sjg-wet-dog wrote:
| It should be backed up, for sure. Like how is this modern?
|
| In this case it's the column format for attributes and the
| newer encodings. Things the industry wasn't doing a decade ago.
| dzogchen wrote:
| We don't have a marketing department, so we're happy to take
| suggestions on our messaging!
|
| What makes it modern are the ideas behind it: the column-
| oriented layout, support for lightweight encodings such as FSST
| and FastPFOR and support for pre-tessellation. Also, enabling
| doing more computations on the GPU instead of the CPU, which
| are made possible thanks to modern graphics APIs like Vulkan
| and Metal. I agree that it is better to be specific about these
| things (if that is your gripe with it), but there's only so
| many characters that fit into a title. ;)
| mattrighetti wrote:
| Does anyone self host maps? If you do, mind sharing the pros,
| cons and tools to do that?
| homebrewer wrote:
| We've been self-hosting protomaps (aka pmtiles) for several
| years. The only thing you need server-side is a web server that
| can serve static files and supports range requests (so anything
| works; I've tried caddy and nginx). The map is one large file,
| it's easy to share it between however many servers you need.
|
| https://docs.protomaps.com/guide/getting-started
|
| Downsides? Nothing major that I can think of. You have to add
| another client-side dependency (support for their custom
| protocol); the library is pretty small and easy to audit.
|
| Editing map styles is slightly more difficult because generic
| maplibre styles won't work with it: they add a bit of custom
| sauce on top. IIRC this editor worked fine, you can import one
| of protomaps styles and base your work off it:
|
| https://maputnik.github.io/editor
|
| That's probably it.
| throw_away_623 wrote:
| Are the names of cities/streets included in the tiles, or do
| they have to be placed from a different data source?
| homebrewer wrote:
| No, the names are there in the file, streets included.
| Their default styles did not support the languages we
| needed out of the box (everything was shown in the local
| language or English IIRC), but it was easy to fix by
| patching the style. I don't remember the exact fix, but it
| was about as simple as replacing something like `["get",
| "name_en"]` with `["get", ["coalesce", "name_xx",
| "name_en"]]`.
| throw_away_623 wrote:
| Is there enough information to show exact addresses? For
| example "221B Baker Street"
| homebrewer wrote:
| Sure. You can look at their demo, it uses the exact same
| single-file hosting mechanism (the network requests tab
| in the browser dev tools confirms it -- it doesn't send
| any other requests), and street/house addresses are
| visible on the map.
|
| https://maps.protomaps.com
| yuretz wrote:
| How do you update pmiles? Do you have to rebuild the entire
| map every time? If so, I think that's a downside/limitation
| for some use cases.
| linsomniac wrote:
| We use mod_tile+renderd:
| https://github.com/openstreetmap/mod_tile
|
| In short: We have a script that builds a pbf of the area we are
| interested in (Colorado, USA) from OSM, then set up a
| openstreetmap-tile-server container with that data, bring in
| our styles, and then set up renderd.
| davidkwast wrote:
| I do. The pros are hosting own data and have total control over
| stack and cloud hosting. The cons are having to code your own
| stack and do cloud management. I use PostGis to storage and
| serve vector tiles. And I use a simple backend with AWS S3 to
| store and serve raster data (GeoTiff COG).
| matt-p wrote:
| Respect this commitment. I think to be honest I'd only ever
| consider hosting a tile server if I was actually rendering
| data on the tiles or there was something 'special' about them
| (e.g style). Using $whatever hosted tiles are likely to be
| faster for the user as they'll be cached, served statically.
| shirol wrote:
| Unrelated, but I noticed that clicking the logo goes to the
| current permalink rather than the homepage, might be
| unintentional.
| zylepe wrote:
| Planetiler currently supports generating MLT by adding ---tile-
| format=mlt cli argument. It's only on latest main right now but I
| should be able to get a release out in the next few days. In my
| testing I've seen ~10% reduction in overall OpenMapTiles archive
| size with default settings but there are some more optimizations
| the team is working on that should bring it down even further.
| edward wrote:
| Come to the MapLibre talk in the Geospatial devroom at FOSDEM on
| Saturday
|
| https://fosdem.org/2026/schedule/event/QAL9VN-state-of-the-m...
| akpa1 wrote:
| If one can fit :P
| Dowwie wrote:
| I <3 Martin and the team that built it. It's great to see that
| the Rust stack they used is the one I contributed to, now 8 years
| ago. Aging like fine wine!
| neiman wrote:
| It's cool that stuff like vector file formats is still being
| reinvented. What's the new idea(s) here, though?
|
| Like, I get that it's new and has better features (better
| compression, faster decoding, etc.) --- but what are the new
| ideas or insights that led to this design?
| mips_avatar wrote:
| I just want support for globe view on maplibre native
| bikelang wrote:
| Been following this for a little bit and am extremely excited for
| this. I think the final big hurdle for adoption (for those of use
| in the MapLibre stack at least) will be getting an equivalent
| As_MLT() function added to PostGIS.
| tjwebbnorfolk wrote:
| and support in Geoserver
___________________________________________________________________
(page generated 2026-01-26 23:00 UTC)