release: bump version to 0.49.0
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
linkong
@@ -8,6 +8,19 @@ This project follows the repository versioning rule:
|
||||
- `improvement` -> `+0.0.1`（bugfix + 小功能混合）
|
||||
- `bugfix` -> `+0.0.1`
|
||||
|
||||
## [0.49.0] — 2026-05-08
|
||||
|
||||
Released: 2026-05-08
|
||||
|
||||
### ✨ Features
|
||||
- 新增统一地理位置解析 Pipeline，支持 SourceCoordinates / Nominatim / Registry / Inherit 多策略链式 resolver。
|
||||
- 新增 BGP 采集站与算力中心地理定位服务（`bgp_collector_locations`、`compute_center_locations`、`bgp_event_locations`）。
|
||||
- 新增 Docs Gatekeeper 带鉴权文档 API（`/api/v1/docs`），按用户权限动态返回文档目录与内容。
|
||||
- 新增 Earth 全球新闻栏（`/api/v1/news/earth-feed`），根据地球视角坐标推断地区并聚合多源 RSS 信息流。
|
||||
- Earth 新增 Mobile 算力中心国家高亮（`mobile-center-country-highlight.js`）。
|
||||
|
||||
---
|
||||
|
||||
## [0.48.0] — 2026-05-07
|
||||
|
||||
Released: 2026-05-07
|
||||
|
||||
@@ -29,6 +29,8 @@
|
||||
- [AIS 多源采集、冲突记录与聚合接口计划](/home/ray/dev/linkong/planet/docs/plans/earth-vessel-ais-aggregation-plan.md)
|
||||
- [earth-interactable-layer-plan.md](/home/ray/dev/linkong/planet/docs/plans/earth-interactable-layer-plan.md)
|
||||
- [frontend-public-docs-site-plan.md](/home/ray/dev/linkong/planet/docs/plans/frontend-public-docs-site-plan.md)
|
||||
- [Docs Gatekeeper 鉴权系统计划](/home/ray/dev/linkong/planet/docs/plans/docs-gatekeeper-auth-plan.md)
|
||||
- [Location Resolver 共享管线计划](/home/ray/dev/linkong/planet/docs/plans/location-resolver-shared-pipeline-plan.md)
|
||||
- [frontend-ai-playground-development-plan.md](/home/ray/dev/linkong/planet/docs/plans/frontend-ai-playground-development-plan.md)
|
||||
- [ue5-mvp-fused-plan.md](/home/ray/dev/linkong/planet/docs/plans/ue5-mvp-fused-plan.md)
|
||||
|
||||
|
||||
92
docs/plans/docs-gatekeeper-auth-plan.md
Normal file
92
docs/plans/docs-gatekeeper-auth-plan.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# Docs Gatekeeper 鉴权系统计划
|
||||
|
||||
**状态**：已实现，当前行为见 [Docs Gatekeeper 开发说明](/home/ray/dev/linkong/planet/docs/technical/zh/docs-gatekeeper-development.md)
|
||||
**创建日期**：2026-05-08
|
||||
**核心目标**：把 `/docs` 从前端公开打包 Markdown 改成后端受控读取，并通过用户 Gatekeeper 权限组划分公开文档、用户文档、开发文档和管理/运维文档。
|
||||
|
||||
## 背景
|
||||
|
||||
当前 Docs 页面通过前端 `import.meta.glob(...?raw)` 把 `docs/technical/{zh,en}` 中注册过的 Markdown 直接打进前端 bundle。即使在前端隐藏目录或增加路由守卫，受保护 Markdown 仍可能出现在构建产物中，无法形成真正鉴权。
|
||||
|
||||
本阶段需要把文档正文读取迁到后端，并让后端根据当前用户身份返回可见目录和正文。Earth 仍保持公开访问，其它控制台模块暂不改变既有鉴权。
|
||||
|
||||
## 鉴权模型
|
||||
|
||||
保留现有 `users.role`，新增 `gatekeeper_groups` 作为可叠加的权限组。`role` 继续用于控制台和系统操作；Gatekeeper 只负责 Docs 等内容权限。
|
||||
|
||||
默认权限：
|
||||
|
||||
| 身份 | 默认 Docs 能力 |
|
||||
| --- | --- |
|
||||
| 未登录访客 | `public` |
|
||||
| 普通登录用户 | `public`，以及用户被分配的 Gatekeeper 组 |
|
||||
| `admin` | `docs_admin`，并隐含 `docs_developer` / `docs_user` |
|
||||
| `super_admin` | 全部 Docs 权限 |
|
||||
|
||||
Gatekeeper 组：
|
||||
|
||||
- `docs_user`：登录用户操作类文档。
|
||||
- `docs_developer`：开发、前端、后端、Earth 实现文档。
|
||||
- `docs_admin`：运维、服务控制、凭证、环境变量和敏感操作文档。
|
||||
|
||||
## 初步文档划分
|
||||
|
||||
`public`：
|
||||
|
||||
- `README.md`
|
||||
- `quickstart.md`
|
||||
- `manual.md`
|
||||
|
||||
`docs_developer`：
|
||||
|
||||
- `earth-frontend-context.md`
|
||||
- `earth-interactable-usage.md`
|
||||
- `earth-layer-style-reference.md`
|
||||
- `earth-render-layer-order.md`
|
||||
- `earth-satellite-footprint-policy.md`
|
||||
- `earth-bgp-context.md`
|
||||
- `earth-news-live-streams-collector-format.md`
|
||||
- `earth-toolbar-overlay-coordination.md`
|
||||
- `frontend-admin-frontend-context.md`
|
||||
- `frontend-layout-guidelines.md`
|
||||
- `backend-collectors.md`
|
||||
- `datasource-collector-settings-connectivity.md`
|
||||
- `backend-datasources-api-performance.md`
|
||||
- `agents-aiprovider.md`
|
||||
|
||||
`docs_admin`：
|
||||
|
||||
- `backend-system-service-control.md`
|
||||
- `ops-docker-compose-buildx-upgrade.md`
|
||||
- `ops-planet-sh-startup.md`
|
||||
|
||||
## 实施要点
|
||||
|
||||
后端新增：
|
||||
|
||||
- `GET /api/v1/docs/catalog`：返回当前用户可见文档目录；未登录只返回 `public`。
|
||||
- `GET /api/v1/docs/{lang}/{slug}`：返回单篇 Markdown；未登录访问受保护文档返回 `401`，已登录无权限返回 `403`。
|
||||
- 服务端维护文档 metadata 白名单，禁止任意路径读取。
|
||||
|
||||
用户管理新增：
|
||||
|
||||
- `users.gatekeeper_groups` JSON 字段。
|
||||
- 用户列表、创建和编辑支持展示/配置 Gatekeeper 权限组。
|
||||
- 只有 `super_admin` 能编辑 Gatekeeper 权限组。
|
||||
|
||||
前端 Docs 改造：
|
||||
|
||||
- 移除 Markdown raw import 作为正文来源。
|
||||
- 从后端 catalog 构建目录和搜索记录。
|
||||
- 从后端 content API 加载正文。
|
||||
- 对 `401` 显示登录入口，对 `403` 显示无权限提示。
|
||||
|
||||
## 验证
|
||||
|
||||
- 未登录用户只能看到和读取 `public` 文档。
|
||||
- 未登录直接访问受保护文档返回 `401` 并显示登录提示。
|
||||
- 无 Gatekeeper 组的普通用户访问开发文档返回 `403`。
|
||||
- `docs_developer` 用户能读开发文档，不能读管理/运维文档。
|
||||
- `admin` 和 `super_admin` 能读管理/运维文档。
|
||||
- 未知 slug、未知语言和路径穿越字符串不能读取文件。
|
||||
- 前端构建产物不再包含受保护 Markdown raw import 生成的文档模块。
|
||||
252
docs/plans/earth-mobile-center-country-highlight-plan.md
Normal file
252
docs/plans/earth-mobile-center-country-highlight-plan.md
Normal file
@@ -0,0 +1,252 @@
|
||||
# Earth Mobile Center Country Highlight Plan
|
||||
|
||||
## Goal
|
||||
|
||||
移动端打开 Earth 国界图层后，用屏幕中心，也就是当前镜头正对的地球表面位置，自动识别所在国家，并高亮该国家国界。
|
||||
|
||||
桌面端仍保持现有 hover 行为。移动端不引入新的国界渲染体系，而是复用已有 `country-boundaries.js` 的 GeoJSON 命中和 hover 高亮能力。
|
||||
|
||||
## Criteria for success
|
||||
|
||||
1. 移动端 `layout-mode-mobile` 下，国界图层开启后，屏幕中心所在国家会自动高亮。
|
||||
2. 移动端旋转、缩放、巡航或自动旋转地球时，高亮会跟随镜头中心更新。
|
||||
3. 屏幕中心落在海洋或没有命中地球时，国家高亮会清除。
|
||||
4. 国界图层关闭时，不执行中心国家识别，也不显示残留高亮。
|
||||
5. 桌面端 pointer hover 行为保持不变。
|
||||
6. 移动端抽屉、搜索、设置、媒体、详情等前景 UI 打开时，不因为用户操作 UI 产生明显误高亮或抖动。
|
||||
7. 中心识别有节流或状态缓存，不把 GeoJSON point-in-polygon 检测放到无条件每帧高频执行。
|
||||
8. 实现后能通过本地静态检查或前端构建，并用移动端 viewport 手动或 Playwright 验证核心场景。
|
||||
|
||||
## Existing pieces
|
||||
|
||||
当前项目已经具备大部分基础能力：
|
||||
|
||||
- [frontend/public/earth/js/country-boundaries.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/country-boundaries.js)
|
||||
- `updateCountryBoundaryHover(coords)`：根据 `{ lat, lon }` 命中国家并更新高亮线。
|
||||
- `clearCountryBoundaryHover()`：清除当前 hover 高亮。
|
||||
- `getShowCountryBoundaries()`：判断国界线图层是否可见。
|
||||
- [frontend/public/earth/js/utils.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/utils.js)
|
||||
- `screenToEarthCoords(clientX, clientY, camera, earth, domElement)`：屏幕坐标 raycast 到地球表面。
|
||||
- `vector3ToLatLon(vector)`：地球本地坐标转经纬度。
|
||||
- [frontend/public/earth/js/constants.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/constants.js)
|
||||
- `COUNTRY_BOUNDARY_CONFIG` 已定义普通国界线和 hover 国界线样式。
|
||||
- 移动端布局状态已经通过 `layout-mode-mobile` body class 区分。
|
||||
|
||||
因此本需求的核心不是新增图层，而是补一个移动端中心取点控制器。
|
||||
|
||||
## Non-goals
|
||||
|
||||
- 不改变桌面端 hover 交互。
|
||||
- 不替换 `countries-admin0.min.geojson` 数据源。
|
||||
- 不新增后端 API。
|
||||
- 不把国家面填充做成新的 selected country 面状 shader。
|
||||
- 不为移动端增加永久准星 UI，除非后续产品明确需要视觉准星。
|
||||
|
||||
## Implementation plan
|
||||
|
||||
### 1. Add a small mobile center hover controller
|
||||
|
||||
新增一个轻量函数，建议放在现有主循环附近或单独模块，例如：
|
||||
|
||||
```text
|
||||
frontend/public/earth/js/mobile-center-country-highlight.js
|
||||
```
|
||||
|
||||
建议导出：
|
||||
|
||||
```js
|
||||
updateMobileCenterCountryHighlight({
|
||||
camera,
|
||||
earth,
|
||||
renderer,
|
||||
now,
|
||||
isBlocked,
|
||||
});
|
||||
|
||||
clearMobileCenterCountryHighlight();
|
||||
```
|
||||
|
||||
职责：
|
||||
|
||||
1. 判断是否处于移动端。
|
||||
2. 判断国界图层是否开启。
|
||||
3. 判断当前是否被移动端前景 UI 阻塞。
|
||||
4. 对 renderer canvas 中心点做 raycast。
|
||||
5. 命中地球后转经纬度。
|
||||
6. 调用 `updateCountryBoundaryHover({ lat, lon })`。
|
||||
7. 无命中或禁用时调用 `clearCountryBoundaryHover()`。
|
||||
|
||||
### 2. Use canvas center, not window center
|
||||
|
||||
中心点应基于 renderer canvas rect 计算：
|
||||
|
||||
```js
|
||||
const rect = renderer.domElement.getBoundingClientRect();
|
||||
const clientX = rect.left + rect.width / 2;
|
||||
const clientY = rect.top + rect.height / 2;
|
||||
```
|
||||
|
||||
这样在移动端安全区、地址栏变化、viewport resize 或 canvas 非全屏时仍然准确。
|
||||
|
||||
### 3. Convert center point into country hover coords
|
||||
|
||||
复用已有工具：
|
||||
|
||||
```js
|
||||
const point = screenToEarthCoords(clientX, clientY, camera, earth, renderer.domElement);
|
||||
if (!point) {
|
||||
clearCountryBoundaryHover();
|
||||
return;
|
||||
}
|
||||
|
||||
const coords = vector3ToLatLon(point);
|
||||
updateCountryBoundaryHover(coords);
|
||||
```
|
||||
|
||||
注意：`screenToEarthCoords` 返回的是 earth local point，符合 `vector3ToLatLon` 的输入语义。
|
||||
|
||||
### 4. Gate updates by mobile and foreground UI state
|
||||
|
||||
建议新增一个本地判断函数：
|
||||
|
||||
```js
|
||||
function isMobileCenterCountryHighlightBlocked() {
|
||||
return (
|
||||
!document.body.classList.contains("layout-mode-mobile") ||
|
||||
document.body.classList.contains("earth-search-open") ||
|
||||
document.body.classList.contains("earth-settings-open") ||
|
||||
document.body.classList.contains("earth-media-open") ||
|
||||
document.body.classList.contains("earth-info-open")
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
如果移动端抽屉只是半收起、且没有覆盖中心视野，可以继续允许中心高亮。若实际体验里抽屉展开会遮挡中心点，再把 drawer open 状态纳入阻塞条件。
|
||||
|
||||
### 5. Throttle and cache center updates
|
||||
|
||||
GeoJSON polygon 命中不应该无条件每帧执行。
|
||||
|
||||
第一版建议：
|
||||
|
||||
- `throttleMs = 120`
|
||||
- 缓存上次经纬度，中心点变化小于 `0.05` 度时跳过。
|
||||
- 禁用、切回桌面、图层关闭、UI 阻塞时立即清除一次高亮。
|
||||
|
||||
伪代码：
|
||||
|
||||
```js
|
||||
if (now - lastUpdateAt < 120) return;
|
||||
if (Math.abs(coords.lat - lastLat) < 0.05 && Math.abs(coords.lon - lastLon) < 0.05) return;
|
||||
```
|
||||
|
||||
### 6. Wire into the Earth animation loop
|
||||
|
||||
在 [frontend/public/earth/js/main.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/main.js) 的动画循环中调用：
|
||||
|
||||
```js
|
||||
updateMobileCenterCountryHighlight({
|
||||
camera,
|
||||
earth,
|
||||
renderer,
|
||||
now: performance.now(),
|
||||
isBlocked: isMobileCenterCountryHighlightBlocked(),
|
||||
});
|
||||
```
|
||||
|
||||
这样自动旋转、手势旋转、缩放和巡航都会自然更新。
|
||||
|
||||
### 7. Keep desktop hover unchanged
|
||||
|
||||
桌面 pointer hover 仍然走当前逻辑。
|
||||
|
||||
移动端中心高亮只在 `layout-mode-mobile` 下生效，不应该监听 pointer move，也不应该抢占 desktop hover 状态。
|
||||
|
||||
### 8. Optional visual tuning
|
||||
|
||||
第一版复用：
|
||||
|
||||
- `COUNTRY_BOUNDARY_CONFIG.hoverLineColor`
|
||||
- `COUNTRY_BOUNDARY_CONFIG.hoverLineOpacity`
|
||||
- `COUNTRY_BOUNDARY_CONFIG.hoverGlowOpacity`
|
||||
|
||||
如果移动端体验太强，可以后续加独立配置：
|
||||
|
||||
```js
|
||||
mobileCenterHoverLineOpacity
|
||||
mobileCenterHoverGlowOpacity
|
||||
```
|
||||
|
||||
但第一版不建议过早分叉样式。
|
||||
|
||||
## Verification
|
||||
|
||||
### Static checks
|
||||
|
||||
1. `npm` 前端构建或现有 lint/typecheck 命令通过。
|
||||
2. `rg` 确认新增函数只在移动端路径调用，不影响桌面 pointer hover。
|
||||
3. `git diff --stat` 和目标文件 diff 确认改动范围集中。
|
||||
|
||||
### Manual mobile checks
|
||||
|
||||
使用移动端 viewport，例如 390x844：
|
||||
|
||||
1. 打开 Earth。
|
||||
2. 开启国界图层。
|
||||
3. 转动地球到中国、美国、澳大利亚等大块陆地区域，确认中心国家国界高亮。
|
||||
4. 转动到太平洋或印度洋，确认高亮消失。
|
||||
5. 缩放地球，确认高亮仍跟随中心点。
|
||||
6. 打开移动端搜索、设置、媒体或详情面板，确认没有明显误高亮或抖动。
|
||||
7. 切回桌面 viewport，确认 hover 仍由鼠标位置控制。
|
||||
|
||||
### Playwright smoke check
|
||||
|
||||
如果已有 Playwright 流程，建议补一个移动端 smoke：
|
||||
|
||||
1. 设置 viewport 为手机尺寸。
|
||||
2. 打开 Earth 页面。
|
||||
3. 开启国界图层。
|
||||
4. 等待国界数据加载。
|
||||
5. 截图确认中心附近国家边界有 hover 高亮线。
|
||||
|
||||
这个 smoke 不必断言具体国家名称，因为当前功能核心是视觉高亮；更稳定的自动化可以后续通过暴露 debug state 实现。
|
||||
|
||||
## Risks and mitigations
|
||||
|
||||
### Polygon hit cost too高
|
||||
|
||||
风险：移动端设备上频繁 `featureContains` 可能带来卡顿。
|
||||
|
||||
缓解：
|
||||
|
||||
- 使用 `120ms` 节流。
|
||||
- 经纬度变化小于阈值时跳过。
|
||||
- 后续如仍慢，再为 GeoJSON features 预计算 bbox，先 bbox 粗筛再 point-in-polygon。
|
||||
|
||||
### UI blocking state 不完整
|
||||
|
||||
风险：某些移动端前景 UI 没有对应 body class，中心点被遮挡但高亮仍更新。
|
||||
|
||||
缓解：
|
||||
|
||||
- 第一版覆盖现有主要 class。
|
||||
- 验证时记录遗漏项，补充到 `isMobileCenterCountryHighlightBlocked()`。
|
||||
|
||||
### Desktop hover 被移动端状态污染
|
||||
|
||||
风险：移动端中心高亮和桌面 hover 共用 `_hoveredFeature` 状态。
|
||||
|
||||
缓解：
|
||||
|
||||
- 只在 `layout-mode-mobile` 下运行中心高亮。
|
||||
- 切出 mobile 或图层关闭时调用一次 `clearCountryBoundaryHover()`。
|
||||
- 不改 `updateCountryBoundaryHover()` 的语义。
|
||||
|
||||
## Milestones
|
||||
|
||||
1. 设计落地：完成本 plan，明确目标和验收标准。
|
||||
2. 最小实现：新增移动端中心取点 controller，并接入 animation loop。
|
||||
3. 性能保护：加入节流、经纬度阈值和禁用态清理。
|
||||
4. 验证：本地构建通过，移动端 viewport 手动检查通过。
|
||||
5. 调优：根据截图或真机体验微调阻塞条件和节流阈值。
|
||||
|
||||
127
docs/plans/location-resolver-shared-pipeline-plan.md
Normal file
127
docs/plans/location-resolver-shared-pipeline-plan.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# Location Resolver Shared Pipeline Plan
|
||||
|
||||
**状态**：已实现，当前用户流程见 [Earth 位置候选采集使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-user.md)，开发接口见 [通用位置估算管线开发说明](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-development.md)。
|
||||
|
||||
## Goal
|
||||
|
||||
把"给定一条记录，决定它的 lat/lon"这件事抽象成一条统一的可插拔管线，让算力中心、BGP 观测站、BGP 事件——以及未来任何需要位置估算的实体——共用同一套接口。新算法（peeringdb 设施查询、IXP 表、用户认领的精确点位等）通过实现一个 Resolver 类即可挂入，不需要改任何上层调用方。
|
||||
|
||||
## Background
|
||||
|
||||
### 实施前现状
|
||||
|
||||
- **算力中心** (`backend/app/services/compute_center_locations.py`) 早期曾使用源坐标 → 本地 JSON 注册表 → 城市兜底 → Nominatim 在线地理编码。后续为避免硬编码位置污染事实链路，算力中心本地注册表已移除；主地图只使用源坐标，手动候选采集使用 ROR 和 Nominatim。
|
||||
- **BGP 观测站** (`collectors/bgp_common.py:RIPE_RIS_COLLECTOR_COORDS`) 是一张写死的字典，26 个 RIPE RIS collector 的城市级坐标。新增 collector / 升级到设施级精度都得改 Python。
|
||||
- **BGP 事件**继承所属 collector 的城市级坐标（`BGPObservation.collector_geo`）。
|
||||
- 用户原本以为 BGP 观测站位置是通过 iptoasn 推断的——其实 iptoasn 只用于前缀级国家归属（`bgp_enrichment.py`），不影响 marker 坐标。
|
||||
|
||||
### 痛点
|
||||
|
||||
1. 算力中心那条 4 层链路写死在算力中心模块里，BGP 想用得复制一遍。
|
||||
2. 三类实体各走各的坐标策略，缺统一抽象。
|
||||
3. 未来要插更精的算法（peeringdb / IXP / 用户认领），现在没有挂入点。
|
||||
|
||||
## Design
|
||||
|
||||
### 接口契约
|
||||
|
||||
`backend/app/services/location/`：
|
||||
|
||||
- `models.py` —— `LocationQuery`（输入）、`LocationCandidate`（候选）、`ResolverOutput`（单 resolver 输出）、`ResolutionResult`/`ResolutionDiagnostic`（管线最终结果）
|
||||
- `pipeline.py` —— `LocationResolver` Protocol、`LocationPipeline` 编排器
|
||||
- `resolvers/source_coordinates.py` —— 记录自带 lat/lon 时直通
|
||||
- `resolvers/registry.py` —— 本地 JSON 注册表（locations + city_fallbacks），按别名得分
|
||||
- `resolvers/nominatim.py` —— 通用 Nominatim 客户端（rate-limited + LRU 缓存）+ 可注入 query plan
|
||||
- `resolvers/inherit.py` —— 从外部回调取候选（事件继承 collector 用）
|
||||
- `text.py` —— 文本规范化共享工具
|
||||
|
||||
核心 Protocol：
|
||||
|
||||
```python
|
||||
class LocationResolver(Protocol):
|
||||
name: str
|
||||
def resolve(self, query: LocationQuery) -> ResolverOutput: ...
|
||||
```
|
||||
|
||||
`LocationPipeline.collect_candidates()` 跑全部 resolver，聚合所有候选，按 `(source_rank, precision_rank, -confidence)` 排序去重；`resolve_best()` 选 top 候选。
|
||||
|
||||
### 各领域管线
|
||||
|
||||
```python
|
||||
# compute_center_locations.py（重构后，公共 API 不变）
|
||||
COMPUTE_CENTER_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
])
|
||||
|
||||
COMPUTE_CENTER_COLLECTION_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
ROROrganizationResolver(),
|
||||
NominatimResolver(query_plan_builder=_compute_center_query_plan,
|
||||
geocoder=lambda q: _geocode_online(q)),
|
||||
])
|
||||
|
||||
# bgp_collector_locations.py（新）
|
||||
BGP_COLLECTOR_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
StoredCollectorLocationResolver(),
|
||||
])
|
||||
|
||||
BGP_COLLECTOR_COLLECTION_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
NominatimResolver(query_plan_builder=_bgp_collector_query_plan,
|
||||
geocoder=lambda q: _geocode_online(q)),
|
||||
])
|
||||
|
||||
# bgp_event_locations.py（新）
|
||||
BGP_EVENT_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
InheritFromAnotherEntityResolver(source_lookup=_inherit_from_owning_collector),
|
||||
# 占位：将来插 ASNFacilityResolver / PrefixGeoResolver
|
||||
])
|
||||
```
|
||||
|
||||
### 关键设计决策
|
||||
|
||||
1. **算力中心公共 API 完全不变**：`resolve_compute_center_location()`、`collect_location_candidates()`、`ComputeCenterLocation` dataclass、`_geocode_online` 模块级符号都保留，前端 / 上层调用方零改动；现有 19 个回归测试全绿。
|
||||
2. **`_geocode_online` 用 lambda 晚绑定**：`NominatimResolver(geocoder=lambda q: _geocode_online(q))` 能让测试 `monkeypatch.setattr(module, "_geocode_online", fake)` 继续生效。
|
||||
3. **`RIPE_RIS_COLLECTOR_COORDS` 自动从 DB-backed cache 重建**：启动时 seed/refresh `bgp_collector_locations` 维表，再原地刷新旧 `{rrcXX → {city, country, lat, lon}}` 字典。下游消费者（`bgp_collectors.py`、序列化、detector）不动即可获得新元数据。
|
||||
4. **修复隐藏 bug**：BGP collector 不再通过 registry/operator 模糊匹配晋升候选，避免 `operator="RIPE NCC"` 让每个事件都落到 `rrc00`。
|
||||
5. **事件继承走严格名字查询**：事件继承不跑 collector 的完整 pipeline，改成直接查 DB-backed cache。"改进位置"用户触发流程只跑源坐标和在线地理编码候选。
|
||||
|
||||
## Files
|
||||
|
||||
### 新增
|
||||
- `backend/app/services/location/__init__.py`
|
||||
- `backend/app/services/location/models.py`
|
||||
- `backend/app/services/location/pipeline.py`
|
||||
- `backend/app/services/location/text.py`
|
||||
- `backend/app/services/location/resolvers/__init__.py`
|
||||
- `backend/app/services/location/resolvers/source_coordinates.py`
|
||||
- `backend/app/services/location/resolvers/registry.py`
|
||||
- `backend/app/services/location/resolvers/nominatim.py`
|
||||
- `backend/app/services/location/resolvers/inherit.py`
|
||||
- `backend/app/services/bgp_collector_locations.py`
|
||||
- `backend/app/services/bgp_event_locations.py`
|
||||
- `backend/app/models/bgp_collector_location.py`
|
||||
- `backend/tests/test_location_pipeline.py`（16 用例）
|
||||
- `backend/tests/test_bgp_collector_locations.py`（11 用例）
|
||||
|
||||
### 修改
|
||||
- `backend/app/services/compute_center_locations.py` —— 改为薄包装
|
||||
- `backend/app/services/collectors/bgp_common.py` —— 删除写死字典，改调 `resolve_bgp_event_geo_dict()`
|
||||
- `backend/app/api/v1/bgp.py` —— 新增 `POST /api/v1/bgp/collectors/{collector_id}/collect-location`
|
||||
- `frontend/public/earth/js/info-card.js` —— `renderComputeCenterCollectSection` → `renderLocationCollectSection`，BGP collector 走通用化路径
|
||||
- `frontend/public/earth/js/compute-centers.js` —— 新增通用 `collectLocationCandidates(endpoint, payload)`
|
||||
- `frontend/public/earth/js/main.js` —— `previewComputeCenterCandidate` → `previewLocationCandidate`，事件名改为 `earth:preview-location-candidate`
|
||||
|
||||
## Verification
|
||||
|
||||
- `uv run pytest backend/tests/test_visualization_compute_centers.py` —— 19 个用例全绿（公共 API 未改）
|
||||
- `uv run pytest backend/tests/test_location_pipeline.py backend/tests/test_bgp_collector_locations.py` —— 16 + 11 用例全绿
|
||||
- 抽象可插拔性测试：`test_pluggability_custom_resolver_works_without_changing_pipeline` —— 临时实现 `_PeeringDBStubResolver` 直接接入 `LocationPipeline`，验证管线不需要改一行就能识别新 source
|
||||
|
||||
## Out of scope
|
||||
|
||||
- 持久化用户认领的精确坐标（写回 JSON 注册表）—— `suggested_registry_entry` 字段已就绪，工作流单独立项
|
||||
- 真正实现 `ASNFacilityResolver` / `PrefixGeoResolver` —— 接口已留好，具体算法（peeringdb / IXP 表 / iptoasn 升级）单独立项
|
||||
- 算力中心 / 观测站 marker 合并避让 —— 上一轮已用 `SURFACE_AVOIDANCE_PROFILES.city` + halo 收敛解决
|
||||
@@ -25,8 +25,12 @@ What belongs here:
|
||||
|
||||
- [Quickstart](/home/ray/dev/linkong/planet/docs/technical/en/quickstart.md): The shortest path to getting Planet running from scratch
|
||||
- [Planet Manual](/home/ray/dev/linkong/planet/docs/technical/en/manual.md): Complete usage guide for the console, `planet.sh`, Earth, and Docs
|
||||
- [Earth Location Candidate Collection User Guide](/home/ray/dev/linkong/planet/docs/technical/en/location-pipeline-user.md): Collect and preview coordinate candidates for compute centers and BGP collectors on Earth
|
||||
- [Collector Settings and Connectivity Validation](/home/ray/dev/linkong/planet/docs/technical/en/datasource-collector-settings-connectivity.md): Data source catalog, collector settings, connectivity validation, and BarentsWatch credentials
|
||||
- [Shared Location Resolution Pipeline Development Guide](/home/ray/dev/linkong/planet/docs/technical/en/location-pipeline-development.md): Backend location resolver / pipeline interfaces, registries, and extension points
|
||||
- [Docs Gatekeeper Development Guide](/home/ray/dev/linkong/planet/docs/technical/en/docs-gatekeeper-development.md): Backend Docs catalog, Markdown content loading, and Gatekeeper permission groups
|
||||
- [Earth Interactable Usage](/home/ray/dev/linkong/planet/docs/technical/en/earth-interactable-usage.md): API, lifecycle, and integration examples for Earth surface icon Interactable
|
||||
- [Earth Toolbar and Overlay Coordination](/home/ray/dev/linkong/planet/docs/technical/en/earth-toolbar-overlay-coordination.md): Closing matrix and integration rules for toolbar buttons, search, settings, news, and layer overlays
|
||||
|
||||
What does not belong here:
|
||||
|
||||
|
||||
@@ -87,6 +87,10 @@ async def run(self, db):
|
||||
| BarentsWatch AIS | vessel | AIS vessel positions, speed, heading, MMSI, and related fields | Collector settings |
|
||||
| AISStream Vessels | vessel_ais | AIS WebSocket realtime stream, written to the raw observation layer and displayed through aggregation | Collector settings |
|
||||
|
||||
AIS vessel collectors use a different persistence path from regular `CollectedData` collectors. BarentsWatch, AISStream, and custom `vessel_ais` sources write into the AIS raw observation layer first, then the aggregation service merges those observations into the GeoJSON and detail payloads used by the Earth vessel layer. This preserves source, transport, field conflicts, and observation time instead of letting one realtime source overwrite the final display table.
|
||||
|
||||
TOP500 and Epoch AI compute sources do not always provide usable coordinates. The unified Earth compute-center endpoint uses only valid source-provided coordinates or `compute_center_locations` dimension-table coordinates during the main map startup path; records without coordinates are returned as `unresolved` instead of being rendered from a local registry, country centroid, or guessed city. When users manually collect candidates, the backend queries ROR and Nominatim/OpenStreetMap from source fields; accepted candidates are saved into `compute_center_locations` and rendered from that table on the next layer refresh.
|
||||
|
||||
## IV. Data Format (stored in CollectedData table)
|
||||
|
||||
```python
|
||||
@@ -213,13 +217,136 @@ backend/app/services/collectors/
|
||||
├── epoch_ai.py # Epoch AI collector
|
||||
├── huggingface.py # HuggingFace collector
|
||||
├── peeringdb.py # PeeringDB collector
|
||||
└── telegeraphy.py # TeleGeography submarine cable collector
|
||||
├── telegeraphy.py # TeleGeography submarine cable collector
|
||||
├── vessel_ais.py # BarentsWatch AIS vessel collector
|
||||
└── aisstream.py # AISStream WebSocket vessel collector
|
||||
|
||||
backend/app/services/
|
||||
├── custom_datasource_runtime.py # Custom REST / WebSocket mapping runtime
|
||||
├── datasource_mapping.py # Deterministic field mapping and target writes
|
||||
├── vessel_ais_aggregation.py # AIS raw observation writes and aggregate reads
|
||||
├── vessel_aggregation_strategy.py # Multi-source field selection, freshness fallback, and conflict records
|
||||
└── vessel_enrichment.py # Vessel profile enrichment cache
|
||||
|
||||
backend/app/models/
|
||||
└── collected_data.py # Unified data model
|
||||
├── collected_data.py # Unified data model
|
||||
└── vessel_enrichment.py # Vessel enrichment cache
|
||||
```
|
||||
|
||||
## IX. Data Usage
|
||||
## IX. Credentialed Collectors
|
||||
|
||||
Some collectors require external service credentials:
|
||||
|
||||
| Collector | Credential provider | Credential sources |
|
||||
| --- | --- | --- |
|
||||
| `barentswatch_vessels` | `barentswatch` | Console collector settings, environment variables, `~/.zshrc` |
|
||||
| `aisstream_vessels` | `aisstream` | Console collector settings, environment variables, `~/.zshrc` for connectivity checks; save it in collector settings or inject it into the backend environment for collection |
|
||||
| `spacetrack_tle` | `spacetrack` | Environment variables, `~/.zshrc` |
|
||||
|
||||
### BarentsWatch AIS
|
||||
|
||||
BarentsWatch AIS credential resolution is centralized in:
|
||||
|
||||
- [barentswatch.py](/home/ray/dev/linkong/planet/backend/app/services/barentswatch.py)
|
||||
|
||||
`VesselAISCollector` only collects and transforms AIS data. It no longer reads environment variables or builds token requests directly. It uses:
|
||||
|
||||
- `resolve_barentswatch_config()`
|
||||
- `fetch_barentswatch_access_token()`
|
||||
|
||||
Resolution priority:
|
||||
|
||||
1. `DataSourceConfig.auth_config`
|
||||
2. `DataSourceConfig.config`
|
||||
3. Environment variables
|
||||
4. `~/.zshrc`
|
||||
|
||||
Supported variables:
|
||||
|
||||
```bash
|
||||
export BARENTSWATCH_CLIENT_ID="..."
|
||||
export BARENTSWATCH_CLIENT_SECRET="..."
|
||||
```
|
||||
|
||||
Historical misspellings are also supported:
|
||||
|
||||
```bash
|
||||
export BARRENTSWATCH_CLIENT_ID="..."
|
||||
export BARRENTSWATCH_CLIENT_SECRET="..."
|
||||
```
|
||||
|
||||
Connectivity validation requests `https://id.barentswatch.no/connect/token` for an access token with `scope=ais`, then requests the AIS endpoint with `Authorization: Bearer <token>`.
|
||||
|
||||
### AISStream Realtime Vessels
|
||||
|
||||
AISStream uses the `wss://stream.aisstream.io/v0/stream` WebSocket endpoint. Its default runtime is a long-lived realtime collector rather than the traditional REST pattern of one request, progress to 100%, then completion.
|
||||
|
||||
Runtime configuration:
|
||||
|
||||
- `api_key`: read first from `DataSourceConfig.auth_config.api_key` or `config.api_key`; it can also come from the backend process environment variable `AISSTREAM_API_KEY`.
|
||||
- `bounding_boxes`: AISStream subscription bounds. The default example is global `[[[-90, -180], [90, 180]]]`; demos and production runs should usually start with a smaller area.
|
||||
- `message_types`: defaults to `PositionReport` and `ShipStaticData`.
|
||||
- `streaming_enabled`: enables long-lived streaming by default; disabling it falls back to batch-style `fetch -> transform -> save`.
|
||||
- `streaming_max_messages`: test-only stop limit. Non-zero values stop the stream after the requested number of messages.
|
||||
- `reconnect_delay_seconds` and `receive_timeout_seconds`: control reconnect delay and idle receive waits.
|
||||
|
||||
State semantics:
|
||||
|
||||
- `connecting`: connecting to AISStream.
|
||||
- `streaming`: receiving realtime messages; `records_processed` means messages seen, usually without a fixed total or percentage.
|
||||
- `reconnecting`: upstream or network interruption; the collector records `AISSourceHealth` and waits before reconnecting.
|
||||
- `stopped` / `cancelled`: stopped by a test limit or user action.
|
||||
|
||||
AISStream connectivity validation reads the saved collector configuration, environment variables, and `AISSTREAM_API_KEY` in `~/.zshrc` through `datasource_connectivity.py`. For actual collection, the most reliable path is saving the API key in `Settings -> Collector Settings -> AISStream Vessels`; if the key only lives in `~/.zshrc`, confirm that the backend process inherited it.
|
||||
|
||||
### AIS Raw Observations And Aggregation
|
||||
|
||||
AIS observations do not directly replace final vessel records. They are first saved as raw observations:
|
||||
|
||||
- `source` records the origin, such as `barentswatch_vessels`, `aisstream_vessels`, or a custom source name.
|
||||
- `delivery_mode` captures realtime quality; `realtime_stream` outranks `polling`.
|
||||
- `transport` records `websocket` or `http`.
|
||||
- Dynamic fields such as position, speed, and course are selected by freshness and source priority.
|
||||
- Static fields prefer non-empty values; conflicting candidates are recorded for detail and diagnostics views.
|
||||
|
||||
Earth still reads vessel data from:
|
||||
|
||||
```http
|
||||
GET /api/v1/visualization/geo/vessels
|
||||
GET /api/v1/visualization/vessels/{mmsi}
|
||||
GET /api/v1/visualization/vessels/{mmsi}/track
|
||||
GET /api/v1/visualization/vessels/{mmsi}/conflicts
|
||||
GET /api/v1/visualization/vessels/aggregation/diagnostics
|
||||
```
|
||||
|
||||
`/geo/vessels` merges raw observation aggregation with the legacy BarentsWatch latest-position tables so adding AISStream does not hide historical BarentsWatch-only vessels.
|
||||
|
||||
## X. Collector Settings And Connectivity Validation
|
||||
|
||||
The console "Collector Settings" page owns endpoint, headers, timeouts, retries, and credentials for all built-in collectors. Connectivity is derived by the backend checksum rather than by frontend button styling:
|
||||
|
||||
- endpoint
|
||||
- auth type
|
||||
- headers
|
||||
- config
|
||||
- credential provider
|
||||
- credential fingerprint
|
||||
|
||||
Related APIs:
|
||||
|
||||
```http
|
||||
GET /api/v1/datasources/configs/all
|
||||
POST /api/v1/datasources/configs/builtin/connection-status
|
||||
POST /api/v1/datasources/configs/builtin/connect
|
||||
POST /api/v1/settings/integrations/barentswatch/connect
|
||||
GET /api/v1/settings/credential-guides/{provider}
|
||||
POST /api/v1/settings/credential-guides/{provider}/generate
|
||||
POST /api/v1/settings/credential-guides/{provider}/reset
|
||||
```
|
||||
|
||||
See [Collector Settings and Connectivity Validation](/home/ray/dev/linkong/planet/docs/technical/en/datasource-collector-settings-connectivity.md) for the full flow.
|
||||
|
||||
## XI. Data Usage
|
||||
|
||||
Collected data ultimately:
|
||||
|
||||
@@ -227,7 +354,7 @@ Collected data ultimately:
|
||||
2. **Situational analysis** — global compute distribution statistics and growth trends
|
||||
3. **Alert system** — detects changes to important nodes
|
||||
|
||||
## X. Collector Registration
|
||||
## XII. Collector Registration
|
||||
|
||||
Collectors are automatically registered at application startup:
|
||||
|
||||
@@ -249,7 +376,7 @@ collector_registry.register(TeleGeographyCableSystemCollector())
|
||||
|
||||
**Core file**: `backend/app/services/collectors/registry.py`
|
||||
|
||||
## XI. Triggering Collection
|
||||
## XIII. Triggering Collection
|
||||
|
||||
### Method 1: Scheduled
|
||||
|
||||
|
||||
99
docs/technical/en/backend-datasources-api-performance.md
Normal file
99
docs/technical/en/backend-datasources-api-performance.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# DataSources List API Performance Optimization
|
||||
|
||||
## Background
|
||||
|
||||
`GET /api/v1/datasources` is the core API for the Data Sources page. Slow responses directly block page rendering.
|
||||
|
||||
## Query Path Before Optimization
|
||||
|
||||
`_load_datasource_list_context` used to run these queries sequentially:
|
||||
|
||||
| Order | Function | Query | Bottleneck |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | `_load_latest_running_tasks` | `collection_tasks` window query; stale check depends on this result | Must be serial |
|
||||
| 2 | `_load_latest_completed_tasks` | `collection_tasks` window query for latest completed tasks | Serial wait |
|
||||
| 3 | `_load_datasource_data_counts` | `COUNT(*) GROUP BY source` on `collected_data` | Slow full-table scan |
|
||||
| 4 | `_load_datasource_endpoint_overrides` | Simple `datasource_configs` SELECT | Serial wait |
|
||||
|
||||
## Phase 1: Parallelization
|
||||
|
||||
The independent queries 2, 3, and 4 were moved to `asyncio.gather` with separate sessions:
|
||||
|
||||
```python
|
||||
async def _fetch_completed():
|
||||
async with async_session_factory() as s:
|
||||
return await _load_latest_completed_tasks(s, datasource_ids)
|
||||
|
||||
async def _fetch_counts():
|
||||
async with async_session_factory() as s:
|
||||
return await _load_datasource_data_counts(s, sources)
|
||||
|
||||
async def _fetch_overrides():
|
||||
async with async_session_factory() as s:
|
||||
return await _load_datasource_endpoint_overrides(s, sources)
|
||||
|
||||
completed_tasks, data_counts, endpoint_overrides = await asyncio.gather(
|
||||
_fetch_completed(), _fetch_counts(), _fetch_overrides(),
|
||||
)
|
||||
```
|
||||
|
||||
SQLAlchemy `AsyncSession` does not support concurrent use from multiple coroutines, so every parallel branch needs its own session.
|
||||
|
||||
## Phase 2: Remove Heavy Queries
|
||||
|
||||
### Remove `_load_datasource_data_counts`
|
||||
|
||||
`data_count` was only used by the frontend to show an edge-case `(0 records)` hint in the latest collection column. It was not worth keeping a `COUNT(*) GROUP BY` full-table scan.
|
||||
|
||||
- Frontend `(0 records)` display logic was removed.
|
||||
- `data_count` was removed from the `BuiltInDataSource` interface.
|
||||
|
||||
### Remove `_load_latest_completed_tasks`
|
||||
|
||||
`last_status` and `last_run_at` are already written to the `DataSource` model when collectors finish, so the list endpoint no longer needs to join `collection_tasks`:
|
||||
|
||||
```python
|
||||
# Before: completed_tasks query required
|
||||
last_run_at = datasource.last_run_at or (last_task.completed_at if last_task else None)
|
||||
last_status = datasource.last_status or (last_task.status if last_task else None)
|
||||
|
||||
# After: read model fields directly
|
||||
last_run_at = datasource.last_run_at
|
||||
last_status = datasource.last_status
|
||||
```
|
||||
|
||||
`last_records_processed` was removed as well because it came from completed task rows and is not displayed in the list.
|
||||
|
||||
## Query Path After Optimization
|
||||
|
||||
```text
|
||||
datasources SELECT -> required primary data
|
||||
_load_latest_running_tasks -> required for running state and stale check
|
||||
_load_datasource_endpoint_overrides -> required for endpoint overrides and collector settings display
|
||||
```
|
||||
|
||||
The endpoint now runs three queries instead of five. The last two run sequentially because running tasks are needed for stale checks and endpoint overrides are lightweight.
|
||||
|
||||
## Frontend `triggerDatasource` Double Refresh Fix
|
||||
|
||||
`triggerDatasource` previously called `fetchData()` twice:
|
||||
|
||||
```typescript
|
||||
// Before
|
||||
} else {
|
||||
window.setTimeout(() => { fetchData() }, 800)
|
||||
}
|
||||
fetchData()
|
||||
|
||||
// After: mutually exclusive
|
||||
if (res.data.task_id) {
|
||||
fetchData()
|
||||
} else {
|
||||
window.setTimeout(fetchData, 800)
|
||||
}
|
||||
```
|
||||
|
||||
## Related Files
|
||||
|
||||
- [datasources.py](/home/ray/dev/linkong/planet/backend/app/api/v1/datasources.py): `_load_datasource_list_context`, `list_datasources`
|
||||
- [DataSources.tsx](/home/ray/dev/linkong/planet/frontend/src/pages/DataSources/DataSources.tsx): `BuiltInDataSource`, `triggerDatasource`
|
||||
@@ -62,7 +62,7 @@ File:
|
||||
Current behavior:
|
||||
|
||||
- The `collector_credentials` tab is displayed as "Collector Settings".
|
||||
- A select lists all built-in collectors.
|
||||
- A select lists built-in collectors and supports maintaining custom supplemental sources that merge into built-in data.
|
||||
- The only button beside the select is a plug icon for health checks.
|
||||
- Status tags below the select show:
|
||||
- `Credentials required` / `No credentials required`
|
||||
@@ -72,6 +72,8 @@ Current behavior:
|
||||
- Whether the endpoint is overridden
|
||||
- Collectors that require credentials place the credential card above base configuration.
|
||||
- Collectors without credentials only show base configuration.
|
||||
- The AISStream collector uses WebSocket semantics: connecting, streaming, reconnecting, or stopped. It does not use a fixed completion percentage.
|
||||
- Custom source editing lives in collector settings. The data source catalog keeps overview, run controls, and read-only drawers.
|
||||
|
||||
The connection button uses an inline Tabler-style plug icon with `plug-connected` semantics, avoiding the older refresh icon for a connection action.
|
||||
|
||||
@@ -284,6 +286,100 @@ Normalization:
|
||||
- Vessel type usually comes from lower-frequency `ShipStaticData.Type`; the backend maps AIS numeric type codes to Cargo / Tanker / Passenger / Fishing / Military.
|
||||
- If a vessel has not yet produced a static message, its aggregated type can still be `Other`; v5 vessel profile enrichment is planned to fill that gap.
|
||||
|
||||
Connectivity validation reads saved configuration, environment variables, and `AISSTREAM_API_KEY` from `~/.zshrc`. For actual collection, prefer saving the API key in collector settings. If the key only lives in `~/.zshrc`, confirm that the backend process inherited it; otherwise validation may pass while the collector runtime cannot read the key.
|
||||
|
||||
## Custom REST / WebSocket Mapping Runtime
|
||||
|
||||
Files:
|
||||
|
||||
- [custom_datasource_runtime.py](/home/ray/dev/linkong/planet/backend/app/services/custom_datasource_runtime.py)
|
||||
- [datasource_mapping.py](/home/ray/dev/linkong/planet/backend/app/services/datasource_mapping.py)
|
||||
|
||||
Custom sources are supplemental inputs for existing target schemas, not isolated data islands. The most complete target today is `vessel_ais`: a custom REST or WebSocket source is mapped deterministically, written into AIS raw observations, and then pushed to Earth through the `vessels` WebSocket channel.
|
||||
|
||||
### Configuration Semantics
|
||||
|
||||
Important fields:
|
||||
|
||||
- `source_type`: `rest` / `http` / `websocket` / `ws`.
|
||||
- `endpoint`: REST uses `http(s)://`; WebSocket uses `ws(s)://`.
|
||||
- `auth_type`: `none`, `bearer`, `api_key`, or `basic`.
|
||||
- `headers`: static request headers.
|
||||
- `auth_config`: token, API key, or basic username/password; API keys can be sent by header or query.
|
||||
- `config.target_schema`: for example `vessel_ais`.
|
||||
- `config.delivery_mode`: REST defaults to `polling`; WebSocket defaults to `realtime_stream`.
|
||||
- `config.merge_target_source`: records which built-in source this custom source supplements, such as `barentswatch_vessels`.
|
||||
|
||||
The REST runner supports:
|
||||
|
||||
- `GET` / `POST`
|
||||
- query params
|
||||
- JSON body
|
||||
- headers and auth injection
|
||||
- active mapping writes into the target schema
|
||||
|
||||
The WebSocket runner supports:
|
||||
|
||||
- endpoint format validation
|
||||
- headers and auth injection
|
||||
- optional `ws_subscribe_message`
|
||||
- `ws_message_path` / `ws_items_path` extraction
|
||||
- reconnects
|
||||
- `debug_max_messages` debug limits
|
||||
- background stream start / stop / status
|
||||
|
||||
Related APIs:
|
||||
|
||||
```http
|
||||
POST /api/v1/datasources/custom/sample
|
||||
GET /api/v1/datasources/target-schemas
|
||||
POST /api/v1/datasources/{config_id}/run-mapped
|
||||
POST /api/v1/datasources/{config_id}/stop-mapped
|
||||
GET /api/v1/datasources/{config_id}/mapped-status
|
||||
DELETE /api/v1/datasources/configs/{config_id}?delete_mappings=true&delete_source_data=true
|
||||
```
|
||||
|
||||
`run-mapped?background=true` only matters for WebSocket sources and starts a background stream. REST sources remain one-shot collection runs.
|
||||
|
||||
### Delete And Data Cleanup
|
||||
|
||||
Deleting a custom source has three levels:
|
||||
|
||||
- Delete configuration only: preserve mapping and historical data.
|
||||
- Delete configuration and mapping: also delete mapping templates for that config.
|
||||
- Delete configuration, mapping, and source data: delete that source's `collected_data`, `ais_raw_observations`, and `ais_source_health`.
|
||||
|
||||
When deleted `vessel_ais` source data affects Earth, the backend broadcasts `reload_required` on the `vessels` channel so Earth reloads aggregated vessels. Legacy `vessel_position` rows are not deleted by custom source because that table cannot safely attribute rows back to a custom source.
|
||||
|
||||
### Local AIS Mock WebSocket
|
||||
|
||||
File:
|
||||
|
||||
- [mock-ais-ws-server.ts](/home/ray/dev/linkong/planet/scripts/mock-ais-ws-server.ts)
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
bun run mock:ais-ws
|
||||
```
|
||||
|
||||
The mock service continuously sends AIS-like JSON to validate the chain: WebSocket custom source -> mapping -> AIS raw observation -> `vessels` channel -> Earth vessel upsert. Typical config:
|
||||
|
||||
```json
|
||||
{
|
||||
"source_type": "websocket",
|
||||
"endpoint": "ws://localhost:8787",
|
||||
"config": {
|
||||
"target_schema": "vessel_ais",
|
||||
"delivery_mode": "realtime_stream",
|
||||
"merge_target_source": "barentswatch_vessels",
|
||||
"ws_message_path": "$.data",
|
||||
"ws_items_path": "$.vessels[*]",
|
||||
"ws_reconnect": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Credential Guide
|
||||
|
||||
File:
|
||||
@@ -345,6 +441,7 @@ Added coverage:
|
||||
Credential providers currently supported:
|
||||
|
||||
- `barentswatch`
|
||||
- `aisstream`
|
||||
- `spacetrack`
|
||||
|
||||
Other collectors with `requires_credentials=true` return that their credential chain has not been wired yet, and the frontend shows `Unavailable`.
|
||||
|
||||
116
docs/technical/en/docs-gatekeeper-development.md
Normal file
116
docs/technical/en/docs-gatekeeper-development.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# Docs Gatekeeper Development Guide
|
||||
|
||||
Docs Gatekeeper moves `/docs` from "bundle all Markdown into the frontend" to "return catalog and content from the backend according to permissions." Its goal is to keep public manuals, user docs, developer docs, and admin/ops docs in one searchable Docs page while making every protected Markdown body pass through a server-side whitelist and authorization check.
|
||||
|
||||
For the user workflow, see the Docs section in [Planet Manual](/home/ray/dev/linkong/planet/docs/technical/en/manual.md).
|
||||
|
||||
## Authorization Model
|
||||
|
||||
Docs uses two permission layers:
|
||||
|
||||
- `users.role`: preserved for console/system permissions.
|
||||
- `users.gatekeeper_groups`: Docs content permission groups.
|
||||
|
||||
Groups:
|
||||
|
||||
| Group | Purpose |
|
||||
| --- | --- |
|
||||
| `docs_user` | User-operation docs |
|
||||
| `docs_developer` | Earth, frontend, backend, collector, and AI Provider development docs |
|
||||
| `docs_admin` | Service control, operations, environment, and sensitive-operation docs |
|
||||
|
||||
Inheritance:
|
||||
|
||||
- Anonymous users can only read `public`.
|
||||
- `docs_developer` includes `docs_user`.
|
||||
- `docs_admin` includes `docs_developer` and `docs_user`.
|
||||
- `admin` and `super_admin` receive all Docs permissions by default.
|
||||
|
||||
## Backend Entry Points
|
||||
|
||||
Files:
|
||||
|
||||
- [docs.py](/home/ray/dev/linkong/planet/backend/app/api/v1/docs.py)
|
||||
- [docs_gatekeeper.py](/home/ray/dev/linkong/planet/backend/app/services/docs_gatekeeper.py)
|
||||
- [user.py](/home/ray/dev/linkong/planet/backend/app/models/user.py)
|
||||
- [users.py](/home/ray/dev/linkong/planet/backend/app/api/v1/users.py)
|
||||
|
||||
APIs:
|
||||
|
||||
```http
|
||||
GET /api/v1/docs/catalog
|
||||
GET /api/v1/docs/{lang}/{slug}
|
||||
```
|
||||
|
||||
`catalog` returns only documents visible to the current user. The content endpoint validates language, slug, and file existence through the metadata whitelist before checking access:
|
||||
|
||||
- Anonymous protected-doc request: `401`.
|
||||
- Authenticated but insufficient permissions: `403`.
|
||||
- Unknown language, unknown slug, or missing file: `404`.
|
||||
|
||||
Markdown bodies can only come from whitelisted files under `docs/technical/{zh,en}/`; arbitrary path reads are not allowed.
|
||||
|
||||
## Metadata Source
|
||||
|
||||
Server-side metadata lives in [docs_gatekeeper.py](/home/ray/dev/linkong/planet/backend/app/services/docs_gatekeeper.py):
|
||||
|
||||
```python
|
||||
DocsMetadata(
|
||||
"manual.md",
|
||||
"manual",
|
||||
"public",
|
||||
"Manual",
|
||||
2,
|
||||
"Planet 使用手册",
|
||||
"Planet Manual",
|
||||
)
|
||||
```
|
||||
|
||||
When adding a public technical doc:
|
||||
|
||||
- Add both Chinese and English Markdown files.
|
||||
- Add filename, slug, access, group, order, and titles to server `DOCS_METADATA`.
|
||||
- Add matching metadata to frontend [docs-content.ts](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/docs-content.ts) so navigation titles and sorting stay aligned.
|
||||
- Update `docs/technical/zh/README.md` and `docs/technical/en/README.md` when the document should be discoverable from the README.
|
||||
|
||||
## User Management
|
||||
|
||||
The `users` table has `gatekeeper_groups JSONB DEFAULT '[]'`. Startup [session.py](/home/ray/dev/linkong/planet/backend/app/db/session.py) applies `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` for existing local databases.
|
||||
|
||||
The user API:
|
||||
|
||||
- Writes `gatekeeper_groups` during user creation.
|
||||
- Validates group names on update: only `docs_user`, `docs_developer`, and `docs_admin` are accepted.
|
||||
- Allows only `super_admin` to modify Gatekeeper groups.
|
||||
|
||||
Frontend [Users.tsx](/home/ray/dev/linkong/planet/frontend/src/pages/Users/Users.tsx) displays group tags and provides a multi-select in the edit form. Non-`super_admin` users see the field disabled, and submission removes `gatekeeper_groups` before sending.
|
||||
|
||||
## Frontend Docs Loading
|
||||
|
||||
Files:
|
||||
|
||||
- [Docs.tsx](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/Docs.tsx)
|
||||
- [docs-content.ts](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/docs-content.ts)
|
||||
- [docs-search.ts](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/docs-search.ts)
|
||||
|
||||
Key changes:
|
||||
|
||||
- Remove `import.meta.glob(...?raw)` as the Markdown content source.
|
||||
- Load `/api/v1/docs/catalog` to build the visible navigation.
|
||||
- Load `/api/v1/docs/{lang}/{slug}` for document bodies.
|
||||
- Index search only across currently visible docs, loading Markdown from the backend as needed.
|
||||
- Show login state for `401`, permission state for `403`, and unavailable-doc state for `404`.
|
||||
|
||||
## Test Coverage
|
||||
|
||||
Relevant tests:
|
||||
|
||||
- [test_docs_gatekeeper.py](/home/ray/dev/linkong/planet/backend/tests/test_docs_gatekeeper.py)
|
||||
|
||||
Tests should cover:
|
||||
|
||||
- Anonymous users only see public docs.
|
||||
- Protected content returns `401` or `403` appropriately.
|
||||
- `docs_developer` can read developer docs but not admin docs.
|
||||
- `admin` and `super_admin` can read admin docs.
|
||||
- Unknown slugs, unknown languages, and path traversal strings cannot read files.
|
||||
@@ -99,7 +99,7 @@ Responsibilities:
|
||||
- [vessels.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/vessels.js)
|
||||
- [bgp.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/bgp.js)
|
||||
- [bgp-cruise-adapter.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/bgp-cruise-adapter.js)
|
||||
- [compute-centers.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/compute-centers.js)
|
||||
- [compute-centers.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/compute-centers.js) renders supercomputer and GPU-cluster markers. The backend renders compute centers only from source-provided coordinates or `compute_center_locations` dimension-table coordinates during startup; manual candidate collection can query ROR and Nominatim/OpenStreetMap, and the layer keeps the `?` badge for unconfirmed positions while the details card shows precision, confidence, source notes, and verification date.
|
||||
- [country-boundaries.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/country-boundaries.js)
|
||||
|
||||
Each module is responsible for its own:
|
||||
@@ -109,6 +109,8 @@ Each module is responsible for its own:
|
||||
- State tracking (loaded, visible, hover, locked)
|
||||
- Self-cleanup (dispose on scene destroy)
|
||||
|
||||
The compute-center layer row has a notification badge for GeoJSON `unresolved` records. The badge means "no trustworthy coordinates, cannot render on the globe"; it is different from the `?` marker drawn on already positioned but unconfirmed compute centers. Clicking the badge opens a fixed info card beside the layer panel. Row-level `采集` fetches candidates only. Header-level `一键采用` processes the queue top-to-bottom, saves the highest-confidence valid candidate, removes successful rows, renumbers the list, and dispatches `earth:compute-center-unresolved-count-change` so the badge updates immediately. When the batch ends, `earth:compute-center-location-saved` refreshes the real layer.
|
||||
|
||||
### AIS Vessel Layer
|
||||
|
||||
The vessel layer fetches `/api/v1/visualization/geo/vessels` and renders the aggregated AIS GeoJSON through `createInteractableLayer()`. By default it does not send a `limit` parameter, and `VESSEL_CONFIG.maxRenderedMarkers = 0` means the frontend does not clip the result to 5000 vessels. A positive `options.limit` or positive `maxRenderedMarkers` can still be used as an explicit temporary cap.
|
||||
@@ -154,6 +156,8 @@ Layer toggle buttons use `data-status-target` attributes to link button state to
|
||||
|
||||
This is the canonical way to synchronize button visual state with actual layer state. Do not maintain separate boolean flags for button display.
|
||||
|
||||
Terrain should not block startup when it is not the restored visible layer. After deferred layer visibility settings are applied, `controls.js` schedules `scheduleTerrainPrefetch()` only when HD texture is enabled, terrain is not ready, and no prefetch is already running. The prefetch uses `setTimeout` plus `requestIdleCallback` so cloud, HD texture, and startup layer work keep first-screen priority.
|
||||
|
||||
## Current Settings Persistence
|
||||
|
||||
Earth settings are stored in `localStorage`. The key is typically a namespaced string defined in `constants.js`. `controls.js` handles read, write, and reset.
|
||||
@@ -171,6 +175,8 @@ Settings that affect visual layers (terrain opacity, day/night mode, satellite d
|
||||
|
||||
When HD texture is off, terrain is temporarily hidden and its state is remembered. When HD texture comes back on, terrain restores its prior visibility.
|
||||
|
||||
Terrain tile fetching is batched. `terrain.js` deduplicates required Terrarium tile keys and sends chunks sized by `TERRAIN_CONFIG.batchRequestSize` to `/api/v1/visualization/terrain/terrarium/batch`. The backend proxies S3 Terrarium tiles with an in-memory LRU cache, per-batch deduplication, and bounded concurrency. The single tile endpoint remains for fallback paths and browser cache semantics.
|
||||
|
||||
## Current High-Frequency Risk Points
|
||||
|
||||
### 1. Visual State and Business State Out of Sync
|
||||
|
||||
86
docs/technical/en/earth-toolbar-overlay-coordination.md
Normal file
86
docs/technical/en/earth-toolbar-overlay-coordination.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Earth Toolbar And Overlay Coordination
|
||||
|
||||
This document describes the current coordination rules between the Earth toolbar buttons and the search panel, settings modal, news/live panel, and layer panel. Use this matrix when changing interactions, adding buttons, or adjusting panels so one action does not close an unrelated overlay.
|
||||
|
||||
Related entries:
|
||||
|
||||
- [Earth Frontend Context](/home/ray/dev/linkong/planet/docs/technical/en/earth-frontend-context.md)
|
||||
- [Frontend Layout Guidelines](/home/ray/dev/linkong/planet/docs/technical/en/frontend-layout-guidelines.md)
|
||||
|
||||
## Toolbar Button Directory
|
||||
|
||||
The toolbar is marked by `.earth-toolbar-btn` in [index.html](/home/ray/dev/linkong/planet/frontend/public/earth/index.html):
|
||||
|
||||
| ID | Title | Type | Overlay / action |
|
||||
|----|-------|------|------------------|
|
||||
| `layer-action` | Layers | Overlay toggle | HUD panel `layer-toggles` on desktop / mobile drawer `layers` card |
|
||||
| `search-action` | Search | Overlay toggle | Search panel on desktop / mobile drawer `search` card |
|
||||
| `rotate-toggle` | Auto rotate | Standalone toggle | No overlay |
|
||||
| `toggle-tv` | News live | Overlay toggle | Media panel `media-panel` with TV and News tabs |
|
||||
| `reload-data` | Reload data | Standalone action | No overlay |
|
||||
| `zoom-trigger` | Zoom control | Floating menu | Zoom floating menu |
|
||||
| `settings-trigger` | Settings | Overlay toggle | Settings modal on desktop / mobile drawer `settings` card |
|
||||
| `reset-view` | Reset view | Standalone action | No overlay |
|
||||
| `layout-toggle` | Maximize layout | Standalone toggle | No overlay |
|
||||
|
||||
## Shared Coordination Entry Point
|
||||
|
||||
[controls.js::closeTransientMobileOverlays](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js) is the shared coordinator for deciding what should close when an overlay opens.
|
||||
|
||||
Every path that opens a fullscreen-style overlay calls `closeTransientMobileOverlays({ except })`, where `except` names the overlay that should stay open:
|
||||
|
||||
```js
|
||||
closeTransientMobileOverlays({ except: "search" });
|
||||
closeTransientMobileOverlays({ except: "settings" });
|
||||
closeTransientMobileOverlays({ except: "media" });
|
||||
closeTransientMobileOverlays({ except: "layer-toggles" });
|
||||
```
|
||||
|
||||
Current `except` values are `"search"`, `"settings"`, `"media"`, `"layer-toggles"`, or omitted to close all transient overlays.
|
||||
|
||||
## Close Matrix
|
||||
|
||||
`close` means the overlay closes; `keep` means it remains open.
|
||||
|
||||
| Action | Search | Settings | Mobile layers drawer | News/live |
|
||||
|--------|:------:|:--------:|:--------------------:|:---------:|
|
||||
| Open search (`except: "search"`) | self | close | close | keep |
|
||||
| Open settings (`except: "settings"`) | close | self | close | keep |
|
||||
| Open news/live (`except: "media"`) | close | close | close | self |
|
||||
| Open mobile layers (`except: "layer-toggles"`) | close | close | self | close |
|
||||
| Close all (`except: null`) | close | close | close | close |
|
||||
|
||||
Examples:
|
||||
|
||||
- Clicking toolbar Settings closes search and the mobile layer drawer, but keeps news/live open.
|
||||
- Clicking toolbar Layers on mobile opens the `layers` drawer and closes search, settings, and news.
|
||||
- Clicking News Live closes search, settings, and the layer drawer, then toggles the media panel.
|
||||
|
||||
## Design Rules
|
||||
|
||||
1. **Floating menus such as `zoom-trigger` are not overlays.** They use `bindFloatingMenu` and are managed separately by `closeFloatingMenus()`. Opening any overlay first closes floating menus.
|
||||
2. **Desktop `layer-toggles` is a persistent HUD panel.** `closeTransientMobileOverlays` only closes it when `activeMobileDrawerId === "layer-toggles"`, so desktop search, settings, and news do not disturb the layer panel.
|
||||
3. **News/live is independent from settings.** Users often adjust collector settings while watching news, so opening settings does not close the media panel. This became an invariant after the May 2026 coordination patch.
|
||||
4. **Search and news are both primary information overlays.** Search opens without closing news, and news opens without closing search. If product direction changes, update both sides in `closeTransientMobileOverlays` so the matrix stays symmetric.
|
||||
5. **Mobile drawers are fullscreen-focus states.** Any mobile drawer, whether layers, search, or settings, uses `setMobileDrawerState` and closes other overlays.
|
||||
6. **Escape has a fixed close order.** See [controls.js::setupKeyboardControls](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js): search, settings, mobile drawer, floating menu, toolbar hub, locked object.
|
||||
|
||||
## Adding A Button Or Overlay
|
||||
|
||||
1. Add the button in the `.earth-toolbar` container in [index.html](/home/ray/dev/linkong/planet/frontend/public/earth/index.html), using the existing `floating-btn liquid-glass-surface earth-toolbar-btn` class pattern.
|
||||
2. Decide whether it is a standalone action, a floating menu, or a mutually coordinated overlay.
|
||||
3. For a coordinated overlay, call `closeTransientMobileOverlays({ except: "<your-key>" })` when opening it.
|
||||
4. Add the reciprocal close branch inside `closeTransientMobileOverlays`, so other overlays can close yours.
|
||||
5. If the new overlay should coexist with an existing overlay, exclude that peer on both sides of the matrix.
|
||||
6. Add an Escape close path in `setupKeyboardControls`.
|
||||
7. On mobile, use `setMobileDrawerState({ open: true, card: "<your-card>" })` for drawer-style panels.
|
||||
|
||||
## Current Implementation Locations
|
||||
|
||||
- Coordinator: [controls.js::closeTransientMobileOverlays](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js)
|
||||
- Settings overlay: [controls.js::openSettingsModal / closeSettingsModal](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js)
|
||||
- Search overlay: [controls.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js), imported from the search module
|
||||
- News/live overlay: [tv.js::setTVPanelVisible](/home/ray/dev/linkong/planet/frontend/public/earth/js/tv.js), with the News tab in [news.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/news.js)
|
||||
- Mobile layer drawer: [controls.js::setMobileDrawerState](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js)
|
||||
- Floating menu: [controls.js::bindFloatingMenu](/home/ray/dev/linkong/planet/frontend/public/earth/js/controls.js)
|
||||
- Toolbar DOM: [index.html](/home/ray/dev/linkong/planet/frontend/public/earth/index.html)
|
||||
@@ -155,6 +155,7 @@ Purpose:
|
||||
- Renders Markdown content for `/docs`
|
||||
- Supports headings, lists, blockquotes, code blocks, tables, and basic inline formatting
|
||||
- Code blocks and tables reuse `Scrollbar` so horizontal content does not blow out the docs page
|
||||
- Docs content is returned by backend `/api/v1/docs/...` endpoints according to Gatekeeper permissions; the frontend only renders content visible to the current user
|
||||
|
||||
Current constraints:
|
||||
|
||||
@@ -190,9 +191,10 @@ Responsibilities:
|
||||
|
||||
- Token
|
||||
- Current user
|
||||
- Gatekeeper groups
|
||||
- Login / logout
|
||||
|
||||
`App.tsx` uses it to decide whether to redirect to the login page.
|
||||
`App.tsx` uses it to decide whether to redirect to the login page. `/docs` remains a public route, but the backend decides the visible catalog and content from the token; anonymous visitors only receive public docs.
|
||||
|
||||
### 2. Business Data Gateway
|
||||
|
||||
|
||||
200
docs/technical/en/location-pipeline-development.md
Normal file
200
docs/technical/en/location-pipeline-development.md
Normal file
@@ -0,0 +1,200 @@
|
||||
# Shared Location Resolution Pipeline Development Guide
|
||||
|
||||
`backend/app/services/location/` is the shared abstraction for any "given a record, decide its lat/lon" workflow. Compute centers, BGP collectors, and BGP events now run on this pipeline. Future entities such as satellite ground stations, user-claimed points, and IXP facilities should plug in here instead of creating another geocoding path.
|
||||
|
||||
For the user workflow, see [Earth Location Candidate Collection User Guide](/home/ray/dev/linkong/planet/docs/technical/en/location-pipeline-user.md).
|
||||
|
||||
## Design Goals
|
||||
|
||||
Historically compute centers had their own four-tier chain, BGP collectors used a hard-coded dictionary, and BGP events inherited collector coordinates. These implementations did not share code, and new algorithms had no stable insertion point.
|
||||
|
||||
The refactored rules:
|
||||
|
||||
- Share the `LocationResolver` protocol and `LocationPipeline` orchestrator.
|
||||
- Domain modules only build `LocationQuery` and choose resolver order.
|
||||
- New algorithms join by adding resolver classes, without changing ingestion, API, or frontend envelopes.
|
||||
- Earth renders only city-level or better locations.
|
||||
- Local JSON registries are not runtime candidate sources for compute centers or BGP collectors; persisted location facts live in database dimension tables.
|
||||
|
||||
## Core Interfaces
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class LocationQuery:
|
||||
name: str | None
|
||||
aliases: tuple[str, ...]
|
||||
city: str | None
|
||||
country: str | None
|
||||
region: str | None
|
||||
source_latitude: float | None
|
||||
source_longitude: float | None
|
||||
extra: Mapping[str, Any]
|
||||
```
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class LocationCandidate:
|
||||
latitude: float
|
||||
longitude: float
|
||||
display_name: str
|
||||
precision: str
|
||||
confidence: float
|
||||
source: str
|
||||
needs_confirmation: bool
|
||||
matched_fields: tuple[str, ...]
|
||||
suggested_registry_entry: dict | None
|
||||
```
|
||||
|
||||
```python
|
||||
class LocationResolver(Protocol):
|
||||
name: str
|
||||
def resolve(self, query: LocationQuery) -> ResolverOutput: ...
|
||||
```
|
||||
|
||||
`LocationPipeline.collect_candidates()` returns sorted candidates plus `attempted_queries`; `resolve_best()` returns the best candidate with diagnostics. The default sort key ranks source, precision, and confidence, then deduplicates candidates with the same source and rounded coordinates.
|
||||
|
||||
## Built-In Resolvers
|
||||
|
||||
| Resolver | File | Responsibility |
|
||||
| --- | --- | --- |
|
||||
| `SourceCoordinatesResolver` | `resolvers/source_coordinates.py` | Emits `precision="precise"` when the record already has lat/lon |
|
||||
| `RegistryResolver` | `resolvers/registry.py` | Legacy generic resolver; current compute-center and BGP runtime paths do not use it to generate candidates |
|
||||
| `NominatimResolver` | `resolvers/nominatim.py` | Runs a domain query plan against Nominatim with LRU cache and rate limiting |
|
||||
| `InheritFromAnotherEntityResolver` | `resolvers/inherit.py` | Wraps an externally resolved entity location as a candidate |
|
||||
|
||||
`RegistryResolver` remains available for future controlled import scenarios, but it should not be reconnected as a hard-coded hint source for compute centers or BGP. Matching common fields such as `operator` or `city` was the main reason multiple entities could collapse onto the same point.
|
||||
|
||||
## Current Domain Pipelines
|
||||
|
||||
### Compute Centers
|
||||
|
||||
Entry points:
|
||||
|
||||
- [compute_center_locations.py](/home/ray/dev/linkong/planet/backend/app/services/compute_center_locations.py)
|
||||
|
||||
Resolver order:
|
||||
|
||||
```python
|
||||
SourceCoordinatesResolver()
|
||||
StoredComputeCenterLocationResolver()
|
||||
```
|
||||
|
||||
The main map startup path is source coordinates first, then the database-backed current-location table. The table is `compute_center_locations`, keyed by `(source, source_id)`, and stores manually accepted locations or true coordinates migrated from source records. `init_db()` only migrates source records that already contain real coordinates; it does not import old hard-coded hints and does not run ROR, Nominatim, or LLM geocoding during startup.
|
||||
|
||||
Candidate collection is intentionally separate from rendering. `collect_location_candidates()` builds ROR and Nominatim/OpenStreetMap queries from source fields, but it does not emit the current `compute_center_locations` row as a candidate. After a user accepts a candidate, the save endpoint upserts it into the dimension table; the next map refresh renders it through `StoredComputeCenterLocationResolver`.
|
||||
|
||||
`resolve_compute_center_location()`, `resolve_compute_center_location_full()`, and `collect_location_candidates()` remain the domain API. `visualization.py` consumes that API and no longer owns coordinate hints, country-centroid fallbacks, or Nominatim details.
|
||||
|
||||
GeoJSON output includes only `RENDERABLE_PRECISIONS`. Unresolved records are returned in `unresolved` with `failure_reason`, `attempted_queries`, `source_id`, `record_id`, and related diagnostics.
|
||||
|
||||
### BGP Collectors
|
||||
|
||||
Entry points:
|
||||
|
||||
- [bgp_collector_locations.py](/home/ray/dev/linkong/planet/backend/app/services/bgp_collector_locations.py)
|
||||
- [bgp_collector_location.py](/home/ray/dev/linkong/planet/backend/app/models/bgp_collector_location.py)
|
||||
|
||||
Resolver order:
|
||||
|
||||
```python
|
||||
SourceCoordinatesResolver()
|
||||
StoredCollectorLocationResolver()
|
||||
NominatimResolver(_bgp_collector_query_plan)
|
||||
```
|
||||
|
||||
The 23 RIPE RIS collector coordinates moved from the old table into the `bgp_collector_locations` dimension table with `source=legacy_seed` and `needs_confirmation=true`. The legacy dictionary is still maintained from the DB-backed cache for compatibility; manual candidate collection uses stored site/city/country as context but does not emit stored rows as candidates.
|
||||
|
||||
### BGP Events
|
||||
|
||||
Entry point:
|
||||
|
||||
- [bgp_event_locations.py](/home/ray/dev/linkong/planet/backend/app/services/bgp_event_locations.py)
|
||||
|
||||
Resolver order:
|
||||
|
||||
```python
|
||||
SourceCoordinatesResolver()
|
||||
InheritFromAnotherEntityResolver(_inherit_from_owning_collector)
|
||||
```
|
||||
|
||||
Event inheritance uses a strict owning-collector lookup and does not run the full fuzzy collector registry. Future ASN facility, PrefixGeo, or PeeringDB resolvers can be inserted after inheritance.
|
||||
|
||||
## API Envelope
|
||||
|
||||
```http
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/collect-location
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/location
|
||||
POST /api/v1/bgp/collectors/{collector_id}/collect-location
|
||||
```
|
||||
|
||||
Both `collect-location` endpoints return the same envelope:
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"candidates": [],
|
||||
"best_candidate": {},
|
||||
"attempted_queries": [],
|
||||
"context": {}
|
||||
}
|
||||
```
|
||||
|
||||
`POST /api/v1/visualization/compute-centers/{source_id}/location` upserts the candidate selected by the frontend into `compute_center_locations`. Manual saves default to `needs_confirmation=false`, `verification_status="verified"`, and a `verified_at` timestamp. Future automated staging can pass `needs_confirmation=true` explicitly.
|
||||
|
||||
The frontend [info-card.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/info-card.js) renders the shared candidate list and preview events. The compute-center layer button shows an `unresolved` badge; clicking it opens the unresolved queue. Row-level `采集` only fetches candidates. Header-level `一键采用` walks the queue top-to-bottom, picks the highest-confidence candidate with valid coordinates, saves it, removes the row, renumbers the list, and dispatches `earth:compute-center-unresolved-count-change` so the badge updates immediately. When the batch finishes, `earth:compute-center-location-saved` refreshes the real layer.
|
||||
|
||||
If the remaining records have no city-level candidates, the batch must not invent coordinates. The UI keeps those rows and shows the backend `failure_reason` plus attempted queries.
|
||||
|
||||
## Adding A Resolver
|
||||
|
||||
A resolver only needs `name` and `resolve()`, returning `ResolverOutput`.
|
||||
|
||||
```python
|
||||
class PeeringDBFacilityResolver:
|
||||
name = "peeringdb_facility"
|
||||
|
||||
def __init__(self, client):
|
||||
self._client = client
|
||||
|
||||
def resolve(self, query):
|
||||
asn = query.extra.get("origin_asn")
|
||||
if not asn:
|
||||
return ResolverOutput()
|
||||
return ResolverOutput(candidates=tuple(
|
||||
LocationCandidate(
|
||||
latitude=f.latitude,
|
||||
longitude=f.longitude,
|
||||
display_name=f.name,
|
||||
precision="site",
|
||||
confidence=0.78,
|
||||
query=f"peeringdb::{asn}",
|
||||
source=self.name,
|
||||
source_note=f"PeeringDB facility for AS{asn}",
|
||||
matched_fields=("origin_asn",),
|
||||
needs_confirmation=False,
|
||||
city=f.city,
|
||||
country=f.country,
|
||||
)
|
||||
for f in self._client.facilities_for_asn(asn)
|
||||
))
|
||||
```
|
||||
|
||||
Wire it in:
|
||||
|
||||
```python
|
||||
BGP_EVENT_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
InheritFromAnotherEntityResolver(source_lookup=...),
|
||||
PeeringDBFacilityResolver(client=peeringdb_client),
|
||||
])
|
||||
```
|
||||
|
||||
## Test Coverage
|
||||
|
||||
Relevant tests:
|
||||
|
||||
- [test_location_pipeline.py](/home/ray/dev/linkong/planet/backend/tests/test_location_pipeline.py)
|
||||
- [test_bgp_collector_locations.py](/home/ray/dev/linkong/planet/backend/tests/test_bgp_collector_locations.py)
|
||||
- [test_visualization_compute_centers.py](/home/ray/dev/linkong/planet/backend/tests/test_visualization_compute_centers.py)
|
||||
|
||||
Coverage focuses on resolver pluggability, registry alias guards, BGP collector legacy dictionary compatibility, compute-center public API compatibility, and non-renderable locations being returned as `unresolved`.
|
||||
127
docs/technical/en/location-pipeline-user.md
Normal file
127
docs/technical/en/location-pipeline-user.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# Earth Location Candidate Collection User Guide
|
||||
|
||||
Location candidate collection helps fill or verify coordinates for compute centers and BGP collectors on Earth. Users do not type coordinates by hand; the backend ranks source coordinates, open organization-registry results, and online geocoding results into a previewable candidate list.
|
||||
|
||||
## Supported Entities
|
||||
|
||||
Currently supported:
|
||||
|
||||
- Compute centers: TOP500 supercomputers and Epoch AI GPU clusters.
|
||||
- BGP collectors: RIPE RIS `rrcXX` collectors.
|
||||
|
||||
BGP events inherit the location of their owning collector. Events do not have a separate collection button yet; future ASN facility, prefix geography, or PeeringDB resolvers should use the same pipeline.
|
||||
|
||||
## What Users See
|
||||
|
||||
Clicking a compute center or BGP collector on Earth opens a detail card with location fields:
|
||||
|
||||
| Field | Meaning |
|
||||
| --- | --- |
|
||||
| Location precision | Precise coordinates, site-level, city-level, or unconfirmed |
|
||||
| Location source | Source coordinates, ROR organization registry, Nominatim online search, or stored BGP collector locations |
|
||||
| Location confidence | Relative confidence reported by the backend resolver |
|
||||
| Verification status | Confirmed, estimated, or online result pending confirmation |
|
||||
| Resolution reason | Why the location was selected |
|
||||
| Matched location name | Canonical name from an open source, online result, or stored collector location |
|
||||
| Verified at | Verification date for confirmed locations; online candidates are usually empty |
|
||||
|
||||
Compute-center GeoJSON no longer renders country centroids, unknown locations, or `[0, 0]` placeholders. Records that cannot reach city-level precision are returned in the endpoint's `unresolved` list and can be improved through candidate collection.
|
||||
|
||||
A compute center with a `?` marker on Earth is not unresolved. It already has coordinates, but the coordinates still need confirmation, either because `needs_confirmation=true` or because the source is online geocoding. Truly unresolved records have no trustworthy coordinates and are therefore absent from the globe.
|
||||
|
||||
## Collect Candidates
|
||||
|
||||
1. Open `http://localhost:3000/earth`.
|
||||
2. Enable the `Compute centers` or `BGP observation` layer.
|
||||
3. Click an object to open its detail card.
|
||||
4. Click `自动采集坐标候选` or `重新自动采集坐标`.
|
||||
5. Wait for up to five candidates to appear.
|
||||
6. Click `预览` on a candidate row; Earth flies to that latitude and longitude.
|
||||
|
||||
Candidate rows show:
|
||||
|
||||
- Candidate name.
|
||||
- Precision: precise, site, or city.
|
||||
- Resolver source.
|
||||
- Confidence.
|
||||
- Coordinates.
|
||||
|
||||
Clicking `保存` on a candidate row writes the selected compute-center candidate into the location dimension table. After the save succeeds, the compute-center layer refreshes; if the record was previously in the unresolved queue, the unresolved count decreases.
|
||||
|
||||
## Unresolved Queue And Adopt All
|
||||
|
||||
The notification badge on the compute-center layer row shows the current unresolved count. Clicking it opens a fixed queue beside the layer panel:
|
||||
|
||||
1. The queue contains only compute centers without trustworthy coordinates.
|
||||
2. Row-level `采集` calls the candidate endpoint and shows up to five previewable candidates.
|
||||
3. Header-level `一键采用` walks the list from top to bottom, chooses the highest-confidence candidate with valid coordinates, and saves it.
|
||||
4. Each successful save immediately removes that row, renumbers the remaining rows, and updates the badge count.
|
||||
5. When the batch completes, the frontend refreshes the compute-center layer so UI state and backend state converge.
|
||||
|
||||
If a record has no saveable candidate, the system does not invent a country centroid, vendor headquarters, or hard-coded hint. The row stays in the queue with the backend failure reason and attempted queries so an operator can supply better evidence later.
|
||||
|
||||
## Backend APIs
|
||||
|
||||
The frontend buttons call:
|
||||
|
||||
```http
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/collect-location
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/location
|
||||
POST /api/v1/bgp/collectors/{collector_id}/collect-location
|
||||
```
|
||||
|
||||
Both `collect-location` endpoints use the same response shape:
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"candidates": [],
|
||||
"best_candidate": {},
|
||||
"attempted_queries": [],
|
||||
"context": {}
|
||||
}
|
||||
```
|
||||
|
||||
When no candidate reaches city-level precision, `success` is `false` and the response includes `failure_reason` plus the attempted queries. This helps distinguish missing source fields, open-source gaps, and online geocoding misses.
|
||||
|
||||
## Registry Maintenance
|
||||
|
||||
Compute centers and BGP collectors no longer maintain local candidate registries. Compute-center accepted locations are stored in the `compute_center_locations` database dimension table keyed by `(source, source_id)`. BGP collector current locations are stored in the `bgp_collector_locations` database dimension table; the old RIPE RIS city-level coordinates are used only as initialization seed data and still require confirmation.
|
||||
|
||||
For compute centers, prefer maintaining:
|
||||
|
||||
- `source` / `source_id`: for example `top500` + `top500_50`.
|
||||
- `name` / `operator` / `site`.
|
||||
- `city` / `country`.
|
||||
- `latitude` / `longitude`.
|
||||
- `precision`: `precise`, `site`, or `city`.
|
||||
- `confidence`: confidence from 0 to 1.
|
||||
- `location_source` / `source_url` / `source_note` / `raw_payload`: evidence source.
|
||||
- `needs_confirmation` / `verification_status` / `verified_at`: manual verification status and date.
|
||||
|
||||
For BGP collectors, prefer maintaining:
|
||||
|
||||
- `collector_id`: for example `rrc12`.
|
||||
- `site` / `operator`: site and operator.
|
||||
- `city` / `country` / `region`.
|
||||
- `latitude` / `longitude`.
|
||||
- `precision`: `precise`, `site`, or `city`.
|
||||
- `confidence`: confidence from 0 to 1.
|
||||
- `source` / `source_url` / `raw_payload`: evidence source.
|
||||
- `verification_status` / `verified_at`: manual verification status and date.
|
||||
|
||||
If only the city is known, use city-level precision. Do not enter a precise-looking coordinate that has not been verified.
|
||||
|
||||
## Common Questions
|
||||
|
||||
### Why are some compute centers missing on Earth?
|
||||
|
||||
Earth only renders coordinates that reach city-level precision or better. If source data, verified storage, and online geocoding all fail, the record is returned as `unresolved` instead of being rendered at a misleading country center or `[0, 0]`.
|
||||
|
||||
### Why do online results need confirmation?
|
||||
|
||||
Nominatim/OpenStreetMap results may match same-name cities, organizations, or campuses. They are useful for previewing candidates, but should be manually confirmed before being persisted as verified locations.
|
||||
|
||||
### Why do BGP events no longer all land in Amsterdam?
|
||||
|
||||
The old behavior could match common fields like `operator="RIPE NCC"` and incorrectly promote `rrc00`. BGP event inheritance now uses a strict owning-collector lookup in the DB-backed cache instead of registry fuzzy matching.
|
||||
@@ -5,7 +5,7 @@ This manual is for daily use, demos, development integration, and local operatio
|
||||
- `planet.sh`: local start, stop, restart, health check, and log access
|
||||
- Earth: public 3D situational awareness page
|
||||
- Console: admin backend (login required)
|
||||
- Docs: public developer documentation and manual
|
||||
- Docs: backend Gatekeeper-controlled documentation; basic usage docs are public, while developer and operations docs require permission groups
|
||||
|
||||
For the shortest path to getting started, see [Quickstart](/home/ray/dev/linkong/planet/docs/technical/en/quickstart.md).
|
||||
|
||||
@@ -16,7 +16,7 @@ After a default startup, the common URLs are:
|
||||
| Name | URL | Login Required | Description |
|
||||
| --- | --- | --- | --- |
|
||||
| Earth | `http://localhost:3000/earth` | No | 3D globe, layers, BGP, satellites, cables, news situational awareness |
|
||||
| Docs | `http://localhost:3000/docs` | No | Developer docs, technical reference, usage manual |
|
||||
| Docs | `http://localhost:3000/docs` | Partly | Usage docs are public; developer, backend, and operations docs require Gatekeeper groups |
|
||||
| Console | `http://localhost:3000/admin` | Yes | Data, config, alerts, logs, and situational observation |
|
||||
| AI Playground | `http://localhost:3000/playground` | Yes | AI Provider status and debugging |
|
||||
| Backend API Docs | `http://localhost:8000/docs` | Depends on endpoint | FastAPI / OpenAPI documentation |
|
||||
@@ -176,7 +176,26 @@ Useful for:
|
||||
- Demos on phone or tablet
|
||||
- Another machine on the same LAN accessing the same dev instance
|
||||
|
||||
After starting, check your firewall and WSL network forwarding if access fails.
|
||||
`--allow-lan` only makes the frontend and backend listen on `0.0.0.0`. When Planet runs in WSL, Windows can usually reach it through `localhost`, but access from a phone or another computer through `http://<Windows LAN IP>:3000` still depends on Windows port forwarding and firewall rules.
|
||||
|
||||
Use this order to diagnose:
|
||||
|
||||
```bash
|
||||
# From WSL or the shell running Planet
|
||||
curl http://localhost:3000
|
||||
curl http://localhost:8000/health
|
||||
ss -ltnp | grep -E ':3000|:8000'
|
||||
```
|
||||
|
||||
If this shows `0.0.0.0:3000` and `0.0.0.0:8000`, but the LAN IP still fails, configure Windows from an elevated PowerShell:
|
||||
|
||||
```powershell
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=3000 connectaddress=127.0.0.1 connectport=3000
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8000 connectaddress=127.0.0.1 connectport=8000
|
||||
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 3000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 8000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8000
|
||||
```
|
||||
|
||||
## Earth
|
||||
|
||||
@@ -259,6 +278,12 @@ Earth search finds current globe objects, such as:
|
||||
|
||||
Search results can be used to quickly locate objects and open their details.
|
||||
|
||||
### Location Candidate Collection
|
||||
|
||||
Compute-center and BGP collector detail cards can collect candidate coordinates automatically. After clicking an object, use `自动采集坐标候选` or `重新自动采集坐标`; the backend ranks source coordinates, open organization lookups, and Nominatim online search results. Stored BGP collector locations are used as query context only and are not emitted as candidates.
|
||||
|
||||
Candidates can be previewed directly on Earth. Compute-center candidates can be saved into the `compute_center_locations` dimension table from the detail card, then the layer refreshes immediately. The notification badge on the compute-center layer row shows unresolved records that cannot be rendered; clicking it opens the queue, where users can collect individual candidates or use `一键采用` to save the highest-confidence candidate top-to-bottom. Records without candidates stay in the queue and are not replaced by country centroids or hard-coded hints. See [Earth Location Candidate Collection User Guide](/home/ray/dev/linkong/planet/docs/technical/en/location-pipeline-user.md) for the full workflow.
|
||||
|
||||
### Settings
|
||||
|
||||
The settings panel contains:
|
||||
@@ -492,33 +517,41 @@ Then open `/logs` for more structured runtime information.
|
||||
|
||||
## Docs
|
||||
|
||||
Public documentation site:
|
||||
Documentation site:
|
||||
|
||||
```text
|
||||
http://localhost:3000/docs
|
||||
```
|
||||
|
||||
Current public content comes from:
|
||||
Docs content is read through backend APIs by permission. The frontend no longer bundles all Markdown files directly. Source files still live in:
|
||||
|
||||
```text
|
||||
docs/technical/zh/ (Chinese)
|
||||
docs/technical/en/ (English)
|
||||
```
|
||||
|
||||
Anonymous visitors only see `public` docs such as the overview, quickstart, and manual. Logged-in users can see more technical docs when assigned Gatekeeper groups:
|
||||
|
||||
- `docs_user`: user-operation docs.
|
||||
- `docs_developer`: Earth, frontend, backend, collector, and AI Provider development docs.
|
||||
- `docs_admin`: service control, operations, environment variable, and sensitive-operation docs.
|
||||
|
||||
`admin` receives admin-doc access by default, and `super_admin` can read all Docs content. Gatekeeper groups are configured in the console Users page.
|
||||
|
||||
Docs supports:
|
||||
|
||||
- Category navigation
|
||||
- Markdown rendering
|
||||
- Tables and code blocks
|
||||
- In-document table of contents
|
||||
- Local search
|
||||
- Search across currently visible docs
|
||||
- Internal links between technical documents
|
||||
|
||||
When adding a new technical document, check:
|
||||
|
||||
- Does it have a clear top-level heading
|
||||
- Does it need to be added to the `/docs` manual category and ordering
|
||||
- Does it contain information that should not be publicly displayed
|
||||
- Does it need to be added to backend Docs metadata for category and ordering
|
||||
- Should it be classified as `public`, `docs_user`, `docs_developer`, or `docs_admin`
|
||||
|
||||
## Development Command Conventions
|
||||
|
||||
@@ -589,5 +622,6 @@ When something goes wrong, follow this sequence:
|
||||
- [Admin Frontend Context](/home/ray/dev/linkong/planet/docs/technical/en/frontend-admin-frontend-context.md)
|
||||
- [Earth Frontend Context](/home/ray/dev/linkong/planet/docs/technical/en/earth-frontend-context.md)
|
||||
- [Earth Layer Style Reference](/home/ray/dev/linkong/planet/docs/technical/en/earth-layer-style-reference.md)
|
||||
- [Earth Location Candidate Collection User Guide](/home/ray/dev/linkong/planet/docs/technical/en/location-pipeline-user.md)
|
||||
- [System Service Control](/home/ray/dev/linkong/planet/docs/technical/en/backend-system-service-control.md)
|
||||
- [Backend Collectors](/home/ray/dev/linkong/planet/docs/technical/en/backend-collectors.md)
|
||||
|
||||
205
docs/technical/en/ops-planet-sh-startup.md
Normal file
205
docs/technical/en/ops-planet-sh-startup.md
Normal file
@@ -0,0 +1,205 @@
|
||||
# `planet.sh` Startup Performance Optimization
|
||||
|
||||
## Background
|
||||
|
||||
`planet.sh` manages start, stop, restart, health checks, and logs for all local services. The previous implementation had several startup issues:
|
||||
|
||||
1. AI Provider rebuilt every time, even when code had not changed.
|
||||
2. Port cleanup could wait up to 45 seconds.
|
||||
3. Port bind detection used a Python subprocess, adding about 300 ms per call.
|
||||
4. Plain `restart` and `restart -b` behaved differently.
|
||||
|
||||
## Issue 1: AI Provider Rebuilt Every Time
|
||||
|
||||
### Root Cause
|
||||
|
||||
The build stamp file lived under `/tmp/`. After WSL or Linux restart, `/tmp` is cleared, so the `stamp_non_empty` condition failed and the script decided to rebuild:
|
||||
|
||||
```bash
|
||||
# All three conditions had to be true to skip rebuild
|
||||
image_exists AND stamp_non_empty AND fingerprint_match
|
||||
```
|
||||
|
||||
### Fix
|
||||
|
||||
The stamp file moved to a persistent cache path:
|
||||
|
||||
```bash
|
||||
AI_PROVIDER_BUILD_STAMP_FILE="$HOME/.cache/planet/aiprovider_build.sha256"
|
||||
```
|
||||
|
||||
Writing the stamp creates the directory first:
|
||||
|
||||
```bash
|
||||
write_ai_provider_build_stamp() {
|
||||
mkdir -p "$(dirname "$AI_PROVIDER_BUILD_STAMP_FILE")"
|
||||
compute_ai_provider_build_fingerprint > "$AI_PROVIDER_BUILD_STAMP_FILE"
|
||||
}
|
||||
```
|
||||
|
||||
### Faster Fingerprint
|
||||
|
||||
The previous implementation tarred the whole `aiprovider/` directory before hashing, which could take seconds in large trees. The new version uses `find + stat` and reads only file metadata:
|
||||
|
||||
```bash
|
||||
compute_ai_provider_build_fingerprint() {
|
||||
find aiprovider \
|
||||
-type f \
|
||||
! -path '*/__pycache__/*' \
|
||||
! -name '.env' \
|
||||
! -name '.env.*' \
|
||||
! -name '*.pyc' \
|
||||
! -name '*.pyo' \
|
||||
| LC_ALL=C sort \
|
||||
| xargs -r stat --format="%Y %s %n" 2>/dev/null
|
||||
sha256sum docker-compose.yml docker-compose.simple.yml 2>/dev/null
|
||||
python3 "$SCRIPT_DIR/scripts/compute_aiprovider_dependency_fingerprint.py" 2>/dev/null
|
||||
}
|
||||
```
|
||||
|
||||
This is roughly 10 times faster for many-small-file workloads while preserving the same practical rebuild signal. `.env` and `.env.*` are excluded because runtime model, key, and Base URL changes should not force an image rebuild.
|
||||
|
||||
### Docker Build Context
|
||||
|
||||
AI Provider only needs root `pyproject.toml`, `uv.lock`, and `aiprovider/` source code. Sending the entire repository as Docker build context wastes time on frontend assets, PDFs, historical data, and Unreal files.
|
||||
|
||||
The root `.dockerignore` now narrows the context:
|
||||
|
||||
```dockerignore
|
||||
**
|
||||
|
||||
!pyproject.toml
|
||||
!uv.lock
|
||||
!aiprovider/
|
||||
!aiprovider/**
|
||||
|
||||
aiprovider/.env
|
||||
aiprovider/.env.*
|
||||
!aiprovider/.env.example
|
||||
```
|
||||
|
||||
The Dockerfile copies only AI Provider inputs:
|
||||
|
||||
```dockerfile
|
||||
COPY pyproject.toml uv.lock /app/
|
||||
RUN --mount=type=cache,target=/root/.cache/uv \
|
||||
uv sync --frozen --no-dev
|
||||
|
||||
COPY aiprovider /app/aiprovider
|
||||
```
|
||||
|
||||
`uv sync` uses a BuildKit cache mount. The first build may still depend on network speed, but later builds reuse `/root/.cache/uv`.
|
||||
|
||||
### Runtime Configuration
|
||||
|
||||
Before starting AI Provider, `planet.sh` generates a temporary env-file and passes it to Compose or the manual `docker run` fallback. Configuration priority:
|
||||
|
||||
1. `aiprovider/.env`
|
||||
2. simple `export AI_...=...` or `AI_...=...` lines from `~/.zshrc`
|
||||
|
||||
The default parser is static and only covers AI Provider, image, and proxy variables. It avoids executing interactive shell initialization. Complex shell expansion can be enabled explicitly:
|
||||
|
||||
```bash
|
||||
PLANET_LOAD_ZSHRC_ENV=source ./planet.sh start -a
|
||||
```
|
||||
|
||||
To ignore personal shell config during debugging:
|
||||
|
||||
```bash
|
||||
PLANET_LOAD_ZSHRC_ENV=0 ./planet.sh start -a
|
||||
```
|
||||
|
||||
### Skip-Rebuild Behavior
|
||||
|
||||
When the fingerprint matches, the script skips `docker compose build` and starts the existing container:
|
||||
|
||||
```bash
|
||||
docker start planet_aiprovider
|
||||
```
|
||||
|
||||
`docker stop` stops the container without deleting the image. `cleanup_exit_containers` removes exited containers but not images, so the next `docker start` can reuse the existing image.
|
||||
|
||||
## Issue 2: Slow Port Cleanup
|
||||
|
||||
### Cause
|
||||
|
||||
`wait_for_port_release` could wait up to 45 seconds by default: 15 attempts times 3 seconds.
|
||||
|
||||
### Fix
|
||||
|
||||
Background process cleanup now uses a 3-second timeout: TERM, 1.5 seconds, KILL, 1.5 seconds.
|
||||
|
||||
```bash
|
||||
PORT_RELEASE_ATTEMPTS=15
|
||||
PORT_RELEASE_INTERVAL=0.2
|
||||
|
||||
wait_for_port_release "$port" 15 0.2
|
||||
```
|
||||
|
||||
`wait_for_port_release` accepts optional parameters so different situations can choose different timeouts.
|
||||
|
||||
## Issue 3: Port Detection Used Python
|
||||
|
||||
### Cause
|
||||
|
||||
`can_bind_port` used `python3 -c "import socket..."`; each call cost about 300 ms.
|
||||
|
||||
### Fix
|
||||
|
||||
Prefer system tools and keep Python as a fallback:
|
||||
|
||||
```bash
|
||||
can_bind_port() {
|
||||
local port="$1"
|
||||
if command -v ss >/dev/null 2>&1; then
|
||||
! ss -tlnH 2>/dev/null | awk '{print $4}' | grep -qE ":${port}$"
|
||||
return
|
||||
fi
|
||||
if command -v lsof >/dev/null 2>&1; then
|
||||
[ -z "$(lsof -tiTCP:"${port}" -sTCP:LISTEN 2>/dev/null)" ]
|
||||
return
|
||||
fi
|
||||
python3 - "$port" <<'PY'
|
||||
import sys, socket
|
||||
p = int(sys.argv[1])
|
||||
s = socket.socket()
|
||||
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
|
||||
try:
|
||||
s.bind(("", p)); s.close(); sys.exit(0)
|
||||
except OSError:
|
||||
sys.exit(1)
|
||||
PY
|
||||
}
|
||||
```
|
||||
|
||||
Frontend startup now has an additional pre-start cleanup retry layer:
|
||||
|
||||
- `PORT_PRESTART_RETRIES`: defaults to 3 attempts.
|
||||
- `PORT_PRESTART_RETRY_INTERVAL`: defaults to 2 seconds.
|
||||
|
||||
`kill_port_if_requested()` only kills processes when the current environment can identify listening PIDs. If no PID is visible but the port still cannot bind, it logs diagnostics and lets the service startup flow make the final decision. `start_frontend_with_retry()` only enters the pre-cleanup retry path when a listener PID is visible, so the script no longer spends its retry budget repeatedly killing nothing while a host-side or external network namespace is still releasing the port. Seeing "no listener found but port still unavailable" on the first restart usually means the external environment is still releasing the port, not that a local process cleanup loop is useful.
|
||||
|
||||
## Issue 4: `restart` Behavior
|
||||
|
||||
Before the stamp path fix:
|
||||
|
||||
- `restart -b`: stop all services, check fingerprint, rebuild only when needed, then start.
|
||||
- plain `restart`: stop all services, then often rebuild AI Provider because `/tmp` lost the stamp.
|
||||
|
||||
After moving the stamp file, plain `restart` uses the same `stop + start` behavior and the same fingerprint check as `restart -b`.
|
||||
|
||||
## Other Cleanup
|
||||
|
||||
Two redundant `sleep 3` waits were removed because health checks already cover the same readiness:
|
||||
|
||||
- `start_backend_service`: post-database-health-check sleep.
|
||||
- `restart_database_service`: post-restart sleep.
|
||||
|
||||
## Related Files
|
||||
|
||||
- [planet.sh](/home/ray/dev/linkong/planet/planet.sh)
|
||||
- [.dockerignore](/home/ray/dev/linkong/planet/.dockerignore)
|
||||
- [aiprovider/Dockerfile](/home/ray/dev/linkong/planet/aiprovider/Dockerfile)
|
||||
- [docker-compose.yml](/home/ray/dev/linkong/planet/docker-compose.yml)
|
||||
- [docker-compose.simple.yml](/home/ray/dev/linkong/planet/docker-compose.simple.yml)
|
||||
- [compute_aiprovider_dependency_fingerprint.py](/home/ray/dev/linkong/planet/scripts/compute_aiprovider_dependency_fingerprint.py)
|
||||
@@ -30,6 +30,16 @@ Personal AI Provider configuration can also live in `~/.zshrc`. `planet.sh` read
|
||||
./planet.sh restart -a
|
||||
```
|
||||
|
||||
Collector credentials such as AISStream and BarentsWatch can also start in `~/.zshrc` for connectivity validation:
|
||||
|
||||
```bash
|
||||
export AISSTREAM_API_KEY="..."
|
||||
export BARENTSWATCH_CLIENT_ID="..."
|
||||
export BARENTSWATCH_CLIENT_SECRET="..."
|
||||
```
|
||||
|
||||
For actual collection, prefer saving credentials in `Settings -> Collector Settings`, especially for AISStream's long-lived WebSocket collector. That keeps connectivity validation, backend collection tasks, and Earth realtime vessel aggregation on the same configuration source.
|
||||
|
||||
## 1. Start Services
|
||||
|
||||
From the repository root:
|
||||
@@ -44,7 +54,7 @@ After startup, the key URLs are:
|
||||
| --- | --- | --- |
|
||||
| Earth | `http://localhost:3000/earth` | Public 3D Earth visualization |
|
||||
| Console | `http://localhost:3000/admin` | Admin console (login required) |
|
||||
| Docs | `http://localhost:3000/docs` | Public developer docs and manual |
|
||||
| Docs | `http://localhost:3000/docs` | Usage docs are public; developer and operations docs require Gatekeeper groups |
|
||||
| AI Playground | `http://localhost:3000/playground` | AI debugging (login required) |
|
||||
| Backend API Docs | `http://localhost:8000/docs` | FastAPI / OpenAPI interface docs |
|
||||
|
||||
@@ -64,6 +74,8 @@ The console requires login. For first-time use:
|
||||
|
||||
Follow the prompts to enter username, password, and role.
|
||||
|
||||
To read developer or operations docs, log in as `super_admin` and assign Gatekeeper groups from the Users page. Use `docs_developer` for development docs and `docs_admin` for service-control and operations docs.
|
||||
|
||||
## 3. Open Earth
|
||||
|
||||
Visit:
|
||||
@@ -79,6 +91,7 @@ Once in, verify:
|
||||
- The globe renders correctly
|
||||
- The right-side layer panel can toggle layers on/off
|
||||
- Search can find cables, satellites, compute centers, BGP events
|
||||
- Compute-center and BGP collector detail cards can collect and preview coordinate candidates; the compute-center unresolved badge can open the queue and save candidates
|
||||
- Mouse drag, wheel zoom, and zoom percent feedback work correctly
|
||||
- Settings panel can switch cruise mode, day/night mode, satellite display style
|
||||
|
||||
@@ -176,6 +189,14 @@ To allow a Windows browser, phone, or another device on the same network:
|
||||
|
||||
This makes the frontend and backend listen on a LAN-accessible address.
|
||||
|
||||
Note: `--allow-lan` only makes Planet listen on `0.0.0.0`; it does not automatically expose WSL services through the Windows LAN IP. A common pattern is:
|
||||
|
||||
- `localhost:3000` / `localhost:8000` works inside WSL
|
||||
- `localhost:3000` / `localhost:8000` works on Windows
|
||||
- `http://<Windows LAN IP>:3000` fails from a phone or another computer
|
||||
|
||||
That usually means Windows still needs port forwarding or firewall rules.
|
||||
|
||||
If access fails, check from the shell running Planet:
|
||||
|
||||
```bash
|
||||
@@ -184,6 +205,16 @@ curl http://localhost:8000/health
|
||||
ss -ltnp | grep -E ':3000|:8000'
|
||||
```
|
||||
|
||||
If WSL is listening on `0.0.0.0:3000` and `0.0.0.0:8000` but the LAN IP still fails, configure Windows forwarding and firewall rules from an elevated PowerShell:
|
||||
|
||||
```powershell
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=3000 connectaddress=127.0.0.1 connectport=3000
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8000 connectaddress=127.0.0.1 connectport=8000
|
||||
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 3000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 8000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8000
|
||||
```
|
||||
|
||||
## 9. Stop Services
|
||||
|
||||
```bash
|
||||
|
||||
@@ -23,7 +23,10 @@
|
||||
|
||||
- [快速开始](/home/ray/dev/linkong/planet/docs/technical/zh/quickstart.md)：从零启动 Planet 的最短路径
|
||||
- [Planet 使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/manual.md)：控制台、`planet.sh`、Earth 和 Docs 的完整使用手册
|
||||
- [Earth 位置候选采集使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-user.md)：在 Earth 上为算力中心和 BGP 观测站采集、预览坐标候选
|
||||
- [数据源、采集器设置与连接验证](/home/ray/dev/linkong/planet/docs/technical/zh/datasource-collector-settings-connectivity.md)：数据源目录、采集器设置、连接验证、BarentsWatch 凭证链路
|
||||
- [通用位置估算管线开发说明](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-development.md)：后端 location resolver / pipeline 的接口、注册表和扩展方式
|
||||
- [Docs Gatekeeper 开发说明](/home/ray/dev/linkong/planet/docs/technical/zh/docs-gatekeeper-development.md)：后端 Docs 目录、正文读取和 Gatekeeper 权限组实现
|
||||
- [Earth 可交互图标接入](/home/ray/dev/linkong/planet/docs/technical/zh/earth-interactable-usage.md)：Earth 地表可交互图标 `Interactable` 的接口、生命周期和接入示例
|
||||
- [Earth 工具栏与浮层协同](/home/ray/dev/linkong/planet/docs/technical/zh/earth-toolbar-overlay-coordination.md)：工具栏按钮与搜索 / 设置 / 新闻 / 图层浮层之间的关闭矩阵和接入规则
|
||||
|
||||
|
||||
@@ -88,6 +88,10 @@ async def run(self, db):
|
||||
| BarentsWatch AIS | vessel | 船只位置、航速、航向、MMSI 等 AIS 数据 | 依采集器配置 |
|
||||
| AISStream Vessels | vessel_ais | AIS WebSocket 实时流，写入原始观测层并由聚合接口展示 | 依采集器配置 |
|
||||
|
||||
AIS 船只类采集器和其它 `CollectedData` 采集器的落库路径不同。BarentsWatch、AISStream 和自定义 `vessel_ais` 源都会进入 AIS 原始观测层，随后由聚合服务合并成 Earth 船只图层使用的 GeoJSON 和详情数据。这样做可以保留来源、传输方式、字段冲突和观测时间，避免某个实时源直接覆盖最终展示表。
|
||||
|
||||
TOP500 和 Epoch AI 算力数据的公开源不总是提供可用经纬度。Earth 统一算力中心接口在主地图启动链路中只使用源数据自带坐标或 `compute_center_locations` 维表坐标；缺少坐标的记录会进入 `unresolved`，不会通过本地注册表、国家质心或猜测城市自动渲染。用户手动采集候选时，后端会用源字段调用 ROR 组织注册 API 和 Nominatim/OpenStreetMap 在线搜索；候选经前端保存后写入 `compute_center_locations`，后续地图刷新再从维表渲染。
|
||||
|
||||
## 四、数据格式 (统一存储到 CollectedData 表)
|
||||
|
||||
```python
|
||||
@@ -242,8 +246,16 @@ backend/app/services/collectors/
|
||||
├── vessel_ais.py # BarentsWatch AIS 船只采集器
|
||||
└── aisstream.py # AISStream WebSocket 船只采集器
|
||||
|
||||
backend/app/services/
|
||||
├── custom_datasource_runtime.py # 自定义 REST / WebSocket 映射运行时
|
||||
├── datasource_mapping.py # 确定性字段映射与目标写入
|
||||
├── vessel_ais_aggregation.py # AIS 原始观测写入与聚合读取
|
||||
├── vessel_aggregation_strategy.py # 多源字段选择、freshness fallback 和冲突记录
|
||||
└── vessel_enrichment.py # 船舶资料富化缓存
|
||||
|
||||
backend/app/models/
|
||||
└── collected_data.py # 统一数据模型
|
||||
├── collected_data.py # 统一数据模型
|
||||
└── vessel_enrichment.py # 船舶富化结果缓存
|
||||
```
|
||||
|
||||
## 九、凭证型采集器
|
||||
@@ -253,7 +265,7 @@ backend/app/models/
|
||||
| 采集器 | credential provider | 凭证来源 |
|
||||
| --- | --- | --- |
|
||||
| `barentswatch_vessels` | `barentswatch` | 控制台采集器设置、环境变量、`~/.zshrc` |
|
||||
| `aisstream_vessels` | `aisstream` | 控制台采集器设置、环境变量 |
|
||||
| `aisstream_vessels` | `aisstream` | 控制台采集器设置、环境变量、`~/.zshrc`（连接验证可读；正式采集建议保存到采集器设置或注入后端环境） |
|
||||
| `spacetrack_tle` | `spacetrack` | 环境变量、`~/.zshrc` |
|
||||
|
||||
### BarentsWatch AIS
|
||||
@@ -292,6 +304,50 @@ export BARRENTSWATCH_CLIENT_SECRET="..."
|
||||
|
||||
连接验证会先请求 `https://id.barentswatch.no/connect/token` 获取 `scope=ais` 的 access token，再用 `Authorization: Bearer <token>` 请求 AIS endpoint。
|
||||
|
||||
### AISStream 实时船舶
|
||||
|
||||
AISStream 使用 `wss://stream.aisstream.io/v0/stream` WebSocket endpoint。默认运行方式是长连接实时采集，而不是传统 REST collector 的“请求一次、进度到 100%、完成”模型。
|
||||
|
||||
运行时配置：
|
||||
|
||||
- `api_key`：优先从 `DataSourceConfig.auth_config.api_key` 或 `config.api_key` 读取；也可由后端进程环境变量 `AISSTREAM_API_KEY` 提供。
|
||||
- `bounding_boxes`：AISStream 订阅范围，默认示例为全球 `[[[-90, -180], [90, 180]]]`，生产或演示建议先缩小区域。
|
||||
- `message_types`：默认 `PositionReport` 和 `ShipStaticData`。
|
||||
- `streaming_enabled`：默认启用长连接；关闭后回退到批次式 `fetch -> transform -> save`。
|
||||
- `streaming_max_messages`：测试用上限，非 0 时收到指定消息数后停止。
|
||||
- `reconnect_delay_seconds`、`receive_timeout_seconds`：控制断线重连和空闲等待。
|
||||
|
||||
状态语义：
|
||||
|
||||
- `connecting`：正在连接 AISStream。
|
||||
- `streaming`：持续接收实时消息，`records_processed` 表示已见消息数，通常没有固定总量和百分比。
|
||||
- `reconnecting`：上游断开或网络异常，采集器记录 `AISSourceHealth` 后等待重连。
|
||||
- `stopped` / `cancelled`：任务被测试上限或用户停止。
|
||||
|
||||
AISStream 连接验证会通过 `datasource_connectivity.py` 读取保存的采集器配置、环境变量和 `~/.zshrc` 中的 `AISSTREAM_API_KEY`。正式采集时，最稳妥的方式是把 API Key 保存到“设置 -> 采集器设置 -> AISStream 实时船舶”；如果只放在 `~/.zshrc`，需要确认后端进程实际继承到了该环境变量。
|
||||
|
||||
### AIS 原始观测与聚合
|
||||
|
||||
AIS 观测写入后不会直接替换最终船只记录，而是先保存为 raw observation：
|
||||
|
||||
- `source` 记录来源，例如 `barentswatch_vessels`、`aisstream_vessels` 或自定义源名称。
|
||||
- `delivery_mode` 表达实时性，`realtime_stream` 优先于 `polling`。
|
||||
- `transport` 记录 `websocket` 或 `http`。
|
||||
- 位置、速度、航向等动态字段会按 freshness 和来源优先级选择。
|
||||
- 静态字段优先保留非空值；冲突候选会记录到详情接口，便于排查多源差异。
|
||||
|
||||
Earth 使用的接口仍是：
|
||||
|
||||
```http
|
||||
GET /api/v1/visualization/geo/vessels
|
||||
GET /api/v1/visualization/vessels/{mmsi}
|
||||
GET /api/v1/visualization/vessels/{mmsi}/track
|
||||
GET /api/v1/visualization/vessels/{mmsi}/conflicts
|
||||
GET /api/v1/visualization/vessels/aggregation/diagnostics
|
||||
```
|
||||
|
||||
`/geo/vessels` 会合并 raw observation 聚合结果和 legacy BarentsWatch latest position 结果，避免只接入 AISStream 后把历史 BarentsWatch 船只遮蔽掉。
|
||||
|
||||
## 十、采集器设置与连接验证
|
||||
|
||||
控制台的“采集器设置”页提供所有内置采集器的 endpoint、请求头、超时、重试和凭证配置。连接验证不是只看前端按钮状态，而是由后端计算 checksum：
|
||||
|
||||
@@ -62,7 +62,7 @@
|
||||
当前行为：
|
||||
|
||||
- `collector_credentials` tab 展示为“采集器设置”。
|
||||
- 下拉框列出所有内置采集器。
|
||||
- 下拉框列出内置采集器，并支持维护合并到内置数据的自定义补充源。
|
||||
- 下拉框右侧只有一个插头图标按钮，用于健康检查。
|
||||
- 下拉框下方用状态标签展示：
|
||||
- `需要凭证` / `无需凭证`
|
||||
@@ -72,6 +72,8 @@
|
||||
- 是否覆盖 endpoint
|
||||
- 需要凭证的采集器把凭证卡片放在基础配置上方。
|
||||
- 不需要凭证的采集器只显示基础配置。
|
||||
- AISStream 采集器使用 WebSocket 语义，状态会显示为连接中、实时接收、重连或停止，不使用固定百分比表达完成度。
|
||||
- 自定义源入口放在采集器设置内，不在数据源目录里重复提供编辑入口；数据源目录只保留总览、运行和只读抽屉。
|
||||
|
||||
连接按钮使用内联 Tabler 风格插头图标，来源语义对应 `plug-connected`，避免继续使用刷新图标表达连接动作。
|
||||
|
||||
@@ -286,6 +288,100 @@ AISStream 使用 WebSocket 实时流，采集器只写入 `ais_raw_observations`
|
||||
- 船型通常来自低频 `ShipStaticData.Type`；后端会把 AIS 数字类型码映射为 Cargo / Tanker / Passenger / Fishing / Military。
|
||||
- 如果某艘船尚未收到静态消息，聚合结果的船型仍可能是 `Other`，后续由 v5 船舶资料 enrichment 补齐。
|
||||
|
||||
连接验证会读取保存配置、环境变量和 `~/.zshrc` 中的 `AISSTREAM_API_KEY`。正式采集时，推荐把 API Key 保存到采集器设置；如果只写在 `~/.zshrc`，需要确认后端进程实际继承了该变量，否则连接验证可能可用但 collector 运行时拿不到 key。
|
||||
|
||||
## 自定义 REST / WebSocket 映射运行时
|
||||
|
||||
文件：
|
||||
|
||||
- [custom_datasource_runtime.py](/home/ray/dev/linkong/planet/backend/app/services/custom_datasource_runtime.py)
|
||||
- [datasource_mapping.py](/home/ray/dev/linkong/planet/backend/app/services/datasource_mapping.py)
|
||||
|
||||
自定义源现在不是独立的新数据孤岛，而是作为内置数据源的补充源写入目标 schema。当前最完整的目标是 `vessel_ais`：自定义 REST 或 WebSocket 源经过确定性 mapping 后写入 AIS raw observations，再通过 `vessels` WebSocket channel 推送给 Earth。
|
||||
|
||||
### 配置语义
|
||||
|
||||
关键字段：
|
||||
|
||||
- `source_type`：`rest` / `http` / `websocket` / `ws`。
|
||||
- `endpoint`：REST 使用 `http(s)://`，WebSocket 使用 `ws(s)://`。
|
||||
- `auth_type`：`none`、`bearer`、`api_key`、`basic`。
|
||||
- `headers`：静态请求头。
|
||||
- `auth_config`：token、API key、basic 用户名密码，API key 支持 header 或 query。
|
||||
- `config.target_schema`：例如 `vessel_ais`。
|
||||
- `config.delivery_mode`：REST 默认 `polling`，WebSocket 默认 `realtime_stream`。
|
||||
- `config.merge_target_source`：记录该自定义源补充哪个内置数据，例如 `barentswatch_vessels`。
|
||||
|
||||
REST runner 支持：
|
||||
|
||||
- `GET` / `POST`
|
||||
- query params
|
||||
- JSON body
|
||||
- headers 和 auth 注入
|
||||
- active mapping 写入目标 schema
|
||||
|
||||
WebSocket runner 支持：
|
||||
|
||||
- endpoint 格式校验
|
||||
- headers 和 auth 注入
|
||||
- 可选 `ws_subscribe_message`
|
||||
- `ws_message_path` / `ws_items_path` 提取消息主体或数组
|
||||
- 断线重连
|
||||
- `debug_max_messages` 调试上限
|
||||
- 后台 stream start / stop / status
|
||||
|
||||
相关 API：
|
||||
|
||||
```http
|
||||
POST /api/v1/datasources/custom/sample
|
||||
GET /api/v1/datasources/target-schemas
|
||||
POST /api/v1/datasources/{config_id}/run-mapped
|
||||
POST /api/v1/datasources/{config_id}/stop-mapped
|
||||
GET /api/v1/datasources/{config_id}/mapped-status
|
||||
DELETE /api/v1/datasources/configs/{config_id}?delete_mappings=true&delete_source_data=true
|
||||
```
|
||||
|
||||
`run-mapped?background=true` 只对 WebSocket 源有意义，会启动后台 stream。REST 源仍是一次性采集。
|
||||
|
||||
### 删除与数据清理
|
||||
|
||||
删除自定义源时有三种层级：
|
||||
|
||||
- 只删除配置：保留 mapping 和历史数据。
|
||||
- 删除配置和 mapping：同时删除该配置的 mapping 模板。
|
||||
- 删除配置、mapping 和该源数据：删除该源写入的 `collected_data`、`ais_raw_observations` 和 `ais_source_health`。
|
||||
|
||||
如果删除的是 `vessel_ais` 自定义源数据，后端会向 `vessels` channel 广播 `reload_required`，提示 Earth 重新拉取船只聚合结果。legacy `vessel_position` 不按自定义源直接删除，因为它没有可靠的 source 归因。
|
||||
|
||||
### 本地 AIS mock WebSocket
|
||||
|
||||
文件：
|
||||
|
||||
- [mock-ais-ws-server.ts](/home/ray/dev/linkong/planet/scripts/mock-ais-ws-server.ts)
|
||||
|
||||
运行方式：
|
||||
|
||||
```bash
|
||||
bun run mock:ais-ws
|
||||
```
|
||||
|
||||
mock 服务持续发送 AIS-like JSON，用于验证“WebSocket 自定义源 -> mapping -> AIS raw observation -> `vessels` channel -> Earth 船只 upsert”链路。典型配置：
|
||||
|
||||
```json
|
||||
{
|
||||
"source_type": "websocket",
|
||||
"endpoint": "ws://localhost:8787",
|
||||
"config": {
|
||||
"target_schema": "vessel_ais",
|
||||
"delivery_mode": "realtime_stream",
|
||||
"merge_target_source": "barentswatch_vessels",
|
||||
"ws_message_path": "$.data",
|
||||
"ws_items_path": "$.vessels[*]",
|
||||
"ws_reconnect": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 凭证教程
|
||||
|
||||
文件：
|
||||
@@ -347,6 +443,7 @@ BarentsWatch `client_secret` 保存时有特殊处理：
|
||||
当前已经支持的凭证 provider：
|
||||
|
||||
- `barentswatch`
|
||||
- `aisstream`
|
||||
- `spacetrack`
|
||||
|
||||
其他 `requires_credentials=true` 的采集器如果还没有 provider，会返回“凭证链路尚未接入”，前端显示 `不可用`。
|
||||
|
||||
116
docs/technical/zh/docs-gatekeeper-development.md
Normal file
116
docs/technical/zh/docs-gatekeeper-development.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# Docs Gatekeeper 开发说明
|
||||
|
||||
Docs Gatekeeper 把 `/docs` 从“前端构建时打包所有 Markdown”改成“后端按权限返回目录和正文”。它的目标是让公开使用手册、用户文档、开发文档和管理/运维文档在同一个 Docs 页面内可检索，但正文读取必须经过服务端白名单和用户权限检查。
|
||||
|
||||
用户侧说明见 [Planet 使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/manual.md) 的 Docs 章节。
|
||||
|
||||
## 鉴权模型
|
||||
|
||||
Docs 使用两层权限：
|
||||
|
||||
- `users.role`：保留给控制台系统权限。
|
||||
- `users.gatekeeper_groups`：Docs 内容权限组。
|
||||
|
||||
权限组：
|
||||
|
||||
| 组 | 用途 |
|
||||
| --- | --- |
|
||||
| `docs_user` | 用户操作类文档 |
|
||||
| `docs_developer` | Earth、前端、后端、采集器和 AI Provider 开发文档 |
|
||||
| `docs_admin` | 服务控制、运维、环境变量和敏感操作文档 |
|
||||
|
||||
继承规则：
|
||||
|
||||
- 未登录用户只能读 `public`。
|
||||
- `docs_developer` 隐含 `docs_user`。
|
||||
- `docs_admin` 隐含 `docs_developer` 和 `docs_user`。
|
||||
- `admin` 和 `super_admin` 默认拥有全部 Docs 权限。
|
||||
|
||||
## 后端入口
|
||||
|
||||
文件：
|
||||
|
||||
- [docs.py](/home/ray/dev/linkong/planet/backend/app/api/v1/docs.py)
|
||||
- [docs_gatekeeper.py](/home/ray/dev/linkong/planet/backend/app/services/docs_gatekeeper.py)
|
||||
- [user.py](/home/ray/dev/linkong/planet/backend/app/models/user.py)
|
||||
- [users.py](/home/ray/dev/linkong/planet/backend/app/api/v1/users.py)
|
||||
|
||||
API：
|
||||
|
||||
```http
|
||||
GET /api/v1/docs/catalog
|
||||
GET /api/v1/docs/{lang}/{slug}
|
||||
```
|
||||
|
||||
`catalog` 只返回当前用户可见文档。正文接口会先校验语言、slug 和文件是否在 metadata 白名单里，再判断权限：
|
||||
|
||||
- 未登录访问受保护文档：`401`。
|
||||
- 已登录但权限不足：`403`。
|
||||
- 未知语言、未知 slug 或文件不存在：`404`。
|
||||
|
||||
正文文件只能来自 `docs/technical/{zh,en}/` 下的白名单文件，不能通过路径拼接读取任意文件。
|
||||
|
||||
## Metadata 来源
|
||||
|
||||
当前服务端 metadata 维护在 [docs_gatekeeper.py](/home/ray/dev/linkong/planet/backend/app/services/docs_gatekeeper.py)：
|
||||
|
||||
```python
|
||||
DocsMetadata(
|
||||
"manual.md",
|
||||
"manual",
|
||||
"public",
|
||||
"Manual",
|
||||
2,
|
||||
"Planet 使用手册",
|
||||
"Planet Manual",
|
||||
)
|
||||
```
|
||||
|
||||
新增公开文档时，需要同步：
|
||||
|
||||
- 新增中英文 Markdown 文件。
|
||||
- 在服务端 `DOCS_METADATA` 添加 filename、slug、access、group、order、标题。
|
||||
- 在前端 [docs-content.ts](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/docs-content.ts) 添加同名 metadata，保持导航标题和排序一致。
|
||||
- 如果需要从 README 发现，更新 `docs/technical/zh/README.md` 和 `docs/technical/en/README.md`。
|
||||
|
||||
## 用户管理
|
||||
|
||||
`users` 表新增 `gatekeeper_groups JSONB DEFAULT '[]'`。启动时 [session.py](/home/ray/dev/linkong/planet/backend/app/db/session.py) 会用 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` 补列，适配已有本地数据库。
|
||||
|
||||
用户 API 负责：
|
||||
|
||||
- 创建用户时写入 `gatekeeper_groups`。
|
||||
- 更新用户时校验组名只能是 `docs_user`、`docs_developer`、`docs_admin`。
|
||||
- 只有 `super_admin` 能修改 Gatekeeper 权限组。
|
||||
|
||||
前端 [Users.tsx](/home/ray/dev/linkong/planet/frontend/src/pages/Users/Users.tsx) 展示权限组标签，并在编辑表单中提供多选框。非 `super_admin` 打开的表单会禁用该字段，并在提交前移除 `gatekeeper_groups`。
|
||||
|
||||
## 前端 Docs 加载
|
||||
|
||||
文件：
|
||||
|
||||
- [Docs.tsx](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/Docs.tsx)
|
||||
- [docs-content.ts](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/docs-content.ts)
|
||||
- [docs-search.ts](/home/ray/dev/linkong/planet/frontend/src/pages/Docs/docs-search.ts)
|
||||
|
||||
关键变化：
|
||||
|
||||
- 移除 `import.meta.glob(...?raw)` 作为正文来源。
|
||||
- 页面加载时请求 `/api/v1/docs/catalog` 构建当前可见目录。
|
||||
- 打开正文时请求 `/api/v1/docs/{lang}/{slug}`。
|
||||
- 搜索只索引当前用户可见文档，并按需从后端读取 Markdown。
|
||||
- `401` 显示登录提示，`403` 显示权限提示，`404` 显示文档不可用。
|
||||
|
||||
## 测试覆盖
|
||||
|
||||
相关测试：
|
||||
|
||||
- [test_docs_gatekeeper.py](/home/ray/dev/linkong/planet/backend/tests/test_docs_gatekeeper.py)
|
||||
|
||||
测试应覆盖：
|
||||
|
||||
- 匿名用户只能看到 public 文档。
|
||||
- 受保护正文的 `401` / `403`。
|
||||
- `docs_developer` 可读开发文档但不能读管理文档。
|
||||
- `admin` 和 `super_admin` 可读管理文档。
|
||||
- 未知 slug、未知语言和路径穿越字符串不能读取文件。
|
||||
@@ -303,7 +303,9 @@ AISStream 的 `PositionReport` 常带实时位置和 `MetaData.ShipName`，但
|
||||
|
||||
登陆点是当前明确保留的例外：它曾接入 `Interactable`，但 pin 类 SVG 在地球边缘会被 `THREE.Points` 的深度测试裁切成碎片；关闭 depthTest 又会破坏背面遮挡语义。因此登陆点退回 `cables.js` 内的专用 `THREE.Sprite` 路径，并改为 canvas 生成的黄色扁平球纹理。它的 `altitudeOffset` 和 `renderOrder` 与海缆线一致，避免漂在海缆之上；Sprite 本体关闭 `depthTest` 保持球完整，背面可见性由 `isFacingCamera()` 的球体遮挡判断控制。
|
||||
|
||||
图标资源可以继续用 canvas draw，也可以放到 `frontend/public/earth/assets/icons/` 后由 `Interactable` 预加载。asset 路径不会在每帧读取；图层加载阶段通过 `preloadAssets()` 只加载一次 SVG / 图片，之后按 `icon source + state + bucket + color` 生成 `CanvasTexture` 并复用。当前算力中心已经从 `assets/icons/compute-supercomputer.svg`、`assets/icons/compute-gpu-cluster.svg` 和备用 `assets/icons/compute-hdd-network.svg` 读取图标，再在 canvas 上叠加估算位置的 `?` badge。
|
||||
图标资源可以继续用 canvas draw，也可以放到 `frontend/public/earth/assets/icons/` 后由 `Interactable` 预加载。asset 路径不会在每帧读取；图层加载阶段通过 `preloadAssets()` 只加载一次 SVG / 图片，之后按 `icon source + state + bucket + color` 生成 `CanvasTexture` 并复用。当前算力中心已经从 `assets/icons/compute-supercomputer.svg`、`assets/icons/compute-gpu-cluster.svg` 和备用 `assets/icons/compute-hdd-network.svg` 读取图标，再在 canvas 上叠加未确认位置的 `?` badge。算力中心后端在启动链路只渲染源数据自带坐标或 `compute_center_locations` 维表坐标；手动候选采集会调用 ROR 和 Nominatim/OpenStreetMap，并在 GeoJSON 或候选响应中返回位置精度、置信度、来源说明和核验时间；前端详情卡展示这些字段。
|
||||
|
||||
算力中心图层行左上角的通知气泡显示 GeoJSON `unresolved` 数量。这个数字表示“完全没有可信坐标、不能渲染到地球上”的记录，不等同于地图上带 `?` 的已定位待确认点。点击气泡会在图层面板右侧打开固定信息卡，信息卡内容区内部滚动，不随鼠标 hover 消失。列表中的单条 `采集` 只展示候选；顶部 `一键采用` 会按当前列表顺序逐条采集、保存最高置信候选，成功一条就移除一条、重新编号，并通过 `earth:compute-center-unresolved-count-change` 同步气泡数量。批量结束后再触发 `earth:compute-center-location-saved` 刷新真实图层。
|
||||
|
||||
asset 图标大小由 `Interactable` 的 `icon.fitSize` 控制。SVG / 图片文件应尽量保持原始 viewBox 和路径，不要为了在地球上显示成 60x60 而手写 `transform`；`drawAssetIcon()` 会把资源等比 contain 到指定尺寸并居中绘制到 atlas canvas。
|
||||
|
||||
@@ -352,6 +354,10 @@ const scale = THREE.MathUtils.clamp(
|
||||
- 按钮：`#toggle-terrain`
|
||||
- 状态节点：`#terrain-status`
|
||||
|
||||
地形不是默认可见图层时，启动期不会立即阻塞加载地形瓦片。`controls.js` 会在图层可见性恢复完成后才调度 `scheduleTerrainPrefetch()`，并且只在高清材质可用、地形尚未 ready、预取未开始时执行。预取使用 `setTimeout` + `requestIdleCallback`，避免和首屏云图、高清材质、图层启动队列抢主线程。
|
||||
|
||||
地形瓦片请求也不再逐个散发大量单 tile 请求。`terrain.js` 会把需要的 Terrarium tile 去重后按 `TERRAIN_CONFIG.batchRequestSize` 分批请求 `/api/v1/visualization/terrain/terrarium/batch`；后端用 LRU 内存缓存、批次去重和并发限制代理 S3 Terrarium tile。单 tile endpoint 仍保留给回退路径和浏览器缓存语义。
|
||||
|
||||
以后别的异步图层也可以沿用这套约定。
|
||||
|
||||
## 当前设置持久化
|
||||
|
||||
@@ -155,6 +155,7 @@
|
||||
- 渲染 `/docs` 的 Markdown 正文
|
||||
- 支持标题、列表、引用、代码块、表格和基础行内格式
|
||||
- 代码块和表格内部复用 `Scrollbar`，避免横向内容撑爆文档页
|
||||
- Docs 正文由后端 `/api/v1/docs/...` 按 Gatekeeper 权限返回；前端只渲染当前用户可见内容
|
||||
|
||||
当前约束：
|
||||
|
||||
@@ -190,9 +191,10 @@
|
||||
|
||||
- token
|
||||
- 当前用户
|
||||
- Gatekeeper 权限组
|
||||
- 登录/退出
|
||||
|
||||
`App.tsx` 用它判断是否进入登录页。
|
||||
`App.tsx` 用它判断是否进入登录页。`/docs` 仍是公开路由，但目录和正文由后端按 token 决定；未登录时只返回公开文档。
|
||||
|
||||
### 2. 业务数据网关
|
||||
|
||||
|
||||
200
docs/technical/zh/location-pipeline-development.md
Normal file
200
docs/technical/zh/location-pipeline-development.md
Normal file
@@ -0,0 +1,200 @@
|
||||
# 通用位置估算管线开发说明
|
||||
|
||||
`backend/app/services/location/` 是所有“给定一条记录，决定它的 lat/lon”业务的共享抽象。算力中心、BGP 观测站、BGP 事件目前都跑在这条管线上。未来需要位置估算的实体，例如卫星地面站、用户认领点位、IXP 设施，也应接入这里，而不是各自再写地理解析逻辑。
|
||||
|
||||
用户侧流程见 [Earth 位置候选采集使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-user.md)。
|
||||
|
||||
## 设计目标
|
||||
|
||||
历史上算力中心有自己的 4 层链路，BGP 观测站使用写死字典，BGP 事件继承 collector。三套实现互不复用，新算法也没有稳定挂入点。
|
||||
|
||||
重构后的原则：
|
||||
|
||||
- 共享 `LocationResolver` 协议和 `LocationPipeline` 编排器。
|
||||
- 各领域只负责构造 `LocationQuery` 和选择 resolver 顺序。
|
||||
- 新算法通过新增 resolver 类接入，不改 ingestion、API 和前端 envelope。
|
||||
- 只有达到城市级或更高精度的位置能渲染到 Earth。
|
||||
- 本地 JSON registry 不作为算力中心或 BGP 观测站的运行时候选来源；持久事实写入数据库维表。
|
||||
|
||||
## 核心接口
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class LocationQuery:
|
||||
name: str | None
|
||||
aliases: tuple[str, ...]
|
||||
city: str | None
|
||||
country: str | None
|
||||
region: str | None
|
||||
source_latitude: float | None
|
||||
source_longitude: float | None
|
||||
extra: Mapping[str, Any]
|
||||
```
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class LocationCandidate:
|
||||
latitude: float
|
||||
longitude: float
|
||||
display_name: str
|
||||
precision: str
|
||||
confidence: float
|
||||
source: str
|
||||
needs_confirmation: bool
|
||||
matched_fields: tuple[str, ...]
|
||||
suggested_registry_entry: dict | None
|
||||
```
|
||||
|
||||
```python
|
||||
class LocationResolver(Protocol):
|
||||
name: str
|
||||
def resolve(self, query: LocationQuery) -> ResolverOutput: ...
|
||||
```
|
||||
|
||||
`LocationPipeline.collect_candidates()` 返回排序后的候选和 `attempted_queries`；`resolve_best()` 返回最佳候选及诊断信息。默认排序按 source rank、precision rank、confidence，且对同 source 和同坐标候选去重。
|
||||
|
||||
## 内置 resolver
|
||||
|
||||
| Resolver | 文件 | 职责 |
|
||||
| --- | --- | --- |
|
||||
| `SourceCoordinatesResolver` | `resolvers/source_coordinates.py` | 源记录已有 lat/lon 时直接产出 `precision="precise"` |
|
||||
| `RegistryResolver` | `resolvers/registry.py` | 遗留通用 resolver；当前算力中心和 BGP 运行时链路不使用它生成候选 |
|
||||
| `NominatimResolver` | `resolvers/nominatim.py` | 按领域 query plan 调 Nominatim，带 LRU 缓存和速率限制 |
|
||||
| `InheritFromAnotherEntityResolver` | `resolvers/inherit.py` | 把外部实体的已解析位置包装为候选 |
|
||||
|
||||
`RegistryResolver` 仍保留给后续可能的受控导入场景，但它不应被重新接入算力中心或 BGP 作为“硬编码 hint”候选源。过去仅凭 `operator`、`city` 等通用字段匹配 registry 容易把多个实体落到同一个点，这是这次下线 registry 候选链路的主要原因。
|
||||
|
||||
## 当前领域管线
|
||||
|
||||
### 算力中心
|
||||
|
||||
入口文件：
|
||||
|
||||
- [compute_center_locations.py](/home/ray/dev/linkong/planet/backend/app/services/compute_center_locations.py)
|
||||
|
||||
管线顺序：
|
||||
|
||||
```python
|
||||
SourceCoordinatesResolver()
|
||||
StoredComputeCenterLocationResolver()
|
||||
```
|
||||
|
||||
主地图启动链路只做“源坐标优先，其次数据库维表坐标”。数据库表为 `compute_center_locations`，唯一键是 `(source, source_id)`，用于保存人工确认或从源记录真实坐标迁入的位置。`init_db()` 只幂等迁入源记录里已有的真实经纬度，不迁入旧硬编码 hint，不在启动期批量调用 ROR、Nominatim 或 LLM。
|
||||
|
||||
手动候选采集链路和渲染链路分开。`collect_location_candidates()` 使用源字段构造 ROR 和 Nominatim/OpenStreetMap 查询，但不会把 `compute_center_locations` 当前坐标当候选返回。用户在前端确认某个候选后，通过保存接口写入维表；之后地图刷新时由 `StoredComputeCenterLocationResolver` 渲染。
|
||||
|
||||
`resolve_compute_center_location()`、`resolve_compute_center_location_full()` 和 `collect_location_candidates()` 保留为领域 API。`visualization.py` 只消费领域 API，不再持有坐标提示常量、国家质心兜底或 Nominatim 细节。
|
||||
|
||||
GeoJSON 输出只包含 `RENDERABLE_PRECISIONS` 内的位置。未解析记录进入 `unresolved`，并带上 `failure_reason`、`attempted_queries`、`source_id`、`record_id` 等诊断字段。
|
||||
|
||||
### BGP 观测站
|
||||
|
||||
入口文件：
|
||||
|
||||
- [bgp_collector_locations.py](/home/ray/dev/linkong/planet/backend/app/services/bgp_collector_locations.py)
|
||||
- [bgp_collector_location.py](/home/ray/dev/linkong/planet/backend/app/models/bgp_collector_location.py)
|
||||
|
||||
管线顺序：
|
||||
|
||||
```python
|
||||
SourceCoordinatesResolver()
|
||||
StoredCollectorLocationResolver()
|
||||
NominatimResolver(_bgp_collector_query_plan)
|
||||
```
|
||||
|
||||
23 个 RIPE RIS collector 坐标从旧表迁入 `bgp_collector_locations` 维表，默认 `source=legacy_seed`、`needs_confirmation=true`。旧字典仍由 DB-backed cache 维护，保证下游接口兼容；手动候选采集不会把这份维表坐标当作候选，只用它补齐 site/city/country 查询上下文。
|
||||
|
||||
### BGP 事件
|
||||
|
||||
入口文件：
|
||||
|
||||
- [bgp_event_locations.py](/home/ray/dev/linkong/planet/backend/app/services/bgp_event_locations.py)
|
||||
|
||||
管线顺序：
|
||||
|
||||
```python
|
||||
SourceCoordinatesResolver()
|
||||
InheritFromAnotherEntityResolver(_inherit_from_owning_collector)
|
||||
```
|
||||
|
||||
事件继承使用所属 collector 的严格查找，不跑完整 collector registry 模糊匹配。后续 ASN 设施、PrefixGeo 或 PeeringDB resolver 可以挂在继承 resolver 之后。
|
||||
|
||||
## API envelope
|
||||
|
||||
```http
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/collect-location
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/location
|
||||
POST /api/v1/bgp/collectors/{collector_id}/collect-location
|
||||
```
|
||||
|
||||
`collect-location` 返回统一 envelope：
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"candidates": [],
|
||||
"best_candidate": {},
|
||||
"attempted_queries": [],
|
||||
"context": {}
|
||||
}
|
||||
```
|
||||
|
||||
`POST /api/v1/visualization/compute-centers/{source_id}/location` 把前端选中的候选 upsert 到 `compute_center_locations`。人工保存默认 `needs_confirmation=false`、`verification_status="verified"` 并写入 `verified_at`；如果后续接入自动暂存，也可以显式传 `needs_confirmation=true`。
|
||||
|
||||
前端 [info-card.js](/home/ray/dev/linkong/planet/frontend/public/earth/js/info-card.js) 使用通用候选列表和预览事件渲染对象详情卡。算力中心图层按钮左上角会显示 `unresolved` 数量；点击角标打开待定位列表。列表中的 `采集` 只拉候选，`一键采用` 会逐条调用候选采集接口，选择最高置信且有有效经纬度的候选保存。保存成功一条就从列表移除并重新编号，同时通过 `earth:compute-center-unresolved-count-change` 同步角标；批量结束后再触发 `earth:compute-center-location-saved` 刷新真实图层。
|
||||
|
||||
如果剩余记录没有任何 city-level 候选，批量采用不会伪造坐标。前端会保留这些记录并展示后端返回的 `failure_reason` 和已尝试查询。
|
||||
|
||||
## 新增 resolver
|
||||
|
||||
resolver 只需要实现 `name` 和 `resolve()`，返回 `ResolverOutput`。
|
||||
|
||||
```python
|
||||
class PeeringDBFacilityResolver:
|
||||
name = "peeringdb_facility"
|
||||
|
||||
def __init__(self, client):
|
||||
self._client = client
|
||||
|
||||
def resolve(self, query):
|
||||
asn = query.extra.get("origin_asn")
|
||||
if not asn:
|
||||
return ResolverOutput()
|
||||
return ResolverOutput(candidates=tuple(
|
||||
LocationCandidate(
|
||||
latitude=f.latitude,
|
||||
longitude=f.longitude,
|
||||
display_name=f.name,
|
||||
precision="site",
|
||||
confidence=0.78,
|
||||
query=f"peeringdb::{asn}",
|
||||
source=self.name,
|
||||
source_note=f"PeeringDB facility for AS{asn}",
|
||||
matched_fields=("origin_asn",),
|
||||
needs_confirmation=False,
|
||||
city=f.city,
|
||||
country=f.country,
|
||||
)
|
||||
for f in self._client.facilities_for_asn(asn)
|
||||
))
|
||||
```
|
||||
|
||||
挂入：
|
||||
|
||||
```python
|
||||
BGP_EVENT_PIPELINE = LocationPipeline([
|
||||
SourceCoordinatesResolver(),
|
||||
InheritFromAnotherEntityResolver(source_lookup=...),
|
||||
PeeringDBFacilityResolver(client=peeringdb_client),
|
||||
])
|
||||
```
|
||||
|
||||
## 测试覆盖
|
||||
|
||||
相关测试：
|
||||
|
||||
- [test_location_pipeline.py](/home/ray/dev/linkong/planet/backend/tests/test_location_pipeline.py)
|
||||
- [test_bgp_collector_locations.py](/home/ray/dev/linkong/planet/backend/tests/test_bgp_collector_locations.py)
|
||||
- [test_visualization_compute_centers.py](/home/ray/dev/linkong/planet/backend/tests/test_visualization_compute_centers.py)
|
||||
|
||||
测试重点包括 resolver 可插拔性、注册表 alias 约束、BGP collector 兼容字典、算力中心公共 API 兼容、不可渲染位置进入 `unresolved`。
|
||||
127
docs/technical/zh/location-pipeline-user.md
Normal file
127
docs/technical/zh/location-pipeline-user.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# Earth 位置候选采集使用手册
|
||||
|
||||
位置候选采集用于给 Earth 上的算力中心和 BGP 观测站补齐或核验经纬度。它不会要求用户手工输入坐标，而是把源数据、开放组织注册 API 和在线地理编码结果整理成候选列表，供用户预览和后续认领。
|
||||
|
||||
## 适用对象
|
||||
|
||||
当前支持：
|
||||
|
||||
- 算力中心：TOP500 超算、Epoch AI GPU 集群。
|
||||
- BGP 观测站：RIPE RIS `rrcXX` collector。
|
||||
|
||||
BGP 事件的位置默认继承所属 collector。事件本身暂不提供单独按钮；后续 ASN 设施、Prefix 地理位置或 PeeringDB 算法接入后会继续走同一条管线。
|
||||
|
||||
## 用户能看到什么
|
||||
|
||||
在 Earth 上点击算力中心或 BGP 观测站后，详情卡会展示位置相关字段：
|
||||
|
||||
| 字段 | 含义 |
|
||||
| --- | --- |
|
||||
| 位置精度 | `精确坐标`、`站点级位置`、`城市级位置` 或 `位置未确认` |
|
||||
| 位置来源 | 源数据坐标、ROR 组织注册 API、Nominatim 在线搜索，或已存储的 BGP collector 维表位置 |
|
||||
| 位置置信度 | 后端 resolver 给出的相对置信度百分比 |
|
||||
| 核验状态 | 已确认、估算位置或在线检索结果待确认 |
|
||||
| 解析依据 | 为什么选择这个位置，例如匹配了哪个站点或城市 |
|
||||
| 匹配的位置名称 | 开放来源、在线结果或已存储 collector 位置中的规范名称 |
|
||||
| 位置核验时间 | 已确认位置的核验日期，在线候选通常为空 |
|
||||
|
||||
算力中心 GeoJSON 不再渲染国家质心、未知位置或 `[0, 0]` 占位点。无法达到城市级精度的数据会进入接口的 `unresolved` 列表，并在图层开关左上角显示待定位数量。点击这个通知气泡会打开待定位列表。
|
||||
|
||||
地图上带 `?` 的算力中心不是 `unresolved`。它们已经有坐标，只是 `needs_confirmation=true` 或来自在线地理编码，仍需人工核验。真正 `unresolved` 的记录没有可信经纬度，因此不会出现在地球上。
|
||||
|
||||
## 自动采集候选
|
||||
|
||||
1. 打开 `http://localhost:3000/earth`。
|
||||
2. 打开 `算力中心` 或 `BGP 观测` 图层。
|
||||
3. 点击目标对象打开详情卡。
|
||||
4. 点击 `自动采集坐标候选` 或 `重新自动采集坐标`。
|
||||
5. 等待详情卡列出最多 5 个候选位置。
|
||||
6. 点击候选行里的 `预览`，Earth 会飞到该候选经纬度附近。
|
||||
|
||||
候选列表会显示：
|
||||
|
||||
- 候选名称。
|
||||
- 精度：精确、站点或城市。
|
||||
- 来源 resolver。
|
||||
- 置信度。
|
||||
- 经纬度。
|
||||
|
||||
点击候选行里的 `保存` 会把所选候选写入算力中心位置维表。保存成功后，算力中心图层会刷新；如果该记录原本在待定位列表中，待定位数量也会减少。
|
||||
|
||||
## 待定位列表和一键采用
|
||||
|
||||
算力中心图层按钮左上角的通知气泡显示当前 `unresolved` 数量。点击后会在图层面板右侧打开固定列表：
|
||||
|
||||
1. 列表只包含没有可信经纬度的算力中心。
|
||||
2. 单条 `采集` 会调用候选接口，并展示最多 5 个候选供预览和保存。
|
||||
3. 顶部 `一键采用` 会从上到下逐条采集候选，选择置信度最高且有有效经纬度的候选保存。
|
||||
4. 成功保存一条后，该行会立即从列表中移除，下面的序号自动上移，通知气泡数量同步减少。
|
||||
5. 批量结束后，前端会刷新算力中心图层，确保 UI 和后端真实状态一致。
|
||||
|
||||
如果某条记录没有任何可保存候选，系统不会用国家中心点、厂商总部或硬编码 hint 伪造位置。该记录会留在列表中，并显示后端返回的失败原因和已尝试查询，等待人工补充更可靠的地址或坐标证据。
|
||||
|
||||
## 后端接口
|
||||
|
||||
前端按钮调用的接口如下：
|
||||
|
||||
```http
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/collect-location
|
||||
POST /api/v1/visualization/compute-centers/{source_id}/location
|
||||
POST /api/v1/bgp/collectors/{collector_id}/collect-location
|
||||
```
|
||||
|
||||
两个 `collect-location` 接口返回相同结构：
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"candidates": [],
|
||||
"best_candidate": {},
|
||||
"attempted_queries": [],
|
||||
"context": {}
|
||||
}
|
||||
```
|
||||
|
||||
当没有候选达到城市级精度时，`success` 为 `false`，响应会包含 `failure_reason` 和已尝试的查询文本，便于判断是源数据字段不足、开放来源缺项，还是在线地理编码没有命中。
|
||||
|
||||
## 数据维护建议
|
||||
|
||||
算力中心和 BGP 观测站都不再维护本地候选注册表。算力中心的人工确认位置保存在 `compute_center_locations` 数据库维表中，唯一键是 `(source, source_id)`；BGP 观测站的当前位置保存在 `bgp_collector_locations` 数据库维表中，旧 RIPE RIS 城市级坐标只作为初始化 seed 写入，默认仍需人工核验。
|
||||
|
||||
维护算力中心时优先补齐：
|
||||
|
||||
- `source` / `source_id`：例如 `top500` + `top500_50`。
|
||||
- `name` / `operator` / `site`。
|
||||
- `city` / `country`。
|
||||
- `latitude` / `longitude`。
|
||||
- `precision`：`precise`、`site` 或 `city`。
|
||||
- `confidence`：0 到 1 的置信度。
|
||||
- `location_source` / `source_url` / `source_note` / `raw_payload`：证据来源。
|
||||
- `needs_confirmation` / `verification_status` / `verified_at`：人工核验状态和日期。
|
||||
|
||||
维护 BGP 观测站时优先补齐：
|
||||
|
||||
- `collector_id`：例如 `rrc12`。
|
||||
- `site` / `operator`：站点和运营方。
|
||||
- `city` / `country` / `region`。
|
||||
- `latitude` / `longitude`。
|
||||
- `precision`：`precise`、`site` 或 `city`。
|
||||
- `confidence`：0 到 1 的置信度。
|
||||
- `source` / `source_url` / `raw_payload`：证据来源。
|
||||
- `verification_status` / `verified_at`：人工核验状态和日期。
|
||||
|
||||
如果只是知道城市，不知道设施坐标，应使用城市级精度，不要填一个看似精确但无法核验的点位。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 为什么有些算力中心不显示在 Earth 上
|
||||
|
||||
Earth 只渲染达到城市级或更高精度的坐标。源数据没有坐标、已验证位置没有命中、在线搜索也没有城市级结果时，记录会进入 `unresolved`，避免在地图上出现误导性的国家中心点或 `[0, 0]`。
|
||||
|
||||
### 为什么在线搜索结果显示“待确认”
|
||||
|
||||
Nominatim/OpenStreetMap 结果来自在线地理编码，可能匹配到同名城市、机构或园区。它可以用于快速定位和预览，但在写入已验证位置前应人工确认。
|
||||
|
||||
### 为什么 BGP 事件没有全部落到 Amsterdam
|
||||
|
||||
旧逻辑中，事件可能因为 `operator="RIPE NCC"` 这种通用字段误匹配到 `rrc00`。当前 BGP 事件继承只按所属 collector 在 DB-backed cache 中严格查找，不再用 registry 模糊匹配。
|
||||
@@ -5,7 +5,7 @@
|
||||
- `planet.sh`：本地启动、停止、重启、健康检查和日志入口
|
||||
- Earth：公开 3D 地球态势页面
|
||||
- 控制台：登录后的管理后台
|
||||
- Docs：公开开发文档与使用手册
|
||||
- Docs：后端 Gatekeeper 受控的文档站，基础使用文档公开，开发/运维文档按权限组开放
|
||||
|
||||
快速启动路径见 [快速开始](/home/ray/dev/linkong/planet/docs/technical/zh/quickstart.md)。
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
| 名称 | 地址 | 是否需要登录 | 说明 |
|
||||
| --- | --- | --- | --- |
|
||||
| Earth | `http://localhost:3000/earth` | 否 | 3D 地球、图层、BGP、卫星、海缆、新闻态势 |
|
||||
| Docs | `http://localhost:3000/docs` | 否 | 开发文档、技术说明、使用手册 |
|
||||
| Docs | `http://localhost:3000/docs` | 部分需要 | 使用手册公开；开发、后端、运维文档按 Gatekeeper 权限组开放 |
|
||||
| 控制台 | `http://localhost:3000/admin` | 是 | 数据、配置、告警、日志和专题观测 |
|
||||
| AI Playground | `http://localhost:3000/playground` | 是 | AI Provider 状态和调试 |
|
||||
| 后端 API 文档 | `http://localhost:8000/docs` | 视接口而定 | FastAPI / OpenAPI 文档 |
|
||||
@@ -198,7 +198,26 @@ AI Provider 镜像只在代码、Dockerfile、Compose 配置或相关 Python 依
|
||||
- 手机或平板演示 Earth
|
||||
- 局域网其他机器访问同一个开发实例
|
||||
|
||||
启动后注意检查防火墙和 WSL 网络转发。
|
||||
`--allow-lan` 只负责让前端和后端监听 `0.0.0.0`。如果服务运行在 WSL 中，Windows 本机通常可以通过 `localhost` 访问，但手机或其他电脑访问 `http://<Windows局域网IP>:3000` 还依赖 Windows 端口转发和防火墙放行。
|
||||
|
||||
推荐按顺序判断：
|
||||
|
||||
```bash
|
||||
# 在 WSL 或运行 Planet 的 shell 中
|
||||
curl http://localhost:3000
|
||||
curl http://localhost:8000/health
|
||||
ss -ltnp | grep -E ':3000|:8000'
|
||||
```
|
||||
|
||||
如果这里能看到 `0.0.0.0:3000` 和 `0.0.0.0:8000`，但局域网 IP 访问失败，请在管理员 PowerShell 中配置：
|
||||
|
||||
```powershell
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=3000 connectaddress=127.0.0.1 connectport=3000
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8000 connectaddress=127.0.0.1 connectport=8000
|
||||
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 3000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 8000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8000
|
||||
```
|
||||
|
||||
## Earth
|
||||
|
||||
@@ -290,6 +309,12 @@ Earth 搜索支持查找当前地球对象，例如：
|
||||
|
||||
搜索结果可以用于快速定位对象，并打开对应详情。
|
||||
|
||||
### 位置候选采集
|
||||
|
||||
算力中心和 BGP 观测站详情卡支持自动采集坐标候选。点击对象后，使用详情卡中的 `自动采集坐标候选` 或 `重新自动采集坐标` 按钮，后端会从源坐标、开放组织注册 API 和在线地理编码中整理候选位置。BGP 观测站的已存储位置只用于补齐查询上下文，不会作为候选直接返回。
|
||||
|
||||
候选可以直接在 Earth 上预览。算力中心候选点击 `保存` 后会写入 `compute_center_locations` 维表，并立即刷新图层。算力中心图层左上角的通知气泡显示无法渲染的待定位数量；点击后可查看列表，单条采集候选，或用 `一键采用` 从上到下保存最高置信候选。没有可用候选的记录会留在列表中，不会被国家中心点或硬编码 hint 伪造位置。详细流程见 [Earth 位置候选采集使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-user.md)。
|
||||
|
||||
### 设置
|
||||
|
||||
设置面板包含：
|
||||
@@ -536,33 +561,41 @@ BarentsWatch AIS 支持从以下位置读取凭证：
|
||||
|
||||
## Docs
|
||||
|
||||
公开文档站入口：
|
||||
文档站入口：
|
||||
|
||||
```text
|
||||
http://localhost:3000/docs
|
||||
```
|
||||
|
||||
当前公开内容来自：
|
||||
Docs 正文由后端 API 按权限读取，不再把全部 Markdown 直接打进前端构建产物。当前文档源文件仍位于：
|
||||
|
||||
```text
|
||||
docs/technical/zh/*.md
|
||||
docs/technical/en/*.md
|
||||
```
|
||||
|
||||
未登录访客默认只能看到 `public` 文档，例如首页、快速开始和使用手册。登录用户如果被分配 Gatekeeper 权限组，可以看到更多技术文档：
|
||||
|
||||
- `docs_user`：用户操作类文档。
|
||||
- `docs_developer`：Earth、前端、后端、采集器和 AI Provider 等开发文档。
|
||||
- `docs_admin`：服务控制、运维、环境变量和敏感操作文档。
|
||||
|
||||
`admin` 默认拥有管理文档权限，`super_admin` 拥有全部 Docs 权限。Gatekeeper 权限组在控制台“用户管理”中配置。
|
||||
|
||||
Docs 支持：
|
||||
|
||||
- 分类导航
|
||||
- Markdown 渲染
|
||||
- 表格和代码块
|
||||
- 文档内目录
|
||||
- 本地搜索
|
||||
- 对当前可见文档搜索
|
||||
- technical 文档之间的内部链接跳转
|
||||
|
||||
如果新增 technical 文档，应同步检查：
|
||||
|
||||
- 是否有清晰的一级标题
|
||||
- 是否需要加入 `/docs` 的人工分类和排序
|
||||
- 是否包含不适合公开展示的信息
|
||||
- 是否需要加入后端 Docs metadata 的人工分类和排序
|
||||
- 应归入 `public`、`docs_user`、`docs_developer` 还是 `docs_admin`
|
||||
|
||||
## 开发命令约定
|
||||
|
||||
@@ -633,6 +666,7 @@ source ~/.zshrc && bun run build
|
||||
- [控制台前端结构](/home/ray/dev/linkong/planet/docs/technical/zh/frontend-admin-frontend-context.md)
|
||||
- [Earth 前端结构](/home/ray/dev/linkong/planet/docs/technical/zh/earth-frontend-context.md)
|
||||
- [Earth 图层样式属性索引](/home/ray/dev/linkong/planet/docs/technical/zh/earth-layer-style-reference.md)
|
||||
- [Earth 位置候选采集使用手册](/home/ray/dev/linkong/planet/docs/technical/zh/location-pipeline-user.md)
|
||||
- [系统服务控制](/home/ray/dev/linkong/planet/docs/technical/zh/backend-system-service-control.md)
|
||||
- [数据采集系统](/home/ray/dev/linkong/planet/docs/technical/zh/backend-collectors.md)
|
||||
- [数据源、采集器设置与连接验证](/home/ray/dev/linkong/planet/docs/technical/zh/datasource-collector-settings-connectivity.md)
|
||||
|
||||
@@ -150,6 +150,13 @@ wait_for_port_release() {
|
||||
}
|
||||
```
|
||||
|
||||
当前启动前端时还有一层预清理重试：
|
||||
|
||||
- `PORT_PRESTART_RETRIES`：默认 3 次。
|
||||
- `PORT_PRESTART_RETRY_INTERVAL`：默认 2 秒。
|
||||
|
||||
`kill_port_if_requested()` 只在当前环境能找到监听 PID 时主动杀进程；如果没有 PID 但端口暂时不可绑定，它会记录诊断并把最终确认交给服务启动流程。`start_frontend_with_retry()` 也只在发现监听 PID 时进入预清理重试，避免在宿主机或外部 network namespace 尚未释放端口时做无意义的“空杀重试”。这意味着第一次重启时看到“未发现监听进程但端口仍不可绑定”通常是外部环境仍在释放端口；脚本不会再把这种情况当成立刻失败的本地进程清理问题。
|
||||
|
||||
## 问题三：端口检测用 Python
|
||||
|
||||
### 原因
|
||||
|
||||
@@ -30,6 +30,16 @@ AI Provider 的个人配置也可以放在 `~/.zshrc`。`planet.sh` 会读取简
|
||||
./planet.sh restart -a
|
||||
```
|
||||
|
||||
AISStream、BarentsWatch 等采集器凭证也可以先写在 `~/.zshrc` 里供连接验证读取，例如：
|
||||
|
||||
```bash
|
||||
export AISSTREAM_API_KEY="..."
|
||||
export BARENTSWATCH_CLIENT_ID="..."
|
||||
export BARENTSWATCH_CLIENT_SECRET="..."
|
||||
```
|
||||
|
||||
正式采集更推荐在控制台 `设置 -> 采集器设置` 保存凭证，尤其是 AISStream 这类长连接 WebSocket collector。这样连接验证、后端采集任务和 Earth 实时船只聚合会使用同一份配置。
|
||||
|
||||
## 1. 启动服务
|
||||
|
||||
在仓库根目录执行：
|
||||
@@ -44,7 +54,7 @@ AI Provider 的个人配置也可以放在 `~/.zshrc`。`planet.sh` 会读取简
|
||||
| --- | --- | --- |
|
||||
| Earth | `http://localhost:3000/earth` | 公开 3D Earth 可视化页面 |
|
||||
| 控制台 | `http://localhost:3000/admin` | 登录后的管理后台 |
|
||||
| 文档站 | `http://localhost:3000/docs` | 公开开发文档和使用手册 |
|
||||
| 文档站 | `http://localhost:3000/docs` | 使用手册公开；开发/运维文档按 Gatekeeper 权限组开放 |
|
||||
| AI Playground | `http://localhost:3000/playground` | 登录后的 AI 调试入口 |
|
||||
| 后端 API 文档 | `http://localhost:8000/docs` | FastAPI / OpenAPI 接口文档 |
|
||||
|
||||
@@ -64,6 +74,8 @@ AI Provider 的个人配置也可以放在 `~/.zshrc`。`planet.sh` 会读取简
|
||||
|
||||
按提示输入用户名、密码和角色。
|
||||
|
||||
如果需要阅读开发或运维文档，用 `super_admin` 登录控制台后，在“用户管理”里给目标用户分配 Gatekeeper 权限组：`docs_developer` 用于开发文档，`docs_admin` 用于服务控制和运维文档。
|
||||
|
||||
## 3. 打开 Earth
|
||||
|
||||
访问：
|
||||
@@ -79,6 +91,7 @@ Earth 是公开页面，不需要登录。
|
||||
- 地球正常显示
|
||||
- 右侧图层控制可打开/关闭图层
|
||||
- 搜索可以查找海缆、卫星、算力中心、BGP 事件
|
||||
- 算力中心和 BGP 观测站详情卡可以自动采集并预览坐标候选；算力中心待定位气泡可以打开列表并保存候选
|
||||
- 鼠标拖动、滚轮缩放和缩放百分比提示正常工作
|
||||
- 设置面板可以切换巡航模式、日夜模式、卫星显示风格
|
||||
|
||||
@@ -176,6 +189,14 @@ http://localhost:3000/admin
|
||||
|
||||
这会让前端和后端监听局域网可访问地址。
|
||||
|
||||
注意：`--allow-lan` 只负责让 Planet 服务监听 `0.0.0.0`，不等于自动把 WSL 服务暴露到 Windows 局域网 IP。常见情况是：
|
||||
|
||||
- WSL 内 `localhost:3000` / `localhost:8000` 能访问
|
||||
- Windows 本机 `localhost:3000` / `localhost:8000` 能访问
|
||||
- 但手机或其他电脑访问 `http://<Windows局域网IP>:3000` 失败
|
||||
|
||||
这通常说明 Windows 端还缺少端口转发或防火墙放行。
|
||||
|
||||
如果访问失败，先在运行 Planet 的 shell 中检查：
|
||||
|
||||
```bash
|
||||
@@ -184,6 +205,16 @@ curl http://localhost:8000/health
|
||||
ss -ltnp | grep -E ':3000|:8000'
|
||||
```
|
||||
|
||||
如果确认 WSL 中已监听 `0.0.0.0:3000` 和 `0.0.0.0:8000`，但局域网 IP 仍不能访问，请在管理员 PowerShell 中配置 Windows 端转发和防火墙：
|
||||
|
||||
```powershell
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=3000 connectaddress=127.0.0.1 connectport=3000
|
||||
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8000 connectaddress=127.0.0.1 connectport=8000
|
||||
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 3000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000
|
||||
New-NetFirewallRule -DisplayName "WSL Planet 8000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8000
|
||||
```
|
||||
|
||||
## 9. 停止服务
|
||||
|
||||
```bash
|
||||
|
||||
@@ -16,12 +16,13 @@
|
||||
## Current Version
|
||||
|
||||
- `main` 当前主线历史推导到：`0.16.5`
|
||||
- `dev` 当前开发分支历史推导到：`0.48.0`
|
||||
- `dev` 当前开发分支历史推导到：`0.49.0`
|
||||
|
||||
## Timeline
|
||||
|
||||
| Version | Type | Branch | Commit | Summary |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `0.49.0` | feature | `dev` | `pending` | 新增位置解析 Pipeline、BGP/算力中心地理定位、Docs Gatekeeper、Earth 新闻栏与 Mobile 国家高亮 |
|
||||
| `0.48.0` | feature | `dev` | `pending` | 新增自定义源 REST/WebSocket 实时 mock 链路，完善 AIS 多源聚合/船舶 enrichment，并将 Earth 全球态势统计改为轻量 SQL 聚合 |
|
||||
| `0.47.0` | feature | `dev` | `pending` | 新增 AISStream WebSocket 船只采集器、多源 AIS 原始观测聚合、采集器状态配置、船型显示修正和文档规则解耦 |
|
||||
| `0.46.3` | bugfix | `dev` | `pending` | 优化 Starlink footprint 拖拽性能，避免旋转地球时重复重建覆盖网格，并恢复线缆点击呼吸动画 |
|
||||
|
||||
Reference in New Issue
Block a user