GeoLibre Supported GIS Data Formats — Complete Reference¶

Abstract: This article provides a comprehensive inventory of all GIS data formats natively supported by GeoLibre, covering vector, raster, and cloud-native geospatial formats, along with the internal parsing logic for each format. It serves as a complete technical reference for WebGIS developers.

Original source: "GIS开发手记", original link: https://mp.weixin.qq.com/s/GrtQzetCBgKtYruEhjsOAw

Preface¶

This article systematically catalogs every geospatial data format built into GeoLibre, distinguishing between vector, raster, and cloud-native geospatial formats, while documenting each format's corresponding parsing dependency, read priority, and applicable scenarios — a ready reference for WebGIS developers.

1. Runtime Configurations & Platform Overview¶

Before listing formats, it's important to clarify "where it runs," since many formats have platform-specific differences.

No accounts, no servers, no fees for the core application. Local files are read in place and stay on your machine, and once the app has loaded, local workflows keep working offline. The optional remote pieces are the exception: online catalogs (STAC, Source Cooperative, Overture, Planetary Computer), basemap and tile downloads from a CDN, and services such as Earth Engine or an authenticated ArcGIS endpoint all need network access, and some need their own credentials or OAuth sign-in.

2. Vector Data Format Support¶

Vector data is GeoLibre's most mature capability. The file picker has a built-in unified format allowlist, supports drag-and-drop auto-detection (no manual format selection needed), and covers 17 mainstream vector extensions.

geojson, json, gpkg, geoparquet, parquet, fgb, flatgeobuf,
csv, tsv, kml, kmz, gml, gpx, dxf, tab, shp, zip

Just drag and drop — no need to first select "which format to import."

What's truly interesting is which engine reads each format behind the scenes — this determines actual performance:

Explicitly unsupported: .xlsx / .xls (zero hits in a full-repo search), raw .osm XML (PBF only). If you need Excel data, save as CSV first.

After loading, it's not just "can you see it" — symbology, graduated coloring, and legends all come along:

3. Raster & Imagery¶

The raster side is narrower than vector but covers the cloud-native mainline.

Note the asymmetry: .img, .vrt, .asc, .jp2, .hgt are only recognized in conversion tools — they cannot be directly dragged in as layers. Drag-and-drop only works for GeoTIFF.

4. Point Clouds & LiDAR¶

The LiDAR layer panel's extension allowlist is not in this repository — it's defined in upstream npm packages. The only direct evidence in the repo is a single .copc.laz example URL. LAS/LAZ/COPC/EPT are very likely supported but cannot be confirmed 100% from the source.

5. 3D Models, Tiles & Gaussian Splats¶

The opening scenario — "received some 3D Tiles, just want to take a quick look" — this section is the answer.

This screenshot is quite telling: in the layer panel on the left, 3D Tiles, vectors, XYZ, glTF models, and Gaussian splats are all stacked in the same list — and the rendering result is right there on the right. "Loading 3D Tiles requires setting up a server and writing a page" becomes paste a URL here.

What's absent: .obj is completely unsupported (zero hits). .b3dm/.pnts/.cmpt — these 3D Tiles internal formats also have zero hits in the repo; they're transparently handled by upstream loaders, so you don't need to worry about them. The Gaussian splat extension list is likewise in upstream packages.

6. Tiles & OGC Services¶

The storage layer type enum has 20 entries:

geojson, raster, wms, wmts, xyz, vector-tiles, arcgis, pmtiles,
mbtiles, zarr, lidar, gaussian-splat, 3d-tiles, cog, flatgeobuf,
geoparquet, duckdb-query, deckgl-viz, video, image

What you can fill in under "Add Data → Web Services":

7. Cloud-Native Formats & Data Catalogs¶

This section is where GeoLibre pulls ahead of traditional desktop GIS.

Scientific data formats:

Online data catalogs (browsable directly):

• STAC — Both static catalogs and STAC API supported; discover catalogs via STAC Index. Only visualizable assets (GeoTIFF / GeoJSON) can be directly added
• Source Cooperative — Bucket browser; recognizes .pmtiles .parquet .geoparquet .tif .geojson .geojsonl .ndjson .fgb .gpkg .csv
• Natural Earth — Essentially the Source Coop panel locked to opengeos/natural-earth
• Hugging Face Hub — Browse dataset repositories; can even create repos and upload
• Overture Maps — Thematic vector tiles; defaults to showing buildings only
• Microsoft Planetary Computer — STAC + TiTiler
• Google Earth Engine — OAuth login; desktop has native OAuth flow
• NASA Earthdata GIS — EOSDIS ImageServer / MapServer / FeatureServer / published web maps
• OpenAerialMap / Esri Wayback (historical imagery) / Mapillary / Google Street View
• Federal data services — FEMA flood maps, EPA EnviroAtlas, USGS National Map
• Weather & time-lapse — RainViewer real-time radar, NASA GIBS, EOX cloudless annual basemap

Planetary data (this exceeds expectations): the Moon and Mars come from OpenPlanetaryMap; Mercury, Venus, Galilean moons, Titan, Pluto, and Charon come from USGS Astrogeology. The key detail is per-project ellipsoid parameters, so distance and area measurements are accurate for the celestial body you're measuring on.

Editor's note: Initially this seemed like a surface-level feature. The per-project ellipsoid parameters changed that impression — the project treats coordinate systems seriously, not as a mere basemap overlay.

8. Project & Style Interoperability¶

This is easy to overlook but determines whether GeoLibre can fit into your existing workflow.

Key insight: Symbology configured in QGIS can be brought over, and vice versa. Style import format is determined by content, not by extension — a file with the wrong extension will still be recognized.

Additionally, there are numerous .json-based libraries: style libraries, layer libraries ("My Data"), service libraries, legends, camera fly-throughs, story maps — all importable and exportable.

9. Export & Format Conversion: Essentially a Free GDAL Frontend¶

The official site underplays this, but it's one of the most practical capabilities.

Direct Layer Export¶

Right-click a layer to export — all done in the browser, no backend needed:

.geojson · .csv · .kml · .kmz · .parquet (GeoParquet) · .gpkg (GeoPackage) · .zip (Shapefile)

GeoPackage and Shapefile writing are pure JS implementations — because DuckDB-WASM cannot write GeoPackage, the author hand-wrote a GeoPackage 1.3 writer using sql.js; for Shapefile, five files (.shp/.shx/.dbf/.prj/.cpg) are manually assembled and then zipped.

Format Conversion Tools (9)¶

Browser-side output format is a subset: geojson / json / csv / parquet / geoparquet / gpkg / zip / fgb. For the full 14-driver set, use the desktop version (via Python sidecar).

Other Exports¶

Export raster layers as GeoTIFF, clip raster subsets by bounding box, extract basemaps as PMTiles offline packages, print layout to PNG/PDF/multi-page ZIP, export entire project as a standalone HTML file, story maps to HTML/PDF, map screen recording to WebM, charts to SVG/PNG.

10. Platform Differences: Points of Caution¶

Mentioned piecemeal above, consolidated here. This is where things most easily go wrong.

11. Architecture: How It Manages to Support So Many Formats¶

After listing over a hundred formats, the natural reaction is "how complex must this be." Here's a brief explanation of how it holds together.

The core is an engine-agnostic store. The @geolibre/core package depends on neither MapLibre, nor Cesium, nor deck.gl — it stores only two things: a set of flat layer records (id, type, source, style, visibility…) and a five-field MapViewState (center / zoom / bearing / pitch / bbox).

All UI operations modify only the store; a sync layer pushes changes to the rendering engine. Strictly one-way. Dragging an opacity slider in the UI modifies the store, not a MapLibre object.

The dividend of this design: adding a format is cheap. As long as a new format can be represented as a layer record, it automatically gains the full capabilities of the layer panel — opacity, ordering, project save, style export.

Division of labor among three renderers (note: there is no "engine abstraction layer"):

• MapLibre is the default primary map; the vast majority of layers are rendered by it
• deck.gl does not occupy a separate view — it is an overlay interleaved within the MapLibre canvas, responsible for COG, 3D Tiles, I3S, Z-enabled vectors, and visualization layers. There's a hard constraint: all interleaving producers must share the same overlay instance, or later ones will wipe out earlier layers (the author encountered this firsthand)
• Cesium is a view mode within split-screen, not a replacement. It only supports GeoJSON, 3D Tiles, and imagery layers; other types are labeled "2D only" in the panel

A noteworthy detail: Cesium's camera sync is not aligned by zoom level, but by ground resolution (meters/pixel), so split-screen panels at different heights maintain the same on-screen scale.

Five compute engines, all under the same UI: DuckDB-WASM Spatial (the workhorse, running in a dedicated Worker), PGlite + PostGIS, Apache Sedona (sidecar or browser WASM version), Pyodide (running GeoPandas/Shapely in the browser), Whitebox WASM (700+ tools).

A clever approach: the Python implementation of vector operators is a "framework-free" module; the sidecar and the browser Pyodide execute the exact same code, so results from both paths are completely consistent — no "local computation doesn't match server computation" discrepancies.

12. Performance: Some Real Numbers¶

A quick overview, all verifiable numbers from the source — not estimates.

How large vectors are handled. Above 50,000 features, it stops using MapLibre's native GeoJSON source and instead tiles on-the-fly client-side — geojson-vt generates tiles (point layers use Supercluster for aggregation), vt-pbf encodes to MVT, then feeds MapLibre through a custom protocol. Max zoom 16, 4096 extent.

Two details that show engineering care: tile index objects are deliberately excluded from the store (too large, non-serializable, can't be written into a project file); encoding checks an abort signal before proceeding, since MapLibre cancels tile requests that scroll off-screen.

Other guard thresholds (these numbers are themselves good reference points):

Attribute table is virtualized, but sorting, filtering, and selection operate on the full data model — virtualization only governs rendering.

Undo history has a memory cap. Because every snapshot holds the full GeoJSON of layers, repeated editing pins multiple copies in memory. The approach: set a feature-count soft budget; when exceeded, discard the oldest snapshots, but always retain the newest one, guaranteeing at least one undo step even after a large edit. Slider drags are coalesced into a single undo record within 400 ms.

Bundle size is controlled through CDN offloading. Three heavyweight WASM engines (PGlite+PostGIS ~25 MB, CereusDB ~40 MB, gdal3.js ~28 MB + 12 MB) are not bundled. They're fetched from CDN at runtime by exact version; after first use, Service Worker caches them for offline availability. Two historical notes in source comments: bundling PGlite would inflate the binary from 42 MB to 63 MB; CereusDB would increase the installer from 27 MB to 36 MB — that's how the 30 MB installer figure is achieved.

One honest performance issue. The documentation has an entire section on Linux/WebKitGTK investigation: empty map steady at 60 FPS at any zoom, but with any tile layer present, FPS drops to single digits during tile loading, immediately returning to 60 once loading stops. Root cause: WebKitGTK performs GPU uploads for each new tile on the main thread (textures for raster, vertex buffers for vectors), with a single tile integration cycle measuring ~125 ms versus Chromium's few ms. The author ruled out software rendering, GPU saturation, Tauri IPC, JSON.parse, compositor latency, and numerous other possibilities. Mitigations (increase tile cache, 512px raster tiles, disable fade-in) are documented but not yet implemented. macOS/Windows WebViews have not been tested.

Editor's note: Projects that willingly document negative findings like this in their architecture docs are rare. This practice deserves recognition.

13. Its Boundaries¶

Having covered the strengths, let's discuss the limitations.

1. The feature scope is deliberately narrow. It focuses on browser workflows, local processing, cloud-native formats, spatial SQL, modern visualization, and portability. Complex professional workflows still belong in QGIS.

2. The iteration speed is a double-edged sword. From 0 to 2.4.0 in just over two months; 2.0.0 to 2.1.0 was separated by roughly 19 hours. If you're considering it as a long-term production dependency, factor in this churn risk.

3. Several clear format gaps. glTF/GLB has no local file picker (URL only), .obj is completely unsupported, Excel is unsupported, HDF4 is unsupported, raw .osm XML is unsupported.

4. Platform capability asymmetry. See the table in Section 10. Don't extrapolate the browser version's experience to represent the whole.

5. Cesium 3D Globe requires an Ion token. The free tier is sufficient for individual use; teams need to budget accordingly.

6. The China-specific environment. Default sources for basemaps, terrain, and Photorealistic 3D Tiles are all outside the firewall; coordinates use standard WGS84 — GCJ-02 offsets must be handled separately. These two issues need to be addressed first for serious use. Reliable first-hand data on this is unavailable; further input from actual users is welcome.

In Closing¶

You receive a zip archive containing a mix of shp, tif, gpkg, and tileset.json — previously requiring three or four different applications. The answer now: open a 30 MB application (or just a webpage), and drag everything in.

GeoLibre's real value is not that it's better than QGIS (it isn't) — it's that it drives the cost of "just take a quick look at the data" down to near zero. This niche was previously empty.

For those working with Cesium / 3D GIS development, there's an additional layer of reference value: the engine-agnostic store design. Storing state as plain layer records and view state, rather than tied to a specific rendering engine's objects, allows a second renderer to slide in smoothly. This approach is worth adopting.

Usage paths by scenario:

1. Just want to take a look — Open web.geolibre.app directly; no installation, no registration
2. Need to get real work done — Download the desktop version from GitHub Releases, or via Microsoft Store / Homebrew / winget; a two-minute process
3. Python users — pip install geolibre; for GeoPandas support, pip install "geolibre[all]"; requires Python 3.10+
4. Intranet / offline environments — VITE_PYODIDE_INDEX_URL and VITE_DUCKDB_SPATIAL_EXTENSION_PATH can point Pyodide and the DuckDB spatial extension to internal mirrors, no rebuild required; an official Docker image is also available at ghcr.io/opengeos/geolibre:latest
5. Secondary development — npm workspaces monorepo, so use npm (the repo tracks package-lock.json) on Node 22+; main application in apps/geolibre-desktop; MIT licensed

Final takeaway: for data preview and exploration, highly recommended; for production deployment, wait a bit longer — at least until the version iteration cadence stabilizes.