秋分

#1，楔子
先说个小段子，2月的事件。
周一下午收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投影。
首先要说明的一点是, 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)

Map #2: US and Alaska in WGS 1984 Web Mecator Projection(Fit to Extent Scale)

Map #3: US and Alaska in Albers Equal Area Projection (Same Scale as Map #2)

;

#3，巧妇难为无米之炊？巧妇难为多米之炊？——关于数据多寡及地图技巧表现
说道地图这十年的变化，大概跟地图技巧本身没有太大关系，变化在于载体，从纸板地图，一度转成刻录在CD上的电子地图，稍后又有了server based的在线地图，这一两年，智能手机大量被使用以后，mobile地图眼下差不多是最热的地图行业之一。
当然，还有个显著变化，是地图数据的大量增加。
现在人们说起早期的地图大都充满赞叹，不在于那些地图制作多么精巧或者美轮美奂，而是在古早时候，数据本身十分难得。没有卫星，交通又不便的时代，隔了座山就是另一个世界，描述自己生活的这个世界除了一具肉身几乎别无他法。徐霞客之伟大不仅仅在于他周游各地描述风土人情，而是他本人确实有绝佳方向感，能够以图的形式数据化的记述自己走过的地方，那便是地图。
题外话一句，前几天在微博上看一个朋友说身边兼有超级路痴和人肉GPS，一个拿着地图大白天绕来绕去找不到路停车问路还出口就错；另一个在深夜来到异地，租了车看了一遍地图一次就把人带到。两个人都让她跪。方向感这个东西，我觉得一定也是build in在基因里的。不是很多女孩子声称自己怎么都找不到路，我倒是觉得我天生方向感相当不错（捂脸，真是吹牛），以前在国内去过一次的地方，不管是白天晚上，下次再去一定能自己再找到；后来到DC开车，Georgetown和Rosslyn那么古怪的地形（Jun可能有不同看法），我基本上去一遍就能自己回来。有时候跟贵人出去，他问些去过一次的餐馆，我蒙头指方向，超过80%的时间都能指对。倒是有了Nav System以后，这个功能退化得很厉害。总结一下说，工具其实弥补了大家天赋上的差别，同样的，对于某些生有天赋的人来说，好的工具也就让他们失去了自己在这方面的优势。
绕回来说，那个古早的时代，没有工具，天赋就很重要。徐霞客这样的人（以及欧洲那些早期地图的制作者），我猜测他的方向感一定是非常非常的强的，倒不是迷路不迷路的问题，而是能够记述自己走过的路，而且可以准确量化（含长度和走向）这一点十分让人钦佩。
地图说到底就是把三维的信息量化成图，到二维的纸上。（还是说我那Google同学，我说到投影的时候，他非常好奇的说，为什么要投影，地图本身就是二维的啊，然后恍然大悟道，哦，是因为要画山吗？我真是要给他跪——汗，我还真是较真）
早期的地图，最大的问题是数据来源，一套准确完善的数据几乎要靠天赐，所谓巧妇难为无米之炊，这数据，就是米。有了一套好数据，地图成品才能有保障。
而到了现代，技术日新月异，我们有了卫星，有了GPS，有了各种丈量手段，用海量来形容数据毫不为过。于是问题又成了，在ingredient满坑满谷的时候，如何取舍，如何让彼此配合共存。
通俗的说，没有原料不好做菜；可是原料很多很多的时候，同样也不好做菜。
这就说回了我前段时间转的那篇，关于去年的得奖地图。
如果数据只是一套点一套线一套面，各自为政，作图当然不至于有大问题；可是有很多套点，很多套线，很多套面，要怎么表现他们可以让彼此都能被看见，又不至于乱得一塌糊涂让观众一看就放弃，就涉及到技巧。
在纸板地图时代，读者跟地图并没有互动，读者不可能像现在这样，把某个图层关掉或者打开，自己决定透明度或者颜色等等等等，于是地图这个成品必须在地图家手上完结，技巧尤其重要。
如果地图有个主题，数据就需要取舍：哪些留哪些丢，哪些应该是重点，哪些应该是背景，这些都是成图之前就要计划的事情。
这些决定了，便可根据重点不同决定图例（颜色，style，粗细），这很多都涉及一些比较普适的心理学：红色给人的感觉大都是热，alert，明黄色也一般是alert，这两个颜色是最常用来表示成图重点的，属于一眼就能看到不会被其他颜色压倒的色系；绿色蓝色给人的感觉是安静，米色大多是背景色。所以警报图大都用红色和黄色标明危险区域，绿色蓝色来覆盖安全区，灰色或者土黄色做地图。
当然，如果背景色是黑色，白色便是最好的抓人眼球的颜色（例如著名的国家地理的那幅The world at night）。
另外地图既然作为现实世界的二维表现，当然在表现物理数据的时候会尽量接近现实世界实物的颜色：蓝色表示海洋，土色表示沙漠，绿色表示森林，这些比较直观的relation可以让读者把地图跟现实世界联系在一起；还有一些稍微抽象点的表现，例如在高度图上，比较常用的渐变色有， 从低海拔到高海拔，由浅蓝色开始，进入浅绿，深绿，土黄，褐黄，然后白色；表现的是从海平面（低海拔），草地（平原），森林（渐高），树木线终结（timberline，意指一定海拔之下树木不再生长），雪山尖（高海拔）， etc. etc，也有用色谱表现高度差别的，大概也有地形高度不同光谱会有差别的缘故（例如紫外线特别强的地方，例如高山上，大都是紫蓝色花居多）。
一副好的地图，看起来简单，往往集结了地图家非常多的心血和思考，其实是非常值得细细阅读的。
另外就是点线面的style，这个之前在讲那个Imus地图的时候说过一次，怎么选择style可以让多层信息都可见，这个一直是纸板地图的大难题，半透明的图层只能用一次，在那之上如果还有别的信息，就得靠不同style，例如一层polygon可以用不同深浅的灰做成阴影体现三维地形，上面再一层透明颜色图层表示植被情况，再上面一层用空心各种花色网点表示其他信息，这些都是现在很常见，从前却经过各种苦思试验的手法。一定还有人记得从前的contour map，用一个个标记高度的闭合高度圈来表示elevation的，这样的图已经不太常见了，只有在需要精确高度值的field work的时候依然还在用。
现在的图形软件把一起都变得容易，一个contour数据输进去，软件自动根据光影效果做hillshade，然后一层层覆盖上去，一个一个换色带换style看效果，不过是几分钟的事情，当然已经是前人种树后人乘凉。
顺便说说从纸板地图到digital map的大变革：前面说到，地图这些年的变化，是载体的变化。这个载体的变化是物理方面的，最直接的结果是，地图在展现在读者面前的时候不再是成品。每个人可以根据自己的需要取消不必要的图层，放大或者缩小到自己需要的区域；不同的人看到的，甚至同一个人在不同时间看到的，都是不一样的地图。——Google Map这一类的地图主要的灵活性是允许读者关掉或者开放某些图层，可以自由zoom in/out或者pan；有些更小区域的地图甚至还允许读者自己选择图层的legend，灵活性更加的大。
因为这个灵活性，做地图的人需要考虑的难点大概是完全不一样的。
但是无论如何，数据以及如何解析数据，依然是这项成品背后的最重要的一个部分。
举个例子来说明一下。
先声明下，虽然这篇闲话里老拿Google Map举例，但我真的真的不是对google map有神马意见，他们真的是革新性的创造伟大的在线地图，我只是拿他们举个例子而已，罪过罪过。
下面比较的是Yahoo Maps（实际上是Nokia Map）和Google Maps在类似zoom上面的Road Network（路网？）——Google Maps的三个zoom是出现Road Network以后第一第二和第三个zoom，Nokia Maps则是出现Road Network以后的第一和第二个zoom。

;

这两个图比较，style不论，我的vote给Nokia Map。
乍一看，区别似乎只 是路网密度的不同，但我的理解是作图的两个人（或者说组图的两个组）对数据和zoom整个有理解上的差别。
为什么这么说呢，我的个人理解（当然大家会有不同意见，我只是说说我的个人理解）：digital map（online, mobile, etc. etc.)的zoom in/zoom out实际上模仿的是同一个地图的不同scale，或者是从缩略图到详细图，或者是同一个人在看同一副地图由远到近的过程。
那么，从大比例尺到小比例尺的过程，是一个从粗略图到细节图的过程，可以这么说，看一副图，从远到近，信息可以越来越多越来越细，但具体feature的nature不应该改变。
作为Road Network，connectivity是一个很重要的属性，我可以接受zoom out以后一些不重要的路被忽略掉（例如local road可以关闭显示），或者路的具体细节被略化（例如九曲十八弯的路被smooth），但我个人不能接受Network忽然从断开变成相连或者反过来。
路网在任何地方任何一个Zoom，只要实际生活中相连，地图上都应该保证一个enclosed network，Nokia在这一点上保证了，Google则没有。
从上面的例子上说，在大比例尺上看Google Map，会有个impression是Wichita Falls和Lubbock之间（红圈之内）是不相通的，只有zoom in以后才能看出来这两个地方其实是可以走通的。
我个人的猜测，Google Maps在做大比例尺地图的时候，仅仅考虑了Freeway（概念上叫做controlled access road)，认为显示freeway就表示了最重要的路；而Nokia用以决定显示与否的，则是地图数据界比较通用的一个概念，Functional Road Class (the Importance of the roads, mostly freeway, but not necessary)，这个概念有一个比较重要的属性，是同一级重要性以及之上，组成一个connected，enclosed road network。
这两套图的根本区别，在于display rule和数据理解上的偏差。
当然每个人都有不同意见，同样有人可以argue说，在zoom in和zoom out的过程中，湖泊，森林可以因为面积大小而出现/消失；非freeway的消失出现也可以按这个原则来。
而我的理解则是，那完全要看你怎么解释和展示数据。freeway和路的宽度并不一定有关系，说到底，在大比例尺显示freeway，就是认为它们比较重要；而我的理解是，路如人体血脉，关键作用在于连接点与点，作为概略图，至少应该显示点与点之间联系的主要路网，可以通过选择不同legend来表达freeway与非freeway，但整个关闭非freeway造成断裂路网，至少在我看来，这是制图上不可原谅的错误。
回想一下，在没有online map的时代，我们买整本的美国交通地图，第一张图就是全美的主要路网，这个路网，是不会也不应该有断裂出现的，这大概是地图家作图和非地图家作图，本质上的区别。

结束语
其实写了这么多闲话，都是我的个人想法，并不一定都正确，不过是供大家消遣。
用两件事来结语，
第一是我十数年前大学上地图课，地图老师说：一个地图，一定要标明标题，比例尺，方向，投影，和source，没有这些信息，地图上的信息就没有办法还原到真实世界，那就只能算是示意图，不是地图。我在美国上Graduate School做Geography101当TA的时候，跟我的学生讲这个道理，并且根据这个原则给他们做的图打分，因为太多人缺东少西，给我扣掉很多分，而别的TA都放过了，于是学生们集体抗议，把我换掉了。从此以后我都没能再做101的TA。
第二是大约十年前我刚刚入行，第二份工作遇上的supervisor出自Clark大学的地理系。这个姑娘，是对我之后从业有非常重要影响的人，应该说，我对地图的严肃态度，很多从她身上而来。她稍后离开我们公司去马里兰大学读PhD，再后来在VA一个County Office继续做online地图。我2010年回去DC稍后曾经被她面试过，又有跟她继续工作的机会。最后因为家庭原因放弃了回CA，我个人觉得非常遗憾。
她初到我原来的公司，整个公司只她一个geography出身，她凭一己之力教育了我们整个公司的Engineers，到她走的时候，我们公司其他组的人，都不再犯拿Lat/long直接算距离的错误，对UTM和State Plane也都有些基本概念，给我们这些后来做图的人奠定了非常好的基础，我在跟别的civil engineer讲噪音影响的时候，讲到投影都很能被理解。
又是一起前人种树后人乘凉。
说回最初，我工作时候第一次做图投影选得很不好，她花了半个多小时来解释她的理解。我半勉强的接受了，她离开的时候对我说，You don’t have to agree with me, you can stick to your own choice. But I believe you will understand later in your career, and come to agree with me.

（完）

外一则：阿根廷的八卦

这些天还在忙阿根廷。
事情是这样，继一遍又一遍跟阿根廷当地以及汽车厂商客户开会email电话等等以后，我们终于（自以为）把阿根廷IGN（Instituto Geográfico Nacional，大概是国家地理局的意思？）的要求搞清楚了，于是，数据组终于可以开始解析数据制图。
首先我们几次开会的两个重要发现是：
1，除了阿根廷，果然，智利也对地图有审查要求，而且重点检查阿根廷跟智利那片争夺地界的国界线。这种情况下，最理想的做法当然是阿根廷和智利各做一个build，但这么做的成本太高，最后我们咨询当地数据商，决定向双方机构approach的解决方案是，在争议地区不显示国界线，即是和稀泥态度了：既不从智利，也不从阿根廷。
大家有兴趣的可以在google map上查一下，google map的approach也是一样的，争议处在阿根廷南部El Calafate的西北边，挨着智利的Bernadao O‘Higgins国家公园，在zoom out的level上，google map显示的是阿根廷方面的国界线，国界线倾入绿色森林区，一直zoom in，就会发现那一带的国界线消失了。

这个approach说起来是很简单的，但对于数据来说，我们必须要知道：作为国界线来说，哪一个节点开始是争议国界，哪里结束，这一段国界线的attribute必须特殊处理，这样才能让apps设置不可见开关。

2，好消息是IGN也不是铁板一块，据当地技术支持说，我们在submit我们的产品时候，如果有什么feature实在没有达到IGN要求的，可以随产品递交一个Errata，表明我们支持IGN的态度，但由于产品技术的限制，不能一一做到IGN要求。例如阿根廷要求他们所有offshore岛屿都要可见，但如果地图根本没有办法包括那些区域，可以记录在勘误表里。
我记得我当时听到这个说法的第一反应是，那我们能不能就按照常规把产品做了，然后做个细致Errata一块交了完事？
我当时在电话会上这么提出的时候，阿根廷那边的地面支持只有闷闷笑了几声，说那当然还是不行，Errata是最后的方法，怎么也得让IGN知道确实在技术上尽力了。
这些个事前讨论略过不表，于是我们开始数据解析。
解析的时候，问题来了。
有个著名的马尾岛（这个我感觉咱们历史课上提到过），西班牙语叫Islas Malvinas的，虽然阿根廷声称这片土地是阿根廷的一部分，这片岛屿，确是在英国名下，大名叫Falkland Island。
好消息是总算南美和英国是分开的两个build，至少我们在南美部分的数据不必顾及英国人的想法，把这个岛划给阿根廷就是。
坏消息却是，虽然阿根廷声称马尾岛属于他们，这个岛实际上是在英国人掌控之中，不仅阿根廷人们不能开车乘轮渡去往那里，那个岛上的路啊店名啊小镇名啊，通通都是英语的！而IGN有个非常严格必须会检查的审查条例，就是地图上所有标注，必须使用西班牙文。
所以呢，要么，我们干脆把所有有英文名字的小镇街道通通从数据里delete掉，geometry没了，label也不会有，一了百了，整个马尾岛就有个形状留在地图上，标注上马尾岛名字，表达本导航的statement是阿根廷政府持有马尾岛；
要么呢，我们把geometry留着，遇上英文名字就通通delete，这下马尾岛上有点有线，但完全无标注。
据阿根廷本地支持回答，以上两种解决办法IGN都可以接受，所以怎么做完全看我们自己。
这些requirement flexible了，我们就开始Engineer们的扯皮，负责解析数据的Dev Team表示，他们觉得所有原始数据的解析都应该保留，应该是后面的component例如显示啊或者routing之类的Dev team来filte这个英文名字；后面的component说，我们没有可以对单地区进行filter的办法，如果南美是整个build出现，我们不能针对某一个岛remove非西班牙语，要么就只能remove整个南美的非西班牙语——这个当然也不可以，这不巴西还说葡萄牙语嘛。
最后开会拍板的那天，display那边的Dev Team的人恰好没来，于是人人推诿之后，所有的担子都落到了Display team，即是前期所有数据一路保留到最后，直到显示之前，由Display team进行条件挑选，凡是阿根廷境内，遇上非西班牙语通通invisible。
这件事的经验是，attendence很重要。

（阿根廷八卦完。。。呃。。。希望如此）