Schema, coordinates and identity
Record source version, fields, units, CRS, vertical datum, geometry, time semantics, stable IDs, update rules, licensing and security classification.
Repository-audited capability inventory
One inventory.
Clear status.
A practical matrix of what GeoVerse3D implements, what is partially integrated, what is staged as reference code, and what Tech Maven delivers through a dataset-, SDK- or device-specific adapter.
2D + 3D GISfiles, services, tiles and analysis
CAD · BIM · LiDARconversion and rendering boundaries
DUCKDB + LIVE DATAlocal, enterprise and streaming paths
TAK · DEFENSE · XRmission context and delivery profiles
How to read the matrix
“Supported” is not one status.
The status records the strongest evidence in the current Unity solution. It intentionally separates code that is in the active compile tree from integration hooks, parked source, optional services and delivery work that must be proven against the customer’s data and target hardware.
Active core — implementation is in an active Unity or backend path
Partial — code exists, but a dependency, loader, behavior or validation step is incomplete
Staged — source or sample exists in a Unity-ignored folder or reference area
Delivery adapter — customer-, SDK-, service- or device-specific implementation is required
Release boundary: “Active core” means repository-backed implementation, not a claim that every platform is release-qualified. The accepted native-binary baseline is Windows x64; the current branch still requires a clean Unity 2022.3.0f1 compile/Test Runner pass plus target-device and live-system acceptance.
01 / Platform and configuration
Shared geospatial foundation.
Configuration, lifecycle and scene orchestration capabilities that other delivery profiles build on.
| Capability | Concrete scope | Runtime behavior | Status | Boundary / delivery context |
|---|---|---|---|---|
| Unity geospatial integration foundation | Unity 2022.3, layer, scene, memory and geospatial managers | Coordinates subsystem initialization, layer state, scene objects and bounded memory use. | Partial | The codebase is an integration foundation, not a finished no-code player; the current scene/content construction path is incomplete. |
| WebScene and CatalogLayer conversion | Esri WebScene item JSON, CatalogLayer JSON, generated Unity C# and configuration JSON | Reference converter code fetches, parses, validates and maps known layer types into reviewable output. | Companion / staged | The converter is reference/companion code rather than an active Unity runtime module. Unmapped layer types and SDK-version differences require review. |
| Configurable layer lifecycle | Visibility, opacity, ordering, bounds, material and memory registration | Creates and updates registered layers and coordinates renderer-facing settings. | Partial | Layer management is active; complete dataset loaders and authored operator UI vary by source. |
| Desktop, mobile, web and XR profiles | Windows, iOS/iPadOS, Android, WebGL/PWA, OpenXR, AR Foundation, ARCore | Shares approved data and spatial logic while adapting storage, input, rendering and interaction. | Delivery profile | Only Windows x64 has the current native-binary baseline. Mobile, browser, AR and VR require platform libraries, builds, signing, hardware and performance acceptance. |
02 / 2D GIS, raster and offline content
Choose the data path by scale.
Small feature overlays, large vector stores, cached map packages and imagery do not share one efficient runtime pattern.
| Capability | Formats / services | Runtime behavior | Status | Boundary / delivery context |
|---|---|---|---|---|
| Local spatial database | DuckDB database plus DuckDB Spatial | Stores/query features, runs SQL and spatial functions, transforms coordinate systems and returns result rows/GeoJSON. | Active core | Committed DuckDB.NET and native DuckDB binaries currently target Windows x64. |
| GeoPackage vector features | GPKG feature tables and geometry columns | Uses DuckDB Spatial to inspect and query local features and expose selected records through in-app handlers. | Partial | WKB coverage is incomplete; direct edits back to a GeoPackage file are not implemented. Selected DuckDB point/polygon CRUD is a separate path. |
| In-app FeatureServer handlers | Service/layer metadata, query, identify, find, selected CRUD and spatial-operation routes | Processes FeatureServer-style request paths in-process against DuckDB-backed layers. | Partial | This is not a standalone ArcGIS Server. The current HTTP-server startup is simulated; an actual local transport must be integrated if external clients need a URL. |
| GeoJSON feature workflows | GeoJSON point, line and polygon records | Imports or returns feature geometry/attributes for analysis, route exchange and realtime-state export. | Active core | Validate geometry type, coordinate reference, Z values, attribute schema and record volume per workflow. |
| Shapefile and KML/KMZ | SHP/DBF/SHX/PRJ, KML and KMZ | Normalizes desktop-GIS interchange data into the approved local feature model. | Staged / adapter | GIS loaders are parked in Unity-ignored source; production ingestion needs an active GDAL/DuckDB Spatial or managed-reader path. |
| Cached map tiles | MBTiles raster or vector tiles | Reads SQLite tile rows by z/x/y, caches hot tiles and feeds a renderer or local tile endpoint. | Staged | The reader/server implementation is parked under Unity-ignored processors/offline maps and must be re-enabled and target-tested. |
| Cloud-native tile archives | PMTiles | Uses range-addressed tile retrieval from a local file or network object with bounded caching. | Delivery adapter | No active PMTiles reader is committed; index parsing, range I/O and renderer integration are delivery work. |
| Esri tile packages | VTPK and TPKX | Extracts or converts package content into renderer-compatible vector/raster tile payloads and style resources. | Delivery adapter | Package layout and style compatibility must be validated. No active VTPK/TPKX reader is committed. |
| Dynamic large-vector delivery | MVT/PBF vector tiles or extent-filtered feature pages | Filters, clips, simplifies and tiles large feature collections before Unity rendering. | Staged / adapter | Vector-tile server code is parked; the active alternative is bounded feature querying through DuckDB/FeatureServer-style handlers. |
| Esri raster and image services | ImageServer/MapServer exportImage, PNG/JPEG tiles | Requests imagery by extent/size/spatial reference with retry, memory cache, disk cache and cancellation controls. | Active core | Terrain material application and cache budgets remain delivery-specific; service credentials and licensing are external requirements. |
| Local GeoTIFF and COG imagery | GeoTIFF/COG and overview/range-read workflows | Reads windowed raster regions or generates display tiles rather than loading a large raster as one texture. | Staged / adapter | COG readers/generators are parked. Native raster dependencies, CRS handling, resampling and nodata behavior require target validation. |
| Defense raster and elevation | DTED, NITF, RPF/CADRG/CIB | Normalizes terrain elevation and defense imagery into Unity terrain, image tiles or local raster caches. | Delivery adapter | No active native readers are committed. Dataset edition, compression, georeferencing, security markings and licensing are validated per program. |
03 / CAD, BIM and 3D processing
Geometry conversion is not the same as BIM preservation.
The matrix separates mesh import, CAD tessellation, geospatial placement, scene tiling and semantic BIM metadata because each needs different tooling and acceptance checks.
| Capability | Formats / models | Runtime behavior | Status | Boundary / delivery context |
|---|---|---|---|---|
| Open Asset Importer integration hook | Assimp/AssimpNet-oriented pipeline | Detects source format, creates import metadata, caches records and prepares a normalized GLB path. | Partial | The active class currently simulates vertex counts, conversion and GameObject mesh loading. AssimpNet/native Assimp binaries are not committed, so this is not yet a completed importer. |
| Interchange model registry | OBJ, FBX, STL, PLY, glTF, GLB, DAE, 3DS and BLEND | Recognizes extensions and routes them toward an import/cache/placement workflow. | Registry only | Format recognition is implemented; real mesh, hierarchy, animation, material and texture import depends on completing the Assimp/glTF loader integration. |
| CAD surface/solid interchange | STEP/STP and IGES/IGS | Routes CAD interchange files toward tessellation, unit/axis normalization and a mesh delivery format. | Registry / adapter | The extensions are registered, but no committed CAD kernel or verified Assimp conversion path performs production tessellation. |
| BIM and authoring formats | IFC, RVT, DWG, DXF, DGN | Delivery workflow converts selected disciplines/views into GLB, I3S/SLPK or 3D Tiles plus mapped object metadata. | Delivery adapter | No active direct reader is committed. Native authoring formats require an approved Autodesk/ODA/IFC or ETL pipeline and licensing appropriate to the deployment. |
| BIM semantic preservation | IFC property sets, element IDs, levels, spaces, systems, classifications and relationships | Maps stable element identity and approved properties into queryable runtime metadata linked to rendered geometry. | Delivery adapter | Generic mesh import does not preserve a BIM graph. Property filtering, object selection, relationships and round-trip behavior require an IFC/BIM-aware conversion specification. |
| Unity mesh to GLB | Unity Mesh to binary glTF container | Writes a compact GLB payload for downstream storage or wrapping. | Partial | The committed converter is intentionally minimal; GLB parsing is incomplete and production material, texture, hierarchy, extension and conformance coverage must be added. |
| GLB to B3DM conversion | Valid GLB payload to legacy B3DM tile payload | Wraps GLB bytes in a B3DM header, supports memory/disk caching and file, directory or download conversion paths. | Active core | This creates tile content, not a complete spatial tileset. Bounding volumes, hierarchy, geometric error, metadata and 3D Tiles 1.0/1.1 conformance are separate work. |
| 3D Tiles streaming bridge | tileset JSON, GLB/B3DM and Google 3D Tiles-oriented requests | Loads tileset metadata, selects tile content, downloads GLB and can route it through the B3DM wrapper/cache. | Partial | The custom loader path is incomplete; production use generally requires a validated Cesium/SDK path, authentication, attribution and target-specific LOD testing. |
| I3S and Scene Layers | SLPK, 3D Object, Integrated Mesh, Building and Point Cloud Scene Layers | Uses an Esri SDK delivery path to stream spatially indexed LOD content into the Unity scene. | SDK profile | Availability depends on the selected ArcGIS Maps SDK version, service/package compatibility, credentials, licensing and platform acceptance. |
| Geospatial model placement | Latitude, longitude, altitude, rotation, scale, tint, visibility and JSON persistence | Creates, updates, queries, removes and restores placed-model records at geographic positions. | Partial | Placement management is active, but the current model loader creates a placeholder GameObject until real model import is integrated; precision coordinate conversion also needs target SDK validation. |
| City model processing | CityGML and CityJSON | Parses building objects and converts selected geometry into Unity meshes with attributes. | Staged | Processors are in a Unity-ignored folder and need topology, CRS, LOD, texture, semantic and large-dataset validation before activation. |
| OGC CDB / synthetic environment | OGC CDB datasets and OpenFlight/FLT-oriented model content | Builds a delivery pipeline for terrain, imagery, features, models and attribution into simulation/training scenes. | Defense adapter | No complete CDB reader is active in this repository. Version, dataset structure, OpenFlight conversion, paging and simulator interoperability are program-specific. |
3D conversion acceptance checks.
Every CAD/BIM/model workflow should record source units, coordinate origin, georeference, handedness and up axis, hierarchy, instancing, normals/tangents, triangle and draw-call budgets, textures and PBR channels, LODs, colliders, stable object IDs, retained metadata, licensing and a visual comparison against the authoring source.
04 / LiDAR and point clouds
Point-cloud support needs both processing and rendering.
Opening a file is only the beginning. Large LiDAR collections need spatial indexing, attribute-aware processing, streaming LOD and a GPU rendering strategy.
| Capability | Formats / attributes | Required processing or rendering | Status | Boundary / delivery context |
|---|---|---|---|---|
| PLY scan/model path | PLY vertices, colors, normals and faces | Routes PLY through the model-import registry for conversion or placement. | Registry only | The active importer simulates mesh loading. It does not provide a scalable point-cloud renderer. |
| Native LiDAR files | LAS, LAZ, COPC and E57 | Reads point records, CRS, scale/offset, bounds, classification, return, intensity, RGB and GPS time. | Delivery adapter | No active LAS/LAZ/COPC/E57 reader or native decompression library is committed. |
| LiDAR preprocessing | Classification filters, crop, reprojection, decimation, ground/non-ground, height normalization and rasterization | Creates fit-for-purpose subsets, elevation/surface products and renderable partitions before scene loading. | Processing adapter | No active point-cloud analytics pipeline is committed; PDAL/GDAL, a service workflow or an equivalent approved processor must be integrated and benchmarked. |
| Large point-cloud streaming | Octree/COPC hierarchy, point tiles, I3S Point Cloud or 3D Tiles-oriented content | Selects nodes by camera and screen-space error, streams bounded point batches and evicts distant nodes. | Rendering adapter | The source references point-cloud scene-layer mappings but has no active native streaming renderer. |
| GPU point rendering | RGB, elevation, intensity, classification and return-based styling | Uses point sprites, splats or compute/indirect rendering with point budgets, frustum culling and LOD. | Rendering adapter | Shader, buffer, picking, transparency, XR stereo and mobile/WebGL constraints are target-specific and not implemented in the active core. |
| Point-cloud interaction | Identify, clipping volumes, cross sections, measurements and point-to-feature context | Queries streamed nodes and links selected points/regions to attributes and surrounding GIS/BIM content. | Delivery adapter | Requires the chosen point index/renderer to expose queryable attributes and stable coordinate transforms. |
05 / Databases, spreadsheets, analytics and real time
Query where the data lives—without inventing connectors.
Unity-side DuckDB attachment, the optional Node service, file ingestion and streaming are distinct paths with different deployment and security characteristics.
| Capability | Sources / protocols | Runtime behavior | Status | Boundary / delivery context |
|---|---|---|---|---|
| Direct relational database attachment | PostgreSQL, MySQL, SQL Server and SQLite | Builds sanitized DuckDB ATTACH commands, loads the selected extension, inspects tables/columns and runs cached SQL results. | Active path | Connector code is active; each DuckDB extension, server version, TLS mode, credentials and native target must be installed and integration-tested. |
| ODBC enterprise sources | Snowflake, Oracle, Redshift, DB2 and other approved DSNs | Builds brace-escaped ODBC connection strings and attaches a named schema for querying. | Active path | Requires the DuckDB ODBC extension plus the correct system driver/DSN; no cross-platform driver bundle is committed. |
| Google Sheets | DuckDB gsheets extension, API key or service-account configuration | The Unity connector defines a Google Sheets connection type, credential path, extension load and ATTACH workflow. | Partial | The gsheets extension is not bundled or runtime-validated, and the optional Node backend does not implement its attach switch. Sheet ID/range and authentication behavior need correction and acceptance testing. |
| BigQuery | DuckDB bigquery-oriented extension and cloud credentials | The Unity connector defines configuration, credential handling and an ATTACH route. | Partial | The extension is not bundled or validated; the Node service schema lists BigQuery but its database attach path does not implement it. |
| Excel workbook ingestion | XLSX and XLS workbooks, sheets, tables and named ranges | Target workflow would normalize selected cells into typed DuckDB tables or a local feature layer. | Not active | No Excel parser or DuckDB Excel-extension integration is committed. TAK can classify an XLS/XLSX as a shared file, but that is attachment support—not spreadsheet ingestion. |
| CSV, JSON and Parquet analytics | Local or controlled-network tabular files | Uses DuckDB readers to infer or enforce schema, filter/project records and materialize selected results. | Engine-capable adapter | The app has CSV export and reference CSV ingestion paths, but no complete operator-facing general file-ingest workflow; backend query safety deliberately blocks arbitrary file-reader functions. |
| Federated SQL | Queries spanning multiple attached schemas | Validates connection presence and lets DuckDB join qualified tables across attached sources with a bounded result cache. | Active path | Query governance, source pushdown, result limits and connector-specific performance must be profiled with representative data. |
| Credential protection | Database passwords and API keys | Stores credentials separately from normal connection metadata using AES-256-CBC plus HMAC-SHA256 and machine-bound PBKDF2-derived keys. | Active core | Production key lifecycle, device migration, operating-system keystore use and recovery policy still require deployment security review. |
| Optional database API | Express/Node DuckDB service, authenticated query/connection routes | Provides connection management, guarded SQL, exports, limits and an independent server-side DuckDB runtime. | Backend release candidate | It is separate from Unity; no active Unity HTTP client connects to it automatically. Deployment needs TLS, auth, load, backup and recovery validation. |
| 2D spatial analysis | Buffer, intersect, union, difference, simplify, distance, nearest, DWithin, contains, crosses, overlaps, touches, centroid, area and length | Routes FeatureServer-style operations to DuckDB Spatial and returns geometry or scalar results. | Active core | Correctness depends on CRS, units, geometry validity and DuckDB extension availability. This is not a general 3D solid-geometry engine. |
| StreamServer ingestion | Esri StreamServer WebSocket and JSON feature events | Connects, subscribes, filters fields/where clauses, parses events, reprojects, batches, caches and reconnects with a cap. | Active core | Service auth, schema variants, disconnect behavior, load and visible-update latency need source-specific acceptance. |
| Bounded realtime processing | TAK/CoT, StreamServer and customer feed adapters | Uses a bounded ingestion queue, stable feature IDs, LRU-style state, memory pressure handling, main-thread handoff, object reuse and layer styling. | Active core | Per-frame, retained-feature and memory budgets are configured for the target device and feed rate. |
| Kafka, MQTT, GTFS and OGC feeds | Kafka, MQTT, GTFS Realtime, Moving Features, SensorThings, SensorML and SOS | Defines adapter contracts and reference parsing/connection workflows for broader real-time ingestion. | Staged | These adapters are in Unity-ignored source and several are explicit placeholders; broker/client libraries and protocol conformance are not in the active baseline. |
06 / TAK, mission planning and defense
Operational data in shared spatial context.
These capabilities combine team events, route planning, symbology and mission content; simulator terrain/data formats remain delivery-profile integrations.
| Capability | Protocols / content | Runtime behavior | Status | Boundary / delivery context |
|---|---|---|---|---|
| TAK Server connectivity | REST authentication, WebSocket, TLS certificates and CoT XML | Authenticates, connects, sends/receives CoT, parses events and dispatches updates onto Unity’s main thread. | Active core | Requires live TAK Server, certificate-chain, disconnect/recovery and load acceptance; credentials must not be serialized in scenes. |
| TAK team awareness | Team members, markers, events, alerts and local DuckDB persistence | Maintains team state, persists events and updates pooled/LOD-aware scene markers. | Active core | Marker positioning, symbology integration and performance must be validated against representative operational traffic. |
| Chat, tasks and mission packages | Chat messages, task lifecycle, data packages and shared files | Handles events, repositories, notifications, package loading and local persistence. | Active core | Server-version interoperability, package security scanning, size limits and conflict behavior require integration testing. |
| Video and sensor context | MP4/MOV file metadata, TAK file attachment and geospatial tag attachment | Associates a video file/thumbnail/duration or sensor reference with a mission object or shared package. | Attachment path | No active RTSP/HLS/WebRTC decoder, KLV metadata parser or live-video georegistration pipeline is committed; those are delivery adapters. |
| Route and waypoint planning | Routes, ordered waypoints, types, metrics, visualization, persistence and GeoJSON export | Creates, edits, reorders, clones, deletes, renders and exports route plans. | Active core | Terrain-aware routing, threat/cost surfaces, network solvers and collaborative conflict resolution are not implied by basic route CRUD. |
| Military symbology | MIL-STD-2525C and 2525D SIDC models, cached symbol rendering and marker display | Validates SIDCs, renders/caches symbols and applies them to Unity sprites, UI or materials. | Active core | 2525E appears as an option in renderer configuration, but complete standard/entity coverage and external symbol-service behavior need acceptance. |
| Mission planning, rehearsal and training | Routes, spatial queries, terrain, 3D assets, TAK context, desktop/VR/AR views | Combines approved layers into role-specific planning, rehearsal, simulation and after-action experiences. | Solution profile | Scenario logic, scoring, physics, AI entities, exercise control, record/replay and HLA/DIS interoperability are program-specific—not automatic core features. |
07 / Delivery and validation
Capability becomes a product through acceptance.
These cross-cutting controls determine whether a source-to-screen workflow is reliable on the intended device and network.
Bound every expensive stage
Measure parse, conversion, query, network, cache, CPU/GPU memory, draw calls, points/triangles, frame time and visible-update latency with representative data.
Prove the exact build
Validate native libraries, SDK/plugin versions, signing, certificates, offline recovery, accessibility, controls and hardware behavior for each Windows, mobile, web, AR or VR profile.
Inventory conclusion.
GeoVerse3D has substantial active GIS, DuckDB, realtime, TAK, mission-planning and spatial-analysis code. CAD/BIM, true Assimp model import, LiDAR processing/rendering, direct Excel ingestion and several offline/defense formats are credible delivery pathways—but they should be scoped as integration work until the named dependencies, loaders and target builds are implemented and accepted.
Bring the source files.
Prove the matrix.
Tech Maven can turn the relevant rows into a dataset-by-dataset acceptance plan, conversion pipeline and target-device delivery profile.