哈哈，還是師兄比較猛！（說實話，師兄還不知道我轉他的呢。算了，算是幫他宣傳下咯，也學習了！）轉http://user.qzone.qq.com/604888793ptlang=2052#!app=2&via=QZ.HashRefresh&pos=1322410365
Ben
[email protected]題記：如果一個遙感影像數據處理的程序不能夠滿足大影像處理的話，那麼，基本可以認定這個程序是廢的。
最近，在幫一位師姐做圖像處理時，遇到了不少的麻煩，她的要求是處理大數據量的影像，而且速度不能太慢。對於我們這些業餘的“碼奴”來講的確是一件很不容易的事情。她提出了三個需求，其中的一個需求就是使用矢量數據對遙感影像進行裁剪。矢量數據使用的是中國行政區圖，而要裁剪的影像的大小是要1G以上的。剛看到這個數據的大小的時候，首先讓我感受的不是信心倍增而是心理充滿着畏懼。我也試想，對於我這種業餘的“程序猿”來說，怎麼能夠完成？？。可是，既然答應了，那麼就要一定做好。好吧！！ 那就從最簡單的開始吧。
我們知道中國政區圖使用的是矢量圖，裏面存儲的是多邊形信息，也就是每個省的矢量化後的範圍，那麼最簡單的裁剪辦法是什麼呢？就是對影像的每個點來判斷是否在這所有的多邊形內，這個最容易不過了，呵呵，以爲找到了答案，欣喜若狂！！！，可是等把代碼寫完，滿懷信心的雙擊執行文件後，我才發現，得到的不是程序運行結束的提示符，而是不知道要運行到什麼時候的程序等待符。OMG！！！，我幾乎抓狂，別說把代碼給師姐了，就連我自己都覺的這代碼可以說是“垃圾”。不管了，讓它運行吧，看它能支持多久，午飯過後，回來再看一下，天哪，還在運行。睡一覺吧，午覺醒來後，在看一眼，終於運行完了，整整用了40多分鐘啊！！！沒辦法了，那隻能尋求高效的方法了。
提到這個高效的方法，我還真是有些“膽大”，那麼，我是怎麼“膽大”的呢？就讓我們開始吧，呵呵！！
既然一副數據量那麼大，那麼何必不按塊進行處理呢？乾脆影像直接按照512*512的塊大小處理吧，呵呵，跨出了程序高效地第一步。那麼下一步怎麼樣呢？我思考了一下，按點進行處理的低效的原因在於大量的點與多邊形拓撲關係的運算，那麼提高效率的方法就在於儘量避免大量的點與多邊形的拓撲關係的運算。基於該出發點，首先是讓影像塊與中國政區矢量圖的多邊形進行做包含運算，如果該影像塊的在政區圖的多邊形內的話，那麼直接跳過該數據的處理，進行下一個影像塊的處理。其次，對於不包含在政區圖內的影像塊進行一次求交運算，如果沒有一個行政圖的多邊形與其相交，那麼，直接跳過，進行下一個影像塊的處理。第三，如果行政區內的影像有一個或多個與該影像塊相交的話，那麼，求取該影像塊與該多邊形的交。第四，雖然相交，但是還是需要將影像塊的所有點與多邊形進行運算，這樣的話，內部還是包含了大量的點。呵呵，沒辦法，繼續優化吧。誰讓咱們的終止是減少與點與多邊形的運算呢？該怎麼處理呢？，這樣吧，我們取求交後的多邊形的外包矩形吧。呵呵，這樣數據量少了吧？只對外包矩形內的點進行與多邊形的求交運算。哈哈......，所有的思路理清楚了。可以完事了嗎？
根本不可能，爲什麼？這裏面又是多邊形求交，又是點與多邊形的處理，我一個學遙感的，怎麼能在那麼短時間裏寫這樣的拓撲關係的代碼？沒辦法了，上網搜吧。還好，我對GDAL很熟悉，哈哈....,優勢來了，GDAL裏面的OGR是矢量模塊的運算庫，但是，讓我失望的是，OGR只是提供了數據讀取的一半接口，而矢量處理卻依賴於GEOS庫。那就用採用GEOS庫吧，事情依然不是那麼順利，一個小小的庫居然花了我1天的時間來編譯，黃天不負有心人啊，終於大功告成！！！事情還沒完呢？haha。。。。下一步工作是要寫代碼了，邏輯清楚了，代碼還在話下嗎？？？？？
測試一下效率吧，驚人啊！！！！！！！！！！！！！！！！！！！！！！！！！，7800*2500的影像的裁剪（包括數據讀寫）不到10秒鐘就裁剪完了。不僅你不相信，就是我也有些不相信自己的眼睛......。效率總算提上去了，雖然程序還是有些小BUG，慢慢地在維護吧...
PS：
1. 該思路沒有參考任何軟件，純自己的想法（可能會其他的軟件於此雷同吧，這個我也不清楚）
2. 有同學建議我使用某國產GIS軟件的二次開發庫，爲什麼不用它的開發包？ 這個“你懂得”！！
3. GDAL(柵格處理庫) + OGR（矢量處理庫） + GEOS（矢量關係庫） + PROJ4（地圖投影庫）， 四庫合璧，天下無敵....