OGC API Features + CQL2
Collections, items, individual features, BBOX and attribute filters, pagination, CRS requests and CQL2-text filtering over DuckDB-backed and virtual collections.
Protocol-level interoperability
Preserve client contracts. Change the engine.
3DGeoServEngine implements and is expanding familiar Esri-compatible and open-standard service shapes while discovering, ingesting and translating remote ArcGIS, GeoServer, MapServer, QGIS Server and OGC endpoints. The matrix below separates implemented routes from partial dispatchers and integration targets.
Service-surface maturity
Concrete operations, with implementation status visible.
These are server-side interface paths, not just endpoint names. Coverage varies by data type and not every surface is at the same maturity; each row distinguishes implemented routing from partial or end-to-end integration work.
| Service surface | Maturity | Concrete behavior or remaining boundary | Primary sources / consumers |
|---|---|---|---|
| FeatureServer | Implemented surface; workflow validation required | Routes include service/layer metadata; query with BBOX, spatial, object ID and CQL2 translation; edit operations; and GlobalID, attachment and related-table paths. Exact renderer, sync, edit-rule and client-version behavior belongs in the acceptance suite. | DuckDB spatial, GeoPackage, virtual collections and registered database tables; ArcGIS, web/mobile and custom REST clients |
| MapServer | Partial | Raster service-directory and metadata paths are present, with raster-bridge components. A complete MapServer request dispatcher and end-to-end export/client compatibility path were not substantiated across the full advertised surface and remain implementation/validation work. | Rasterized basemap/style services; target consumers include ArcGIS, WMS and tactical map clients |
| VectorTileServer | Implemented surface; client validation required | Service metadata, root style JSON, PBF tile path, sprite JSON/PNG and generated styling paths are present for dynamic or packaged vector tiles. | Dynamic MVT, vector MBTiles/VTPK/GPKG; ArcGIS VectorTileLayer, MapLibre and compatible clients |
| StreamServer | Implemented surface; feed/client validation required | Service/layer metadata, current-feature snapshot, WebSocket subscription and event-update paths are present. Each source adapter and consuming client must be load- and reconnect-tested. | TAK/CoT, IoT, GNSS, MQTT, Redis, Kafka REST and WebSocket feeds; ArcGIS/GeoEvent-style and custom consumers |
| SceneServer | Implemented surface; dataset validation required | I3S service/layer documents, node pages, geometry/textures and statistics paths are present for SLPK/I3S workflows; compatibility depends on the scene profile and client. | SLPK, I3S and registered scene layers; ArcGIS SceneLayer and 3D web clients |
| ImageServer | Split maturity | Local raster/ImageServer operation paths include metadata, exportImage, identify, samples, statistics and tile variants. A remote HTTPS COG range reader exists, but the registration-to-ImageServer caller/endpoint is an integration target that still requires wiring and end-to-end client validation. | Local COG/raster sources are the substantiated path; remote S3/Azure/GCS COG is the designed integration path for ArcGIS imagery and analytical clients |
Status definitions: “implemented surface” means route/handler code is present, not universal certification against every client. “Partial” means useful components exist but the full dispatcher or contract is incomplete. “Integration target” means supporting components exist but the advertised end-to-end path still needs wiring and validation. All compatibility must be tested against the actual client versions, renderers, geometry types, editing rules and authentication flows in scope.
Open-standard surfaces
Standards are first-class interfaces, not export checkboxes.
The same datasets can remain available to open-source desktop tools, web clients, catalogs and automation pipelines.
STAC 1.0 + OGC API Records
Search local and discovered assets through STAC collections/items/search and a unified OGC API Records catalog, with a CSW 2.0.2 crosswalk for legacy catalog clients.
WMTS, XYZ, MVT + TileJSON
WMTS 1.0.0 capabilities and REST/KVP tile access, XYZ templates, vector PBF tiles and TileJSON metadata across MBTiles, PMTiles, GeoPackage and generated collections.
WCS 2.0.1 + WMS 1.3
Coverage metadata/download and raster-bridge components establish the WCS/WMS direction. Treat full GetMap/coverage dispatch and client combinations as maturity-matrix items that require route-level and end-to-end validation.
OGC 3D Tiles 1.1
Serve and consume 3D Tiles content, including packaged 3TZ, converted scenes and optimized implicit tiling for point clouds and Gaussian splats.
SensorThings, SOS + Moving Features
Connect to and normalize OGC SensorThings, SOS and SensorML feeds; parse OGC Moving Features JSON into time-aware observations for the real-time data plane.
Universal discovery
Start from the server URL, not a hand-built layer URL.
The discovery engine crawls service directories and capabilities documents, classifies protocols, extracts layers and persists normalized records to a local GeoPackage catalog.
01
Auto-detect
ArcGIS REST, GeoServer, WMS, WFS, WCS, WMTS, OGC API, XYZ/TMS and 3D Tiles server patterns.
02
Crawl and classify
FeatureServer, MapServer, ImageServer, VectorTileServer, StreamServer, SceneServer and open-standard layers are recorded with protocol and resource URLs.
03
Decode applications
Read web-map, web-scene and web-application JSON so operational layers, visibility, basemaps and service references can be reconstructed.
04
Add or ingest
Build a frontend-specific add-to-map specification, or stream compatible feature protocols into a local, QGIS-readable GeoPackage.
05
Search the catalog
Query discovered services alongside local assets through OGC API Records and CSW with text, BBOX and protocol filters.
Consuming the standards, not just serving them
Proven against live third-party services.
The endpoint matrix above documents what 3DGeoServEngine itself implements. The same protocols also run in the other direction: the reference client genuinely consuming real STAC and ArcGIS services over the internet, network-traced rather than staged.
sampleserver6 FeatureServer, with genuine attribution.Network-traced, not staged: real 200/206 responses from Element84's Earth Search API and Esri's sample FeatureServer, including a genuine byte-range read of an S3-hosted Sentinel-2 COG.
See it in motion
Real product capture
The STAC search above, run start to finish.
Configuring the query and getting real Sentinel-2 results back, recorded end to end against Element84's public Earth Search API.
Incremental migration
Run old and new clients at the same time.
A contract-preserving cutover lowers risk because the data plane can change independently of every consuming application.
Existing estateArcGIS web maps and appsQGIS projectsCustom REST integrationsETL and scheduled jobs
→
Compatibility validationSchema and GlobalID mappingRenderer/style translationEdit/attachment round tripsPerformance and security tests
→
Phased cutoverRead-only mirrorDual publishTransactional pilotApplication-by-application switch