v0.0.8

Full Changelog: v0.0.7...v0.0.8

v0.0.7

Full Changelog: app-v0.0.6...v0.0.7

app-v0.0.6

Full Changelog: app-v0.0.5...app-v0.0.6

app-v0.0.5

Full Changelog: app-v0.0.4...app-v0.0.5

app-v0.0.4

Shell migration: Tauri → Electron

The native shell has been rewritten from the Tauri 2 / WKWebView stack to Electron 41.2.1 / Chromium 134. Same feature set, same Python sidecar, same 5-artifact matrix (.dmg, .deb, .rpm, .msi, NSIS .exe) — but the renderer now runs on the same Chromium + V8 + Dawn stack as your browser, so WebGPU scatter performance matches chrome.google.com exactly.

Why

Profiling the v0.0.3 macOS build against Chrome on the same hardware (5 M points dataset) showed pan/zoom noticeably slower in the .app than in Chrome, despite both using Metal-backed WebGPU. The gap traced to the embedded webview: WKWebView runs MapLibre's per-frame JavaScript on JavaScriptCore (vs V8 in Chrome), issues WebGL draw calls through a less-tuned Metal bridge than Chromium's ANGLE, and composites the canvas through Core Animation rather than Chromium's Viz compositor. Switching to Electron collapses all three gaps; a 5 M-point dataset now pans at Chrome-native framerate.

Changed

• Shell: Tauri 2.2 Rust binary → Electron 41 main process (TypeScript). Bundle size goes from ~500 MB (Tauri + sidecar) to ~800 MB (Electron + sidecar). Electron pays for itself in perf.
• User state migration: viewer state is still stored at {appData}/io.github.do-me.geospatial-atlas/viewer-state.json, so existing per-dataset view states from v0.0.1–v0.0.3 carry over.
• Linux runtime deps (.deb Depends): swapped WebKitGTK / GTK+3 / appindicator for the standard Chromium runtime set (libgtk-3-0, libnss3, libxss1, libxtst6, libsecret-1-0, libatspi2.0-0, libnotify4, xdg-utils, libuuid1). Most distros already have these because they're what Chrome / Edge / Firefox pull in.
• CI: dropped Rust for the shell (kept for density-clustering / UMAP WASM). Dropped libwebkit2gtk-4.1-dev + friends from the Linux runner. Build is ~35 % faster end-to-end.

Fixed

• v0.0.3 macOS: on WKWebView, MapLibre's base-map canvas and the embedding-atlas overlay both ran slower than Chrome's equivalent. Migration to Chromium eliminates the gap.
• File-picker + drag-drop now use Electron's native dialog and HTML5 DataTransfer.files path (via webUtils.getPathForFile) instead of Tauri's plugin-dialog. Behaviour is identical.

Known issues

• Still unsigned everywhere. macOS Gatekeeper shows the "damaged" message; strip quarantine with xattr -cr "/Applications/Geospatial Atlas.app". Windows SmartScreen shows "unrecognized publisher"; More info → Run anyway. Linux has no Gatekeeper equivalent.
• macOS Intel still not shipped (runner queue issue, same as v0.0.2+). Intel-Mac users: uv run geospatial-atlas ....

Downloads

Platform	File
macOS (Apple Silicon)	geospatial-atlas-macos-arm64.dmg
Linux (Debian/Ubuntu, x64)	geospatial-atlas-linux-x64.deb
Linux (Fedora/RHEL, x64)	geospatial-atlas-linux-x64.rpm
Windows (NSIS installer, x64)	geospatial-atlas-windows-x64-setup.exe
Windows (MSI installer, x64)	geospatial-atlas-windows-x64.msi

Full Changelog: app-v0.0.3...app-v0.0.4

Geospatial Atlas v0.0.3

Third tagged release of the Geospatial Atlas desktop app.

Built from commit 6571cd6 via the app-release workflow.

Headline: macOS sidecar startup fix

v0.0.2 macOS bundles crashed at startup with a FileNotFoundError on
rfc3987_syntax/syntax_rfc3987.lark — a grammar data file buried in
the MCP dep chain (mcp → jsonschema → rfc3987_syntax).
PyInstaller only bundles .py files by default, so the .lark was
left behind and from mcp import types blew up before the sidecar
could even start.

sidecar.spec now runs collect_all across mcp, jsonschema,
jsonschema_specifications, referencing, rfc3987_syntax, and
sse_starlette, so the data files travel with the bundle and the
MCP server comes up cleanly on a fresh install.

If you tried v0.0.2 on macOS and saw the app bounce in the dock or
quit silently — that was this. Grab v0.0.3 and it should launch.

Bundles

• macOS (Apple Silicon) — geospatial-atlas-macos-arm64.dmg
• Linux x86_64 — geospatial-atlas-linux-x64.deb, geospatial-atlas-linux-x64.rpm
• Windows x86_64 — geospatial-atlas-windows-x64.msi, geospatial-atlas-windows-x64-setup.exe

Still unsigned; Gatekeeper / SmartScreen will warn on first
launch. Intel-Mac users aren't served by a pre-built bundle — run the
CLI path (uv run geospatial-atlas ...) instead.

macOS: "Geospatial Atlas.app is damaged and can't be opened"

Not actual damage. Gatekeeper shows that misleading message for any
unsigned app downloaded from the internet. To bypass it:

1. Mount the .dmg and drag Geospatial Atlas to Applications.

2. Open Terminal and run:

   xattr -cr "/Applications/Geospatial Atlas.app"

   This strips the com.apple.quarantine extended attribute that
   Chrome / Safari / Firefox add to downloaded files.

3. Double-click the app — Gatekeeper stops complaining.

Alternative: after a failed launch, open System Settings → Privacy
& Security and click Open Anyway near the bottom of the page.

Proper Apple Developer ID signing + notarization is planned; until
then every new .dmg needs the xattr -cr dance once.

Linux / Windows

• .deb — sudo dpkg -i geospatial-atlas-linux-x64.deb
• .rpm — sudo rpm -i geospatial-atlas-linux-x64.rpm
• .msi — double-click; SmartScreen warns "unrecognized publisher", click More info → Run anyway.
• .exe (NSIS setup) — same SmartScreen behaviour as the .msi.

Full Changelog: app-v0.0.2...app-v0.0.3

app-v0.0.2

Second tagged release of the Geospatial Atlas desktop app.

Built from commit 85e08a8 via workflow run 24624885827.

Headline: MCP in the desktop app

The biggest change since v0.0.1 is Model Context Protocol support.
The desktop app now ships the MCP server on by default: when you load
a dataset, the idle picker has an "Expose MCP endpoint" checkbox, and
once the viewer is live the status panel shows a copy-button URL like
http://localhost:54xxx/mcp. Point Claude Desktop, Claude Code,
Cursor, Continue, or any other MCP-capable client at that URL and
you get 31 tools for driving the viewer — SQL, charts, layout,
styles, and a full suite of new geospatial tools:

• Navigation — get_map_viewport, fly_to_point, fly_to_bbox,
  set_basemap_style
• Inspection — get_map_screenshot, get_map_screenshot_at,
  count_in_bbox, find_nearby, density_grid
• Selection — select_bbox, clear_selection, highlight_points

Full tool list and config examples: see docs/MCP.md
and the README.

Bundles

• macOS (Apple Silicon) — geospatial-atlas-macos-arm64.dmg
• Linux x86_64 — geospatial-atlas-linux-x64.deb, geospatial-atlas-linux-x64.rpm
• Windows x86_64 — geospatial-atlas-windows-x64.msi, geospatial-atlas-windows-x64-setup.exe

Still unsigned; Gatekeeper / SmartScreen will warn on first
launch. Intel-Mac users aren't served by a pre-built bundle — run the
CLI path (uv run geospatial-atlas ...) instead.

macOS: "Geospatial Atlas.app is damaged and can't be opened"

Not actual damage. Gatekeeper shows that misleading message for any
unsigned app downloaded from the internet. To bypass it:

1. Mount the .dmg and drag Geospatial Atlas to Applications.

2. Open Terminal and run:

   xattr -cr "/Applications/Geospatial Atlas.app"

   This strips the com.apple.quarantine extended attribute that
   Chrome / Safari / Firefox add to downloaded files.

3. Double-click the app — Gatekeeper stops complaining.

Alternative: after a failed launch, open System Settings → Privacy
& Security and click Open Anyway near the bottom of the page.

Proper Apple Developer ID signing + notarization is planned; until
then every new .dmg needs the xattr -cr dance once.

Linux / Windows

• .deb — sudo dpkg -i geospatial-atlas-linux-x64.deb
• .rpm — sudo rpm -i geospatial-atlas-linux-x64.rpm
• .msi — double-click; SmartScreen warns "unrecognized publisher", click More info → Run anyway.
• .exe (NSIS setup) — same SmartScreen behaviour as the .msi.

app-v0.0.1

First tagged release of the Geospatial Atlas desktop app.

Built from commit e8f0bff via workflow run 24613106633. The macOS x86_64 build was abandoned after the GitHub-hosted macos-13 runner sat unclaimed for 10+ hours; subsequent releases drop that target entirely. Intel-Mac users should run the Python CLI path (uv run geospatial-atlas ...).

Bundles

• macOS (Apple Silicon) — geospatial-atlas-macos-arm64.dmg
• Linux x86_64 — geospatial-atlas-linux-x64.deb, geospatial-atlas-linux-x64.rpm
• Windows x86_64 — geospatial-atlas-windows-x64.msi, geospatial-atlas-windows-x64-setup.exe

All bundles are unsigned; expect Gatekeeper / SmartScreen prompts on first launch. MCP (Model Context Protocol) support in the desktop app ships with v0.0.2.

macOS: "Geospatial Atlas.app is damaged and can't be opened"

This is not actual damage. macOS Gatekeeper shows that misleading
message for any unsigned app downloaded from the internet. To bypass it:

1. Mount the .dmg and drag Geospatial Atlas to Applications.

2. Open Terminal and run:

   xattr -cr "/Applications/Geospatial Atlas.app"

   This strips the com.apple.quarantine extended attribute that
   Chrome / Safari / Firefox add to downloaded files.

3. Double-click the app — Gatekeeper stops complaining.

Alternative: after a failed launch, open System Settings → Privacy &
Security and click Open Anyway near the bottom of the page.

Proper Apple Developer ID signing + notarization is planned for a
future release; until then, every new .dmg will need the
xattr -cr dance once.

Linux / Windows

• .deb — sudo dpkg -i geospatial-atlas-linux-x64.deb
• .rpm — sudo rpm -i geospatial-atlas-linux-x64.rpm
• .msi — double-click; SmartScreen will warn "unrecognized publisher", click More info → Run anyway.
• .exe (NSIS setup) — same SmartScreen behaviour as the .msi.