Navara是WebGIS的第三条路吗?

最近在关注开源 GIS 和 3D 地理可视化项目时，我发现了一个非常值得研究的项目：Navara。

它来自 Re:Earth 社区，是一个面向 3D Globe 的可扩展地图引擎。

项目官方给出的定位是：

A flexible 3D globe map engine for building interactive, customizable, and data-driven geospatial experiences.

从技术栈来看，Navara非常有意思：

Rust + WebAssembly + Three.js + TypeScript + Bevy ECS

如果只把它理解成：

"又一个3D地图引擎。"

其实低估了这个项目。

Navara真正值得关注的地方，是它试图解决一个长期存在于3D GIS领域的问题：

GIS计算能力与3D渲染能力，是否可以真正解耦？

本文就从架构、代码组织、数据处理、渲染机制以及空间智能几个方面，完整分析一下Navara。

一、Navara是什么？

先不谈代码。

从产品层面理解，Navara就是一个：

3D Globe Map Engine。

它可以把真实世界的地理数据加载到一个三维地球中。

目前支持的数据类型包括：

Raster Tiles
Vector Tiles
3D Tiles
GeoJSON
Terrain
GLB / GLTF
3D城市模型

也就是说，它面对的不是简单的Web地图，而是一个完整的三维地理空间场景。( $GitHub$ $2$ )

例如：

text 复制代码

卫星影像
    ↓
Terrain
    ↓
3D Tiles
    ↓
Vector Data
    ↓
3D Model
    ↓
       Navara
          ↓
     Three.js
          ↓
        WebGL
          ↓
         GPU

最终在浏览器中形成一个：

可交互的3D地球。

二、为什么还需要一个新的3D地图引擎？

这是理解Navara设计的关键。

现在已经有很多成熟项目：

Cesium
MapLibre
Three.js
deck.gl
OpenLayers

为什么还要重新做一个？

因为传统地图引擎实际上存在一个很有意思的矛盾。

第一类：高层地图引擎

例如：

MapLibre。

优点非常明显：

简单。

你可以通过：

json 复制代码

{
  "sources": {},
  "layers": []
}

这样的配置快速构建地图。

但是问题也很明显：

扩展到引擎底层比较困难。

如果你希望：

修改底层渲染流程
深度控制3D对象
自定义Shader
自己处理Geometry
修改GPU资源管理

开发复杂度会快速增加。

第二类：底层3D引擎

比如：

Three.js。

它给你非常强大的3D能力。

但是Three.js并不知道：

什么是：

text 复制代码

经纬度

什么是：

text 复制代码

椭球

什么是：

text 复制代码

ECEF

什么是：

text 复制代码

Terrain

什么是：

text 复制代码

Tile

什么是：

text 复制代码

MVT

更不知道：

两个地理实体之间是什么空间关系。

所以：

Three.js很强，但它不是GIS引擎。

三、Navara试图解决什么问题？

Navara的答案非常直接：

把GIS Core和Rendering Engine拆开。

这是整个架构最重要的一点。

官方架构文档明确把Navara设计成：

Headless GIS Core

也就是说：

GIS核心不依赖具体的渲染引擎。

而当前的渲染层：

使用Three.js。

架构可以简化成：

text 复制代码

                 Application
                      │
          ┌───────────┴───────────┐
          │                       │
       GIS Core              Rendering
          │                       │
      Rust/WASM                Three.js
          │                       │
          └───────────┬───────────┘
                      │
                    WebGL
                      │
                     GPU

这和传统"地图引擎就是渲染引擎"的思路存在明显区别。

Navara把：

空间计算

和：

图形渲染

看成两个不同的问题。

四、为什么选择Rust？

这是第二个非常值得研究的地方。

GIS其实是一个非常"计算密集型"的领域。

比如：

坐标转换
几何计算
空间索引
Terrain网格生成
Polygon处理
Polyline处理
Tile处理
LOD
Mesh生成

这些操作如果全部使用JavaScript实现，会面临性能和工程复杂度的问题。

所以Navara把大量核心能力放到了：

Rust。

项目内部目前有40多个Rust crate，分别负责核心数学、几何处理、Terrain、WASM、数据处理等不同模块。( $GitHub$ $3$ )

例如：

text 复制代码

navara_core
navara_geometry
martini
navara_wasm
navara_wasm_worker
navara_wasm_api
...

这种设计实际上非常接近：

一个真正的GIS Engine。

而不是简单的：

JavaScript地图组件。

五、为什么又需要WebAssembly？

Rust运行在浏览器里怎么办？

答案：

WebAssembly。

整体链路就是：

text 复制代码

Rust
  ↓
wasm-bindgen
  ↓
WebAssembly
  ↓
Browser
  ↓
TypeScript

这样做的最大意义是：

把高性能GIS计算带到了浏览器。

例如：

text 复制代码

JavaScript
   │
   │ 调用
   ↓
WebAssembly
   │
   ↓
Rust GIS Core
   │
   ↓
Geometry / Terrain / Spatial Calculation

而且Navara不是简单地把整个Rust项目编译成一个WASM。

目前设计了三个主要WASM模块：

1. navara_wasm

完整引擎。

负责：

Camera
Layer
Feature
Tile
ECS
3D Engine

2. navara_wasm_worker

后台处理。

主要承担：

Terrain Mesh生成
Polygon处理
Polyline处理
CPU密集型任务

这样可以避免主线程被复杂计算阻塞。

3. navara_wasm_api

轻量API。

例如：

坐标转换
数学计算
ECEF
Geodetic

这意味着：

不需要为了一个坐标转换，把整个3D GIS引擎都加载进来。

这种模块化设计还是比较漂亮的。( $GitHub$ $2$ )

六、Navara为什么使用Bevy ECS？

如果你熟悉游戏引擎，就会发现：

Navara并没有简单地采用传统GIS Layer架构。

它的Rust核心使用了：

Bevy ECS。

ECS：

Entity Component System

是一种非常典型的实时3D应用架构。

传统GIS可能更习惯：

text 复制代码

Map
 ├── Layer
 │    ├── Feature
 │    ├── Feature
 │    └── Feature

而ECS更加倾向：

text 复制代码

Entity
  +
Component
  +
System

例如一个建筑：

text 复制代码

Entity
 ├── Position
 ├── Geometry
 ├── Material
 ├── Transform
 ├── FeatureProperties
 └── Visibility

系统则负责：

text 复制代码

GeometrySystem
TerrainSystem
CameraSystem
TileSystem
RenderSystem

这种架构非常适合动态3D世界。

七、GIS为什么可能需要ECS？

这是一个非常值得讨论的问题。

因为未来的GIS对象可能越来越复杂。

传统GIS中的Feature：

text 复制代码

Building
Road
River

更多是：

数据对象。

但是在实时3D世界中：

一个建筑可能同时具有：

text 复制代码

Geometry
Position
Height
Material
Texture
Semantic
Sensor
Traffic
Energy
Population

甚至还可能不断变化。

这时候：

Entity + Component

其实比简单的Feature对象更加灵活。

所以Navara采用ECS，并不是偶然。

它实际上是在向：

Real-time Spatial World

靠近。

八、Navara的四层API设计

Navara另外一个很值得学习的设计，是：

Tiered API。

也就是把开发能力划分成四个层级。

第一层：Declarative

最简单。

直接配置：

text 复制代码

Source
Layer
Terrain
Mesh
Light
Effect

例如：

javascript 复制代码

const map = new Navara({
  terrain: terrainSource,
  imagery: imagerySource
});

开发者不需要理解底层渲染过程。

九、第二层：Plugin

如果基础能力不够。

可以使用Plugin。

例如：

Photorealistic Scene
First Person Walking
DOM Overlay
Attribution

这种设计和现代前端生态非常接近。

更重要的是：

插件不仅仅是功能扩展，也是能力封装。

未来甚至可以形成：

text 复制代码

Navara Plugin Marketplace

十、第三层：API

如果你需要更加精细的控制：

进入API层。

例如：

Feature Picking

点击地图对象：

text 复制代码

Screen
 ↓
Ray
 ↓
Feature

最终得到：

javascript 复制代码

{
  id: "building_001",
  properties: {
    height: 32,
    type: "residential"
  }
}

Terrain Sampling

给定：

text 复制代码

longitude
latitude

获取：

text 复制代码

height

这类能力其实是GIS应用非常常见的需求。

Camera Control

可以直接控制：

text 复制代码

Camera
Position
Orientation
Frustum

十一、第四层：Shader

如果你是高级开发者：

可以直接进入：

Shader层。

这意味着：

你甚至可以不满足于：

text 复制代码

Navara提供什么效果

而是自己写：

glsl 复制代码

vertex shader
fragment shader

甚至自定义：

text 复制代码

Mesh
Effect
Light
Material

因此Navara形成了一种很有意思的能力阶梯：

text 复制代码

Declarative
     ↓
Plugin
     ↓
API
     ↓
Shader

初学者：

简单。

专业开发者：

自由。

这是Navara想解决的核心矛盾之一。( $GitHub$ $1$ )

十二、Navara支持哪些GIS数据？

目前Navara已经覆盖了比较完整的Web GIS数据体系。

包括：

Raster Tiles

例如：

text 复制代码

XYZ
TMS

用于：

卫星影像
底图
栅格数据

Vector Tiles

主要是：

MVT

也就是：

Mapbox Vector Tile。

这对于WebGIS非常重要。

3D Tiles

这是3D GIS领域非常重要的数据标准。

例如：

text 复制代码

建筑
点云
城市模型

GeoJSON

适合：

text 复制代码

Point
LineString
Polygon

等矢量数据。

Terrain

也就是：

数字高程模型。

最终生成：

text 复制代码

Terrain Mesh

GLB / GLTF

用于：

text 复制代码

3D Model

因此从数据层来看：

Navara已经不是一个单纯的：

3D Globe Demo。

而是逐渐形成完整的：

Geospatial Data Engine。

( $GitHub$ $2$ )

十三、Terrain是一个特别值得关注的部分

Terrain其实是3D GIS里比较难处理的问题。

因为它不仅仅是：

text 复制代码

DEM → Mesh

还涉及：

LOD
Tile
裂缝
邻接关系
父子Tile
相机距离
网格细分

Navara使用了：

RTIN

十四、Navara和Three.js是什么关系？

这个问题非常重要。

Navara：

不是Three.js插件那么简单。

Three.js主要负责：

text 复制代码

Scene
Camera
Mesh
Material
Light
Renderer

Navara则负责：

text 复制代码

Globe
Geospatial Coordinate
Terrain
Tiles
GIS Data
Feature
Spatial Processing

所以更准确的理解是：

text 复制代码

Navara
  │
  ├── GIS Core
  │
  └── Three.js Integration

Three.js是：

Rendering Backend。

而不是：

Navara本身。

Navara官方架构也明确强调，渲染层保持可替换性，当前使用Three.js，但GIS核心并不依赖特定渲染引擎。( $GitHub$ $2$ )

十五、这和Cesium有什么区别？

这是很多GIS开发者最关心的问题。

简单来看：

技术	核心定位
MapLibre	Web地图
OpenLayers	Web GIS
Three.js	3D Graphics
Cesium	3D Globe
Navara	GIS Core + 3D Rendering

Cesium最大的优势之一是：

成熟。

尤其是在：

3D Tiles
Globe
Terrain
Camera
Time Dynamic
Digital Twin

这些方面积累非常深。

所以现在谈：

Navara替代Cesium

显然还为时过早。

Navara当前更值得关注的是：

它选择了不同的架构。

十六、Navara和MapLibre的关系反而更有意思

如果深入研究Navara，会发现它与MapLibre生态存在非常紧密的关系。

Navara已经在考虑：

MapLibre Style Specification。

也就是说：

未来可能直接把：

text 复制代码

style.json

应用到：

3D Globe。

这意味着：

过去：

text 复制代码

MapLibre
 ↓
2D / 2.5D

未来可能出现：

text 复制代码

MapLibre Style
 ↓
Navara
 ↓
3D Globe

这实际上是一个非常有想象空间的方向。

而且Navara已经支持MapLibre生态中的一些核心开放格式，包括MVT、PMTiles等，项目也在推进MapLibre Style Specification相关能力。( $GitHub$ $4$ )

十七、Navara最值得GIS开发者学习的地方

如果让我总结Navara最值得学习的地方，我认为不是某一个API。

而是：

架构思想。

1. GIS Core独立

不要把：

text 复制代码

GIS

和：

text 复制代码

Rendering

绑定。

2. Rust负责计算

把高性能空间计算放到：

text 复制代码

Rust

3. WASM负责浏览器运行

让：

text 复制代码

Rust

进入：

text 复制代码

Browser

4. Three.js负责图形

让：

text 复制代码

GIS

和：

text 复制代码

CG

各自发挥优势。

5. ECS管理复杂空间对象

让GIS从：

text 复制代码

Feature

逐渐走向：

text 复制代码

Entity

十八、这其实正在改变我们对"GIS引擎"的理解

过去我们说GIS引擎，脑子里想到的可能是：

text 复制代码

地图
图层
要素
空间查询
坐标转换

但是实时3D时代出现以后：

GIS引擎可能需要处理：

text 复制代码

Terrain
Tile
Mesh
Material
Camera
LOD
GPU
Shader
Entity
Event

所以：

GIS Engine正在逐渐和Game Engine、Rendering Engine发生融合。

Navara采用Bevy ECS + Rust + Three.js，本质上就是这种趋势的一种体现。

十九、总结

Navara现在还非常年轻。

从GitHub仓库来看，它目前仍然处在快速迭代阶段，版本更新也非常频繁，因此不应该把它当成已经完全成熟的生产级替代方案。( $GitHub$ $5$ )

但是从架构设计来看，它非常值得研究。

因为它把几个重要技术组合到了一起：

text 复制代码

Rust
 +
WebAssembly
 +
Bevy ECS
 +
Three.js
 +
GIS
 +
3D Globe

最终形成：

一个面向浏览器的现代3D GIS Engine。

更重要的是，它提出了一种值得思考的架构：

GIS Core不应该被某一种渲染技术绑定。

空间计算归空间计算。

图形渲染归图形渲染。

应用层再把两者组合起来。

这种思想对于未来：

WebGIS
3D GIS
Digital Twin
Spatial Computing
Spatial Intelligence
AI Agent

都有一定参考价值。

最后

如果只是想做一个：

"地图网站"

Navara可能有点重。

如果想做：

"3D空间应用"

Navara开始变得有意思。

如果想进一步做：

"真实世界数字模型 + AI Agent"

那么Navara这样的架构就更值得关注。

因为未来的GIS可能不再只是：

把世界画在地图上。

而是：

把世界变成一个可以计算、理解、模拟和交互的数字空间。

而这，可能才是：

下一代3D GIS真正值得研究的方向。