CN101114916A - 面向Smartphone的交通信息查询与点播的系统及方法 - Google Patents

Abstract

本发明涉及一种面向Smartphone的交通信息查询与点播的系统及方法，系统包括后台交通信息网格，Smartphone客户终端，无线通信网络。该系统提供了本地服务：在Smartphone终端对矢量地图数据的组织、请求、传输、存储，以实现本地服务请求；后台服务：Smartphone终端通过无线通信网络与后台服务器端实现实时通信，请求动态交通信息；后台交通信息网格服务器响应该请求，处理并发送数据；Smartphone终端接收动态路况数据，并根据路况数据绘制反映动态路况的变化地图，完成动态(静态)最短路径、动态路况展示、停车场查询等后台服务点播。本发明的有益效果为：在Smartphone上为用户提供了丰富的实时、动态交通信息查询与点播服务。实现一个良好的人—机交互界面，且操作简单方便。

Description

面向Smartphone的交通信息查询与点播的系统及方法

技术领域

本发明涉及一种面向Smartphone的交通信息查询与点播的系统及方法。

背景技术

随着当今城市的发展，交通信息在人们生活中占有越来越重要的地位，功能强大而且方便快捷的交通信息查询与点播方式已经成为迫切的需要。网格技术为交通信息的复杂计算提供了后台技术支撑，而PDA、Smartphone以及车载嵌入式系统等移动设备的应用则提供了便捷的查询平台，使人们随时随地都能对交通信息了如指掌。

Smartphone是微软提出的新一代移动嵌入式平台，它基于Windows CE 3.0操作系统，集成了PDA和移动电话的功能，提供了友好的人机交互和强大的数据处理能力。然而面向Smartphone的交通信息查询与点播还未得到普及应用。

发明内容

本发明的目的在于提供一种面向Smartphone的交通信息查询与点播的系统及方法，该系统以强大的后台网格服务为支撑，为用户提供实时、动态的交通信息查询与点播服务。

为了实现以上目的，本发明提供了一种面向Smartphone的交通信息查询与点播的系统，其特征在于：包括

交通信息网格，作为后台以提供实时的交通信息；

Smartphone客户终端；

无线通信网络，Smartphone与后台交通信息网格服务器端之间通过无线通信网络通信。

本发明还提供了一种面向Smartphone的交通信息查询与点播的方法，其特征在于：包括

本地服务：在Smartphone终端对矢量地图数据的组织、请求、传输、存储，以实现本地服务请求；

后台服务：Smartphone终端通过无线通信网络与后台服务器端实现实时通信，请求动态交通信息；后台交通信息网格服务器响应该请求，处理并发送数据；Smartphone终端接收动态路况数据，并根据路况数据绘制反映动态路况的变化地图，完成后台服务点播。

其中，Smartphone终端调用一次绘图函数完成一整条道路上所有路段所连接成的折线的绘制。

对地图数据进行纵向分层和横向分块，Smartphone客户端根据需要在操作过程中从后台交通信息网格节点中动态地请求部分地图数据；所述的纵向分层，即将路段在层次上分解为四种类型，即主干道、快速干道、次干道和支路，按照绘图比例尺的变化决定请求哪个层次的地图数据；所谓横向分块，即Smartphone客户端通过向后台交通信息网格服务器端发送一个矩形区域的方式获取所需要的地图数据；服务器端将所有包含在该矩形区域内的路口和与该矩形区域有交叉的路段发送回客户端。

Smartphone客户端每次生成地图时，将地图绘制于地图缓存位图上，该地图缓存位图的面积大于Smartphone屏幕的面积。

所述的地图缓存位图的上下左右各设有一个预取缓存区域，这四个预取缓存区域分别由四个独立线程绘制。

所述的地图缓存位图的长和宽均为Smartphone屏幕长和宽的2倍，面积为Smartphone屏幕面积的4倍。

所述的预取缓存区域的面积为Smartphone屏幕面积的2倍，预取缓存区域与地图缓存位图的连接处的边界长度相同。

本发明的有益效果为：在Smartphone上为用户提供了丰富的实时、动态交通信息查询与点播服务。实现一个良好的人-机交互界面，合理利用Smartphone的显示区域，将地图信息或服务响应准确、有效地反映给用户，且操作简单方便。

附图说明

图1为本发明的总体框图。

图2为与矩形区域有交叉的路段的示意图。

图3为地图缓冲示意图。

图4为屏幕超出地图缓存左边界调整示意图。

图5为地图预取示意图。

图6为有地图预取功能时屏幕超出地图缓存左边界调整示意图。

图7前台与后台网格平台的交互的流程示意图。

具体实施方式

以下结合附图及实施例对本发明作进一步描述。

一种面向Smartphone的交通信息查询与点播的系统，其特征在于：包括

交通信息网格，作为后台以提供实时的交通信息；

Smartphone客户终端；

无线通信网络，Smartphone与后台交通信息网格服务器端之间通过无线通信网络通信。

本发明还提供了一种面向Smartphone的交通信息查询与点播的方法，其特征在于：包括

本地服务：在Smartphone终端对矢量地图数据的组织、请求、传输、存储，以实现本地服务请求；实现地图的各项基本操作，即地图的显示、移动、放大、缩小等基本浏览功能。

后台服务：Smartphone终端通过无线通信网络与后台服务器端实现实时通信，请求动态交通信息；后台交通信息网格服务器响应该请求，处理并发送数据；Smartphone终端接收动态路况数据，并根据路况数据绘制反映动态路况的变化地图，完成后台服务点播。实现与后台服务层的连接以及服务请求的响应。在Smartphone终端上的需要支持的服务响应主要为动态(静态)最短路径、动态路况展示、停车场查询等等。

Smartphone展示平台需要实现的功能大体上可以分成本地操作的实现和后台服务的请求两部分组成。具体实施的总体框图如图1所示。

本地服务实现是指需要的计算量较小，可以直接在Smartphone上实现的部分功能，包括人机交互响应、地图拖动缩放、路名路口查询和后台服务请求展示。后台服务请求是指需要的计算量较大，在Smartphone上不能实现，需要借助网格的强大计算能力完成的功能，包括最短路径服务、实时路况服务和黄页信息服务。人机交互响应模块是响应用户对Smartphone的操作，完成用户指定功能。地图拖动缩放模块是在Smartphone屏幕上显示地图，并根据用户需要拖动地图或者放大缩小地图。路名查询模块是根据用户输入的路名查询道路或者路口，并把查询到的信息显示到屏幕上。

后台服务展示模块是把用户的要求转化为后台请求发送给后台，然后把后台传回的信息以友好的方式显示给用户。最短路径服务模块包括动态最短路径和静态最短路径。静态最短路径是查询两地之间距离最短的路径，动态最短路径是查询两地之间根据当前路况所需时间最短的路径。实时路况服务模块是查询当前的路况。黄页信息服务模块是查询某地附近的公共设施位置及使用状况。

为了解决Smartphone输入方式简单和地图操作的复杂性之间的矛盾，本系统精心设计了一整套适合于地图操作的输入输出接口，如用键盘模拟鼠标操作。为了解决Smartphone相对较弱的计算能力与地图的生成和现实需要的较大计算量之间的矛盾，本系统将重点放在如何在Smartphone上提高地图生成和响应时间上，如地图的缓存和预取等。本系统把用户的后台请求转换为SOCKET请求，发给服务器，并把后台网格平台传回的用户需要的信息(如实时交通路况、动态路径决策、公共设施查询等)以友好的方式显示给用户。

1)用户输入接口设计与实现：虽然Smartphone有很多PDA(个人数字助手，PersonalDigital Assistant)和多媒体娱乐、等多种功能，但本质上Smartphone还是以移动电话的功能为主。所以Smartphone的输入设备只有键盘，只支持单手操作(one-handed operation)。对于普通的移动电话为主的简单操作，Smartphone的标准键盘操作完全足够了。但对于交通信息查询所需要到的复杂地图操作(如地图的拖动缩放，道路和路口的选择等等)，标准键盘操作则显得比较单薄，远不如鼠标和触摸屏操作方便。这就需要重新设计操作方式，使之能适用于交通信息查询。在本系统中，我采用了模拟鼠标的方式来解决复杂地图操作的问题。即用键盘上的上下左右四个键控制模拟鼠标的移动，用“确认选择”键来模拟鼠标左键的单击和双击。对于0-9数字键，在地图操作中不需要，就可以把它设置为一些快捷键。

2)地图的显示和预取：

地图显示是本系统中消耗CPU时间和内存的部分，所以要想尽一切办法较快地图显示和速度，这是整个系统的关键。根据我们目前使用的由上海市交通局提供的上海市交通地图数据，共有14006个路口，21753个路段，如果每次拖动缩放地图或者其它操作引起的重绘都要画者20000多条路段，对于Smartphone这样的相对低速的移动设备来说，所产生的时间延时无疑是无法忍受的。

采取下面的一些策略来加快地图显示速度，减少绘制地图的延时：

A.一次画一条道路，而不是一次只要一个路段

对于Windows系统的GDI(Graphic Developer’s Interface，图形开发接口)，在一个设备上下文(DC)上画一个图形对象所需要的时间的数量级几乎是一个常量，图像对象的复杂程度引起的时间开销很小，常常可以忽略不计。所以要加快绘制地图的速度，可以通过减少图形对象数量，增加每个图形对象的复杂程度。

在一个设备上下文DC上画一个路段，实际上是调用Windows GDI函数PolyPolyline，画一条连接路段上各点的折线。一条道路由一系列首尾相连的路段组成，每个路段又是一条折线，那么就可以把这些首尾相连的路段所代表的折线连起来，组成一条更长的折线，只用一次调用PolyPolyline函数画出一条连接道路上所有路段上的点的折线，而不是画道路上的每个路段时都调用一次PolyPolyline函数。这样就增加了每个图形对象的复杂程度，减少了图形对象的数量，加快了绘制地图的速度。

B.根据需要动态地请求部分的数据，即地图纵向分层、横向分块的策略。

a.所谓纵向分层，即将路段在层次上分解为四种类型，即主干道、快速干道、次干道和支路。按照绘图比例尺的变化决定请求哪个层次的地图数据。

当比例尺较小时，只需要画出主干道，而其它层次的道路不用画出。当比例尺逐渐放大到一定程度，则需要画出主干道和快速干道，次干道和支路不必画出。依此类推，当比例尺放大到足够大时，所有层次的道路才会需要被画出。

b.所谓横向分块，只有与要显示区域矩形有交叉部分的道路才会被画出，其他道路不必画出。所谓“与矩形区域有交叉”是指道路的“闭包矩形”与要显示区域矩形有相交的部分。

如图2所示，上面的一条道路与要显示区域矩形没有交叉部分，所以不需要被画出，席面的四条道路，中间一条被矩形完全包围，其他三条和矩形有交叉部分，它们都需要被画出。

采用地图纵向分层、横向分块的策略，当比例尺较小时，虽然要显示区域较大，但只有等级较高的道路会被画出，等级较低的道路则不会被画出，也就是只有一小部分道路会被画出；当比例尺较大时，虽然一些低等级道路也会被画出，但要显示区域却较小，与该区域矩形有交叉部分的道路比较少，所以仍然只有一小部分道路会被划出。

这样就大大减少绘制地图时图形对象的数量，加快了绘制速度。

3)地图缓存

虽然以上两种方法显著减少了绘制地图时图形对象的数量，但即使这样，绘制一次地图的延时仍需要几秒钟。如果每次移动地图或者其它操作引起的窗口重绘，都需要重新生成一次地图，这仍然是无法忍受的。

所以我们采用了地图缓存的办法来减少地图生成的次数。地图缓存实际上一个比屏幕尺寸更大的一张位图，每次生成地图时，不直接画到屏幕上，而是画到这张位图上。每次重绘时，只要根据屏幕与这张位图地相对位置把位图的一部分画到屏幕上，而不需要重新生成地图。只有在屏幕的位置超出了这张位图的范围时，才需要重新生成地图。

在本系统中，地图缓存的大小为屏幕大小的4倍，即宽度和高度都是屏幕的2倍。

如图3所示，中间的小矩形表示屏幕矩形，设它的宽度和高度分别为SW(Screen Width)和SH(Screen Height)。外面的大矩形为地图缓存矩形，它的宽度和高度分别2×SW和2×SH。屏幕和地图缓存的的相对坐标{x，y}为屏幕矩形的左上角与地图缓存矩形的左上角距离。初始化时或者在刚缩小放大地图后，屏幕在地图缓存上的相对坐标为{SW/2，SH/2}，表示屏幕在地图缓存的中央。移动屏幕实际上是移动屏幕在地图缓存的相对坐标，每次重绘时，只需要把地图缓存上以屏幕相对坐标{x，y}为左上角，分别以SW和SH为宽度和高度的举行区域画到屏幕上。屏幕在地图缓存上的相对坐标横轴的范围为0-SW，纵轴的范围为0-SH。当相对坐标超过这个范围时，就需要重新生成地图，并且调整相对坐标。

如图4的左半部分所示，当相对坐标{x，y}的横坐标x小于0时，即屏幕超出了地图缓存的左边界，就需要地图缓存的矩形范围向左移SW，重新生成地图，同是相对坐标也相应调整为{x+SW，y}。如图4的右半部分所示，虚线矩形表示调整之前的地图缓存矩形范围，实线矩形则表示调整之前的地图缓存矩形范围。

同理当相对坐标{x，y}的横坐标x大于SW时，即屏幕超出了地图缓存的右边界，就需要地图缓存的矩形范围向右移SW，重新生成地图，同是相对坐标也相应调整为{x-SW，y}。当相对坐标{x，y}的纵坐标y小于0时，即屏幕超出了地图缓存的上边界，就需要地图缓存的矩形范围向上移SH，重新生成地图，同是相对坐标也相应调整为{x，y+SW}。当相对坐标{x，y}的纵坐标y大于SH时，即屏幕超出了地图缓存的下边界，就需要地图缓存的矩形范围向下移SH，重新生成地图，同是相对坐标也相应调整为{x，y-SH}。

4)地图预取

大部分时间地图只是在小范围内移动，如果采用了地图缓存，大部分时间内不需要重新生成地图。但是，当屏幕与地图缓存的相对坐标超出范围时，还是需要重新生成地图。对于用户来说，前面的地图移动都很流畅，但在边界处突然停顿几秒，然后才能继续移动，这也是很不友好的。所以，我们必须想办法消除地图缓存在边界处重新生成地图对用户造成的影响。地图预取就是为了解决这个问题而采用的。

地图预取是指，在地图缓存的基础上在加四个预取缓存(预取缓存和地图缓存一样，实际上也是一张位图)，如图5所示，上下两个预取缓存宽度和高度分别为2×SW和SH，生成紧邻地图缓存矩形范围且在其上方和下方的部分地图，左右上下两个预取缓存宽度和高度分别为SW和2×SH，生成紧邻地图缓存矩形范围且在其左方和右方的部分地图。

四个地图预取缓存分别由四个独立线程在生成，线程优先级低于主线程，所以不影响地图本身的操作，只在系统空闲时，预先生成部分地图。当屏幕在地图缓存上的相对坐标超出范围时，如果它所需要的部分地图已经预取，就不必再生成地图，而是直接把这各预取缓存画到地图缓存的合适位置，并调整向对坐标的值。这样，在屏幕的相对位置超出范围时，也不会出现突然的停顿，是地图移动过程比较流畅。

如图6所示，当相对坐标{x，y}的横坐标x小于0时，即屏幕超出了地图缓存的左边界，如果左边的预取缓存预取已经完成，那么先把地图缓存的右半部分画到右边的预取缓存上，然后把地图缓存的左半部分画到地图缓存的右半部分上，最后把左边的预取缓存画到地图缓存的右半部分上，这样地图缓存的重绘就完成了，同时使右边的预取缓存仍然有效，不需要再重新预取，而其它三个预取缓存则因为重绘地图缓存而无效，需要重新启动预取。相对坐标的调整与没有地图预取功能是相同。当左边的预取缓存预取还没有完成时，就需要先提高左边的预取缓存预取线成优先级，使它能够尽快完成，等待它预取完成后才能进行上面的操作。虽然，这也可能会使移动操作不流畅，但一般来说，从一次地图缓存重绘到下一次重绘，中间会间隔一段时间，在这段时间里，预取操作一般都会完成。即使因为预取还没有完成而等待，在此之间它已经完成了一部分地图的生成，所需要等待的时间也比重新生成地图要短得多。从概率上讲，如果屏幕超出了地图缓存的左边界而重绘地图缓存后，那么下一次重绘最有可能用到预取缓存仍然是左边的那个，因为用很有肯能是一直按住左移键，连续发生屏幕超出了地图缓存的左边界而重绘，所以把左边的预取缓存的预取线程的优先级设得比其它两个无效预取缓存的预取线程高，但仍然低于主线程的优先级，因为预取只是一个提高效率的辅助手段，不能影响正常的操作。

同理，其它三种屏幕超出了地图缓存的边界的情况也类似地，利用预取缓存重绘地图缓存，并是其中三个预取缓存无效而重新预取，最后屏幕在地图缓存上相对坐标的调整与没有地图预取功能是相同。

初始化时或者地图放大缩小时，先只在地图缓存上生成地图，四个预取缓存都无效，然后启动它们的预取线程，开始预取，线程优先级相同，但都低于主线程由优先级。

以上是本系统采用的四点加快地图操作响应速度的策略，从实际效果来看，的确起到了加快响应减少延时的作用。

与后台网格平台的交互：本系统为用户提供的实时交通系统(实是路况，最短路径，黄页信息等)，都是由后台网格平台经过海量计算后得到的。

本系统的接到用户的操作后，判断时候是否需要后台服务，如果不需要则直接完成本地服务后更新地图。若需要，则先根据用户的操作生成数据服务请求数据包。如果当前GPRS还没连通，还需要连接GPRS。然后与后台网格平台建立SOCKET连接，并向后台发送请求数据。由于与后台采用异步请求模式，发送请求之后直接返回，继续等待接受用户操作。后台网格平台接收到请求后，经过网格计算，将结果的响应数据传回本系统。本系统根据后台发回的数据更新地图，把结果显示给用户。流程图如图7所示。

Claims (8)

1.面向Smartphone的交通信息查询与点播的系统，其特征在于：包括

交通信息网格，作为后台以提供实时的交通信息；

Smartphone客户终端；

无线通信网络，Smartphone客户终端与后台交通信息网格服务器端之间通过无线通信网络通信。

2.面向Smartphone的交通信息查询与点播的方法，其特征在于：包括

本地服务：在Smartphone客户终端对矢量地图数据的组织、请求、传输、存储，以实现本地服务请求；

后台服务：Smartphone客户终端通过无线通信网络与后台服务器端实现实时通信，请求动态交通信息；后台交通信息网格服务器响应该请求，处理并发送数据；Smartphone客户终端接收动态路况数据，并根据路况数据绘制反映动态路况的变化地图，完成后台服务点播。

3.按权利要求2所述的面向Smartphone的交通信息查询与点播的方法，其特征在于：Smartphone终端调用一次绘图函数完成一整条道路上所有路段所连接成的折线的绘制。

4.按权利要求2所述的面向Smartphone的交通信息查询与点播的方法，其特征在于：对地图数据进行纵向分层和横向分块，Smartphone客户端根据需要在操作过程中从后台交通信息网格节点中动态地请求部分地图数据；

所述的纵向分层，即将路段在层次上分解为四种类型，即主干道、快速干道、次干道和支路，按照绘图比例尺的变化决定请求哪个层次的地图数据；

所谓横向分块，即Smartphone客户端通过向后台交通信息网格服务器端发送一个矩形区域的方式获取所需要的地图数据；服务器端将所有包含在该矩形区域内的路口和与该矩形区域有交叉的路段发送回客户端。

5.按权利要求2所述的面向Smartphone的交通信息查询与点播的方法，其特征在于：Smartphone客户终端每次生成地图时，将地图绘制于地图缓存位图上，该地图缓存位图的面积大于Smartphone屏幕的面积。

6.按权利要求5所述的面向Smartphone的交通信息查询与点播的方法，其特征在于：所述的地图缓存位图的上下左右各设有一个预取缓存区域，这四个预取缓存区域分别由四个独立线程绘制。

7.按权利要求5或6所述的面向Smartphone的交通信息查询与点播的方法，其特征在于：所述的地图缓存位图的长和宽均为Smartphone屏幕长和宽的2倍，面积为Smartphone屏幕面积的4倍。

8.按权利要求6所述的面向Smartphone的交通信息查询与点播的方法，其特征在于：所述的预取缓存区域的面积为Smartphone屏幕面积的2倍，预取缓存区域与地图缓存位图的连接处的边界长度相同。

Images