为什么要取这样的一个题目呢？主要是因为今天去了一家公司和他们谈了谈，本来是指望做兼职的，谈到最后当然是不成了。去谈的是地图制作(可兼职)一职，要求是地图制图经验，最后加了个有WEBGIS开发经验。本来想自己毕业设计做的就是WEBGIS，而且对WEBGIS很感兴趣，最主要的是我从事的便是地图方面的工作，合情合理。最后谈下来是不需要我去制图而是需要我去搭建一个WEBGIS平台，跟他们谈了下MapInfo公司和ESRI的平台中间还谈了超图公司的平台还谈到了MapBar这样的地图网站，最后呢选择了象MapBar这样的平台(也不能算平台，只能说是原理)，因为他们本身的WEBGIS要求比MapBar还要简单。为什么不成我想现在也明白了吧，我是主攻地图数据这块的，让我搭建平台也行，但程序我就不行了，要是我会程序我早就把MapBar这样的网站给研究出来了。
其实两者的平台完全不一样，一个是基于矢量地图的发布一个是基于栅格地图的发布，个人觉得速度是栅格的要快，因为象MapBar这样的纯粹是把地图切割后无缝拼接(为什么要家个无缝呢，看灵图的地图就知道了，灵图的地图是有缝隙的)显示吗(我指的是MapBar的博客地图以及提供给百度的地图的实现部分就是运用这样原理实现的，但MapBar和MapABC他们的主平台并不是用这种原理实现的)，其实象Google Map API、灵图的API、E都市等网站实现的原理都是这样的，至少他们在客户端是这样用JS方法实现的，就那么四五千行的JS代码吗，其中线面状的图完全作为底图，图上看到的部分点也已经是图片了，不就是在MapInfo或者ArcInfo中将点线面的标注打开然后分幅保存成栅格图就OK了，地图显示部分就解决了，关于放大缩小在不同比例尺下显示那就是不同比例尺下截取不同的图而已，大比例尺截的图非常多，小比例尺就比较少了，不相信你自己可以下载MapBar里的世界地图，就是显示全世界的图，清空你的IE临时文件夹，然后拖拉世界地图看一遍整个世界地图，然后你再到你的IE临时文件夹去看，就是那么多幅的世界地图而已，大比例尺就很多了我就不多说了。至于查询到的点等信息，完全是建个数据库，这个数据库就比较丰富了，你可以包括点的名称信息等(比如公司名称公司介绍公司地址网站连接等等)，这个其实很重要，如果你在这个数据库上可以翻出花样来说不定就可以赚钱，但是，这些点需要两个最基本的字段，就是X坐标和Y坐标的值(可能是一个值，进行了加密的缘故吧)，至于样式什么的就简单了，你完全可以建个TYPE字段各个值对应一种样式就OK了(比如google提供的点有不同的颜色，我所说的样式便是指这些)。有了XY值就简单了，从数据库中读出来然后丢给JS就可以让JS在地图上标出准确的位置了，至于显示气泡框等这样的也就是数据库里传几个值让JS执行下就OK了(这里可以用对查询到的数据生成XML让JS读取或者用JSP等读取数据后直接生成JS代码，如果使用SQL server就很简单，一个查询语句就可以生成XML让JS调用了，超图的IS就是读XML数据的)。关于公交路线和驾车路线，这个比较麻烦，最短路径的算法我到现在还是不会，但有一点是可以肯定的，就是生成的路线其实是很多的点，把各个点连接起来就是线了，不相信你可以去百度地图着个换乘的路线看看，只是这个如何使用JSP来实现计算的我就不太清楚了。一个简单的WEBGIS模型就成型了，简单不？
可惜我不会技术那，所以我要一边骂技术更新太快而且不值钱一边骂自己水平太菜(其实也不能说技术更新太快，比如AJAX，其实就是JS+XML等，几年前就在大富翁论坛讨论过了)。所以我今天把这个框架写出来，希望这里的朋友能够联合起来成立个团队，写出自己的JS或者把MapBar的JS研究出来，并发布自己的API，搞定地图，写出网站程序，把这个WEBGIS平台给搭建起来，希望开源并能够运用到中小企业(当然这些需要在一份详细的计划书的前提下)。有兴趣的朋友可以多多讨论。
重点难点：
一：吃透JS代码(这JS代码里已经包含了放大缩小平移以及测量画线还有双击移动到中心等，地图显示部分就是完全靠这么多的JS)；
二：地图数据部分，坐标问题，如何转换，如何切图，切图后如何命名等，还有特殊点的坐标信息等录入数据库(需要根据JS里的算法以符合JS的算法，这是基础数据部分，看到的地图就是地图数据)；
三：网站程序部分，读取数据库，生成JS或者XML等。
讨论：
一：我上面所说的框架是否正确并可行？
二：从技术、速度等方面讨论基于栅格地图和基于矢量地图的WEBGIS优势和劣势，以及各平台的优劣。
[更新：Google Maps带来的新型WebGIS设计模式]
看了这篇文章觉得非常的好，非常的有深度，所以转了下，来自二度空间。
原文索引：http://spaces.msn.com/members/gemtang/Blog/cns!1p8Kzn8ffRJpPVVp4vlG3Vxg!195.entry
以下是引文：
其实早前我就说到Google Maps带来的轰动效应背后，少不了基于客户端浏览器的图片缓存技术的支持，我认为这是一种技术革新——因为任何常见的WebGIS商业产品都没有此种地图展现方式。Go2map其实也很早就运用了该技术（去年推出新版本的VIP地图服务时），不过该地图服务仍然是基于MapInfo产品线的，不是很漂亮和高质量（起码跟Google比起来，道路少了灰色的border），而且界面稍显复杂（个人感觉）。使用客户端图片缓存后，很好的缓解了中心地图服务器的压力，要知道以前在Go2Map上查询北京的公交老是等待超时。仔细分析一下Google Maps的内部机制（从界面上的操作体验中也可推断），此种WebGIS系统真的与以前的ArcIMS、MapXtreme等二次开发出来的系统有着本质的不同： 地图预先生成，这一点是首当其冲的，说了很多次了。 地图切片，客户端同时下载。当地图窗口发生移动、缩放时，便需要下载新的图片来填充新的区域，在这里充分利用了浏览器（如IE）的多线程同时下载的功能，另外，下载过的图片无需再次访问服务器下载。缺点就是客户端编写需要大量脚本来支持。 由于服务器不是实时地根据矢量数据生成地图图片，就造成了地图数据无法及时更新。但若仔细察看，不难发现Google Maps上的数据其实大部分是道路交通、行政边界，其他的POI(Point Of Interests)信息并不是固化在地图上的，如此便使人觉得地图稍显单调，好在高质量的卫片影像弥补了此不足。Google通过客户端脚本技术，把用户的搜索结果（也就是各种POI数据）以“大头针”图片的形式展现在客户端浏览器上，比如有名的官方Pizza店示例。反过来一想，还真得佩服Google的设计：POI数据是经常更新的，而基础数据（Framework dataset，比如高级别的道路、桥梁、城市、湖泊等）则是很少变动的，即便是某些小道路发生变化，也可以很方便的生成该范围的地图斑块，这个工作量是较小的。 上面提到了POI数据，其实它是动态生成的（当然，也可以是静态的），这个怎么说呢？好比Google的网络爬虫找到了某个公司的门户网站，分析出了该页面的内容结构并找到了其联系方式：##,**Road,**City，通过Geocoding技术便可在地图上找到其位置。 由于地图图片的预生成，以前的WebGIS站点经常提供的“图层控制”功能便无法达到，其实，这个并不影响用户的使用体验——Google地图是如此的清晰明了，用那玩意儿干啥？ 抛弃“鹰眼”窗口，也就是那个缩略图，可能有人觉得用起来不太习惯——因为你不知道目前浏览到具体哪个位置了。但是，想想看：全世界的地图，当你放到到很细节的地方时，鹰眼上的显示框会多么的小啊，丝毫没有意义。 在地图上弹出Info Window以显示详细信息，底层实现使用了XML和XSLT，的确在界面上和视觉上给人以冲击，而且这也的确是一个好主意——既很好的节约了页面空间，又方便了用户操作。 “图中图”。该功能可谓煞费苦心，看看人家就是做得细致，在弹出的Info window中还有一个小地图来显示周围的情况，还可以在小地图上进行缩放，有点儿类似放置了一个放大镜在那里，真够绝的。 疯狂的运用Javascript脚本，恰好现在的Web设计又回归Javascript，特别是自AJAX的流行以来，似乎有唤醒了大家对浏览器端的脚本的重视。Google Maps的脚本可不是一段两段，而是超过了万行，就拿它在客户端显示路径这个功能来说，就必须牵涉到XML解析、路径数据的转码（Google在传输路径的位置坐标时作了编码处理）、VML渲染、如果非IE则需要访问服务器以便让服务器程序画出路径并回传图片……如此林林总总，不一而足。 Google在中国的本地搜索服务也推出了Beta公众试用版了，而且北京地区的图也很详细，我想最大的困难也许就是国内的地名解析吧，要知道国内的门牌号、街区号、邮政编码都不是划分的很清晰，这个属于城市规划建设的问题了~GIS发展至今，经历了System-Science-Service几个阶段的蜕变，而且这三个过程的界线愈发明晰，象现在，就有人在做System，有人在做Science，有人在做Service，其实归根到底，它仍然是一种IT技术，个人认为无论搞科研，还是搞软件开发，又或者你是搞服务圈钱，都与计算机和网络是分不开的，不结合计算机技术，是搞不出任何新花样出来的~ 不多使用人家的软件，不多多看人家的代码、不多多多上人家的网站，就不知道人家究竟在捣鼓啥？