使用openlayers调用本地瓦片数据方案

身边经常有一些朋友在与GIS项目的时候抱怨没有地图数据，而实际上他们在做具体的应用的时候常常仅仅是需要一个地图来使得应用程序变得更漂亮。以前自己也遇到过一些这些问题，在08年公司做兼职的时候，就行开发一个离线的GIS数据包，这些的话，对于一些小型的应用程序就不用花大笔的钱去购买地图数据。

对于以上的问题，大家常常采用的是两种解决方案：一种解决方案就是直接使用一些第三方数据服务，例如Google maps 或者是MapABC的API来实现自己的功能，这种方法开发比较简单，很容易上手，但是一个重要问题就是给一些不能上网的客户来说，这样的开发方式就不适合了；另外一种方式就是让客户购买地图数据去支持应用程序，这样的方式用户需要花一些钱去购买地图数据（我以前在做项目的过程中，由于地图数据量不是很大，所以也可以用一些基础图层，然后再加上一些影像数据进行数字化）。其实上述的两种方式是目前大多数应用程序解决地图数据的主要方法，下面本片文章介绍第三种方式来实现（特在此申明，文章中提出的方法仅仅是提供交流和学习使用，如果使用商业用途用户自行负责）。

如果想从本地访问瓦片数据的话，首先需要解决的问题是从一些公共地图服务中获取瓦片数据。在这里将使用工具http://www.daogle.com/?page_id=66下载地图的瓦片数据。瓦片数据下载到本地之后，可以看到瓦片的数据命名“m_14_13519_6253.png”，其中m后面的14代表的目前的缩放级别，“13519”代表的是瓦片数据的横坐标，“6253”代表的是瓦片数据的纵坐标。对于Google maps用的是墨卡托投影方式，将地图投影成了一个40075016.685578488 m的正方形坐标的形式，然后根据缩放级别将这个正方形分割成不不同粒度的小正方形，这种分割的形式采用的是四叉树索引的方式进行。具体的分割如下图所示。

首先在level 0级别的时候，就是将这个正方形划分为一个256 像素的图片，如果化成米的形式的话，就是40075016.685578488的正方形，从这里可以计算出比例为：40075016.685578488/256 = 156543.033928041 （米/像素）。对于level 1级别时，然后再将这个正方形划分为一个4个256像素的正方形，此时计算出的比例为：40075016.685578488/512 = 78271.51696402 （米/像素）。 Read the rest of this entry »

中国地名搜索引擎

中国地名搜索引擎是天津大学计算机科学与技术学院，信息系统与软件工程研究所自己研发的关于中国地名的搜索引擎。目前搜索引擎中已经有40多万地名数据，全国的大多数的地名已经能够检索到。目前这个小组有教师一名、博士一名、硕士三名，目前发行的是一个简单的版本，虽然数据不是很完善，但是我们正在整理相关的数据，数据会越来越全的。

介绍了这么多，自己已经不是那个小组的成员了，作为地名引擎的创始人之一，觉得这个将会是我们实验室做应急的一个重要的里程碑，为今后收集数据和应急情景数据的管理提供了直接的参考依据。

地名引擎

目前这个关于地名的搜索引擎叫做地名引擎，按照字面的意思就是按照地名来进行检索，其实这个在其他的网站上也可以看到相关的应用。我们所做的地名引擎的开始目前是为了管理我们实验室的数据，最后发展成为一个以地名为核心的知识系统。

截止昨天为止，我们的地名引擎可以看到的数据有地名的位置、相关的描述以及关于这个地方的相关的应急预案和应急案例信息，目前的功能相对来说比较简单，主要还是直接采用关键字做匹配的。我们实验室关于地名的本体也快发布出来了，今后的地名引擎的主要功能为会围绕着它来做。在接下来的功能中我们将会加入我们现有的一些数据信息来增加关于地名的相关知识，在昨天的讨论中，大家都觉得应该将个性话的部分加进去，所以到时候我还得花点时间来研究一下关于个性化的部分，按照目前关于个性化的数据的收集主要分为两个部分：一个是显式的去收集用户的喜好数据，比如让用户填写自己的兴趣、爱好和自己所从事专业方向，或者是在搜索结果中让搜索引擎去和用户交互；另外一种方式是隐式的去收集用户的数据，一般来说这种方法就是看用户点击了或者是没有点击哪条数据，然后分析用户所感兴趣的文档进行分析用户可能会对那些关键字感兴趣。个性化搜索加进去之后，还可以给用户做一些简单的推荐。 Read the rest of this entry »

界面设计

地名引擎的最后的功能还没有完全确定下来，目前确定显示的数据有：应急预案、应急案例、地名的相关介绍性数据和地图数据等。上两个星期自己主要是将程序的主要框架写完了，至于程序框架的合理性问题，目前只能是说按照目前的需求来写，并在此基础之上自己把有可能出现的问题先考虑进去。

其实我们在考虑做地名引擎之前，也看过不少的地名引擎相关的资料，其中也包括Google Maps,Baidu map,mapbar,mapabc和Sogou相关的地图搜索。他们的搜索都做的非常的强大，而且是和人们的生活是密切相关的。我们要做的地名引擎的主要目的是从知识的角度来思考，这个也是我们的地名引擎与现在的GIS搜索主要区别的地方，我们的最终结果是将与地名相关的知识展现出来。目前我们有的数据有地名数据（包括经纬度坐标和相关的介绍数据）、突发事件数据、湖泊数据、人口数据和气象数据等。我们地名引擎做的就是要以地名为主要搜索关键字，将与他相关的信息有组织的形式展现出来。

然而目前界面设计确实是一种很恶心的事情，我们实验室就缺乏这样的一个人，我做的界面大家都看的有点想吐了，颜色搭配太不协调了。不过我一直想想做一个类似于iGoogle那样的界面，而且用户可以根据自己对于信息喜好来管理需要显示的信息。如果用户在查看数据的过程中发现我们的数据有误，用户还能够对出错的数据进行修改，经过审核之后就可以将正确的数据展现出来。 Read the rest of this entry »

估计得忙一阵子了

自己这一年多来一直忙着实验室的那点项目，说句实话现在做的东西真的是很难投入使用，目前自己的总结原因有：开发氛围不好，简单的来说很多人都没有把这项目当回事（估计老板也差不多），所以从项目管理上很难入手；业务分析不够透彻，做软件产品的话，就必须得好好的分析一下实际情况，我们基本上是凭空想象。最近老板又让我做地名引擎，说句实话，我的兴致很高，就怕哪一天他对这个不感兴趣，我又是瞎折腾了。

目前总体上可以这么说，地图数据我们已经有了，至于这个地名引擎不在于地图本身，其主要是基于地名数据基础之上的。自己大概花了两天的时候好好的将自己要做的东西勾勒了一下，然后将自己第一期要完成的目标也确定了一下，最后定了一下关于地名引擎的技术基础。我们实验室是做应急方向的，所以我们做的地名引擎其主要的还是围绕着应急。关于这个系统我前面的工作主要是将把他当做一个系统来完成，解决问题的方法也主要是从工程的角度来思考（说句实话，在实验室做研究我实在是不怎么感兴趣，因为……）。第一期的主要目的就是将实验室目前的数据以地名为中心展现出来，其主要的开发的环境 Read the rest of this entry »