精简版的报警点已经发布，虽然根据刚开始的设想，是按照路口来删除报警点的，但是该模型想像的太过于完美了，非常适合十字交叉型的路口，对于复杂一些的道路情况就不适用了，比如主路和辅路，并且附近又有交叉的小路，这样的情况太过于复杂到底以哪个交叉路口为参照呢，如果全部参照，那多个交叉路口过近本身就是一个问题。另外获取交叉路口也不是一件容易的事情，最终我放弃了这个想法。
想了很多的方法，最后觉得直接将多个报警点进行抽稀处理，即将多个较近的点位删除，合并成一个点位。听起来很简单，就是将靠近在某一路口的报警点取平均值一下，但是如何判断这些点位算是靠近在一起这是关键。首先，任何一点位都有离它比较近的点位，这个可以通过距离来判断，比如只要和它距离保持在80米以内的就属于较近点位。其次，这些较近点位是否真的较近，或者是否有飞点(就是有几个靠近在一起而另外一个比较远但也在距离范围之内)的现象，或者点位数量是否也有一定的关系。首先就以某一点位为参考点位，在其半径为80米的范围内，都属于它的较近点。但对于这些较近点，并不是所有的相加再平均即可得到一个坐标位置，这样误删的几率比较大，最早使用100米作为半径范围来平均点位的时候，就存在两个较近路口最后点位平均后变成两路口中间点位的现象，此情况即属于错误。那么肯定还需要增加条件，大致的情况条件是
1，参考点如果周围80米范围内没有较近点位，则该点位为独立点位，予以保留；
2，参考点周围有一个靠近点位，如果参考点和靠近点的距离大于50米，则放弃该靠近点，因为个人担心两个点位超过50米可能会是两个路口的情况。如果参考点和靠近点的距离小于50米，则两点相加取平均，即获得两点中间的点位作为最终报警点为；
3，如何判断一个点为上一段说的飞点情况，首先在参考点周围80米范围内找到了超过一个的靠近点位，此时不能直接做平均，我增加了一个条件，即如果参考点和各靠近点之间的距离，最大距离超过第二大距离的两倍，则放弃最大距离点位，从靠近点位中剔除还原为普通点位，只需要将参考点和靠近点位取平均值即可得到报警点位。而对于没有最大距离超过第二大距离两倍的情况，那么就直接全部靠近点和参考点相加后取平均即可得到报警点位。
根据这一思路，我便开始写function，是用VB写的。此函数肯定脱离不了遍历，并且是不断的遍历，为了加快速度，我首先将文件中的所有点位读入到一个非常巨大的数组中，然后再在数组中进行遍历，从第一条记录点位开始，假设该点位即为参考点，遍历第二条记录开始的所有点位，将距离在80米以内的点位全部作为靠近点，完成后再按照上面所提出的三个条件进行判断。同时为了避免重复计算点位，将每一个点位都带上了判断标记，如果该标记为真则表示该记录已经处理过，不需要处理直接跳过，而对于没有标记为真的数据则归结为判断点位，继续进入到下一轮的多点删除过程中。
下面来看看我们处理前后的两份地图的对比，我会附上一定的说明和评注，下面两幅分别为静安公园附近处理前和处理后的数据对比，很明显的发现，处理后的数据非常的符合多点删除标准，但同时也发现了一定的弊端。
静安公园附近全部的报警点位图：
处理后静安公园附近的报警点位图：
如上图所示，有三个地方存在疑问，我已经使用1、2、3数字标出，我们对此三个疑问具体分析：
第一个标记处，是因为两个点位虽然在80米距离范围内，但是由于只有两个点位，并且超过了50米距离，所以最后并没有合并处理，而成为了两个独立的点位，此情况符合上述第二种条件，所以处理正确。如下图所示：
第二个标记处，此处符合第三个条件，即最大距离超过第二大距离的两倍，42>18*2，如下图所示：
第三个标记处，同样属于第三个条件，55>24*2，如下图所示：
但是个人认为第三个条件还是存在一定弊端的，或者说方法存在一定的弊端，比如上述的两个标记点位，如果使用中间点位作为参照点位，其余两个靠近点位就是属于可平均范围，即可以将三个点位直接相加后取平均值，最后得到一个点位，而不是两个点位。为了改善这个情况，由于我是顺序遍历，不是乱序遍历，所以在这样的情况下，哪一点作为参照点位无法进行选择，但我如果我增加一个距离条件，即可改善这一情况。我又增加了一个判断条件，即最大距离小于50米的，即使比第二大距离两倍还要长，但不予以考虑，直接将所有点位作为相加取平均值，加入此条件后是有效果的，上述的第二标记处就从两点降为一个点位，但第三个标记处是因为最大距离超过了50米所以未能三点处理成一点，最后还是处理成了两个点位。但该条件确实存在效果的，如下图所示，未增加条件前，将四个点位处理成了两个点位，但增加条件后，将四个点位直接处理成一个点位了，并且个人认为一个点位的效果要好于两个点位。
而增加条件后的效果还是能够看到的，拿上海来举例，总共3237个报警点数据，没有增加条件的时候，处理结果为1790条记录，增加条件后处理结果为1770条记录，其中的20条就是因为增加了一个条件而多删除的记录，使数据更加精简。
多点删除最终效果：
违章报警点数量由原来的31915个点位变成18223个点位，减少43%
闯红灯报警点数量由原来的24871个点位变成13121个点位，减少47%
未区分违章和闯红灯的报警点版本：由原来的56786个点位变为29985个点位，减少47%
(由于未分类报警点没有考虑违章和闯红灯，而仅仅作为相同报警点处理，所以29985<18223+13121)
最终的结果来看，效果还是非常不错的，但是我也相信存在一定的弊端和未能考虑的情况，比如文中就没有任何认证的情况下选取了80米和50米这样的两个关键数字，比如文中第三标记最终未能变成一个点位就是一个弊端，而反过来说，并不是所有的情况都是满足条件的情况，毕竟多点删除算是数据分拣，要么保留要么抛弃，再好的条件也只能有这样两个选择。能够处理到这样的结果，我个人还是比较满意的。如果大家有更好的方法或者规则，欢迎讨论。
本文是Garmin报警点完善计划和精简版报警点发布(Garmin报警点完善计划续)两篇文章的续文，本来想写成说明文的，但结果成了原理讨论的技术文，所以可能直接查看本文有点雾水，建议先查看以上两篇文章后再来浏览此文，可能会有一个更好的理解。