本發(fā)明涉及移動通訊技術領域，尤其涉及一種基于路線計劃的智能出行方法及系統(tǒng)。

背景技術：

當前旅游已經(jīng)成為人們一種必不可少的生活方式，而且隨著智能手機普及，越來越多人借助APP(手機軟件)獲得便捷的旅游服務。例如通過APP預訂機票、酒店、景區(qū)門票，甚至可以自行定制行程計劃。然而現(xiàn)有技術所提供定制或自動生成的行程計劃只適合單人或幾個人的自由行，對于人數(shù)較多的團隊出行，顯然無法適用，其主要的不足在于：

1）行程計劃只有文字描述，需要游客登錄網(wǎng)站或APP瀏覽。對于沒法在一起溝通的多人游客來說，通常只能通過即時通訊工具推送給游客，缺乏團隊共享模式；

2）行程計劃沒有提醒功能，尤其是沒有群體提醒、多人協(xié)同的功能。為了避免遺忘出錯，游客需要自行設定日程提醒；盡管一些日程管理工具也支持基于時間地點進行提醒管理，然而這類日程管理工具要么是按單人事務的模式進行管理，要么按照會議固定地點的模式進行管理，沒有考慮多個目標地點及目標地點動態(tài)變化的情形；

3）行程計劃只是對出行路線進行粗放式管理，即按景點對行程路線進行說明，沒有實際地理位置對應，沒有具體的時間計劃，只是一個個地理名詞和大致的時間。游客始終無法直觀了解具體的路線安排。從而也導致游玩過程中，一方面導游需要通過不斷招呼來引導游客，隨時關注游客是否跟上，一旦游客掉隊了，還要不斷地電話聯(lián)系，費心費力；另一方面游客需要始終跟著導游，即使自由活動時也提心吊膽的，擔心一不小心就跟丟了，缺少自由游玩的樂趣。容易想到的解決方法就是通過即時通訊工具進行多人的位置共享，讓導游、游客彼此間能看到對方的位置，如果發(fā)現(xiàn)有人掉隊了就通過即時通訊工具招呼引導。然而這種方法需要導游、游客經(jīng)常查看手機來引導隊伍或跟隨隊伍，工作量并未減少，而且多人的位置共享，使得游客的隱私權遭到侵害，從而容易受到游客的抵觸，最終導致方法無法實際應用。另一種方式就是采用地理圍欄技術，可以一定程度上對游客進行路線管理，避免游客偏離計劃路線。然而地理圍欄僅僅通過地理位置進行路線控制，沒有時間維度的管理，也就是說如果游客沒有偏離路線，無論呆多長時間都不會提醒或發(fā)出警報，這顯然也無法在旅游活動中采用；

4）行程路線變更通常通過口頭傳達，容易通知不到位，且缺乏游客確認憑據(jù)，容易導致旅游糾紛。

而且旅游過程中，隊伍經(jīng)常需要集合，例如坐車、就餐時。現(xiàn)有技術都是把集合要求同時發(fā)給所有人員，然后再在集合點清點人數(shù)。這種做法在隊伍行進進度差異較大時，必然導致快的人要等慢的人較長的時間，容易引發(fā)一些抱怨甚至引起沖突。

此外，人們出行時需要預訂酒店、門票、消費券等旅游服務，然而這些服務通常都有時間上和/或位置上的限制。當實際出行時，如果路線發(fā)生改變，則需要支付一定的退訂費用。尤其隨著網(wǎng)絡支付的普及，越來越多服務類商品采用二維碼等作為用戶線下消費憑證。由于二維碼/消費碼已被知曉，無法進行二次交易，在無法退訂情況下，游客只能免費轉讓給好友甚至浪費了。這些都在一定程度上限制了人們出行的自由度。

總而言之，現(xiàn)有技術并沒有針對多人團體旅游提供便捷智能的出行管理服務，滿足人們游玩路線的自主性、多變性的需求，讓游客在獲得跟團旅游安全省心價優(yōu)的優(yōu)質服務，的同時，又能享受個性自由行的樂趣。且由于路線計劃不精細，使得第三方服務無法智能接入，難以真正做到智慧旅游、智慧出行。

技術實現(xiàn)要素：

針對上述不足，本發(fā)明提供一種基于路線計劃的智能出行方法及系統(tǒng)，由導游或領隊預先設置路線計劃，然后通過系統(tǒng)根據(jù)路線計劃自動地對游客進行路線引導提醒及服務支持。借助位置定位及互聯(lián)網(wǎng)的云管理，一方面降低了導游領隊的帶團工作強度，實現(xiàn)路線導游的智能化及服務資源的共享，另一方面在確保行程安全順利情況下給予游客更大的自由活動空間，可以充分體驗自由行的快樂。

為達到上述目的，本發(fā)明的技術方案為：

一種出行路線智能管理方法，包括以下步驟：

第一用戶創(chuàng)建團隊路線計劃；

第二用戶接受團隊路線計劃，以及根據(jù)需要設置個人路線計劃；

根據(jù)整體路線計劃對第一用戶和第二用戶進行智能管理。

所述第一用戶指代導游或領隊或活動組織者；

所述第二用戶指代游客或活動參與者；

所述團隊路線計劃由至少兩個路線節(jié)點構成；

所述路線節(jié)點包括但不限于以下屬性項：節(jié)點序號、節(jié)點類型、節(jié)點位置、計劃到達時間、計劃停留時間、出行方式、預警時限、組隊方式；

所述節(jié)點序號是由系統(tǒng)按照出行順序(也就是計劃到達時間順序)自動生成的節(jié)點編號，方便用戶快速地識別或區(qū)別路線節(jié)點，以及用戶交流時能準確傳遞節(jié)點信息；例如節(jié)點序號為n的路線節(jié)點，即可稱作路線節(jié)點n；

所述節(jié)點類型包括：必選節(jié)點、可選節(jié)點；

所述節(jié)點位置具有兩種定位模式：

1）預定位模式。當用戶在設定或瀏覽團隊路線計劃時系統(tǒng)根據(jù)給定的經(jīng)緯度坐標，或地理名稱，或電子地圖中選取點獲得的固定的地理位置；

2）動態(tài)定位模式。在預定的時間范圍，當?shù)谝挥脩艉偷诙脩襞R近預定位的地理位置時，系統(tǒng)即時地根據(jù)第一用戶的位置坐標給出的動態(tài)變化的地理位置。

所述出行方式用于設定用戶前往路線節(jié)點的交通方式，包括但不限于以下的一個或多個：步行、騎行、乘車、駕車、飛機；

所述預警時限是第一用戶為了避免第二用戶前往路線節(jié)點時出現(xiàn)遲到等異常情況設置的提前預警時間；

所述組隊方式用于設定用戶前往路線節(jié)點期間的組隊方式，包括但不限于：導游/領隊帶隊、自由行。

所述第一用戶創(chuàng)建團隊路線計劃步驟，具體包括：

1）進入路線制作模塊；

2）新建一個團隊路線計劃，設置團隊路線屬性；

3）添加路線節(jié)點,設置節(jié)點屬性；

4）根據(jù)需要為路線節(jié)點添加子路線；

5）完成團隊路線計劃。

所述團隊路線屬性包括但不限于以下屬性：路線名稱、內容介紹、制作人、制作時間；

所述路線計劃可以有多個層級，即一個路線節(jié)點可以展開為子路線計劃，形成多層級的樹狀結構；

所述團隊路線計劃具有唯一標識號，支持復制、修改、轉發(fā)和共享；

優(yōu)選的，所述團隊路線計劃在傳播時可以采用XML(EXtensible Markup Language，可擴展標記語言)格式進行存儲，以進行跨平臺使用；

進一步的，第一用戶可通過復制修改的已有的團隊路線計劃生成新的團隊路線計劃；

更進一步的，系統(tǒng)可以根據(jù)第一用戶選擇的目的地自動匹配熱門的路線節(jié)點（包含子路線計劃）及其優(yōu)先設置，進而生成新的團隊路線計劃。

所述第二用戶接受團隊路線計劃包括但不限于以下方式：

1）第一用戶把第二用戶添加為包含團隊路線計劃的活動的參與成員；

2）第二用戶自行加入包含團隊路線計劃的活動。

所述設置個人路線計劃的步驟包括：

1)打開團隊路線計劃；

2) 啟動個人路線編輯模式；

3) 關閉團隊路線計劃中的可選節(jié)點；或者

4) 添加新的路線節(jié)點，并設置節(jié)點屬性；

5) 完成個人路線設置。

所述根據(jù)整體路線計劃對第一用戶和第二用戶進行智能管理步驟，包括但不限于：

1）周期地通過衛(wèi)星定位或位置服務獲得第一用戶和第二用戶的地理位置；

2）將第一用戶的地理位置共享給第二用戶；

3）根據(jù)第一用戶和第二用戶的地理位置判斷團隊及個人當前行進的階段，即確定團隊和個人的當前節(jié)點(正在前往或正處在停留期間的路線節(jié)點)；

4）計算并顯示用戶到達當前節(jié)點的剩余距離、預計用時以及根據(jù)需要進行路線導航；

5） 根據(jù)第一用戶和第二用戶的地理位置及當前節(jié)點的節(jié)點位置和組隊方式，確定第二用戶的預警等級：正常、提醒、警報；

6） 當?shù)诙脩舻念A警等級為提醒時，系統(tǒng)對第二用戶發(fā)出提醒，同時將第二用戶與第一用戶的距離同步給第一用戶；

7） 當?shù)诙脩舻念A警等級為警報時，系統(tǒng)將同時向第一用戶和第二用戶發(fā)出警報，并且如果節(jié)點類型為可選，向第二用戶確認是否關閉當前的可選節(jié)點以及基于后續(xù)節(jié)點提供新的路線計劃供第二用戶選擇，否則持續(xù)周期性對第二用戶和第一用戶發(fā)出警報，或提供預先設定的服務支持，包括但不限于導航服務、求助服務、報警服務；

8）當?shù)诙脩舴钦ｋx線時，向第一用戶發(fā)出警報及提供第二用戶的最后位置及上報時間。

所述根據(jù)第一用戶和第二用戶的地理位置及當前節(jié)點的節(jié)點位置和組隊方式，確定第二用戶的預警等級，包括但不限于以下方法：

1）計算第二用戶到第一用戶的距離，當相距距離小于等于第一距離閾值時，預警等級為正常；

2）計算第二用戶到當前節(jié)點的距離，當相距距離小于等于第一距離閾值時，預警等級為正常；

3）當前節(jié)點的組隊方式為導游/領隊帶隊時，如果第二用戶到第一用戶的距離大于第一距離閾值小于等于第二距離閾值時，預警等級為提醒；

4）當前節(jié)點的組隊方式為導游/領隊帶隊時，如果第二用戶到第一用戶的距離大于第二距離閾值時，預警等級為警報；

5）當前節(jié)點的組隊方式為自由行時，根據(jù)當前節(jié)點的出行方式計算出第二用戶從當前位置到達當前節(jié)點位置的到達時間，如果到達時間早于(即小于等于)計劃到達時間且提前時間超過(大于等于)預警時限時，預警等級為正常；

6）當前節(jié)點的組隊方式為自由行時，根據(jù)當前節(jié)點的出行方式計算出第二用戶從當前位置到達當前節(jié)點位置的到達時間,如果到達時間早于(即小于等于)計劃到達時間，但提前時間小于預警時限時，預警等級為提醒；

7）當前節(jié)點的組隊方式為自由行時，根據(jù)當前節(jié)點的出行方式計算出第二用戶從當前位置到達當前節(jié)點位置的到達時間,如果到達時間晚于(即大于)計劃到達時間時，預警等級為警報。

所述一種出行路線智能管理方法，可以進一步包括:

1)經(jīng)授權的第一用戶可以隨時修改團隊路線計劃，系統(tǒng)僅對歷史路線計劃進行記錄保存；

2) 第一用戶可以通過團隊路線屬性的設置使得第二用戶的個人路線計劃對第一用戶可見，或者第二用戶的個人路線計劃必須得到第一用戶的同意；

3) 經(jīng)授權確認后，第一用戶的人員構成可以根據(jù)需要添加或退出；

4) 基于第二用戶的路線計劃進行導游服務共享。

所述基于第二用戶的路線計劃進行導游服務共享步驟包括：

a) 第二用戶將個人路線計劃中的路線節(jié)點的組隊方式設置為動態(tài)導游；

b)系統(tǒng)根據(jù)第二用戶的動態(tài)導游路線自動匹配第一用戶人選；

c)對第二用戶與經(jīng)匹配的第一用戶在行進過程中進行智能管理；

d)當?shù)诙脩粜枰F(xiàn)場導游服務時向第一用戶發(fā)出導游請求；

e)第一用戶響應于第二用戶，并開始進行位置共享；

f)第一用戶與第二用戶通過系統(tǒng)提供的身份標識相互確認身份，以及第一用戶為第二用戶提供現(xiàn)場導游服務。

所述一種出行路線智能管理方法，可以再進一步包括：

第一用戶可設置路線節(jié)點的集合指令，或即時發(fā)起集合指令，系統(tǒng)根據(jù)集合指令自動進行隊伍分級集合管理。

所述集合指令包括：集合時間、集合地點；

所述系統(tǒng)根據(jù)集合指令自動進行隊伍分級集合管理，具體步驟包括：

1）根據(jù)集合指令及第二用戶當前的地理位置，計算出第二用戶前往集合地點所需的時間，并按預定的時間層級了確定通知順序層級：暫不通知、第一通知、第二通知、第三通知、已集合；如果所有第二用戶都處在暫不通知層級時，表示暫時不進行集合。系統(tǒng)在集合指令仍然有效時將持續(xù)周期地重復本步驟；

2）判斷是否存在處在第一通知層級的第二用戶，如果沒有則進行下一步，否則向第二用戶推送集合請求。如果第二用戶響應了集合請求，則將第二用戶狀態(tài)標記為正在集合，并周期更新第二用戶的位置給第一用戶。當所有處在第一通知層級且狀態(tài)為正在集合的第二用戶都進入第二通知層級區(qū)間時，進行下一步；

3）判斷是否存在處在第二通知層級且未作標記的第二用戶，如果沒有則進行下一步，否則向第二用戶推送集合請求。如果第二用戶響應了集合請求，則將第二用戶狀態(tài)標記為正在集合，并周期更新第二用戶與第一用戶的距離給第一用戶。當所有處在第二通知層級且狀態(tài)為正在集合的第二用戶都進入第三通知層級區(qū)間時，進行下一步；

4）判斷是否存在處在第三通知層級且未作標記的第二用戶，如果沒有則進行下一步，否則向第二用戶推送集合請求。如果第二用戶響應了集合請求，則將第二用戶狀態(tài)標記為正在集合，進行下一步；

5）當?shù)诙脩襞c集合地點的距離小于等于集合距離閾值時，標記為已集合。當當所有狀態(tài)為正在集合的第二用戶都標記為已集合時，提示集合指令執(zhí)行完成；

6）集合期間，如果第二用戶未接收到集合請求信息，則在預定時間范圍內周期性向第二用戶推送集合請求，如仍未能正常接收，則將第二用戶狀態(tài)標記為接收異常；如第二用戶不同意集合請求或不響應集合請求，則將第二用戶狀態(tài)標記為暫不集合；

7）集合期間，系統(tǒng)將每個第二用戶的狀態(tài)及匯總數(shù)據(jù)實時更新給第一用戶。

所述一種出行路線智能管理方法，還可以進一步包括以下步驟：

根據(jù)整體路線計劃對第三用戶發(fā)出服務請求及進行智能管理；

當?shù)谝挥脩艉?或第二用戶出現(xiàn)異常情況時，根據(jù)預設方式通知第四用戶。

所述根據(jù)整體路線計劃對第三用戶發(fā)出服務請求及進行智能管理步驟，包括：

1）將第一用戶的位置信息及團隊人數(shù)共享給第三用戶；

2）當?shù)谝挥脩舻奈恢脻M足預設條件時向第三用戶發(fā)出服務請求或提醒；

3）第二用戶可以對第三用戶進行評價，系統(tǒng)將根據(jù)自行設定的評價系統(tǒng)對第三用戶進行優(yōu)先推薦或逐步淘汰。

所述第三用戶指代第三方服務人員或組織；

所述第四用戶指代第一用戶和第二用戶的緊急聯(lián)系人。

為了避免由于路線變更導致已訂購旅游產(chǎn)品造成的退訂費用甚至無法退訂的損失，本發(fā)明還提供一種基于多級匹配的服務類商品交換方法，包括以下步驟：

用戶提交附帶時間范圍屬性和/或地理位置屬性的服務類商品交換請求，以及提出附帶時間范圍和/或地理位置需求的交換條件；

根據(jù)交換條件進行多級搜索，獲得滿足匹配條件的閉環(huán)交易鏈；

向交易鏈上的交易用戶發(fā)出交易確認請求；

在獲得交易用戶的確認信息后，將交易商品的現(xiàn)有商品標識碼注銷，生成新的商品標識碼發(fā)給對應的交易用戶。

所述商品消費碼是用戶進行商品消費時提交給商家的憑證，包括但不限于：條形碼、二維碼、消費碼、驗證號、團購號；

所述商品信息包括但不限于：商戶標識號、商品內容、訂購價格、有效期、服務地點或網(wǎng)點；

所述商品交換條件包括但不限于：商品內容/商品規(guī)格、消費時間、消費地點；

所述一種基于多級匹配的服務類商品交換方法，在用戶提交附帶時間范圍屬性和/或地理位置屬性的服務類商品交換請求，以及提出附帶時間范圍和/或地理位置需求的交換條件步驟之前，還可以包括：

與商家系統(tǒng)對接，獲得所接入服務類商品的查詢權限及交易權限。

所述一種基于多級匹配的服務類商品交換方法， 還可以進一步包括：

1)對于同一商品的多個商品消費碼，系統(tǒng)自動根據(jù)服務期限的到期快慢順序進行匹配；

2)系統(tǒng)在商品退訂期限前，自動向商家發(fā)起退票請求，以及在完成退票操作后，將退訂信息推送給用戶。

同時，發(fā)明還提供一種基于路線計劃的智能出行方法，包括以下步驟：

第一用戶創(chuàng)建即時通訊群，設置群屬性及添加團隊路線計劃；

第二用戶加入群，設置個人偏好設置及根據(jù)需要設置個人路線計劃；

系統(tǒng)根據(jù)路線計劃的時間范圍進行群信息共享；以及

根據(jù)路線計劃進行出行路線智能管理。

進一步的，一種基于路線計劃的智能出行方法，還可以包括：

1）以團體方式訂購的旅游產(chǎn)品可以分發(fā)到個人，并支持進行基于多級匹配的服務類商品交換；

2）第一用戶基于照片或短視頻的進行景點解說及游記制作。

所述以團體方式訂購的旅游產(chǎn)品可以分發(fā)到個人，并支持進行基于多級匹配的服務類商品交換，具體步驟包括：

a)團隊預訂的旅游產(chǎn)品在系統(tǒng)后臺生成對應數(shù)量的商品消費碼；

b)第二用戶可以申請歸屬個人的商品消費碼下發(fā)到個人；以及

c)根據(jù)需要可將商品消費碼對外進行基于多級匹配的服務類商品交換。

所述第一用戶基于照片或短視頻的進行景點解說及游記制作分享，具體步驟包括：

a)第二用戶提交景點照片或短視頻，同時附加位置信息；

b)第一用戶基于所述景點照片或短視頻及附加的位置信息進行景點解說;

c)第二用戶對景點照片或短視頻進行評價/評級；

d)旅游結束后，第一用戶或系統(tǒng)根據(jù)篩選規(guī)則篩選出景點照片或短視頻；

e)第二用戶選擇一個經(jīng)篩選的景點照片或短視頻進行留言；

f)第一用戶將景點照片或短視頻結合解說內容和第二用戶的留言生成電子版游記。

一種基于路線計劃的智能出行系統(tǒng)，包括服務器和至少2個移動終端，移動終端通過移動通訊網(wǎng)絡與服務器進行交互，其特征在于，

所述服務器包括：

即時通訊服務模塊，用于實現(xiàn)多個移動客戶端之間的即時通訊，包括創(chuàng)建對話/聊天群，進行信息推送；

路線管理服務模塊，包括位置服務單元，路線查詢服務單元，路線制作服務單元，路線預警服務單元，路線導航服務單元；

其中位置服務單元用于通過衛(wèi)星定位信息或位置服務獲取用戶的地理位置信息；路線制作服務單元用于進行路線計劃的創(chuàng)建、修改、發(fā)布及查詢；路線預警服務單元用于依據(jù)路線計劃對用戶提醒、預警；路線導航服務單元用于依據(jù)路線計劃或用戶設定目標進行路線導航；

地理信息模塊，用于提供平臺所需地理信息數(shù)據(jù)。

所述移動終端包括：

即時通訊模塊，用于提供即時通訊交互界面，提交或顯示即時通訊信息；

路線管理模塊，用于進行路線查找、路線制作、路線預警、路線導航的交互，提交用戶指令給服務器及獲得交互結果信息；

衛(wèi)星定位模塊，用于通過衛(wèi)星定位芯片獲得衛(wèi)星定位信息，并上報給服務器。

所述服務器可以進一步包括：

商品交換服務模塊，包括第三方商家接入單元，交易管理單元，多級撮合單元，商品消費碼管理單元；

其中第三方商家接入單元用于與提供服務類商品的商家交易系統(tǒng)對接，進行商品查詢及后臺交易；交易管理單元，用于交易(交換)請求的生成及交易流程管理；多級撮合單元，用于進行交易(交換)請求的多級撮合匹配；商品消費碼管理單元，用于商品消費碼的注銷、生成及管理。

所述移動終端可以進一步包括：

商品交換模塊，用于提供商品交換的交互界面，提交交易請求及顯示交易信息。

根據(jù)上述發(fā)明內容，本發(fā)明通過導游領隊預先設定路線計劃，對游客的旅游出行進行全路線的智能引導、智能服務。利用路線節(jié)點的動態(tài)定位及自由設置刪減，滿足路線計劃的即時性、多樣性、多變性的要求，使得跟團旅游也能享受自由行的樂趣。利用導游的位置共享，在確保游客隱私情況下，讓第三方服務依舊能無差錯地即時接入。利用對導游領隊的標識定位，使得導游領隊不再是固定的人員，實現(xiàn)導游服務的共享，在確保游客安全出行的同時最大限度利用導游資源，降低導游工作強度，提高導游待遇。此外本發(fā)明還提供了一種基于多級匹配的服務類商品交換方法，幫助游客根據(jù)個人喜好或自由行路線需要，與其他旅客進行酒店、門票、消費券等旅游服務的交換，減少因行程變化帶來的。讓游客不必一成不變地接受即定的服務，而是可以一定范圍內自主享受變化的樂趣。

附圖說明

圖1為本發(fā)明實施例一的一種出行路線智能管理的方法流程圖；

圖2為本發(fā)明實施例二的一種出行路線智能管理的方法流程圖；

圖3為本發(fā)明實施例三的路線計劃的終端展示圖之一；

圖4為本發(fā)明實施例三的路線計劃的終端展示圖之二；

圖5為本發(fā)明實施例三的路線計劃的終端展示圖之三；

圖6為本發(fā)明實施例三的路線計劃的終端展示圖之四；

圖7為本發(fā)明實施例四的一種基于多級匹配的服務類商品交換的方法流程圖；

圖8為本發(fā)明實施例五的一種基于路線計劃的智能出行的方法流程圖；

圖9為本發(fā)明實施例六的一種基于路線計劃的智能出行的系統(tǒng)結構框圖。

具體實施方式

為了便于本領域技術人員的理解，下面結合附圖對本發(fā)明作進一步的描述，所描述的實施例僅是本發(fā)明的部分實施例，并不能用來限制本發(fā)明的保護范圍。在不沖突的情況下，本申請的實施例及實施例中的特征可以相互組合。

圖1為本發(fā)明實施例一的出行路線智能管理的方法流程圖，包括以下步驟：

步驟S101, 第一用戶創(chuàng)建團隊路線計劃；

所述第一用戶指代導游和/或領隊和/或活動組織者；

所述團隊路線計劃由至少兩個路線節(jié)點構成；

所述路線節(jié)點包括但不限于以下屬性項：節(jié)點序號、節(jié)點類型、節(jié)點位置、計劃到達時間、計劃停留時間、出行方式、預警時限、組隊方式；

所述節(jié)點序號是由系統(tǒng)按照出行順序(也就是計劃到達時間順序)自動生成的節(jié)點編號，方便用戶快速地識別或區(qū)別路線節(jié)點，以及用戶交流時能準確傳遞節(jié)點信息；例如節(jié)點序號為n的路線節(jié)點，即可稱作路線節(jié)點n；

所述節(jié)點類型包括：必選節(jié)點、可選節(jié)點。

所述節(jié)點位置具有兩種定位模式：

1） 預定位模式。當用戶在設定或瀏覽團隊路線計劃時系統(tǒng)根據(jù)給定的經(jīng)緯度坐標，或地理名稱，或電子地圖中選取點獲得的固定的地理位置；

2） 動態(tài)定位模式。在預定的時間范圍，當?shù)谝挥脩艉偷诙脩襞R近預定位的地理位置時，系統(tǒng)即時地根據(jù)第一用戶的位置坐標給出的動態(tài)變化的地理位置。

其中動態(tài)定位模式是為了解決路線節(jié)點位置無法預先精確定位的問題。例如當路線節(jié)點是機場時，系統(tǒng)只能根據(jù)地理名詞，給出默認的地理位置。然而，機場面積并不小，游客在沒有更具體定位下是無法會合在一起的?？蓪в我矡o法事先如此具體地把集合點預先確定下來。因此，本發(fā)明通過預先粗定位結合現(xiàn)場動態(tài)精確定位的方式，在不增加計劃設定難度的前提下實現(xiàn)對游客進行有效的具體的引導。

同時，當?shù)谝挥脩舸_定集合點后，可以啟動位置坐標固定的功能，使其位置坐標不再隨者自身移動而移動。相當于將第一用戶的位置坐標臨時固定在某一個位置坐標上，直到第一用戶取消臨時定點。位置坐標固定功能還具有給以第一用戶短暫的私人空間的作用，同時又不讓游客失去了第一用戶位置的導航目標。

顯然地，采用諸如雙節(jié)點(固定節(jié)點+動態(tài)節(jié)點)等變通方式來實現(xiàn)上述功能需求的，亦屬于本發(fā)明保護的范圍。

所述預計達到時間默認情況下由系統(tǒng)將根據(jù)歷史導航數(shù)據(jù)計算出路線節(jié)點間的用時及合理余量自動給出。為了進一步減少設置的工作量，預計到達時間可以分為浮動式或驅動式的，浮動式的預計到達時間將以驅動式的預計到達時間為基準自動調整，除非兩個動式的預計到達時間存在矛盾，系統(tǒng)將給出沖突提示。

所述出行方式用于設定用戶前往路線節(jié)點的交通方式，包括但不限于以下的一個或多個：步行、騎行、乘車、駕車、飛機。其中乘車表示乘坐公共交通類工具，可能需要中轉的交通方式，而駕車則表示自駕車或乘坐專車或的士等可以直達的交通方式。當?shù)谝挥脩粑丛O置路線節(jié)點的出行方式時，則由系統(tǒng)根據(jù)用戶的地理位置和節(jié)點位置自動設置交通方式。

所述預警時限是第一用戶為了避免第二用戶前往路線節(jié)點時出現(xiàn)遲到等異常情況設置的提前預警時間。預警時間通常根據(jù)路線節(jié)點的關鍵性及交通狀況來預設。當然也可以由系統(tǒng)根據(jù)大量的歷史數(shù)據(jù)分析給出，或者簡單地直接設置統(tǒng)一的數(shù)值。

通過第一用戶設定的出行方式，使得系統(tǒng)可以根據(jù)用戶位置估算用戶前往對應路線節(jié)點的時間，進而根據(jù)所述預警時限向用戶發(fā)出提醒或預警。

所述組隊方式用于設定用戶前往路線節(jié)點期間的組隊方式，包括但不限于：1）導游/領隊帶隊；2）自由行。組隊方式對游客設定個人路線計劃進行一定的約束。例如對于乘坐飛機或路線復雜存在一定危險的路段，要求導游/領隊帶隊，此時游客必須在出發(fā)前與導游/領隊會合，再一同出發(fā)；對于安全系數(shù)較高的路線或區(qū)域，可以設置為自由行，則游客無需和導游/領隊一起，可以自行出發(fā)行進。

應當知道的是，所述路線節(jié)點的屬性項是基于路線計劃的通用控制要求而設定的，但并不需要每個路線節(jié)點都要設置所有屬性。也就是說當對某一屬性沒有要求時，是可以不設置或采用默認值的。例如計劃停留時間不設置則采用默認值0，即不作停留。

所述第一用戶創(chuàng)建團隊路線計劃步驟，具體包括：

1）進入路線制作模塊；

2）新建一個團隊路線計劃,設置團隊路線屬性；

3）添加路線節(jié)點，設置節(jié)點屬性；

4）根據(jù)需要為路線節(jié)點添加子路線；

5）完成團隊路線計劃。

所述團隊路線屬性包括但不限于以下屬性：路線名稱、內容介紹、制作人、制作時間；

所述添加路線節(jié)點,設置節(jié)點屬性步驟，可以是通過手工輸入各節(jié)點屬性的直接方式來添加一個路線節(jié)點，也可以通過輸入或導入機票/動車票/門票/酒店預訂等信息來間接添加路線節(jié)點。例如，當輸入機票信息時，系統(tǒng)可以根據(jù)機票的出發(fā)時間及出發(fā)城市生成節(jié)點A，同時再根據(jù)機票的預計達到時間及到達城市來生成節(jié)點B，從而簡化路線計劃的制作難度。具體將在后文示例中說明。需要說明的時，根據(jù)機票獲取的預計達到時間，默認是驅動式的。

所述路線計劃可以有多個層級，即一個路線節(jié)點可以展開為子路線計劃，形成多層級的樹狀結構。例如可以把一個景區(qū)當作一個路徑節(jié)點（父節(jié)點），而在景區(qū)內的游玩路線就可以作為子路線計劃。又例如一個包含多個城市游玩的路線，每個城市可以作為一個父節(jié)點，在城市內的游玩路線就作為子路線計劃。這樣，旅游達人或專業(yè)人員可以把一個景點或一個城市的游玩路線做成經(jīng)典路線計劃，而導游或活動組織者只需要簡單地把這些經(jīng)典路線計劃以單個路線節(jié)點的方式添加到待定制的路線計劃中即可，最大程度減少了路線計劃制作的工作量。需要說明的是，當子路線計劃的起始節(jié)點位置和結尾節(jié)點位置不是同一位置時，父節(jié)點的節(jié)點位置可以對應拆分為節(jié)點位置1和節(jié)點位置2。

為了方便管理及跨平臺使用，當團隊路線計劃發(fā)布時，系統(tǒng)還需要生成一個具有唯一性的路線計劃標識。通過路線計劃標識，用戶可在社交網(wǎng)絡或即時通訊工具中轉發(fā)、共享團隊路線計劃。除了首次打開時需要下載必要的插件或APP外，用戶可直接點擊包含路線計劃標識的鏈接以打開相應的團隊路線計劃。

優(yōu)選地，所述團隊路線計劃在傳遞時可以采用XML(EXtensible Markup Language，可擴展標記語言)格式進行存儲，以進行跨平臺使用。

進一步的，第一用戶可通過復制修改的已有的團隊路線計劃啦生成新的團隊路線計劃；

更進一步的，系統(tǒng)可以根據(jù)第一用戶選擇的目的地自動匹配熱門的路線節(jié)點（包含子路線計劃）及其優(yōu)先設置，進而生成新的團隊路線計劃。

通常地，所述路線計劃在移動終端展示時，只將同一層級的路線節(jié)點按節(jié)點序號順序依次排列顯示。當路線節(jié)點存在下一級的子路線計劃時，可以通過點擊的方式展開。優(yōu)選地，將同一層級的路線節(jié)點根據(jù)節(jié)點位置在電子地圖上用節(jié)點圖標標記出來，并采用連線或行進路線依次連接，形成連續(xù)的導航線。 為了使路線計劃在移動終端展示時更為簡潔，還可以根據(jù)時間/地點臨近優(yōu)先原則僅顯示部分路線節(jié)點，或者將位置相鄰的多個節(jié)點合并為一個節(jié)點圖標。 例如在一個城市停留3天游玩，并不需要把這3天的所有路線節(jié)點都顯示出來，可以根據(jù)時間臨近優(yōu)先原則先顯示第一天涉及的路線節(jié)點，再顯示第二、第三天的。再例如路線節(jié)點1和路線節(jié)點10的節(jié)點位置都是同一酒店時，可以把兩節(jié)點合并為一個節(jié)點圖標顯示。具體將在后文示例中說明。

步驟S102, 第二用戶接受團隊路線計劃，以及根據(jù)需要設置個人路線計劃；

所述第二用戶指代游客或活動參與者；

所述第二用戶接受團隊路線計劃包括但不限于以下方式：

1）第一用戶把第二用戶添加為包含團隊路線計劃的活動的參與成員；

2）第二用戶自行加入包含團隊路線計劃的活動。

同一活動可以啟用多條團隊路線計劃，但時間上需要錯開。

所述設置個人路線計劃的步驟包括：

1)打開團隊路線計劃；

2)啟動個人路線編輯模式；

3)刪除或修改團隊路線計劃中的可選節(jié)點；或者

4)修改團隊計劃中必選節(jié)點的特定屬性；

5)添加新的路線節(jié)點，并設置節(jié)點屬性；

6)保存修改，完成個人路線計劃設置。

需要說明的是，由于個人路線計劃僅適用于第二用戶自己，因此新增的路線節(jié)點的節(jié)點類型都是可選節(jié)點，即第二用戶可以隨時刪除或修改該節(jié)點。

此外，刪除團隊路線計劃中的可選節(jié)點并非真正移除，僅是做關閉或失效處理；而修改團隊路線計劃中的可選節(jié)點并不對團隊路線計劃產(chǎn)生影響，修改后的節(jié)點即為個人的路線節(jié)點，作用范圍僅限第二用戶自己。

第二用戶在添加、修改、刪除路線節(jié)點時，路線制作模塊將檢查所設置項是否與團隊路線計劃沖突。檢驗規(guī)則包括但不限于：

1） 第二用戶不能刪除團隊路線計劃中的必選節(jié)點；

2）第二用戶只能修改團隊路線計劃中必選節(jié)點的前往方式；

3）當新增路線節(jié)點或修改的可選節(jié)點時，其組隊方式自動設置和下一路線節(jié)點的組隊方式相同。這個原則確保了個人路線計劃要和團隊路線計劃的組隊方式一致；也就是說，如果某一必選節(jié)點設置為導游/領隊帶隊，則在此路線節(jié)點前的所有可選節(jié)點都應該是導游/領隊帶隊。通常地，應將路段兩端的節(jié)點都設為必選節(jié)點，避免節(jié)點被刪除后導致控制失效；

4）個人路線計劃是否會導致團隊路線計劃的任一節(jié)點的計劃到達時間無法滿足。如果不滿足則不允許添加或修改。例如當?shù)诙脩粝胄略鰣F隊路線計劃外的景點時，系統(tǒng)首先根據(jù)出行方式計算出新增的路線節(jié)點對下一路線節(jié)點的預計到達時間是否有影響，如果有影響，則限制添加。

可以看到個人路線計劃是基于團隊路線計劃的衍生計劃。除了節(jié)點類型和組隊方式有一定規(guī)則限制外，個人路線計劃和團隊路線計劃的組成結構及節(jié)點屬性種類并沒有什么不同，其主要差別僅在于適用的人員范圍不一樣。團隊路線計劃由第一用戶制定，適用于參與活動的所有用戶。而個人路線計劃由第二用戶自行制定，僅適用于第二用戶自己。

顯然地，為了便于系統(tǒng)能根據(jù)個人路線計劃對相應的第二用戶進行智能管理，個人路線計劃也應具有唯一標識號。通常個人路線計劃的標識號可以采用路線計劃標識加流水號的方式表示。

需要說明的是，如果第二用戶沒有修改團隊路線計劃進而形成個人路線計劃的，則團隊路線計劃等同于第二用戶的個人路線計劃，即系統(tǒng)依據(jù)團隊路線計劃對第二用戶個人進行路線智能管理。

步驟S103, 根據(jù)整體路線計劃對第一用戶和第二用戶進行智能管理；

所述根據(jù)整體路線計劃對第一用戶和第二用戶進行智能管理步驟，包括但不限于：

1）周期地通過衛(wèi)星定位或位置服務獲得第一用戶和第二用戶的地理位置；

2）將第一用戶的地理位置共享給第二用戶；

3）根據(jù)第一用戶和第二用戶的地理位置判斷團隊及個人當前行進的階段，即確定團隊和個人的當前節(jié)點(正在前往或正處在停留期間的路線節(jié)點)；

4）計算并顯示用戶到達當前節(jié)點的剩余距離、預計用時以及根據(jù)需要進行路線導航；

5） 根據(jù)第一用戶和第二用戶的地理位置及當前節(jié)點的節(jié)點位置和組隊方式，確定第二用戶的預警等級：正常、提醒、警報；

6）當?shù)诙脩舻念A警等級為提醒時，系統(tǒng)對第二用戶發(fā)出提醒，同時將第二用戶與第一用戶的距離同步給第一用戶；

7）當?shù)诙脩舻念A警等級為警報時，系統(tǒng)將同時向第一用戶和第二用戶發(fā)出警報，并且如果節(jié)點類型為可選，向第二用戶確認是否關閉當前的可選節(jié)點以及基于后續(xù)節(jié)點提供新的路線計劃供第二用戶選擇，否則持續(xù)周期性對第二用戶和第一用戶發(fā)出警報，或提供預先設定的服務支持，包括但不限于導航服務、求助服務、報警服務；

8）當?shù)诙脩舴钦ｋx線時，向第一用戶發(fā)出警報及提供第二用戶的最后位置及上報時間。

所述根據(jù)第一用戶和第二用戶的地理位置及當前節(jié)點的節(jié)點位置和組隊方式，確定第二用戶的預警等級，包括但不限于以下方法：

1）計算第二用戶到第一用戶的距離，當相距距離小于等于第一距離閾值時，預警等級為正常；

2）計算第二用戶到當前節(jié)點的距離，當相距距離小于等于第一距離閾值時，預警等級為正常；

3）當前節(jié)點的組隊方式為導游/領隊帶隊時，如果第二用戶到第一用戶的距離大于第一距離閾值小于等于第二距離閾值時，預警等級為提醒；

4）當前節(jié)點的組隊方式為導游/領隊帶隊時，如果第二用戶到第一用戶的距離大于第二距離閾值時，預警等級為警報；

5）當前節(jié)點的組隊方式為自由行時，根據(jù)當前節(jié)點的出行方式計算出第二用戶從當前位置到達當前節(jié)點位置的到達時間,如果到達時間早于(即小于等于)計劃到達時間且提前時間超過(大于等于)預警時限時，預警等級為正常；

6）當前節(jié)點的組隊方式為自由行時，根據(jù)當前節(jié)點的出行方式計算出第二用戶從當前位置到達當前節(jié)點位置的到達時間,如果到達時間早于(即小于等于)計劃到達時間，但提前時間小于預警時限時，預警等級為提醒；

7）當前節(jié)點的組隊方式為自由行時，根據(jù)當前節(jié)點的出行方式計算出第二用戶從當前位置到達當前節(jié)點位置的到達時間,如果到達時間晚于(即大于)計劃到達時間時，預警等級為警報。

當組隊方式增加時，還可以根據(jù)組隊方式的不同采用更多的規(guī)則來判斷第二用戶的預警等級。

顯然的，預警等級判斷規(guī)則的不同以及預警等級種類數(shù)量的不同，不能用于規(guī)避本發(fā)明的保護范圍。

需要說明的是，第一用戶可以是一個人，也可以是多個人。當?shù)谝挥脩羰嵌鄠€人時，所述第一用戶和第二用戶的距離通常指最近的距離，即系統(tǒng)默認以距離第二用戶個體最近的第一用戶個體作為具體計算/分析對象，再執(zhí)行相關管理控制。例如多個第一用戶個體，可以分別帶領著一個第二用戶小組游玩，此時系統(tǒng)也將根據(jù)各小組的行進路線及進度分別地進行智能管理。

所述一種出行路線智能管理方法，可以進一步包括:

1) 經(jīng)授權的第一用戶可以隨時修改團隊路線計劃，系統(tǒng)僅對歷史路線計劃進行記錄保存；

當團隊無法按時到達路線節(jié)點，或者團隊臨時決定變更旅游路線時，經(jīng)授權的第一用戶可以根據(jù)需要修改團隊路線計劃。而當團隊路線計劃修改后，將立即同步影響所有用戶,包括影響所有基于該團隊路線計劃的個人路線計劃。當然，路線計劃變更涉及合同行程變更時，需要得到第二用戶的確認，同時路線計劃的變更記錄也可以作為行程變更的記錄憑證；

2) 第一用戶可以通過團隊路線屬性的設置使得第二用戶的個人路線計劃對第一用戶可見，或者第二用戶的個人路線計劃必須得到第一用戶的同意；

在個別情況下，第一用戶希望能查看第二用戶制定的個人路線計劃，以便對第二用戶的個人安排保留知情權，避免第二用戶不安全的安排?；蛘咴O定第二用戶制定個人路線計劃時必須得到第一用戶的同意方能保存生效。例如導游帶團出國旅游時，導游有權知道團隊成員的行動安排，避免發(fā)生脫團情況，或能即時獲取脫團情況。當然，為了兼顧第二用戶的隱私權，當?shù)诙脩粢恢卑粗鴤€人路線計劃活動時，第一用戶時不知道第二用戶的具體位置的；

3) 經(jīng)授權確認后，第一用戶的人員構成可以根據(jù)需要添加或退出；

例如導游可以授權某個第二用戶為領隊，協(xié)助帶隊及活動管理；或者系統(tǒng)授權當?shù)貙в未嫒虒в芜M行景點內的帶隊及管理。由于第二用戶可以通過第一用戶的身份標識來識別不同的第一用戶，帶隊人員可以也不需要是固定不變的；

4）基于第二用戶的路線計劃進行導游服務共享；

所述基于第二用戶的路線計劃進行導游服務共享步驟包括：

a) 第二用戶將個人路線計劃中的路線節(jié)點的組隊方式設置為動態(tài)導游；

b)系統(tǒng)根據(jù)第二用戶的動態(tài)導游路線自動匹配第一用戶人選；

c)對第二用戶與經(jīng)匹配的第一用戶在行進過程中進行智能管理；

d)當?shù)诙脩粜枰F(xiàn)場導游服務時向第一用戶發(fā)出導游請求；

e)第一用戶響應于第二用戶，并開始進行位置共享；

f)第一用戶與第二用戶通過系統(tǒng)提供的身份標識相互確認身份，以及第一用戶為第二用戶提供現(xiàn)場導游服務。

所述動態(tài)導游的組隊方式與導游/領隊帶隊的組隊方式的差別僅在于動態(tài)導游時，系統(tǒng)將根據(jù)第二用戶的路線自動匹配路線一致的第一用戶，包括當前路線計劃外的外部用戶，而不限于當前路線計劃的第一用戶。換而言之，對第二用戶而言，導游服務是跨路線計劃的，是在系統(tǒng)范圍內相互共享的，主要基于路線一致/相同作為匹配依據(jù)；

所述的動態(tài)導游路線即第二用戶個人路線計劃中組隊方式為動態(tài)導游的路線節(jié)點所定位的路線；

所述對第二用戶與經(jīng)匹配的第一用戶在行進過程中進行智能管理，其具體方法與圖一步驟103的方法是一致的，在此不再贅述。

為了提高第一用戶的導游服務質量，所述一種出行路線智能管理方法可以進一步包括: 第二用戶可以對提供過導游服務的第一用戶進行評價。系統(tǒng)將根據(jù)自行設定的評價系統(tǒng)對第一用戶進行優(yōu)先推薦或逐步淘汰。

為了方便第一用戶進行隊伍集合，所述一種出行路線智能管理方法，可以進一步包括：第一用戶可設置路線節(jié)點的集合指令，或即時發(fā)起集合指令。系統(tǒng)根據(jù)集合指令自動進行隊伍分級集合管理。

所述集合指令包括：集合時間、集合地點；

其中集合時間是指預計完成集合的時間。集合時間可以采用絕對時間，也可以采用相對于路線節(jié)點時間的相對時間，例如在某一路線節(jié)點的預計到達時間的20分鐘后。

所述設置路線節(jié)點的集合指令即第一用戶在制定路線計劃時就提前設置好集合指令，其集合時間和集合地點與路線節(jié)點的預計到達時間及節(jié)點位置一致或相關聯(lián)；

所述即時發(fā)起集合指令即第一用戶根據(jù)當前需要立即發(fā)起集合請求，其集合地點和集合時間可根據(jù)需要自由設定。

所述系統(tǒng)根據(jù)集合指令自動進行隊伍分級集合管理，具體步驟包括：

1）根據(jù)集合指令及第二用戶當前的地理位置，計算出第二用戶前往集合地點所需的時間，并按預定的時間層級了確定通知順序層級：暫不通知、第一通知、第二通知、第三通知、已集合；

如果所有第二用戶都處在暫不通知層級時，表示暫時不進行集合。系統(tǒng)在集合指令仍然有效時將持續(xù)周期地重復本步驟；

2）判斷是否存在處在第一通知層級的第二用戶，如果沒有則進行下一步，否則向第二用戶推送集合請求。如果第二用戶響應了集合請求，則將第二用戶狀態(tài)標記為正在集合，并周期更新第二用戶的位置給第一用戶。當所有處在第一通知層級且狀態(tài)為正在集合的第二用戶都進入第二通知層級區(qū)間時，進行下一步；

3）判斷是否存在處在第二通知層級且未作標記的第二用戶，如果沒有則進行下一步，否則向第二用戶推送集合請求。如果第二用戶響應了集合請求，則將第二用戶狀態(tài)標記為正在集合，并周期更新第二用戶與第一用戶的距離給第一用戶。當所有處在第二通知層級且狀態(tài)為正在集合的第二用戶都進入第三通知層級區(qū)間時，進行下一步；

4）判斷是否存在處在第三通知層級且未作標記的第二用戶，如果沒有則進行下一步，否則向第二用戶推送集合請求。如果第二用戶響應了集合請求，則將第二用戶狀態(tài)標記為正在集合，進行下一步；

5）當?shù)诙脩襞c集合地點的距離小于等于集合距離閾值時，標記為已集合。當當所有狀態(tài)為正在集合的第二用戶都標記為已集合時，提示集合指令執(zhí)行完成；

6）集合期間，如果第二用戶未接收到集合請求信息，則在預定時間范圍內周期性向第二用戶推送集合請求，如仍未能正常接收，則將第二用戶狀態(tài)標記為接收異常；如第二用戶不同意集合請求或不響應集合請求，則將第二用戶狀態(tài)標記為暫不集合；

7）集合期間，系統(tǒng)將每個第二用戶的狀態(tài)及匯總數(shù)據(jù)實時更新給第一用戶。

可以看到，所述系統(tǒng)根據(jù)集合指令自動進行隊伍分級集合管理的方法，其核心創(chuàng)新點在于根據(jù)第二用戶的距離，由遠到近分級別/區(qū)間逐步發(fā)出集合通知，這樣既符合事情處理的緊急優(yōu)先原則，又可以讓第二用戶盡可能同一時間完成集合，而不是讓快的人(集合點附近的人)要等待慢的人（距離集合點遠的人），引發(fā)一些不滿情緒。顯然地，所述級別/區(qū)間的設置可以根據(jù)需要采用不同方式定義，這不能用于規(guī)避本發(fā)明的保護范圍。

通過上述發(fā)明方法，路線計劃實現(xiàn)了行程安排，智能提醒，多人活動協(xié)同以及導游共享服務的智能出行管理功能。且在絕大多數(shù)情況下，游客或活動參與者的位置坐標并沒有向其他用戶公開，保障了游客或活動參與者的隱私權。同時，相較于現(xiàn)有采用文字描述的行程計劃、旅游攻略，采用多級樹狀節(jié)點結構的路線計劃更利于用戶的靈活定制及傳播優(yōu)化，兼顧智能、簡單的雙重需求。

如圖2所示，所述一種出行路線智能管理方法，還可以進一步包括以下步驟：

根據(jù)整體路線計劃對第三用戶發(fā)出服務請求及進行智能管理；

當?shù)谝挥脩艉?或第二用戶出現(xiàn)異常情況時，根據(jù)預設聯(lián)系方式通知第四用戶；

所述第三用戶指代第三方服務人員或組織；

所述第四用戶指代第一用戶和第二用戶的緊急聯(lián)系人。

所述根據(jù)整體路線計劃對第三用戶發(fā)出服務請求及進行智能管理步驟，包括：

1）將第一用戶的位置信息及團隊人數(shù)共享給第三用戶；

2）當?shù)谝挥脩舻奈恢脻M足預設條件時向第三用戶發(fā)出服務請求或提醒；

3）第二用戶可以對第三用戶進行評價，系統(tǒng)將根據(jù)自行設定的評價系統(tǒng)對第三用戶進行優(yōu)先推薦或逐步淘汰。

所述將第一用戶的位置信息及團隊人數(shù)共享給第三用戶，可以由系統(tǒng)根據(jù)路線計劃及當前團隊進度提前一定時間向第三用戶發(fā)出；

所述預設條件可以由第三用戶設置及修改；

例如酒店可以預設當?shù)谌脩暨M入酒店3公里范圍內時再給酒店發(fā)出提醒，這樣酒店既無需提前準備太長時間影響運營效率，又可以在游客到達時馬上提供周到的服務，避免讓游客等待太長影響服務滿意度。

再例如旅游車輛服務，也可以隨時根據(jù)第一用戶的位置及團隊人數(shù)，向游客提供的派車服務，而無需總是指派旅游專車跟團出行，降低車輛利用率，也無形中增加了游客的旅游成本。

對于第三用戶的服務，第二用戶可以進行評價，系統(tǒng)將根據(jù)整體評價結果對第三用戶進行優(yōu)先推薦或逐步淘汰。

當判斷出第一用戶和/或第二用戶出現(xiàn)異常情況時，系統(tǒng)將根據(jù)預設聯(lián)系方式通知第四用戶。其中異常情況包括但不限于：

1）用戶非正常離線，且在一定時間范圍內無應答；

2）多名用戶在一定時間范圍內無應答；用戶位置嚴重偏離個人路線計劃，且在一定時間范圍內無應答。

通過本發(fā)明以上方案，第三用戶可以根據(jù)第一用戶的位置信息，為第二用戶提供快速準確的服務，同時又能保障了第二用戶的隱私權。

圖3、圖4、圖5、圖6為本發(fā)明實施例三的路線計劃的4個終端展示圖。

其中圖3為第一層級路線計劃的終端展示圖，包括：

節(jié)點圖標31，包含從福州出發(fā)時的路線節(jié)點1（即節(jié)點序號為1的路線節(jié)點，下同）,路線節(jié)點2 和返回時的路線節(jié)點18；

節(jié)點圖標32，包含在北京游玩期間的路線節(jié)點3~17；

圖4為出發(fā)時福州區(qū)域范圍內路線節(jié)點的終端展示圖，包括：

節(jié)點圖標41，即路線節(jié)點1；

節(jié)點圖標42，即路線節(jié)點2；

圖5為第一天北京區(qū)域范圍內路線節(jié)點的終端展示圖，包括路線節(jié)點3、4、5、6、7、8；

圖6為圖5的局部放大圖，僅包含第一天北京中心城區(qū)范圍內的路線節(jié)點4、5、6、7、8。

舉個例子來說明路線制作的過程：導游小紅首先在路線計劃制作平臺上添加已預訂的8月10號的機票CA1808，此時系統(tǒng)將查詢機票信息，獲取出發(fā)地點福州長樂國際機場，出發(fā)時間08:15，到達地點北京首都國際機場T3，到達時間11:10。因此系統(tǒng)根據(jù)后臺數(shù)據(jù)或默認設置自動生成路線節(jié)點1和路線節(jié)點2。路線節(jié)點1的節(jié)點類型為必選，節(jié)點位置為119.680508,25.934501，計劃到達時間為7:15，計劃停留時間為1小時，預警時限為30分鐘；路線節(jié)點2的節(jié)點類型為必選，節(jié)點位置為116.620821,40.058507，計劃到達時間為11::30，計劃停留時間為30分鐘，前往方式為飛機，預警時限不設置，組隊方式為導游/領隊帶隊。

接著由于所帶的團大多數(shù)人需要從五一廣場出發(fā)，旅游公司也安排了專車接送到機場，因此導游小紅需要增加一個路線節(jié)點。她打開電子地圖后，搜索到五一廣場，然后在圖中五一廣場東側選取并創(chuàng)建了一個路線節(jié)點，節(jié)點位置為119.315806,26.081523。此時由于新增的路線節(jié)點排位為1，系統(tǒng)自動設置為路線節(jié)點1（見圖4的41），因此原路線節(jié)點1和路線節(jié)點2自動調整為路線節(jié)點2（見圖4的42）和路線節(jié)點3（見圖5的51）。由于是乘專車前往機場，小紅又把路線節(jié)點2的前往方式設為駕車。系統(tǒng)由此計算出從路線節(jié)點1到路線節(jié)點2的用時為50分鐘，自動地將路線節(jié)點1的預計到達時間設為6:15(系統(tǒng)自動給出10分鐘余量)。導游小紅考慮到集合可能會有人遲到，手動地把預計到達時間(相當于集合時間)設為6:00，預計停留時間為15分鐘，前往方式不設置，預警時間為15分鐘，組隊方式為自由行。同時由于并非所有人都乘坐機場專車，節(jié)點類型設為可選節(jié)點。

同樣地，導游小紅也根據(jù)第一天在北京的游玩安排（北京國際飯店->故宮天安門->天壇->王府井->北京國際飯店），添加了路線節(jié)點4~8。其中路線節(jié)點4和路線節(jié)點8為同一個地理位置（北京國際飯店），路線展示時合并在一個組節(jié)點圖標中，見圖5和圖6，各路線節(jié)點的具體設置如下：

路線節(jié)點4，可選節(jié)點，節(jié)點位置為116.433725,39.916347（北京國際飯店西門），預計達到時間12:30，預計停留1小時；

路線節(jié)點5，可選節(jié)點，節(jié)點位置為116.403781,39.917903（故宮），預計達到時間13:50，預計停留2.5小時；

路線節(jié)點6，可選節(jié)點，節(jié)點位置為116.418865,39.894206（天壇北門），預計達到時間16:15，預計停留1小時；

路線節(jié)點7，可選節(jié)點，節(jié)點位置為116.417966,39.91673（王府井），預計達到時間17:10，預計停留1小時；

以上路線節(jié)點4~8的節(jié)點類型均為可選節(jié)點，預警時間默認為10分鐘，出行方式不設置。

至此，導游小紅完成了團隊路線計劃的制作?？梢钥吹剑?路線計劃中各路線節(jié)點的位置和預計到達時間（即集合時間）都是非常具體的。到了現(xiàn)場時，節(jié)點位置又能根據(jù)導游位置動態(tài)調整，滿足現(xiàn)場多變的需求。再結合整個路線計劃將實時同步給每個游客的移動終端，包括當前導游(隊伍)的位置/行進進度以及可能發(fā)生的變動游客都一清二楚，游客也就能放心地根據(jù)自己意愿在允許的范圍內自由地安排個人的游玩路線。

下面具體地以游客小明來說簡單說明路線計劃的應用： 小明參加了此次北京游，由于他住在福州長樂市區(qū)，考慮到從長樂到五一廣場集合還不如直接去機場快，所以小明把團隊路線計劃做了修改，刪除（/關閉）可選的路線節(jié)點1，同時修改路線節(jié)點2的前往方式為駕車。到了8月10早上，小明不需要向大多人一樣5:45（6點減去15分鐘預警時間）前甚至更早起床，否則就會收到系統(tǒng)的提醒或預警。由于系統(tǒng)計算到從小明家到機場的時間只需要20分鐘，因此他只需要在7:15-30分鐘(預警時間)-20分鐘(路程時間)=6:25前出發(fā)即可，最遲在7:15-20分鐘(路程時間)=6:55前出發(fā)就不會觸發(fā)預警。

到了長樂國際機場國內出發(fā)大廳，小明通過APP清楚地看到導游正在趕往機場的路上，預計7:05到達，于是安心地玩起手機游戲等待隊伍。7:07分導游和隊伍也進入了國內出發(fā)大廳，此時節(jié)點位置已經(jīng)動態(tài)地和導游位置一致，其他單獨前往機場的游客也開始往節(jié)點位置（導游位置）集合。大家在導游的引導下領取登機牌隨后登上了前往北京的CA1808航班。

到了北京首都國際機場，當導游小紅再次開啟手機，北京當?shù)氐穆糜螌＼囁緳C就收到了隊伍到達的提醒信息，同時，根據(jù)導游小紅的實時位置，司機很快地到達隊伍準確的集合點，接送大家前往北京國際飯店。第一天行程，小明除了會和大家一起去天安門、故宮，其余景點他不想去了，而是想獨自感受北京胡同的文化沉淀。他之前已經(jīng)修改了團隊路線計劃，關閉了天壇、王府井的路線節(jié)點，添加了南鑼鼓巷、煙袋斜街、帽兒胡同等路線節(jié)點。他提交個人路線計劃時，系統(tǒng)確認無需導游同意，且他的個人路線計劃不會與團隊路線計劃沖突，于是予以保存生效。不過根據(jù)團隊導游路線的屬性設置，小明的個人路線計劃導游小紅時可以查看的，這點小明也明確知曉 。就這樣，小明在導游許可的范圍內，開始了自己的自由行。

可以看到，所述一種出行路線智能管理方法，借助精確的定位技術及團隊路線與個人路線的靈活設置，在不增加游客操作要求情況下(因為大多數(shù)人可以按照團隊計劃活動)，實現(xiàn)多人的路線同步，為游客提供具體周到的提醒服務，讓游客在獲得跟團的優(yōu)質服務的同時，也能享受個性的自由行樂趣。 而這恰恰是現(xiàn)有技術無法提供的。

當然，在上述示例中，游客小明遇到一個讓他有些無奈的問題：由于小明選擇放棄天壇游，那么團隊提供的天壇門票就浪費了。這種情況在當前是普遍存在的，例如酒店預訂、門票、消費券等，通常對退票都有限制，尤其是以團隊預訂的方式，更無法以單人方式退票，或者需要承擔一定金額的退票費用。 為了更好地保護游客利益，又不損害商家利益，本發(fā)明還提供了一種基于多級匹配的服務類商品交換方法。

圖7為本發(fā)明實施例四的一種基于多級匹配的服務類商品交換方法流程圖，包括以下步驟：

步驟S701, 用戶提交附帶時間范圍屬性和/或地理位置屬性的服務類商品交換請求，以及提出附帶時間范圍和/或地理位置需求的交換條件；

所述用戶提交附帶時間范圍屬性和/或地理位置屬性的服務類商品交換請求，以及提出附帶時間范圍和/或地理位置需求的交換條件步驟包括：

1） 用戶登陸交易平臺；

2） 輸入商品消費碼；

3） 系統(tǒng)根據(jù)商品消費碼獲取包含服務期限、服務地點的商品信息，以及確認商品變更的交易授權；

4） 用戶輸入交互條件；

5） 提交商品交換請求。

所述商品消費碼是用戶進行商品消費時提交給商家的憑證，包括但不限于：條形碼、二維碼、消費碼、驗證號、團購號；

步驟2)中如果商品消費碼不具有唯一性時（例如有些商家提供的消費碼只是在商家內部唯一），應當追加輸入/選擇商戶標識號。

所述商品信息包括但不限于：商戶標識號、商品內容、訂購價格、有效期、服務地點或網(wǎng)點；

所述商品交換條件包括但不限于：商品內容/商品規(guī)格、消費時間、消費地點；

當然，在用戶沒有具體商品需求時，可以由用戶或系統(tǒng)給出商品價格范圍作為交換條件，此時用戶相當于進行寄售。

步驟S702, 根據(jù)交換條件進行多級搜索，獲得滿足匹配條件的閉環(huán)交易鏈；

所述根據(jù)交換條件進行多級搜索，獲得滿足匹配條件的閉環(huán)交易鏈，即對2個及2個以上用戶的商品進行交換匹配，使得每個用戶的需求可以被滿足同時自己的商品又能滿足其他用戶的需求。例如A用戶的商品滿足B用戶需求，B用戶的商品滿足C用戶的需求，C用戶的商品滿足A用戶的需求，這樣就構成了A->B->C->A的閉環(huán)交易鏈。

通過多級搜索匹配，可以使得商品交換并不限于兩個人之間的商品互換，大大提高了商品交換/的成功率。

進一步的，當商品無法進行等價交換時，系統(tǒng)計算出交易差額，并向商品價值低的交易一方發(fā)起付費請求。

更進一步的，當用戶的商品滿足他人需求，但用戶提出的需求暫時無法獲得時，獲得經(jīng)用戶允許，系統(tǒng)可以以等價金額進行臨時記賬，后續(xù)交易滿足時再予以兌換。

步驟S703，向交易鏈上的交易用戶發(fā)出交易確認請求；

如果用戶設置了系統(tǒng)自動確認且用戶交換需求完全滿足時，可以跳過本步驟；

當商品無法進行等價交換時，商品價值低的交易一方需支付差額后才能完成交易確認。

步驟S704, 在獲得交易用戶的確認信息后，將交易商品的現(xiàn)有商品消費碼注銷，生成新的商品消費碼發(fā)給獲得商品所有權的對應交易用戶；

在獲得交易鏈上的所有交易用戶的確認信息后，系統(tǒng)開始將所涉及現(xiàn)有商品消費碼進行注銷，同時生成新的商品消費碼發(fā)給新的商品所有權擁有者。這樣，舊的商品消費碼就無法再使用了。

所述一種基于多級匹配的服務類商品交換方法，在用戶提交附帶時間范圍屬性和/或地理位置屬性的服務類商品交換請求，以及提出附帶時間范圍和/或地理位置需求的交換條件步驟之前，還可以包括：

與商家系統(tǒng)對接，獲得所接入服務類商品的查詢權限及交易權限；

也就是說，通過與商家或第三方服務商的合作，讓所提供的服務類商品都能以商品消費碼的方式下發(fā)給用戶。

所述一種基于多級匹配的服務類商品交換方法， 還可以進一步包括：

1)對于同一商品的多商品消費碼，系統(tǒng)自動根據(jù)服務期限的到期快慢順序進行匹配；

通過這樣的設定，可以在滿足當前用戶需求情況下，最大限度提高后續(xù)匹配的成功率；

2)系統(tǒng)在商品退訂期限前，自動向商家發(fā)起退票請求，以及在完成退票操作后，將退訂信息推送給用戶。

通過這樣的設定，確保用戶應有的經(jīng)濟利益，使得用戶可以放心地在交易平臺交換商品。

通過上述發(fā)明方法，當游客行程發(fā)生變化時，就可以通過交換的方式獲取各自所需的服務資源。即使是采用商品消費碼交付且無法退訂的情形，也能最大限度減少游客的經(jīng)濟損失,為旅游服務共享及游客的自由出行提供基礎保障。具體將在下文實施例五中予以示例說明。

圖8為本發(fā)明實施例五的一種基于路線計劃的智能出行的方法流程圖，包括以下步驟：

步驟S801，第一用戶創(chuàng)建即時通訊群，設置群屬性及添加團隊路線計劃；

所述群屬性包括但不限于：群名稱、群編號、成員清單；

其中成員清單可以在本步驟中由第一用戶通過導入聯(lián)系人的方式添加，也可以在下一步驟中由第二用戶加入群時自動添加；

步驟S802，第二用戶加入群，設置個人偏好設置及根據(jù)需要設置個人路線計劃；

如果步驟801中第一用戶未添加第二用戶，則第二用戶可以通過輸入群名稱或群編號或掃描群二維碼的方式發(fā)出入群請求，經(jīng)第一用戶同意后加入群；

第二用戶加入群后，即可查看團隊路線計劃，同時也意味了同意接受團隊路線計劃；

第二用戶隨時可以修改團隊路線計劃，生成個人路線計劃；

步驟S803，系統(tǒng)根據(jù)團隊路線計劃的時間范圍進行群信息共享；

在旅游出行期間及出行前后一段時間(通常為前后3天)范圍內，第二用戶才能在群內發(fā)言，進行交流及信息共享。而在此期間外，只有第一用戶能在群內留言。

步驟S804，根據(jù)路線計劃進行出行路線智能管理；

本步驟的內容已在前文提出的一種出行路線智能管理方法中詳細說明，在此不再贅述。唯一需要補充說明的是，當?shù)诙脩魝€人路線計劃的組隊方式設為動態(tài)導游時，系統(tǒng)還將為第二用戶推薦同在一個路線的其它旅游團隊的導游或領隊，作為第一用戶對第二用戶提供導游服務。例如小明在游玩南鑼鼓巷、煙袋斜街、帽兒胡同時，顯然和原帶團的第一用戶不在一起了，但系統(tǒng)可以把在同一路線上的別的旅游團的導游作為第一用戶顯示給小明。這樣，當小明需要導游服務時，即可就近呼叫該“臨時”導游。

進一步的，一種基于路線計劃的智能出行方法，還可以包括：

1）以團體方式訂購的旅游產(chǎn)品可以分發(fā)到個人，并支持進行基于多級匹配的服務類商品交換；

所述以團體方式訂購的旅游產(chǎn)品可以分發(fā)到個人，并支持進行基于多級匹配的服務類商品交換，具體步驟包括：

a)團隊預訂的旅游產(chǎn)品在系統(tǒng)后臺生成對應數(shù)量的商品消費碼；

b)第二用戶可以申請歸屬個人的商品消費碼下發(fā)到個人；以及

c)根據(jù)需要可將商品消費碼對外進行基于多級匹配的服務類商品交換；

例如在上文示例的北京旅游活動中，游客小明可以申請?zhí)靿T票的商品消費碼下發(fā)給自己，然后在交易平臺上提出其它旅游產(chǎn)品需求進行交換；

又例如小明的同學家在北京，知道小明到北京旅游，非得要求他到家里做客，一醉方休。小明只得臨時修改個人路線計劃，并且也不再回北京國際飯店住宿。這樣，他又申請下發(fā)個人當晚北京國際飯店的商品消費碼，然后在交易平臺上提出換取福州溫泉門票，準備回福州再消費；

可以看到，通過商品消費碼，可以把團體消費項目拆分為個人消費項目，然后再通過基于多級匹配的服務類商品交換方法，實現(xiàn)消費項目或消費地點/消費時間的變更，使得跟團旅游不再是跟著導游走，“身不由己”的；

2)第一用戶基于照片或短視頻的進行景點解說及游記制作；

所述第一用戶基于照片或短視頻的進行景點解說及游記制作分享，具體步驟包括：

a)第二用戶提交景點照片或短視頻，同時附加位置信息；

b)第一用戶基于所述景點照片或短視頻及附加的位置信息進行景點解說;

c)第二用戶對景點照片或短視頻進行評價/評級；即其他游客也能對照片及短視頻進行評價評級，例如點贊等；

d)旅游結束后，第一用戶或系統(tǒng)根據(jù)篩選規(guī)則篩選出景點照片或短視頻；

e)第二用戶選擇一個經(jīng)篩選的景點照片或短視頻進行留言；

f)第一用戶將景點照片或短視頻結合解說內容和第二用戶的留言生成電子版游記。

例如游客小明在游故宮時，和導游不在一起。按現(xiàn)有技術，小明只能通過的電子導游APP或景區(qū)導游裝置來獲得景點介紹信息。然而電子導游APP等是沒辦法進行交互的，小明想了解的內容也不是哪些大眾化的景點知識，而且自己看到一處景象想到有趣的問題。此時，小明可以把這個景象拍下來，然后通過即時通訊群共享出來，同時問詢導游。導游小紅看到游客小明的照片后，隨即用語音回答了小明的問題。其他游客也紛紛對這個景象發(fā)表評論或點贊。旅游結束后，小紅把過程中這些有趣的照片整理出來，讓大家每人再留一句話在某一張經(jīng)篩選的照片上。最后，導游小紅把這次旅游過程有趣的內容生成了電子游記，共享給所有游客，作為這次北京旅游的美好回憶。

圖9為本發(fā)明實施例六的一種基于路線計劃的智能出行的系統(tǒng)結構框圖，包括：

包括服務器91和移動終端92，移動終端92通過移動通訊網(wǎng)絡與服務器91進行信息交互；

所述服務器91包括：

即時通訊服務模塊911，用于實現(xiàn)多個移動客戶端之間的即時通訊，包括創(chuàng)建對話/聊天群，進行信息推送；

路線管理服務模塊912，包括位置服務單元，路線查詢服務單元，路線制作服務單元，路線預警服務單元，路線導航服務單元。

其中位置服務單元9121用于通過衛(wèi)星定位信息或位置服務獲取用戶的地理位置信息；

路線制作服務單元9122用于進行路線計劃的創(chuàng)建、修改、發(fā)布及查詢；

路線預警服務單元9123用于依據(jù)路線計劃對用戶提醒、預警；

路線導航服務單元9124用于依據(jù)路線計劃或用戶設定目標進行路線導航；

地理信息模塊913，用于提供平臺所需地理信息數(shù)據(jù)；

所述移動終端92包括：

即時通訊模塊921，用于提供即時通訊交互界面，提交或顯示即時通訊信息；

路線管理模塊922，用于進行路線查找、路線制作、路線預警、路線導航的交互，提交用戶指令給服務器92及獲得交互結果信息；

衛(wèi)星定位模塊923，用于通過衛(wèi)星定位芯片獲得衛(wèi)星定位信息，并上報給服務器。

所述服務器91可以進一步包括：

商品交換服務模塊，包括第三方商家接入單元，交易管理單元，多級撮合單元，商品消費碼管理單元；

其中第三方商家接入單元用于與提供服務類商品的商家交易系統(tǒng)對接，進行商品查詢及后臺交易；

交易管理單元，用于交易(交換)請求的生成及交易流程管理；

多級撮合單元，用于進行交易(交換)請求的多級撮合匹配；

商品消費碼管理單元，用于商品消費碼的注銷、生成及管理。

所述移動終端92可以進一步包括：

商品交換模塊，用于提供商品交換的交互界面，提交交易請求及顯示交易信息。

繼續(xù)以上文的北京旅游為例，對系統(tǒng)運作進行簡單的說明。在收到A公司的旅游預定后，導游小紅首先通過移動終端92的即時通訊模塊921提交建群申請，服務器91的即時通訊服務模塊911接收到指令后創(chuàng)建即時通訊群，并返回信息到移動終端92的即時通訊模塊921中顯示。然后，導游小紅通過即時通訊模塊921添加了A公司的組織人老陳作為領隊，以便由老陳來添加其他成員。接著，小紅打開路線管理模塊922，在服務器91的路線管理服務模塊912的后臺支持下，查找到熱門的北京旅游路線計劃，在其基礎上修改創(chuàng)建本次北京旅游的團隊路線計劃，作為所創(chuàng)建的即時通訊群的配套路線計劃。另一方面，領隊老陳也在移動終端92上通過即時通訊模塊921提交添加群成員的申請到服務器92的即時通訊服務模塊911，將其他成員添加到即時通訊群里。

出團期間，服務器91的路線管理服務模塊912通過各移動終端92的衛(wèi)星定位模塊獲得的衛(wèi)星定位信息后，在路線管理服務模塊912的位置服務單元9121、路線預警服務單元9123、路線導航服務單元9124后臺控制下，對所有用戶進行基于路線計劃的智能管理。

以上過程描述只是對各模塊間的信息傳遞作簡化地闡述，實際應用時各模塊間的信息傳遞更為復雜頻繁，在此不再說明。

以上所述，僅是為了說明本發(fā)明的內容所列舉的部分實施例，并非對本發(fā)明作任何形式上的限制。本領域技術人員在不脫離本發(fā)明技術方案范圍內，當可利用上述揭示的技術內容做出些許更動或修飾為等同變化的等效實施例。凡未脫離本發(fā)明技術方案內容，依據(jù)本發(fā)明的技術實質對以上實施例所作的任何簡單修改、等同變化與修飾，均仍屬于本發(fā)明技術方案的范圍內。