为何GIS栅格处理工具PROJ的配套数据体积达550MB？

跨基准坐标转换并非纯理想数学逻辑，这才是配套数据体积大的核心原因 #

很多人对坐标转换的认知存在偏差：同个基准下，把椭球上的经纬度换算成平面投影坐标（比如UTM、墨卡托）的过程，确实只是固定的三角函数运算，这部分核心代码的体积加起来还不到1MB。但真正工程可用的坐标转换，绕不开跨地理基准的偏差修正，这部分就是550MB配套数据的主要来源：

• 不同坐标系对应的是不同的地表实测拟合结果：我们熟悉的WGS84、北京54、西安80、CGCS2000，虽然对应的理想参考椭球参数差异不大，但受板块运动、重力场分布、历史测绘误差影响，同一个实际点位在不同基准下的坐标差可达几十米甚至上百米。这种偏差根本不可能靠固定的七参数仿射变换实现全区域高精度适配，全球上万个独立测绘区域，都需要存储公里级分辨率的逐点偏差修正格网，这些二进制格网文件占了配套数据的近80%体积。
• 兼容历史测绘资产的需要：PROJ需要适配从19世纪三角测量时代的老旧局部坐标系，到当代实时更新的地壳形变模型，每个坐标系对应的官方转换参数、历史版本修正规则、甚至曾经出现过的参数偏差修正记录，都需要完整留存，避免老测绘成果转换时出现大的结果误差。
• 动态形变模型的存储：因为板块运动，同一坐标在WGS84框架下的实测位置，每20年的偏移就能达到30-50厘米，这些随时间变化的板块运动速率模型、对流层延迟修正参数，也需要作为配套数据存放。

很多人容易存在的认知误区是，投影转换全程都是纯公式计算，实际上跨基准的精度修正根本没有全局通用的纯数学公式，必须依赖实测格网数据才能达到工程要求的精度。

投影转换的GPU加速：技术可行，但应用场景存在明确边界 #

从计算原理上，逐点的坐标转换完全可以依托GPU的并行计算能力实现，但实际工程落地的价值非常有限：

• 单条坐标的转换计算量极低：哪怕是带格网插值的跨基准转换，单条坐标的运算仅涉及十几次浮点运算和一次邻域插值，CPU处理百万级点位的耗时仅为几毫秒，而GPU启动核函数的固定开销都远大于单批计算的收益，绝大多数点级转换场景用GPU完全是性能浪费。
• 唯一能体现GPU优势的场景，是超大规模栅格数据的批量重投影：比如数亿像素分辨率的卫星栅格影像，做全幅逐像素的坐标映射、重采样操作时，把独立的像素计算批量丢给GPU并行处理，速度可以比CPU集群快几十倍。目前主流的GDAL栅格处理模块已经集成了基于CUDA的加速接口，底层就是复用PROJ的转换逻辑实现的。
• 需要明确的是：哪怕用GPU做加速，那些占体积的格网修正数据还是需要完整加载，不会因为计算方式从CPU换为GPU就减少数据体积。

内容的提问来源于stack exchange，提问作者Loki the great