Query object storage and enterprise databases and generate vector tiles from current data. For imagery, the server includes a remote COG HTTP range reader and an ImageServer surface; wiring them into a general registration-to-service path is an explicit integration and validation target, not a claim of complete availability today.
The architecture is intentionally ambitious; the status column keeps the current implementation boundary clear.
| Capability | Maturity | Substantiated path | Remaining validation |
|---|---|---|---|
| Dynamic MVT | Implemented | Spatial queries are clipped and encoded into view-dependent vector tiles rather than requiring a prebuilt pyramid. | Benchmark source-specific SQL, filters, invalid geometry, concurrency and cache behavior at production scale. |
| Cloud/object-store query | Implemented connectors; environment validation required | DuckDB/httpfs and cloud-extension paths support supported Parquet/GeoParquet and tabular sources over HTTPS or configured object-store access. | Validate credential mode, extension availability, egress policy, pushdown and source-specific behavior. |
| Remote COG HTTP range reader | Implemented component | The range-reader seam can inspect a remote TIFF and request byte ranges instead of downloading the complete object. | Validate server range semantics, signed URL lifetime, COG layout, nodata/overview behavior and failure handling. |
| Remote COG → ImageServer | Integration target | The remote range reader and ImageServer operation components exist as adjacent building blocks. | Complete and test the registration/caller wiring, then verify metadata, export, identify, samples, statistics and tiles in real clients before production claims. |
The DuckDB spatial engine creates Mapbox Vector Tiles with ST_AsMVT() for the requested z/x/y view. This avoids treating the tile pyramid as a second authoritative dataset.
Beyond serving current data dynamically, the engine can watch attached data files and fire alerts the moment a rule matches. Author a SQL predicate, pick a severity, and route matches through the existing alert notifier—no external job scheduler or change-data-capture pipeline required.
.gpkg, .sqlite, .db or .duckdb file once under an alias.value > 80, battery < 10, or ST_DWithin(geom, point, 1000)).transaction_commit re-evaluates rules, so matches appear near-instantly.query_end, planning_error, …) forwards into the activity feed and event bus.Data-content rules carry the matched payload; lifecycle events carry raw database activity. Together they turn any local data file into a monitored, reactive source without a separate CDC tool.
DuckDB httpfs, spatial, Azure and Delta extensions provide a zero-copy query path with projection and predicate pushdown where the underlying format supports it.
| Source | Connection model | Data paths | What the engine can do |
|---|---|---|---|
| Amazon S3 / MinIO | Access key/secret, endpoint and region; anonymous public buckets supported | s3://, S3-compatible endpoints, HTTPS | Browse objects, inspect schemas, query Parquet/GeoParquet/CSV/GeoJSON, register spatial result collections |
| Google Cloud Storage | HMAC interoperability keys through the S3-compatible API | gs:// and configured endpoint access | Browse, query and register cloud datasets through the same SQL workflow |
| Azure Blob Storage | Storage account/key or SAS-oriented deployment configuration | az://, abfs://, HTTPS | Browse containers, query supported columnar/spatial files and retain source-aware connection profiles |
| Microsoft Fabric OneLake | Azure storage semantics plus DuckDB Delta extension | OneLake ABFS endpoints | Read Delta Lake table directories with delta_scan and join to spatial sources |
| HTTP/HTTPS | Public or signed URL | Remote Parquet, CSV, GeoJSON, COG and PMTiles | Range-read cloud-optimized assets or query supported tabular formats |
| Enterprise databases | Saved, credential-redacted connection profiles | PostgreSQL/PostGIS, MySQL, SQL Server, Oracle, Snowflake, ClickHouse, BigQuery, SQLite, DuckDB | Discover tables, execute SQL, map business data to geometry and register tables as service collections |
A Cloud Optimized GeoTIFF in a web-addressable S3, Azure Blob, GCS or compatible object-store endpoint can be addressed through HTTPS. Public or time-limited signed URLs fit the existing range-reader component. The general remote registration-to-ImageServer dispatcher still needs implementation and client validation.
The server checks the remote object and reads TIFF metadata without downloading the complete raster.
HTTP Range requests fetch IFD metadata and the image blocks required for the requested map extent and resolution.
Complete the caller/registration path from the remote object to ImageServer metadata, exportImage, identify, samples, statistics and tile operations.
Validate extents, pixel values, reprojection, nodata, overviews, signed-URL expiry, range failures and performance before presenting the path as production-ready.
The object remains a standards-based GeoTIFF that GDAL, QGIS, rasterio and cloud-native pipelines can also use.
Virtual collections are the core abstraction: a queryable dataset is registered once and presented through the interface each consumer expects.
The comparison below describes the 3DGeoServEngine design relative to common publish-and-cache GIS deployments. It is not a claim that no other platform can be customized to achieve similar patterns.
| Concern | Conventional publish/cache pattern | 3DGeoServEngine pattern |
|---|---|---|
| Vector visualization | Generate and maintain a separate cached tile product. | Generate MVT dynamically from the current spatial query, or use a stored tile archive when immutability is preferable. |
| Cloud imagery | Copy imagery into a managed raster store or build a platform-specific mosaic/service definition. | Target path: retain the remote COG, range-read only required blocks and publish through ImageServer after the registration/dispatcher integration passes endpoint and client validation. |
| Client compatibility | Publish a separate service for each client/protocol. | Expose multiple service contracts over the same virtual collection. |
| Analytical access | ETL data into the GIS datastore before spatial query. | Use DuckDB to query supported object-store formats in place and materialize only when performance, governance or DDIL requires it. |
| Offline/edge | Depend on the central portal and prepare offline packages separately. | Use the same service binary with staged GeoPackage, MBTiles, PMTiles and COG data at the edge. |
The bundled DuckDB cloudfs extension lets the engine COPY TO query results directly into the document stores and file shares operators use daily—no separate sync tool, staging bucket, or manual download-and-upload step.
Export GeoPackage, GeoParquet or CSV results into a SharePoint document library or OneDrive folder using Entra ID app credentials.
Push derived datasets into a shared Drive through the configured service-account credentials.
Write to a Dropbox folder so downstream analysts receive files in a tool they already mount locally.
Ship exports to an SFTP server or a customer-managed VPS for air-gapped or partner-network exchange.
Exports run as async jobs with progress polling and cancellation—large result sets never block the request thread or the map.
Choose the right shape per consumer: GeoPackage for offline GIS, GeoParquet for analytics, CSV/JSON for BI, or a styled layer bundle.
cloudfs connection dialog behind the export path above — shown in its empty state, before real credentials are entered.