业务层面向对象底层引擎只认 proj 字符串。中间类型映射表藏着不少反直觉的坑。前言做坐标转换功能的工程师大概率都遇到过这种割裂业务层想要面向对象——一个坐标系就是一个对象里面有椭球、投影类型、中央子午线、加常数、七参数这些明确的字段底层引擎却只认字符串——比如 PROJ 系引擎你要喂给它的是一段projtmerc lon_0111 lat_00 k_01 ...这样的文本定义。于是所有的坐标转换工具都必然要解决同一个问题怎么把一棵结构化的坐标系对象翻译成一串底层引擎认得的投影定义再翻译回来。表面上这是个琐碎活实际上这里藏着一大堆看起来一样、用起来完全不同的投影陷阱。这套引擎要对接几十种投影类型靠的正是中间那张映射表来游刃有余地翻译。本篇就拆开讲讲这张表是怎么搭起来的。一、问题长什么样一个坐标系统对象大概长这样classCoordinateReferenceSystem{varellipsoid:Ellipsoid// 椭球长半轴、短半轴、名字varprojection:Projection// 投影类型、中央子午线、加常数、比例尺varsevenParam:SevenParam// 七参数平移、旋转、尺度varcode:Long// EPSG 编码varname:String// 坐标系统名称}而底层引擎要的是这样一串文本projtmerc lon_0111 lat_00 x_0500000 y_00 k_01 ellpsWGS84翻译工作分成两步对象 → proj 字符串用于把坐标送进引擎以及proj 字符串 → 对象用于把引擎结果还原成业务对象。第一步相对直观只要把字段拼进模板真正烧脑的是类型映射表——不同的投影类型proj 的写法天差地别。二、为什么类型映射这么难你可能以为把ProjectionType枚举值换成字符串就行。事实远没那么简单以下几个坑尤其典型坑一同一个投影参数名还不一样。同样是中央子午线普通投影用lon_0但斜轴墨卡托投影要用loncUTM 则根本没有lon_0而是用zone带号让引擎自己对齐中央子午线。代码里为此单独开了一条分支。when(projectType){PT_OBLIQUE_MERCATOR_RSO-deflonclon0 PT_UTM,PT_UTM_SOUTH-defzoneutmZone(lon0) PT_LONLAT,PT_GEOCENT-/* 无需经度 */else-deflon_0lon0 }坑二UTM 带号会吃掉你输入的中央子午线。PROJ 引擎在projutm模式下会自动对齐带号对应的中央子午线比如你输入 112它实际可能用 111。所以代码里要自己先算 UTM 带号保证双向一致不能把lon_0直接塞给 UTM。坑三兰勃特切圆锥与割圆锥用标准纬线区分。同样是lcc单标准纬线1SP和双标准纬线2SP的lat_1、lat_2写法不同而切圆锥在引擎里有个特殊要求——lat_0、lat_1相等才表示切圆锥否则会被当成割圆锥。于是代码里做了这样的归一化if(ptPT_LAMBERTlat10.0)lat1lat0// 1SP 切圆锥if(ptPT_LAMBERT_DUAL_LATlat10.0lat20.0)lat1lat0坑四尺度因子别乱设。切圆锥投影里lat_1 lat_2即切圆锥但有的引擎初始化时lat10会直接报错所以必须把lat0兜底填给lat1。正是这些看起来一样、实则不同的细节让一张类型映射表变成了最容易出 bug 的地方。类型映射表的难点不在拼字符串而在投影之间的差异。三、解法一张映射表 缓存句柄整个翻译工作被组织成几条清晰的路正向对象 → proj 字符串。先按投影类型查表得到 proj 主名再按类型补投影参数最后补椭球参数。椭球这一环还有个小优化——先尝试匹配已知椭球的名字如 WGS84、CGCS2000匹配不上才把长短半轴a、b直接写进去valguessguessWellKnownEllipsoid(ellipsoid.a,ellipsoid.b)if(guess!null)defellpsguess.name elsedefaellipsoid.a bellipsoid.b 反向proj 字符串 → 对象。反过来要读参数逐项把引擎给出的dlat_0、dlon_0、izone等数值回填到对象里。这里有个微妙点引擎返回的是引擎视角的参数名需要再映射回业务字段。缓存句柄。因为初始化一个坐标系句柄ProjHandle是有开销的代码用了一个 LRU 缓存按 EPSG 编码缓存句柄命中就直接复用避免反复初始化privatevalcacheLruCacheLong,ProjHandle(100)funcachedHandle(epsg:Long):ProjHandle?cache.get(epsg)?:createFromEpsg(epsg).also{cache.put(epsg,it)}命名特判。代码里还对 CGCS2000 系列做了专门处理——把引擎返回的 GRS 1980 椭球、China 2000之类的名字统一修正成业务侧约定的CGCS2000命名保证导出 WKT / JSON 时的名称与国内标准一致。这类命名对齐看似不涉及数学却是用户最直观感受到的差异。四、升华翻译表的工程价值投影类型 ↔ proj 字符串这套映射本质上是一种适配器模式的落地底层引擎是一种接口契约业务对象是另一种契约中间这层翻译让两边解耦。它的价值不止于此可扩展新增一种投影只需要在映射表加一条分支业务对象、引擎都不受影响。可反向同一张表支撑正向生成 proj与反向解析 proj两条路保证来回转换不漂移。可移植换个底层引擎只需要替换写参数 / 读参数这一层的实现对象模型基本不动。边界兜底对切/割圆锥、UTM 带号这类引擎会自作主张的边界情况用归一化逻辑主动兜住避免用户踩坑。如果哪天要重写可以把这张映射表抽象成投影定义器接口每种投影一个实现类用策略模式替代一长串when让每一种投影的拼参逻辑自洽、可单独测试。结论坐标系业务对象与底层 proj 字符串之间需要一层双向翻译适配。最难的不是拼字符串而是处理类型之间的差异参数名不同、UTM 自动对齐带号、兰勃特切/割圆锥区分等。用 LRU 缓存ProjHandle能显著减少坐标系句柄的重复初始化开销。CGCS2000 等国内坐标系需要命名特判统一导出名称与国内标准一致。这层映射是适配器模式的典型应用抽象成每种投影一个定义器会更优雅、更可测试。你在对接 PROJ 或其它坐标引擎时被哪类投影参数坑过欢迎在评论区交流。关键词标签#Android#坐标转换#PROJ#投影#EPSG#适配器模式#GIS#CGCS2000 
长河君 · 2026/9/24 5:15:22 · 阅读 1.2k Android 一套代码扛几十种坐标系？投影类型到 proj 字符串翻译
业务层面向对象底层引擎只认 proj 字符串。中间类型映射表藏着不少反直觉的坑。前言做坐标转换功能的工程师大概率都遇到过这种割裂业务层想要面向对象——一个坐标系就是一个对象里面有椭球、投影类型、中央子午线、加常数、七参数这些明确的字段底层引擎却只认字符串——比如 PROJ 系引擎你要喂给它的是一段projtmerc lon_0111 lat_00 k_01 ...这样的文本定义。于是所有的坐标转换工具都必然要解决同一个问题怎么把一棵结构化的坐标系对象翻译成一串底层引擎认得的投影定义再翻译回来。表面上这是个琐碎活实际上这里藏着一大堆看起来一样、用起来完全不同的投影陷阱。这套引擎要对接几十种投影类型靠的正是中间那张映射表来游刃有余地翻译。本篇就拆开讲讲这张表是怎么搭起来的。一、问题长什么样一个坐标系统对象大概长这样classCoordinateReferenceSystem{varellipsoid:Ellipsoid// 椭球长半轴、短半轴、名字varprojection:Projection// 投影类型、中央子午线、加常数、比例尺varsevenParam:SevenParam// 七参数平移、旋转、尺度varcode:Long// EPSG 编码varname:String// 坐标系统名称}而底层引擎要的是这样一串文本projtmerc lon_0111 lat_00 x_0500000 y_00 k_01 ellpsWGS84翻译工作分成两步对象 → proj 字符串用于把坐标送进引擎以及proj 字符串 → 对象用于把引擎结果还原成业务对象。第一步相对直观只要把字段拼进模板真正烧脑的是类型映射表——不同的投影类型proj 的写法天差地别。二、为什么类型映射这么难你可能以为把ProjectionType枚举值换成字符串就行。事实远没那么简单以下几个坑尤其典型坑一同一个投影参数名还不一样。同样是中央子午线普通投影用lon_0但斜轴墨卡托投影要用loncUTM 则根本没有lon_0而是用zone带号让引擎自己对齐中央子午线。代码里为此单独开了一条分支。when(projectType){PT_OBLIQUE_MERCATOR_RSO-deflonclon0 PT_UTM,PT_UTM_SOUTH-defzoneutmZone(lon0) PT_LONLAT,PT_GEOCENT-/* 无需经度 */else-deflon_0lon0 }坑二UTM 带号会吃掉你输入的中央子午线。PROJ 引擎在projutm模式下会自动对齐带号对应的中央子午线比如你输入 112它实际可能用 111。所以代码里要自己先算 UTM 带号保证双向一致不能把lon_0直接塞给 UTM。坑三兰勃特切圆锥与割圆锥用标准纬线区分。同样是lcc单标准纬线1SP和双标准纬线2SP的lat_1、lat_2写法不同而切圆锥在引擎里有个特殊要求——lat_0、lat_1相等才表示切圆锥否则会被当成割圆锥。于是代码里做了这样的归一化if(ptPT_LAMBERTlat10.0)lat1lat0// 1SP 切圆锥if(ptPT_LAMBERT_DUAL_LATlat10.0lat20.0)lat1lat0坑四尺度因子别乱设。切圆锥投影里lat_1 lat_2即切圆锥但有的引擎初始化时lat10会直接报错所以必须把lat0兜底填给lat1。正是这些看起来一样、实则不同的细节让一张类型映射表变成了最容易出 bug 的地方。类型映射表的难点不在拼字符串而在投影之间的差异。三、解法一张映射表 缓存句柄整个翻译工作被组织成几条清晰的路正向对象 → proj 字符串。先按投影类型查表得到 proj 主名再按类型补投影参数最后补椭球参数。椭球这一环还有个小优化——先尝试匹配已知椭球的名字如 WGS84、CGCS2000匹配不上才把长短半轴a、b直接写进去valguessguessWellKnownEllipsoid(ellipsoid.a,ellipsoid.b)if(guess!null)defellpsguess.name elsedefaellipsoid.a bellipsoid.b 反向proj 字符串 → 对象。反过来要读参数逐项把引擎给出的dlat_0、dlon_0、izone等数值回填到对象里。这里有个微妙点引擎返回的是引擎视角的参数名需要再映射回业务字段。缓存句柄。因为初始化一个坐标系句柄ProjHandle是有开销的代码用了一个 LRU 缓存按 EPSG 编码缓存句柄命中就直接复用避免反复初始化privatevalcacheLruCacheLong,ProjHandle(100)funcachedHandle(epsg:Long):ProjHandle?cache.get(epsg)?:createFromEpsg(epsg).also{cache.put(epsg,it)}命名特判。代码里还对 CGCS2000 系列做了专门处理——把引擎返回的 GRS 1980 椭球、China 2000之类的名字统一修正成业务侧约定的CGCS2000命名保证导出 WKT / JSON 时的名称与国内标准一致。这类命名对齐看似不涉及数学却是用户最直观感受到的差异。四、升华翻译表的工程价值投影类型 ↔ proj 字符串这套映射本质上是一种适配器模式的落地底层引擎是一种接口契约业务对象是另一种契约中间这层翻译让两边解耦。它的价值不止于此可扩展新增一种投影只需要在映射表加一条分支业务对象、引擎都不受影响。可反向同一张表支撑正向生成 proj与反向解析 proj两条路保证来回转换不漂移。可移植换个底层引擎只需要替换写参数 / 读参数这一层的实现对象模型基本不动。边界兜底对切/割圆锥、UTM 带号这类引擎会自作主张的边界情况用归一化逻辑主动兜住避免用户踩坑。如果哪天要重写可以把这张映射表抽象成投影定义器接口每种投影一个实现类用策略模式替代一长串when让每一种投影的拼参逻辑自洽、可单独测试。结论坐标系业务对象与底层 proj 字符串之间需要一层双向翻译适配。最难的不是拼字符串而是处理类型之间的差异参数名不同、UTM 自动对齐带号、兰勃特切/割圆锥区分等。用 LRU 缓存ProjHandle能显著减少坐标系句柄的重复初始化开销。CGCS2000 等国内坐标系需要命名特判统一导出名称与国内标准一致。这层映射是适配器模式的典型应用抽象成每种投影一个定义器会更优雅、更可测试。你在对接 PROJ 或其它坐标引擎时被哪类投影参数坑过欢迎在评论区交流。关键词标签#Android#坐标转换#PROJ#投影#EPSG#适配器模式#GIS#CGCS2000