熱門論文
最新論文
莫干山郡安里景區綜合信息管理系統 設計與實現
發布時間：2023-07-08 09:58
目 錄
摘 要 I
Abstract II
第1 章 引 言 1
1.1研究背景與意義 1
1.2國內外研究現狀 2
1.2.1智慧景區 2
1.2.2車輛調度 4
1.3主要研究內容及技術路線 5
1.4章節安排 6
第2 章 需求分析與地理數據獲取 8
2.1研究區域 8
2.2需求分析 9
2.3已有地圖數據 10
2.4無人機航測 12
2.4.1數據采集 12
2.4.2數據處理 13
2.5導航節點選取 14
2.6圖像配準 15
2.7本章小結 16
第3 章 車輛調度問題的遺傳算法 17
3.1問題分析 17
3.2數學模型 18
3.2.1遺傳算法 19
3.2.2數學模型 19
3.3遺傳算法求解過程 20
3.3.1編碼 21
3.3.2解碼 21
3.3.3初始化種群 23
3.3.4適應度函數 23
3.3.5遺傳操作 23
3.3.6終止條件 25
3.4實驗分析 25
3.5本章小結 28
第4 章 綜合信息管理系統設計 29
4.1系統開發相關技術 29
4.1.1WebGIS 29
4.1.2MySQL 29
4.1.3WebSocket 29
4.1.4JSON 30
4.1.5第三方地圖服務 30
4.2系統總體設計 30
4.2.1系統框架 31
4.2.2基礎設施層 32
4.2.3數據資源層 32
4.2.4業務應用層 34
4.2.5用戶層 34
4.3系統數據庫設計 34
4.4綜合信息管理平臺設計 39
4.4.1VS 平臺 39
4.4.2車輛調度模塊 40
4.4.3信息管理模塊 40
4.4.4可視化模塊 41
4.4.5最短路徑規劃模塊 41
4.5車載 APP 設計 42
4.5.1Android 平臺 43
4.5.2賬號模塊 44
4.5.3地圖模塊 45
4.5.4接送模塊 45
4.5.5剩余座位數管理模塊 45
4.5.6其他模塊 46
4.5.7高程剖面圖模塊 46
4.6微信小程序設計 47
4.6.1微信小程序開發工具 48
4.6.2掃碼登錄 48
4.6.3地圖模塊 48
4.6.4叫車模塊 48
4.6.5評價模塊 48
4.7本章小結 49
第5 章 綜合信息管理系統實現 50
5.1綜合信息管理平臺 50
5.1.1登錄模塊 50
5.1.2信息管理模塊 50
5.1.3最短路徑規劃 51
5.1.4可視化模塊 52
5.1.5通訊機制 53
5.2車載 APP 54
5.2.1通訊內容 54
5.2.2賬號模塊 55
5.2.3地圖模塊 58
5.2.4接送模塊 59
5.2.5剩余座位數控制模塊 63
5.2.6其他模塊 64
5.2.7高程剖面圖模塊 65
5.3微信小程序 67
5.3.1通訊內容 67
5.3.2地圖模塊 67
5.3.3叫車模塊 68
5.3.4評價模塊 72
5.4本章小結 72
結 論 73
致 謝 75
參考文獻 76
攻讀學位期間取得學術成果 80
第1 章 引 言
1.1研究背景與意義
隨著我國經濟的突飛猛進，中國特色社會主義進入新時代，我國社會主要矛 盾已經轉化為人民日益增長的美好生活需要和不平衡不充分的發展之間的矛盾 （顏曉峰，2019）。除了日常的衣食住行外，人們越來越注重生活品質，旅游幾 乎成了假期的必備選項。在此背景下，我國的旅游產業迅速發展，游客數量不斷 攀升。根據國家統計局（2021）發布的數據顯示：因疫情影響，2020 年全年國內 游客 28.8 億人次，國內旅游收入即使較上年下降61.1%，也高達 22286 億元。近 五年國內旅游人次及其增長速度如圖 1-1 所示。
圖 1-1 2016-2020 年國內游客人次及其增長速度
游客認同一個景區，一是景區的特色，二是景區的服務與便利程度（蘭海軍， 2016）。面對越來越多的游客，對景區的承受能力和平衡能力提出了更高要求， 景區的管理與運營也迎來了巨大挑戰，而景區的品質和服務質量也直接影響著該 景區的發展和核心競爭力。尤其在節假日期間，景區游客急劇增加，僅僅靠人工 管理顯然不能滿足景區的發展需要。特別地，對為游客提供代步服務的景區，常 出現忘記給游客調度車輛或者游客等待時間過長等情況，如何在景區內為游客提 供便利的代步服務，保障景區內的交通系統正常運行，保證景區內出行的便捷， 是一個迫在眉睫的問題。
隨著大數據、人工智能等新興技術的發展，對傳統產業提出了“智能化”的 新要求，打造智慧景區已經成為景區發展的必然趨勢，具有巨大的發展潛力（徐 岸峰，2019）。智慧景區不僅能提高游客的游玩體驗，同時能夠滿足景區高效、 低成本的管理需求，促進景區的全面可持續發展。在國家旅游局的大力倡導下， 全國已有多家景區完成了智慧景區相關的體系建設。
位于浙江省湖州市德清縣莫干山鎮的郡安里景區，擬建立一套郡安里景區的 綜合信息管理系統，完成對景區客流信息、車輛信息、用車信息等全面實時掌控， 針對目前景區的急需，率先實現線上叫車功能，初步形成莫干山郡安里景區交通 組織的信息化和智能化管理。
1.2國內外研究現狀
1.2.1智慧景區
隨著“智慧地球”這一概念首次被 IBM 公司提出（李德仁，2010），智慧城 市、智慧交通、智慧醫療、智慧景區等概念也應運而生，成為當今各領域發展的 熱點方向。
美國是最早進行智慧景區實踐探索的國家之一，促進了世界其他各國智慧景 區的發展（蔣麗芹，2013）。 2005 年，科羅拉多州的 Steamboat 滑雪場利用 GPS 定位技術，開發定位反饋系統了解游客的實時位置，通過實時位置分析，確保游 客的安全，開啟了智慧景區的探索；2006 年，賓夕法尼亞州波科諾山脈度假區引 入的智能手環系統，極大地方便了游客在景區內的游玩，此系統能夠智能識別游 客身份，為游客提供智能導覽服務，同時可利用該系統實現景區內快速支付功能 （顏敏，2014）。 2009 年英國德國兩家公司協作開發了一款智能導游軟件，此軟 件通過手機 GPS 實現對游客實時位置的確認，通過虛擬成像技術，還原古跡歷 史影像，游客只需手機掃描古跡，即可快速了解到古跡所對應的歷史事件，讓游 客輕松且全面地了解到古跡之美（鄭俊，2013）。2010年，韓國旅游局推出了 T Tour Seoul”掌上移動旅游信息服務系統，以當前位置為基點，推薦周邊的景區、 美食、演出、酒店等信息，并提供相應的預訂功能，可在 APP 上根據個人喜好 定制旅游路線，同時也為游客推薦旅游路線、電子書等，此系統全面的、便捷的 旅游信息服務，使游客能夠輕松的獲取到高質量的旅游服務（高楊浩， 2017）。 2012 年 6 月比利時推出“標識都市”平臺，游客只需在手機上使用特定條碼掃 描器，掃描“標識都市”不干膠，即可獲取平臺提供的交通、購物、景點等各種 旅游信息及服務（吳一， 2015）。新加坡提出的“智慧國 2015計劃”中，可實現 讓游客隨時隨地享受機票購買、交通工具選擇、旅游簽證辦理、旅游路線規劃等 內容的一站式服務（李芳，2018）。
Gretzel （2011）指出未來旅游景區應該向智慧景區轉變，以保持其核心競爭 力。Buhalis et al.（2015）等提出將互聯網和通訊技術應用于智慧景區的建設中， 實現景區數據的即時傳遞，利用大數據分析對游客的需求進行挖掘，最大限度的 滿足游客個性化需求。
2011年國家旅游局提出，國內旅游景點應逐漸將科技手段引入景區建設中， 如互聯網技術、遙感技術等，提升景區管理水平，增強游客體驗（金賽， 2020）。 我國各景區在智慧景區的建設中取得了一系列成果。智慧泰山景區信息集成平臺 實現了 3D形式的泰山虛擬旅游服務，景區實時視頻監視管理，以圖表形式展示 客流分布統計，運用遙感技術進行病蟲害監測等，增強了游客的游玩品質，提升 了泰山管理方的工作效率，對提高泰山景區形象并推動景區的信息化管理水平有 重要意義（宋磊等， 2011）。武夷山在智慧景區的建設中實現了景區內實時監控、 定位導航、指揮調度、安全防護等功能，建立了公共信息服務平臺，使得政務、 游客服務等內容都可通過網絡交互共享，進一步建設智慧展廳，整合旅游資源， 構建旅游信息分享的專項平臺，實現了旅游資源的高效利用（張菲菲， 2015）。 九寨溝智慧景區的建設可概括為“一項應用、三大平臺、五個系統”，應用大數 據分析技術，深入分析數據間的潛在關系，提供輔助決策功能，從而為游客提供 更加人性化的公共服務，為管理方管理提供數據支撐；三大平臺建設從根本上改 變九寨溝現有的格局，形成惠及各環節的智慧九寨，帶動整體的信息化智能化進 程；五個系統實現對公共事務快速處理、旅游資源保護監測、景區資源營銷推廣、 游客車輛動態指揮、多維數據輔助決策，智慧九寨的建設大大提升了景區的管理 效率（高偉， 2015）。故宮博物館在智慧景區的建設中取得了豐碩成果，從2017 年起全面實施網絡售票，景區管理方通過大數據平臺，實時掌握景區人流量、車 流量等基本信息，引導游客科學游玩，全方位多角度實現景區監控，確保游客安 全。不僅如此，故宮還自主研發多款APP，“故宮” APP讓游客游玩時僅需智能 手機，就可定制故宮的導覽方式，經過景點時，軟件自動半屏顯示該景點信息， 為游客提供相應的文字、圖片、視頻等服務。“每日故宮” APP讓游客足不出戶 就可提前了解到紫禁城內所有事物及其歷史故事，故宮文創產品也在智慧導購模 式下也發展得紅紅火火，智慧故宮的建設推動了故宮多維度的發展（楊林林， 2020）。
智慧景區建設應結合互聯網技術、通訊技術、人工智能等，為游客提供便利 的個性化服務，為景區管理方提供便捷的管理模式。中國十四五規劃為各行業指 明了發展方向，跨領域結合相關科技技術，實現產業智慧化發展已是必然趨勢。
1.2.2車輛調度
車輛調度問題由Dantzig et al. (1959)提出，運用運籌學知識解決車輛調度 問題，切實讓企業物流運輸效率得到了提升，進而提升了企業效益，因此車輛調 度問題自提出以來就受到了廣泛關注。車輛調度問題是一個經典的 NP(Non- deterministic Polynomial)難題(Tarantilis et al.， 2005)。一般地，為降低其求解 難度，通常通過一定的方法和技術把車輛調度問題分解轉化成已研究過的基本問 題，再采用這些研究中相對成熟的方法求解。這些常見的問題有：旅行商問題、 中國郵遞員問題、車輛路徑問題、背包問題等(Li et al.，2014)。求解車輛調度 問題的算法可分為精確算法和啟發式智能算法兩類(Pinedo, 2015)。相較于精確 算法，啟發式智能算法更受專家學者們的青睞，啟發式智能算法主要包括模擬退 火算法、禁忌搜索算法、遺傳算法、蟻群算法等。
1953年Metropolis等人最早提出了模擬退火算法(Tufano et al.， 2020)，該 算法模仿了鋼鐵退火過程，通過全局搜索來求得最優化問題的最優解。 Banos (2013)采用模擬退火算法解決了多目標帶有時間窗的車輛調度問題，在保持解 決方案質量的同時，大大減少了運行時間。
Glover(1981)提出禁忌搜索算法，該算法從局部開始，逐步擴展搜索到全 局，進而找到最優解。Petersen(2012)解決乘客在兩次定時交通服務中轉移的等 待時間問題時，使用禁忌搜索算法，根據禁忌表逐步向全局擴散來求解車輛調度 問題。Alinaghian et al.(2021)在解決帶時間窗的路徑問題時使用了增強禁忌搜 索算法，與其他算法相比，增強禁忌搜索算法是產生高質量解的最佳方案。
Holland (1992)根據生物進化的思想提出遺傳算法，該算法模擬自然界中生 物的自然選擇現象和優勝劣汰的生物進化過程。Ombuki(2006)將Pareto排序 技術應用于遺傳算法中，解決了多目標帶有時間窗的車輛調度問題，有效地提升 了遺傳算法計算效率。Desfontaines et al.(2018)提出多車場公交車輛調度問題， 建立了可控行程切換的公交車調度模型，形成了一種有效的兩階段數學方法，合 理有效地解決了公交車輛調度問題。
Dorigo(1992)提出蟻群算法，該算法模擬螞蟻在尋找食物過程中發現并形 成路徑的行為。Bell(2004)基于蟻群算法對車輛調度問題進行了分析研究，允 許搜索車輛路徑中的多個節點，建立候選列表信息，進而提高了蟻群算法的計算 效率。Jiao et al.(2021)采用非線性優化和遺傳算法對蟻群算法進行改進，大大 降低了蟻群算法的計算時間，避免了局部最優的的缺陷，提高了蟻群算法的效率。
國內對車輛調度問題的研究相對較晚。鐘石泉(2005)在研究多車場有時間 窗的多車型車輛調度中，根據約束條件設計禁忌算法，并進行算例分析，最終得 出禁忌搜索算法對該問題的有效性。衛田(2007)采用遺傳算法對物流配送中車 輛路徑問題的多目標優化問題進行了研究，改進后的遺傳算法能夠快速有效地得 到最優解。楊善林等(2010)根據實際情況，綜合考慮車輛行駛速度隨時間段的 不同，將車輛行駛速度劃分為隨時間變化的分段函數，采用模擬退火算法解決了 該類車輛調度問題。余國印(2015)通過引入衰退因子，在算法初期避免遺傳算 法陷入局部最優，在算法后期保護優秀個體，進而改善了遺傳算法的早熟收斂問 題。陳成(2018)對遺傳算法的變異操作進行改進，對除第一個以外的基因進行 變異，滿足條件后取出該基因，最后再將所有取出基因重新隨機插入基因序列中， 保證了種群的多樣性，進而得到更為合理的解。
啟發式智能算法與其他類算法相比，具有易與其他啟發式智能算法相結合的 特點，并且能夠保留算法各自的優點。因此，有許多學者采用兩兩啟發式智能算 法相結合的方式來改進算法，彌補不足。如郎茂祥(2002)結合爬山算法和遺傳 算法，利用爬山算法改進遺傳算法得到的最優個體，實現了兩種算法的優勢互補， 得到了更高質量的解。李高揚(2008)結合蟻群算法和遺傳算法，有效地回避了 二者的缺點，保留了二者的優點，進而提高了算法效率。柳武生等(2012)結合 禁忌搜索算法和遺傳算法，先是在每一代中采用鄰域搜索的方式優化個體，隨著 不斷更新的信息加入，采用禁忌搜索法不斷改善配送路徑，最終發現不僅能加快 求解過程，而且解也更加可靠。張雁翔等(2017)提出的改進遺傳模擬退火算法， 結合了經典遺傳算法、模擬退火算法的優勢，具有更強的全局搜索能力，能夠更 加快速有效地獲取到最優解。范立南等(2021)將遺傳算法與蟻群算法結合解決 校園外賣配送路徑問題，以蟻群算法得到的尋優路徑作為遺傳算法的初始值，進 一步對遺傳操作進行改進，使得算法效率得到明顯提升。
隨著車輛調度問題中需求的變更，國內外在算法方面的研究也在不斷地發展， 不斷地結合新算法、新思想、新技術，對各類車輛調度問題進行完善。
1.3主要研究內容及技術路線
根據郡安里景區信息化、智能化的需求，本文以郡安里景區內車輛調度和綜 合信息管理問題為研究對象，從實際需求出發，擬提出一套基于遺傳算法的郡安 里景區內車輛調度解決方案，設計并研發以車輛調度為核心的綜合信息管理系統， 并預留擴展接口，為郡安里景區將來的智能化管理做鋪墊。綜合信息管理系統將 在空間基礎地理信息支撐下，實現景區內車輛調度，完成對各類信息的管理和分 發，如車輛信息、游客叫車信息、用車記錄信息等。針對景區內車輛調度功能， 綜合信息管理系統擬設計游客叫車的微信小程序、調度車輛和司機的車載 APP、 數據處理的綜合信息管理平臺；為進一步滿足人們對高程信息的需求，擬繪制路 徑高程剖面圖，實現高程信息的直觀展示，并根據路徑長度和坡度給出出行方式
建議。
本文技術路線圖如圖1-2所示，在明確本文的研究背景和意義后，對莫干山 郡安里景區管理方構建綜合信息管理系統的需求進行綜合分析，指出系統中所用 到的各類數據來源，應用改進后的遺傳算法解決郡安里景區內的車輛調度問題， 提出總體設計方案，對各部分內容進行相關設計，最后完成系統中各功能模塊的 開發工作。
1.4章節安排
根據本文的研究內容，章節安排如下：
第 1 章引言。介紹本文的研究背景和意義，收集分析智慧景區和車輛調度問 題的國內外研究現狀，明確了本文研究內容以及章節安排。
第2章需求分析與地理數據獲取。從景區管理方的要求出發，分析建立系統 的可行性，其次根據需求分析，介紹本文基礎數據來源以及相應的必要處理流程， 為后續的系統開發做準備。
第3 章車輛調度問題的遺傳算法。指出郡安里景區內面臨的車輛調度問題， 根據問題進行具體分析，設計并優化遺傳算法，完成景區內的車輛調度，使用測 試數據，采用 MATLAB 編程計算，驗證算法的合理性和可行性。
第 4 章綜合信息管理系統設計。根據可行性分析，提出系統總體設計方案， 并進行詳細的數據庫設計、綜合信息管理平臺設計、車載 APP 設計和微信小程 序設計，為后續系統實現指定方向。
第5章綜合信息管理系統實現。根據系統設計要求，完成綜合信息管理系統 各部分的開發工作，展示綜合信息管理系統的運行結果。
結論部分對本文的研究內容和成果進行總結，分析不足之處，進一步指出后 續需要完善的地方。
第2 章 需求分析與地理數據獲取
2.1研究區域
本文研究區域為浙江省湖州市德清縣莫干山鎮的郡安里景區，景區位于北 緯30°36'37"、東經119°54'12"附近，如圖2-1所示。向東可到德清主城區，向西 可到達莫干山風景區，距東南方向的杭州市約60km,環境優美，是一個度假、 旅游、休閑的勝地。莫干山郡安里景區是一個集酒店、建筑、住宅為一體的綜合 體，占地面積約為1800畝，有約11萬平方米的建筑體量，綠化面積超過90%， 內部有騎士學院、接待中心、馬場、休閑草坪活動區、云頂西餐廳、真美味中餐 廳、酒店主樓、 Discovery 探索極限基地等設施。
119°54'30”E
圖2-1莫干山郡安里景區位置示意圖
2.2需求分析
郡安里景區管理方積極響應國家號召，擬基于地理信息技術，構建綜合信 息管理系統，提升景區管理效率，打造智慧景區。第一步先實現景區內的線上叫 車功能，給游客和業主提供便利的代步服務。在實現郡安里車輛信息化管理的基 礎上，進一步針對人員出行、安全防控等現實需求，開發信息處理、分析、展現 等功能模塊，滿足郡安里信息化、智慧化的管理要求，提升郡安里的居住品質， 打造品牌效應。郡安里景區內有業主、游客、管理方三類人員（以下將業主和游 客統稱為游客），郡安里管理方為了方便管理，所有私家車不允許進入景區內部， 統一停放在停車場內，景區內的代步服務由管理方提供，代步車輛共有33輛。
郡安里景區目前采用是人工叫車模式：游客將用車需求告訴工作人員，工 作人員通過對講機呼叫司機，司機應答后接送游客。這樣的模式人工參與度高， 信息化程度低。針對線上叫車功能，擬設計游客使用微信小程序進行叫車，叫車 成功后可在等待界面顯示車輛位置和路徑，并且顯示車輛號碼、司機電話、預計 等車時間等信息，用車結束后可評價司機服務。司機通過車載 APP 接收游客的 叫車信息，按照規劃路徑接送游客，期間司機能夠通過車載 APP 向游客發送提 示信息并可撥打電話，遇到異常情況可上報異常內容等。景區管理方通過綜合信 息管理平臺可以查看景區情況和進行相關數據管理，平臺自動完成路徑規劃和車 輛調度功能。因此以車輛調度為核心內容的綜合信息管理系統主要包括綜合信息 管理平臺、車載APP、微信小程序三部分。
（ 1）綜合信息管理平臺：是系統樞紐，負責數據管理，數據交互，車輛調 度等工作；能可視化展示數據，動態展示景區人流量、監控視屏等信息。
（2） 微信小程序：游客叫車。實現景區地圖展示、景點展示、發布叫車信 息、等待界面顯示車輛位置、顯示接送車輛相關信息、顯示司機接送路徑、評價 司機服務質量等功能。
（3） 車載APP：司機專用軟件。實現司機登錄、修改密碼、地圖展示、接 收任務、路徑規劃、游客上下車、撥打電話、位置上報、異常信息上報、繪制路 徑高程剖面圖等功能。
隨著互聯網技術的發展，人們越來越多的在網絡上獲取和傳播數據，推動了 社會中各類數據的交互，為各類軟件的開發提供了堅實的基礎。不僅如此，各類 開源代碼平臺的興起，如GitHub，讓軟件開發變得更加快捷高效。郡安里景區的 綜合信息管理系統可選擇 Visual Studio 2017 進行開發，采用 B/S（ Browser/Server， 即瀏覽器/服務器）架構進行系統的搭建和開發， B/S 模型使用方便、易于操作， 只需要瀏覽器便可進行訪問，界面統一簡單，系統安全可靠。系統一旦開發出來， 管理員可以在任何一臺具有瀏覽器的PC機上登錄系統，實現對景區運營狀態的
及時查看和管理，提高整體運營效率。車載APP可選擇Android Studio 3.6.2進 行開發，司機專屬軟件保證服務的及時性和可靠性。微信小程序可在微信開發者 工具下開發，游客使用時只需打開微信即可，不需要下載軟件，使用方便快捷。 數據庫管理系統可選擇開源的MySQL，系統通訊可選擇WebSocket技術，通訊 格式可選擇JSON格式，路徑規劃可采用Dijkstra算法，車輛調度可使用遺傳算 法并進行優化改進，地理底圖可采用第三方地圖服務，如天地圖、百度地圖等， 坐標系統可統一采用 CGCS2000。
2.3已有地圖數據
在 WebGIS 技術高速發展的今天，電子地圖使得人們的出行變得更加簡單便 捷(陳建英， 2015)。定位、導航功能更是人們生活中必不可少的一部分。如圖
2-2所示是當前常用的四種電子地圖顯示的郡安里景區地圖，對郡安里景區來說，
這些數據相對簡單、不完整，無法滿足景區管理方的需要，為此需要獲取更加詳
郡安里景區現有地圖數據包括兩部分，一是 2019 年完成的郡安里景區
1:2000總平面設計圖（dwg格式），坐標系為CGCS2000,如圖2-3所示。二是根
據總平面設計圖繪制的郡安里景區規劃效果圖（PNG格式），如圖2-4所示。
圖 2-3 郡安里景區總平面設計圖
圖 2-4 郡安里景區規劃效果圖
實現綜合信息管理系統的運行需要用到以下兩類基礎數據：一類是郡安里 景區的車輛等基礎信息，由郡安里景區管理方提供；另一類是郡安里景區基礎地 圖數據。但是現有地圖數據并不能滿足本系統的開發需要，因此選擇無人機航測 方式，獲取郡安里景區的數字正射影像DOM和數字表面模型DSM。
2.4無人機航測
目前郡安里景區只有設計效果圖，沒有高分辨率影像圖。因此，本項目采用 無人機攝影測量的方法獲取DOM和DSM，外業數據采集使用南方天鴻T610六 旋翼無人機，搭載索尼ILCE-5100進行作業，焦距15.45mm。內業數據處理使用 Pix4Dmapper 軟件，它是一款專業化、簡單化且精度高的數據處理軟件。
2.4.1數據采集
根據郡安里景區實際情況，布設8個測量控制點，采用RTK方式測量，坐 標系為CGCS2000，控制點分布如圖2-5所示。
圖 2-5 航測控制點分布圖
為了保證作業安全和獲得更高的測量精度，在規劃航線時采取分塊進行航拍 的方式布設航線，第一塊區域采用200m的航高，第二塊區域采用265m的航高。 具體航線規劃圖如圖2-6所示。
圖 2-6 航飛路線示意圖
2.4.2數據處理
本次郡安里景區航測外業共拍攝照片1358張，應用Pix4DMapper軟件處理 數據的具體流程如圖2-7所示。
Pix4DMapper 軟件能一鍵初始化處理，其次添加控制點信息和進行相關設置 后，可全自動化完成更高精度的模型重建，處理完畢后可查看數字正射影像圖 DOM 和數字表面模型 DSM 以及質量報告，如圖 2-8 所示，為生成的 DOM 和 DSM成果，平均地面分辨率為2.5cm。
119°54©'E 1I9°54'3O”E 1I9°54'O"E 119°54'30"E
（a） DOM （b） DSM
圖 2-8 郡安里景區 DOM 和 DSM 成果圖
2.5導航節點選取
由于現有的電子地圖服務往往存在信息點不足，道路信息不全等缺陷，不能 滿足郡安里景區的導航服務要求，因此，本系統需要建立自定義導航功能，構建 郡安里景區內的導航節點信息表以滿導航需求。選擇郡安里景區總平面設計圖為 基礎底圖，按照道路方向選取節點信息，在ArcGIS中完成信息提取，最終得到 郡安里景區導航節點點表和線表，見表2-1和表2-2。
表2-1郡安里景區導航節點之點表（部分）
點號 經度（°） 緯度（°） 高程（m） 權重
1 119.***659 30.***314 138.047 1
2 119.***094 30.***283 137.877 1
3 119.***418 30.***282 137.728 1
1547 119.***645 30.***924 55.102 0
1548 119.***482 30.***318 55.312 0
1549 119.***412 30.***555 55.523 0
表 2-2 郡安里景區導航節點之線表（部分）
線段編號 起點點號 終點點號
八、、八、、-J —、八、、八、、-J 線段長度/m 權重
1 264 263 0.917 1
2 361 362 1.187 1
3 306 305 1.216 1
1568 1319 1321 10.083 1
1569 1547 1548 8.256 0
1570 1548 1549 9.555 0
郡安里景區一共建立導航節點1549個，導航節點間線段關系1570條。線表 是指相鄰兩個可通行點之間的線段信息，不跨點。由表2-1 和表2-2可知，點表 包括五部分信息：點號、經度、緯度、高程、權重，線表包括五部分信息：線段 編號、起點點號、終點點號、線段長度、權重，其中權重 0 表示只能行人通行， 權重 1 表示車輛和行人都可通行。
2.6圖像配準
系統中需要用到的地圖數據和基礎底圖之間存在幾何形變，需要進行圖像配 準操作。圖像配準是將不同方法獲得的同一地區的圖像，經過配準操作，使得同 名像點在位置上和方位上完全重疊的操作。如車載 APP 需要用到的郡安里景區 規劃效果圖與百度地圖之間就存在幾何形變，需要進行圖像配準，配準操作使用 ENVI 軟件進行，參考圖像是導航節點換到百度坐標系后得到的點圖，經過實地 檢查符合導航定位要求，配準結果如圖2-9所示。
圖 2-9 圖像配準結果圖
系統中車載APP使用百度坐標系，其它部分為CGCS2000坐標系，因此涉 及到了坐標轉換問題。一是導航節點由CGCS2000轉換到百度坐標，用于繪制規 劃路徑；二是后文“位置上報”功能中，將百度坐標轉換到CGCS2000,兩者均 采用四參數轉換，在系統中編程實現，經驗證轉換結果符合系統要求。
2.7本章小結
本章介紹了莫干山郡安里景區所處地理位置，以及景區管理方建立以車輛調 度為核心內容的綜合信息管理系統的需求，分析了系統建設的可行性，進一步闡 明了系統中使用的基礎地理信息數據的來源，為后續的開發工作提供數據依據。 其中包括郡安里景區管理方提供的郡安里景區總平面設計圖、規劃效果圖、航測 得到的DOM和DSM，以及在這些地圖基礎上得到的導航節點信息。點表數據 是系統中自定義導航的基礎數據，線表是系統中路徑規劃的基礎數據。
第3 章 車輛調度問題的遺傳算法
3.1問題分析
目前，我國大部分景區的車輛調度方式還停留在人工調度階段，或采用車輛 停在某處等游客坐滿后再出發的方式。這樣的調度模式經常導致車輛在景區內的 不均勻、不合理分布。在用車高峰期，常見車輛扎堆、車輛空放、部分路段無車 輛等情況，這樣的交通組織不僅增加了運營成本，還可能讓游客被迫選擇步行， 增加游客旅行負擔，進而降低對景區的好感度。郡安里景區目前采用的車輛調度 方式為人工叫車模式：游客在固定停車點將用車需求告訴工作人員，工作人員通 過對講機呼叫司機，司機再出發去接送游客。這樣的調度模式繁瑣、人工參與度 高、信息化程度低，不利于景區的長遠發展。
車輛調度問題已在物流配送領域得到了廣泛研究與應用。一般的車輛調度問 題可以描述為：對地理位置分散的游客點，在一定約束條件下，如車輛座位數限 制、客戶時間限制等，確定最優行進路徑，調派最優車輛接送游客，并達到如總 行車路徑最短、游客等待時間最短等目的（Coelho et al.，2015）。因此研究車輛 調度問題，就是研究車輛的選調方案，使得車輛依照最短的路徑或最短的時間， 服務于每個客戶，實現總成本最小。景區的車輛調度問題與此相似。
對于郡安里景區而言，車輛調度問題就是根據游客的用車需求，以及當前車 輛所在位置，在一定的優化目標如游客等待時間最短、總行駛距離最短、車輛額 定載客數等約束下，合理選調車輛，達到最優的運作結果。景區內的車輛調度主 要存在以下問題，管理方希望通過最少的投入，就能滿足游客的代步需求，以此 獲得最大利益；而游客則希望一人一車專車服務，讓專車隨時為我服務，獲得全 心全意的私人服務。因此管理方和游客的利益存在沖突，就需權衡利弊，盡可能 的找到一個平衡點。解決此類問題就需要利用科學算法，建立一個合理有效的車 輛調度方案（王惠， 2004）。
對于景區這類特殊場地，游客的乘車計劃有較為明顯的規律（鄧婷文，2016）， 一般來說熱門的景點的用車需求量比較大；臨近飯點時，用車需求與餐廳相關。 總的來說游客一般會從景區的入口或某個景點前往另一個景點。郡安里景區的入 口處便是停車場，主要是上山和下山兩條線路，均可雙向通行。按常規方法，可 在沿途設立乘車點，用開設公交線路的方式解決景區交通問題，但公交方式游客 體驗較差，等車時間較長而無機動性可言，空載幾率增加，成本上升，要精細化 管理景區交通可采用智能化車輛調度系統。
在車輛調度過程中，若在景區內均勻布設可預約乘車的站點，游客通過微信 小程序輸入自己的出行需求進行叫車服務，輸入內容主要包括上下車地點、所需 座位數、電話號碼等信息。系統根據游客的用車需求，統一調派車輛并規劃行駛 路徑，將調度結果命令發送給司機。這樣的線上叫車模式，游客使用方便，操作 簡單，能夠減少人工參與，提高信息化程度，向景區的智能化邁出步堅實的一步。
3.2數學模型
鑒于車輛調度問題規模大，問題比較復雜，而且各種計算和實驗表明（張漢 坤， 2019），啟發式智能算法在求解此類問題時更加方便快捷，且結果可靠，在 此羅列出啟發式智能算法的優缺點，見表3-1。
表 3-1 各啟發式智能算法特點
算法 優點 缺點
遺傳算法 可求解大規模問題。收斂性 強，計算速度快，適應性強。 局部搜索能力低，對初始種群有一定的依 賴，算法實現比較復雜，參數的選擇影響 解的品質。
模擬退火算法 全局搜索能力強，計算過程
簡單 容易過早的收斂，陷入局部最優解。
粒子群算法 通用性強，搜索速度快，結構
簡單，易于實現 局部搜索能力較差，全局收斂性較差，計 算精度較差，結果依賴于參數的選擇，不 能有效解決離散及組合優化問題。
神經網絡算法 具有自學習、聯想存儲功能，
解算能力強 參數多，學習時間長；數據不充分時無法 工作。結果容易丟失信息。
禁忌搜索算法 易于實現，最接近最優解。與 對初始解的依賴性很強，隨著數據量的增
其他算法結合能力強 長，求解速度明顯降低。
蟻群算法 正反饋機制，分步計算。尋優 規模較大時，計算時間長；參數的選擇對
能力強，結果不依賴初始解 解的質量影響很大。容易出現停滯現象。
從表 3-1 可知，遺傳算法所具有良好的收斂性、適應性和全局搜索能力，能 夠高效的獲得最優解。不僅如此，由于其進化特性，在求解過程中只需要將問題 的解抽象為基因表達形式，能對任意形式的目標函數進行處理，且能夠進行概率 意義上的全局搜索，保證了解的質量（曹二保， 2008）。基于這些特點，本文采 用遺傳算法解決車輛調度問題。
3.2.1遺傳算法
遺傳算法是由 Holland 教授 1967 年提出的，遺傳算法將問題的解轉化成一 組編碼，將問題在表現型與基因型之間做轉換，形成初始化種群，計算種群中個 體的適應度，以適應度值判斷個體的優劣，通過選擇、交叉和變異等操作來模擬 生物適者生存、遺傳變異的過程，進而求得問題的最優解（陳國良等， 1996）。 初始階段，遺傳算法從確定大小的、表示問題解的初始種群中開始搜索，以根據 實際問題得到的適應度函數值評價個體與種群，使用選擇策略從當前種群中選擇 優秀個體，通過交叉和變異操作產生新一代種群，如此一代代地演化下去，直到 滿足一定條件為止。遺傳算法利用簡單機制就能夠解決復雜難題，能夠在較大的 參數空間中搜索得到最優解（甄文祥， 2000）。
3.2.2數學模型
基于以上對景區車輛調度問題的分析來構建景區車輛調度模型。構建景區的 車輛調度模型的目的在于提高景區車輛的運營效率，滿足游客對車輛的時間要求， 降低車輛運營成本的同時提高服務質量。為達到這一綜合優化目的，將車輛運營 成本和時間要求做線性處理，即目標函數G將由所有車輛運行成本G1和所有違 反游客時間的懲罰成本G2兩部分組成，如式（3-1）。對于景區綜合信息管理來 說，考慮運行成本和滿足游客時間需求一樣重要，所以此處兩者權重一樣。
G =G1+G2 （3-1）
由于郡安里車輛為電動車，車輛的運行成本就包括耗電和日常損耗兩部分， 既可得到如式（3-2）的表達式：
G1 = 丫 (a+b)L
a為車輛每公里耗電成本，b為車輛每公里損耗成本，廠為車輛7行駛的總 距離。
針對游客叫車時間要求，對違反游客時間的懲罰成本采用懲罰函數思想進行 量化。當車輛到達時間，超過游客設定上車時間時，對其做出懲罰；當車輛到達 時間在游客設定時間內時，不做任何懲罰。具體游客時間懲罰成本由式（3-3）確 定。
其中以為懲罰系數，tn為車輛到達時間，tp游客設定上車時間。則有游客時 間懲罰成本等于所有車輛受到懲罰的和，如式（3-4）。
G2 = Yt (3-4)
綜上可得目標函數表達式為：
G = min(G1+ G2) (3-5)
同時，車輛調度還需滿足以下約束：
(1)參與調度車輛數量不超過景區內可調度的車輛總數目。
(2)車輛單次運輸人數不得超過車輛的額定載客數。
(3)為了簡化問題，假定游客發布的信息完全正確。
(4)游客按照調度安排乘坐指定車輛，中途不改變目的地，不刁難司機。
3.3遺傳算法求解過程
遺傳算法求解過程不依賴于問題本身，它僅對遺傳算法產生的每個個體基于 適應度進行評價和選擇，在整個進化過程中是遺傳算法的五個基本操作分別是確 定編碼解碼規則、確定參數值、生成初始種群、構造適應度函數、設定遺傳操作 (郭肇祿， 2014)。遺傳算法的流程如圖 3-1 所示。
圖 3-1 遺傳算法流程圖
遺傳算法的具體步驟包括：
（1）根據實際問題確定編碼規則，并將實際問題轉化為基因結構；
（ 2）確定遺傳操作參數：種群大小、選擇策略、交叉策略、變異策略、交 叉概率、變異概率；
（3） 選擇合適的方式產生初始化種群中的每一個個體基因；
（4） 計算種群中每個個體的適應度函數值；
（ 5）應用選擇、交叉和變異操作產生下一代種群；
（6）判斷種群能否滿足設定的終止條件，不滿足則重復步驟（5）和（6）， 直到滿足終止條件為止，結束后解碼輸出最佳方案。
3.3.1編碼
編碼就是將車輛調度問題的可能解轉換為遺傳算法可以處理的基因序列形 式，編碼方式直接影響到解的表現形式，編碼應結合適應度函數，以便于適應度 函數計算處理。目前常見的編碼方式有二進制編碼、字符編碼、自然數編碼、自 適應編碼等，選擇合適的編碼方式能有效的提高算法的求解效率和效果（陳建安 等， 1998）。郡安里景區內的車輛調度問題與經典的車輛調度不同在于游客的起 點和終點具有方向性。吳樹新（2015）用遺傳算法解決城市出租車合乘問題時， 將終點和起點同時放入編碼中，在遺傳操作中，檢查每條基因序列，有亂序的情 況時交換起點終點位置。這樣的起點加終點的編碼形式，隨著數量增加，算法計 算效率低下。因此根據前文構建的調度模型，本文改進了編碼和解碼方式，只采 用起點的自然數編碼，終點根據貪心思想最終形成行駛路徑。
假設調度中共有10個叫車信息參與調度，其中有兩個游客在4號站點上車， 起點編號包括：1 2 3 4 4 5 6 7 8 9，終點編碼為對應起點編碼加10：11 12 13 14 14 15 16 17 18 19，則改進前和改進后的基因序列如下所示：
改進前基因序列：4 5 6 1 2 3 7 8 9 4 14 15 16 11 12 13 17 18 19 14
改進后基因序列：4 5 6 1 2 3 7 8 9 4 顯然，改進后的編碼方式因沒有加入終點編號，基因序列長度減半，降低了 算法的全局搜索范圍，有利于更加快速地得到最優解。
3.3.2解碼
根據基因序列，依次讀取上車人數并求和，滿足車輛額定載客數后，重新為 后續游客依次安排車輛，依次類推，直到所有游客都安排上車。在安排過程中每 個叫車請求中的游客安排在同一輛車上。
每輛車最終行駛路徑根據車上所有游客的起點編號將終點編號插入。形成行 駛路徑時基于貪心思想，每次選擇距離上一個點最近的可插入點插入到路徑中 （兩點之間的距離由 Dijkstra 算法確定）。根據實際情況可知，行駛的第一個點 必定是起點，最后一個點必定是終點，其次確定具體路徑時，中間經過點注意對 應起始點的順序。這樣的編碼和解碼形式能夠彌補遺傳算法在局部搜索能力的不 足，增強結果的可靠性。
假設上述舉例的基因序列按照解碼規則一共派遣了3輛車，現在車輛都在1 號站點，且以下路徑均為每輛車在滿足游客時間需求下，行駛的最短路徑，則根
據解碼規則路徑如下：
車輛 1：
車輛 2： 車輛 3：
1—4—5—6—14—15 — 16
1—2—7—12—3 — 1 — 13 — 17 T11
1—4—8—14—9—19—18
解碼過程偽代碼實現如下： initialize bestPop;
starts j []; points j []; route j []; sumPop j 0; for i j 1 to chromosome_size
if sumPop + numPop(i) <= 8
sumPop j sumPop + numPop(i); starts j [starts, bestPop(i)];
else
sumPop j numPop(i); points j [points, starts]; while (~isempty(points)) route j [route, minPoint]; points remove minPoint; points add minPointEnd;
print route;
points j [bestPop(i)]; index j i;
if i = index
// 相等時剩下最后一個乘客單獨乘車 print route;
else
points j [points, starts];
while (~isempty(points))
route j [route, minPoint]; points remove minPoint; points add minPointEnd;
print route;
//
//
//
//
//
//
//
//
//
//
//
//
//
遍歷整個基因序列
判斷是否超載
累加占座位數 分在一輛車上的所有起點
構造路徑可插入點數組
路徑放入最近可插入點 移除已插入的點 添加已插入點對應的終點 輸出車輛的行駛路徑
構造路徑可插入點數組
路徑放入最近可插入點 移除已插入的點 添加已插入點對應的終點
上述代碼中：bestPop表示計算得到的最佳個體的基因序列，sumPop表示累
計占座位數，chromosome_size表示基因序列長度，numPop(i)表示基因序列中第
i 個基因對應的占座位數，后文中相同字符表示內容一致。
3.3.3初始化種群
遺傳算法從初始種群開始搜索，一般情況下，初始種群在問題解空間中采樣 要盡量均勻且數量規模大小適當，初始種群常常隨機產生(徐洋洋， 2013)。合 理分布均勻的初始種群對算法的求解效率有著直接的影響，算法求解質量在一定 程度上依賴于初始種群，因此，改進遺傳算法的方式之一就是改進初始化種群。 根據上述編碼方式生成個體的基因序列，基因為所有起點對應自然數的全排列， 所以本文初始種群隨機產生。將下列偽代碼運行 50次，生成初始化種群。
population(i,:) — randperm(chromosome_size);
由于本文的基因序列中有重復基因，事先所有基因進行處理，使所有基因最 終變為從 1開始的連續自然數。
3.3.4適應度函數
適應度函數體現的是生物的進化法則，用于對種群中的個體進行評價，以實 際優化目標為準則，由約束條件共同決定。適應度函數值越大，表示個體生存能 力越強，越符合目標函數，是遺傳算法中判斷個體優劣的標準。合理恰當的適應 度函數可以使算法高效地找到最優解，引領著種群的進化方向。
根據本文的目標函數，個體的目標函數值越小，適應度函數值就應越大，生 存能力越強。所以本文的適應度函數使用目標函數G的倒數，即
F = — (3-6)
F G
式(3-6)中，適應度函數 Fp 的值是個體 p 的適應度大小，適應度值越大， 生存的機會越大，進化到下一代的概率也越大。反之亦然，適應度值越小進化到 下一代的概率就越小。
3.3.5遺傳操作
遺傳操作主要靠選擇、交叉、變異三個算子實現，它們共同決定著種群的進 化，在保證種群多樣性的同時，使種群變得越來越適合生存環境，即適應度函數 值越大。
(1)選擇算子
選擇算子體現的是適者生存的法則，保證種群是向著適應度變大的方向進化， 目前常見的選擇算子主要有輪盤賭選擇、排序選擇、精英保留選擇、競標賽選擇
等(He et al.，2021)。本文采取輪盤賭選擇加精英保留選擇的方式進行選擇。 首先每一代的最佳個體直接遺傳到子代，其次由輪盤賭選擇其他適應度大的 個體，這樣能夠保證每一代的最佳個體一定優于或等于上一代的，選擇算子偽代 碼實現如下：
for i — 1 to population_size - 1 // 遍歷種群
r — rand * fitness_sum(population_size); // 生成一個［0,總適應度］之間的隨機數 // 輪盤賭選擇
if r < fitness_sum(1)
population_new(i,:) — population(1,:);
else
for j — 1 to population_size
if fitness_sum(j-1) < r <= fitness_sum(j); population_new(i,:) — population(j,:); population_new(population_size) — bestPop; // 精英保留
上述代碼中：fitness_sum (i)表示前i個個體的適應度之和，population (j,:) 表示當前種群的第j個個體,population_new(i,:)表示新一代種群的第i個個體。
( 2)交叉算子 交叉算子體現的是父帶基因重組生成子代的過程，保證種群中基因的多樣性。
常見的交叉類型主要有單點交叉、多點交叉、一致交叉、部分匹配交叉等(He et al.， 2015)。根據本文編碼和解碼方式，選擇單點交叉即可；交叉概率一般為 0.4 至 0.9 之間，本文選擇交叉概率為 0.9。實行交叉操作的具體過程如下：
①在種群中隨機選取兩個個體X和Y：
X = 4 7 8 6 3 1 5 2 9 10
Y= 8 6 2 9 7 4 3 1 10 5
②隨機產生一個交叉位K,將交叉位及之前的基因放到另一條基因序列最 前面，假設K=4，則有：
X1 =( 8 6 2 9) 4 7 8 6 3 1 5 2 9 10
Y1 =( 4 7 8 6) 8 6 2 9 7 4 3 1 10 5
③刪除交叉操作之后重復的基因，保證基因長度不變，最終得到交叉后的 X和Y。
X = 8 6 2 9 4 7 3 1 5 10
Y= 4 7 8 6 2 9 3 1 10 5 交叉算子偽代碼實現如下：
if rand < cross_tate // 隨機數小于交叉概率
rp — randperm(50,2); // 隨機生成 2 個 1-50 的隨機數
X — population(rp(1),:);
Y — population(rp(2),:); cross_position = round(rand * (chromosome_size - 1) +1); // 隨機交叉位置
X1 j [temp1,X]; // 拼接基因序列
Y1 j [temp2,Y];
X J deleteRepeat(X1); //刪除X1中的重復基因
Y j deleteRepeat(Y1);
上述代碼中：temp1和temp2分別表示Y和X交叉位及之前的基因。
(3)變異算子 變異算子體現的是基因突變的過程，挖掘種群中個體多樣性，克服可能限于 局部解的弊端。常用的變異方式有實值變異、取反變異、本位變異、均勻變異以 及非均勻變異。根據本文模型，變異操作時隨機產生一個變異位置，將變異位置 前后的基因片段進行交換。變異概率一般為 0.001 至 0.1 之間，本文選擇變異概 率為 0.1。變異算子偽代碼實現如下：
if rand < mutate_rate // 小于變異概率
mutate_position = round(rand*(chromosome_size-1) + 1); // 隨機變異位置 temp j population(i,:);
// 變異操作
for k j 1 to chromosome_size
if k <= chromosome_size - mutate_position
population(i,k) = population(i, mutate_position + k);
else
x = k - chromosome_size + mutate_position; population(i,k) j temp(x);
3.3.6終止條件
遺傳算法的終止條件通常有兩種定義方式，一種是設定算法的最大進化代數； 另一種形式是判斷是否已經搜索到了最優解，或者是最優解達到某個程度就輸出 結果。本文選擇采用第一種方式，設定最大進化代數為 200代，這樣設置簡單易 行，既能在有效的時間內控制算法得出最優解，又一定程度上保證算法的精度。
3.4實驗分析
(1)站點分布與測試數據
在景區內設置 20 個可叫車的預約站點，均勻分布在景區內，相對位置分布 如圖3-2所示。測試數據為某時段內10位游客發布的叫車信息，具體見表3-2。
圖 3-2 郡安里景區站點分布圖
表 3-2 游客叫車信息表
序號 起點點號 終點點號 座位個數 上車時間
1 1 5 2 叫車10min內
2 1 6 3 叫車 10min 內
3 1 13 4 叫車 10min 內
4 3 7 3 叫車 10min 內
5 6 12 2 叫車 10min 內
6 10 4 4 叫車 10min 內
7 14 4 6 叫車 10min 內
8 16 10 2 叫車 10min 內
9 16 18 1 叫車 10min 內
10 17 10 3 叫車 10min 內
( 2)條件設置
此時有12輛車可以參與調度，一輛車在10站點，一輛車在14站點，其余 車輛全在 1 號站點（停車場），每輛車的額定載客數為 8人，平均車速為20 千米 每小時，車輛耗電和日常損耗之和為每千米1 元，具體參數見表3-3。
表 3-3 車輛相關參數
車輛數（輛） 額定載客數（人） 平均車速（ km/h） a+b （元/km）
12 8 20 1
（3）遺傳算法參數設置 遺傳算法測試中需要明確基因序列長度、種群大小、最大進化代數、選擇方 式、交叉和變異概率，具體參數設置見表 3-4。
表 3-4 遺傳算法參數設置
基因序列長度 種群大小 最大進化代數 交叉概率 變異概率 a
10 50 200 0.9 0.1 100
（4）結果分析
由于遺傳算法中的隨機性，迭代次數每次計算時會不一致，繪制出某次改進 前和改進后的最佳適應度隨代數的變化曲線，如圖3-3所示。種群中最優個體適 應度在朝著適應度變大的方向進化，滿足遺傳算法變化規律，用該思路解決景區 內車輛調度問題切實可行。改進后的遺傳算法在200 代內得到的最優解速度和質 量優于改進前，并且迭代次數明顯減少。
本次計算過程中改進后的最佳個體出現在第75代，根據公式（3-6）算出的 最佳個體適應度為0.1056,計算總用時4s,而改進前的最佳個體出現在第166代, 最佳個體適應度為0.1024,計算總用時15s。說明改進后的遺傳算法在此情況下 能夠更快地得出較高質量的最優解，無論是在獲得最優解的速度，還是在解的質 量上均優于改進前，也說明了遺傳算法在解決此類車輛調度問題時的高效性。改 進后遺傳算法輸出的最優個體基因序列為： 17 1 16 16 3 1 10 14 1 6。解碼后得到： 一共派遣5輛車完成任務，所有路徑都能滿足游客的時間要求，每輛車具體路線 如下所示：
車輛 1： 1—1—5—17—16—16—18—10—10
車輛 2： 1—1—3—6—7
車輛 3： 10—10—4
車輛 4： 14—14—4
車輛 5： 1—1—6—12—13
圖 3-3 最優個體適應度隨代數變化曲線
（5）對比實驗
另外對改進前后的算法分別計算5000次作對比，改進后的算法平均迭代次 數為77次，最佳適應度不低于0.1056的次數為4627次，改進前的平均迭代次 數為124次，最佳適應度不低于0.1056的次數為14次，說明改進后的算法優于 改進前，避免了遺傳算法陷入局部最優，提高了算法效率。
3.5本章小結
本章首先分析了郡安里景區存在的車輛調度具體問題，并根據各類求解車輛 調度問題算法的優缺點，選擇用遺傳算法解決郡安里景區內車輛調度問題。根據 同時考慮車輛運營成本和游客用車時間的要求，設計出車輛調度模型，通過測試 數據驗證了算法的有效性。實驗結果表明：針對此類有起點終點有順序的車輛調 度問題，只選擇起始站點進行編碼，終點在解碼時根據貪心思想形成最終路徑， 這樣改進后的遺傳算法降低了全局搜索范圍，增強了局部搜索能力，能夠快速有 效地得出較高質量的解。
第4 章 綜合信息管理系統設計
4.1系統開發相關技術
4.1.1WebGIS
WebGIS 又稱網絡地理信息系統，是傳統 GIS 借助互聯網技術發展形成的， 具有傳統 GIS 的數據檢索、查詢、編輯、制圖輸出等功能，同時通過互聯網將地 理信息數據進行管理和共享，用戶只需要訪問指定網址，就可獲得WebGIS提供 的數據服務（陳春來等，2004）。與傳統的GIS相比WebGIS具有獨立性強、可 擴展性強、用戶使用方便、操作簡單等特點，因此，WebGIS在各行各業中得到 了廣泛應用，讓地理信息成為了人們生活中必不可少的一部分。隨著智能手機和 互聯技術的高速發展，移動端的GIS越來越成為國民生活的一部分，其中百度、 高德等多家地圖產業公司做出了巨大貢獻，未來的 GIS 必然是朝著移動端方向 發展（周輝等， 2010）。
4.1.2MySQL
MySQL 是一種關系型數據庫管理系統，使用結構化查詢語言，可運行在多 個系統上，支持多種編程語言，其最大特點是開放源碼。近年來隨著數據庫技術 的不斷發展， MySQL 數據庫由于其出色的穩定性、可靠性和開源性，加之其使 用簡單、邏輯結構清晰、硬件要求低等優勢，受到越來越多的中小型企業和個人 的關注（俞海等， 2017）。本文中采用 MySQL 數據庫對系統的數據進行存儲和 管理。
4.1.3WebSocket
由于本系統在設計中需要實現服務器主動向客戶端發送信息，而在傳統的 HTTP 協議，通訊只能由客戶端發起（胡洋洋， 2018）。很多網站在實現實時推送 時，都采用 Ajax 輪詢技術。該技術的本質還是通過客戶端請求，服務器返回數 據給客戶端，不同在于這個請求由客戶端在特定的時間間隔（如每隔2秒）自動 發出。這種傳統模式的缺點也較明顯，即客戶端需要不斷的向服務器發出請求， 然而 HTTP 請求可能包含較長的頭部，其中真正有效的數據可能只是很小的一部 分，造成了帶寬等資源的浪費。
WebSocket 是一種在單個 TCP （Transmission Control Protocol）連接上進行全 雙工通訊的協議(石文濤， 2014)。最大的特點是：允許服務端主動向客戶端推 送數據。在使用 WebSocket 時，客戶端和服務器只需要完成一次握手，兩者就可 通過該通道隨時隨地的發送數據，使服務器與客戶端的數據交換變得更加簡單。 所以本系統中采用 WebSocket 技術進行數據交互。
4.1.4JSON
JSON(JavaScript Object Notation)是一種輕量級的數據交換格式，數據的存儲 和表示采用文本格式(王東華，2016),層次分明，簡潔明了，易于閱讀和編寫， 數據量很小，能夠在任意平臺和開發語言中讀取、傳輸和使用，有效地提升了網 絡數據傳輸效率。JSON數據基礎格式為鍵值對形式，不同數據間用逗號分隔， JSON常見編輯形式分為數組、對象和復合對象三類，在開發過程中能夠很容易 將各類數據轉化為JSON數據，常使用JSONObject進行封裝轉換。鑒于以上原 因JSON是目前主流的數據交換格式，廣泛應用在各項數據交換中，本文中的數 據通訊格式也采用JSON格式。
4.1.5第三方地圖服務
如今百度地圖、高德地圖等電子地圖已經成為國民生活的一部分，顯示當前 所在位置的同時，可隨時隨地查詢任意位置，并且給出路徑導航，使出行變得簡 單快捷。對于軟件開發來說，此類地圖服務商提供開發接口 API (Application Programming Interface),允許其它應用集成并使用其地圖服務。常見的地圖API 有：天地圖、百度地圖、高德地圖、騰訊地圖等。開發過程中，使用地圖API能 夠方便開發人員輕松地獲取到想要的基礎地理信息數據，如位置和道路數據；對 一個系統來說，不再需要費力構建基礎GIS數據，節省開發時間和經濟投入，符 合當今共享的發展理念。
響應國家號召和為將來必定采用的 CGCS2000 坐標系需求做準備，綜合信 息管理系統和微信小程序選擇由國家測繪地理信息局推出的，坐標系為 CGCS2000的天地圖作為地理底圖，使用Web端API提供的直接以圖片形式疊 加地圖的方法;但天地圖Android端的API中無該方法，且開發時間緊迫，因此， 車載APP端的地理底圖采用作者更加熟悉的百度地圖。
4.2系統總體設計
針對郡安里景區的管理需要，經過可行性分析，確定了構建綜合信息管理系 統的可能性，選定了軟件開發平臺、數據庫管理系統、地理底圖、數據通訊模式、
數據格式、坐標系等。從郡安里景區實際情況出發，系統率先完成以車輛調度為 核心內容的部分功能，為保證結構配置的合理性，設計時需保證系統的先進性、 實用性、完備性、可擴展性、可維護性、安全性、兼容性和穩定性。在保證系統 功能和性能的前提下，為后續郡安里景區智能化進程打下堅實基礎。
4.2.1系統框架
在基礎地理信息支撐下，針對目前郡安里景區車輛調度的核心需求，結合人 員、環境信息化管理等未來的潛在需求，構建郡安里景區的綜合信息管理系統框 架結構，其總體框架如圖 4-1 所示。
圖 4-1 綜合信息管理系統建設總體架構圖
綜合信息管理系統的建設是以基礎地理信息數據為基準，針對當前車輛調度 需求，結合郡安里景區車輛、人員、安防等管理信息數據，采用網絡服務加終端 應用的模式，實現郡安里景區的全域信息化管理。系統總體框架包括基礎設施層、 數據資源層、業務應用層、用戶層等四個層次結構。
4.2.2 基礎設施層
主要包括基礎設施和支撐軟件兩部分內容，其中，基礎設施則是指綜合信息 管理系統的物理承載，如網絡、服務器、存儲設備等；支撐軟件則是為了確保系 統正常運行所需要的操作系統、數據庫等軟件系統。
基礎設施：租用阿里云的基礎設施服務，具體見表4-1。
支撐軟件：支撐軟件主要是滿足系統正常運行所需要的操作系統、數據庫、 運行環境等軟件，具體見表 4-2。
表 4-1 基礎設施需求表
名稱 配置及性能說明
Web 服務器
移動網絡 CPU： 4核以上；
內存容量：16GB以上；
硬盤容量：120GB云盤；
操作系統： Windows Server 2008/2012；
其他要求：滿足Web門戶網站訪問需求【20MB以上帶寬資源】
支持4G信號覆蓋
表 4-2 支撐軟件需求表
名稱 說明
操作系統 數據庫 系統運行環境 Windows Server 2008/2012
MySQL 5.0
ASP.Net 4.0； NET FrameWork 4.5； JDK 1.8； Android 8.0
4.2.3數據資源層
實現對系統平臺所使用數據的存儲管理，主要包括基礎數據庫、空間數據庫、 人員活動數據庫等。
基礎數據庫：基礎數據庫主要實現系統中人員、車輛等基礎信息的管理，主 要包括表 4-3 中所列的幾類數據。
表4-3基礎數據庫表
名稱 說明
人員編號、姓名、性別、年齡、類別、職務等基本信息
車輛編號、車牌號碼、車輛類別、使用年限、使用狀態等基本信息
導航節點編號，導航節點經度，導航節點緯度
視頻監控等點位的基本信息，包括監控編號、類別、坐標位置、接口
IP 等基本信息
其它需要系統保存的基本信息數據
空間數據庫：空間數據庫主要實現系統中涉及的遙感影像、矢量地圖等空間 信息數據的管理，主要包括表4-4中所列的幾類數據。
表4-4空間數據庫表
名稱 說明
客咸像 通過測繪過程得到的郡安里正射影像數據，數據庫中保存遙感影像的
遙感影像 數據時間、存儲位置等基本信息，遙感影像數據以文件形式保存。
矢量地圖 通過測繪過程得到的郡安里景區矢量線劃圖。
拓撲關系 通過對矢量數據進行計算得到拓撲數據，用于內部導航使用。
… 系統涉及的其它有關空間信息數據。
人員活動數據庫：人員活動數據庫主要實現系統中涉及的人員活動數據，如
車輛使用情況、游客用車等信息數據，主要包括表4-5中所列的幾類數據。
表4-5人員活動數據庫表
名稱 說明
車輛編號（和車輛基礎信息表對應）、使用時間、司機、起點、終點、 行駛時長等信息。
車輛編號（和車輛基礎信息表對應）、坐標位置、定位時間等信息 人員的活動情況，人員編號（和人員信息表對應）、活動。 游客編號、姓名、性別、旅游項目、到達時間、離開時間等信息。 安防事件編號、發生時間、處理時間、處理人等信息。 系統涉及的其它有關人員活動的信息數據。
4.2.4業務應用層
業務應用層主要實現郡安里景區車輛調度相關業務流程，同時為將來可能存 在的綜合信息化管理模式搭建框架和基礎，業務層主要包括綜合信息管理平臺、 車載APP、微信小程序三部分內容，郡安里景區的綜合信息管理系統關系結構如 圖 4-2 所示。
圖 4-2 綜合信息管理系統關系結構圖
綜合信息管理平臺：是整個軟件體系的中心，主要提供給管理人員使用，用 于實現對系統所有數據的存儲與管理功能，同時作為車載 APP 和微信小程序的 后臺調度平臺，確保兩者之間的數據能順利共享與交互。
車載APP：安裝在司機的安卓手機終端，在后臺管理系統的支持下，接收游
客的叫車信息，接送游客，顯示規劃道路及路徑高程剖面圖等。
微信小程序：提供給游客使用，在后臺管理系統的支持下，實現游客線上叫 車功能，顯示車輛位置和路徑等信息。
4.2.5用戶層
在系統統一的安全體系基礎上，針對郡安里景區管理部門、業主、司機、游 客的實際需求設定用戶。管理部門主要使用綜合信息管理平臺，擁有最高權限， 可以編輯數據庫內容，所有賬戶由管理方設定產生，不提供注冊功能；游客通過 微信掃碼或搜索小程序的方式使用叫車服務，無需注冊賬戶便可直接使用；司機 使用車載 APP 根據提示信息接送游客，使用管理方提供的員工個人賬戶進行登 錄。
4.3系統數據庫設計
數據庫是整個系統中數據管理的核心，也是決定一個系統優劣的關鍵，一個 良好的數據庫系統會使整個系統高效運行，使系統具有完整性。數據庫的搭建主 要在于數據庫表的設計，根據具體的需求，對各類數據信息進行歸納分析，將所 需內容轉換為數據庫可存儲的結構。在數據庫表設計時，除了需要保證數據實體
使用需求與設計范式外，還應注意主鍵、唯一鍵約束的合理性，中間表的靈活性， 以及適當的冗余性，進而保證數據存儲的正確性與數據訪問操作的高效性（何奕 慧， 2014）。在郡安里景區車輛調度綜合信息管理系統中，存在游客、車輛、接 送任務三個對象實體，根據對象關系建立實體關系圖，如圖 4-3 所示。
系統中，游客通過線上叫車與接送任務建立聯系，為一對一關系；車輛通過 車輛調度與接送任務建立關系，為一對多關系。依據以上數據庫表設計要求，綜 合分析車輛、游客、接送任務三者的屬性信息，由此設計了表 4-6 中的幾類數據 庫表。
表 4-6 系統中所用到的表及用途
表名 用途
JALStaffInfo 員工基本信息表
JALCarCallerRecorInfo 叫車記錄信息表
JALCarInfo 車輛基本信息表
JALCarPosData 車輛點位信息表
JALRoadNodeInfo 節點基本信息表
JALRoadSegmentInfo 路段基本信息表
JALCarWorkRecordinfo 車輛工作記錄信息表
JALVisitorsInfo 游客基本信息表
（1）員工基本信息表。
在員工基本信息表中存放了員工的F_ID、編號、名字、電話號碼、系統登 錄密碼等信息。具體見表4-7。在實際表中每個字段名前有“jal_”標識符，在此 為了表示的方便與整潔，表中去掉了該部分標識符。
表 4-7 員工基本信息表
字段名稱 字段含義 數據類型 屬性限制
F_ID 唯一標識碼 varchar 主鍵
StaffCode 員工編號 varchar 唯一
StaffName 員工名字 varchar 非空
StaffPass 員工登錄密碼 varchar 非空
StaffChief 員工簡稱、登錄名 varchar 非空
StaffPhone 員工聯系電話 varchar 數字
（2）叫車記錄信息表。
在叫車記錄信息表中存放了 F_ID、游客的代碼、姓名、電話號碼、起點、終 點、叫車時間、叫車反饋時間、游客上下車時間、響應車輛ID、駕駛員ID、無 法接送車輛ID等信息，具體見表4-8。
表 4-8 叫車記錄信息表
字段名稱 字段含義 數據類型 屬性限制
F_ID 唯一標識碼 varchar 主鍵
CallerCode 游客代碼 varchar 唯一
CallerName 游客姓名 varchar 非空
CallerPhone 游客電話 varchar 數字
CallerPlace 游客起點 varchar 非空
CallerSeatNum 需要座位數 int 非空
CallerEndPlace 游客終點 varchar 非空
CallerTime 叫車時間 varchar 非空
CallerTimeBack 叫車反饋時間 datetime 非空
CallerBoardTime 游客上車時間 datetime 非空
CallerArrivedTime 游客下車時間 datetime 非空
CallerCarID 響應車輛 ID varchar 唯一
CarDriverID 駕駛員 ID varchar 唯一
CallerNotGo 無法接送車輛ID varchar 默認空
（3）車輛基本信息表。
在車輛基本信息表中存放了車輛的F_ID、代碼、當前狀態、座位總數、有 效座位數等信息，具體見表 4-9。
表 4-9 車輛基本信息表
字段名稱 字段含義 數據類型 屬性限制
CarCode 車輛代碼 varchar 主鍵
CarConnector 車輛聯系人 varchar 非空
CarStatus 車輛狀態 varchar 非空
CarSeatCount 車輛座位總數 int 非空
CarValidateSeat 車輛有效座位數 int 非空
（4）車輛點位信息表。 在車輛點位信息表中存放了運行車輛的代碼、所在位置經緯度、位置更新時 間等信息，具體見表 4-10。
表 4-10 車輛點位信息表
字段名稱 字段含義 數據類型 屬性限制
CarCode 車輛代碼 varchar 主鍵
CarPosLat 車輛位置緯度 double 非空
CarPosLon 車輛位置經度 double 非空
CarPosUpTime 車輛位置更新時間 datetime 非空
（5）節點基本信息表。
在節點基本信息表中存放了郡安里景區運行道路上各節點信息，包括節點的
代碼、名稱、經緯度、 類別等信息，
表 4-11 具體見表 4-11。
節點基本位信息表
字段名稱 字段含義 數據類型 屬性限制
NodeCode 節點代碼 varchar 主鍵
NodeName 節點名稱 varchar 唯一
NodeType 節點類別 varchar 非空
NodeLon 節點經度 double 非空
NodeLat 節點緯度 double 非空
NodeStatus 節點狀態 varchar 非空
（6）路段基本信息表。
在節點基本信息表中存放了路段的編號、起點和終點編號、路徑長度、路徑 類型等信息，具體見表4-12。
表 4-12 路段基本位信息表
字段名稱 字段含義 數據類型 屬性限制
SegNo 路段編號 int 主鍵
BNodeCode 起點編號 int 非空
ENodeCode 終點編號 int 非空
SegLength 線段長度 double 非空
SegWeight 線段權重 int 非空
SegType 線段類型 varchar 非空
（7）車輛工作記錄信息表。
在車輛工作記錄信息表中存放了車輛代碼、駕駛員ID、開始和結束位置、 開始和結束時間、訂單F_ID等信息，具體見表4-13。
表 4-13 車輛工作記錄信息表
字段名稱 字段含義 數據類型 屬性限制
CarCode 車輛代碼 varchar 主鍵
F_ID 訂單唯一標識符 varchar 唯一
CarWorkBPlace 運行開始位置 varchar 非空
CarWorkBLon 運行開始經度 double 非空
CarWorkBLat 運行開始緯度 double 非空
CarWorkEPlace 運行結束位置 varchar 非空
CarWorkELon 運行結束經度 double 非空
CarWorkELat 運行結束緯度 double 非空
CarWorkBTime 開始時間 datetime 非空
CarWorkETime 結束時間 datetime 非空
CarWorkDriverID 駕駛員ID varchar 非空
（8）游客基本信息表。
在游客基本信息表中存放了游客的F_ID、姓名、電話、性別等信息，具體 見表 4-14。
表 4-14 游客基本信息表
字段名稱 字段含義 數據類型 屬性限制
F_ID 游客編碼 varchar 主鍵
VisitorName 游客姓名 varchar 非空
VisitorCode 游客微信號 varchar 默認空
VisitorPhone 游客電話 varchar 非空
VisitorSex 游客性別 varchar 默認空
VisitorAge 游客年齡 int 默認零
4.4綜合信息管理平臺設計
綜合信息管理平臺運行于系統服務器端，采用B/S架構設計，主要包括車輛 調度、信息管理、可視化、最短路徑規劃等四個模塊，其功能模塊劃分如圖 4-4 所示。
綜合信息管理平臺
圖 4-4 綜合信息管理平臺功能模塊圖
441 VS平臺
綜合信息管理平臺基于Visual Studio 2017 （簡稱VS）開發，使用C#語言。 開發框架選擇目前主流框架 ASP.NET MVC5， ASP.NET MVC5 是微軟提供的以 MVC（Model-View-Controller）模式為基礎的應用程序框架（秦冠男，2013）, MVC 各部分關系如圖 4-5 所示。
圖 4-5 MVC 框架關系圖
MVC5 開發框架提供了開發基礎，使開發者可以比較清晰的構建應用程序， 讓開發工作變得更加的方便與快捷，同時也方便代碼的管理與更新。 MVC5 注重 關注點分離，將整體框架分為三層，Model為數據處理層，具體實現某功能；View 為視圖層，顯示運行結果，與用戶交互；Controller為控制層，把特定的功能邏 輯抽離出來。這樣的關注點分離設計理念，使得程序更加簡化、可維護性大幅提 高、更加容易測試（黃保翕， 2013）。
4.4.2車輛調度模塊
車輛調度模塊是根據游客的叫車信息，結合當前車輛位置、車輛額定載客數 等實際情況，調派合理的車輛接送游客，在保證游客服務質量的前提下，盡可能 的降低車輛運行成本。采用本文第三章改進后的遺傳算法，系統自動規劃出最優 的車輛接送方式，并向指定車載 APP 發送調度信息。在調度過程中判斷此時游 客的 WebSocket 連接數量，第一如果連接數量小于 20，直接實時指派最近車輛 接送游客；第二如果連接數量大于等于20，在30秒內每接收到10個叫車信息， 將這10個叫車信息按照調度算法統一調度；如果30秒內接收到的游客叫車信息 不足 10個，將這段時間內接收到所有叫車信息按照調度算法統一調度。
4.4.3信息管理模塊
車輛管理模塊主要基于地理信息平臺，實現對郡安里景區內的車輛的基本信 息進行管理，包括信息編輯、信息查詢等功能。
（1）車輛信息編輯
以列表形式，對郡安里景區車輛的編號、車輛類別、使用年限、使用狀態等 基本信息進行編輯，主要包括車輛基本信息的錄入、修改、刪除等操作。
①車輛信息錄入：實現將車輛基本信息寫入數據庫表中，點擊“添加”按 鈕，系統彈出信息錄入的對話框，根據其提示的步驟完成車輛基本信息的錄入；
②車輛信息修改：實現對某輛車或某些車的基本信息進行修改，選中列表 中的某輛車的信息欄，點擊“編輯”按鈕，可以在對話框中對其信息進行修改或 完善，若在列表中選中多輛車，可以同時修改這些車輛的共同信息項。
③車輛信息刪除：實現將某輛車或某些車的基本信息從數據庫的表中刪除， 選中列表中的某輛車或某些車的信息欄，點擊“刪除”按鈕，系統會在再次確認 后將選中車輛的信息從數據庫中刪除。
④車輛信息查詢：在以列表形式顯示車輛基本信息的基礎上，實現通過車 牌號碼、車輛型號、使用年限、車輛狀況等條件進行查詢，支持自定義查詢功能。 點擊“查詢”按鈕，系統會給出查詢條件的勾選框及自定義欄，并在查詢結果欄 按設定條件顯示查詢結果。
(2)其他信息編輯 員工信息、路徑節點信息、用車記錄信息等的展示與管理方式與上述車輛信 息管理類似，不再贅述。
4.4.4可視化模塊
可視化模塊主要是對各類信息進行展示，如景區的人流信息、車輛實時載客 信息、監控信息等進行可視化展示，為后續郡安里景區的信息化、智能化管理做 鋪墊。在實現過程中可采用Echarts數據可視化圖標庫實現可視化功能，Echarts 以圖表形式生動、直觀的展示數據，也可根據個性化需求定制圖表樣式，滿足不 同的開發需求。
4.4.5最短路徑規劃模塊
根據郡安里景區自定義導航的需要，基于郡安里景區導航節點點表和線表數 據，采用最短路徑算法計算得到具體的行駛路徑。常見的最短路徑算法有Dijkstra 算法，Floyd算法，SPFA算法等(Chen et al.，2018)。本文采用Dijkstra算法計 算兩點間的最短路徑，根據游客的叫車信息，確定游客的起點點號，從起點出發， 根據導航節點線表的連接關系，搜索出全部可到達終點的路線集合，對比所有路 線的距離，輸出最短路徑的完整節點信息， Dijkstra 算法流程圖如圖 4-6 所示。 微信小程序和車載 APP 依據此節點信息在地圖中繪制最短路徑，進而完成自定 義導航功能。
Dijkstra 算法的計算過程為：
步驟1：根據輸入的起點和終點，生成集合Close=｛S｝，集合OPEN=｛其余 點｝,集合Close和OPEN互補；
步驟2：從集合OPEN中選取一個距離S最小的頂點K （該距離就是S到K 的最短路徑），把K加入到集合Close中，記錄節點S為節點K的父節點；
步驟3：以K為新考慮的中間點，修改OPEN集合中各頂點的距離； 步驟4：重復步驟2和步驟3直到所有頂點都包含在集合Close中； 步驟 5：根據終點的父節點反向進行迭代，輸出最短路徑。
4.5車載APP設計
車載 APP 主要實現接送游客的功能，以及與綜合信息管理平臺之間的信息 交互功能，包括賬號模塊、地圖模塊、接送模塊、剩余座位數控制模塊、其他模 塊、高程剖面圖模塊等六個模塊，其功能模塊劃分如圖4-7所示，車載APP原理 如圖 4-8 所示。
4.5.1Android 平臺
車載APP基于Android Studio 3.6.2開發，使用JAVA語言，車載APP開發 選擇 MVP (Model-View-Presenter)框架(郭佳寧，2016)。Model 數據處理層, 主要負責網絡請求，數據存取等操作；View展示層，直接與用戶交互；Presenter
邏輯層，各項功能的具體實現層。MVP框架是在MVC的基礎上形成的適合 Android 開發的框架，與 MVC 最大的區別在于 Activity 所屬位置不同，前者屬 于 View 層，后者屬于 Controller 層；其次 View 和 Model 是不能直接通訊的，因 此增加了 P層的負擔。MVP框架三者之間關系如圖4-9所示。
現在市場上絕大部分手機是Android操作系統。Android系統為開發者提供 了四大組件：Activity、BroadcastReceiver、Service> ContentProvider，使得基于 Android 系統的開發具有堅實的技術保證。對于每一個 Android 應用來說至少需 要一個Activity,完成與用戶的信息交互。在Android6.0之后，Google將權限分 為兩類：普通權限和危險權限。危險權限在使用時需要判斷用戶是否對該權限授 權，如果沒有授權，需要動態申請，在沒有用戶授權的情況下，無法使用該功能， 如位置權限、打開相機權限等。
4.5.2賬號模塊
賬戶模塊主要包括司機登錄和密碼修改功能。
(1)司機登錄
司機啟動 APP 后，在啟動頁面輸入賬戶和密碼，并提交給服務器驗證。因 車載APP只提供給郡安里景區駕駛員使用，使用人群固定，故在車載APP中不 開放賬戶注冊功能，司機登錄所需要的賬戶通過綜合信息管理平臺的駕駛員管理 模塊進行錄入和編輯。用戶首次登錄采用默認密碼登錄，登錄成功后，可修改密 碼。
( 2)密碼修改 用戶登錄后，通過選擇“修改密碼”按鈕，可進入密碼修改頁面，輸入原密 碼進行驗證身份，兩次輸入新密碼一致后，則成功修改登錄密碼。
4.5.3地圖模塊
因天地圖 Android 端的 API 沒有疊加方法，且項目時間緊迫，故車載 APP 的地理底圖采用百度地圖。地圖模塊為車載 APP 的主界面模塊，地圖模塊主要 包括地圖顯示、定位導航、影像疊加等功能。
（1） 地圖顯示 使用百度地圖為地理底圖，顯示郡安里景區范圍內的地圖，并可通過在屏幕
上點擊拖拽，實現地圖的漫游和縮放操作。
（2） 影像疊加 在百度地圖地理底圖上直接以圖片形式疊加郡安里景區規劃效果圖，以便使
用者更加清晰明了地獲取到想要的信息。
（3）定位與導航
基于百度地圖 API 顯示車輛當前位置。通過在地圖主界面上點擊“定位”圖 標，系統快速定位到用戶當前所在位置。結合游客位置和車輛位置，顯示服務器 規劃的路徑，完成導航功能。
4.5.4接送模塊
接送模塊是車載 APP 的核心模塊，主要實現游客接送功能，完成與當前登 錄用戶相關的信息通訊，如用車信息、反饋信息等，該模塊主要包括信息接收、 信息上傳等功能。
（1） 信息接收 接收來自綜合信息管理平臺推送的游客叫車信息，通過提示音和震動提醒司
機有叫車信息，并在頁面以彈窗的形式顯示游客起始點、目的地、所需座位數信 息。確認接單后接收最短路徑信息，導航司機去接送游客。整個接送流程分為應 答確認、接客確認、游客到達三部分。
（2） 信息上傳 信息上傳主要是根據推送的信息以及實際情況，把叫車信息的反饋信息、車
輛位置信息、異常信息等內容發送給服務器，綜合信息管理系統更新對應數據庫 信息。
4.5.5剩余座位數管理模塊
在整個系統中，車輛的剩余座位數是系統進行車輛調度的關鍵，系統需要隨 時準確地了解到當前車輛剩余座位數，所以賦予司機最高的權限，可隨時對信息 進行更正操作。該模塊主要實現顯示車輛總座位數和剩余座位數，修改當前剩余
座位數，并上傳給綜合信息管理系統。
4.5.6其他模塊
其他模塊主要是指異常上報和信息提示兩部分。
（1）異常上報
車輛在運行過程中，可以根據實際情況上傳異常內容，可以選擇預設的異常 內容，也可手動描述異常信息，完成對郡安里景區信息的實時掌控。
（2）信息提示
信息提示是指司機在當前 APP 中可以查看當前車輛編號、賬戶名、相關提 示信息等基礎信息。
4.5.7高程剖面圖模塊
目前越來越多的人（不僅僅針對景區游客）在出行過程中想要了解到所到目 的地及沿線的高程、與當前位置的高差，即所經線路的地形起伏情況。現有的市 面流行的軟件中，沒有集成該功能的設計，需要打開其他軟件查詢指定位置的高 程信息。另外人們有在出行時想要了解到該路段的長度和坡度，進而選擇不同的 出行方式的需求，但是沒有專門的軟件給出此等意見和建議。
針對以上人們的需求，設計有關線路高程可視化顯示功能，作為拓展功能在 車載 APP 內實現。在規劃出車輛路徑之后，在軟件中顯示出該路段中的高程剖 面圖，進一步分析得到該路徑中的坡度變化信息，結合路徑長度和坡度大小，給 出不同的出行方式的參考建議。
結合生活經驗、問卷調查結果和公路自行車爬坡點坡度（雨辰， 2018）綜合 考慮，當路徑長度小于等于1km，給出步行建議；路徑長度小于等于4km,且路 徑坡度小于等于 8%時，給出騎行建議；其他情況下建議駕車出行。出行建議分 類見表 4-15。
表 4-15 出行建議分類表
路徑長度 路徑坡度 出行建議
W 1km 無要求 步行
W 4km W 8% 騎行
> 1km > 8% 駕車
4.6微信小程序設計
微信小程序主要提供給游客使用，主要包括掃碼登錄、地圖模塊、叫車模塊、 評價模塊等四個模塊，如圖4-10所示，微信小程序原理如圖4-11所示。
圖 4-10 微信小程序功能模塊圖
圖 4-11 微信小程序原理圖
4.6.1微信小程序開發工具
微信小程序采用微信小程序開發工具實現，使用JavaScript腳本語言，簡稱 JS。JS的誕生增加了 HTML頁面的交互性，JS本身是一種輕量級的高級編程語 言，被世界上大多數主流瀏覽器所支持（劉軍， 2009），如谷歌瀏覽器、百度瀏 覽器等。隨著新的語言標準的出現，JS在游戲、移動、桌面等應用程序的開發也 有應用（李沖等， 2011）。隨著微信的廣泛使用，微信小程序功能也越來越多的 受到人們的關注與使用，與 APP 相比，微信小程序不需要下載應用程序便可直 接使用，非常地方便快捷。
4.6.2掃碼登錄
掃碼登錄主要針對游客在首次接觸郡安里景區的時候，需要使用線上叫車功 能時， 可在景區入口或酒店通過微信掃描二維碼打開微信小程序，從而享受郡安 里景區提供的優質代步服務。在后續的使用中，每次可以掃碼登錄，也可直接調 出微信小程序功能找到“郡安里便捷叫車服務”小程序使用線上叫車功能。
4.6.3地圖模塊
微信小程序調用天地圖作為地理底圖，并在底圖上疊加郡安里景區的 DOM。 小程序疊加地圖時是使用 Web 端 API 能夠直接以圖片形式疊加地圖。地圖模塊 功能與車載 APP 中的地圖模塊功能類似，能夠完成地圖的平移，縮放和旋轉功 能，顯示游客自身的定位及其相關的車輛信息等，地圖中設置興趣點，點擊興趣 點圖標，可以查看該點的相關信息，使用戶能直觀了解其自身所處的空間方位， 幫助其獲得更好的服務和體驗。
4.6.4叫車模塊
該功能模塊是微信小程序的核心模塊，主要為用戶提供叫車服務入口和叫車 成功后的提示信息顯示。當游客打開小程序后，通過輸入上車地點、下車地點、 電話號碼等信息后，點擊“叫車服務”，系統自動為用戶調度合理車輛。叫車成 功后，地圖上顯示車輛位置和路徑，并且顯示車輛編號、司機姓名和手機號、距 離和預計時間等信息，幫助游客時間掌握接送狀態。
4.6.5評價模塊
游客到達目的地后，可以對本次的用車服務進行評級，最高五星。其次游客 可以選擇評價語句，如 “服務態度好”、“駕車技術好”等，也可以自行輸入評 價語句。通過該功能實現管理方對景區服務質量的把控，尋找優秀駕駛員，進而 實現景區人員的高效管理。
4.7本章小結
本章介紹了綜合信息管理系統開發中需要用到的相關技術，給出了系統總體 建設方案，選定了開發平臺，根據線上叫車功能中存在的實體，詳細設計了數據 庫表，按照功能模塊詳細設計了綜合信息管理平臺、車載 APP 和微信小程序的 多項功能。綜合信息管理平臺供管理方使用，車載 APP 提供給景區司機使用， 微信小程序則面向所有郡安里景區游客。此外針對人們對高程信息和獲取出行建 議的需求，創新地設計了高程剖面圖功能，以圖表的形式展示路線高程信息，根 據路線長度和坡度給出出行方式建議。
第5 章 綜合信息管理系統實現
莫干山郡安里景區綜合信息管理系統分為三部分：綜合信息管理平臺、車載 APP 和微信小程序。從項目需求分析到系統設計直至系統實現，作者合作完成了 綜合信息管理系統和微信小程序，獨立開發了車載 APP。
5.1綜合信息管理平臺
5.1.1登錄模塊
登錄界面主要完成綜合信息管理平臺的登錄功能，頁面設計如圖 5-1 所示。
登錄時通過 POST 請求提交用戶名和密碼，驗證后進入綜合信息系統界面，可進 行相關數據的查看和管理。
圖 5-1 綜合信息管理平臺登錄界面
5.1.2信息管理模塊
該功能模塊主要對系統數據庫中的各類數據進行管理，如路徑節點數據、車 輛信息數據、車輛行駛記錄數據等。以員工信息數據為例，在此頁面中分別點擊 圖中的“添加員工”、“刪除”、“編輯”和“搜索”按鈕，即可進行相關操作，如 圖 5-2 所示。
點擊“添加員工”可以添加新員工信息，添加員工信息界面如圖 5-3 所示， 輸入員工姓名、編號、聯系電話、入職時間、類型后，點擊“新增”即可完成新 員工信息錄入。
Arnaus*
S.ZS-5
聯親電詩 人耳葉間 貝二兵旦
圖 5-3 添加員工信息示意圖
點擊“刪除”按鈕可以刪除員工信息，彈出提示信息“確認刪除此員工”， 以防止刪除錯誤。不僅如此，系統還提供了批量導入功能和批量刪除功能。批量 導入以 Excel 表格形式導入。執行批量刪除操作時，單擊勾選圖 5-2 中“員工編 碼”前面的方框即可，然后點擊批量刪除，根據提示信息操作即可正確刪除。
點擊“編輯”按鈕可以進行員工信息修改，彈出員工信息編輯界面，界面和 操作都與圖 5-3 類似，修改指定數據即可。
點擊“搜索”按鈕可以根據條件查詢指定信息。
5.1.3最短路徑規劃
系統中最短路徑采用 Dijkstra 算法。 Dijkstra 算法是一種被廣泛應用的最優 路徑搜索算法，作為最為著名的路徑搜索算法之一，它不僅被應用在了各類最短 路徑求解上，在通信領域的路由問題求解上也被大規模的加以應用。不同于別的 算法搜索到終點就停止搜索，基于貪婪的搜索思想，計算過程中Dijkstra算法會 將點網系統圖中所有的頂點都一一納入搜索過程中，直到待搜索集合變為空集時 算法的搜索過程才會停止。因此， Dijkstra 算法的優點是不管在什么情況下，總 能夠準確地求解得出最短路徑。
基于郡安里景區導航節點點表和線表，系統結合車輛位置和游客位置規劃出 最短路徑。從起點出發，根據線表連接關系依次搜索出所有可以到達的下一個節 點，并對路徑長度進行累加，在所有可以到達終點的路徑中，找出最短路徑長度， 輸出對應的路徑節點信息。
5.1.4可視化模塊
可視化模塊主要以圖表的形式，可視化展示當前系統中的設備狀態，如圖 5 4 所示。綜合信息管理平臺完成對景區內信息的可視化管理和動態管理。中間部 分是在天地圖地理底圖上疊加遙感影像和導航節點線。四周包括景區人流量、當 日累計叫車次數、監控視頻、車輛實時載客等情況。從此界面中管理者可以輕松 掌控景區的整體運行狀況。
由于郡安里景區人流量統計設備、監控視頻設備等建設不完善，此部分功能 尚未正式投入使用，所有數據均為模擬數據。
5.1.5通訊機制
通訊是整個系統的必不可少的部分，綜合信息管理系統的運行，離不開信息 通訊。不僅要將游客的叫車信息完整的發送給指定車輛，也要將指定車輛的反饋 信息完整的發送給對應的游客。在通訊前需明確通訊內容，規定通訊格式，這樣 能使各端明確信息內容，解析時有理可依，保障系統高效穩定地工作。系統中所 有的通訊信息均轉換為 JSON 的形式，不同通訊信息的區分主要靠唯一的叫車 ID。服務器總共給車載APP發送兩類信息，具體內容見表5-1；總共給小程序發 送五類信息，具體內容見表5-2。
表 5-1 服務器發送給車載 APP 的兩類信息
叫車 內容 乘車點經度；乘車點緯度；所需座位數；乘車點名稱；手機號；游客 姓名；叫車ID；目的地名稱；目的地經度；目的地緯度
信息 實例 119.***349;30.***266;3;面館；184***089;張三；e962d4c1-935e-44f8-
8d0f-f17f5e506b53;云頂餐廳;119.***361;30.***585
路徑 內容 叫車ID；最短路徑節點號*總距離*
信息 實例 b877d1cc-eeab-4242-9d93-70d1caf7e5d1;
838,839,840,...,1090,1089,*1641*
表 5-2 服務器發送給微信小程序的五類信息
YES 信息 內容 YES；車輛代碼；司機姓名；司機電話號碼；司機編號；司機位置經 度，緯度；最短路徑節點號；*總距離*
實例 YES;20;張*;176*****;丁“卩008;119.***162,30.***467;
838,839,840,..., 1091,1090,1089;*1641*
POS 信息 內容 POS；叫車ID；司機位置經度，緯度；上傳時間；司機姓名；司機手 機號；乘車點經度；乘車點緯度；目的地經度；目的地緯度
實例 POS;e66a177a-81db-4d02-a7d3-253f30e;119.***292,30.***214;
2020/10/18 20:57:42;張*;176*****;119.***066;30.***003; 119.***275;30.***965
STAND
BY信息 內容 STANDBY；車輛代碼；上傳時間；司機姓名；司機手機號；司機經 度；司機緯度；目的地經度；目的地緯度
實例 STANDBY;20;2020/10/16 18:6:45;張*;176*****;119.***456;
30.***203;119.***275;30.***965
BOARD
信息 內容 BOARD；車輛代碼；司機姓名；司機電話；叫車ID；最短路徑節點 號；*總距離*
實例 BOARD;20;張*;176******£0692匕力血5。8-4匕80乜。3匸6山643966468;
1089,1088,1087,1086,1085,1084,*58*
ARRIV
ED 信息 內容 ARRIVED；叫車 ID
實例 ARRIVED;fab10c43-5d2c-4540-a3ee-5ef13de34875
表 5-1 中第一條信息是服務器向車載 APP 發送的游客叫車詳細信息，后文 中稱叫車信息。當司機同意接送游客后，服務器向車載 APP 發送表中第二條信 息，包括規劃路線節點信息和總距離，后文中稱路徑信息。
表5-2為叫車成功之后，服務器發送給微信小程序端的五類反饋信息的內容 與實例。根據信息的開頭字符，在后文中分別稱為YES信息、POS信息、STAND 信息、BOARDBY信息、ARRIVED信息。
5.2車載APP
5.2.1通訊內容
在5.1.5中明確了由后臺服務器發送給車載APP的信息，車輛在收到信息之 后，需要做出相應的回應，比如是否去接送游客等。在接收服務器信息之前，車 輛還需要告訴服務器，當前可以接送游客以及車輛所在位置等信息，只有服務器 接收到此類信息后，服務器才能區分車輛，完成調度任務。車輛與服務器通訊內 容分類見表 5-3。
表 5-3 車輛與服務器通訊內容分類一覽表
編號 字段 狀態
1 CARSTART 司機登錄
2 CARLEAVE 司機離開
3 CARPOS 車輛行駛位置檢測
4 CARCALLBACK 叫車應答
5 CAREVENT 異常上報
6 CARBOARD 游客上車
7 CARARRIVED 抵達目的地
8 CARSTANDBY 車輛到達接送游客位置等待
9 CARVALIDATESEA 司機直接修改座位數
表 5-3為此管理系統中車載 APP 發給后臺服務器的九條信息類型，根據每 條信息表示的狀態，在后文中簡稱為登錄信息、離開信息、位置信息、應答信息、 異常信息、上車信息、下車信息、等待信息、座位信息，表5-4為通訊的具體內 容，全部以字符串類型進行拼接，中間由分號隔開。每一行中上為數據類型說明， 下為具體的數據內容實例。
表 5-4 車輛與服務器通訊內容字段名與實例表
登錄
信息 內容 Message+1#車輛代碼；駕駛員代碼；車輛位置；車輛位置經度；車輛位 置緯度；上傳時間
實例 Message+1 #21;TMP008;停車場；119.***268;30.***427;2020/10/02
10:41:23
離開
信息 內容 Message+2#車輛代碼；駕駛員代碼；車輛位置；車輛位置經度；車輛位 置緯度；上傳時間
實例 Message+2#21; TMP008;停車場；119.***728;30.***427;0;2020/10/04
17:41:43
位置
信息 內容 Message+3#車輛代碼；車輛經度；車輛緯度；上傳時間
實例 Message+3 #21;119.97728;30.5427;2020/10/03 17:41:23
應答
信息 內容 Message+4#車輛代碼；叫車ID；上傳時間；反饋信息（True為確認接送，
False為無法接送）
實例 Message+4# 21;a1bc2583-7950-499d-9f6f-69af807faa11;2020/10/05
18:11:23;True
異常
信息 內容 Message+5#車輛代碼；駕駛員代碼；車輛位置；車輛位置經度；車輛位 置緯度；異常內容；上傳時間
實例 Message+5 #21;PHY09;面館;119.***455;30.***511;輪胎爆胎;2020/10/05
16:11:23
上車
信息 內容 Message+6#車輛代碼；叫車ID；上傳時間；反饋信息
實例 Message+6 #21;be5d7e29-0e5c-4c59-91e6-42b1c9264253;2020/10/3
18:01:1;Board
下車
信息 內容 Message+7#車輛代碼；叫車ID；上傳時間；反饋信息
實例 Message+7 #21;be5d7e29-0e5c-4c59-91e6-42b1c9264253;2020/10/3
11:35:18;Arrived
等待
信息 內容 Message+8#車輛代碼；叫車ID；到達時間
實例 Message+8 #21;be5d7e29-0e5c-4c59-91e6-42b1c9264253;2020/10/3 11:25:8
座位
信息 內容 Message+9#車輛代碼；剩余座位數
實例 Message+9 #21;2
5.2.2賬號模塊
5.2.2.1登錄驗證
在使用車載 APP 之前，需要對讀寫權限和位置權限進行動態授權，如圖 5 5 所示，同意后進入車載 APP 登錄界面，如圖 5-6 所示。車載 APP 為郡安里景 區專屬，不提供注冊接口，賬戶密碼由管理人員生成后直接分發給司機，登錄成 功后可修改密碼。
登錄時需要輸入司機的賬戶和密碼，選擇當前車輛的車牌號信息，三者中有 空值時，屏幕下方彈出提示語句“輸入不能為空”。全部輸入完成后，根據返回 的狀態碼和返回的JSON字符串，判斷賬戶和密碼是否正確。登錄失敗時提示“賬 戶密碼錯誤，請重新輸入”。成功后自動跳轉到APP主界面，如圖5-7 (a)所示， 加載地圖等信息，準備接收游客的叫車信息。選中圖 5-6 中的“記住狀態”，在 本次登錄成功后，下一次直接默認輸入本次內容，直接點擊登錄即可。
5.2.2.2WebSocket 鏈接建立
在登錄成功后，訪問指定WebSocket接口即可進行通信。為了保證建立的通 道是安全的，分三步建立各車輛的專屬通訊通道。
第一步：先發送信息“Hello”表明登錄了，需要建立通信通道；
第二步：發送信息“NickName+Car_15”數字為車牌號(carcode)，表明是 15 號車請求建立專屬通信通道；
第三步：發送登錄信息，“上報”當前車輛位置，表明車輛可以開始服務。 專屬WebSocket通道連接步驟關鍵代碼如下：
WebSocketHandler.getDefault().send("Hello"); // 發送信息“Hello” WebSocketHandler.getDefault().send("NickName+CAR_" + carcode);
LatLng myLocation = ((HomeActivity) mContext).mapviewFragment .getMyLocation(); // 獲取位置信息
//構造登錄信息(參見表5-4)
String s1 = "Message+1#" + carcode + ";" + name + ";"
+ getPlaceName(myLocation) + myLocation.longitude + ";"
+ myLocation.latitude + MyCalendar.getTimeString();
WebSocketHandler.getDefault().send(s1); // 發送登錄信息
5.2.2.3主界面與修改密碼
由圖5-7 (a)可知，主界面從上往下一共分為4個區域。第一部分為導航欄 部分，左邊數字15為當前車輛的車牌號信息，中間為提示信息，右邊為設置按 鈕，點擊之后可以修改訪問的服務器IP和修改密碼。第二部分為剩余座位數控 制器，表明車輛當前剩余座位數數量。第三部分為地圖展示區域，采用 Fragment 控件加載。第四部分為底部導航欄，司機根據提示進行點擊操作。
點擊圖5-7 (a)設置按鈕中的“修改密碼”，來到修改密碼界面，如圖5-7 (b) 所示。當輸入的原密碼正確，兩次輸入的新密碼一致時，點擊“確定”按鈕，會 提示“密碼修改成功”。修改密碼時的提示有三種：輸入不能為空、原密碼輸入 不正確、兩次輸入密碼不一致。
■
座位總數：8個
剩余座位：8個© 8 ®
圖 5-7 車載 APP 主界面和修改密碼界面
5.2.3地圖模塊
車載APP的地理底圖選擇百度地圖。使用百度地圖Android端API，需要在 百度地圖開放平臺中注冊申請，生成與程序相應的百度地圖密鑰，下載需要用到 的地圖jar包，按照官方說明文檔進行相關信息的配置后，可正常調用其功能。 調用的百度地圖作為地理底圖如圖5-7 (a)所示，當前所在位置以小藍點的形式 顯示，在此界面中可以通過手勢對地圖進行平移、旋轉、縮放等操作。
(1)顯示當前位置 當找不到所在位置時，點擊主界面左側中間的“定位圖標”，地圖可以直接
顯示到當前位置。當地圖呈現效果發生旋轉和傾斜后，左上角會出現指北針，點 擊即可恢復地圖為常規顯示模式。
(2)地圖疊加
由于百度地圖在郡安里景區沒有詳細完整的景區地圖，建筑物信息缺失嚴重， 不能滿足景區的需求，為此在百度地圖基礎上進行地圖疊加。考慮到地形圖對用 戶來說，不夠直觀，用戶需要更加直接地獲取到想要的信息，故采用直觀化平民 化的郡安里景區規劃效果圖進行地圖疊加，疊加效果如圖5-7 (a)所示。地圖疊 加關鍵代碼如下：
LatLng southwest = new LatLng(30.***352,119.***028); // 西南角坐標
LatLng northeast = new LatLng(30.***019, 119.***889); // 東北角坐標
LatLngBounds bounds = new LatLngBounds.Builder().include(southwest) .include(northeast).build(); // 構造圖片邊界信息
BitmapDescriptor bdGround = BitmapDescriptorFactory .fromResource(R.drawable.jal_final); // 獲取疊加的圖片對象
//轉換為百度地圖疊加對象，并設置透明度
OverlayOptions ooGrround = new GroundOverlayOptions() .positionFromBounds(bounds).image(bdGroundl) .transparency( 1f);
mBaiduMap.addOverlay(ooGrround); // 顯示地圖疊加內容
( 3)位置上報 車輛在運行中，每隔10秒需要向服務器“上報”自己當前位置，即向服務 器發送位置信息。系統統一采用的坐標系為CGCS2000,而百度坐標采用BD09LL 坐標系，因此需要將百度坐標轉換到 CGCS2000 系下。
在車載APP中建立坐標轉換工具TransformUtils，將定位得到的百度坐標轉 換到 CGCS2000 坐標系下，進一步將轉換后的坐標與郡安里景區導航節點點表 做比較，取出距離最小的點作為當前車輛的位置“上報”給服務器。這樣能夠保 證服務器在最短路徑規劃時，每次都能從點表的數組中取到正確的索引值。
5.2.4接送模塊
接客送客功能分為三部分：應答確認、接客確認、游客到達。三部分都由對 話框展示必要信息，提示司機有內容需要進行操作。
5.2.4.1應答確認
當客戶向服務器發布叫車信息后，服務器通過專屬的WebSocket通道，將叫 車信息推送給指定車載APP,收到信息后APP將發出震動和聲音，提示司機有 游客需要接送。主界面中彈窗顯示乘客位置、目的地、所需座位數等信息，如圖 5-8 (a)所示，底部應答確認處的數字表示收到一條叫車信息。點擊“取消”按 鈕，將需求信息返還給服務器，服務器重新派遣接送車輛；點擊“確定”按鈕， 向服務器發送應答信息，表示愿意去接送該游客，彈窗消失，地圖上繪制規劃路 徑，如圖5-8 (b)所示。(b)與(a)相比，剩余座位數減少了 3個，底部的應 答確認處數字提示消失，接客確認處數字提示為 1。
圖 5-8 應答確認和規劃路徑圖
路徑繪制關鍵代碼如下：
//繪制路徑
// path為傳入的路徑信息(參見表5-1)
public void drawLine(String path){ //根據傳入的路徑信息繪制路線 List<LatLng> listPathExample = new ArrayList<>();
String]] split = path.split(","); 〃用逗號拆分字符串，得到節點點號數組 for (int i = 0; i < split.length - 1; i++){ // 遍歷數組
int index = Integer.parselnt(split[i]); // 將點號轉換為 int 類型 //得到各點號對應的百度坐標 listPathExample.add(PointList.listBD.get(index - 1));
}
//構造折線疊加對象，指定線寬、顏色、對象集合
OverlayOptions onPolyline_str = new PolylineOptions().width(10)
.color(OxAAFFOOOO).points(listPathExample);
mBaiduMap.addOverlay(onPolyline_str); // 顯示繪制折線
當觸發遺傳算法調度車輛時，車載 APP 通常會同時收到多個信息，在第 3 章計算結果中，車輛2使用的車載APP接收到的信息如圖5-9所示，(a)為收到 調度指令時的信息提示，(b)為應答后顯示從車輛位置到所有乘客起點的路徑。
圖 5-9 車輛 2 收到的車輛調度信息
如果接到叫車信息時， APP 處于后臺，在頂部的通知欄還會有信息通知，如 圖5-10所示。此時點擊通知欄部分可直接進入車載APP。
為防止司機長時間不接單，造成游客叫不到車，本系統設計為：如果司機 40 秒內沒有操作，則自動為司機拒絕該任務，給服務器發送應答信息，反饋信息的 內容為 false。
5.2.4.2接客確認
司機到達游客的起點后，點擊接客確認區域，頂部提示信息變為“接客確認”， 彈出提示框如圖5-11 (a)所示。如果此時游客正好在上車地點，司機確認游客 信息后，點擊“確認”按鈕，向服務器發送上車信息，表示乘客已經上車。此時 彈窗消失，底部接客確認處數字提示消失，游客到達處的數字提示變為1。
在圖5-11 (a)中司機也可點擊“到達”按鈕，向服務器發送等待信息，表 示司機已經到達起始位置。與此同時“到達”按鈕消失，微信小程序端更新顯示 信息，提示游客司機已到達出發位置。司機還可點擊圖中的電話號碼，直接跳轉 到撥號界面給游客撥打電話。
圖 5-11 接客確認和游客到達
接客確認彈窗關鍵代碼如下：
//聲明一個彈窗對象
AlertDialog.Builder builder = new AlertDialog.Builder(context);
View received_view = LayoutInflater.from(context)
.inflate(R.layout.dialog_received, null); // 彈窗布局
builder.setView(received_view); // 應用布局
initView(received_view); //找到布局中的各控件
setDisplay(); //填寫彈窗的具體展示內容
//注冊自定義點擊事件
MyOnClickListener myOnClickListener = new MyOnClickListener(context, replyList, caller, mapviewFragment, receivedList);
received_phone.setOnClickListener(myOnClickListener); // 電話號碼點擊事件 cancel.setOnClickListener(myOnClickListener); // 取消按鈕點擊事件 ok.setOnClickListener(myOnClickListener); // 確定按鈕點擊事件 received_ready.setOnClickListener(myOnClickListener); // 到達按鈕點擊事件 dialog = builder.show(); // 展示彈窗
5.2.4.3游客到達
當游客到達目的地時，點擊底部游客到達區域，頂部提示信息變為“游客到 達”，彈出對話框如圖5-11 (b)所示。里面包括游客姓名，目的地，占座位數等 信息。此時也可以修改游客的占座位數，修改后座位控制器中數字出現對應變化。 點擊“下車”按鈕，向后臺發送下車信息，表示游客已下車，接客送客功能完成。 同時底部游客到達處數字提示減一，上方剩余座位數自動加上下車人數。點擊“全 部下車”按鈕，表示所有游客已下車，底部數字提示消失，剩余座位數恢復到最 大座位數。
5.2.5剩余座位數控制模塊
主界面的上方為剩余座位控制模塊，包括最大座位數和剩余座位數兩部分。 最大座位數為固定值，與車牌號相對應，司機沒有修改權限。剩余座位數顯示當 前車輛剩余的座位數，根據訂單情況進行自動加減。剩余座位數是后臺判斷座位 數是否滿足客戶需求的唯一標準。為保障數據和調度的準確性，賦予司機最高權 限，可隨時更改當前的剩余座位數，修改后發送座位信息給服務器更新當前車輛 剩余座位數。修改剩余座位數時，數字底色會改變，點擊底色覆蓋區域，將當前 剩余座位數發送給后臺，底色消失。
5.2.6其他模塊
5.2.6.1 異常上報模塊
其他模塊包括修改異常上報模塊和信息提示模塊。當車輛發生事故時，可以 通過 APP 將異常信息迅速地發送給服務器，由管理平臺處理異常信息，點擊圖 5-12 (a)中的“異常上報”，進入異常上報界面，在其中可以選擇預設的異常信 息，或者手動輸入異常信息，如圖5-12 (b)所示。
賬號:TMP003 車牌號：15
我的狀態：離開
斷開
重連
異常上報
提示音 4》 震動 ©
\ f.I a I I i Resort /
(a)設置界面
圖 5-12 設置界面和異常上報界面
5.2.6.2信息提示
設置界面如圖5-12 (a)所示，在此頁面中，圓圈表示當前登錄的車牌號， 下方提示信息表明當前身份。“我的狀態”分為兩部分：在線和離開，點擊兩個 標簽會有彈窗提示，如圖 5-13 所示，點擊“確認”后分別發送登錄信息和離開 信息給服務器。在線狀態時，接收所有信息，隨時準備服務。離線狀態時，表示 當前有事離開，不接收信息。
圖 5-13 “我的狀態”標簽的提示語
下方的“斷開”和“重連”，是指斷開和重連WebSocket。在景區內車輛運行 時，有可能會出現Web Socket自動重連失敗的情況，此時需要司機先手動點擊斷 開，再點擊重連，重連成功后會彈出提示“可以通訊”，此時與服務器恢復鏈接。
點擊提示音和震動文字后面的圖標，可以控制接收到叫車信息時，手機是否 發出提示音和震動。使用該功能的前提是，手機允許車載 APP 進行信息通知。
5.2.7高程剖面圖模塊
此部分功能不針對景區的線上叫車，而是一個擴展功能，滿足人們（不僅 僅是游客）對高程信息和出行建議的需求。在路徑規劃完成后，點擊底部上拉 框，可以看到此條路徑的高程剖面圖，如圖 5-14 所示。
標題下方的藍色提示語句告訴游客路徑總長度和坡度大小情況，以及給出整 體的出行方式建議。其次游客可以選擇路徑上的某點，選擇后有提示框語句，如 圖 5-15 所示。提示框分為兩部分，上方為此點的高程信息，單位為米，下方為 結合此處的坡度信息給出的出行建議。由圖5-15 (a)可知左邊坡度較緩，所以 給出局部出行方式建議為“步行、騎行”，字體為藍色；由圖5-15 (b)可知右邊 坡度較陡，所以給出局部出行方式建議“駕車”，字體為紅色。
圖 5-15 局部高程信息和出行方式建議圖
高程剖面圖繪制關鍵代碼如下：
//新建曲線對象，設置基礎數據和名稱
lineDataSet = new LineDataSet(entries,"高程剖面圖”)；
setLine(); 〃對lineDataSet操作，設置線的顏色、寬度等信息 LineData lineData = new LineData(lineDataSet); // 構造 LineData 對象 //實例化MyMarker。查看圖像上點顯示內容布局
MyMarker myMarKer = new MyMarker(this,R.layout.marker test);
// 確保查看信息始終保持在圖形區域
// 不繪制圖例
// 給 LineChat 設置 marker
//給LineChat設置曲線數據
// 設置整個圖形上下左右的邊距
// X 軸相關設置
// Y軸相關設置
5.3微信小程序
5.3.1通訊內容
微信小程序為叫車服務的發起點，游客通過掃二維碼或搜索微信小程序“郡 安里便捷叫車服務”便可享受交通出行服務。
微信小程序發給服務器的內容有兩類，具體見表5-5。一是填寫姓名、手機 號、所需座位數等必要信息后，向服務器發送表5-5中的叫車信息。二是當游客 到達目的地后，司機確認游客下車后，小程序端跳出評價窗口，評價后發送表5- 5 中的第二條數據，后文稱評價信息。
表 5-5 微信小程序發給服務器的兩類信息匯總表
叫車 內容 Message+1#4；乘車點經度；乘車點緯度；所需座位數；乘車點名稱；手機 號；游客姓名；叫車時間；目的地經度；目的地緯度；目的地名稱
信息 實例 Message+l#4;119.***349;30.***266;3;面館;184*****;張三；2020/10/2
18:36:11;119.***361;30.***585;云頂餐廳
評價 內容 Message+2#游客姓名；叫車ID；反饋信息；上傳時間
信息 實例 Message+2#張三;albc2583-7950-499d-9f6f-69af807faall;本次服務很好，點 贊;2020/10/2 17:29:13
5.3.2地圖模塊
微信小程序的地理底圖采用天地圖，使用天地圖Web端API，直接以圖片 的形式疊加郡安里景區DOM。進入小程序后主界面如圖5-16所示，中間為地圖 展示區域，可以通過手勢對地圖進行移動、縮放等操作。在地圖上添加有預設的 興趣點（圖中紅色定位圖標），點擊后還會彈出信息框，包含該景點的信息，如 圖 5-17 所示。
圖 5-16 微信小程序主界面
圖 5-17 真美味興趣點提示信息
5.3.3叫車模塊
5.3.3.1 叫車服務
例如，點擊圖 5-16 中“馬場”處，選擇乘車站點，點擊“停車場”位置，選 擇下車站點，如圖5-18 (a)所示，該界面默認為游客展示公共區域熱門站點， 游客單擊即完成了選擇操作并跳轉回上一頁面，同時該頁面還隱藏了很多使用頻 率較低的站點，游客可以通過搜索操作完成站點選擇，如圖5-18 (b)所示，同 時也在一定程度上保護了旅游區內部住戶的隱私。
(a)默認站點
Q郡安里叫車服務
搜索：|5
3 幢 105
5 幢 101
5 幢 102
5 幢 103
5 幢 104
5 幢 105
7幢 105
8幢 105
9幢 105
12幢 105
13幢 105
14幢 105
15幢 101
(b)隱藏站點
圖 5-18 站點選擇界面
在游客選擇乘車與下車站點完畢后，點擊“確定”按鈕，首先進行WebSocket 預連接，向服務器發出連接請求，用于服務器判斷此時即將使用叫車功能的用戶 數量。其次頁面跳轉至游客信息填寫界面，小程序會將信息緩存在本地機器，游 客將全部信息填寫完畢后一并提交，游客信息填寫界面如圖 5-20 所示。在游客 填寫信息前會顯示圖 5-19 的彈窗，進行權限申請，獲取游客的位置信息作為游 客信息的一部分一并發送給后臺。在此界面會顯示游客在上一界面填寫過的乘車 點與下車點供游客確認，無需重新填寫，同時需要補充乘車人數、手機號碼、房 間號、姓名以及是否攜帶拉桿箱或其他大型行李。其中乘車人數與手機號碼是必 填項，用紅色星號標記，因為乘車人數信息是用來篩選數據庫中車輛隊列的指標， 而手機號也是司機與游客聯系的主要方式，其他內容為選填。
衽£郡安里陲捷叫車服務申請
獲取你的位置信息
你的位置信息將用于小程序位置接口
拒絕
允許
圖 5-19 權限獲取
圖 5-20 叫車信息填寫界面
游客勾選“攜帶拉桿箱或其他大型行李”后，發送給服務器的叫車信息中乘 車人數自動加1。由于旅游區內有很多游客會攜帶行李，且在填寫乘車人數時常 忽略行李會占座位的情況，因此該選項能夠有效避免預定座位數與實際占座數不 符而導致無法乘車的情況，以上信息填寫完畢后點擊“叫車服務”按鈕。
小程序會先判斷游客填寫的信息是否規范，比如手機號限制為 11 位等。信 息滿足要求后，小程序會在預連接的基礎上建立專屬的 WebSocket 通道，隨之將 游客的叫車信息發送給服務器。之所以在此建立專屬連接而非小程序首頁，是為 了減輕服務器的運載負荷，只有使用叫車服務的游客才會建立WebSocket連接, 而不是掃碼進入小程序就直接連接。司機接收任務后頁面跳轉至車輛信息與導航 頁面如圖 5-21 所示。
5.3.3.2專屬WebSocket通道建立與通信
游客在提交乘車信息時，在預連接的基礎上，微信小程序與服務器建立專屬 的WebSocket通道，WebSocket與微信小程序建立連接流程分為兩步：
（1）小程序：“NickName+VIS」23*******”，數字部分為手機號。
（ 2）服務器：“ Hello”
當服務器回復“Hello”后，該游客的專屬通信通道已經建立，小程序將游客 的叫車信息發送給服務器，此后依次接受到YES信息、POS信息、STANDBY信 息、BOARD信息、ARRIVED信息共五類信息，分別代表訂單進行五個階段：
第一階段： YES 信息。在地圖上顯示調度車輛位置與自己當前位置，并提供 司機的信息，方便游客與司機聯系并可提出個性化需求。
第二階段： POS 信息。在司機到達游客乘車點前，每隔 10 秒就會向游客發 送車輛的實時位置信息，方便游客知曉車輛位置并做好提前準備。
第三階段：STANDBY信息。當司機已到達游客的乘車點時發送，游客看到 此信息即可出門上車，也可與司機先通過電話相互溝通。
第四階段：BOARD信息。表示游客已上車，游客可以清晰的看到自己乘車 與目的地的位置。
第五階段：ARRIVED信息。當游客接收到此信息時，表示司機已將游客送 達目的地，游客界面跳轉至游客評價頁面，游客可以根據實際情況與乘車體驗給 予相應評分并提出自己的意見與建議。
5.3.4評價模塊
在乘車訂單完成后，小程序端自動跳轉至游客評價界面，點擊“提交評價” 向服務發送評價信息，如圖 5-22 所示。
圖 5-22 評價界面
游客的評分很大程度上反應了景區叫車服務的滿意度，評論內容也能反映出 景區服務的不足之處，可從中收納意見汲取經驗，在以后的景區發展規劃問題上 指引方向。
5.4本章小結
本章詳細介紹了綜合信息管理系統各部分開發所采用的開發平臺、語言以及 用到的相關技術。將系統各部分內容按照功能模塊進行了使用介紹，截圖展示了 各功能在實際使用中的狀態，配合文字說明，闡述了軟件的使用流程。詳細介紹 了系統通訊內容。游客通過掃碼或者微信搜索使用小程序進行叫車，服務器通過 叫車請求調度當前可用車輛，并將叫車信息發送給車載APP，司機接收到信息后, 按照服務器的調度安排選擇接送車輛，期間實時反饋車輛位置給游客。通過該系 統實現了游客線上叫車功能，減少了人工參與，提高了景區綜合信息管理質量， 也使游客獲得了更好的旅游體驗。在車載APP中擴展性地實現高程剖面圖功能， 滿足了人們對高程信息和出行方式的需求。
結 論
本文針對莫干山郡安里景區構建綜合信息管理系統擬分步實現對景區的信 息化、智能化管理的需求，完成了系統需求分析和已有資料的收集整理，深入研 究了景區內車輛調度問題，設計并優化了遺傳算法，有效地解決了郡安里景區內 的車輛調度問題，使用B/S開發模式、WebSocket、數據可視化、第三方地圖服 務、數據庫等技術，開發了以車輛調度為核心內容的綜合信息管理系統，實現了 景區內人工叫車模式向線上叫車模式的轉變，使景區各項數據得到了有效管理。 本文主要成果和結論如下：
（1） 利用無人機航測方式生產了景區DOM和DSM，提取了景區內的導航 節點信息，進一步對所有數據進行加工處理，使得圖像疊加更加準確，點位精度 滿足自定義導航要求。
（2） 針對郡安里景區的實際情況，建立相應的車輛調度數學模型，優化了 遺傳算法，創新地設計了只采用起點的自然數編碼，終點則在解碼時結合貪心思 想形成最終路徑。解決了景區內在保證游客服務質量的同時，降低車輛運行成本 的問題，實驗結果表明，改進后的遺傳算法與傳統遺傳算法相比，編碼串長度減 半，搜索范圍減少，計算速度更快，解的質量更高，該方法更能合理有效地解決 郡安里景區內的車輛調度問題。
（3） 針對郡安里景區管理方的要求，設計并實現了以車輛調度為核心的莫 干山郡安里景區綜合信息管理系統，并為系統后續的補充完善提供了可擴展接口。 微信小程序內顯示景區地圖，提供掃碼登錄、線上叫車、反饋信息提示、評價服 務等功能；車載 APP 完成叫車信息接收與處理、地圖顯示規劃路線、繪制高程 剖面圖、以及其他相關設置；綜合信息管理平臺統籌微信小程序和車載APP,使 用WebSocket技術保證系統各項信息及時交互，規劃最短路徑，完成車輛調度， 存儲并管理景區各類數據，可視化顯示景區人流量、車輛載客數等實時信息。綜 合信息管理系統大大降低了人工參與度，方便游客使用的同時提升了景區管理效 率與整體形象。
（4） 不同于其他導航地圖應用而設計了繪制高程剖面圖擴展功能，目前已 在車載 APP 上實現。根據規劃的路徑信息，以圖表的形式展示出路徑的高程剖 面圖，并根據計算的路徑坡度和長度給出出行方式建議，還可查詢線路上任一點 的高程信息，該功能滿足了日常人們出行時對高程信息以及獲取出行方式建議的 需求，方便了人們的生活。
本文的研究成果已經實用于景區的車輛調度管理，并且系統處于持續更新完 善狀態。本系統在更換基礎數據之后，能夠用于其他類似需要車輛調度的地區。 雖然本系統及相關算法已經具有了具體的使用場景，但是本文還有以下內容需要
進一步完善：
（1）在車輛調度中，本文只是簡單的給出游客對時間的要求來度量滿意度， 然而現實中不同游客對時間的需求是不一樣的，并且游客滿意度的度量不僅僅是 時間，還有司機服務態度、交通狀況等因素，所以在后續的研究中，還因細化不 同游客的滿意度，加入更多的因素來度量滿意度。
（2）因工期等原因，目前高程剖面圖功能僅實現于車載APP中，后續應該 將此功能集成到微信小程序中，方便游客的使用。
（ 3）目前系統雖然可以正常滿足需求，系統異常也較少，但是界面還需進 一步的美化。
致 謝
行色匆匆，三年的研究生生涯轉瞬即逝，七年的理工生涯即將結束，站在校 園與社會的路口，感觸頗多。從最開始懷著進一步提升自己的夢想，再次踏入理 工校門，成都理工大學以其優良的學風、嚴謹的治學理念育我成人。值此畢業論 文完成之際，向關心和幫助我的老師和同學表示最誠摯的感謝與最美好的祝愿。
首先要感謝我的恩師余代俊教授。本論文是在余老師和蒲老師的悉心指導下 完成的。本科期間，余老師就以其淵博的知識、嚴謹的治學態度、幽默風趣的課 堂、精益求精的工作態度以及平易近人的生活態度深受同學們的敬愛，而自己有 幸在研究生期間成為余老師學生。在研究生期間，余老師對我做人做事都細心教 導，關心日常生活，養成良好生活習慣；做事循循善誘，鼓勵大膽去鉆研學習； 余老師很少會嚴厲斥責學生，更多的是以誠相待，讓學生自己意識到錯誤并改之。 在與余老師的相處中懂了胸有成竹以及理解和真誠，在我離開校園后定能警示自 己知識才是最大的財富，待人接物應如余老師一般真誠。余老師不僅授我以魚， 更授我以漁，在此我向我的導師余代俊教授再次表示由衷的感謝和祝福！
其次我還要特別感謝蒲朝旭老師，蒲老師對我來說亦師亦友，在理工的七年 給予了我很大幫助。本科剛進學校時他是班主任，接著作為實驗室助理，隨后便 是蒲老師指導測量比賽，再到本科畢業，研究生入學到畢業，那兒都有蒲老師的 影子。在學習上為我授業解惑，在生活中我們無話不說。由衷的感謝蒲老師七年 以來對我的幫助和鼓勵，在您的支持下我變得更加堅強與懂事。
同時，也要感謝德清數聯空間信息技術有限公司給予我的實習機會，感謝數 聯空間總裁倪涵高工和黎旻毅總經理在工作實習中給予的幫助和支持，在實習過 程中始終耐心解答問題，鼓勵創新試錯，開拓了視野，以實際項目提升了自身能 力，為今后工作打下了堅實基礎，期待今后再次合作。
感謝銀四六一六的室友牟致恒、譚易、李思彤以及同門萬啟樂、錢素芳，在 三年的朝夕相處中，大家互相幫助，共同進步，暢聊天地，為生活增添了不少樂 趣，還記得一起深夜去吃蹄花、燒烤那段路，感謝你們的陪伴。
感謝父母兄弟以及老婆對我研究生三年學習的支持，感謝你們總是支持我讀 研的決定，是你們在背后的默默付出支撐著我前進，從經濟上和精神上給予了我 莫大的鼓勵，你們是我努力奮斗的動力，在今后的生活中換我為你們遮風擋雨。
感謝成都理工大學地球科學學院測繪工程系各位老師的教導和幫助！是你們 讓我專業知識更加牢固，有了立足之本。
最后向參與審閱、評議本文的各位老師表示忠心的感謝！因為有您們的關心 和幫助，我才能順利的完成自己的學業。在以后的生活中我會更加勤奮的學習、 認真工作。最后祝愿所有關心和幫助我的人永遠健康、快樂。
參考文獻
曹二保.2008.物流配送車輛路徑問題模型及算法研究[D].長沙:湖南大學.
陳成.2018.基于改進遺傳算法的帶時間窗的多目標配送路徑優化J].信息技術與信息化, (10):48-51.
陳國良，王煦法，莊鎮泉，等.1996.遺傳算法及其應用[M].北京:人民郵電出版社.
陳建安，郭大偉，徐乃平，等.1998.遺傳算法理論研究綜述J].西安電子科技大學學報(自 然科學版)， 25(3):363-368.
陳建英，黃演紅.2015.互聯網+大數據[M].北京:人民郵電出版社.
鄧婷文.2016.茶卡鹽湖游客空間行為分析及智慧景區設計[D].昆明:云南大學.
范立南，呂鵬.2021.基于改進遺傳算法的校園外賣配送路徑規劃J].物流科技,44(01):14-19. 高偉.2015.九寨溝智慧景區管理體系建設J].科技創新導報,12(20):177-178.
高楊浩.2017.基于RFID的景區服務系統的研究[D].西安:陜西科技大學.
郭佳寧.2016.基于MVP的前端框架CASFront的設計與實現[D].天津:天津大學.
郭肇祿.2010. 一種基于自適應遷移策略的并行遺傳算法[D].贛州:江西理工大學. 國家統計局.2021.中華人民共和國2020年國民經濟和社會發展統計公報[N].人民日報.
胡洋洋.2018.基于WebSocket的服務器推送技術的研究與實現[D].南京:南京郵電大學.
黃保翕.2013. ASP.NET MVC5開發指南[M].北京:清華大學出版社.
蔣麗芹，包沁昕.2013.基于物聯網技術的我國智慧旅游產業發展研究J].雞西大學學報, 13(01):60-62.
金賽.2020.供需視角下景區智慧化發展水平測度與優化研究[D].桂林:桂林理工大學.
蘭海軍.2016.旅游公共服務質量改進研究[D].廈門:廈門大學.
郎茂祥，胡思繼.2002.用混合遺傳算法求解物流配送路徑優化問題的研究J].中國科學管 理， 1010(15):51-56.
李沖，熊淑華，魏穎穎.2011.基于CSS與JavaScript技術的Tab面板的設計與實現J].計算 機技術與發展， 21(3):28-30.
李德仁，龔健雅，邵振峰.2010.從數字地球到智慧地球J].武漢大學學報(信息科學版), 35(02):127-132.
李芳.2018.游客體驗視角下天涯海角智慧旅游景區建設與發展研究[D].三亞:海南熱帶海 洋學院.
李高揚.2008.蟻群算法在車輛調度問題中的應用研究[D].沈陽:東北大學.
劉軍.2009.基于Intranet的Web應用向Internet遷移的方案設計與實現[D].沈陽:東北大學.
柳武生，譚倩.2012.基于混合算法的實時訂貨信息下車輛調度優化J].應用數學與計算數 學學報， 26(1):53-65.
秦冠男.2013.基于ASP.NET MVC框架的IT管理系統的設計[D].上海:上海交通大學.
石文濤.2014. Html5中WebSocket協議關鍵技術的研究及基于WebSocket協議的實時Web 通信系統的實現[D].南京:南京郵電大學.
宋磊，林洪波，王緒華.2011.基于3D-GIS的智慧泰山景區信息集成平臺[J].中國園林, 27(09):30-32.
王東華.2016.精通Android網絡開發[M].北京:人民郵電出版社.
王惠，陳燕.2004.基于遺傳算法的多目標的有時間窗的車輛調度[J].計算機應用,24(9):144- 146.
衛田.2007.物流配送中車輛路徑問題的多目標優化算法研究[D].北京:清華大學.
吳樹新.2015.基于雙層遺傳算法的城市出租車合乘模型的研究[D].大連:大連交通大學. 吳一.2015. YS智慧景區建設研究[D].鄭州:鄭州大學.
徐岸峰.2019基于網絡平臺的智慧旅游服務模式研究[D].哈爾濱:哈爾濱理工大學.
徐洋洋.2013.多目標帶時間窗的車輛路徑問題研究[D].沈陽:東北大學.
顏敏.2014.基于物聯網的南京智慧景區建設研究[J].江蘇第二師范學院學報,(08):5-8.
顏曉峰.2019.論新時代我國社會主要矛盾的變化[J].中共中央黨校(國家行政學院)學報, 23(02):5-13.
楊林林.2020.智慧景區建設模式研究一一以故宮博物院為例[J].現代營銷(經營版),(10):24- 25.
楊善林，馬華偉，顧鐵軍.2010.時變條件下帶時間窗車輛調度問題的模擬退火算法[J].運籌 學學報, 14(03):83-90.
余國印.2015.車輛調度問題的改進自適應遺傳算法[J].物流科技,38(8):141-143.
俞海，顧金媛.2017.數據庫基本原理及應用開發教程[M].南京:南京大學出版社. 雨辰.2018. 2018環法自行車賽回顧[J].中國自行車,(09):94-101.
張菲菲.2015.黃果樹智慧景區建設研究[D].重慶:西南大學.
張漢坤.2019.鐵路貨物門到門運輸經由設計的多目標群集智能算法研究[D].北京:北京交 通大學.
張雁翔，祁育仙.2017.改進遺傳模擬退火算法求解TSP[J].智能計算機與應用,7(03):52-54. 甄文祥，王文田.2000.遺傳算法及其應用[J].小型微型計算機系統,23(6):9-10.
鄭俊，方旻蔚.2013.淺談智慧旅游建設[J].計算機時代,(05):68-70.
鐘石泉，賀國光.2005.多車場有時間窗的多車型車輛調度及其禁忌算法研究[J].運籌學學 報, (4):67-73.
Alinag hian M, Tirkolaee E B, Dezaki Z K, et al. 2021. An Augmented Tabu Search Algorithm for the Green Inventory-Routing Problem with Time Windows[J]. Swarm and Evolutionary Computation, 60:100802.
Banos R, Ortega J, Gil C, et al. 2013. A simulated annealing-based parallel multi-objective approach to vehicle routing problems with time windows[J]. Expert Systems with Applications, 40(5): 1696-1707.
Bell J E, Mc Mullen P R. 2004. Ant colony optimization techniques for the vehicle routing problem[J]. Advanced Engineering Informatics, 18(1): 41-48.
Buhalis D, Amaranggana A. 2015. Smart Tourism Destinations Enhancing Tourism Experience Through Personalisation of Services[J]. Springer International Publishing.
Chen B, Zhu W X, Liu Y. 2018. Algorithm for complex network diameter based on distance matrix[J]. Journal of Systems Engineering and Electronics, 29(02):336-342.
Coelho V. N., Grasas A., Ramalhinho H. 2015. An ILS-based algroitthm to solve a large-scale real heterogeneous fleet with multi-trips and docking constrains[j]. European Journal of Operational Research, 1-10
Dantzig G B, Ramser J H. 1959. The Truck Dispatching Problem[J]. Management Science, 6(1):80- 91.
Desfontaines L, Desaulniers G. 2018. Multiple Depot Vehicle Scheduling with Controlled Trip Shifting[J]. Transportation Research Part B: Methodological, 113:34-53.
Dorigo M, Maniezzo V, Colorni A. 1991. The ant system: An autocalytic optimizing process[R]. Technical Report.
Glover F. 1989. Tabu search-part I[J]. ORSA Journal on computing, 1(3): 190-206.
Gretzel U. 2011. Intelligent systems in tourism: a social science perspective[J]. Annals of Tourism Research, 38(3):757-779.
He Z Q, Yan Y F, Feng S, et al. 2021. Multi-objective optimizations on thermal and hydraulic performance of symmetric and asymmetric bionic Y-shaped fractal networks by genetic algorithm coupled with CFD simulation[J]. International Communications in Heat and Mass Transfer, 124.
Holland J H. 1992. Adaptation in Natural and Artificial Systems: An Introductory Analysis with Applications to Biology, Control, and Artificial Intelligence[M]. The MIT Press: 04-29.
Jiao D Q, Liu C, Li Z, Wang D H. 2021. An improved ant colony algorithm for TSP application[J]. Journal of Physics: Conference Series, 1802(3).
Li J, Lu W H. 2014. Full truckload vehicle routing problem with profits[J]. Journal of Traffic and Transportation Engineering(English Edition) ,1(02):146-152.
Li Y Q, Wang R X, Liu Y, Xu M Q. 2015. Satellite range scheduling with the priority constraint: An improved genetic algorithm using a station ID encoding method[J]. Chinese Journal of Aeronautics, 28(03):789-803.
Ombuki B, Ross B J, Hanshar F. 2006. Multi-objective genetic algorithms for vehicle routing problem with time windows[J]. Applied Intelligence, 24(1): 17-30.
Petersen H L， Larsen A， Madsen O B G， et al. 2012. The simultaneous vehicle scheduling and passenger service problem[J]. Transportation Science. 47(4): 603-616.
Pinedo M， Zacharias C， et al. 2015. SCHEDULING IN THE SERVICE INDUSTRIES:AN OVERVIEW[J]. Journal of Systems Science and Systems Engineering， 24(01):1-48.
Tarantilis C D， Ioannou G， Kiranoudis C T， et al. 2005. Solving the open vehicle routing problem via a single parameter metaheuristic algorithm[J]. Journal of the Operational Research Society， 56(5): 588-596.
Tufano A， Accorsi R， Manzini R. 2020. A simulated annealing algorithm for the allocation of production resources in the food catering industry[J]. British Food Journal， 122(7).
下一篇：沒有了
相關標簽:
