仓颉技术交流平台

gcoord（GIS坐标转换库）招募

发布人:仓颉技术交流平台官方
分类:地理信息 / GIS工具与坐标转换

为丰富仓颉语言在地理信息处理领域的生态，现招募有志于开源贡献的开发者，共同参与开发一款高性能、类型安全、符合工业级标准的坐标转换库。本项目参考主流GIS工具（如gcoord）的核心思想，但将完全基于仓颉语言的特性进行深度优化与功能扩展，致力于为开发者提供轻量级、多场景适配的地理数据处理解决方案。

等待接取
2025-11-20
5

悬赏内容

招募内容

一、项目核心目标​

开发符合工业级精度的GIS坐标转换库，实现以下能力：

  1. 坐标系互转​

    • 支持WGS84、GCJ-02、BD-09、CGCS2000、UTM等坐标系的无损双向转换​

    • 提供统一类型接口（CoordinateSystem<CRS: CoordinateReferenceSystem>）

  2. 几何对象处理​

    • 实现Point/Polyline/Polygon的批量坐标转换（≥10⁶点/秒@x86_64）

  3. 国际标准兼容​

    • 坐标系标识符遵循EPSG编码规范（如EPSG:4326）

    • 输入/输出格式支持GeoJSON RFC7946、WKT ISO 19125-1​

二、质量认证体系​

1. 算法精度要求​

指标

标准值

验证方式

单点转换误差

≤1e-7弧度

比照PROJ库v9.2结果

椭球体参数容差

WGS84与CGCS2000差异<1mm

国土资源部GNSS实测数据集

非线性变换可逆性

往返转换坐标偏移≤0.001米

国测局加密算法测试矩阵

2. 性能与健壮性​

场景

要求

单点转换延迟

≤0.3μs (i9-13900K @5.8GHz)

内存占用

零堆分配（纯栈操作）

模糊测试

通过≥10⁸次随机输入迭代（cj-fuzz）

异常处理

非法输入100%触发类型错误（非运行时异常）

3. 工程化标准​

// 代码质量示例要求  
module CoordinateTransformer requires  
    -- 类型系统约束  
    impl<CRS: CoordinateReferenceSystem> for CoordinateSystem<CRS>  
        where CRS.validate() -> bool,  
              CRS.toWGS84() -> CoordinateSystem<WGS84>;  

    -- 内存安全保证  
    @nogc @stackonly  
    fn transform_batch(points: [Point]^) -> [Point]^;

  • 编译检测：通过cj build --strict（零Warning）

  • 测试覆盖率：核心算法≥100%，工具链≥95%（LCOV报告）

  • 文档规范：所有公共API需包含@geo元数据标签及误差范围说明

三、交付物要求​

模块

必须包含组件

验收标准

核心转换引擎​

仿射变换/非线性变换/投影变换实现

通过PROJ一致性测试套件

几何处理层​

Point/Polyline/Polygon转换算子

处理10⁶点云数据误差<1cm

序列化扩展​

GeoJSON/WKT解析器

通过OGC标准测试用例

WebAssembly适配​

wasm32-unknown-unknown目标编译

浏览器端转换延迟≤1ms（Chrome）

四、协作与验证机制​

  1. 代码审查​

    • 所有PR需经2名GIS领域专家+1名仓颉语言核心开发者双审

    • 算法变更需附数值稳定性证明（如Kahan求和法误差分析）

  2. 持续集成​

    # 必需的CI流水线步骤  
- step: coordinate_fidelity_test  
  dataset: national_geodetic_survey/2025  
  max_error: 1e-7 rad  
- step: wasm_performance  
  target: chrome-headless  
  benchmark: transform_1e6_points < 300ms

  3. 权威认证​

    • 通过中国地理信息产业协会算法认证

    • 收录至仓颉语言标准工具链（需满足《仓颉标准库质量白皮书》第4.3章）

相关附件

暂无附件

质量认证要求

交付件

NO

交付件描述

备注

1

三方库源代码

源代码

2

三方库测试方案和用例

测试用例和文档

3

用户手册，API文档，设计文档，license文档

 资料和文档

验收标准

1.功能

  1. 三方库必须有明确的功能；

  2. 如果参考对标库移值开发，功能与参考三方库保持一致。

2.资料

  1. Readme：包含简介，软件架构，目录结构，下载安装（编译构建），接口说明，使用示例，约束限制，开源协议，参与贡献等内容；

  2. Changelog，三方库版本需包含基本的修改说明。

3.标准遵从性（可选），三方库实现需满足对应协议或行业标准，举例

  1. appquth：支持对OAuth 的PKCE扩展；

  2. icu4j：支持unicode标准库，通用字符集ISO/IEC 10646。

4.性能目标

  1. 性能敏感三方库接口运行性能持平对标三方库

5.开源协议遵从，必须包含License文件

  1. 放置合适的开源License协议，建议Apache License Version 2.0；

  2. 引用或参考开源三方库，需遵从开源协议。

6.网络安全要求

  1. 满足基础的网络安全红线及隐私要求，符合安全编码规范。

过程质量要求

指标分类

指标名称

指标要求

度量工具

牵引 OR Must

代码度量

平均文件代码行

≤300 LOC

CMetricsPlus，CJMetric

Must

总文件重复率

C/C++≤4%；相比开源不劣化

CMetricsPlus，CJMetric

Must

源文件重复率

C/C++≤4%；相比开源不劣化

CMetricsPlus，CJMetric

Must

平均函数或方法代码行*

≤30  LOC

CMetricsPlus，CJMetric

Must

总代码重复率

C/C++≤10%；相比开源不劣化

CMetricsPlus，CJMetric

Must

源文件代码重复率

C/C++≤10%；相比开源不劣化

CMetricsPlus，CJMetric

Must

平均圈复杂度

≤5；相比开源不劣化

CMetricsPlus，CJMetric

Must

冗余代码

“0” 【2】；

CMetricsPlus，CJMetric

Must

不安全函数

NA

CMetricsPlus，CJMetric

Must

静态检查

编译告警

“0” 【2】

Compile工具

牵引

通用静态告警

“0” 【2】

Pclint plus，CJLINT

Must

开发者测试

DT用例密度(个/KLOC)

> 40

手工

牵引 

DT代码语句覆盖率

>=85%

Gcov，cjcov

牵引

DT代码分支覆盖率

>=50%

Gcov，cjcov

牵引

未做DT文件数

0

手工

牵引

问题解决率

遗留问题DI

整体<10

Issue

牵引 

遗留致命缺陷数(0)

0

Issue

Must

累计缺陷解决率

85%

Issue

牵引 

软件开发

每日构建成功率

100%

CI

牵引

测试评估

测试缺陷密度（/KLOC）

5-9

人工

牵引

测试用例密度（个/KLOC）

20-40

人工

牵引

初验用例自动化率

100%

CIDA

牵引 

HLT自动化用例比率

【85%，95%】

CIDA

牵引 

开源第三方（含构建工具）

开源片段引用

0（除例外备案类）

FOSSBOT+人工

Must

可信构建

二进制一致性

0（含可澄清）

人工

Mus