|
Mercator（1512～1594），生于Rupelmonde（现比利时某地，当时属于 Flanders——荷、法、比交界的地方），制图学家、哲学家及数学家。拟定了著名的Mercator投影（正轴等角切圆柱），推动了航海事业和Web地图产业（这个您老没想到吧～）发展；首次使用“Atlas”来表示地图集，并延续至今。今年恰逢Mercator诞辰500周年，Esri曾专门撰文纪念，在此也向Mercator表示敬意。 （比利时法郎中的Mercator头像，及Mercator投影和Atlas，via umich） Mercator与航海在Mercator投影发明之前，航海中使用的是最简单的plate carrée投影（现在天地图还在用），最早由Ptolemy发明，投影公式简单到不能再简单了：x=lon， y=lat。但这个投影既不等角也不等积，特别在高纬度地区，与实际相差很大，所以并不实用。Mercator于1569年发明了Mercator投影，通过对普通透视圆柱投影的改进，根据纬度越高的纬圈投影到圆柱上长度变化越大，因此考虑纬度变长时将对应的经线也拉长，从而保证两者之比恒定，即能等角。 在Mercator投影的海图中，恒向线（Rhumb line）是一条直线，这对航海来说有重要意义。沿恒向线航行不用改变航向就能到达目的地。比如你要从A航行到B，只需拿把尺子在Mercator海图上将AB连起来，计算AB与经线所成的角度，在航行中使用罗盘一直保持这个角度就能到达B了。但要注意，恒向线并不是球面上的最短距离。球面上两点间的最短距离是大圆航线（Great circle）。在实际航海中，考虑到航行的距离和驾驶的方便性，往往是两者结合起来使用。在近距离航海中，沿着恒向线朝一个方向航行就能到达目的地。远距离航行中，可以先绘制从出发到目的地的大圆航线，再将大圆航线分为几段，每段按恒向线航行，这就能兼顾了距离和方便性了。当然，实际中并没那么简单。也可以想这么个问题，你一直朝一个方向走（与经线成一个恒定的角度），最终不是走到北极就是南极，除非你沿着经纬网走，那能走回原地。所以，恒向线其实是一条螺旋线。 （大圆航线和恒向线在Mercator投影中的对比，via esri） 人类征服海洋的过程是十分坎坷的，Mercator投影的发明只是一部分。直到伟大的Harrison发明了海钟（1737），人类才能在航海时精确地计算经度，进而保证航行的安全。Harrison发明海钟又是一个百味杂陈的故事，有机会可以另说，或者阅读这本书。 Mercator投影公式虽然我没推导过，但不妨碍我们看看起投影公式的真面容： （Mercator投影正解公式） （以赤道、本初子午线为原点） 使用的参数不做过多解释，参看地图投影书籍。Mercator投影的最大优点就是正形（conformal）， （变形椭圆，via wikipedia） 但与之相伴的在高纬度地区极度的失真（面积、距离），最经典的是格陵兰岛和南美洲的大小差异，这个可以从投影公式中用到的正切函数看出。 （比例尺，via wikipedia） Mercator并不很适合用来展现世界地图，特别是一些专题图的制作，面积与实际的差异实在是夸张，地图也会撒谎的。在教育小孩的时候，最好不要用Mercator投影地图，这可能会影响“世界观”的呀。 Web地图之空间参考自从Google Maps（2005）出现以来，现今全球范围的Web地图，用的空间参考都是Web Mercator投影（3857）。Web Mercator与Mercator相似，可以看下其投影公式： （Web Mercator投影正解公式） 与Mercator投影的主要差别在于纬度的计算上，Google工程师为了简便起见，没有使用椭球第一偏心率（e1），从而简化了投影公式。即将WGS84椭球在投影时看作了以其长半轴（6378137）为半径的正球体，而经纬度坐标还是参考WGS84的，这显然与GIS中的空间参考规范不符。众所周知，常用空间参考主要有投影坐标系（PCS）与地理坐标系（GCS）两大类，一个PCS建立在一个GCS之上，并要指定一个投影公式，这个投影公式是要以GCS为基准的，不然定义PCS基于GCS就没有意义了。但Google没有这么做，这就搞乱了空间参考的标准体系，不过这样我们可以从两个角度来理解Web Mercator： （1）GIS角度。如前所述，Web Mercator采用了两个椭球，WGS84椭球和以WGS84长半轴为半径的正球。GCS用的是WGS84，而GCS投影到PCS时，使用的是正球，虽然地理坐标是参考WGS84的，这点最关键！ （2）非GIS角度。从数学上看，投影无非是一个函数。Mercator投影利用了WGS84椭球的所有参数（a、b、e1、e2），而Web Mercator只不过使用了部分参数罢了（a）。这么理解，就能忽略椭球与正球的差异了，那Web Mercator就是Google参考Mercator投影发明的一种新投影。 值得注意的是，Web Mercator投影不是等角的，只是近似等角（near-conformality），Mercator投影是等角的。虽然我不能证明，但我可以理解。从投影公式去看，或者想象一下投影时椭球和正球的区别，显然是能直观地想明白的。 Google的Hack行为一来推动了Web地图的发展，并形成了一套标准，二来也搅乱了GIS界。EPSG开始并不认可这种投影，至少是不推荐，并不给其编号。但是坊间已经应用广泛，并编之为900913，意指google。后来900913俨然成为了业界标准，EPSG数据库中也就出现了3785这个投影，但没过多久又换成了3857（3785与3857之间的差异后面再说）。Esri方面，Esri的Web地图开始用的都是4326，到09年末才转换为3857，并逐步停用了原先的4326。选择3857自然有许多好处，比如这是业界标准，这样大家都能互相mashup，一起建设和谐社会。4326的瓦片大小是512×512，3857是256×256，瓦片变小既能减少单张瓦片的网络流量，又能缩小瓦片数目的规模，而且在一张256×256的瓦片正好能做一张世界地图。 Web Mercator与Web Mercator（Auxiliary Sphere）之异同ArcGIS中的Web Mercator就是3785，Web Mercator（Auxiliary Sphere）就是3857。如果你有一份与Google Maps使用相同投影的数据A，但失去了投影信息，那么你在ArcGIS中使用任何一个去定义（define）你的空间参考都是正确的。但是，假如你再将一份WGS84（4326）定义的GCS数据B与A去叠加，那么B与A3857可以直接叠加，而B与A3785就不能了，至少不能on the fly。为什么呢？这个通过看一下投影文件，结合前述的Web Mercator投影介绍，再自己实践一下就能明白。 （3785投影文件） （3857投影文件） 两个比较明显的区别： （1）3785用的是正球体，3857用的是椭球体。 （2）3857的投影参数里面多了“Auxiliary_Sphere_Type: 0.0”。 也就是说3785是以正球体上为基准的，但其GCS还是参考WGS84；3857是以椭球体为基准的，但投影时参考正球体，“Auxiliary_Sphere_Type: 0.0”的作用就在这里吧。 那么，我现在有一份4326的数据，分别要投影到3785和3875上，该怎么做呢？ 对于3857，因为3857本身基于4326的，所以可以直接project。但是对于3785，就稍微麻烦点了，如果你直接project，那arcgis会提示你进行椭球转换，结果显然会与你预期的不一致。所以你得先重新给这份4326的数据定义一个新的空间参考，定义一个空间参考并不改变其数据，而椭球转换显然是会改变数据的。根据3785所使用的椭球，为4326定义一个新的GCS（104199），就是6378137为半径的正球体，然后再project到3785。这样得到的数据会跟4326直接project到3857一致，但空间参考是不一致的，一个是3857，一个是3785。如果有兴趣可以自己尝试，我附了数据在后面。 显而易见，3857比3785更合适一些，至少Datum是正常的。GIS的一大特征就是能叠加多源数据，3785这样的投影在叠加数据就很尴尬了，这也是Esri最终使用3857的原因。Esri Dev Summit的视频中也表示，3875和3785在数学上是一致的，如果要考虑叠加数据，建议使用3857。其实我觉得3785现在基本上没什么用了，只是Esri自己凌乱状态下定义的一个过渡空间参考：P 回过头看，Google 工程师的一次偷懒行为，破坏了GIS界的规范，还最终逆袭成为了事实上的标准，让人唏嘘不已。如果Google使用的是正常的Mercator投影，同样也可以在一张256×256的瓦片中容纳世界地图，只不过南北的跨度略有差异，这样既能保证真正的等角，又符合GIS规范，也不会给我们带来这么困扰。同样，如果Esri或者EPSG能更有话语权，那或许也不会有Web Mercator的存在了。只能说IT和GIS相遇，失意的总是GIS，至少目前是这样的。 ——— 空间参考本身比较复杂，所以文中难免有所疏漏和错误，请批评、指正。另外，现今GIS中的地图学课程越来越式微，地图投影等学习也十分薄弱。个人觉得，GIS的教育是很失败的，但是教育失败并不是我们止步的借口，而是我们更应发奋的缘由之一。 附：文中所提及的相关资料，包括数据、代码及投影文件等 相关日志
|
|
|
