本申請涉及GIS應用技術(shù)領域,特別地,涉及一種基于GIS拓撲分析的地址匹配區(qū)域塊方法和系統(tǒng)。
背景技術(shù):
基于GIS系統(tǒng)的區(qū)域劃分和訂單分揀技術(shù)是GIS應用之一,目前絕大多數(shù)物流配送企業(yè)多采用人工地址庫自動分揀技術(shù),其中:地址庫采用人工維護的方式,需要手工錄入業(yè)務區(qū)劃的四至(東、南、西、北)及樓宇、大廈、街道地址,手工更新維護地址庫;訂單劃分則通過訂單地址與人工地址庫進行關(guān)鍵詞匹配實現(xiàn),匹配成功的訂單才被劃分到對應的業(yè)務區(qū)劃,并歸屬給對應的派件網(wǎng)點及派件人;因此存在操作時間長,效率低,錯誤率高等問題。
技術(shù)實現(xiàn)要素:
本申請?zhí)峁┮环N基于GIS拓撲分析的地址匹配區(qū)域塊方法和系統(tǒng),用于解決現(xiàn)有分單系統(tǒng)效率低下、錯誤率高的問題。
本申請公開的一種基于GIS拓撲分析的地址匹配區(qū)域塊方法,在服務端,所述方法包括:接收客戶端提交的訂單地址;利用后臺地址解析算法對所述訂單地址進行解析;從后臺地址庫查詢獲得解析后的訂單地址對應的空間位置信息,根據(jù)所述空間位置信息將所述訂單地址匹配到電子地圖上;根據(jù)GIS拓撲關(guān)系確定所述訂單地址對應的業(yè)務區(qū)域塊,將所述業(yè)務區(qū)域塊的信息返回至客戶端。
優(yōu)選的,所述利用后臺地址解析算法對所述訂單地址進行解析,具體包括:根據(jù)詞庫對所述訂單地址進行切分,識別出其中的行政區(qū)劃關(guān)鍵詞、道路關(guān)鍵詞、標建關(guān)鍵詞和/或門牌號關(guān)鍵詞;對上述識別出的關(guān)鍵詞進行搜索匹配,并對匹配結(jié)果進行相關(guān)度計算,將相關(guān)度最高的匹配結(jié)果作為解析后的訂單地址。
優(yōu)選的,在通過GIS拓撲關(guān)系確定所述訂單地址對應的業(yè)務區(qū)域塊,將所述業(yè)務區(qū)域塊的區(qū)塊信息返回至客戶端之前還包括:若后臺地址庫中不存在解析后的訂單地址對應的空間位置信息,則提醒用戶手工標注所述訂單地址對應的業(yè)務區(qū)域塊,并將所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系存儲到地址糾錯庫中。
優(yōu)選的,在利用后臺地址解析算法對所述訂單地址進行解析之前,還包括:判斷所述地址糾錯庫中是否保存有該訂單地址的糾錯信息,若是,直接根據(jù)所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系獲得所述業(yè)務區(qū)域塊的信息并返回至客戶端;否則執(zhí)行后續(xù)流程。
優(yōu)選的,所述空間位置信息為所述訂單地址的經(jīng)緯度。
優(yōu)選的,所述業(yè)務區(qū)域塊的信息包括區(qū)塊名稱、區(qū)塊編號、配送網(wǎng)點名稱和/或配送網(wǎng)點的屬性。
優(yōu)選的,所述方法還包括:基于GIS拓撲關(guān)系對業(yè)務區(qū)域塊進行添加、修改、合并和/或拆分操作,將電子地圖劃分成無縫拼接的業(yè)務區(qū)域塊。。
本申請公開的一種基于GIS拓撲分析的地址匹配區(qū)域塊系統(tǒng),包括通過網(wǎng)絡連接的客戶端和服務器,所述服務器具體包括:訂單地址接收模塊,用于接收客戶端提交的訂單地址;訂單地址解析模塊,用于利用后臺地址解析算法對所述訂單地址進行解析;地圖標繪模塊,用于從后臺地址庫查詢獲得解析后的訂單地址對應的空間位置信息,根據(jù)所述空間位置信息將所述訂單地址匹配到電子地圖上;第一分單模塊,用于根據(jù)GIS拓撲關(guān)系確定所述訂單地址對應的業(yè)務區(qū)域塊,將所述業(yè)務區(qū)域塊的信息返回至客戶端。
優(yōu)選的,所述訂單地址解析模塊具體包括:分詞子模塊,用于根據(jù)詞庫對所述訂單地址進行分詞,識別出其中的行政區(qū)劃關(guān)鍵詞、道路關(guān)鍵詞、標建關(guān)鍵詞和/或門牌號關(guān)鍵詞;評分子模塊,用于對分詞子模塊識別出的關(guān)鍵詞進行搜索匹配,并對匹配結(jié)果進行相關(guān)度計算,將相關(guān)度最高的匹配結(jié)果作為解析后的訂單地址。
優(yōu)選的,所述服務器還包括:地址糾錯模塊,用于判斷后臺地址庫中是否存在解析后的訂單地址對應的空間位置信息,若是,則提醒用戶手工標注所述訂單地址對應的業(yè)務區(qū)域塊,并將所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系存儲到地址糾錯庫中;第二分單模塊,用于在利用后臺地址解析算法對所述訂單地址進行解析之前,判斷所述地址糾錯庫中是否保存有該訂單地址的糾錯信息;若是,直接根據(jù)所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系獲得所述業(yè)務區(qū)域塊的信息并返回至客戶端;否則轉(zhuǎn)訂單地址解析模塊、地圖標繪模塊和第一分單模塊進行相應的地址解析、地圖標繪和分單操作。
與現(xiàn)有技術(shù)相比,本申請具有以下優(yōu)點:
本申請優(yōu)選實施例通過對訂單地址進行解析生成訂單地址對應的空間地理位置信息,并將空間地理位置信息基于GIS拓撲關(guān)系與業(yè)務區(qū)域塊進行匹配的方式,實現(xiàn)了對訂單的自動識別分區(qū),并自動分派到相關(guān)的派件網(wǎng)點和派件人,可實現(xiàn)對海量訂單進行批量自動分揀和連續(xù)不斷的分揀,減輕了分揀人員的勞動強度,提高了派單效率,解決了物流等行業(yè)的分揀派單難題,并為企業(yè)節(jié)省了人力成本。
附圖說明
附圖僅用于示出優(yōu)選實施方式的目的,而并不認為是對本申請的限制。而且在整個附圖中,用相同的參考符號表示相同的部件。在附圖中:
圖1為本申請基于GIS拓撲分析的地址匹配區(qū)域塊方法一實施例的流程;
圖2為本申請基于GIS拓撲分析的地址匹配區(qū)域塊系統(tǒng)一實施例的結(jié)構(gòu)示意圖;
圖3為本申請基于GIS拓撲分析的地址匹配區(qū)域塊系統(tǒng)具體實施例的標繪結(jié)果示意圖;
圖4為本申請基于GIS拓撲分析的地址匹配區(qū)域塊系統(tǒng)具體實施例的分單結(jié)果示意圖;
圖5為本申請基于GIS拓撲分析的地址匹配區(qū)域塊系統(tǒng)具體實施例的訂單處理情況分時段匯總結(jié)果示意圖;
圖6為本申請基于GIS拓撲分析的地址匹配區(qū)域塊方法具體實施例的地址匹配度評分模型。
具體實施方式
為使本申請的上述目的、特征和優(yōu)點能夠更加明顯易懂,下面結(jié)合附圖和具體實施方式對本申請作進一步詳細的說明。
在本申請的描述中,需要理解的是,術(shù)語“第一”、“第二”僅用于描述目的,而不能理解為指示或暗示相對重要性或者隱含指明所指示的技術(shù)特征的數(shù)量。由此,限定有“第一”、“第二”的特征可以明示或者隱含地包括一個或者更多個該特征?!岸鄠€”的含義是兩個或兩個以上,除非另有明確具體的限定。術(shù)語“包括”、“包含”及類似術(shù)語應該被理解為是開放性的術(shù)語,即“包括/包含但不限于”。術(shù)語“基于”是“至少部分地基于”。術(shù)語“一實施例”表示“至少一個實施例”;術(shù)語“另一實施例”表示“至少一個另外的實施例”。其他術(shù)語的相關(guān)定義將在下文描述中給出。
參照圖1,示出了本申請基于GIS拓撲分析的地址匹配區(qū)域塊方法一實施例的流程,執(zhí)行所述方法的系統(tǒng)包括通過網(wǎng)絡連接的客戶端和服務器,在服務器端,所述方法包括:
步驟S101:接收客戶端提交的訂單地址;
具體實施時,可以將客戶端提交的訂單地址批量傳入系統(tǒng)進行后續(xù)處理。
步驟S103:利用后臺地址解析算法對所述訂單地址進行解析;
具體實施時,步驟S103可以包括如下分詞、評分和排序的過程:
分詞
根據(jù)詞庫對訂單地址(即中文地址)進行切分和關(guān)鍵詞識別,包括對省、市、區(qū)、縣、鄉(xiāng)鎮(zhèn)等行政區(qū)劃關(guān)鍵詞的識別,以及道路、地標建筑名稱(簡稱標建)和/或門牌號等關(guān)鍵詞的識別。
由于全國的地址樣例較多,所涉及的關(guān)鍵詞信息量太大,在對道路及門牌號的識別則采用相關(guān)正則模式進行匹配,從而實現(xiàn)對道路、標建的識別。
例如:上海市嘉定區(qū)馬陸鎮(zhèn)豐兆路118號上海鵬晨消防器材有限公司
分詞結(jié)果之后將會變?yōu)椋荷虾J?嘉定區(qū)/馬陸鎮(zhèn)/豐兆路/118號/上海鵬晨消防器材有限公司
“上海市/嘉定區(qū)/馬陸鎮(zhèn)”這三個關(guān)鍵詞采用各級行政區(qū)關(guān)鍵詞進行切分,從“豐兆路”開始則使用道路及標建正則模式進行匹配。例如:xx路/大街/大道xx號。
評分:
在對評分進行介紹之前,需要簡要介紹一下地址匹配的過程。實現(xiàn)地址匹配需要做兩部分主要工作,索引與搜索。索引就是將基礎數(shù)據(jù)按照特定的方式打包。地址匹配采用的是倒排索引的方式,即將基礎數(shù)據(jù)進行分詞,然后將分詞作為關(guān)鍵詞進行存儲,該關(guān)鍵詞并指向原始文檔。當進行搜索的時候也會對搜索目標進行分詞,并使用分詞的結(jié)果進行關(guān)鍵詞搜索,從而匹配到相應的原始文檔。
以上為地址匹配的簡要過程,評分是對搜索結(jié)果進行相關(guān)度計算,給出得分,從而找出匹配度最高的結(jié)果。地址匹配采用的相關(guān)度算法為TF-IDF,該算法按照向量空間的方式進行相似度計算。具體模型參考如圖6所示。
圖6展示了地址匹配過程中,計算文檔相似度的評分。箭頭query表示查詢目標,箭頭document表示命中結(jié)果。對兩者進行叉積運算從而得到一個分數(shù),兩者的夾角越小表示相似度越高。
每一個權(quán)重(weight)代表一個分詞命中分數(shù),該分數(shù)的計算采用信息檢索與數(shù)據(jù)挖掘加權(quán)技術(shù)(TF-IDF,Term Frequency–Inverse Document Frequency)計算。該算法分為兩個部分,tf和idf。tf表示一個分詞項在一個目標文檔(Document)中的頻率,idf表示這個分詞項在多少文檔中出現(xiàn)。所以公式可表示為如下:
Vq*Vd = w(t1, q)*w(t1, d) + w(t2, q)*w(t2, d) + …… + w(tn ,q)*w(tn, d)
ti(1≤i≤n)表示第i個分詞項(如天安門、九里堤等就為一個分詞項),q表示查詢對象,d表示命中文檔,w表示權(quán)重,*表示叉積運算。帶入tf與idf之后。
Vq*Vd = tf(t1, q)*idf(t1, q)*tf(t1, d)*idf(t1, d) + tf(t2, q)*idf(t2, q)*tf(t2, d)*idf(t2, d) + …… + tf(tn ,q)*idf(tn, q)*tf(tn, d)*idf(tn, d)
以上向量空間的計算結(jié)果并不能作為最終的評分結(jié)果,同時還要考慮目標文檔的長度。因為通常情況下,當出現(xiàn)同樣詞項的時候,文檔長度越短則匹配度越高。同時,在實際應用中,還需要考慮詞項加權(quán)的情況,因為并不是所有的詞項都具有同等的低位,比如地址“豐兆路/118號”,“豐兆路”的權(quán)重就應該比“118號”重要,所以在對地址匹配的時候需要對“豐兆路”進行加權(quán)。
排序:
地址匹配的排序結(jié)果是依據(jù)各個命中結(jié)果的相關(guān)度評分進行的,將匹配度最高的搜索結(jié)果作為解析后的訂單地址。
利用上述地址解析方式,對于符合標準規(guī)范的訂單地址,解析率可達99%以上。將解析好的訂單地址與已有區(qū)域塊進行后續(xù)流程的匹配處理,即實現(xiàn)了自動分單。
步驟S105:從后臺地址庫查詢獲得解析后的訂單地址對應的空間位置信息,根據(jù)所述空間位置信息將所述訂單地址匹配到電子地圖上;
具體實施時,可以基于海量地址庫數(shù)據(jù)構(gòu)建的地址詞典,利用中文地址模糊匹配算法搜索并定位上述解析后的訂單地址的空間位置信息(如經(jīng)緯度),確定其在電子地圖上的具體位置,并可電子地圖相應位置上進行標注。
另外,后臺地址庫的數(shù)據(jù)可以逐漸積累,并在不斷迭代中更新。
步驟S107:根據(jù)GIS拓撲關(guān)系確定所述訂單地址對應的業(yè)務區(qū)域塊,將所述業(yè)務區(qū)域塊的信息返回至客戶端。
GIS的空間對象間的拓撲關(guān)系是指在拓撲變換(旋轉(zhuǎn)、平移、縮放等)時保持不變的空間關(guān)系,即拓撲不變量,包括空間對象的相鄰和連通關(guān)系。拓撲關(guān)系所表達的是滿足拓撲幾何學原理的各空間數(shù)據(jù)間的相互關(guān)系,采用結(jié)點、弧段和多邊形表示實體之間的鄰接、關(guān)聯(lián)、包含和連通等關(guān)系。如:點與點的鄰接關(guān)系、點與面的包含關(guān)系、線與面的相離關(guān)系、面與面的重合關(guān)系等。
在另一實施例中,返回的業(yè)務區(qū)域塊的信息可以包括業(yè)務區(qū)域塊名稱、業(yè)務區(qū)域塊編號以及對應的配送網(wǎng)點名稱、配送網(wǎng)點屬性信息(如網(wǎng)點負責人、電話、網(wǎng)點其他情況等)。
在進一步的優(yōu)選實施例中,步驟S107之前還可以包括:
步驟S106:判斷后臺地址庫中是否存在解析后的訂單地址對應的空間位置信息,若是,轉(zhuǎn)步驟S107;否則,轉(zhuǎn)步驟S108。
步驟S108:提醒用戶手工標注所述訂單地址對應的業(yè)務區(qū)域塊,并將所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系存儲到地址糾錯庫中。
相應的,在步驟S103之前,還包括:
步驟S102:判斷所述地址糾錯庫中是否保存有該訂單地址的糾錯信息,若是,轉(zhuǎn)步驟S109;否則,轉(zhuǎn)步驟S103。
步驟S109:直接根據(jù)所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系獲得所述業(yè)務區(qū)域塊的信息并返回至客戶端。
另外,所述方法還可以包括:
步驟S110:基于GIS拓撲關(guān)系對業(yè)務區(qū)域塊進行添加、修改、合并和/或拆分操作,將電子地圖劃分成無縫拼接的業(yè)務區(qū)域塊。
對于前述的各方法實施例,為了描述簡單,故將其都表述為一系列的動作組合,但是本領域的技術(shù)人員應該知悉,本申請并不受所描述的動作順序的限制,因為根據(jù)本申請,某些步驟可以采用其他順序或同時執(zhí)行;其次,本領域技術(shù)人員也應該知悉,上述方法實施例均屬于優(yōu)選實施例,所涉及的動作和模塊并不一定是本申請所必須的。
本申請還公開了一種在其上記錄有用于執(zhí)行上述方法的程序的計算機可讀記錄介質(zhì)。所述計算機可讀記錄介質(zhì)包括配置為以計算機(以計算機為例)可讀的形式存儲或傳送信息的任何機制。例如,機器可讀介質(zhì)包括只讀存儲器(ROM)、隨機存取存儲器(RAM)、磁盤存儲介質(zhì)、光存儲介質(zhì)、閃速存儲介質(zhì)、電、光、聲或其他形式的傳播信號(例如,載波、紅外信號、數(shù)字信號等)等。
參照圖2,示出了本申請基于GIS拓撲分析的地址匹配區(qū)域塊系統(tǒng)一實施例的結(jié)構(gòu)框圖,包括通過網(wǎng)絡連接的客戶端1和服務器2,其中的服務器2具體包括:
訂單地址接收模塊21,用于接收客戶端提交的訂單地址。
訂單地址解析模塊22,用于利用后臺地址解析算法對所述訂單地址進行解析。
地圖標繪模塊23,用于從后臺地址庫查詢獲得解析后的訂單地址對應的空間位置信息,根據(jù)所述空間位置信息將所述訂單地址匹配到電子地圖上。
具體實施時,可以基于海量地址庫數(shù)據(jù)構(gòu)建的地址詞典,利用中文地址模糊匹配算法搜索并定位上述解析后的訂單地址的空間位置信息(如經(jīng)緯度),確定其在電子地圖上的具體位置,并可電子地圖相應位置上進行標注,其形式可以如圖3所示。
第一分單模塊24,用于根據(jù)GIS拓撲關(guān)系確定所述訂單地址對應的業(yè)務區(qū)域塊,將所述業(yè)務區(qū)域塊的信息返回至客戶端。
具體實施時,分單結(jié)果可以采用圖4所示的形式顯示。
在進一步的優(yōu)選實施例中,訂單地址解析模塊22具體可以包括:
分詞子模塊,用于根據(jù)詞庫對所述訂單地址進行分詞,識別出其中的行政區(qū)劃關(guān)鍵詞、道路關(guān)鍵詞、標建關(guān)鍵詞和/或門牌號關(guān)鍵詞;
評分子模塊,用于對分詞子模塊識別出的關(guān)鍵詞進行搜索匹配,并對匹配結(jié)果進行相關(guān)度計算,將相關(guān)度最高的匹配結(jié)果作為解析后的訂單地址。在另一實施例中,服務器2還可以包括:
第一地址糾錯模塊25,用于判斷后臺地址庫中是否存在解析后的訂單地址對應的空間位置信息,若是,則提醒用戶手工標注所述訂單地址對應的業(yè)務區(qū)域塊,并將所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系存儲到地址糾錯庫中。
第二分單模塊26,用于在利用后臺地址解析算法對所述訂單地址進行解析之前,判斷所述地址糾錯庫中是否保存有該訂單地址的糾錯信息;若是,直接根據(jù)所述訂單地址與業(yè)務區(qū)域塊的對應關(guān)系獲得所述業(yè)務區(qū)域塊的信息并返回至客戶端;否則轉(zhuǎn)訂單地址解析模塊、地圖標繪模塊和第一分單模塊進行相應的地址解析、地圖標繪和分單操作。
第二地址糾錯模塊27,用于為業(yè)務員在實地配送時,若發(fā)現(xiàn)訂單地址分配有誤或地址更新等情況,在地圖上直接調(diào)整配送網(wǎng)點位置的接口。由于業(yè)務員權(quán)限有限,因此相應的配送網(wǎng)點負責人負責對業(yè)務員糾錯后的地址進行審核,查看該地址在地圖上的位置是否準確,并將審核通過的地址錄入地址糾錯庫。下次再遇到類似訂單地址,系統(tǒng)直接到地址糾錯庫中去匹配,將匹配結(jié)果返回給客戶端。
網(wǎng)點管理模塊28,用于管理配送網(wǎng)點,包括配送網(wǎng)點的增加/刪除/修改/查詢(含條件查詢)、以及配送網(wǎng)點對于配送面的綁定/解綁等。其中的配送網(wǎng)點信息除了點坐標數(shù)據(jù)之外,還包括配送網(wǎng)點名稱、責任人、電話、所屬分組等,上述屬性還可以作為配送網(wǎng)點的查詢條件。該模塊還提供配送網(wǎng)點的批量導入、自定義屬性及各類屬性的增加/刪除/修改/查詢、圖片上傳、分類顯示/查詢、彈窗字段自定義等功能。
區(qū)劃管理模塊29:用于為管理員提供業(yè)務區(qū)域塊管理接口,包括業(yè)務區(qū)域塊的增加/刪除/修改/查詢、合并拆分,業(yè)務區(qū)域塊與配送網(wǎng)點的綁定/解綁等。業(yè)務區(qū)域塊的信息除了業(yè)務區(qū)域塊的矢量數(shù)據(jù)外,還包括業(yè)務區(qū)域塊的名稱等信息。該模塊支持多人同時在線協(xié)同操作。
系統(tǒng)管理模塊20,用于用戶賬號的權(quán)限劃分以及系統(tǒng)運營支撐管理。其中,用戶賬號的權(quán)限劃分包括用戶賬號信息管理、角色權(quán)限賦值、數(shù)據(jù)權(quán)限管理等。系統(tǒng)運營支撐管理包括記錄客戶每次發(fā)送任務的地址,統(tǒng)計月度任務地址總數(shù),自動分單總數(shù),分單失敗總數(shù),管理用戶、限權(quán)、日志和認證,監(jiān)控系統(tǒng),支持系統(tǒng)自動還原備份等。具體實施時,訂單量的統(tǒng)計形式可以如圖5所示。
在具體實施時,可分為三層實現(xiàn):數(shù)據(jù)層、服務層和用戶界面(UI,User Interface)層。數(shù)據(jù)層包含基礎地圖數(shù)據(jù)、基礎GIS數(shù)據(jù)、業(yè)務數(shù)據(jù)、文件型數(shù)據(jù)、地址數(shù)據(jù)等。服務層由Web平臺組件和系統(tǒng)組件構(gòu)成,前者提供角色管理等業(yè)務功能,后者提供區(qū)劃和分單功能,兩者通過HTTP、SOAP、FTP等協(xié)議交換數(shù)據(jù)。UI層可通過PC瀏覽器、終端APP接入,與服務層通過HTTP協(xié)議交換數(shù)據(jù),支持Ajax異步請求。系統(tǒng)采用SOA架構(gòu),實現(xiàn)系統(tǒng)的復用和低耦合,以及與外部應用的無縫集成。
為提高系統(tǒng)的可擴展性、可維護性和高安全性,可采用標準的MVC分層開發(fā)模式,在數(shù)據(jù)層、服務層和UI層分別采用如下機制:
數(shù)據(jù)持久機制:采用開源的對象關(guān)系映射框架Hibernate對數(shù)據(jù)庫進行持久化,在數(shù)據(jù)庫與系統(tǒng)之間,建立數(shù)據(jù)庫表/視圖和Java類的映射關(guān)系,形成模塊化關(guān)系集成管理數(shù)據(jù)庫,同時為服務層提供POJO類支撐,簡化服務層操作數(shù)據(jù)庫的工作量,提高對數(shù)據(jù)庫的訪問效率、安全性、穩(wěn)定性和可擴展性。
業(yè)務處理機制:采用Spring企業(yè)級集成框架,基于持久化的數(shù)據(jù),結(jié)合用戶需求和UI展現(xiàn),為系統(tǒng)實現(xiàn)復雜的業(yè)務邏輯處理,返回正確的處理結(jié)果并展現(xiàn)給用戶,系統(tǒng)資源開銷小、配置管理靈活、集成性和可移植性高。
分發(fā)控制機制:采用SpringMVC框架,提供B/S結(jié)構(gòu)通信管道,處理系統(tǒng)中的非法請求攔截、系統(tǒng)權(quán)限控制、業(yè)務請求調(diào)度分發(fā)、跳轉(zhuǎn)UI視圖等。
UI表現(xiàn)機制:采用前端開發(fā)框架Bootstrap和jQuery,提供友好、人性化的UI設計。Bootstrap和jQuery提供豐富的插件(如時間控件、表格控件、樹形控件等)、圖形化UI(如柱狀圖、餅狀圖、曲線圖等)和安全穩(wěn)定的Ajax技術(shù),以保證UI層的實現(xiàn)。
需要說明的是,上述系統(tǒng)實施例屬于優(yōu)選實施例,所涉及的單元和模塊并不一定是本申請所必須的。
本說明書中的各個實施例均采用遞進的方式描述,每個實施例重點說明的都是與其他實施例的不同之處,各個實施例之間相同相似的部分互相參見即可。
以上對本申請所提供的一種基于GIS拓撲分析的地址匹配區(qū)域塊方法和系統(tǒng),進行了詳細介紹,本文中應用了具體個例對本申請的原理及實施方式進行了闡述,以上實施例的說明只是用于幫助理解本申請的方法及其核心思想;同時,對于本領域的一般技術(shù)人員,依據(jù)本申請的思想,在具體實施方式及應用范圍上均會有改變之處,綜上所述,本說明書內(nèi)容不應理解為對本申請的限制。