地图拟路化实现——利用百度鹰眼

这次的项目难点是需要将一串gps轨迹纠偏为绑路的轨迹，鉴于这个情况，超图需要购买服务，而百度和高德提供了免费接口，百度还额外提供了鹰眼平台管理这些数据，所以这次预研了下鹰眼地图。

实现思路就是，1.上传excel解析出点位list，2添加终端addEntity，2上传点位addpoint，3查询纠偏后轨迹gettrack

百度鹰眼api地址：http://lbsyun.baidu.com/index.php?title=yingyan/api/v3/trackupload

业务模块主要分为1终端管理，2点位上传，3纠偏查询，4轨迹分析，5电子围栏

终端：可以理解为设备、人、车，为移动轨迹的载体；

点位：可以理解为终端在时间轴上的单位位置信息；

纠偏：普通的纠偏在webGis内的概念主要是不同地图厂商投影坐标系不同产生了误差，需要坐标系转换，这里用于轨迹的纠偏，分为去噪、抽稀、绑路，

去噪，则是去除前后时间轴上方差过大的点，简言之就是速度100码，但前一个点在西湖，后一个点已在湘湖，偏差过大了，也可能根据radius精度判断，

抽稀，则是去除重复性太大的点，点位一秒上传一次，但一条100米的路却因为开的慢上传了上万个点，轨迹几乎是直线，优化下，

绑路，则是将点位纠正到道路上，对点位进行最近距离的路网信息进行搜索，然后选取最适道路绑定，坐标也做一个纠正

轨迹：可以理解为终端在时间轴上的历史位置展示，可根据速度分析出停留点、驾驶行为、里程信息；

围栏：可以理解为一个多边形区域，终端在一个时间段在区域外，或在区域内但不满足限速，产生出栏、超速、低速、停止等可报警元素。

出现问题：addpoints批量上传点位接口，反复出现loc_time类型不匹配，经查，不是类型不匹配，而可能原因有

1、loc_time是unix时间戳，取得是秒数，js举例为Math.round((new Date()).getTime()/1000)

2、loc_name时间小于了或重复了原已存在点位时间

3、entity_name不存在，

4、掺夹了没有添加的自定义字段

2017-11-7续接新问题：

gettrack查不出纠偏后数据，源于addpoints上传的点位只有经纬度，并没有设模拟的方向和速度，速度暂设100km/h，而方向则根据前后两个点形成的向量算出与y正轴顺时针的方向夹角即可。

2017-11-8续接新问题：

gettrack无法查询出wgs84坐标系的数据，只支持百度和国测局，百度公开的坐标转换api——

http://api.map.baidu.com/geoconv/v1/?coords=x,y&from=1&to=5 ,无法将百度转化为wgs84坐标系;

解决办法：找到另一个百度不公开的api转换，顺手研究了下坐标系转换相关知识，见下篇WebGis坐标系转换知识

api为http://api.map.baidu.com/ag/coord/convert?from=0&to=2&x=longitude&y=latitude

其中：from: 来源坐标系（0 表示 WGS-84 坐标；2 表示 GCJ-02 坐标，即 iOS 地图 / Google Maps / 高德地图使用的（900913）；4 表示 BD-09 坐标，即百度地图使用的（3857））,

to: 转换后的坐标系,x: 经度,y: 纬度

返回的结果是一个 JSON 字符串：

{"error":0,"x":"MTIxLjUwMDIyODIxNDk2","y":"MzEuMjM1ODUwMjYwMTE3"}

error：是结果是否出错标志位，

0 表示成功,

x: 坐标系 2 时为经度，4 时为纬度(Base64 编码);

坐标系 4 时为经度，2 时为纬度(Base64 编码)

2017-11-9续接新问题：

无法将国测局或百度转成wgs84，百度不公开api也不行，超图api也不提供，民间算法也不准确，有偏差

而目前基线地图不能全盘切成百度地图，之前承载太多的业务，且支持离线企业应用

最后解决办法：

addPoint上传wgs84，然后gettrack查出未绑路的gcj02，算出这两条线的平均偏移，

再gettrack查出绑路后的gcj02，减去之前算出的偏移，算出绑路后的wgs84。

因为这两者距离很小，可以避开国测局大范围的不同经纬区块偏移策略，偏移基本够用，误差很小。