中国华录杯之公交线路准点预测 赛后记录
中国华录杯之公交线路准点预测
按照惯例，给出我们组的最终成绩0.03901和第一名成绩0.03068
题目任务
公共交通绿色出行，是世界极力推行的策略。然而由于交通拥堵的原因，公交车经常不能准时到站，要么长久不来，要么两辆一起来。于是，是等公交车呢？还是不等公交车呢？我们可以通过实时的预测来解决这个问题。
公交线路准点预测赛题为参赛者提提供百余条公交车线路的运行信息，本赛题需要大家准确预测某一辆公交车是否能准时到达各个站点。
竞赛提供了百余条公交线路长达一个月的运营信息，每条线路的每一辆公交车都会定时发送GPS信息，参赛者需要根据历史信息训练模型，根据GPS信息估计每辆公交车到站时间。具体来讲，对于测试集中给到的每一条“待预测的公交车运行路线”，需要预测该辆公交车到达指定站点的时间。
数据
1. 数据总体
数据包含了天津市大约519条公交线路5716辆公交车的超过4亿条GPS记录，时间从2017年10月1日~10月31日。 用于比赛的数据被划分为三个部分。
2. 训练集的数据字段及样例
训练集包含了10月1日到10月24日之间的所有公交车辆的运行信息，包括线路id、公交车id、经纬度、记录时间、车辆运行状态。 文件名为：201010xx.csv，其中xx为01, 02, 03,…, 24。
数据格式及样例： O_LINENO,O_TERMINALNO,O_TIME,O_LONGITUDE,O_LATITUDE,O_SPEED,O_MIDDOOR,O_REARDOOR,O_FRONTDOOR,O_UP,O_RUN,O_NEXTSTATIONNO 671,911410,06:37:05,117.178,39.1618,0,1,0,0,0,0,2 671,911410,06:37:27,117.178,39.1618,0,1,0,0,0,0,2
字段解释为：
O_LINENO 线路id
O_TERMINALNO 公交车id
O_TIME 记录时间
O_LONGITUDE 经度
O_LATITUDE 纬度
O_SPEED 瞬时速度
O_MIDDOOR 中门状态
O_REARDOOR 后门状态
O_FRONTDOOR 前门状态
O_UP 上行
O_RUN 运行状态
O_NEXTSTATIONNO 下站编号
3. 测试集的数据字段及样例
从10月25日～31日，我们共选取了6万条线路。对于每条线路，我们给出了“日期，线路id，车辆id，开始预测时间，开始预测站点，结束预测站点上下行标记”。
文件名为：toBePredicted_forUser.csv
数据格式及样例： O_DATA,O_LINENO,O_TERMINALNO,predHour,pred_start_stop_ID,pred_end_stop_ID,O_UP
10-25,1,902731,17:00:00,25,29,1
解释后面三个字段：这条线路的predHour为17:00:00，是指在17:00:00时刻，车辆902731的下一站是pred_start_ID,即25；那么参赛者需要预测该车辆到达第25站、26站、27站、28站、29站的时间。
4. 用于辅助估计“待预测线路”路况的数据
对应于待预测的线路，我们提供了每条线路之前一个小时的车辆信息，用于辅助估计路况。 数据格式同训练集；但时间上与测试集无重合。
以3中的样例进行说明。上例中，待遇测的线路是从17:00:00开始，那么，当天（即10-25）的16:00:00~16:59:59的所有公交车的信息都会给出，帮助了解当天的道路情况。
5. 其他数据使用
①可使用外部数据！但须满足第2条！
②不能使用数据存在的漏洞！包括时间存在的漏洞，例如，假设被预测线路处于以下时间段2017年10月25日09:00:00～09:59:59，那么就不能使用2017年10月25日09:00:00以后的“任何事实数据”来预测此线路。
事实数据，是指真实记录的数据，包括但不限于以下几种数据：
（a）交通车辆的GPS记录
（b）交通事故的真实记录
（c）天气情况的真实记录（可采用“预报”的数据）
其他说明与数据清洗
数据集中清除了每天晚上23点到次日早上6点之间的数据。
判断公交车是否到达车站使用且仅使用nextStation值的变化判断。原因：假如同时考虑“nextStation变化”以及“瞬时速度为0”，那么有两种情形。情形一，若公交车在车站停留时间超过10秒，那么gps记录就一定会记录到“瞬时速度为0”的情况，此时，判断标准就是“速度为0”对应的时间。情形二，若某站无上下客，那么公交车为了遵守公交公司的约定，仍然会在公交站有停留，但时间很可能不足5秒，甚至速度为0的时间只是那么2秒钟，那么这个“速度为0”但状态被记录下来的可能性就很小了，因为gps的发送时间间隔大多是10秒；此时，就无法采用“速度为0”来判断。我们通过简单统计，发现司机往往会提前按下“nextStation”的报站提醒（甚至是在红绿灯路口就有可能按下报站提醒）————基于此，情形一和情形二的差异可（qi）能（shi）很大。
同理，若同时考虑车门开启与否，也会遇到情形一与情形二，即“车门打开的状态“可能并不能被捕捉到。
基于以上情形，如果强行考虑这些情况，是不容易有统一标准的。
为什么不用GPS呢？我们通过统计发现，GPS信息并不那么精确，比如有些离群点会定位到河里面，有些会到公园里面；若是通过GPS来判断是否到站，标准会更加复杂。
因此，仅根据“nextStation变化”来确定是否到站，既简单又不会有歧义。（当然，需要排除掉“连续按到站键”和“忘记按到站键”的情况啦）。（数据中已删除连续按到站键的情况，但是保留有GPS信号丢失导致经纬度为0,0这种情况）
数据预处理
官方提供的数据为
训练数据解压出来是
其中csv打开后是
既然是数据预处理，就不得不谈使用的算法，要确定算法就不得不从问题入手。
嗨呀，我就直说了吧。这个任务是给出某趟公交的某站到达时间，所以不同线路之间的影响可以忽略，数据预处理时候就把线路分开。就像这样（文件名是线路号O_LINENO）
算法
团队使用了常见几种算法进行比较，统计、聚类、神经网络、协同过滤推荐等。现在大致讲一下每种算法是怎么应用的：
统计，这是第一个进行尝试的算法也是最终提交版本的基础。不考虑此趟公交此站前的运行情况，仅考虑此趟公交此站的历史数据，求取平均值、中位数、众数。比较之后选择结果较好的一个时间作为此趟公交从上站到此站的需要（预测）的时间。从直观上来讲这样预测很不负责，因为缺乏了此趟公交的自己的运行情况。但是从大数据的结果上来看结果较好，因为大多数实际情况都没有异常，“每天都是平凡的过”。
聚类，这是为了解决统计中丝毫不考虑此趟公交的运行情况问题。主要做法是将此趟公交的历史数据进行聚类，根据预测的这趟公交最接近于历史上哪类聚类中心，就按照那一类进行预测。这样的好处是如果晴天公交运行和雨天的运行情况是两种截然不同的情况，那么就会被聚类成不同类，这样在预测时候就会根据要预测的这趟公交在要预测的站点之前的站点情况来判断他是在晴天还是雨天运行的。本来这个算法作为统计的算法改良。但是实际情况并不好，尤其是需要预测的站点离出发站点比较近，也就意味着系统在需要预测的站点之前并不能确定这趟公交是在天晴还是下雨运行的，一旦聚类中心确定错误，其带来的误差也较大。从最后的结果上来看有些预测更准确了，有些预测偏差更大了，综合比较不如直接统计。
神经网络，通过某条线路的历史数据进行训练，使用前3站的数据预测后一站的所用时间。且不说如果需要预测的站点是出发站的三站内怎么办，就是后面能够正常预测的站点，网络也没有学习出来一个较好的结果。猜测可能是网络对于公交车门的开关和车速等数据没有理解吧，我也不清楚。
推荐算法，根据公交车前几站所花费的时间“预测并推荐”他接下来的一站所花费的时间。虽然算法不同但是这个和聚类的算法对数据的操作很像，只是寻找聚类中心的计算方式不同。结果稍有不同，相同的是一样的差劲。
转了一圈又回到了熟悉的统计。对于数据分类细致程度影响了最后的结果，但是细分过头又会因为数据不足或者其他原因导致结果变差。没有具体记录，大致的误差随细分程度的曲线是v型。
回头总结一下：数据虽然很多了，但是还是有限。在使用一些方法时候数据缺失和不准确的问题严重。最致命的是丢失GPS数据后GPS返回0,0，但是算法没有分别0,0是缺失还是真的公交车瞬移到了经纬度0,0的地方。而且观察数据后发现，有些线路的公交车上传数据比较完整，有些线路的公交车就会误差比较大（导致GPS数据几乎无法使用），有些时候数据会丢失（有时候两站之间有50个点，有时候只有40个点）。（也有可能不是丢失，是司机开快了~）
总结
本次大数据其实还不算很大，虽然之前写算法都是所有数据读取到内存之后再处理在这个项目上行不通了，但是在数据细分之后，每类数据还都可以这样都放到内存中处理。
主办方没有要求使用的算法工具和语言，依旧觉得自己即使是在使用工具方面依然退步明显。想一想自己从手写算法到现在用工具都吃力也是蛮悲伤的。有时间会多玩玩工具的。
竞赛的任务难度有高有低，同样的是时间限制和没有更多的精力。而且感觉做事不细致不规范，可能赛事方也只是想要一个粗略的结果吧。本次竞赛我只是蜻蜓点水式的参与，希望有机会能够有更好的成绩。
