Kriging and uncertainty
Ordinary, Universal, Empirical Bayesian and Indicator kriging; spherical, exponential, Gaussian, Matérn and linear variograms; leave-one-out cross-validation and prediction variance.
Four compute paths, one service layer
Analysis where it fits. Results back on the map.
Use pure Go for dependable server functions, DuckDB for spatial SQL, Pyodide for browser-local Python and an optional Python sidecar for native geospatial and machine-learning libraries.
Compute architecture
Choose the runtime by workload, not ideology.
Each execution path has a deliberate role and can return portable GeoJSON, rasters, tables, profiles or service registrations.
| Runtime | Best for | Representative capabilities | Deployment behavior |
|---|---|---|---|
| Pure Go services | Low-dependency, concurrent server operations and edge deployment | Geometry, topology, terrain, routing, catalogs, service translation, streaming, mission workflows | Compiled into the same headless server binary; no Python dependency |
| DuckDB spatial | Fast analytical SQL over local, database and cloud-native data | Spatial joins, aggregation, CQL2 execution, dynamic MVT, GeoParquet/object-store query, H3 and time-series workflows | Embedded analytical engine with spatial/httpfs and optional cloud extensions |
| Pyodide / WebAssembly | Interactive browser analysis with zero server compute | Python console, GeoPandas/Shapely-style processing, data transforms and notebook cells that drive the map | Runs inside the browser sandbox; packages and memory are constrained by WebAssembly/browser support |
| Python sidecar | Native Python packages, long-running jobs, ML and specialist geoprocessing | WhiteboxTools, rasterio, scikit-learn, gstools, pykrige, OR-Tools, spaCy, Py6S, MegaDetector, BirdNET, virtualizarr and document generation | Optional isolated service with 176 routes; the core server continues operating when it is absent |
Spatial analysis depth
From raster hydrology to constrained logistics.
The analytics surface is intended to replace real operational workflows, not merely demonstrate buffers and centroids.
Regression and clustering
OLS with Moran’s I diagnostics, GWR/MGWR, LISA HH/LL/HL/LH clusters, Ripley functions, random forests with spatial cross-validation and space-time patterns.
Watersheds and flow
D8 flow, depression fill/breach, stream extraction and ordering, watershed/sub-basin delineation, pour-point snapping, wetness index and upstream length.
Surface intelligence
Viewshed, skyline, slope, aspect, cut/fill, solar radiation, surface area, DEM draping, 3D buffers and terrain-aware routing.
Routing and allocation
Vehicle routing with constraints, origin-destination matrices, p-median/p-center, location set covering and maximal covering facility siting.
Imagery processing
Raster function DAGs, band math, classification, convolution, atmospheric correction, change detection, segmentation, object detection and pixel-to-ground results.
Documents, entities and link graphs
Extract text from PDF, DOCX, PPTX and XLSX; run semantic search and citation-bearing RAG; identify 15 entity types, extract relations and push Cytoscape-compatible graphs into activity-based intelligence workflows.
What GeoLibre already has
The notebook foundation is implemented today.
GeoLibre’s notebook work is not just a concept. The checked-in build and documentation define a dual-mode architecture with shared map scripting.
WEB
Self-hosted JupyterLite
The web build stages a JupyterLite application inside the notebook panel and runs the Pyodide kernel entirely in the browser.
DESK
Real JupyterLab on desktop
The desktop path launches a uv-managed JupyterLab server for native packages and a full Python environment.
MAP
Two-way scripting bridge
Notebook cells can drive the live map and project state through the same scripting API used by the Python console.
PKG
Python package + anywidget direction
The geolibre package is designed for local Jupyter, VS Code, Colab and JupyterHub-style environments with a leafmap-like API.
AIR
Self-hostable runtimes
Runtime overrides allow Pyodide and DuckDB Spatial assets to be hosted locally for secure or disconnected environments.
Product recommendation
Yes—develop a Notebook Server equivalent by productizing the existing foundation.
Do not rebuild notebook UI or kernels from scratch. Keep JupyterLite for zero-infrastructure browser work, and add a governed multi-user server tier for workloads that need native packages, scheduled execution and enterprise controls.
Recommended product name: 3DGeoServ Notebook Service
A server-managed JupyterHub/Jupyter Server deployment integrated with 3DGeoServEngine identity, catalogs, service tokens, job scheduling and map/project APIs.
| Capability | JupyterLite / Pyodide workspace | 3DGeoServ Notebook Service |
|---|---|---|
| Compute location | User’s browser via WebAssembly | Containerized server kernels, optionally GPU-enabled |
| Native geospatial libraries | Only packages compatible with Pyodide/WASM | GDAL, rasterio, GeoPandas, PyTorch, WhiteboxTools and organization-specific environments |
| Large data | Limited by browser memory, sandbox and network behavior | Server-side access to databases, object storage, local high-speed storage and distributed services |
| Multi-user governance | Browser-local workspace | SSO/RBAC, per-user workspaces, quotas, image allowlists, audit events and network policy |
| Automation | Interactive, user-driven execution | Scheduled jobs, parameterized notebooks, headless execution, retries, logs and artifacts |
| Secrets | Avoid durable privileged credentials in browser code | Vault/Kubernetes secret injection, scoped service tokens and credential rotation |
| Deployment | Static, self-hosted JupyterLite assets | JupyterHub/Jupyter Server on Docker or Kubernetes, with air-gapped image registry support |
Build sequence
A practical notebook product roadmap.
Start with integration and governance around mature Jupyter components, then add differentiating geospatial workflows.
Harden the existing bridge
Stabilize project/map synchronization, notebook file persistence, self-hosted runtime assets and repeatable example notebooks.
Managed server kernels
Deploy JupyterHub with curated CPU/GPU images, persistent volumes, SSO/RBAC and scoped 3DGeoServEngine tokens.
Jobs and publishing
Schedule parameterized notebooks, capture logs/artifacts and publish outputs back as COG, FeatureServer, MVT, STAC or reports.
Enterprise operations
Add quotas, image promotion, package provenance, audit, cost controls, HA and disconnected deployment profiles.
GeoAgent
Natural language can invoke real tools—but stays auditable.
The agent registers geospatial tools for kriging, routing, hydrology, statistics, topology and 3D analysis, then returns rendering hints for maps, rasters, profiles and tables.
Not a replacement for notebooks
Agent workflows are ideal for guided execution and repeatable tool calls. Notebooks remain the right environment for exploratory analysis, custom code, peer review, narrative, visualization and reproducible research. Both should call the same underlying service and job APIs.