闲话地图——各种杂七乱八(完)
Posted: 2012-02-08 13:44
#1,楔子
先说个小段子,本周的事件。
周一下午收email忽然收到PJM的红旗信,我第一次收红旗信,简直吓一跳,颤抖着打开。
起因是阿根廷,我们去年底给客户做了南美的build,已经ship出去了,眼看要发布,客户忽然收到通知,原来在南美发表的商业地图(含电子地图)必须要通过政府审批才能售卖,顿时抓狂,于是身为链上下一环节的电子地图以及导航系统供应商的我们,就自然受气了。
当然主要受气的不是我们,而是提供地图数据的数据供应商,因为常规上说地图数据供应商必须提供当地跟地图相关的所有法令,包括speed camera能不能合法在导航上publish,国家对地图有什么特殊要求,等等,等等。
阿根廷的情况是,地图数据要售卖必须要经过审批,这个供应商自己当然已经申请并且通过了;但是下一步是根据该数据制作的各类商业产品包括纸版地图电子地图导航系统等等,也要再度申请审批并且要通过,才能进入售卖环节。这个要求供应商忘记通知我们,于是我们就傻眼了。
于是紧急抓了阿根提国家地图要求来读,这机构很官僚,并没有明确发布条文什么可以通过什么不可以通过,只说请递交草稿由他们返回审批意见。好在当地供应商还算有经验,自己总结了一个表格,包括阿根廷跟智利之间的国界要求,首都必须要用西班牙文标注并且要在所有尺寸上可见的要求,所有外部岛屿必须标记Arg. suffix,所有国家海域必须用西班牙标注并且在所有尺寸上可见,等等,等等,不一而足,基本是关于地图展示方面的。
令人头大的问题是整个南美我们按客户要求是作为一个Build发布的,如果按照了阿根廷的要求来,会不会又trigger了别的国家的敏感神经呢(例如智利?)
跟PJM讨论,PJM叹气,说大国有特殊要求,那好做(It's easy when big countries have special requirements),反正他们是独立的一个Build(例如咱们国家);小国家有特殊要求,那叫一个困难。
同样的事件我们还碰到过土耳其。土耳其比较奇特的一点是他不仅对自己国家以及自己国界有诸般要求,对欧洲其他地方也有些不同意见并且要在地图上表现出来,例如Cyprus 必须是两个国家,Kosovo不是Serbia的一部分而应是苏维埃国家,etc etc。
我们的客户本来打算在土耳其生产汽车并出口到欧洲其他国家售卖,这么一来,在土耳其生产的汽车内含的导航就必须完全按照土耳其自己的口味来,这个改变属于欧洲其他地区(情感上非法律上有些甚至是法律上)不能接受的地图,扯皮半天,最后当地政权力量最大,只得改变商业策略,定制土耳其自己的一个build,仅含土耳其地图,在土耳其生产及售卖;放弃在土耳其生产汽车出口欧洲其他国家的计划。
花这么多篇幅说这么个琐碎事儿呢,是要说明几点(我最近 貌似越来越geek了),第一地图是非常主观的产品,在某些政区里面,比小说散文诗歌等等文学体裁更具体的体现政见,用户最终看到的,是制图人希望用户看到的,传达的是制图人的理念;第二数据是一切地图之本,没有数据就没有地图,地图完全依赖数据,如果说第一点地图是制图人的观点,第二点更重要,地图是数据的观点;第三,地图数据不同其他的实验数据,地图数据是有国界有观点有政见的。
算是这个(如果能写完,会)很长很长的闲话的楔子。
#2,失之毫厘,谬以千里——关于投影
做地图,先有主题,然后拿到数据第一步是要做什么呢,是决定投影。
这是个说起来很简单,展开来说可以上一个学期的课的题目。现代社会,基本上所有的人都已经认同咱们生活在一个球体世界上(啊,在那遥远的年代里,天圆地方是多么的容易制图啊),但是地图却是二维世界。
把三维的信息投影到二维,这个过程,打个比方形容下是这样:假设你在吃一个橙子,想象你把橙子皮剥开,在桌面展开,这个,就是球到平面的过程。在用力摊平橙子皮的过程中,必然有些地方被挤压,有些地方被拉伸开,这些被挤压或者被拉伸的地方,就会有数据扭曲(distortion)。哪些地方有扭曲,怎么扭曲最小,第一取决这是个怎么样的橙子(如同大众所知,我们的地球并非一个完美球体,怎么define这个球体,这是Datum),还取决于这个橙子皮是怎么划分的,常识是,橙子皮剥开以后切开越小再摊平,造成的数据扭曲越小,但无论如何,除非橙子皮能被切得无限小,这个扭曲是不可避免的。
既然扭曲不可避免,只能争取这个扭曲最好的服务自己。
几何学上来说,作为投影中心的的原点附近扭曲最小,离中心越远,扭曲越大。所以大部分国家在做世界地图时候把自己放在地图中心,并不是为了表达自己是世界中心,而是争取自己国家的数据扭曲最小化。——当然也可以把原点移动到图的右边左边,不过方便起见,原点都是在图中间。
目前通用的地图投影有上千种,适用不同目的不同地区。例如有长度保持得比较好的投影,有面积保持得比较好的投影,根据地图目的主体不同,选不同的投影。
我之前工作的地方作图总是在给政府作报告,机场附近多少面积被某个噪音段影响,所以面积对我们来说一直很重要,好在机场附近总是很小的地方,一直就跟着US State Plane Projection走。
跟切橙子皮摊平的原理类似,作图如果做比较小的地方,需要面对数据扭曲就很少,弧度小到一定程度,几乎就可以当做平面对待——这也是为什么古人一直认为天圆地方的缘故吧,因为目之所见,是很小很小的一块橙子皮。
说道投影,就不得不说到目前Google启用以至于几乎成为网络地图规范的Web Mercator投影。
------------------------------抗3-----------------------------
首先要说明的一点是, Don't get me wrong,Google Map是革命性的idea和产品,给整个地图界地理界带来的冲击是正面的巨大的,而且也带来有地图史以来最多的地图用户。在Google Map之前,基本可以说没有全面的online map/digital map,并非没有online地图,这个是有的,比较通用的是ESRI ArcIMS做出来的,常见于各个County GIS Office,基本上基于网络的看矢量地图的工具,用户也可以选择不同zoom level,可以选择不同地图层,改变legend,label是否visible,选择数据下载,甚至可以修改数据,等等。ArcIMS的缺点是十分十分缓慢,因为Server上存的是地图矢量文件,光是display有时候就要花个半分钟。另外很重要的一点,根据我上面的描述,可以看出这个设计还是针对做地图的人的需求,其实并没有考虑普通用户的想法。——除了做地图的人,谁想要改地图层颜色/选择label/下载数据修改数据啊?
Google Map则面对了一般的地图用户,集中了最通用的几种地图用法:找地方(POI+地址),找路线(当然,今天的Google Map功能更多了,但最常用的还是这两种),然后就display。因此完全取消了面对数据这一层,提前把地图数据在不同zoom level处理过,直接切割成图,把切割出来的成图做成tile,这样虽然limit了用户对成图可能的修改,但也大大缩短了display的时间。Google Map之前还有一家用来找路线的网站,MapQuest,我不知道有几个人知道,这个网站的想法不够深远,但其实有是Online Map Source的先驱。MapQuest大概还是不够有钱,只能做到让你输入起点终点,然后给出路线,最后再给一张小的示意图。要达成这个结果,其实是必须有地图数据在后台的,他们少做的,是把地图数据display出来这一步。
关于他们为什么没有这么做,我有几个猜想,速度显然会是一个考量,以当时的固有技术来看,如果用ArcIMS,用户半天还没有等到地图就失去耐心,显然不值得投入在上面;第二个,很不幸的,要追求距离地图精确,投影只能限于小区域投影,如果用非投影的LAT/LONG数据,一路zoom到小地区,地图会很难看不说,还没有一了百了的办法切换。
这就说道跟随Google Map出现的WGS1984 Web Mecator。Google Map另一个革命性是他们第一次真正意义上进行了从Lat/Long往点上(digital distance)而不是物理距离的投影(的尝试?)。Web Mecator理论上来说并不是从经纬度换算物理距离,而是从经纬度换算像素,但当然这些像素对应了物理距离——精确不精确另说。这个投影是World Scale的,可以理解,因为他们要面对用户不断zoom in/zoom out地图的行为,如果根据不同区域切换投影,需要的工作量非常巨大而且转换投影的过程中会有图形忽然变化的现象,这当然是他们需要避免的。(这里也可以看出网络地图和传统地图的一个巨大区别,用户本身的role很大,传统地图成图以后用户只有看这个角色,地图家可以根据自己想做的feature来决定投影比例尺和extent,但这一点在网络地图时代则不可行)
Web Mecator基本上就是基于WGS(World Geodetic System)1984经纬度的一个换算,这个换算基本上比较简单。在图#2可以看出来,这个换算忽略了经度上的球面效应,把不同纬度上的同样经度距离换算成同样的像素距离。这个说起来比较拗口,举个例子,北纬圈附近经度5度的弧长度应该远远小于赤道附近经度5度的弧长度,虽然x差距都是5,换算出来的距离应该是不同的。但在图#2可以的经纬栅格上可以看出来,Web Mecator并没有考虑这个球面;Web Mecator在纬度球面做了个变换,即赤道附近纬度弧长度比较小,越往两极同样纬度弧长度变长。——我有点不能理解这个投影的逻辑是什么,但是这两个特点加起来,造成Web Mecator最致命的一个弱点,就是越往两极靠近,数据误差越惊人,因为无论X还是Y都被远远拉长。所以Google Map上来看,阿拉斯加非常的大,格林兰岛也异常的大,都是因为没有正确投影的缘故。
为了更好说明我的观点,做了以下三张图作为辅助。这三张用的是同一份数据,2010年US Census发布的TIGER,原始数据给的是NAD1983 Lat/Long,北美Albers是基于这个Datum的,所以没有转换;做成WGS1984 Web Mecator(Google Map),做了一步转换,这个转换在全美应用本身会有些许误差,不过这个误差在这个比较里面可以忽略。
当然Google Map的Web Mecator是世界范围用的投影,但这里的两个Albers Conic(US Contiguous Albers Conic和Alaska Albers Conic)都是区域性的,肯定区域性投影的精确度要远远超过世界范围的,只是为了用一个更精确的投影来说明Web Mecator的扭曲程度。
三张图用的是完全相同的frame:水平方向的A4纸,Alaska用的insert map的frame大小也是完全一样的,图#1是在这个Extent下用Albers Conic展示美国本土48州和阿拉斯加,本土比例尺是1:18,000,000。图#2就是Google Map用的Web Mecator,在这个同样的extent下,要放下美国本土48州,比例尺需要缩小到25,000,000,说明在Web Mecator下面表现出来的面积远远大于Albers Conic的。在阿拉斯加这样极北的地区,distortion更加离谱,在图#1里Alaska Albers Conic里面1:40,000,000可以容下的阿拉斯加,到了Web Mecator需要把比例尺缩小一半多,到1:90,000,000才能容下。
另外图上的grid是10*10经纬度的,更加明显的表现了两个投影的区别。一个是白博说道的弧度问题,还有一个就是经纬度弧长度在不同位置的变化问题。
图#3和图#2是完全相同的比例尺,但不同的投影,光看图可以看出两者的面积相差有多大。
当然以世界的scale来说,没有完美的投影,但毕竟也有些可用的投影,我有点不太能理解的是Google Map为什么自己发明了一个并不正确好处只是换算简单的投影,以我个人来看,这个转换基本上就是在用经纬度的线性关系,几乎可以不转。何不直接用经纬度呢——当然在平面上展示经纬度本身是个不合理的,但我个人认为这个extra step并没有大的改善。
Google Map因为广入人心,很多小的在线地图公司基本上就是直接用google map的api,因此web mecator流传广泛,包括我之前面试过National Geographic的,也沿用了这个投影,实在是件让专业人士很无奈的事情。
Map #1: US and Alaska in Albers Equal Area Projections (Fix to Extent Scale)
大图
http://farm8.staticflickr.com/7176/6921 ... fce3_b.jpg
Map #2: US and Alaska in WGS 1984 Web Mecator Projection(Fit to Extent Scale)
大图
http://farm8.staticflickr.com/7042/6921 ... b1af_b.jpg
Map #3: US and Alaska in Albers Equal Area Projection (Same Scale as Map #2)
大图
http://farm8.staticflickr.com/7199/6921 ... d9f3_b.jpg
--------------------
#3,巧妇难为无米之炊?巧妇难为多米之炊?——关于数据多寡
(转第3页)
先说个小段子,本周的事件。
周一下午收email忽然收到PJM的红旗信,我第一次收红旗信,简直吓一跳,颤抖着打开。
起因是阿根廷,我们去年底给客户做了南美的build,已经ship出去了,眼看要发布,客户忽然收到通知,原来在南美发表的商业地图(含电子地图)必须要通过政府审批才能售卖,顿时抓狂,于是身为链上下一环节的电子地图以及导航系统供应商的我们,就自然受气了。
当然主要受气的不是我们,而是提供地图数据的数据供应商,因为常规上说地图数据供应商必须提供当地跟地图相关的所有法令,包括speed camera能不能合法在导航上publish,国家对地图有什么特殊要求,等等,等等。
阿根廷的情况是,地图数据要售卖必须要经过审批,这个供应商自己当然已经申请并且通过了;但是下一步是根据该数据制作的各类商业产品包括纸版地图电子地图导航系统等等,也要再度申请审批并且要通过,才能进入售卖环节。这个要求供应商忘记通知我们,于是我们就傻眼了。
于是紧急抓了阿根提国家地图要求来读,这机构很官僚,并没有明确发布条文什么可以通过什么不可以通过,只说请递交草稿由他们返回审批意见。好在当地供应商还算有经验,自己总结了一个表格,包括阿根廷跟智利之间的国界要求,首都必须要用西班牙文标注并且要在所有尺寸上可见的要求,所有外部岛屿必须标记Arg. suffix,所有国家海域必须用西班牙标注并且在所有尺寸上可见,等等,等等,不一而足,基本是关于地图展示方面的。
令人头大的问题是整个南美我们按客户要求是作为一个Build发布的,如果按照了阿根廷的要求来,会不会又trigger了别的国家的敏感神经呢(例如智利?)
跟PJM讨论,PJM叹气,说大国有特殊要求,那好做(It's easy when big countries have special requirements),反正他们是独立的一个Build(例如咱们国家);小国家有特殊要求,那叫一个困难。
同样的事件我们还碰到过土耳其。土耳其比较奇特的一点是他不仅对自己国家以及自己国界有诸般要求,对欧洲其他地方也有些不同意见并且要在地图上表现出来,例如Cyprus 必须是两个国家,Kosovo不是Serbia的一部分而应是苏维埃国家,etc etc。
我们的客户本来打算在土耳其生产汽车并出口到欧洲其他国家售卖,这么一来,在土耳其生产的汽车内含的导航就必须完全按照土耳其自己的口味来,这个改变属于欧洲其他地区(情感上非法律上有些甚至是法律上)不能接受的地图,扯皮半天,最后当地政权力量最大,只得改变商业策略,定制土耳其自己的一个build,仅含土耳其地图,在土耳其生产及售卖;放弃在土耳其生产汽车出口欧洲其他国家的计划。
花这么多篇幅说这么个琐碎事儿呢,是要说明几点(我最近 貌似越来越geek了),第一地图是非常主观的产品,在某些政区里面,比小说散文诗歌等等文学体裁更具体的体现政见,用户最终看到的,是制图人希望用户看到的,传达的是制图人的理念;第二数据是一切地图之本,没有数据就没有地图,地图完全依赖数据,如果说第一点地图是制图人的观点,第二点更重要,地图是数据的观点;第三,地图数据不同其他的实验数据,地图数据是有国界有观点有政见的。
算是这个(如果能写完,会)很长很长的闲话的楔子。
#2,失之毫厘,谬以千里——关于投影
做地图,先有主题,然后拿到数据第一步是要做什么呢,是决定投影。
这是个说起来很简单,展开来说可以上一个学期的课的题目。现代社会,基本上所有的人都已经认同咱们生活在一个球体世界上(啊,在那遥远的年代里,天圆地方是多么的容易制图啊),但是地图却是二维世界。
把三维的信息投影到二维,这个过程,打个比方形容下是这样:假设你在吃一个橙子,想象你把橙子皮剥开,在桌面展开,这个,就是球到平面的过程。在用力摊平橙子皮的过程中,必然有些地方被挤压,有些地方被拉伸开,这些被挤压或者被拉伸的地方,就会有数据扭曲(distortion)。哪些地方有扭曲,怎么扭曲最小,第一取决这是个怎么样的橙子(如同大众所知,我们的地球并非一个完美球体,怎么define这个球体,这是Datum),还取决于这个橙子皮是怎么划分的,常识是,橙子皮剥开以后切开越小再摊平,造成的数据扭曲越小,但无论如何,除非橙子皮能被切得无限小,这个扭曲是不可避免的。
既然扭曲不可避免,只能争取这个扭曲最好的服务自己。
几何学上来说,作为投影中心的的原点附近扭曲最小,离中心越远,扭曲越大。所以大部分国家在做世界地图时候把自己放在地图中心,并不是为了表达自己是世界中心,而是争取自己国家的数据扭曲最小化。——当然也可以把原点移动到图的右边左边,不过方便起见,原点都是在图中间。
目前通用的地图投影有上千种,适用不同目的不同地区。例如有长度保持得比较好的投影,有面积保持得比较好的投影,根据地图目的主体不同,选不同的投影。
我之前工作的地方作图总是在给政府作报告,机场附近多少面积被某个噪音段影响,所以面积对我们来说一直很重要,好在机场附近总是很小的地方,一直就跟着US State Plane Projection走。
跟切橙子皮摊平的原理类似,作图如果做比较小的地方,需要面对数据扭曲就很少,弧度小到一定程度,几乎就可以当做平面对待——这也是为什么古人一直认为天圆地方的缘故吧,因为目之所见,是很小很小的一块橙子皮。
说道投影,就不得不说到目前Google启用以至于几乎成为网络地图规范的Web Mercator投影。
------------------------------抗3-----------------------------
首先要说明的一点是, Don't get me wrong,Google Map是革命性的idea和产品,给整个地图界地理界带来的冲击是正面的巨大的,而且也带来有地图史以来最多的地图用户。在Google Map之前,基本可以说没有全面的online map/digital map,并非没有online地图,这个是有的,比较通用的是ESRI ArcIMS做出来的,常见于各个County GIS Office,基本上基于网络的看矢量地图的工具,用户也可以选择不同zoom level,可以选择不同地图层,改变legend,label是否visible,选择数据下载,甚至可以修改数据,等等。ArcIMS的缺点是十分十分缓慢,因为Server上存的是地图矢量文件,光是display有时候就要花个半分钟。另外很重要的一点,根据我上面的描述,可以看出这个设计还是针对做地图的人的需求,其实并没有考虑普通用户的想法。——除了做地图的人,谁想要改地图层颜色/选择label/下载数据修改数据啊?
Google Map则面对了一般的地图用户,集中了最通用的几种地图用法:找地方(POI+地址),找路线(当然,今天的Google Map功能更多了,但最常用的还是这两种),然后就display。因此完全取消了面对数据这一层,提前把地图数据在不同zoom level处理过,直接切割成图,把切割出来的成图做成tile,这样虽然limit了用户对成图可能的修改,但也大大缩短了display的时间。Google Map之前还有一家用来找路线的网站,MapQuest,我不知道有几个人知道,这个网站的想法不够深远,但其实有是Online Map Source的先驱。MapQuest大概还是不够有钱,只能做到让你输入起点终点,然后给出路线,最后再给一张小的示意图。要达成这个结果,其实是必须有地图数据在后台的,他们少做的,是把地图数据display出来这一步。
关于他们为什么没有这么做,我有几个猜想,速度显然会是一个考量,以当时的固有技术来看,如果用ArcIMS,用户半天还没有等到地图就失去耐心,显然不值得投入在上面;第二个,很不幸的,要追求距离地图精确,投影只能限于小区域投影,如果用非投影的LAT/LONG数据,一路zoom到小地区,地图会很难看不说,还没有一了百了的办法切换。
这就说道跟随Google Map出现的WGS1984 Web Mecator。Google Map另一个革命性是他们第一次真正意义上进行了从Lat/Long往点上(digital distance)而不是物理距离的投影(的尝试?)。Web Mecator理论上来说并不是从经纬度换算物理距离,而是从经纬度换算像素,但当然这些像素对应了物理距离——精确不精确另说。这个投影是World Scale的,可以理解,因为他们要面对用户不断zoom in/zoom out地图的行为,如果根据不同区域切换投影,需要的工作量非常巨大而且转换投影的过程中会有图形忽然变化的现象,这当然是他们需要避免的。(这里也可以看出网络地图和传统地图的一个巨大区别,用户本身的role很大,传统地图成图以后用户只有看这个角色,地图家可以根据自己想做的feature来决定投影比例尺和extent,但这一点在网络地图时代则不可行)
Web Mecator基本上就是基于WGS(World Geodetic System)1984经纬度的一个换算,这个换算基本上比较简单。在图#2可以看出来,这个换算忽略了经度上的球面效应,把不同纬度上的同样经度距离换算成同样的像素距离。这个说起来比较拗口,举个例子,北纬圈附近经度5度的弧长度应该远远小于赤道附近经度5度的弧长度,虽然x差距都是5,换算出来的距离应该是不同的。但在图#2可以的经纬栅格上可以看出来,Web Mecator并没有考虑这个球面;Web Mecator在纬度球面做了个变换,即赤道附近纬度弧长度比较小,越往两极同样纬度弧长度变长。——我有点不能理解这个投影的逻辑是什么,但是这两个特点加起来,造成Web Mecator最致命的一个弱点,就是越往两极靠近,数据误差越惊人,因为无论X还是Y都被远远拉长。所以Google Map上来看,阿拉斯加非常的大,格林兰岛也异常的大,都是因为没有正确投影的缘故。
为了更好说明我的观点,做了以下三张图作为辅助。这三张用的是同一份数据,2010年US Census发布的TIGER,原始数据给的是NAD1983 Lat/Long,北美Albers是基于这个Datum的,所以没有转换;做成WGS1984 Web Mecator(Google Map),做了一步转换,这个转换在全美应用本身会有些许误差,不过这个误差在这个比较里面可以忽略。
当然Google Map的Web Mecator是世界范围用的投影,但这里的两个Albers Conic(US Contiguous Albers Conic和Alaska Albers Conic)都是区域性的,肯定区域性投影的精确度要远远超过世界范围的,只是为了用一个更精确的投影来说明Web Mecator的扭曲程度。
三张图用的是完全相同的frame:水平方向的A4纸,Alaska用的insert map的frame大小也是完全一样的,图#1是在这个Extent下用Albers Conic展示美国本土48州和阿拉斯加,本土比例尺是1:18,000,000。图#2就是Google Map用的Web Mecator,在这个同样的extent下,要放下美国本土48州,比例尺需要缩小到25,000,000,说明在Web Mecator下面表现出来的面积远远大于Albers Conic的。在阿拉斯加这样极北的地区,distortion更加离谱,在图#1里Alaska Albers Conic里面1:40,000,000可以容下的阿拉斯加,到了Web Mecator需要把比例尺缩小一半多,到1:90,000,000才能容下。
另外图上的grid是10*10经纬度的,更加明显的表现了两个投影的区别。一个是白博说道的弧度问题,还有一个就是经纬度弧长度在不同位置的变化问题。
图#3和图#2是完全相同的比例尺,但不同的投影,光看图可以看出两者的面积相差有多大。
当然以世界的scale来说,没有完美的投影,但毕竟也有些可用的投影,我有点不太能理解的是Google Map为什么自己发明了一个并不正确好处只是换算简单的投影,以我个人来看,这个转换基本上就是在用经纬度的线性关系,几乎可以不转。何不直接用经纬度呢——当然在平面上展示经纬度本身是个不合理的,但我个人认为这个extra step并没有大的改善。
Google Map因为广入人心,很多小的在线地图公司基本上就是直接用google map的api,因此web mecator流传广泛,包括我之前面试过National Geographic的,也沿用了这个投影,实在是件让专业人士很无奈的事情。
Map #1: US and Alaska in Albers Equal Area Projections (Fix to Extent Scale)
大图
http://farm8.staticflickr.com/7176/6921 ... fce3_b.jpg
Map #2: US and Alaska in WGS 1984 Web Mecator Projection(Fit to Extent Scale)
大图
http://farm8.staticflickr.com/7042/6921 ... b1af_b.jpg
Map #3: US and Alaska in Albers Equal Area Projection (Same Scale as Map #2)
大图
http://farm8.staticflickr.com/7199/6921 ... d9f3_b.jpg
--------------------
#3,巧妇难为无米之炊?巧妇难为多米之炊?——关于数据多寡
(转第3页)