菜单
How to choose and configure data sources for MapLibre GL JS — rendering your own data without tiles, hosted tile services, serverless PMTiles, self-hosted tile servers, tile schemas, glyphs, and sprites.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Migrating from Mapbox GL JS to MapLibre GL JS — package and import changes, removing the access token, choosing tile sources, plugin equivalents, and what you gain or give up. Use when moving an existing Mapbox map to MapLibre.
Serverless vector and raster tiles with PMTiles for MapLibre GL JS — single-file format, HTTP range requests, hosting on S3/R2/GitHub Pages, generating with Planetiler or tippecanoe, and the pmtiles protocol. Use when you need no tile server or want to host tiles from static storage.
| name | maplibre-tile-sources |
| description | How to choose and configure data sources for MapLibre GL JS — rendering your own data without tiles, hosted tile services, serverless PMTiles, self-hosted tile servers, tile schemas, glyphs, and sprites. |
MapLibre GL JS does not ship with map data. You provide a style that references sources — URLs or inline data that MapLibre fetches and renders. MapLibre works equally well for a store locator with 200 addresses, a city transit map, and a global basemap — the right source type depends on geographic scale and level of detail, update frequency, infrastructure constraints, and use case.
A style (a style JSON, style document, or style object) is the configuration you pass to MapLibre. It contains the specific rendering rules governed by the MapLibre Style Specification, maintained with parity for MapLibre GL JS and MapLibre Native.
You can use a style URL from a provider — that URL references a style with sources, layers, glyphs, and sprite. Or you can build your own style and configure each yourself.
A style has three main components:
type and either inline data or a URL. MapLibre requests tiles or data as the viewport changes. The same source can back many layers (e.g. roads, water, and labels all from one vector URL).source-layer name) and specifies paint/layout properties.Source types:
| Type | Description |
|---|---|
vector | Vector tiles — binary-encoded geometry and attributes; the primary format for basemaps and data overlays |
raster | Raster tile imagery — satellite photos, WMS/WMTS layers |
raster-dem | Elevation tiles — for terrain rendering and hillshading |
geojson | GeoJSON data — inline object or URL; no tile server needed |
image | A single georeferenced image — scanned maps, annotated overlays |
video | Georeferenced video |
vector and raster are the most common for basemaps and data overlays. geojson is ideal for small datasets or interactive data that doesn't need tiling. raster-dem is used for terrain and hillshade effects, as well as emerging use cases in scientific visualization. image and video sources are the least common, but let you georeference static images (such as a scanned map, chart, or overlay) or georeferenced videos as map layers.
For many use cases you don't need a tile service. MapLibre can render points, lines, or polygons directly from an inline GeoJSON object or a URL to a GeoJSON file. The entire dataset is downloaded and parsed in the browser; MapLibre handles rendering client-side.
map.addSource('my-data', {
type: 'geojson',
data: '/path/to/data.geojson' // or an inline GeoJSON object
});
map.addLayer({
id: 'my-layer',
type: 'fill',
source: 'my-data',
paint: { 'fill-color': '#0080ff', 'fill-opacity': 0.5 }
});
GeoJSON downloads the entire file on every load. This works well at small scale and degrades predictably:
| Range | File size / feature count | Behavior |
|---|---|---|
| Sweet spot | < 2 MB / < 5,000 features | Instantaneous loading, smooth interaction |
| Lag zone | 5–20 MB / up to ~50,000 features | 1–3s parse delay; mobile may struggle; optimize by simplifying geometries and reducing coordinate precision |
| Crash zone | > 50 MB / > 100,000 features | High risk of browser freeze or crash; switch to vector tiles |
GeoJSON is lossless (exact coordinates preserved) and gives you full client-side access to feature properties — ideal for interactive data, dynamic updates, and datasets where you need to query or modify features without a server round-trip.
If your dataset exceeds these thresholds, or if you need zoom-dependent rendering (less detail at lower zoom levels), consider vector tiles instead.
The choice of data source is shaped by more than performance: data type, update frequency, access patterns, and the broader geospatial ecosystem all factor in. Many formats (FlatGeobuf, GeoParquet, Cloud-Optimized GeoTIFF, KML, GPX, and more) can be displayed in MapLibre via plugins and custom protocols. The cloud-native geospatial ecosystem — formats designed for HTTP range requests and distributed storage — is evolving rapidly and increasingly relevant for web maps. A separate skill will cover this in depth; for now, see the Map Rendering Plugins and Utility Libraries sections of awesome-maplibre.
Vector tiles load only the data visible in the current viewport, in a compact binary format. Use them when:
When you need tiles, you'll choose between two tile types:
Vector tiles encode geometry and feature attributes as compact binary data (Mapbox Vector Tile format, or the newer MapLibre Tile / MLT). MapLibre renders and styles them client-side:
Raster tiles are pre-rendered images (PNG, JPEG, or WebP) at each zoom level, displayed by MapLibre as-is:
Most MapLibre workflows use vector tiles; increasing numbers are integrating raster-dem sources e.g. for terrain rendering. Use raster tiles when you need satellite/aerial imagery, when integrating with existing WMS or WMTS services, or when you need a pre-rendered cartographic style.
Leaflet is a widely used JavaScript mapping library that supports only raster tiles. If your app is built on Leaflet, MapLibre GL Leaflet lets you pre-render a MapLibre GL compatible style as a raster layer — allowing you to use hosted vector tile sources in your Leaflet app.
A MapLibre style can have any number of sources of any types simultaneously. Layers from different sources are composited in draw order. This makes it natural to mix sources for different purposes.
Sources can be composited in a custom style sheet or at run-time. Be aware that layer order matters: layers are drawn bottom-to-top in the order they appear in the style. A raster layer added after vector layers will obscure them.
map.addSource() and map.addLayer(). To keep labels readable, insert your layer before the first symbol layer rather than appending to the top of the stack.// Start with any basemap style URL, then add your own data below labels
map.on('load', () => {
// Find the first symbol (label) layer to insert below
const firstSymbolId = map.getStyle().layers.find((l) => l.type === 'symbol')?.id;
map.addSource('my-data', { type: 'geojson', data: '/path/to/data.geojson' });
map.addLayer(
{ id: 'my-layer', type: 'circle', source: 'my-data' },
firstSymbolId // insert before labels; omit to append above everything
);
});
raster-dem source (elevation tiles). This is how MapLibre renders terrain and hillshade without a separate basemap style.Most real-world apps combine source types — a hosted basemap for the reference layer and your own data as a separate source. You rarely need to build a custom tile pipeline just for your data.
| Scenario | Recommended source setup |
|---|---|
| < ~5,000 features, need click/hover interaction or live updates | GeoJSON — no tile server needed |
| 5,000–100,000 features | GeoJSON if you can simplify and accept 1–3s load delay; otherwise vector tiles |
| > 100,000 features or > 50 MB | Vector tiles — generate with tippecanoe or Planetiler |
| Street, terrain, or place basemap | Hosted tile service (OpenFreeMap, MapTiler) or self-hosted (Martin) |
| Your own data over any basemap | Hosted basemap style URL + your data as a separate GeoJSON or vector tile source |
| Satellite/aerial imagery + labels | Raster tile source for imagery + vector source for roads and labels |
The key distinction: the basemap and your data are almost always separate sources, even if both are vector tiles. The basemap provides context; your sources provide your application's data. Mixing them into a single custom tile source is rarely the right approach unless you are building a self-hosted map with full control of the tile pipeline.
"Hosting" tile data can mean two different things:
.pmtiles archive (or pre-generated tile directory) lives on static storage like S3, R2, or GitHub Pages. No server process runs; MapLibre fetches tiles over HTTP using range requests or standard HTTP. Updates require regenerating and re-uploading the file.The three options below map to these two approaches: PMTiles is file-based and serverless; hosted tile services run tile server infrastructure on your behalf; self-hosted means you run your own server.
PMTiles is an open single-file tile format that supports vector or raster tiles — MapLibre fetches only the byte ranges it needs via HTTP range requests, with no tile server. Extract only the geographic scale you need, and host a .pmtiles file on static storage (S3, R2, GitHub Pages).
See maplibre-pmtiles-patterns for setup.
Many providers offer hosted vector or raster tiles and pre-built style and tile URLs — no server to run. See Map/Tile Providers in awesome-maplibre for a full list.
For a no-key starting point, OpenFreeMap provides free hosted OpenStreetMap tiles with MapLibre-ready styles (https://tiles.openfreemap.org/styles/liberty or /positron). It is community-funded — if your app depends on it in production, consider donating or self-hosting to reduce load on shared infrastructure.
Do not use tile.openstreetmap.org in production or for anything beyond very limited testing. The OpenStreetMap Foundation prohibits bulk and high-traffic use of their tile server; violating this blocks your IP. Use a hosted provider or self-host instead. See switch2osm.org/providers for a current provider list.
Store API keys in environment variables; never commit to source control.
Run your own server for full control over data, cost, and deployment. See Tile Servers in awesome-maplibre for options, including the MapLibre-maintained 💙 Martin. Use an existing tile schema or generate custom tiles with Planetiler or tippecanoe.
A custom style is one you write yourself, rather than using a provider's pre-built style URL. Custom styles can reference either hosted or self-hosted tile sources — and in practice, the most common pattern is both:
The most common real-world pattern is a hybrid: a custom style that references a hosted provider's basemap tiles — and often reuses their glyphs and sprite — while adding self-hosted tile sources or GeoJSON overlays for your own data. This gives you full control over your data layers without building basemap tile infrastructure from scratch.
When building a custom style (rather than using a provider's pre-built style URL), you need to know the tile schema — the source-layer names and their properties. Your style's layer definitions must match the schema of your tile source.
Common schemas:
transportation, water, landuse, poi. The largest ecosystem of community styles targets this schema.land, water, roads, places; optimized for serverless delivery.If you use a provider's pre-built style URL, the schema is already matched.
Every MapLibre style that shows text or icons needs:
"glyphs": "https://example.com/fonts/{fontstack}/{range}.pbf".json and .png) — "sprite": "https://example.com/sprites/basic"Pre-built style URLs from hosted providers include their own glyphs and sprite. When building a custom style or self-hosting, you must supply these URLs.
If you are modifying a style based on a pre-defined tile schema, look for an existing style that matches that schema and reuse the glyphs and sprites. Pay attention to licensing and attribution requirements when reusing assets. If needed you can host the same glyphs and sprites yourself by downloading the files and serving them from your own storage or tile server.
The alternative is to generate your own glyphs and sprite sheets. See Font Glyph Generation and Sprite Generation in awesome-maplibre for tools to generate your own.
TileJSON is a standard JSON format for describing a tileset — its tile URL template, zoom range, bounds, center, attribution, and (for vector tiles) the available source-layers. Tile servers and providers expose TileJSON endpoints; MapLibre can consume them directly.
Tiles are addressed by zoom (Z), column (X), and row (Y) — a universal scheme across raster and vector tile sources (see the OpenStreetMap wiki for more information). In a MapLibre source, you reference tiles either directly via a tiles URL template or via a url pointing to a TileJSON endpoint.
When a TileJSON endpoint is available, prefer url: MapLibre fetches the document and reads the tile URL template, zoom range, bounds, attribution, and (for vector tiles) the available source-layers automatically. Tile servers like Martin and tileserver-gl generate TileJSON endpoints for every tileset they serve, as do many hosted providers.
When no TileJSON endpoint exists — for example, a raw raster tile service that gives you a URL template directly — use the tiles array and specify any metadata (minzoom, maxzoom, attribution) in the source definition yourself.
tiles array:
{
"type": "vector",
"tiles": ["https://example.com/tiles/{z}/{x}/{y}.pbf"],
"minzoom": 0,
"maxzoom": 14
}
url to TileJSON endpoint:
{
"type": "vector",
"url": "https://example.com/tiles.json"
}
For vector sources, the TileJSON vector_layers field lists each available source-layer, its attribute fields, and its zoom range. This is the authoritative reference when building a custom style: your layer definitions must reference source-layer names exactly as they appear here.
When generating tiles with Planetiler or tippecanoe, the output embeds TileJSON metadata in the MBTiles or PMTiles file. Tile servers like Martin read this metadata and expose it as a TileJSON endpoint automatically.
If your tiles, glyphs, or sprites are on a different origin, the server must send CORS headers (Access-Control-Allow-Origin). Otherwise the browser blocks requests and the map will be blank or missing labels.
Hosted providers handle CORS for you. For self-hosted servers or static storage, configure CORS on the server or CDN.