2024年3月11日发(作者：慕盼晴)

Google map地图坐标系

Google map地图坐标系部分：【转自/e/

童杨辉的博客】

中国网络有一天没一天的。还是全文转过来

——-分割线—–以下是主要内容——

Google Maps地图投影全解析

Google Maps、Virtual Earth等网络地理所使用的地图投影，常被称作Web

Mercator或Spherical Mercator，它与常规墨卡托投影的主要区别就是把地球

模拟为球体而非椭球体。建议先对地图投影知识做一个基本的了解，《地图投影

为什么》。

什么是墨卡托投影？

墨卡托(Mercator)投影，又名”等角正轴圆柱投影”，荷兰地图学家墨卡托

（Mercator）在1569年拟定，假设地球被围在一个中空的圆柱 里，其赤道与圆

柱相接触，然后再假想地球中心有一盏灯，把球面上的图形投影到圆柱体上，再

把圆柱体展开，这就是一幅标准纬线为零度（即赤道）的”墨卡托投 影”绘制

出的世界地图。从球到平面，肯定有个转换公式，这里就不再罗列。

Google们为什么选择墨卡托投影？

墨卡托投影的”等角”特性，保证了对象的形状的不变行，正方形的物体投影后

不会变为长方形。”等角”也保证了方向和相互位置的正确性，因此在航海和航

空中常常应用，而Google们在计算人们查询地物的方向时不会出错。

墨卡托投影的”圆柱”特性，保证了南北（纬线）和东西（经线）都是平行直线，

并且相互垂直。而且经线间隔是相同的，纬线间隔从标准纬线（此处是赤道，也

可能是其他纬线）向两级逐渐增大。

但是，”等角”不可避免的带来的面积的巨大变形，特别是两极地区，明显的如

格陵兰岛比实际面积扩大了N倍。不过要是去两极地区探险或可靠的同志们，一

般有更详细的资料，不会来查看网络地图的，这个不要紧。

为什么是圆形球体，而非椭球体？

这说来简单，仅仅是由于实现的方便，和计算上的简单，精度理论上差别0.33%

之内，特别是比例尺越大，地物更详细的时候，差别基本可以忽略。

Web墨卡托投影坐标系：

以整个世界范围，赤道作为标准纬线，本初子午线作为中央经线，两者交点为坐

标原点，向东向北为正，向西向南为负。

X轴：由于赤道半径为6378137米，则赤道周长为2*PI*r = 20037508.3427892，

因此X轴的取值范围：[-20037508.3427892,20037508.3427892]。

Y轴：由墨卡托投影的公式可知，同时上图也有示意，当纬度φ接近两极，即

90°时，y值趋向于无穷。这是那些”懒惰的工程师”就把Y轴的取值范围也限

定在[-20037508.3427892,20037508.3427892]之间，搞个正方形。

懒人的好处，众所周知，事先切好静态图片，提高访问效率云云。俺只是告诉你

为什么会是这样子。因此在投影坐标系（米）下的范围是：最小

(-20037508.3427892, -20037508.3427892 )到最大 (20037508.3427892,

20037508.3427892)。

对应的地理坐标系:

按道理，先讲地理坐标系才是，比如球体还是椭球体是地理坐标系的事情，和墨

卡托投影本关联不大。简单来说，投影坐标系(PROJCS)是平面坐标系，以米 为

单位；而地理坐标系(GEOGCS)是椭球面坐标系，以经纬度为单位。具体可参考《坐

标系、坐标参照系、坐标变换、投影变换》。

经度：这边没问题，可取全球范围：[-180,180]。

纬度：上面已知，纬度不可能到达90°，懒人们为了正方形而取的

-20037508.3427892，经过反计算，可得到纬度 85.59。因此纬度

取值范围是[-85.59，85.59]。其余的地区怎 么办？

没事，企鹅们不在乎。

因此，地理坐标系（经纬度）对应的范围是：最小(-180,-85.59)，

最大(180, 85.59)。至于其中的Datum、坐标转换等就不再多言。

相关坐标计算：

关于Google Maps等的组织方式——地图瓦片金字塔，估计我在这里重复一遍这

玩意，怕也是没人看了。尽管原理都一样，但具体到写不同厂商不同数据源的代

码时，你会发 现，可缩放级别数不一样，最小级别不一样，编码方式不一样，

比如Google的QRST，微软的四叉树，OSGeo的TMS等。

然而，你或许也不必这么麻烦，因为这些算法在网络上早已遍布朝野，你尽可从

他人博客中获取，或是从开源软件里学习。这本身都不是秘密，微软自己也是公

布的。

《Tiles à la Google Maps》 用交互性地方式可得到任一Tile的边界范围，各

种流行编码方式等。该页面的链接都非常有价值，部分也是本文写作的重要参考。

作者用python完成了下 列坐标之间转换算法：经纬度（出现在KML中的坐标，

WMS的BBOX参数等），平面坐标XY（米，Web Mercator投影坐标系），金字塔

的XYZ（即X轴的位置，Y轴的位置，和缩放级别ZoomLevel），每个Tile的编

码Key值（QRST或 0123等）。转换时，还需要注意两个概念，Ground Resolution

和Map Scale。

Ground Resolution，地面分辨率，类似Spatial Resolution（空间分辨率），

我们这里主要关注用象元(pixel size)表示的形式：一个像素(pixel)代表的地

面尺寸(米)。以Virtual Earth为例，Level为1时，图片大小为512*512（4

个Tile），那么赤道空间分辨率为：赤道周长/512。其他纬度的空间分辨率则

为纬度 圈长度/512，极端的北极则为0。Level为2时，赤道的空间分辨率为 赤

道周长/1024，其他纬度为纬度圈长度1024。很明显，Ground Resolution取决

于两个参数，缩放级别Level和纬度latitude ，Level决定像素的多少，latitude

决定地面距离的长短。地面分辨率的公式为，单位：米/像素：

ground resolution = (cos(latitude * pi/180) * 2 * pi * 6378137 meters)

/ (256 * 2levelpixels)

Map Scale，即地图比例尺，小学知识，图上距离比实地距离，两者单位一般都

是米。在Ground Resolution的计算中，由Level可得到图片的像素大小，那么

需要把其转换为以米为单位的距离，涉及到DPI（dot per inch），暂时可理解

为类似的PPI（pixelper inch），即每英寸代表多少个像素。256 * 2level / DPI

即得到相应的英寸inch，再把英寸inch除以0.0254转换为米。实地距离仍旧

是：cos(latitude * pi/180) * 2 * pi * 6378137 meters; 因此比例尺的公式

为，一般都化为1：XXX，无单位：

map scale = 256 * 2level / screen dpi / 0.0254 / (cos(latitude * pi/180)

* 2 * pi * 6378137)

= 1 : (cos(latitude * pi/180) * 2 * pi * 6378137 * screen dpi) / (256 *

2level * 0.0254)

其实，Map Scale 和 Ground Resolution存在对应关系，毕竟都和实地距离相

关联，两者关系：map scale = 1 : ground resolution * screen dpi / 0.0254

meters/inch

《Virtual Earth Tile System》列举了Virtual Earth在赤道上，Level、像素

数、地面分辨率、地图比例尺的对应关系，同时本文也简单介绍了Mercator投

影和上述两个概念，推荐。

此外，《Addressing Google Maps image tiles》应用程序，输入经纬度和缩放

级别，即可缩放到相应的Google Maps位置，而且可以显示出查找过程的QRST。

JavaScript实现的算法，也可以抓下来和《Tiles à la Google Maps》对比下，

从经纬度到到Tile编码的转换。

WKT形式表示

Google Maps和Virtual Earth等的流行程度不用多讲，然而他们所使用的Web

Mercator或Spherical Mercator在很长一段时间内并没有被EPSG的投影数据

库所接纳。EPSG认为它不能算作科学意义上的投影，所以只是给了一个 EPSG：

900913的标号（SRID），这个标号游离在EPSG常规标号范围之外。（EPSG、SRID

是什么？参见《EPSG 、SRID》。）

到了2008年5月（据SharpGIS同学）， EPSG恍然明白，不管椭球体还是球体，

其实都是对地球的模拟，只是精确程度上的差别，没有本质上的不同。或者是不

得不接受广泛的事实标准，接纳了这个投 影，定义投影坐标系PROJCS的名字

为”Popular Visualisation CRS / Mercator”，SRID为EPSG:3785；地理坐标

系GEOGCS的名字为”Popular Visualisation CRS”，SRID为”EPSG:4055″。

这些标号已经进入”正常范围”。（PS：这个Visualisation 是英式英语写法？）

PROJCS 的WKT《Well Known Text》写法如下，GEOGCS、Datum等的WKT表示参

见《Spherical/Web Mercator: EPSG code 3785》。附带说一句，Web Mercator

在ESRI公司的编号（ESRI叫它Well Known ID？）暂时是102113，或许偶尔用

得到。

PROJCS["Popular Visualisation CRS / Mercator",

GEOGCS["Popular Visualisation CRS",

DATUM["Popular_Visualisation_Datum",

SPHEROID["Popular Visualisation Sphere",6378137,0,

AUTHORITY["EPSG","7059"]],

TOWGS84[0,0,0,0,0,0,0],

AUTHORITY["EPSG","6055"]],

PRIMEM["Greenwich",0,

AUTHORITY["EPSG","8901"]],

UNIT["degree",0.94328,

AUTHORITY["EPSG","9122"]],

AUTHORITY["EPSG","4055"]],

UNIT["metre",1,

AUTHORITY["EPSG","9001"]],

PROJECTION["Mercator_1SP"],

PARAMETER["central_meridian",0],

PARAMETER["scale_factor",1],

PARAMETER["false_easting",0],

PARAMETER["false_northing",0],

AUTHORITY["EPSG","3785"],

AXIS["X",EAST],

AXIS["Y",NORTH]]

附记：这个问题算是老问题，费这么多时间，主要就是分享，毕竟自己还算是相

当明白。也是看见有人不懂乱说，写篇文章纠正下。当然谁都会犯错误，包括我

这篇 是否100%正确，你也可以质疑。起这个题目其实不是本意，因为它不科学，

甚至EPSG的INFORMATION_SOURCE字段写的都是 Microsoft，只不过国内Google

更火些，SEO一下。

这篇文章除了参考文中所列链接外， Microsoft、Google、EPSG、OGC等组织相

关的说明外，Charlie Savage、SharpGIS、Nelson John等博客也是非常重要的

来源，在此致以谢意。

2024年3月11日发(作者：慕盼晴)

Google map地图坐标系

Google map地图坐标系部分：【转自/e/

童杨辉的博客】

中国网络有一天没一天的。还是全文转过来

——-分割线—–以下是主要内容——

Google Maps地图投影全解析

Google Maps、Virtual Earth等网络地理所使用的地图投影，常被称作Web

Mercator或Spherical Mercator，它与常规墨卡托投影的主要区别就是把地球

模拟为球体而非椭球体。建议先对地图投影知识做一个基本的了解，《地图投影

为什么》。

什么是墨卡托投影？

墨卡托(Mercator)投影，又名”等角正轴圆柱投影”，荷兰地图学家墨卡托

（Mercator）在1569年拟定，假设地球被围在一个中空的圆柱 里，其赤道与圆

柱相接触，然后再假想地球中心有一盏灯，把球面上的图形投影到圆柱体上，再

把圆柱体展开，这就是一幅标准纬线为零度（即赤道）的”墨卡托投 影”绘制

出的世界地图。从球到平面，肯定有个转换公式，这里就不再罗列。

Google们为什么选择墨卡托投影？

墨卡托投影的”等角”特性，保证了对象的形状的不变行，正方形的物体投影后

不会变为长方形。”等角”也保证了方向和相互位置的正确性，因此在航海和航

空中常常应用，而Google们在计算人们查询地物的方向时不会出错。

墨卡托投影的”圆柱”特性，保证了南北（纬线）和东西（经线）都是平行直线，

并且相互垂直。而且经线间隔是相同的，纬线间隔从标准纬线（此处是赤道，也

可能是其他纬线）向两级逐渐增大。

但是，”等角”不可避免的带来的面积的巨大变形，特别是两极地区，明显的如

格陵兰岛比实际面积扩大了N倍。不过要是去两极地区探险或可靠的同志们，一

般有更详细的资料，不会来查看网络地图的，这个不要紧。

为什么是圆形球体，而非椭球体？

这说来简单，仅仅是由于实现的方便，和计算上的简单，精度理论上差别0.33%

之内，特别是比例尺越大，地物更详细的时候，差别基本可以忽略。

Web墨卡托投影坐标系：

以整个世界范围，赤道作为标准纬线，本初子午线作为中央经线，两者交点为坐

标原点，向东向北为正，向西向南为负。

X轴：由于赤道半径为6378137米，则赤道周长为2*PI*r = 20037508.3427892，

因此X轴的取值范围：[-20037508.3427892,20037508.3427892]。

Y轴：由墨卡托投影的公式可知，同时上图也有示意，当纬度φ接近两极，即

90°时，y值趋向于无穷。这是那些”懒惰的工程师”就把Y轴的取值范围也限

定在[-20037508.3427892,20037508.3427892]之间，搞个正方形。

懒人的好处，众所周知，事先切好静态图片，提高访问效率云云。俺只是告诉你

为什么会是这样子。因此在投影坐标系（米）下的范围是：最小

(-20037508.3427892, -20037508.3427892 )到最大 (20037508.3427892,

20037508.3427892)。

对应的地理坐标系:

按道理，先讲地理坐标系才是，比如球体还是椭球体是地理坐标系的事情，和墨

卡托投影本关联不大。简单来说，投影坐标系(PROJCS)是平面坐标系，以米 为

单位；而地理坐标系(GEOGCS)是椭球面坐标系，以经纬度为单位。具体可参考《坐

标系、坐标参照系、坐标变换、投影变换》。

经度：这边没问题，可取全球范围：[-180,180]。

纬度：上面已知，纬度不可能到达90°，懒人们为了正方形而取的

-20037508.3427892，经过反计算，可得到纬度 85.59。因此纬度

取值范围是[-85.59，85.59]。其余的地区怎 么办？

没事，企鹅们不在乎。

因此，地理坐标系（经纬度）对应的范围是：最小(-180,-85.59)，

最大(180, 85.59)。至于其中的Datum、坐标转换等就不再多言。

相关坐标计算：

关于Google Maps等的组织方式——地图瓦片金字塔，估计我在这里重复一遍这

玩意，怕也是没人看了。尽管原理都一样，但具体到写不同厂商不同数据源的代

码时，你会发 现，可缩放级别数不一样，最小级别不一样，编码方式不一样，

比如Google的QRST，微软的四叉树，OSGeo的TMS等。

然而，你或许也不必这么麻烦，因为这些算法在网络上早已遍布朝野，你尽可从

他人博客中获取，或是从开源软件里学习。这本身都不是秘密，微软自己也是公

布的。

《Tiles à la Google Maps》 用交互性地方式可得到任一Tile的边界范围，各

种流行编码方式等。该页面的链接都非常有价值，部分也是本文写作的重要参考。

作者用python完成了下 列坐标之间转换算法：经纬度（出现在KML中的坐标，

WMS的BBOX参数等），平面坐标XY（米，Web Mercator投影坐标系），金字塔

的XYZ（即X轴的位置，Y轴的位置，和缩放级别ZoomLevel），每个Tile的编

码Key值（QRST或 0123等）。转换时，还需要注意两个概念，Ground Resolution

和Map Scale。

Ground Resolution，地面分辨率，类似Spatial Resolution（空间分辨率），

我们这里主要关注用象元(pixel size)表示的形式：一个像素(pixel)代表的地

面尺寸(米)。以Virtual Earth为例，Level为1时，图片大小为512*512（4

个Tile），那么赤道空间分辨率为：赤道周长/512。其他纬度的空间分辨率则

为纬度 圈长度/512，极端的北极则为0。Level为2时，赤道的空间分辨率为 赤

道周长/1024，其他纬度为纬度圈长度1024。很明显，Ground Resolution取决

于两个参数，缩放级别Level和纬度latitude ，Level决定像素的多少，latitude

决定地面距离的长短。地面分辨率的公式为，单位：米/像素：

ground resolution = (cos(latitude * pi/180) * 2 * pi * 6378137 meters)

/ (256 * 2levelpixels)

Map Scale，即地图比例尺，小学知识，图上距离比实地距离，两者单位一般都

是米。在Ground Resolution的计算中，由Level可得到图片的像素大小，那么

需要把其转换为以米为单位的距离，涉及到DPI（dot per inch），暂时可理解

为类似的PPI（pixelper inch），即每英寸代表多少个像素。256 * 2level / DPI

即得到相应的英寸inch，再把英寸inch除以0.0254转换为米。实地距离仍旧

是：cos(latitude * pi/180) * 2 * pi * 6378137 meters; 因此比例尺的公式

为，一般都化为1：XXX，无单位：

map scale = 256 * 2level / screen dpi / 0.0254 / (cos(latitude * pi/180)

* 2 * pi * 6378137)

= 1 : (cos(latitude * pi/180) * 2 * pi * 6378137 * screen dpi) / (256 *

2level * 0.0254)

其实，Map Scale 和 Ground Resolution存在对应关系，毕竟都和实地距离相

关联，两者关系：map scale = 1 : ground resolution * screen dpi / 0.0254

meters/inch

《Virtual Earth Tile System》列举了Virtual Earth在赤道上，Level、像素

数、地面分辨率、地图比例尺的对应关系，同时本文也简单介绍了Mercator投

影和上述两个概念，推荐。

此外，《Addressing Google Maps image tiles》应用程序，输入经纬度和缩放

级别，即可缩放到相应的Google Maps位置，而且可以显示出查找过程的QRST。

JavaScript实现的算法，也可以抓下来和《Tiles à la Google Maps》对比下，

从经纬度到到Tile编码的转换。

WKT形式表示

Google Maps和Virtual Earth等的流行程度不用多讲，然而他们所使用的Web

Mercator或Spherical Mercator在很长一段时间内并没有被EPSG的投影数据

库所接纳。EPSG认为它不能算作科学意义上的投影，所以只是给了一个 EPSG：

900913的标号（SRID），这个标号游离在EPSG常规标号范围之外。（EPSG、SRID

是什么？参见《EPSG 、SRID》。）

到了2008年5月（据SharpGIS同学）， EPSG恍然明白，不管椭球体还是球体，

其实都是对地球的模拟，只是精确程度上的差别，没有本质上的不同。或者是不

得不接受广泛的事实标准，接纳了这个投 影，定义投影坐标系PROJCS的名字

为”Popular Visualisation CRS / Mercator”，SRID为EPSG:3785；地理坐标

系GEOGCS的名字为”Popular Visualisation CRS”，SRID为”EPSG:4055″。

这些标号已经进入”正常范围”。（PS：这个Visualisation 是英式英语写法？）

PROJCS 的WKT《Well Known Text》写法如下，GEOGCS、Datum等的WKT表示参

见《Spherical/Web Mercator: EPSG code 3785》。附带说一句，Web Mercator

在ESRI公司的编号（ESRI叫它Well Known ID？）暂时是102113，或许偶尔用

得到。

PROJCS["Popular Visualisation CRS / Mercator",

GEOGCS["Popular Visualisation CRS",

DATUM["Popular_Visualisation_Datum",

SPHEROID["Popular Visualisation Sphere",6378137,0,

AUTHORITY["EPSG","7059"]],

TOWGS84[0,0,0,0,0,0,0],

AUTHORITY["EPSG","6055"]],

PRIMEM["Greenwich",0,

AUTHORITY["EPSG","8901"]],

UNIT["degree",0.94328,

AUTHORITY["EPSG","9122"]],

AUTHORITY["EPSG","4055"]],

UNIT["metre",1,

AUTHORITY["EPSG","9001"]],

PROJECTION["Mercator_1SP"],

PARAMETER["central_meridian",0],

PARAMETER["scale_factor",1],

PARAMETER["false_easting",0],

PARAMETER["false_northing",0],

AUTHORITY["EPSG","3785"],

AXIS["X",EAST],

AXIS["Y",NORTH]]

附记：这个问题算是老问题，费这么多时间，主要就是分享，毕竟自己还算是相

当明白。也是看见有人不懂乱说，写篇文章纠正下。当然谁都会犯错误，包括我

这篇 是否100%正确，你也可以质疑。起这个题目其实不是本意，因为它不科学，

甚至EPSG的INFORMATION_SOURCE字段写的都是 Microsoft，只不过国内Google

更火些，SEO一下。

这篇文章除了参考文中所列链接外， Microsoft、Google、EPSG、OGC等组织相

关的说明外，Charlie Savage、SharpGIS、Nelson John等博客也是非常重要的

来源，在此致以谢意。