坐标系转换

1. 大地测量学 (Geodesy)

大地测量学是一门量测和描绘地球表面的学科,也包括确定地球重力场和海底地形。

1.1 大地水准面 (geoid)

大地水准面是海洋表面在排除风力、潮汐等其它影响,只考虑重力和自转影响下的形状,这个形状延伸过陆地,生成一个密闭的曲面。虽然我们通常说地球是一个球体或者椭球体,但是由于地球引力分布不均(因为密度不同等原因),大地水准面是一个不规则的光滑曲面。虽然不规则,但是可以近似地表示为一个椭球体,这个椭球体被 称为参考椭球体(Reference ellipsoid)。大地水准面相对于参考椭球体的高度被称为 Undulation of the geoid 。这个波动并不是非常大,最高在冰岛为85m,最低在印度南部为 −106 m,一共不到200m。下图来自维基百科,表示 EGM96 geoid 下不同地区的 Undulation。

1.2 参考椭球体(Reference ellipsoid)

参考椭球体(Reference ellipsoid)是一个数学上定义的地球表面,它近似于大地水准面。因为是几何模型,可以用长半轴、短半轴和扁率来确定。我们通常所说的经度、纬度以及高度都以此为基础。

一方面,我们对地球形状的测量随着时间迁移而不断精确,另一方面,因为大地水准面并不规则,地球上不同地区往往需要使用不同的参考椭球体,来尽可能适合当地的大地水准面。历史上出现了很多不同的参考椭球体,很多还仍然在使用中。国内过去使用过“北京54”和“西安90”两个坐标系,其中北京54使用的是克拉索夫斯基(Krasovsky)1940的参考椭球,西安80使用的是1975年国际大地测量与地球物理联合会第16届大会推荐的参考椭球。当前世界范围内更普遍使用的是WGS所定义的参考椭球。

2. 坐标系(coordinate system)

有了参考椭球体这样的几何模型后,就可以定义坐标系来进行描述位置,测量距离等操作,使用相同的坐标系,可以保证同样坐标下的位置是相同的,同样的测量得到的结果也是相同的。通常有两种坐标系 地理坐标系(geographic coordinate systems) 和 投影坐标系(projected coordinate systems)。

2.1 地理坐标系(Geographic coordinate system)

地理坐标系一般是指由经度、纬度和高度组成的坐标系,能够标示地球上的任何一个位置。前面提到了,不同地区可能会使用不同的参考椭球体,即使是使用相同的椭球体,也可能会为了让椭球体更好地吻合当地的大地水准面,而调整椭球体的方位,甚至大小。这就需要使用不同的大地测量系统(Geodetic datum)来标识。因此,对于地球上某一个位置来说,使用不同的测量系统,得到的坐标是不一样的。我们在处理地理数据时,必须先确认数据所用的测量系统。事实上,随着我们对地球形状测量的越来越精确,北美使用的 NAD83 基准和欧洲使用的 ETRS89 基准,与 WGS 84 基准是基本一致的,甚至我国的 CGCS2000 与WGS84之间的差异也是非常小的。但是差异非常小,不代表完全一致,以 NAD83 为例,因为它要保证北美地区的恒定,所以它与 WGS84 之间的差异在不断变化,对于美国大部分地区来说,每年有1-2cm的差异。

2.2 投影坐标系(Projected coordinate systems)

地理坐标系是三维的,我们要在地图或者屏幕上显示就需要转化为二维,这被称为投影(Map projection)。显而易见的是,从三维到二维的转化,必然会导致变形和失真,失真是不可避免的,但是不同投影下会有不同的失真,这让我们可以有得选择。常用的投影有等矩矩形投影(Platte Carre)和墨卡托投影(Mercator),下图来自Mercator vs. well…not Mercator (Platte Carre),生动地说明了这两种投影下的失真:

左图表示地球球面上大小相同的圆形,右上为墨卡托投影,投影后仍然是圆形,但是在高纬度时物体被严重放大了。右下为等距投影,物体的大小变化不是那么明显,但是图像被拉长了。Platte Carre 投影因为在投影上有扭曲,并不适合于航海等活动,但是因为坐标与像素之间的对应关系十分简单,非常适合于栅格图的展示,Platte Carre 投影是很多GIS 软件的默认投影。

需要注意的是,对于墨卡托投影来说,越到高纬度,大小扭曲越严重,到两极会被放到无限大,所以,墨卡托投影无法显示极地地区。下图来自维基百科,可以看到墨卡托投影下每个国家的大小和实际大小的差异。但是 conformality(正形性) 和 straight rhumb lines 这两个特点,让它非常适合于航海导航。

3. 对于 Web Map 开发人员的意义

对于 Web Map 开发人员来说,最熟悉的应该是EPSG:4326 (WGS84) and EPSG:3857(Pseudo-Mercator),这又是啥呢?

3.1 EPSG:4326 (WGS84)

前面说了 WGS84 是目前最流行的地理坐标系统。在国际上,每个坐标系统都会被分配一个 EPSG 代码,EPSG:4326 就是 WGS84 的代码。GPS是基于WGS84的,所以通常我们得到的坐标数据都是WGS84的。一般我们在存储数据时,仍然按WGS84存储。

3.2 EPSG:3857 (Pseudo-Mercator)

伪墨卡托投影,也被称为球体墨卡托,Web Mercator。它是基于墨卡托投影的,把 WGS84坐标系投影到正方形。我们前面已经知道 WGS84 是基于椭球体的,但是伪墨卡托投影把坐标投影到球体上,这导致两极的失真变大,但是却更容易计算。这也许是为什么被称为”伪“墨卡托吧。另外,伪墨卡托投影还切掉了南北85.051129°纬度以上的地区,以保证整个投影是正方形的。因为墨卡托投影等正形性的特点,在不同层级的图层上物体的形状保持不变,一个正方形可以不断被划分为更多更小的正方形以显示更清晰的细节。很明显,伪墨卡托坐标系是非常显示数据,但是不适合存储数据的,通常我们使用WGS84 存储数据,使用伪墨卡托显示数据。

Web Mercator 最早是由 Google 提出的,当前已经成为 Web Map 的事实标准。但是也许是由于上面”伪“的原因,最初 Web Mercator 被拒绝分配EPSG 代码。于是大家普遍使用 EPSG:900913(Google的数字变形) 的非官方代码来代表它。直到2008年,才被分配了EPSG:3785的代码,但在同一年没多久,又被弃用,重新分配了 EPSG:3857 的正式代码,使用至今。

4. 转换神器:Proj4js

Proj4js is a JavaScript library to transform point coordinates from one coordinate system to another, including datum transformations. Originally a port of PROJ (then known as PROJ.4) and GCTCP C (Archive) it is a part of the MetaCRS group of projects. (Proj4js是一个JavaScript类库,其主要功能就是将点坐标从一个坐标系转换为另一个坐标系。)

github: https://github.com/proj4js/proj4js

proj4参数详解

有关各种投影的参数定义,可参考https://epsg.io/ 或者 http://spatialreference.org 如果已有定义,可搜索并查看其投影参数。如果没有定义,需要用户自定义投影,可通过defs 定义 EPSGCODE来创建投影,defs 内容为参考投影参数:分别包括名称、投影、转换到 WGS84 坐标系(三参数、七参数)、椭球长半轴、扁率、原点纬线、中央经线、两条标准纬线、东偏移量、北偏移量和单位等。 比如从 https://epsg.io 网站中获得EPSG:3395的WKT描述:

或者从 http://spatialreference.org/ref/epsg/3395/proj4/ 网站可以获得EPSG:3395的投影参数: +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs

proj4常用定义参数:

+proj 投影坐标系统名称 +a 椭球体长半轴长度 +alpha 用于斜墨卡托和其它几个可能的投影 +axis 轴方向 +b 椭球体短半轴长度 +datum 基准面名 +ellps 椭球体名 +k 比例因子(old name) +k_0 比例因子(new name) +lat_0 维度起点 +lat_1 标准平行纬线第一条 +lat_2 标准平行纬线第二条 +lat_ts 有效纬度范围 +lon_0 中央经线 +lonc 经度用于斜墨卡托和其它几个可能的投影 +pm 备用本初子午线 +proj 投影名 +south 表示南半球UTM区域 +to_meter 乘数,转换地图单位为1.0m +towgs84 3或7参数基准面转换 +units meters(米), US survey feet(美国测量英尺),等. +vto_meter 垂直变换为米. +vunits 垂直单位. +x_0 东伪偏移 +y_0 北伪偏移 +zone UTM区域

转换流程(demo村庄转换流程)

根据航拍得到的村庄模型外,还可获得metadata.xml

<?xml version="1.0" encoding="utf-8"?>
<ModelMetadata version="1">
    <!--Spatial Reference System-->
    <SRS>EPSG:4549</SRS>
    <!--Origin in Spatial Reference System-->
    <SRSOrigin>350424,2933384,0</SRSOrigin>
    <Texture>
        <ColorSource>Visible</ColorSource>
    </Texture>
</ModelMetadata>
  • SRS表示所使用的坐标系
  • SRSOrigin表示对应的坐标。

通过使用proj4js将 ESPG:4549 转换为 WGS84、EPSG:3857 (Pseudo-Mercator)

Mercator直接与Creator坐标系相对应

根据Creator里的虚拟坐标系 加上虚拟坐标原点的 Mercator 坐标,再转为所需的WGS84(即经纬度)便可实现坐标转换。

转换WGS84、GCJ02、BD09坐标,解决百度高德坐标偏移

https://www.imooc.com/article/details/id/23512

做过地图相关开发的同学肯定会遇到这样一个问题:同样的经纬度坐标,在百度地图和高德地图上位置不一样。

关于坐标系

我们通常用经纬度来表示一个地理位置,但是由于一些原因,我们从不同渠道得到的经纬度信息可能并不是在同一个坐标系下。

  • 高德地图、腾讯地图以及谷歌中国区地图使用的是GCJ-02坐标系
  • 百度地图使用的是BD-09坐标系
  • 底层接口(HTML5 Geolocation或ios、安卓API)通过GPS设备获取的坐标使用的是WGS-84坐标系

不同的坐标系之间可能有几十到几百米的偏移,所以在开发基于地图的产品,或者做地理数据可视化时,我们需要修正不同坐标系之间的偏差。

WGS-84 - 世界大地测量系统

WGS-84(World Geodetic System, WGS)是使用最广泛的坐标系,也是世界通用的坐标系,GPS设备得到的经纬度就是在WGS84坐标系下的经纬度。通常通过底层接口得到的定位信息都是WGS84坐标系。

GCJ-02 - 国测局坐标

GCJ-02(G-Guojia国家,C-Cehui测绘,J-Ju局),又被称为火星坐标系,是一种基于WGS-84制定的大地测量系统,由中国国测局制定。此坐标系所采用的混淆算法会在经纬度中加入随机的偏移。

国家规定,中国大陆所有公开地理数据都需要至少用GCJ-02进行加密,也就是说我们从国内公司的产品中得到的数据,一定是经过了加密的。绝大部分国内互联网地图提供商都是使用GCJ-02坐标系,包括高德地图,谷歌地图中国区等。

导航电子地图在公开出版、销售、传播、展示和使用前,必须进行空间位置技术处理。— GB 20263―2006《导航电子地图安全处理技术基本要求》,4.1

BD-09 - 百度坐标系

BD-09(Baidu, BD)是百度地图使用的地理坐标系,其在GCJ-02上多增加了一次变换,用来保护用户隐私。从百度产品中得到的坐标都是BD-09坐标系。

解决方案

百度地图以及高德地图都提供了一些方法来转换不同坐标系下的坐标,但是它们都需要进行网络请求,性能很差。 在春节假期时,我做了一个库gcoord来做这些事。

gcoord

gcoord主要解决了两个问题:

  • 能将坐标在不同坐标系下相互转换
  • 能够处理GeoJSON GeoJSON是地理行业一种通用的数据格式,它本质上就是JSON,不过对字段有一些约定。

gcoord使用起来非常简单

例如从手机的GPS得到一个经纬度坐标,需要将其展示在百度地图上,则可以通过gcoord将当前坐标从WGS-84坐标系转换为BD-09坐标系


    var result = gcoord.transform(
        [116.403988,39.914266],  // 经纬度坐标
        gcoord.WGS84,   // 当前坐标系
        gcoord.BD09);   // 目标坐标系
    console.log( result );  // [ 116.41661560068297, 39.92196580126834 ]

详细的使用方式请查看 gcoord的文档

results matching ""

    No results matching ""