技术日志

其实我很早的时候就写过一篇“我的 2010世博地图1.0版发布”，但没有和大家做明确的说明和制作方法，今天就和大家一起来分享地图配准和地图切割并进行网络发布的问题，其实就是以世博为例制作一份简单的网络地图。网络地图是以Google Maps API为基础，在Google Maps上面叠加一份自制的世博地图，但有一点，这里的地图配准和切割很重要，不过使用本文介绍的工具后一切都将变的不困难了。 我们先去世博的网站找一点素材，在世博规划中可以下载到规划总平面图，如有兴趣也可以下载一份场馆规划图。不过你所下载的文件是PDF文件，需要导出成为JPG图片，方法是使用PDF编辑软件或者PDFtoJPG软件来完成，这里就不做介绍了，最终得到的就是一个世博规划的平面图。为了不让大家难做，我就直接提供我导出后的世博规划图，点击这里可以下载。(BTW：如果觉得世博规划图不够清晰，那我也没有办法，PDF中的图片本身就不清晰) 接下来配准地图，配准有很多的方法，比如用MapInfo来配准甚至ArcInfo来配准等，不过这些太复杂了，我们今天介绍一个简单的软件来进行配准，这就是GlobalMapper，一个非常牛的GIS软件，可以打开超级多的地图格式，并且可以另存为超级多的地图格式，我们就用它来进行简单的配准吧。不过万变不离其中，配准重要的就是根据点位来进行配准，就是找到一些关键点标定上坐标。我们使用GlobalMapper打开这个bmp的图片，然后就提示是否配准，我们当然需要配准啦，就点是，这个时候就进入配准界面了。配准所需的关键点就是图片中非常清晰可辨并且容易标定上坐标的位置，看了这份地图我们只能使用路口的方式进行配准了，因为其他信息都没有参考价值，我们选择了三个点位，并且找到了坐标，分别是：打浦路瞿溪路(N31.19832 E121.47227)、历城路昌里路(N31.17383 E121.49261)、临沂路南码头路(N31.19375 E121.51033)，有了这三个位置信息后就可以配置了，如下图所示： 赶紧点击OK吧，你的地图就配准完成啦。其实MapInfo里的配准也是同样的一个道理。 好了，接下来我们需要切割地图了，由于希望在切割地图的软件里变得更加简单一些，所以我们将刚刚在GlobalMapper中配准完成的地图另存为GeoTIFF格式，就是一个带有坐标信息的TIF图片。我们现在需要介绍一个杀手级的软件，让你的这个平面图直接输出到Google Maps里面，自动帮助你切割完成，真的是超牛，这个软件是什么呢，就是MapTiler，一个Map Tile Cutter软件，可以制作overlay到Google Maps或者Google Earth，不再多介绍这个超级牛的软件，需要了解到用户自行到网站上了解，我们只用简单的切割功能，以前介绍的GMapImageCutter工具和它相比真是小巫见大巫了。BTW，GlobalMapper软件其实也有输出Google maps tile的功能，但是不算太好，所以才用到这个专业的地图切割软件。打开软件，选择第一个Google Maps兼容格式： 下一步当然是添加我们刚刚的tif文件，如下图所示： 可以看到这个图片的坐标信息就自动进入了，而不需要你手动输入地理信息，如果你使用JPG或者BMP图片那当然是需要手动输入的，这也算是一个小小的技巧吧。然后就是选择坐标系啊、地图缩放的级别啊、版权信息啊、Google Maps API key啊什么的，然后就开始真的切割了，等待一会你就可以得到切割好了的地图了。 完成后大家赶紧来看看效果吧： 要知道这不是简单的仅仅是一个图片叠加在Google地图上面，你放大缩小加载的是不同的tile，而且和原有地图的叠加非常的好，因为我们配准了的嘛，但也必须要说MapTile这个软件的功能不可忽视。不过Google地图叠加tile的overlay的速度还是很慢的，除了本身图片加载速度可能有点慢以外，有可能GoogleMapsAPI就是如此，所以我们疯狂的延伸一下想法：将我的Google Maps API离线开发包中的Google地图替换成自己的地图，那么就真正的完全的离线并且是定制的地图了，期待看过此文的朋友能够完成这一壮举。 好了，最后给大家围观一下我的世博地图吧，毕竟在线的版本比本文的图片要实在：http://sharesh.cn/map/expo2010/ 三月份到此结束，时间过的真是太快，这个月仅贡献此一篇博文，希望能够给大家带来帮助。谢谢。

维基百科的资料非常不错，所以准备下载一些下来，本来以为都要自己抓取，但结果维基百科自己开放了所有的数据给你下载，具体可以参见这个页面： 维基百科的开放的态度是出乎我的意料的： 维基百科提供所有完整内容的电子档案给有兴趣的使用者。这些资料可以被重复使用，当作镜像站点，或是个人使用，或是资料备份，或是分析。所有维基百科文章都在知识共享 署名-相同方式共享 3.0协议下发布，图片以及其他档案则可能以其他的许可证发布，详情参见Wikipedia:版权信息。 当然，这样的开放是基于知识共享协议的，并且其中没有商业限制这一条。 大家可以去http://download.wikimedia.org/zhwiki/latest/下载最新的中文版的维基数据，其中前面几条的xml为最终的数据，不过这个xml仅仅包含了文字内容，并且是非常简单的文字内容，就像是简介一样，不是完整的页面。其余的压缩包的大多为数据库数据，当然这些数据库包含了页面信息文件信息等，由于太大我没有下载全部。顺便看了一下中文维基和英文维基的xml文件的大小，296M vs 2.6G，说明数据的差异有多大？由此可见我的分享上海众包计划没有进展也算是正常了。 我年前下载了2月2号的xml数据，今天最新的xml数据增加了3M。过年无聊就写了几行python语句，然后处理成了数据库，现在提供给大家下载。总数据条数为65536条，分成三栏数据，第一栏是名称，第二栏是维基百科的网页链接，第三栏是简要的说明，效果如下： 文件已经放在我的Google docs上了，不再限制文件类型我当然就用Google的作为免费下载空间了。地址：http://goo.gl/FZST (mdb格式，解压缩后86M) http://goo.gl/9Oei (xls格式，解压缩后17M)。 等等，还没有结束，再给大家送上一份维基百科的地理数据，就是带地理坐标的维基百科数据，啥时候下载的已经忘记了，哪里下载的也已经没有地址了，现在共享出来。要知道，这是一份全世界的地理数据哦，虽然从kmz文件来看只有6.5M，但如果解压缩出来的kml文件实际上为122M，如果你的电脑配置不够好，使用Google Earth加载这份数据基本上没戏，反正我是没有加载成功过，我只有通过其他软件打开，然后可以挑选出一部分数据来。从文件的日期上能够看到这个是08年初的一份数据，不知道原作者是如何提取出这份数据的，这份数据基本上就是Google Maps或Google Earth中显示的维基百科数据的离线版，不知道大家有什么好的方法下载维基百科的地理数据呢？我倒是想下载一些。而这份08年的数据实在是比较差的，可能和当时的维基百科数据量有关吧，但中国地区和国外地区的数据量差异也蛮大的，中国地区的差不多就只是一些城市的数据了，而城市内的位置信息(地标、公园、大厦甚至公司等等)基本上没有，其他国家的数据相对要比我们详细一些，看看中国的大城市上海的数据的稀疏程度就知道这是有多么的悲哀了： 好了，下载地址：http://goo.gl/HuMy 文件名为：Wikipedia_en_2008-03-12.kmz。

看了非常多的论坛地图插件和博客地图插件，总觉得不是很好用，不是安装太复杂就是使用太复杂，而且效果也是差强人意。最近在做MapURL.info的网站，就是一个通过URL分享地图的简单网站(详细介绍)，于是乎想把网站的功能搬到博客和论坛。其实，不管是谁开发的地图插件，基本上都是通过插入一个iframe实现，于是我做了iframe，而论坛一般会限制iframe，所以将iframe通过Discuz Code(UBB code也是同理)来实现，这样在论坛也就可以显示地图了。好吧，我们具体来讲解一下需求和操作吧。 我一般先想好需求然后再开始做页面，那么论坛地图插件主要实现的是什么呢？当然是显示地图。但地图有简单和复杂之分啊，那用数据库？我不想用数据库，因为数据库的操作不仅仅写代码太麻烦，而且使用的时候也会变的很复杂。其实细想一下，插入一份地图，最简单的就是一个marker，复杂的则可能有多个点或线等对象，对于简单的地图我们不使用数据库就可以实现，对于复杂地图难道一定要用数据库吗？即使用到数据库，也不一定完全能够表达出一个复杂的地图，或者由于操作的过于繁杂而让他人本身就不想放置一份地图了，不过，如果在本地通过软件先将复杂地图编辑好，做成一份gpx或者kml文件，也许是不错的。所以，需求就是显示一个地图，可以简单可以复杂，复杂的就通过加载gpx或者kml文件来实现，另外就是在发贴操作的时候要简单。而值得高兴的是，我在做MapURL.info的时候就已经实现了这些功能，大家可以通过帮助页面看到这几大功能，而我现在只需要在论坛中简单插入地图就可以了。 说了这么多废话回过头来说安装。如果说论坛本身支持iframe那么我也就没有写这个帖子的必要了，但虽然论坛不支持iframe不过我们作为管理员倒可以让用户插入iframe，这个方法就是通过自定义Discuz Code的方法实现。 进入论坛后台管理-界面-编辑器设置-Discuz!代码，新增一个mapurl的标签，如下图所示： 其中map.gif是一个图标，我做了一个，可以直接另存为map.gif到你的电脑，然后将map.gif上传到论坛的images\common目录下，当然你也可以自己定制一个。新增完成后点详情进行设置，如下图所示： 其中，替换的内容为：<iframe src="http://mapurl.info/if/#{1}" width="640" height="480" frameborder="0" marginwidth="0" scrolling="no" marginheight="0"></iframe>，就是一个iframe而已，而#后面的内容通过输入获得。设置完成这些后，你发表日志的时候就可以看到插入地图的按钮了。 点那按钮，然后输入地图控制代码，提交后就表示插入了一个地图。 效果如下图所示： 当然，你也可以插入其他一些地图控制代码，比如复杂的展示一个kml文件“[mapurl]wttghbcf7uxvm13-http%3A%2F%2Fmapurl.info%2Fyangchenghuchixie.kml[/mapurl]”，你可以得到如下效果： 更多地图控制代码可以通过MapURL.info中获得，我们提供了向导页面，按照向导生成代码即可，所有方法都可以通过帮助获得。 罗嗦的说了非常多，边聊天边写这篇日志，所以很乱糟糟，大家将就着看吧。如果有什么问题欢迎留言，我尽量解答。如有好的建议也欢迎提出哦。最后也希望我的MapURL.info网站能够给你带来一些方便吧。

花了大概两个星期的时间来做MapURL.info这个网站，起因很简单，偶然的路过了earthURL，并且惊人的发现人家的PR是5，不就是一个“Just copy and share the URL!”的网站吗，就是一个Google earth定一个位置然后将这个URL的链接发给好友，好友打开这个链接就可以看到地球的位置，就这么简单的一个功能，能够有如此高的PR，我嫉妒了。考虑到在IE或FF中浏览Google earth是需要安装插件的，有可能很多的朋友都没有安装这个插件，那么我就用javascript版的Google Maps API开发一个，做一个Map版的，一样可以copy and share the URL，而且还不需要特殊插件，于是MapURL.info诞生了。 今天我就这两个星期做MapURL的经历来讲一下功能和技术细节，当然，都很简单，算是对网站做一个功能告知，以及技术实现的细节。 earthURL网站的功能非常的简单，你移动Google earth改变中心位置或视角，你的网址(暂且这么错误的理解吧)就发生变化，你可以将这个网址copy下来，发推的时候带上这个网址人家打开就可以知道你推中所说的位置，当然你也可以通过邮件、即时通讯工具等来分发你要别人看的这个位置。MapURL也是照搬了这样的模式，这个功能算是最主要的功能。比如你打开这个链接http://mapurl.info/#wtw3sjmu5frzm14，就可以看到一个以上海为中心的地图，非常简单就可以分享给别人你所想的地图。另外，我还做了一些简单的扩展，就是支持iframe调用，这样的话你在自己的网站或者博客中插入一个地址为http://mapurl.info/if/#wtw3sjmu5frzm14(网址中多了if)的iframe，你的这个页面就可以显示地图了。 当然我同样照搬了搜索功能，可以通过名称、地址甚至经纬度进行搜索并将结果定位，如此强大的功能实现起来非常简单，主要是因为强大的Google。当你在搜索栏输入关键字或经纬度后直接回车，就可以给你定位到搜索结果的位置，当然，其实搜索结果是非常多的，但我们只取出了第一个结果，这也许是Google认为最匹配的结果。不过不要认为这样的搜索会变的很困难，很有可能不是你想要的结果，但强大的Google自有聪明的地方，比如你想搜索出徐家汇的那个东方商厦，你输入“东方商厦”，第一个结果不是上海的，很郁闷，但请不要气馁，当你尝试搜索“上海 东方商厦”的时候，这个东方商厦就是上海的了，不过还不是我们想要的徐家汇的东方商厦，于是我们继续尝试搜索“上海 徐汇 东方商厦”，结果惊讶的发现真的是我们所要的结果哦，可见Google的模糊搜索功能是非常的强大，顺便提醒一下，这个搜索是基于Google全世界(没有Google maps的国家另说)数据的，即使你搜索美国的一个街道地址，也是能够给你直接定位的，强大吧。不过这里我做了一个小小的处理，因为上一段我们只是分享了一个网址，比如这是徐家汇东方商厦的地图http://mapurl.info/#wtw37qs6r5n5m16，但没有任何的marker，这样即使地图放大到最大，你也不一定知道想要的啥具体对象，如果有一个marker应该更好，于是通过搜索的marker就此产生了，你可以分享这个网址http://mapurl.info/#wtw37qs6r5n5m16_%E4%B8%8A%E6%B5%B7%20%E5%BE%90%E6%B1%87%20%E4%B8%9C%E6%96%B9%E5%95%86%E5%8E%A6，其实就多加了一些将关键字编码了的网址(地图地址和关键字中间用_来链接，如果你不编码网址也一样，但编码后应该更具有通用性)，但可以搜索并直接出现marker，非常直观吧。 继续往下想，既然这样，那是不是有人希望能够在地图上留言一下？当然有，比如通过地图告诉人家说“星期天我们一起去逛东方商厦吧”，那么你只需要分享这个网址就可以http://mapurl.info/#wtw37qs6r5n5m16+%E6%98%9F%E6%9C%9F%E5%A4%A9%E6%88%91%E4%BB%AC%E4%B8%80%E8%B5%B7%E5%8E%BB%E9%80%9B%E4%B8%9C%E6%96%B9%E5%95%86%E5%8E%A6%E5%90%A7，当然我把话放在了URL里，中间用加号隔开了。这应该也算是一个比较实用的功能吧。 顺便提一下，如果你直接访问网站而没有任何地图定位的话，网站会根据你的IP地址计算一个位置并将这个位置设置为地图的中心，这样应该比较合理和贴切，不过不要指望太准确哦，等我以后使用Google的Gear定位来实现的话也许会更加准确，不过这个技术还在Google的labs里。 另外，希望后期能够加入更多的功能吧，比如直接在地图上发推，或者将推直接在地图上显示，甚至以后做个留言板。当然，我相信现阶段有很多这样功能的网站，除了我个人玩玩所谓的技术外，更希望能够加入一些创意提供一些不相同的内容或形式。后面还有计划加入专题地图，甚至想用Google maps API做一个类似百度地图的东东(这样百度不知道会不会气死)，当然这些都是虚无缥缈之事，等我实现后再说，不过感叹自己的三脚猫本事实在太差，写code还真不是我的强项，有哪位大大愿意帮忙？好了，废话多说，进入技术环节，其实主要是和大家分享一下我这两个星期碰到的问题。 不刷新页面来改变网址 这句话其实是错的，因为如果网址的改变就必定会带来刷新，只是有些时候是眼睛骗了我们。你拖动地图、放大缩小地图、改变地图视图等都会发现网址发生变化，但其实变化的不是网址，是hash，就是网址中#号后面的内容，原则上是用来定位锚标记的，但现在作为关键字做一些处理产生特殊作用，我们现在就用来定义地图的位置等信息。这个所谓的不刷新页面来改变网址的功能大家也可以在Facebook和安居客地图找房这两个网站上看到效果。而技术实现竟然是惊人的简单，通过document.location.hash就可以实现，一般当你在页面发生操作的时候，你去赋予它新的值，你就会发现不刷新页面也可以改变网址了，不过我强调一下这是欺骗眼睛的做法。 坐标位置编码成字符串(Geohash实现) earthURL网站有一套自己的将坐标位置变成字符串的function，但觉得不太好(因为越放大好像字符串越长)或者不实用(他可能考虑到GE的viewbox和视角吧)，所以没想用。然后我想到了早年写的MapBar中坐标的加密和解密(JS实现)，虽然说也是不错的方法，但我更想用新技术，大半年前看到的Geohash应该要派上用场了，并且用它的重要原因是坐标加密后得到的字符串是固定长度的。Geohash是什么？wikipedia上给出了最好的解释，是geohash.org网站作者写的一种经纬度编码方法，使用32个字符来表示经纬度坐标。经纬度坐标转换成字符串后，还可以将字符串反解成经纬度坐标，不过反解过后就成了一个bound了，好在这个bound的中心和你加密的坐标是一致的，小数点后六位是一致的，而经纬度用六位小数点表示也是最常用的方式了，而如果你只需要小数点后三位，那geohash编码后的字符串可以更加短一些。顺便要说的是，wikipedia上提供了基于python、PHP、Perl、Javascript等语言来实现的方法，图个方便就直接使用人家的JS库了，不过geohash.js在IE6下有点问题，不过修复也很简单，将53行的geohash[i]改成geohash.charAt(i)，将106行的BASE32[ch]改成BASE32.charAt(ch)，我就不提供修改后的文件给大家下载了。总的来说，Geohash很神奇吧，不过说来话长，还是推荐看一下K_Reverter的研究吧：关于geohash的简单探讨。 跨浏览器复制剪切板解决方案 如何将内容通过网页上的单击复制到剪贴板上(MapURL.info页面移动地图后底部出现网址的Copy按钮就是要实现这个功能)？看上去是一个超级简单的问题，但其实非常复杂，虽然IE可以使用一个简单JS语句实现，但好像也是类似控件的形式，并且浏览器的安全级别又不能设置太高，而其余的浏览器可能根本就不支持这样的方法，那么如何解决跨浏览器复制到剪贴板的功能呢？Zero Clipboard应该是现阶段大家认为最好的解决方案吧。使用方法可以看这一篇的中文介绍，我就不展开说了。另外如果使用jQuery的朋友可以看一下这个名为Clipboard的jQuery扩展，据说也是可以解决这个问题，实现方法个人觉得基本类似，大家可以继续研究比较一下，毕竟使用jQuery扩展的话应该使用起来要更简单一些。 通过IP地址定位你的地理坐标位置 通过访问者的IP地址定位地理坐标位置，这是一个非常有意思的功能，用户如果直接打开网站的话我就按照他的IP地址来设置地图的中心位置。那么如何实现呢？如果自己写程序来实现的话，基本思路是这样的：先从网上下载一个IP库，这个IP库带地址，然后通过地址反算出经纬度(可以使用Google maps API的反向地址解析功能)，将IP和经纬度存入数据库，然后写个程序访问数据库的接口就可以，当然如果你偷懒一些并且不担心Google反向地址解析速度的话倒可以实时解算出经纬度坐标。不过网上找了一下，IPinfoDB网站提供了现成的接口，我下载了他们的库，然后自己写了几行超级简单的PHP根据IP生成XML，然后用jQuery去解析这个XML就可以定位到地图上了。这里值得一提的是，IPinfoDB网站非常的慷慨，慷慨到让人惊讶的程度，除了提供给你XML API和JSON API调用外，还提供了实现这些API的source code和所有的IP数据库，也就是说你只要下载这份code和database你也可以架设一个和IPinfoDB一样的网站，一样能够提供API服务，不可思议吧，也许你会认为IPinfoDB很傻，但其实很聪明，一来人家是专门做这个的，你是肯定无法超越的，二是人家提供的source code不一定是他们服务器上的，试想IP数据库有300多M大小，有超过370万的数据记录，你用PHP直接查询一个数据库表，即使能够查询出一条来也不一定能够并发多少的量，所以IPinfoDB提供给我们code和database没用，你无法仿造它超越它，人家卖的就是服务，你要是频繁访问我的接口的话你就需要付费了，厉害吧，这就是不一样的商业模式。既然说到此，顺便提一下ip2location这一个网站，实现的功能和IPinfoDB完全一样，但做法不一样，人家使用PHP访问的不是数据库而是文件，数据库查询难免会发生瓶颈，而将数据库转换成特殊格式的文件，直接访问文件的速度也许要比数据库快很多(个人的猜想)，特别是针对大数据量的情况。而ip2location也开放source code，但人家不开放数据库，数据库文件你需要向他们购买。由此可见，模式不同，但结果相同，效果也是类似，我甚至怀疑ip2location和IPinfoDB是一家公司作出两套方案来让我们购买，所以同样的服务不同的商业模式值得我们深思。回到正题，使用IPinfoDB肯定也有不好的地方，一是国外网站访问速度会慢一点(不过我的站本身就布置在美国主机上，他们的速度应该不是很大问题吧)，二是国外做的IP数据库对国内来说肯定不是很全很准。不过先将就着用吧。另外，其实个人倒是想将IPinfoDB提供的数据库转换成文件，然后使用python解析，放到GAE上做一个公共的服务，不知道有谁有想并能帮实现的不？ 地址解析和Adsense地图广告 其实就是Google的两个class，具体可以看GClientGeocoder和GAdsManager，我基本上算是照抄sample的吧。 好了，技术也基本都讲完了，讲的有点多，本来想分成好几篇的，毕竟这个月只在月初发表了两篇，但想想还是整合在一起做成一篇并进行分段，看大家的各取所需了，希望能够给大家带来一定的帮助吧。 最后说一下MapURL的网址：MapURL.info。花了一美刀在GD上买的info玉米(现在GD支持支付宝支付哦)，第一次使用info，希望MapURL以后的PR也能达到5吧(先让我遥想一下吧)，更希望MapURL能够带来更多的地图方面的分享吧。另外做人不能言而无信，标题中说了提供earthURL的code下载，那就请猛击这里，你会得到这份code的，如想看这份code的演示，可以围观这个地址：mapurl.tk(使用免费的.tk域名做的演示，如有需要则也可以去dot.tk免费申请注册一个，没有太大的限制)。 顺便提一下我的“众包实验：《分享上海》出书计划”的进展，虽然已经历时近一个月了，但暂时还没有任何人投稿，也没有太多的人注意，难道众包真的在大陆地区推广不开吗？难道国人真的太懒太现实而不去分享不去创造精神财富吗？想到此，心里哇凉哇凉的，不过没有关系，最多大不了我一个人扛好了，至少，我还有我的坚持。但也不得不说，码字真的是件辛苦的事情，现在是凌晨四点，这篇五千字左右的文章，花了我五个小时左右的时间。看来，我需要进一步的思考了。

写这篇文字是由某大虾谈及Ophone屏蔽Google Map引起，文中谈到了Google Map和高德地图，讲到打开和放大地图速度，讲到定位和搜索速度，讲到导航和LBS，大部分观点我认同，但说Google Map用来导航高德地图用来LBS我是不认同的，我甚至认为高德地图的LBS功能都没有Google Map强大，Google Map为什么提供在线搜索更是LBS的必须。不认同归不认同，但同时引发了我对导航地图软件的易用性思考，作为一名GPS的从业者，什么样的导航地图软件算是好用的导航软件？以前写过一篇“手机导航：是服务，不是软件！”，阐述的似乎是道理，今天结合我自身的使用感受来说一下我认为的导航地图软件的易用性。这里需要说明的是，导航软件肯定是地图软件，但地图软件不一定是导航软件，至于手机上的软件，Google Map严格来说是足够用的了，只是也有很多我不满意的地方，但总体来说我是很满意的。 我用的是诺基亚6220c，为什么选它是因为我需要五百万的摄像头和内置GPS，虽然样子一般，做工也不太好，但满足我需求并且性价比好，所以我就只好选鱼而不能选熊掌了，如果你对我这机器有点兴趣可以看我入手一周后的综合评价。这个手机也算是智能手机(虽然大家对symbian系统评价并不怎么样)，所以我也装了很多软件，当然也包括导航地图软件，甚至还有一款被坑的不浅的垃圾地图软件(我在这里点名批评老虎地图软件，由于注册提示含糊不清导致被坑五块钱，别和我说就那几个钱，也别TMD那些托说老虎地图好用，被坑的不只是我一个傻瓜，做人要有道德更不用说是企业)，然而我真正使用的就两款软件，一款导航软件，一款地图软件，而用的最多的就是Google Map，就以此来说导航地图软件的易用性吧。 易用性思考一：软件打开速度要快。这是指在按下程序按钮到进入主界面这个过程，中间肯定加载了许多内容，这个速度的快慢影响用户使用感受，就和你使用电脑一样，按下开机按钮到进入桌面能够使用，如果是十分钟你能否承受？我现在启动电脑两分钟多我就已经很受不了。所以进入导航地图软件尽量控制在五秒以内。 易用性思考二：定位速度要快。话说一般GPS定位要一分钟以上，这是一个很难承受的数字，试想我要用到地图大部分是在有需要(比如迷路或找地方)的情况下，如果等半天都没有告诉我现在的位置，那我要地图要GPS有何用？手机的GPS芯片是很弱的，比PND的高感要差很多，不过好在能够使用A-GPS，虽然走点流量但速度快很多，在空旷的地方我基本在十秒左右定位，当然也需要手机的信号比较好。而Google Map值得表扬的是：能够通过基站定位，也就是说没有GPS也能定位，虽然误差大了一些但还算可用并值得使用的，对于香港这种高楼大厦过于密集致使GPS失灵的区域基站定位更显示出了易用性。如果在GPS定位前能够通过基站给你一个大概的位置，这应该是很贴心的考虑了。 易用性思考三：地图快。不管地图软件还是导航软件，其实地图和软件都是独立的，地图一般按照存储方式的不同可以分为在线式和内置式，Google Map地图软件和中移动的手机导航软件(泰为公司提供)都是在线地图，而凯立德导航软件则是内置地图。地图打开速度的快慢一般都是内置的快于在线的，因为不用通过网络下载。这也导致在线地图软件一个致命的尴尬，在没有网络的情况下，在线地图软件就成了废物。地图快不仅仅表现在地图加载，也表现在地图的缩放和拖动，手机的键盘(键盘有无)和屏幕(是否触摸)本身就有局限性，在这局限下如何快速缩放和平滑移动地图非常影响用户使用感受。Google Map的缩放是先将当前地图图片缩放，在地图加载的过程中没有让用户感受到地图空白，在小范围地图移动的过程中也没有地图重新绘制或突然空白。地图快是我使用Google Map而不用导航软件的重要原因。 易用性思考四：搜索的智能性。不管看地图还是导航，总要寻找目的地，如何智能并快速的搜索到目的地是一种考验。外置地图是将关键字发送到服务器然后服务器将结果返回到客户端，好处是服务器给你检索的，计算能力肯定比手机的CPU强，并且数据库是庞大的并且未知的甚至可以说是不断更新的，坏处还是网络问题。而内置地图情况恰好相反，没有不能搜索的情况，但地图数据也要不断更新才能搜索到最新的内容。而搜索结果的准确性和实用性非常重要，比如搜索浦东机场却找不到浦东国际机场，找陕西商务酒店却找到了一堆陕西省的商务酒店，找如家酒店第一个结果竟然离我十几公里远，可能第八九个才是离我最近的结果也是我要的结果。搜索有结果是第一(除非不存在。存在但地图中没有而导致无法搜索到结果是最郁闷的，就表示软件和我脑子一样，还是一片空白)，准确是第二，贴心是第三。 易用性思考五：信息的丰富性。传统的内置文件数据库查询出的结果往往是简单的结果，而像Google Map这样的在线查询软件给我们提供了更多的信息，除了名称地址电话外还有详细的介绍甚至评论，这些参考信息有利于判断搜索结果与我们目标需求的吻合性。Google Map不愧为集大成者，通过自己的引擎将网络上的信息整合到了一起，不断丰富不断扩大，而LBS的重要核心也正是这些丰富的数据。 手机除了电话和短信，在我们的日常生活中日益扮演着重要的角色，但在GPS和地图方面，手机也仅仅是一个方便的参考，不可能代替WEB地图和车载导航，而基于位置的服务(LBS)则渐渐凸显。如何让用户喜欢上你的软件，让自己大口大口啃LBS这块蛋糕，易用性应该是首要考虑的问题。我在去杭州的火车上，用手机写下了这些文字(可见手机还是很有用的)，算是个人在使用手机导航软件和地图软件的思考，欢迎大家继续探讨。

虽然还有一个多月的时间才过圣诞，但我还是早早的给大家送圣诞礼物了，那么圣诞礼物到底是什么呢？就是Google Maps API开发样例一则。不过这个礼物也不算是我送给大家的，而是谷歌地图中国的开发团队送给大家的，因为我也是从他们的GoogleCode上下载的，具体地址：http://code.google.com/p/chinamaps/。当然，这里有很多好的例子，甚至我在这里都能看到全国的公交数据信息，都心痒痒的想下载下来分析分析。今天正巧也有个朋友在日志上留言说起是否有样例提供，所以就翻了翻我很早SVN下来的这个code，东西很多，但对这个圣诞节地图的例子觉得特别完整，而且也确实非常的不错，应该说用到的内容很全面，甚至比我做的分享上海上的要好，我当时怎么就没有参考这个code的呢，纳闷了。OK，那么我为什么推荐它呢？因为： 1，JSON数据供稿。虽然现在提供的是静态的JSON，但我想随便改改就可以改成动态JSON供稿的，这样就可以学习Google maps API和JSON之间如何处理的了； 2，结果列表和地图marker部分如何联动。经常结果列表出来了，但浮动在结果列表上不知道地图上到底是哪一个marker，或者在地图的一个marker上但不知道属性结果是什么，记得以前在用mapbar的JS开发的时候就碰到这个问题，甚至到今天我自己来做也觉得有点头大，看看谷歌团队是如何来做的。 3，marker上的icon切换以及infowindows的tab显示。当然这些是小case了。 4，最后看看如何做搜索的，好像是JS搜索，虽然不是强大的搜索功能但值得一学。 说多了，反正我也没怎么看code，简单看一下觉得会code的人和我这样不会code的写出来的code确实不一样啊。最后来看一下效果吧，在线围观地址(临时)：http://sharesh.cn/map/XmasMap/，如果点击链接觉得麻烦，那么直接看下图即可。 最后，欢迎一起探讨学习GmapAPI，顺便说明一下，code版权归谷歌地图中国团队所有，我仅仅是搬运工。下载地址：http://files.cnblogs.com/Tangf/XmasMapDemo.rar

自从上次低调发布上海和北京地图后，其实也一直在想如何做的更好，这次将上海地图发布到我的分享上海的站点上去了，更新的内容也算较多，code也基本重写了大部分。代码是断断续续写的，加上自己不会code，所以整个弄起来很累，本来计划国庆七天好好做的，但中间这样那样的事情一直没有安心写code，直到最近觉得实在过意不去，所以决定在十一月份总该上线吧，总结下来觉得人的惰性还是蛮可怕的。OK，废话多说了，看图： 和上次的地图界面差不多，不过可能大家并没有注意到太多的变化，总的来说变化有： 1，将数据搜索和专题地图整合到一起，在不需要跳转的情况下可以搜索地图并访问专题地图。 2，数据搜索部分除了标准的数据(只有简单的名称地址电话等内容)外，增加了增值数据(就是有详细的内容介绍和图片等内容)，增值数据是特色的部分，也将是后期将持续增加的内容。 3，每一个增值数据拥有一个独立的页面，在该页面可以留言。 4，将原来的难懂的“显示当前范围内的POI”更改成“视野范围内搜索”，仿照了百度的视野范围搜索功能，但我并没有加入再次的查询，只做当前范围内分类兴趣点的列表查询。 5，增加了一个天气预报的小应用，不过仅仅是针对上海的天气。 大概的变化就这么多吧，那么用到了什么好玩的技术呢？算PHP+ajax吧，不过PHP就是实现读取查询数据库并显示为XML的功能，其余的作用不大，所有的功能基本上都是配合JQuery使用JS写成的吧。简单列举一下吧： 1，JQuery，这个大名鼎鼎的JS框架我就不用说了吧，我用它来完成了大部分的内容，特别是对xml文件的处理。JQuery确实简单易用，让我省掉非常多的事情，相比Prototype确实要简单许多。 2，jquery.pageFoot，是基于JQuery的分页插件，用于结果数量过多进行分页处理。虽然还有像jPage for jQuery的插件，但我最后放弃了，实现的原理不太一样，pageFoot插件仅仅是分页，不提取数据，而jPage需要用到全部的数据，关于这一点可能我理解有误，但我觉得pageFoot比较简单实用。 3，Google weather api，首页面为了学习百度使用天气预报点缀一下，所以用到了Google的天气API，这个本来准备用JQuery跨域访问的，不过失败了，最后只好写个PHP去读取Google天气API，然后直接输出到页面。 4，sNews，用来做增值数据的展示。这是一个CMS系统，不过是世界上最小的CMS系统，因为基本上可以说只有一个PHP文件，但却包含了CMS的绝大部分内容，一个简单的CMS，比如用来建立公司网页，用它绝对足够，除了没有tag功能外。不过由于sNews自身的限制，所以主要内容的改动相对来说不够灵活，现在看来我没有使用wordpress作为CMS展示是一个失误，看来还需要继续研究一下wordpress的数据结构。 大概就是这些内容了吧，不过也算是冲冲发布，问题在所难免，有些功能甚至都没有写(因为暂时还没用到)，下一步应该加入对gpx和kml文件的支持，最好的话能够整合wordpress，不知道大家有什么好的建议，欢迎给我反馈。最后附上访问地址，欢迎大家访问分享上海：http://sharesh.cn/

谷歌纵横(Google latitude)是什么我想大家都知道的，我也写过两篇和此相关的文章：谷歌地图移动版(Google Mobile Map)试用(附部分Latitude试用)和Google Latitude试用和思考(LBS之个人监控市场的兴起)。今天看到有人添加了谷歌纵横到了自己的博客中，以前见过添加到iGoogle小工具的，但没有看到添加到blog的，所以也想试玩试玩，不过这一试玩让我有了新的想法，就是如何使用谷歌纵横实现监控，当然，这个的想法其实在和一朋友聊天的时候就产生了，只是现在整体看来Google的技术很强大，能够实现监控的方式非常多，下面就和大家分享一下我的思路吧。 1，如何在博客中添加谷歌纵横 既然上面说到博客中添加纵横，那么我们也将这个实现方式告诉大家吧，其实非常简单，这只是谷歌纵横实验室的一个小产品而已，具体可以访问Google 公开位置显示图这个页面。在设置中启用位置信息即可，设置选项如下： 设置完成后就可以得到代码了，当然也可以进一步的进行设置，比如大小。 其实代码就是一个iframe，而这个iframe生成了一个以你的位置为中心的地图图片，嵌入到博客后的效果如下： 这个效果和iGoogle工具中的效果类似，只是更简单了。 PS：博客园的左侧自定义HTML中无法插入iframe，所以作罢，只好用在我的wordpress架设的blog中了。 而Google同时提供了两种公开位置显示的方式：“使用公开位置显示图的标准嵌入代码”和“使用 KML 或 JSON 供稿在您自己的应用程序中创建自定义体验” 其中，令我兴奋的是，提供KML形式分享位置信息，我认为这一点是可以做大文章的，具体下面的内容中会叙述到。 将谷歌纵横插入到blog后，你可是实时的被人家监控哦，而且是随便哪个访问你blog的人都可以看到你的位置，有担心隐私问题的请就不要添加啦。 顺便提一下，谷歌纵横实验室中还提供了Google Talk 显示位置的功能，就是你Gtalk中的个性签名栏显示你的位置信息，别人就可以通过Gtalk实时了解到你所在城市的信息了，不过意义好像并不是很大。 2，如何利用谷歌纵横实现监控？ 传统意义上的监控，是基于服务端和客户端的，是主控和被控的模式，主控主要查看被监控对象的位置，被控主要是实时分享自己的位置给主控。 而谷歌纵横和传统的监控又有所不同，可以说谷歌纵横既是服务端又是客户端，因为只要他共享位置给我，我就可以查看他的位置信息，如果我共享我的位置信息给他，则他同样可以查看我的位置信息，当然前提是我和他是谷歌纵横中的朋友关系，而关于“实时”的实现，也是很简单的，因为我们不是有手机版的Google mobile map吗？而手机版Google mobile map是可以添加谷歌纵横的图层的，具体可以看我的Google mobile map试用一文。 OK，那就具体的来说一下实现吧。 客户端：Google mobile map 下图就是我加入谷歌纵横后显示出自己的位置 当然在设置中需要设置成自动更新你的位置 这个的时候就可以实时分享你的位置信息了，当然有人说，那我要是退出Google mobile map是不是就不可以实时共享位置信息了？呵呵，不用怕，Google mobile map有一个非常可怕的功能，如下图所示： PS：如果你的他或她在你手机上运行了Google mobile map，然后退出程序的时候选择了否，你和他或她又是纵横的朋友，那么你就无形中被监控了，实时可以看到你所在的位置，可怕吧。这也是关于隐私讨论的比较多的，大家说法不一的地方。不过今天我们确实需要用这样的功能来实现监控，请不要用来做坏事哦。(当然，聪明的人看看GPRS的链接状态就可以看出不对劲的地方了吧。) 总的来说就是使用Google mobile map实现被监控，需要做的是：0，你的手机必须是智能手机且能够安装Google地图(这是废话了)；1，你们成为谷歌纵横上的朋友；2，打开实时更新你的位置信息的功能；3，保持程序为运行状态或者退出程序时选择否来共享你的位置。OK，被监控端就这么被实现了。 说一下被监控端的优势：1，不使用GPS也能获得位置信息(这个我在Google地图试用中已经提到)，虽然误差较大，但至少能够知道你的大概位置信息(只要你能收到基站信号，误差在几百米到几千米不等)。2，支持多种智能手机：Android/iPhone/BlackBerry/Windows Mobile/Symbian S60，大部分的都支持了吧。3，使用GPS的话精度可以得到很大的提高。 说完被监控的那来说说监控端吧，监控端的实现方式就多种多样了。 a，手机端的Google mobile map软件实现监控： [...]

这是四维公司在周四的时候做的一个小小的活动(由于一直有点忙，所以今天才整理此篇文章)，主要是讨论行人导航地图的应用与发展。由于我们经理比较忙，所以就让我过去看看。这次活动在蓝色港湾酒吧一条街的全明星运动餐厅(All Star)举行，环境还非常不错。 不过虽然说是一次产品推荐产品探讨，但请的全部都是媒体，泡泡啊中关村在线啊IT168啊爱卡啊等等都有到场，就我们是合作伙伴，感觉有点怪不过也算荣幸。当然到场的记者朋友们也比较熟，谁让我也算是在市场部门呢，公司与媒体的沟通合作自然是少不了的。沙龙的气氛非常的不错，主要是环境确实挺好。 虽然说沙龙上主要是行人导航地图的介绍，但也讲了比较多的其他的内容，首先当然介绍了一下公司，四维公司在今年上半年又是一个非常不错的佳绩，上半年的前装市场占据了67.79%，前装市场四维公司独大当然是没得说的，当然剩下的份额基本上是高德占据，这是在前装市场处于垄断地位的两家公司。而在手机市场四维公司占据了60.47%的份额，这一点Nokia的功劳肯定是不小的，出厂预装Nokia Map就已经占据了非常大的市场了。另外在互联网市场在08年达到了74%，可以说又是四维独大了，想想也是，除了Google使用高德公司的地图外，其余能叫上名的基本都是选择四维公司地图，当然现在没落的51地图另说，而互联网地图上占据较大市场份额(这一点我没有考证，但我所看到许多网站的应用基本上是Mapbar的，特别是以前搞城市代理和联盟的形式市场拓展比较好，当然现在Google Maps API日渐流行这部分市场Mapbar的份额将会减少)的MapBar选用的就是，而搜狗地图、微软地图(微软的地图我很少用)等等等都是四维公司的数据。 这次沙龙上比较感兴趣的是讲解导航电子地图的制作流程，以前一直想写一篇导航电子地图的介绍(主要是讲导航地图的数据组织和如何制作)，我想今天可以拿四维公司的导航电子地图制作流程作为开始了。我做了一下简单的记录，所以就简单讲上几点个人觉得挺不错的地方。首先是地图的演变或者区隔，简单的地图两字但内容真是千差万别，有纸质地图，纸质地图肯定是最早的地图了，因为计算机或者显示器才一百年的历史都不到(我说的没错吧)，而在这个的时代才会有所谓的栅格地图了吧，大家可能看到的比较多的也是栅格地图，简单的来说，就是将一份纸质的城市地图扫描到电脑，在电脑上看到的图片就算是栅格地图(我的理解大概是如此)，当然甚至我们看到的Google map等都可以理解为栅格地图，因为大家都知道Google map是将地图存储为了金字塔地图图片库，只是制作这些图片使用的是矢量地图，在后台的数据库中也保存了一份强大的矢量地图内容，甚至我们经常看到的基于C/S的Webmap系统也可以理解为是栅格地图，虽然后台是矢量地图服务器，但传送到WEB端的时候在服务器端生成了临时的图片，用户看到的还是图片(对于栅格地图的理解可能有些狭隘了)。接下来是三维模型结合遥感的卫星影像地图，这一点Google earth是最佳的推动者，虽然NASA有WW、微软有VE，但最普遍的还是Google的GE，应该说卫星影像地图也算是有很长一段历史了，只是大概出于军事使用等考虑一直没有让我们这些小老百姓看到。最后说到的就是非常特殊的导航电子地图，这个特殊主要在于什么呢？有很多的点，比如有关系到国家保密插件问题(这个是中国的特色了)，比如导航电子地图制作的难度问题等，导航电子地图的最特殊之处在于这个地图是可以导航的(废话)，导航两字非常重要，从我们国家有十家左右的导航电子地图供应商但真正占领市场的只有四维和高德两家就能说明做导航电子地图的不容易，这也是我想写导航电子地图介绍的主因(不过这个会上基本上都讲了)。 导航电子地图从形式上看有道路、背景、注记、POI组成，当然还可以有很多的特色内容，比如像Garmin任我游产品中的3D路口实景放大图、三维建筑物等，都可以算做导航地图的特色部分，只是导航地图归根结底就这四个部分组成(矢量的电子地图不就是由点线面组成的吗)，不过不要小看这四个部分，最难的就是道路了，虽然道路就是线，但如何在这些线上进行导航(也就是路径计算)，不是一般的难(不难也不会这么多公司都做不好了)。从功能表现上来看，导航电子地图需要有定位显示、索引、路径计算、引导的功能，不过这个讲的好像有点虚，或者说这些功能的实现除了需要导航电子地图作为依托外，也需要导航软件的支持，这四大功能可以说是导航软件的主要功能，首先需要有一个地图显示引擎将一大片以数字标记的数据库(就是矢量地图)能够显示，而定位倒是简单的读取GPS信息的功能，索引就是查询，导航导航要有目的地才能导航，而如何确定目的地就涉及到了索引，而需要制作索引的基本上是道路和POI，当然这里的索引个人理解有所片面，仅仅理解为了名称查询功能，在路径计算的部分可能也是需要所谓的索引存在，只是这不是表象的查询功能了。路径计算是导航电子地图的核心，许多公司做不好，很大的原因是核心做不好，所以地图市场为什么会有两家独大的局面，当然路径计算不仅仅是地图供应商的问题(主因是地图供应商)，还涉及到导航软件厂商的路径计算算法，即使同样的导航电子地图，甚至不同的公司做出来的路线是不一样的，这就要看导航软件公司的技术积累了。路径计算是一个导航软件或者说导航产品生死的关键，数据公司责任重大啊。至于路径计算道路应该如何组织会上并没有做介绍，我们下次简单讲讲一份导航电子地图的数据组织(大概是数据规格、如何矢量化等这些方面吧)。引导功能虽然单列了出来，但个人认为和导航电子地图的关系并不算太大，更多的应该算是导航软件的功能(只是还是需要路径计算和地图属性为依托)，引导功能大概基本上表现为文字引导、地图引导和语音引导(这是个人的理解总结，当然也可以扩展，比如甚至可以加上图片引导)，举例来说吧，你在导航软件中看到的“左转到某某路”这就是文字引导，听到说“左转到某某路”这就是语音引导，而你在地图上看到的用特殊颜色表示的航线，以及在作出机动的时候的箭头指示等都理解为地图引导，航线可以说是路径计算的结果，是在地图上的表现，而在语音和文字方面的内容是需要地图属性的依托，比如上面说到的“某某路”就是地图属性，比如“右侧出口前往上海方向”，这里的上海两字就需要地图属性依托。总的来说，不管对导航电子地图还是导航软件，用“定位显示、索引、路径计算、引导”四个词来总结还是非常到位的。 导航电子地图的组成说完了，那么如何制作一份导航电子地图呢？也许大家和我一样，理解为外业采集和内业处理，严格来说也确实就这两个主要环节，看看四维的总结吧：规格流程确定->基础数据的收集和处理(早期通过权威资料进行参考)->实地信息采集->信息录入->实地验证->理论检查、保密审查和数据转换->封库。四维的总结算是非常的严谨了，我们只是抓了一些粗枝大叶。一起来细说一下这个流程总结吧。首先是规格流程的确定，应该说这是导航电子地图的最关键的部分，上面说到的路径算法等其实都需要符合一定的规格，而制定一个规格标准更是关系到了整个导航电子地图的好坏，比如拓扑关系的组织。虽然每家都有自己的数据规格，但易用性、全面性等考虑都不一样，比如道路路口信息的处理这一点就是比较高深的学问(至少我认为这一点不容易)。规格算是核心中的核心了，没有规格何来数据，更是如何让导航软件公司使用数据？虽然国际上有什么GDF啊KIWI啊等规格，但国内的数据供应商还是有自己的一套制作标准，每家都有所不同，导航软件公司对数据的转换就需要解读这些数据规格。个人觉得GDF这样的规格看的真让人眼花，不容易理解，还是国内自己定义的规格比较容易理解一些，虽然各家的定义也不一样。基础数据的收集处理倒是我没有想到的，可能是忽略了吧，但细想也应该是必须才对，比如你要去某某地方旅游，你总会在网上找一些路线啊攻略啊什么，比如我就会先确定一下位置(时间不够的话太远肯定不会去的嘛)，然后查看一下路线，当然是否好玩等是第一位的，比如我不喜欢古迹什么的，像十三陵这样的古墓我想我是不会去的，这些所有的信息你肯定都是收集并是重要的参考，所以制作导航电子地图没有想到也是如此。实地信息采集就是我们理解为的外业采集，基本上都是车在外面跑，用GPS记录下轨迹，当然不是记录下轨迹这么简单，还有很多的信息需要采集，比如道路名称、车道信息、道路速度限制、是否单行道、是否双黄线等等等，太多的信息需要采集，这些是道路信息的外业采集，当然外业采集也包括了POI信息的采集，POI的采集可以在道路采集的过程中完成，也可以独立完成，毕竟道路作业的时候最多采集POI的名称，至于地址、电话等信息除了通过收集的资料外，有很多还是需要实际的进去询问。应该说外业采集是非常艰苦的工作，可以去看一下有篇介绍凯立德公司的外业人员一天作业跟踪的文章。外业采集完成后当然就需要内业的信息录入了，而内业不仅仅是字面上的录入这么简单，根据外业提供的信息录入名称等内容，而在道路限制等方面就涉及到了对规格的理解，如何在属性中体现出禁止左转这一内容，这不是根据外业简单的告知就能完成的工作，更需要对数据规格的理解。在外业采集和内业录入的部分，有些时候甚至是可以由内业录入代替部分的外业采集，比如在拥有质量非常好的卫星影像的情况下，道路就可以按照卫星影像制作出来，只是拓扑关系还是需要外业采集。实地验证就是对数据录入后的验证，当然导航软件公司的导航软件测试也可以认为是实地验证的一个部分。理论检查还是非常有必要的，就是按照规格，写一些工具验证属性是否符合规格，这些基本上都是必须的工作，一个连理论上都有错误的数据难道就可以直接提供给用户？而保密审查其实就是我们国家特色的一个部分，这里会涉及到许多保密内容的删除，比如军事基地，不过我们的国家似乎太过于严格了，严格到什么程度？比如北京新街口附近的二炮医院，其实都已经面向民用了但还是需要保密需要从导航电子地图数据中删除，而不对附属的幼儿园等都属于这样的情况，甚至所有的消防局，呵呵。数据转换不是简单的数据格式的转换，也可以说是数据规格的转换，我们作为非地图公司的人员，能够看到的数据规格，甚至包括所谓的GDF规格，其实是已经透明的成品的规格，而其实地图公司内部本身有更加细化的规格，这一部分的规格是不对外公开的，可能也是一个公司技术核心的部分吧。封库动作就不用讲了，但也算是四维公司严谨的一个方面吧，虽然我也认为数据公司并不严谨。封库的意思是地图数据即将发布，不再做任何的改动，这一版本的地图数据制作就算是告一段落了。 好了，今天就讲到这里吧，夜深人静花了两个小时写了这些凌乱的文字，本来写的题目是四维公司的导航地图推介沙龙，但最后改成了导航电子地图的制作，回看上面三大段确实偏离了我本来只介绍沙龙的目的，不过也好，一直想写的导航电子地图介绍就以本文来代替了，说的有点广和泛，也比较乱，但也算是给大家从头至尾讲解了一下导航电子地图是如何产生的，至于更详细的数据规格、数据处理等以后有机会再说吧。欢迎GIS界的朋友们一起交流。

声势浩大的Google2009开发者大会早就有所闻，只是像我这样的无名小辈是不敢想象去参加Google开发者大会的，上次我分享过两个Google开发的简介文档，这个大概也就是Google2008年开发大会的产物了吧，现在，Google2009大会已经顺利结束，今天再逛开发者主题网站的时候，发现他们已经为我们提供了这次大会的宝贵“遗产”，许多是开发者大会上的演讲稿和视频已经可以在线查看了，这样的话也算是让我们感受一些先进技术的气氛了，对于我来说，看看这些高人们介绍产品和技术，真是大为感叹啊，现在的技术真的已经是不等人的时代那，我这样的也许脱了裤子追都追不上那，就如同拥有傲骨的女生们一样。好了，废话多说，接下来说下我看了这些文档后的感想吧，算是随便的感叹一下吧，大家需要下载的可以登录Google开发者大会的网站，具体下载地址可以见这里：http://code.google.com/intl/zh-CN/events/developerday/2009/sessions.html 阅读的第一篇：GDD2009-Maps_Maps-API-Forum.pdf，开发者论坛经典案例。先是主讲人员的介绍，主要看到了Google地图的李双峰先生的真人照，原来是这样的啊，还有就是开发人员原来也有一些是长头发的吗。继续，第一个讲解的是wherefun这个网站，其实是一个旅游性质的网站，讲解的是旅行的行程、景点等信息，总的看下来其实和我一直理想的目标类似，就是上传航迹航点等进行分享，不过有些地方我也不是很喜欢，比如做那个所谓的动的路线其实个人觉得还是挺没有意思的，当然这仅仅是我的个人观点，因为我没有耐心看完这一路的行程，虽然时间也不会很长。最近看来也需要做这么一个东西了，看来wherefun算是我最好的参考了吧。然后讲了一个简单生活的网站，主要是信息服务类内容，看了下页面，看来也是我喜欢的样子，恩又是一个好的参考(唉，这年头看到好东西还真没有办法)，这里顺便也讲到了一些gmarker的应用，也讲了几个问题的解决，是不错的案例。在下面就是玩转房地产的网站，一个类似于在线房地产游戏的网站，不过我没有去过，也不是很感兴趣，对于房地产的网站个人倒是蛮喜欢安居客的按地图找房的风格，我想，有可能是比较类似的吧，就是拖动地图能够显示当前地图的房地产信息，动态显示，这可不是一个简单的事情哦，虽然我想的很简单，但在昨天晚上和一个朋友聊天后才发现这个的不容易处，此点就作为我们后期讲解的内容吧，但这一个案例中提到了marker的处理，对marker进行了扩展，特别是避免marker的重叠这是我蛮喜欢看的内容，不过没有太详细的介绍，看来后面要看视频内容进行回复了。然后是抗震救灾地图，这个其实个人不是很喜欢的，虽然说是Google的工程师做的，最重要的不喜欢是因为它是做在Google地图页面的，而不是一个独立的页面，当然这里讲到了一些tile的叠加等内容，还算不错，和我上次的世博地图有类似的地方，而叠加自己的KML文件这已经是Google API最简单的应用了，至于使用appengine来解析URL，这个想看一下的，不过没有细说，但应该也没有太多的大不了吧，要么存为文件要么存为数据库吧，这个是我猜的。最后是李大侠的Google map小工具集，也不太喜欢，因为我本身就不会太实用小工具，但作为开源的东西，还是有很多地方是值得借鉴的，而对于李大侠的开源内容，我们下一次来分享给大家一起学习，包括他们开发的公交查询系统。OK，这一篇就这么结束了，不过我没有看到Google maps API v3的内容在里面，可能后面的文档中有吧，继续。 下面看的一篇是Performance Tips for Maps API Mashups，这应该是老外讲解的吧，加上全英文，非常的难懂，不过好在讲解了一些Google maps API v3的内容，其中讲到了如何提高显示效率的问题，对于并发500个marker的情况(现阶段一个地图页面标注500个marker的话速度是非常慢的，浏览器甚至都会死掉，Google的算是优化的了，使用mapbar的JS基本上就不能操作了)如何处理，其实从Google现在的地图来看，可能已经应用了V3的技术了吧，你看查询结果显示出来的密密麻麻的点位，以及你放大和拖动地图后在地图上看到的公交车站点、地标建筑等，这些原来仅仅是地图图片中的label，现在都已经是类似于一个marker的内容了，因为你可以点击了，只是和marker不同，没有那么明显，应该来说是使用server端动态生成tile并叠加到Google map上，而至于clickable，这一点我就不清楚了，也许是动态img的area？不会使用这么低效的内容吧，有明白的大大请支一声。在这篇的下半部分，基本上都是演示了V3版API的强大，但V3版强大的确实有点超乎我的想象，本来以为大量marker并发就已经很牛了，结果这仅仅是九牛一毛，V3版在线、面等方面做了非常强的改进，当然也有marker等，而这强大到可以制作专题图，可以处理大量的并发和聚合，就是说V3版完全可以支撑超大数量级别的点线面等内容，加上能够制作专题图(制作专题图其实部分还是得益于点线面的优化)等，俨然是要抢ArcGIS等的饭碗吗。此文虽然提供了很多的样例链接，但由于在家无法上网所以没有在线参观这些链接，但从图片上看就已经让我觉得够震撼了，正如今天看到一个博文说Google appengine的真正意图是什么？其实是为大家提供一个统一的平台(mail、图片等各种本来需要系统内核的内容，现在全部搬到服务端)，以后用户只需要使用Google的chrome浏览器就可以完成所有的事务了，以后我们的开发看来真的只能做应用了，Google地图API的真正意图也许也在于此吧，为大家提供了强大的平台，脱离掉那些ArcGIS等需要硬件服务器以及软件和系统的平台吧，来我们Google的在线地图平台来跳舞吧，也许这是Google早晚有一天能够做到的事情。 接下来是李大侠的Google地图API高级应用，每年都是他来讲的嘛，看来我称之为大侠是没有错的。不过文档看下来倒不是很吸引人，因为讲解的基本上都是API的特性而已，可能用的人比较少而已，当然这些所有的实现你自己也可以实现，如果你本身就具有数据和服务器的话，只是Google现在都帮你做好了，而且直接使用Google的高性能服务器，多好。其实周边搜索、地址和坐标互解析应该不是什么难事，而路线规划完全是和服务器的交互完成的，至于自定义地图等就是叠加自己的tile而已，现在来说已经不是什么难事，看我的世博地图就能知道(下次讲解如何使用现有的工具制作自己的tile，上次的GMapImageCutter工具应该来说仅仅是一个简单低级的tile工具罢了)。下面说到的静态图片式的地图，这个来说个人觉得手机上比较有用，如果WEB端的话用处不大，毕竟WEB端的操作和网路快速显示等都不是什么问题。至于flash API和Earth API，第一个是因为不懂flash所以做罢，第二个的话应该和Maps API类似吧，只是装Earth plugin的人不一定多吧，所以在这上开发兴趣就不大了，不过对于专业的应用应该还是比较不错的，比如用于Web电力巡检等。其他部分也不知所云，就略过吧。总的来说这篇文章倒是有点炒冷饭的味道，算是温故而知新吧。 下面一片仍然是老外的Google API+手机端的文章，不过这一篇讲解的最多的还是API V3版，让我们更多的是看到V3的特性，快速应该算是V3版API最大的特色了吧，文章中总结了V3版的几个特色：1，加载的文件更小；2，适当的时候加载适当的内容(不再一次性加载全部内容)；3，优先显示一个图片然后再显示地图(至少让人先看到图片吧，这样才有耐心再继续下去)；4，更多的考虑到了手机端浏览器的支持(以后难道真的是手机的天下？不解)。顺便说一下本文中提到的几个个人觉得不错的地方，一个是建议使用JSON而不使用XML，因为看上去好像JSON的数据更加容易理解和解析，也许我也需要开始学习JSON了吧，毕竟它和JS的配合要比XML好非常多，另一个说到的小点是，气泡框会根据地图界面的大小进行自动的缩放了，就是说如果内容太多气泡太高长的话超过地图界面范围，就会自动将你的气泡压扁处理，恩，也许自己手工判断也能做，但既然Google添加了这个功能，那还不错。然后看到一个“No Keys Required!”，这个是让我惊讶的，不会是我理解错了吧。此文再加上我看的上面的第二篇文章，总的来说，我们对于Google maps API v3版还是非常期待的。 Google earth API一文我们就略过吧，介绍的内容和maps API类似，需要的话看看Earth API的文档就可以了。 最后一文是创建scalable地理程序。这一文的开篇就讲述了自己维护一个服务端有多难，然后告诉大家Google能够为大家提供什么？其中提到了三样重要的东西：app enngine(特别请注意看我本文的第三段的结尾部分)，Maps Data API，Google Base。强大啊。而Maps Data API有一个Feature写成了soon：Specialized spatial queries，这不会又要给我们惊喜吧。不过此文我是看不太明白，特别是后面的部分，看来Google这些东西整合在一起，理解起来也不是一件容易的事情，需要学习的东西还真是多啊。 好了，以上内容是个人边看文档边记录下的感受，算是鄙人晚上闲来无事的乱弹和分享吧，有兴趣的同学们赶紧也去看看吧，不管技术会不会，至少会开阔你的思路，当然Google如此强大让我觉得我们需要学习的东西还是非常的多，大家一起努力吧。本来准备将Google2009开发者大会中的所有文档读完和大家分享的，但就这地图文档读了我两个小时都不止，所以其他非地图方面的文档下次读了再来和大家分享吧。欢迎大家继续讨论。