本次提交的個人觀點：
- 對GIS的依賴程度 ,是否要接入postgresql進行GIS方面的計算（之前有一點點研究览效，并不深入）照弥；
- 關(guān)鍵的特征應(yīng)該是trajectories軌跡方面的特征害幅。在初期可以采用類似張洋在翻譯中提到的geohash的方法（沒找到和R相關(guān)的漓踢，倒是有個python包增蹭，誰幫忙研究下）：類似的思想就是將地圖切分成大量的小方塊（高級一點會切成六邊形学少，小方塊的案例有：Uber和神州專車，沒找到技術(shù)鏈接將地圖切塊鳞疲，進行用車預(yù)測罪郊，從而動態(tài)調(diào)價；六邊形的好像是高德尚洽，做地圖上某個六邊形區(qū)域點擊悔橄，可以看到半小時、一小時腺毫、兩小時的到達區(qū)域范圍）切成塊之后進行編碼癣疟，這樣可以將任意一條行程轉(zhuǎn)化成為軌跡覆蓋區(qū)域編碼的序列，或者整個編碼區(qū)域的稀疏矩陣潮酒。再簡單點睛挚，之間使用起止點的編碼作為特征進行預(yù)測也是可以接受的。
- 在上一步的基礎(chǔ)上急黎，可以進行一些OD方面提取特征竞川，baidu出租車OD分析、baidu出租車運營平臺
一些還未想好是否能合理使用的點：
- 是否應(yīng)該將行程切分叁熔，區(qū)分載客和/空車的行程（需要進行驗證）委乌，在后期用來訓(xùn)練的數(shù)據(jù)是根據(jù)某個特征（載客/空車）切分的行程，還是整個行程中的每兩個點之間的行程都作為訓(xùn)練數(shù)據(jù)荣回？
比如說一段行程在經(jīng)過geohash標號后遭贸， A →B→C→C→D→E，到達每個標號的時間知道心软；
訓(xùn)練的輸入會是其中任意一個子集么壕吹，如A →B； A →B→C - （這條肯定用）高德的API删铃，企業(yè)用戶耳贬，具體可能會發(fā)生關(guān)聯(lián)的如：路徑規(guī)劃API；基于API的相關(guān)屬性構(gòu)建特征值猎唁；
- 駕駛員駕駛行為屬性（由于數(shù)據(jù)間隔30s咒劲，所以很難學(xué)習(xí)到駕駛員的駕駛行為傾向）
- 用戶畫像方面：駕駛員的生活習(xí)慣，貌似也沒什么建模必要；
- H2O的使用腐魂；
以下是我的方案：
- 在將原始數(shù)據(jù)計算平均車速度后帐偎，驗證一些典型的特征驗證：
- 城市不同時段的車流量；
- 不同日期的車流量變化（節(jié)假日/非節(jié)假日蛔屹，需要考察程度在該段時間內(nèi)會影響OD的重大事件）
- 每個人的平均速度是否有不同（個人駕駛傾向）
- 載客與非載客對時間的影響削樊，理論上taxi在乘客上車后，應(yīng)該直接確定目的地兔毒，并且不會在中間因為非交通原因等待漫贞。
- 出駐車的換班時段是否固定，如不固定是否有必要作為特征
- 對于軌跡的信息提取育叁，傾向于使用geohash的方法迅脐，編碼地圖上的每一個小塊。（能想到的另一種方法是GIS數(shù)據(jù)庫擂红，postgresql的使用）仪际，基于編碼提取特征围小，將GIS特征變?yōu)閿?shù)字特征作為輸入?yún)?shù)昵骤；
其他的特征還有：
- 行程起止點GPS距離；
- 行程的GPS點個數(shù)肯适；
- 行程所處時間段变秦、日期；
- 行程是否包含了預(yù)設(shè)的經(jīng)常擁堵路段框舔；
- 駕駛員方面的因素蹦玫；
- 高德提供的特征：如導(dǎo)航時長
- 未完待續(xù)。刘绣。樱溉。。纬凤。福贞。
- 模型，這部分現(xiàn)在談好像紙上談兵停士，但是否使用一些機器學(xué)習(xí)的平臺可以提前考慮下挖帘，比如H2O;
- 測試，
- 提交測試結(jié)果恋技，可以查看下被用來預(yù)測數(shù)據(jù)的樣式拇舀；目前最高分0.22。
盡量能在月底提交一次結(jié)果吧蜻底，通過與結(jié)果的比對骄崩，不斷迭代更新算法吧。
| 任務(wù) | 完成日期 | 任務(wù)分發(fā) |
|---|---|---|
