1. 程式人生 > >軌跡系列13——多軌跡展示在實際專案中的落地和優化

軌跡系列13——多軌跡展示在實際專案中的落地和優化

文章版權由作者李曉暉和部落格園共有,若轉載請於明顯處標明出處:http://www.cnblogs.com/naaoveGIS/

1.背景

         在之前的”多車輛實時跡展示方案”(https://www.cnblogs.com/naaoveGIS/p/8551915.html)文章中,我講解了我們對多軌跡實時監測展示方案在前段的一些實踐和對於後端架構的設計,但是在真實專案的落地過程中,我們基於此做了很多的優化,這裡做一個簡單的總結。

       這裡我將該專案大致做一個描述:公司某個專案中有一萬兩千輛車需要做實時監控,而且這些車24小時均會不間斷進行GPS上報。所以其中涉及到GPS的對接、海量資料儲存的設計方案、訊息推送、前端展示、系列報警設計等。這其中的GPS對接、資料儲存涉及等問題我在軌跡系列文章中均有描述,感興趣的朋友可以看看,本篇著重描述資訊推送和前端展示的優化。

2.GPS推送機制的設計

       這裡的訊息推送並不是很複雜,所以我們並沒有採用卡夫卡等成熟的訊息機制架構,依然採用的是前篇中我進行了介紹的WebSocket方案。但是,有幾點我們需要考慮:

       a.前端為了播放效果,每次傳入的GPS中一個車輛必須擁有2個以上的GPS資料(如果只有一個則是停留的)

       b.我們有1萬輛以上的車輛,每次推送給前端的資料不應該是所有的,即做成廣播協議是不合理的。

       針對這兩個問題,我們分別做了解決:

       a.採用redis進行GPS資料的實時存放,但是進行了存放規則設定,即redis中存放的軌跡只包含目前時間向前推移指定時間的軌跡量。比如,redis中永遠存放的是此前三分鐘的軌跡資料(時間長可設定)。這樣可以累積一定量的軌跡後推送,以便實現播放效果,並且方便高效讀取。

       b.在訊息推送中,我們根據humanID來進行資料推送的選擇。不同人員要看到的車輛是不一樣的,因humanID不同而不同。

       在推送方案中我們還進行了其他優化:

       a.通過心跳檢查來進行socket連線保活。

       b.前端播放時效與後臺軌跡推送的同步。

3.多軌跡前端展示優化點總結

       a.根據車輛數目切換展示方式,車輛少時用車輛圖示,車輛多時用點。

       b.重新設計車輛圖示,以俯檢視進行車輛圖示設計,並通過後視鏡等細節來更好的表現車頭和車尾。

       c.每次GPS重新獲取後,地圖不進行縮放,保持觀察的連續性。並且通過車輛ID的關聯,保證前端播放軌跡的連續不閃爍。

       d.車輛車牌的顯示,並且只有在地圖縮放到一定級別後才顯示,以避免圖示雜亂。

       e.通過計算播放點與最近GPS點的距離來展示該播放點的車速。

       f.提供車輛詳細資訊展示的入口。

       g.根據車輛不同的狀態,比如超速、停留等用不同的車輛圖示來進行表示。

 4.專案真實效果展示

   多軌跡展示效果:

  

  單車輛歷史軌跡展示效果:

  

                                                                              如果您覺得本文確實幫助了您,可以微信掃一掃,進行小額的打賞和鼓勵,謝謝 ^_^