仓颉技术交流平台

tile-lnglat-transform（经纬度坐标与瓦片坐标转换库）招募

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

为丰富仓颉编程语言的开源生态，特别是在地理信息系统领域的基础工具链，我们现启动一个公益性开源项目。本项目旨在基于参考项目 tile-lnglat-transform的核心功能与设计思想，使用仓颉语言重新设计并实现一个高性能、高可靠性的地理坐标转换库。 该库将精确实现经纬度坐标与地图瓦片坐标在不同缩放级别下的相互转换算法。项目的最终成果将作为一个独立的、高质量的仓颉语言开源库，贡献给开源社区，为未来基于仓颉语言开发的地图应用、空间数据分析和可视化项目提供坚实的技术基础。

等待接取
2025-11-20
4

悬赏内容

招募内容

一、 项目背景与目标详述

随着仓颉编程语言生态的快速发展，其在系统级软件、高性能计算等领域的潜力日益凸显。然而，在诸如地理信息系统等专业应用领域，其基础软件库仍待完善。本项目旨在填补这一空白，通过实现一个功能完备、性能卓越的坐标转换库，为未来基于仓颉语言的地图引擎、空间数据分析平台等应用提供核心支撑。

本项目要求交付物不仅功能正确，更需在代码质量、架构设计、测试覆盖率和文档完备性方面达到高标准，力求成为仓颉生态中的标杆性开源组件。

二、 详细功能规格与技术要求

1. 核心算法模块

交付库必须精确实现以下算法，并保证其在不同尺度下的计算精度。

功能模块

输入参数

输出结果

核心算法要求

经纬度 → 瓦片坐标​

longitude（经度）, latitude（纬度）, zoom（缩放级别）

tileX, tileY（瓦片坐标）

基于Web墨卡托投影（EPSG:3857），使用切片方案（Tiling Scheme）进行转换。需处理经度-180°至180°，纬度-85.06°至85.06°的有效范围。

瓦片坐标 → 经纬度​

tileX, tileY, zoom

north, south, east, west（瓦片四至范围经纬度）

返回指定瓦片的地理边界框（Bounding Box）。

经纬度 → 像素坐标​

longitude, latitude, zoom

pixelX, pixelY（在指定瓦片内的像素坐标）

用于精确定位瓦片内的具体像素位置。

像素坐标 → 经纬度​

pixelX, pixelY, tileX, tileY, zoom

longitude, latitude

上述过程的逆运算。

2. 支持的坐标系与参数

参数

说明

默认/要求

投影方式​

Web墨卡托投影（球形/椭球体）

首要支持球形墨卡托投影，代码结构应允许扩展其他投影。

瓦片大小​

单块瓦片的像素尺寸

默认为256x256像素，应设计为可配置参数。

初始分辨率​

在缩放级别0下，每像素代表的地图单位数。

根据地球周长和瓦片大小计算得出。

原点位置​

瓦片坐标系的原点。

支持左上角（TMS）和左下角（Google Maps/OSM）等多种规范，需明确实现并注明。

3. API 设计示例（伪代码风格）

库的接口设计应清晰、简洁且符合直觉。以下为期望的API风格示例：

// 模块： geo_transform
// 功能： 核心转换函数

// 将经纬度转换为指定缩放级别的瓦片坐标
pub fn lnglat_to_tile(longitude: f64, latitude: f64, zoom: u8) -> (i32, i32) {
    // 实现算法...
    // 返回： (tileX, tileY)
}

// 将瓦片坐标转换为其地理范围（西北角、东南角经纬度）
pub fn tile_to_lnglat_bounds(tileX: i32, tileY: i32, zoom: u8) -> Bounds {
    // Bounds 是一个结构体，包含 north, south, east, west 四个f64字段。
    // 实现算法...
}

// 结构体定义示例
pub struct Bounds {
    pub north: f64,
    pub south: f64,
    pub east: f64,
    pub west: f64
}

// 辅助函数：检查坐标是否在有效范围内
pub fn is_valid_lnglat(longitude: f64, latitude: f64) -> bool {
    // 实现范围检查...
}

三、 交付物与质量认证要求

1. 源代码质量

  • 架构清晰：​ 代码应模块化，将数学计算、投影逻辑、工具函数等分离。

  • 错误处理：​ 对非法输入（如超出范围的经纬度、缩放级别）应有明确的错误处理机制（如返回错误码或使用Result类型），避免程序崩溃。

  • 性能优化：​ 关键路径上的计算应进行优化，避免不必要的内存分配和重复计算。

2. 测试与验证标准

测试类型

覆盖率目标

验证方法

单元测试​

核心函数行覆盖率 ≥ 95%

使用仓颉语言的测试框架。测试案例需覆盖正常值、边界值（如国际日期变更线、极点附近）和异常值。

集成测试​

主要功能流程100%覆盖

模拟真实使用场景，例如连续进行“经纬度->瓦片->经纬度”的往返测试，并验证结果的误差在可接受范围内（例如1e-10度）。

基准验证​

关键算法100%交叉验证

将本库的输出与成熟库（如Proj4js、Python的mercantile）在相同输入下的输出进行比对，确保结果一致。

3. 文档完备性

  • API 文档：​ 所有公开函数、结构体必须有详细的注释，并能够通过文档生成工具（如类似cargo doc的工具）生成可浏览的API参考手册。

  • README.md：​ 必须包含：

    • 项目简介和快速入门指南。

    • 安装和构建说明。

    • 详尽的代码示例。

    • 指向完整API文档的链接。

  • CONTRIBUTING.md：​ 代码贡献指南。

4. 工程化标准

  • 构建系统：​ 提供标准、一键式的项目构建脚本。

  • 依赖管理：​ 清晰声明项目依赖（如有）。

  • 持续集成：​ 在AtomGit平台上配置CI流水线，实现提交代码后自动运行测试套件。

四、 项目验收流程

  1. 初步代码审查：​ 项目负责人将对提交的代码进行结构和质量审查。

  2. 功能验收测试：​ 运行开发者提供的全部测试案例，并执行额外的边界案例测试。

  3. 性能基准测试：​ 对核心函数的执行效率进行评估。

  4. 文档审核：​ 确认文档的准确性和易用性。

相关附件

暂无附件

质量认证要求

交付件

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