因?yàn)楣ぷ餍枰?，要把路況信息做成切片，因?yàn)橹澳欠N方式（直接繪制路況）效果不大好，繪制速度太慢，也太過于消耗流量了（一次就把整個(gè)市的路況信息都返回來了）。四月十三號開始接到這個(gè)任務(wù)，并著手查找關(guān)于切片的資料。
最開始，主任的想法是通過算法實(shí)現(xiàn)，很顯然要用到裁剪算法。但這個(gè)方式我并不贊同，且不說裁剪算法用于此次多么復(fù)雜，而且還要考慮到效率問題，polyline排序本來就非常的復(fù)雜而且來回遍歷也是很費(fèi)事的。主任同意我使用一些現(xiàn)成的切片庫，這樣可以節(jié)省很多精力。
- 首先想到的arcgis engine二次開發(fā)，但不久就放棄了。網(wǎng)上找到一些切片demo，好像是必須要安裝arcgis server，那么就真的麻煩了。而且還要安裝arcgis runtime，以及授權(quán)許可，簡直麻煩到家了。
- 然后想到第三方開源軟件geoserver，這個(gè)可以實(shí)現(xiàn)切片，通過二次開發(fā)的話應(yīng)該也是沒問題的。但這方面的資料好少啊，簡直無從下手。
- 使用gdal工具gdal2tiles.py，這個(gè)看起來不錯，可以實(shí)現(xiàn)切片功能。需要配置gdal環(huán)境，不知怎么得就放棄了這個(gè)。
- 是看到了mapnik，才放棄了gdal2tiles.py，也許是后者資料太少吧。mapnik也是需要安裝的，可以選擇三種語言來開發(fā)——python、nodejs以及c++?？紤]的效率問題，我最開始打算使用c++，要求版本好像挺高的，需要c++11；之后就想用nodejs，很早就像用nodejs實(shí)戰(zhàn)一下，何況對于ajax請求以及json解析也是存在優(yōu)勢的，最后也不得不放棄了，因?yàn)楣俜椒懦龅馁Y料太少了，連一個(gè)demo都不給我。不得不選用python了，也不錯，頭一次使用python寫程序，還有些小激動呢！
雖然是第一次使用python，但開發(fā)起來效率還是比較高的，分為以下步驟：
- 讀取本地測試數(shù)據(jù)json，并解析
中間出現(xiàn)過字符編碼問題，糾結(jié)過一段時(shí)間。 - 生成shapefile文件
同樣利用第三方庫pyshp. - 利用網(wǎng)上開源代碼generate_tiles.py，實(shí)現(xiàn)多級別切片
不幸呀！出現(xiàn)了重疊部分，糾結(jié)了整整一天。有可能是地圖投影是出現(xiàn)了問題，當(dāng)我設(shè)置m.aspect_fix_mode屬性是沒有出現(xiàn)效果 - 利用NSIS封裝打包
由于第三步出現(xiàn)了故障，打包推遲。
老楊給出了比較好的解決方案，直接通過行列號反算經(jīng)緯度，實(shí)現(xiàn)bbox范圍的確定，解決了切面重疊問題。老楊很聰明，這一方面也不得不服。那么問題來了，路況信息5分鐘刷新一次，切片也要在五分鐘內(nèi)完成吧。然而事實(shí)上很殘酷，畢竟是到20級呀，一套下來4700秒，接近80分鐘。顯然不合理，20級地圖占用了太多的時(shí)間，理論上是更高一級是低一級耗時(shí)的四倍，也就是說僅20級就用了一個(gè)小時(shí)。假使服務(wù)器cpu是32個(gè)核，都占用起來應(yīng)該會縮短到五分鐘以內(nèi)，但想想機(jī)房里cpu瘋狂般的不停高負(fù)荷運(yùn)轉(zhuǎn)也是夠了。也許使用geojson，借助前端地圖渲染引擎來支持或許是個(gè)好辦法。
計(jì)時(shí)單位：毫秒
