英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料
TRAVIC：公共交通轨迹数据的可视化客户端
摘要
我们介绍TRAVIC，一种基于浏览器的客户端，可以在地图上显示平滑的车辆运动。 重点是以交互方式对全球公共交通车辆运动进行可视化。 但我们也研究了其他用例，例如传输模拟。 我们详细描述哪些服务器请求是异常的，以及接收的数据是如何处理的。 我们还提供在多个浏览器上进行的性能评估。 我们证明，与有效的后端相结合，TRAVIC能够实时显示数以千计的车辆动作。 我们的原型实现可以在http://tracker.geops.ch下访问。
类别和主题描述符
H.3.5 [信息系统应用程序]：基于Web的服务
关键词：
实时可视化，时空查询，公交网络
1.引言
现在可以以网络应用的形式提供各种车辆的实时地图。 例如，瑞士3和德国的飞机1的飞行轨迹1，船只跟踪2以及现场列车运动可视化4。 还有本地交通的实时地图，例如慕尼黑的地铁5或伦敦的地铁6和公交车7。 多个运输机构提供其车辆的位置可视化。
但是，所有现有的实时地图都限制在某种运输模式（如火车）或非常小的区域。 （除数据可用性问题外）的主要原因是与整个国家（甚至整个世界）的完整公共交通运输相关的数据非常大。为了获得流畅的可视化，这些数据必须进行充分的处理和实时显示。
例如，仅德国的列车网络就只有约6,650个车站，而每天有一列火车从车站出发约60万次。包括当地交通，大约有25万个车站，离场事件的数量接近每天1500万。在纽约这样的大都市区，数以千计的车辆在白天的任何时间点都会四处移动。在可缩放和可拖动的地图上可视化这些车辆动作对后端和客户都是一个挑战。
我们提出了一个客户端实现，与适当的客户端/服务器架构相结合，可以显示投影到地图上的数千个平滑的车辆运动。由于我们的主要应用是公交数据的可视化，我们称之为客户TRAVIC（TRAnsit VIsualization Client）。我们将在本文最后讨论客户的其他用例。 TRAVIC使用Lea fl et，这是一个用于交互式Web地图的OpenSource JavaScript库。 Lea fl et可以处理大多数可用的地图切片格式，但主要用于Google地图或OpenStreetMap（OSM）切片。图1提供了荷兰TRAVIC可视化车辆的屏幕截图，使用了OSM Transport Map8图层。
在论文中，我们描述了TRAVIC如何处理从后端接收到的数据，解释如何构建矢量层以及如何实现车辆平稳移动。
2.客户端-服务器端的交流
我们假定一个服务器的可用性保存静态时间表数据。我们的系统建立在免费提供的GTFS feeds9上，当然也可以使用其他数据源。由于世界各地的许多机构都以这种格式提供数据，因此GTFS Feed的优势在于覆盖面已经很高。此外还有一个名为GTFS-realtime的扩展，可以报告延迟和路由变化。例如，荷兰的公共交通完全由GTFS和GTFS实时覆盖。服务器从GTFS源提取车辆轨迹。轨迹是一系列时空航点。每个路点由平面中的坐标x，y和时间戳t指定。因此，轨迹描述了单个车辆如何在空间和时间中移动。时间戳根据时间表对应于车辆到达/离开时间，但是可以在实时延迟信息可用时更新。
Figure1，使用TRAVIC进行长途和本地传输的可视化。 如果用户点击特定的车辆，则会显示完整的到达和离开时间路线（并且还会出现延误）。
一个可能的客户端 - 服务器接口将是让客户端为空间边界框内的所有车辆定期请求定位（实际地图视图）。该接口用于大多数基于GPS和传感器数据的实时地图，参见例如[1]，[2]或[3]。但是对于时间覆盖，这种请求的频率必须很高（特别是如果车辆运动应该平稳）。这导致了大量的客户端 - 服务器通信。此外，如果连接中断，客户端不会回落并且车辆停止移动。为了避免这些缺点，我们使用另一个基于预见查询的界面。然后请求具有时空边界框的形式。这意味着客户要求在特定时间间隔内与地图视图相交的所有车辆轨迹。然后服务器必须确定相关的轨迹并将它们裁剪到请求的边界框。这些部分轨迹然后被发送回客户端。客户端然后遍历部分轨迹，计算新的车辆位置，并相应地移动标记。在许多GTFS馈源中，时空航点仅在站点提供，但不在两者之间。因此，时间和空间插值是平滑运动可视化所必需的。因为轨迹基本上是分段线性曲线，所以这些插值可以在这条线上执行。
有了这个接口，一个新的服务器请求只能在先前请求的时间间隔到期后（减去一些缓冲区来处理网络延迟等）才由客户端进行处理。在我们的实现中，TRAVIC每60秒或在视图框超出当前一组（部分）轨迹（由于拖动或缩放）的边界框之后进行时空请求。
由于TRAVIC可以向服务器发送任意的时空请求，所以也可以“快进”的车辆运动高达60倍，从而实现了整天的车辆轨迹可视化。由于车辆的实际绘图占用了大部分计算时间，因此TRAVIC不能在每个间隔简单重绘整个地图。我们在下一节描述一种更新画布的有效方法。
3.过境层
在Web地图上显示位置的常用方法是通过地图自己的API绘制标记。许多过境地图处理车辆作为地图标记，并通过使用通常以经度和纬度值作为坐标的一些地图方法绘制它们。然后用两种方法之一绘制标记。可以作为一个HTML元素，通常是一个封装在lt;DIVgt;中的lt;IMGgt;。例如，Google地图或Bing使用此方法。或者，标记是SVG图层上的实际矢量对象。例如，OpenLayers或Lea fl。等人使用这种方法。虽然矢量图层在显示数千个标记时通常更加高效，但在其上放置标记的基本方法仍然是一种接受纬度（phi;）和经度（lambda;）坐标作为参数的方法。如上所述，这需要地图将phi;和lambda;投影到地图平面上，在这种情况下，这是屏幕本身。对于定位一次的几百个标记，这种计算是可以忽略的一次性成本。但考虑在早上高峰时段在纽约的公共交通，在每个时间点可以有多达4,000辆车辆在其周围移动。为了获得流畅的可视化，每个车辆标记至少应每隔50毫秒更新一次。如果我们使用纬度/经度坐标定位标记，则每秒会有4,000times;20 = 80,000个投影。在JavaScript环境或移动设备上，这对客户端来说太多了。
因此，我们让服务器项目轨迹路标到地图平面上，并将投影像素坐标发送给客户端。 TRAVIC几乎完全绕过地图服务来利用这一点。它主要建立在Transit Layer上，它是我们为Leaflet。开发的矢量图层。它特别设计用来显示任何类型的车辆在轨迹上移动。地图API（Leaflet）和传输层之间的交互只包含一些响应地图拖动或缩放的回调。 Transit Layer基于Raphauml;el，它是JavaScript的矢量库，用于提高浏览器兼容性（仍然存在不支持SVG的浏览器）。图2显示了Transit Layer的一般概念。
figure2：TRAVIC和运输层的一般架构。
画布或矢量图层放置在实际的地图图层上，平移和缩放，并通过DOM事件（如鼠标点击）。 Transit Layer上的车辆被绘制为矢量对象，并通过服务器计算出的像素坐标进行定位，而不需要客户以任何方式进一步转换。重绘地图仍然存在微妙的困难。例如，删除和创建新标记比重新定位画布上已存在的标记要昂贵得多。另一方面，搜索4000个标记以找到属于单个轨迹的标记同样很昂贵。 TRAVIC针对空间上的时间进行了大量优化，并保存了一个简单的JavaScript数组，其中包含当前可见的每个标记，并通过其轨迹ID进行索引。由于轨迹ID始终由服务器以整数形式输出，因此大多数浏览器都将该阵列实施为针对快速密钥访问进行了优化的映射。此外，在新要求的一组部分轨迹的第一次更新期间，每个轨迹的标记被保存为轨迹对象内的参考视场。
4.示例
该演示将重点介绍我们实施的客户端的可视化功能以及它与不同浏览器的兼容性（另请参阅我们在第6部分的实验评估）。 我们邀请用户使用他们自己的设备访问我们的公共交通跟踪系统（http://tracker.geops.ch），并检查他们所在地区的数据覆盖情况。 用户可以放大和缩小，并将地图拖动到任意位置。 点击相应的标记就可以轻松跟踪单辆车。 然后标记被放大并且车辆的完整路线被绘制在地图上。 有关车辆的更多信息（线路号码，运营日期，代理商）将显示在信息框中，以及要停靠的次序和相应的到达和离开时间（参见图1）。 如果延迟信息可用，它将与时间表一起显示。
5.进一步的案例
TRAVIC的适用性超过了公共交通范围。 理论上，Transit Layer可用于显示任何类型的车辆或移动物体。 在公共交通领域之外，车辆可以是飞机，卫星，甚至是像汽车，自行车或人一样的个体物体。 跟踪数据也适用于某些动物.10 TRAVIC的一种可能应用可能是作为服务器的客户端，该服务器输出在特定道路上行驶的汽车的轨迹以在特定时间可视化交通量。 图3显示了机动私人交通的可视化
图3：TRAVIC用于传输模拟。
在弗赖堡的主要东西走廊。 车辆号码遵循双峰分布，在早晨和晚上高峰时段都有峰值。每天大约有20,000辆车通过中央大桥向一个方向行驶。
6.实验结果
衡量JavaScript性能是一项挑战。有效地在一种浏览器类型上运行的代码示例可以完全锁定另一种浏览器类型。为了评估TRAVIC的性能，我们选择在当前版本的五个不同的Web浏览器上运行测试：Firefox 27.0，Internet Explorer 11.0.2，Chromium 32.0.1700，Safari 5.1.7和Opera 12.16。我们使用来自欧洲，北美，澳大利亚和新西兰的22个单一GTFS订阅源的组合订阅源加载服务器安装，并以尽可能高的缩放级别将阿姆斯特丹的TRAVIC集中在一起，并逐渐缩小。我们认为20个缩放级别（与Z = 20放大和z = 0缩小），以及运输方式的层级（地铁和公共汽车都只有当用户在足够远的放大，火车和渡轮也较低变焦可见显示水平）。对于每个缩放级别，我们使用SVG渲染测量显示的车辆数量#v和花费在单个屏幕刷新tr上的时间。我们从纽约市政厅的圆顶进行了相同的测试，但是调用了画布渲染。 TRAVIC在较低的缩放级别使用较低的刷新率（1 / f）。因此，我们将这次乘以每个级别的每秒更新次数。这给出了TRAVIC忙于在一秒内刷新屏幕的时间量ttot / s。值ttot / sgt; 1000 ms将表示每秒刷新的预期次数不可行。
在运行Ubuntu 13.10的英特尔酷睿i5-3320M处理器，8 GB内存和NVIDIA Quadro NVS 5400M图形处理器上测试Firefox，Google Chrome和Opera。 Internet Explorer和Safari的测试是在运行Microsoft Windows 8（SP1）的同一台计算机上完成的。所有测试都是在1920times;1080的全屏模式下运行的。数值取自100次样品运行的平均值。结果可以在表1和表2中看到。我们观察到，对于渲染方案和缩放级别，TRAVIC的性能足以实现实时动态可视化，即使实际视图中存在1,000多种车辆。使用画布渲染，对于所有测试过的浏览器，ttot / s的值远远低于1000的性能临界值。我们目前的TRAVIC实施服务可以通过http://tracker.geops.ch访问，它为全球80多个GTFS源提供服务。
表1：在不同的浏览器类型和缩放级别上使用SVG渲染进行TRAVIC性能测试。 地图集中在阿姆斯特丹
表2：TRAVIC在不同的浏览器类型和缩放级别上的性能，使用画布渲染。 地图集中在纽约。
图4：异步延迟
7.更多的工作
对所有靠近车辆进行可视化对于移动用户来说尤其有趣。所以未来工作的一个自然方向是为移动客户实施TRAVIC。我们介绍的客户机/服务器体系结构已经适用于此，但必须对GUI进行调整。
对于较大的更新间隔，异步延迟信息的问题带来了一个尚未解决的问题。考虑图4所示的情景：车辆在两个航点之间的某个路线上行驶。在时间t1，客户端发送时空请求
服务器，其当前对于轨迹具有delta;= 5的延迟。延迟5传达给客户。然后服务器执行更新并获取实时提要的最新版本。不知何故，车辆已经恢复了失去的时间，现在delta;为0（在t = t2时）。然而，客户端仍然在t1所接收到的时空请求回答的范围内运行。现在，在t = t3时，客户最终会填写一个新的时空请求，并获知车辆的实际位置远远落后于当前显示的位置。当然，也有可能车辆远远领先于当前客户的位置。目前，我们通过让车辆“跳”到正确的位置来解决这种情况。另一种方法是计算车辆的新行驶速度，以允许将其与其实际位置同步，但使用平滑的运动。
8.参考文献
[1] Michela Bertolotto, Ailish Brophy, Alan Martin, O Gregory, Robin Strahan, Eoin McLoughlin, et al. Bus catcher: A context sensitive prototype system for public transportation users. In Web Information Systems Engineering Workshops, International Conference on, page 64. IEEE Computer Society,
全文共13781字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[14135]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
