终于找到问题所在了，原来不是程序问题，而是数据质量问题

本篇仅仅是本人工作中的感想，非做本行业软件人员看不明白的

我写的服务程序，任务有如下：

1、接受通讯服务器得自车辆的消息

2、分析消息，并按消息类别保存

3、自动划分班次，即车辆来的消息，是线性的，服务要根据线路各个站点的拓扑关系，将线性发上来的消息，按段分割，使其分属不同的班次

      当掉头，并且掉头后报上来的站点多于一个站点，则理解为掉头，原来班次结束，新班次开始；

      当到达终点站后，再报上来始发站消息，则将首次报始发站前的消息，归结为前一班次，后面的为新班次。

4、对于停车消息：

      a> 须整理上下车、留车人数

      b> 须将每次停车，归属于某个班次

5、实时统计技术指标

      断面按小时统计平均需用时间

      断面按小时统计留车人数

      断面按小时统计通过次数

      站点按小时统计上下车人数

。。。

      原来，断面车距与通过班次 的报表，显示的各个站点按时间段的通过差别很大，这肯定是有问题，因为，在一天内，除去中途掉头的特殊情况外，各个站点通过的班次，应该是一样的，而不同时间段即便有差别，也不会太大，并且应该是按照站点顺序线性分布的，可报表显示，各个班次无规律差别很大。

      本周的工作，就是修改服务，以解决此问题，幸亏服务有消息录放机，可以快速（约半小时可以播放并处理一天的数据）地模拟出一天的车辆消息，即便如此，也是修改了n次，模拟了n次，检查了n次报表，还是无果。

      终于，在今天半夜，找到了问题症结：数据源----车辆发来的消息有问题，在一个班次中间，会多次错报反方向站点的信息。

       虽然找到问题来源，但要解决，还是很困难，或者修改车辆终端的程序，或者试着修改兴趣点，或者上层服务来通过算法屏蔽这种情况。

      修改底层程序，需要时间可能会很长；

      检查是否兴趣点设置不合适，或许是最容易解决的方法；

      修改服务屏蔽这种错报，也比较麻烦，因为，这样的话，就不能实时分析统计了。如怀疑某个消息错误，则必须在其后续报上来的多个消息，最多要等到下个站点的消息上来后才能确定是真的掉头还是错报，这样的话，就必须也要阻塞本车辆后续消息的分析、怀疑错报站点的其他车辆报该站点的消息的分析。

      明天将问题提交，再由领导确定如何解决吧。