李文平 王衛(wèi)青 趙 顗
(1.常熟市公安局交通管理科學技術(shù)研究所 江蘇 常熟 215500;2.南京柏博交通科技有限責任公司 南京 210018)
一般來講,城市居民OD 調(diào)查采用的抽樣率在3%~4%[1]。所以,即使是一個人口為40萬的中等城市,其需要采集的樣本問卷也需在1.4萬份左右。例如,在湖州市城市綜合交通規(guī)劃中,總抽樣率為3.05%,得到有效居民出行表格共13 377份。由此看來,城市居民OD 調(diào)查所得到的樣本數(shù)據(jù)是非常龐大的。
在后期的數(shù)據(jù)處理方面,一般都是將Access、Excel、Matlab等軟件結(jié)合使用;雖然可以滿足大部分OD統(tǒng)計分析的功能需求,但是這些軟件設計的初衷是通用性,即大眾化、簡單化、易用化,面向的處理對象是一般的商業(yè)數(shù)據(jù),對于OD 出行這種特殊的海量工程數(shù)據(jù)的處理分析,顯得力不從心。
比如Access的查詢功能兼顧了所有用戶,提供了一個查詢窗體設計器,可以實現(xiàn)簡單的按列匹配進行查詢,但是對于“按年齡組的平均出行次數(shù)分布”這樣的查詢,簡單的查詢窗體無法很好的滿足要求;即使工程人員有較高的計算機、數(shù)據(jù)庫方面的知識與經(jīng)驗,并且掌握了基本的SQL 語言,要實現(xiàn)出行次數(shù)的統(tǒng)計,仍然需要自己為每個年齡組手工設計兩條查詢語句,分別得到結(jié)果,然后進行除法運算。這樣一來,如果存在6個年齡組,那么至少需要12條SQL語句和6次除法運算才能實現(xiàn)以上功能要求。而且極易出現(xiàn)人為操作失誤,比如,除法運算錯誤等。同樣,對于更高階的統(tǒng)計,如“各出行目的的出行方式”,統(tǒng)計出的結(jié)果應該為1張表格,假設出行目的、出行方式均有9種,那么需要繪制的表格就有81個單元格,同樣需要對每個單元格進行數(shù)據(jù)統(tǒng)計,這樣的工作量是很大的。再者,Access這種小型關(guān)系數(shù)據(jù)庫的效率并不高,在動輒幾十萬數(shù)據(jù)樣本的OD調(diào)查中,搜索一次所要花費的時間也是比較長的。在一篇出行調(diào)查與特征分析的報告或論文中,需要幾十個大小不等的數(shù)據(jù)表格,如果所有的統(tǒng)計數(shù)據(jù)均依靠這種半人工方式實現(xiàn),效率將會非常低。
為了解決上述實際操作存在的問題,對當前OD調(diào)查中使用到的統(tǒng)計方法以及利用該統(tǒng)計方法得到的大量數(shù)據(jù)表格、圖形進行分析,提取出幾乎所有OD調(diào)查所用到的統(tǒng)計方法的基本共性,加以分類、總結(jié),最終提出了統(tǒng)計分析的核心技術(shù),即下面所介紹的OD Result Set Exchange Standard和ODQL。OD Result Set Exchange Standard的優(yōu)勢在于將所有的統(tǒng)計結(jié)果的存儲方式統(tǒng)一化,能夠滿足幾乎任意維的數(shù)據(jù)空間;并且易于交換、修改、轉(zhuǎn)換到表格、圖形等更直觀的表述形式。ODQL則是為解決所有的OD統(tǒng)計方法而專門設計的一門查詢語言,語法與SQL 類似,但是提供了統(tǒng)計任意維數(shù)據(jù)空間的功能,甚至可以得到“非規(guī)則”的數(shù)據(jù)空間;其最終的結(jié)果則使用OD Result Set Exchange Standard進行表述。
目前所使用的出行調(diào)查問卷的形式是以自然人為單位,包括其自身的特征屬性,如年齡、性別、收入等,以及在特定時間段(通常為24h)內(nèi)的所有出行記錄,出行記錄數(shù)量一般在10次以內(nèi)。個人特征屬性為一維表結(jié)構(gòu),出行記錄則為二維表結(jié)構(gòu)。從出行本身的性質(zhì)來看,以一個被調(diào)查人員為例,其出行記錄之間的基本關(guān)系如下:①出行的完整性;②出行信息的合理性;③居民的屬性與出行信息的關(guān)聯(lián)性[2]。
其中,樣本數(shù)據(jù)的完整性,是指居民調(diào)查表和居民調(diào)查子表中所包含的出行者家庭與個人特征以及出行信息等相關(guān)信息能夠滿足建立活動模型的需要;出行信息的合理性,主要包括出行記錄的空間一致性、出行記錄的時間連續(xù)性、出行方式的一致性;居民的屬性與出行信息的關(guān)聯(lián)性,主要包含工作-職業(yè)、工作-年齡、上學-職業(yè)、上學-年齡等方面的檢驗。
傳統(tǒng)的OD數(shù)據(jù)統(tǒng)計方法可分為出行次數(shù)和特定屬性的統(tǒng)計,出行次數(shù)的統(tǒng)計又可分為出行次數(shù)總量的統(tǒng)計,即出行量和平均出行次數(shù)的統(tǒng)計;指定屬性的統(tǒng)計可分為屬性的總量(如總時耗、總花費)、平均量(如平均時耗、平均花費)、最大量、最小量共6種統(tǒng)計方法[3]。
傳統(tǒng)的OD數(shù)據(jù)統(tǒng)計方法所統(tǒng)計得到的結(jié)果數(shù)據(jù)集形式通常為一維空間或二維空間,坐標軸通常對應特定的屬性,即出行調(diào)查表中的列(如出行方式、出行目的),也可為組合列(如時耗,到達時間減去出發(fā)時間),空間中數(shù)據(jù)點的值通常有整型的出行量、浮點型的平均出行次數(shù)或平均耗費,或?qū)⑶皟烧邤?shù)據(jù)按照某個方向歸一化后的百分比數(shù)據(jù)[4-5]。
該類統(tǒng)計結(jié)果的特點是各個數(shù)據(jù)點所代表的數(shù)據(jù)空間均為獨立不重疊的,即任意一點數(shù)據(jù)不包含其它任何點的數(shù)據(jù);基于這一點,對結(jié)果的歸一化操作才有實際意義。
由于原始樣本的出行記錄數(shù)據(jù)一般保存在關(guān)系數(shù)據(jù)庫中,單次出行以數(shù)據(jù)表中行的形式存在,數(shù)據(jù)類型一般均為常見計算機語言內(nèi)置類型,如整型、浮點型,因此利用現(xiàn)有的計算機語言處理原始數(shù)據(jù)會帶來很大的便捷。目前國內(nèi)普遍使用Microsoft Office辦公套件中的Access、Excel等軟件對出行數(shù)據(jù)進行統(tǒng)計分析,常見方式為利用Access的查詢窗體對數(shù)據(jù)樣本進行簡單查詢,或者使用結(jié)構(gòu)化查詢語言SQL對樣本進行高級查詢,可以實現(xiàn)多表的連接查詢或更高級的功能,采用這種方式,用戶可以完全自定義查詢方法;缺點是對用戶的計算機水平要求較高、整體自動化程度不高、查詢速度較慢等。因此,無論是從便捷性還是專業(yè)性方面來看,將辦公軟件用于交通調(diào)查統(tǒng)計中,效果不是很理想。
同時由于在交通出行調(diào)查統(tǒng)計分析領(lǐng)域,尚未出現(xiàn)專用的軟件和通用開放標準,因此我們提出了一套開放標準和實現(xiàn)。
ODQL和ODRS就是根據(jù)上述理論分析的結(jié)果,設計的類自然語言和數(shù)據(jù)格式規(guī)范。ODQL與ODRS在設計之初就考慮到如何同時滿足高度的專業(yè)化、功能的靈活性以及使用的便捷性?,F(xiàn)有的版本是參考了SQL的語法和一些工程軟件的數(shù)據(jù)文件格式,經(jīng)過不斷改進而成形的。
ODQL與ODRS已經(jīng)在OD Star中實現(xiàn),通過該接口,我們實現(xiàn)了43種常用統(tǒng)計方法。
ODQL的 全 稱是origin-destination query language,即交通起止點查詢語言。
ODQL所針對的原始數(shù)據(jù)空間是以一次出行記錄為基本單位的全體出行樣本,其首要設計目標是滿足各種需求的OD數(shù)據(jù)統(tǒng)計,按照針對坐標軸和全局的約束條件進行查詢并建立起符合OD Result Set Exchange Standard的數(shù)據(jù)結(jié)果空間模型。在這里我們只關(guān)注ODQL的語法如何滿足不同需求的統(tǒng)計以及最終結(jié)果的存儲形式,對于原始出行記錄的存儲格式以及ODQL如何被解釋執(zhí)行等方面的介紹請參閱OD Star說明書。
完整的ODQL語句包含幾個要素,見表1。
表1 ODQL語句說明Tab.1 Illustration of ODQL statement
*歸一化:假設統(tǒng)計的數(shù)據(jù)空間為二維空間,如需要按列計算各個單元格所占的百分比,則可以設置歸一化方向為0;同理,如需要按行計算各個單元格所占的百分比,則可以設置歸一化方向為1;設置為-1則不進行歸一化處理。
ODQL文法(正則表達式描述)如下。語法關(guān)鍵字說明見表2。
表2ODQL文法(正則表達式描述)
ODQL核心特征:
1)支持交通量(出行量)、平均出行次數(shù)的統(tǒng)計。
2)支持無限多空間坐標軸。
3)支持符合坐標軸。
4)支持任意多軸約束。
5)支持不同類型的軸約束結(jié)合。
6)支持全局約束條件。
Query Engine是為了解釋并執(zhí)行ODQL語句而實現(xiàn)的解釋器和執(zhí)行器。
在OD-Star中集成了一個ODQL的命令行接口——ODQL Shell,通過該接口,用戶可以直接執(zhí)行完全自定義的ODQL語句。詳細介紹請參閱《基于B/S模式的居民OD調(diào)查統(tǒng)計分析軟件的研究與開發(fā)》,這里不再贅述。
執(zhí)行一次ODQL所需要的時間依賴于結(jié)果集的規(guī)模。根據(jù)不同規(guī)模的測試結(jié)果見表3、表4。
由平均單次執(zhí)行時間可以看出,隨著統(tǒng)計結(jié)果空間規(guī)模的增大,總執(zhí)行時間接近線性增長,平均單次執(zhí)行時間保持在200ms左右。常用的統(tǒng)計方法的規(guī)模一般在100以內(nèi),出行記錄一般也小于10萬規(guī)模,因此ODQL Executer的性能完全能夠滿足一般的工程應用。ODQL所面向的原始數(shù)據(jù)的規(guī)模一般在幾十萬,雖然ODQL可以一次性執(zhí)行得到一個完整的空間數(shù)據(jù)集,但是執(zhí)行所需的時間還是相當可觀的。如果使用傳統(tǒng)的Access、Excel等軟件對數(shù)據(jù)進行一個一個的統(tǒng)計,可想而知其中存在大量的重復勞動會消耗大量的時間。
表2 語法關(guān)鍵字說明Tab.2 Keyword description in syntax
表3 測試樣本數(shù)據(jù)總量Tab.3 Total amount of test sample
表4 測試環(huán)境Tab.4 Test environment
在現(xiàn)有的OD 調(diào)查數(shù)據(jù)基礎(chǔ)上,我們提出的ODQL標準查詢語言和ODRS標準數(shù)據(jù)集格式,規(guī)范了查詢數(shù)據(jù)的方式,覆蓋了絕大多數(shù)的分析需求并大大減少了時間開銷。用戶通過標準的ODQL語句能得到各種所需的數(shù)據(jù)結(jié)果形式,實現(xiàn)了數(shù)據(jù)結(jié)構(gòu)標準查詢,使居民OD 調(diào)查數(shù)據(jù)得到最大化的利用,也為調(diào)查數(shù)據(jù)的挖掘工作提供便利的途徑。
表5 測試結(jié)果Tab.5 Test result
[1]東南大學交通學院.蚌埠市城市綜合交通規(guī)劃[R].南京:東南大學交通學院,2007.
[2]王伊麗.城市居民活動-出行特征分析方法研究[D].南京:東南大學,2007.
[3]王建軍,嚴寶杰.交通調(diào)查與分析[M].2版.北京:人民交通出版社,2004.
[4]王 煒,陳學武,陸建.交通規(guī)劃[M].北京:人民交通出版社,2007.
[5]陸 建,王 煒.面向可持續(xù)發(fā)展的城市交通系統(tǒng)調(diào)查內(nèi)容與分析[J].中國市政工程,2003(5):1-4.
[6]王小敏,熊 軍,馬木欣.基于GPS的大跨度橋梁變形監(jiān)測與數(shù)據(jù)處理[J].武漢理工大學學報:交通科學與工程版,2009,33(2):219-223.
[7]戢曉峰,劉 瀾.多模式公共交通系統(tǒng)的出行信息有效性研究[J].武漢理工大學學報:交通科學與工程版,2009,33(5):980-983.