關於全國poi興趣點數據


1、POI數據介紹

 POI是“Point of Interest”的縮寫,中文可以翻譯為“興趣點”。POI數據會包含各種信息,如前面提到的名稱、別名等信息,可以將這些信息看成一個個的標簽(tag),而分類是其中最重要的一個tag,在OSM中 “An OSM element should represent a single on-the-ground feature once and only once”作為一個基本規則,一般來說POI數據可以進行一級和二級分類,每個分類都有對應的行業和名稱,這些分類在數據采集和應用中都是十分重要的信息,通常在OSM展示中依靠分類進行信息展示,而名稱、地址、坐標在OSM展示和檢索作為基礎信息來使用。而興趣是一個非常主觀性非常強的詞語,在特定的情況下例如用戶想發一封電子郵件的時候,電話遠遠沒有郵箱地址有趣。所以POI在不同使用場景下,對POI數據有不同需求,當一個POI數據平台提供一系列接口和數據輸出的時候必須考慮不同場景下用戶的需求和數據特點。

  通常我們將POI的信息划分為基礎信息和詳情信息,隨着社會的發展,LBS、O2O服務相繼出現,用戶的需求也在不斷演化:

    以前我們在網上搜索全聚德在北京有幾個店,那個離自己最近,如何換乘地鐵或公交,這時候地圖是用來尋址規划路線的;

    現在我們直接搜索某個區域有什么店鋪,那個評分更高服務更好,招牌菜是否符合口味,甚至直接團購下單,現在地圖是為了生活服務的;

  這時候我們發現POI包含的信息演化包含了三個部分:

    1. 基礎信息:名稱、地址、坐標、別名、電話、分類等

    2. 詳情信息:評分、菜單、價格、評論、團購信息、營業時間、圖片等垂直行業信息。

    3. 挖掘信息:營業狀態、可信度等挖掘產生的數據

    有了第1部分我們可以提供基礎的檢索服務,可以根據用戶輸入的名稱或者當前位置檢索到需要的特定類型的POI信息,完成用戶的搜索需求;而第2部分可以優化一定場景下的用戶體驗或者提供高附加值的服務;第3部分數據優化用戶體驗,避免用戶流失。    

  當然,在地圖上POI可能不是一個點,而地圖上點也未必是一個POI,如一個步行街、一片海灘又或者兩條鐵路的交叉口。通常人們會將步行街或者海灘這些區域簡化為一個點也就是POI,而鐵路的交叉口在地圖上可能呈現一個點,可實際上並非一個POI或者有價值的POI,因此,地圖上的點和POI實際並非一個概念,雖然我們通常將POI映射為一個點。

  地圖數據的最終願景是復刻這個世界,而POI則是這個願景的基石。

2、POI數據處理流程

POI數據根據數據源不同,接入數據獲取的信息會有所不同,但無非是基礎數據和詳情數據。

  數據接入后處理流程也可以統一為: 

    數據接入 => 數據標准化 => 數據判重 => 數據融合 => 數據發布 => 持續更新

    不同的數據在步驟中操作可能會有所差異,但是基本上都會遵循上述步驟,下面將逐一介紹每個步驟

    1. 數據接入:根據數據來源的不同接入方式也是多種多樣,如圖商的數據最為標准,通常為mid/mif的文件提供,此時轉化為流程可處理的數據格式即可;互聯網抓取的數據內容豐富但是遵循的規范多種多樣,此時進行初步判斷是否符合接入的條件以向下流轉;合作方的數據相對標准,但業務側重不同,而通常合作方的數據需要進行反饋數據接入時做好對賬和反饋查詢接口;ugc數據相對較少但是需要給與及時處理和反饋...。不同數據源數據重要性和數量級會所有不同,針對數據較大但是重要性相對較低的數據需要做好數據准入驗證;對數據量少、但是重要的數據要有通用的對賬和反饋機制,這會減少后期業務展開時的工作量。

    2. 數據標准化:數據標准化一般包含三部分內容:1)字段對齊,對於某些數據源相同內容字段名稱可能不一致,此時將其轉換為統一的名稱和路徑;計算分類、狀態等字段值補全到數據中;2)數據正確性驗證,例如根據坐標校驗地址的省市區划是否一致,3)剔除部分分類的數據或者觸發黑名單數據,如涉黑涉恐等違法數據類型。標准化的過程不復雜但會隨着接入數據源的增加而變得繁瑣,因此一個健壯的可配置的標准化服務可以使得后續工作事半功倍。

    3. 數據判重:數據源接入后如何判斷新接入數據是否與原有的數據重復,也就說新接入的了某個數據源的POI如果當前已經有了這個POI那么應該將新增的POI與原有的POI融合並更新原有的POI信息,如果當前沒有該POI,那么應使用新接入的POI獨立新增一個POI數據到自己的系統。判重流程比較負責,在這里暫不詳述,簡單說是將已有的POI的關鍵信息建立倒排索引,根據新增的POI的信息查詢倒排索引,根據倒排索引返回的POI列表計算相似度,如果有相似度達到閾值的那么判斷為重復。

    4. 數據融合:是將不同來源標識相同的POI的數據融合為一條數據,這條數據在各個源中的數據選擇最可靠的基礎數據,和不同業務的詳情數生成一條POI。這條POI可以滿足不同的業務需求。

    5. 數據發布:數據發布指數據融合得到的POI數據推送到各個業務方進行線上操作。同數據接入一樣,發布對接多個業務方,根據不同的業務進行數據適配和校驗,一個通用的發布模式是十分必要。

    6. 數據更新:數據生成是一個持續交付過程,數據不斷采集和融合,數據也會不斷更新,數據發布的交付也是一個持續的過程。

3、POI數據存儲

POI數據存儲是指在整個數據處理過程產生的結果數據和中間數據的記錄和存儲,在這個過程中不同的數據存儲的目的也不盡相同。

  為了描述方便,我們這里將數據接入的poI稱為pp,融合后產生的結果稱為poi

  按照目的不同,我們將數據存儲分為若干類:

  1. 數據輸出:計算流程的結果,也就是POI數據,是最重要的數據。

  2. 數據計算:計算流程的中間結果,例如每個已接入的pp數據的規范化輸出(我們輸出的POI是若干判定為相同pp融合產生的POI,那么每個接入pp規范化的結果在每次融合的時候都會用到)

  3. 歷史追蹤:或者說問題排查或者數據變更分析,歷史POI的歷史是如何變更的,如在高德地圖搜索古北水鎮,返回結果包含了古北水鎮的位置,電話,售票信息以及評論,這些數據可能來自多個數據源,我們假設古北水鎮的位置信息來源於高德自己的數據生產,售票信息來自飛豬等平台數據,評論來自大眾點評等平台,而這三個源的pp分別接入,那么該poi的數據就會由最開始的基礎信息,逐步增加售票信息和評論信息,該數據與關聯的原始poi數據是對應的,以此來發現分析問題。

  不同目的的數據,可能存儲的數據是相同的,例如poi,數據輸出給用戶或者業務方的融合后結果數據,而此數據在數據計算過程中也會用到,在歷史追蹤過程中對poi的變化也就是記錄每次poi融合的結果數據。對於數據輸出根據輸出方式不同,存儲方式也會不同,如用戶需要實時查詢那么比較適合的方式應該是kv數據庫,當然關系型數據庫滿足性能情況下也是可以的,但是當數據需要批量輸出時候,尤其是涉及到全國poi數據時候(當期高德、百度地圖、騰訊地圖的poi總量均達到7千萬左右)數據庫顯然不能滿足需求,這個時候最好通過hive進行數據輸出;而歷史關系數據因為需要根據id查詢多個歷史版本,這時候比較好的方式應該是hbase或者高性價比的kv數據庫。

  在這個過程中,數據輸出和數據計算是必須滿足穩定且高效的性能要求,是最緊迫的需求,相反的歷史追蹤功能,不會影響當前線上服務,不那么緊迫,而其數據存儲量遠遠超過1,2需求,因此可以犧牲部分性能要求去實現。

從大學到研究生,也算是從事GIS行業7年了,這是這7年來積累的全國POI興趣點數據,數據量還是挺大的,有從事GIS行業的同學可以一起交流討論。

4、POI數據發布和保障

POI數據發布:

     數據發布方式有多種,具體方式和需求由業務決定,發布方式主要分為兩類,一類是通過數據打包整體發布,一類是通過api請求逐條調用。

     1. 打包整體發布:通過提取歸檔數據,根據業務需求的模板進行數據提取轉換,將數據以文件形式推送到需求端,該方式適用於有獨立處理數據並提供業務服務的情況;

     2. 通過api請求:該方式通過服務調用請求數據,以數據id進行數據查詢,或者類似地圖查詢以關鍵詞進行數據匹配。

  第一種方式數據發布量大,如果發布全國的POI數據那么將是超過五千萬的數據量,數據發布和加載時間將是一個較長的過程,這決定了打包發布不會是一個實時的數據方案,該方案適用於數據量大,但是實時性不強的情況

  第二種方案,實時性強,但是數據量因為服務請求的原因,受限於服務qps限制數據量無法達到較大的量級,即便qps達到滿足較短時間內同步全量數據,也難以保證數據的全量更新,這種方式提供實時的數據查詢,無需進行數據全量的保證,只需保證服務請求數據准確性和實時性。

  兩種發布方案雖然方式不同,但是同為發布需要滿足發布的基本需求:1. 正確性   2. 實時性   

  1. 正確性,包含兩個因素,單條數據的准確性,數據整體的正確性

    單條數據的准確性可以通過字段校驗來提供保證,字段校驗是針對字段類型和值范圍的校驗,對每條數據進行字段校驗可以保證一定的數據正確性

    數據整體正確性,可以通過數據差分來進行保證,對上一次發布的數據進行數據比對:數據上線和下線數據量的比較,在線數據更新字段變更值的比較,通過字段變化率的比較可以確定新的數據和歷史數據變化情況可以確定數據沒有因為策略異常或者服務異常造成的數據錯誤。當數據差異率超過閾值的時候需要進行人工介入,確定數據變更是否符合策略預期。

  2. 實時性,打包發布只要保證數據發布成功可以保證實時性,api請求需要保證數據同步正常服務穩定

5、POI數據校驗 

POI數據校驗是POI數據正確性的保證,而針對結果校驗是數據發布正確性的最后一道保障,所以對數據校驗需要在多個緯度進行,力求POI的正確性。

  數據變更主要分為狀態變更、關鍵字段變更以及詳情字段變更。其中狀態變更影響最大,可以造成線上POI的上下線狀態改變,而基礎字段和詳情字段則會影響業務的正確性。須知數據變更引起的原因有多種,基本可以分為3類:

      1. 數據來源變更   

      2. 處理策略變更   

      3. 系統性錯誤

  1.  數據來源變更,數據新增、下線接入來源或者既有來源的大量數據變更都可能造成POI數據變化;

  2. 處理策略變更,處理過程中針對狀態或者關鍵字段的策略變化會引起數據變化,例如新增一個名稱過濾策略,如果名稱不合法則將數據直接過濾下線,如果這個策略影響面較大會造成數據的大面積下線;而如果名稱策略只是將不合法字符屏蔽那么數據會上線,而名字可能和實際POI有出入。

  3.  系統性錯誤則是指在處理過程中bug造成的數據錯誤,這種錯誤影響的數據會比較集中造成的數據面影響會比較大,但是也最容易發現,只需比較新的數據結果與上一版本數據是否變更,變更率是否有明顯變化則可以迅速預警數據系統性錯誤。

  數據校驗:

    字段校驗: POI數據字段的值類型,取值范圍的校驗,實現過程可以將規則寫入配置,當規則有變化時可以通過修改配置實現與代碼分離

    規則校驗:對數據整體設置校驗規則,如某個字段必須有值以及和某個字段有校驗規則,某個字段有值率的占比,當不符合規則時則進行攔截

    變更校驗:比較本次發布數據和上一次發布數據的變更,包括數據新增和下線,以及兩次發布同時存在的數據字段的變更,當沒有變更時名稱、地址、坐標作為關鍵字段其變化率應少於1‰,如果變更多余該值則應該確認數據來源、策略是否有變更,且變更結果符合預期。

  因此數據校驗和策略、數據接入應進行聯動;當數據接入有變化時如數據在一段時間內接入數據變化可能引起的POI集合變化;數據策略變更引起的結果變化以及預期的結果應有告知的流程,並與校驗的結果互相印證;當變更預期與預先設計不符時,應該引入人工評測,評估本次數據變更是否對數據有積極影響,判斷是否上線。

6、POI數據變更校驗

變更校驗:比較本次發布數據和上一次發布數據的變更,包括數據新增和下線,以及兩次發布同時存在的數據字段的變更,當沒有變更時名稱、地址、坐標作為關鍵字段其變化率應少於1‰,如果變更多余該值則應該確認數據來源、策略是否有變更,且變更結果符合預期。

  變化維度:數值變更(變更范圍);字段存續變更;POI存續變更

  變化體現:數據變更數據值大小,如果非數值類型可能體現為數據長短變化;

       字段存續是變更是指數據POI某個字段可能因為某種原因缺失,可能是正常也可能是因為字段產生過程數據丟失;

       POI存續是指poi的新增或者下線在兩次發布中出現新增和丟失的情況;

  校驗方式:

數值變更:數值不同數據校驗方式不同,如經緯度字段,因為經緯度經度問題,其值每次取值會有不同,如果單純因為字段取值不同進行判定則可能造成誤報,按照經緯度取值經可以截取小數點后五位進行判定,或者將前后版本經緯度進行距離計算,如果距離在30米范圍內可以認為位置沒有變化;如果字段值為字段或者數組等結構體,甚至包含二級、三級的鍵值的時候那么比對將相對麻煩,尤其是結構體可能將值轉為string類型時可能無法以通用的手段進行比較。此時可以根據字段配置表進行數據比較,比對到相對字段配置表指定的數據層級,將字段大小變更納入比對策略。
字段存續變更:根據配置字段比較兩個版本字段是否存在
POI新增減少,只比POIid和上一版本的新增或者減少即可
  報警策略:三個校驗的關鍵在於報警閾值的設定,根據多個版本的變化數據進行比較,獲得數據報警閾值的。

  相應報警數據還需要報警后的問題分析,如數據變更范圍,數據類型,數據變化較大的數據地理區域,數據分類,數據源組成方便問題定位分析

7、突發事件的下POI數據應對策略

近日來武漢新型肺炎對地圖行業的及時應對提出了考驗,大量和疫情的POI需要上線,很多服務行業、電影院,景區等POI暫停營業。這些信息在地圖上顯示和POI實際狀態是否相同,能否真實的反映現實世界,是否能為用戶提供有價值的信息。

  相關的POI信息變化可以分為三類:

    1.  新增的醫療的地點,如發熱門診

    2. 停止運營的交通設施,如地鐵、長途客運、火車站點

    3. 停止營業的景點、餐飲、電影院等娛樂場所

  數據搜集方式有多種,其中較為簡單有效的是人工運營,新增醫療地點,發熱門診的信息可以有運營人員關注官方發布的信息,微博以及各個重點醫院的公告信息,獲取第1類的信息,這些信息數據量相對較小,且相對重要,需要人工運營確認,此類信息人工運營較為合適。第二類信息和第一類相似,但是具體信息則相對負責,如長途客運停運公告,可能涉及線路只有幾條,但是每條線路涉及的站點則十倍二十倍增長。第三類則數據量相對較大,且分布廣泛,不能簡單按照時間類型進行處理,需要實時抓取商戶公告信息,這需要多個渠道獲取信息的能力,如公眾號、企業新聞公告,和poi關聯處理,不過這需要研發預先開發信息獲取渠道、以及相應的處理上線能力。第一類和第二類數據量級和重要性相似,但是信息不同,第一類需要匹配相應的坐標、名稱,第二類只是狀態變更;在數據變化方面第二類和第三類相同。

  數據上線方式,第一類則需要數據動態新增或者增量更新,第二類可由人工操作后動態更新,第三類可以動態新增,但是沒有信息獲取渠道和處理流程的時候手動操作較為復雜且數較大,可以由客戶端新增策略進行話術提示。但是根據策略和分類進行批量處理較為籠統,需要用戶確認商戶狀態對用戶體驗較差。最好的處理方法是增強信息獲取渠道和處理上線能力。

 交流學習QQ:1148212080


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM