大奇軟體研發中心，版權所有，歡迎轉載

軟體作者：興國縣朱明軟體工作室，官方網站：http://www.nasagis.com/ 天下之大奇地理資訊系統,QQ群：天下之大奇軟體1（群號：289388350）（群號：116355287）（群號：139019602）

2015.7.15.8.14 1.沒有完全修復圖示連結的問題

2015.7.17.21.48 1.加入了已經兩點經緯計算距離的程式碼 2.已經其中一點經緯度，還有距離和方位角，求另一點經緯度座標的程式碼，經測試精度還高，測試程式碼放在關於裡測試，計算的結果在谷歌地球中比對，小數點後4位基本吻合。

2015.7.18.9.42 1.添加了根據方位角和距離生成另一條線的程式碼，但有線路有交叉，因為模型的方位角都一樣，沒有按照實際計算 2.修復了重複生成模型的bug 3.測試了模型的方位角有效果 4.模型紋理丟失問題沒解決

2015.7.19.23.27

1.添加了根據緩衝區生成三相電線的功能，可以輸入數值來生成

2015.7.20.11.19 1.修復了緩衝區生成末尾資料跑到0度去的bug,在原始資料中加了個trimend()把末尾空白資料刪除。 2.添加了根據生成三相導線的功能，並且可以設定三根導線的顏色，海拔高度模型採用替換".0"的方式

2015.7.24.11.51

1.修改了批量讀取相片經緯度生成3D線路杆塔的程式 2.還沒有給山東萊陽電力局解決軟體記憶體不足的問題

2015.7.29 1.已經解決軟體記憶體不足的問題，在codeplex下載了一套處理圖片的原始碼，然後從中引用了一個生成影象縮圖的類，編譯成新軟體，發給客戶測試，100多張圖片沒有提示記憶體不足。之前十幾張相片就提示記憶體不足，並且客戶電腦是4G記憶體高配電腦。原來是GDI的記憶體洩露問題。

2015.7.31 1.修復了線間距為0時生成的三條線重合的bug.

2015.8.4 1.給excel轉kml專家簡單的添加了三級註冊的功能

2015.8.13 1.添加了預設模型的功能，生成3d時，如果沒有設定模型所在的檔案，則預設為程式包中的模型 2.修復了生成kmz時因為圖片路徑為空，顯示z.add(f,“files”)出錯無法識別的URI的錯誤，加了個try…catch防止報錯

2015.8.14 1.增加了度分秒相互轉換的類，可以實現度轉度分秒等功能，並且可以互轉

2015.8.21 1.增加了kml轉excel匯出度分秒格式的功能

2015.8.26 1.添加了htmltable轉xls的類，目前只支援簡單結構的htmltable，用來完成客戶的農業資訊查詢系統

2015.8.30 1.修改了儲存配製檔案和讀取配製檔案時多邊形的顏色不儲存的狀況。 2.excel轉kml專家介面從datagridview初始化時抽象為一個函式，並且添加了通過datagridview或者excel和ini配製檔案和儲存路徑自動生成多邊形的功能。

2015.9.1 1.修改了點按照分類標識生成時第二個資料夾缺少第一個點資料的bug 2.在win8 64位蘋果電腦上也可以運行了

2015.9.21 1.修改了自定義模型時生成出錯的問題。可以生成預設的杆塔模型，也可以生成自定義的模型了。 2.修復了生成點時帶圖片資源的kmz檔案提示不能識別URI的錯誤，採用壓縮類新增縮圖的資料夾，然後kml的圖片路徑改為.*.jpg的模式，可以生成帶圖片資源的kmz了，並且可以移動到其它電腦和路徑使用。

2015.9.24 1.修復了生成線段和線條時線高的功能，可以專門指定線高，支援線段起點和終點的高度不一樣

2015.9.28 1.修改了非單一模型時模型路徑出錯的程式碼。注意模型名和圖片名路徑不要帶中文，否則會出錯。

2015.9.29 1.把所有的圖片和圖示資源路徑都設定成“1.png"的格式，這樣就可以把引用的圖示和圖片一起壓縮到kmz檔案中，拷到別的電腦也不會出現路徑錯誤的問題。 2.添加了去除arraylist重複的方法。避免了zip壓縮時提示已經有了相同的項的錯誤。 3.實現了生成三相線，兩點之間都為線段的功能

2015.9.30 1.當軟體所在資料夾名稱更改或者移動時，會出現讀取配製檔案點的圖示無法讀取的錯誤，這是因為ini檔案存放的是舊的路徑。通過改成Application.StartPath後，自動讀取軟體所在目錄的圖示資源。 2.修改了生成三相線段重複生成的bug 3.添加了生成Kml資料夾的功能

2015.10.5 1.發現一個bug，zip解壓時若資料夾存在，則會報錯。加了個判斷資料夾是否存在的功能 2.添加了生成點、三線、模型不帶kml頭和尾的函式，然後一次性生成kml的點、三線、模型的功能。

2015.10.9 1.添加了視窗自適應的類，通過迴圈遍歷控制元件的方法，記錄控制元件的初始位置，然後在在size_change事件中獲取窗體改變的比例，按照比例來調整控制元件的大小。經測試基本滿足要求，可以適應不同的電腦解析度了。但還是存在一些bug，有時窗體調整後會出現混亂的佈局，還沒查清原因。 2.修復了一鍵生成點、線、杆塔時，高亮圖示顯示為X的錯誤。還有生成後按鈕變灰色的錯誤。 3.修復了一鍵生成點、線、杆塔時，zip壓縮後把kml檔案壓縮到User檔案下導致無法讀取圖片的錯誤，正確程式碼：zip.add(savepath,"")

2015.10.10 1.修改了openfiledialog.filter檔案字尾過濾模式，可以同時過濾兩種以上檔案格式了

2015.10.12 1.添加了通過usbserailnumberlist的方法來識別USB註冊，避免了繫結多個USB要為每個USB都製作編譯一款軟體的麻煩。這樣只要編譯一個軟體，並可以為已經新增到USB列表中的USB綁定了。

2015.10.14 1.今天有個客戶需要帶GPS相片轉為谷歌地球中可以看到的kml檔案，並且需要帶相片。但轉換後竟然發現緯度和相片GPS座標中的不一樣。客戶用的是華為的手機拍攝的相片，之前我用蘋果手機還有山東萊陽電力局用尼康相機照的相片可以正常讀取，不清楚什麼原因，難道是之前讀取exif類的程式碼版本比較老。後來在codeplex中找了個支援exif2.2版本的程式碼類，測試可以正常使用。於是更新了一下。

2015.10.16 1.陝西電力一客戶展示了在奧維地圖上的一些應用，並且提出了計算線段節點間距離和累距的需求。然後我在谷歌地球平臺中實現了基本功能。客戶還要求能反向距離計算，下一步繼續實現。客戶提取像奧維地圖哪樣可以匯入kml的一個平臺及計算距離的需求，給我一個月的時間開發，我覺得很容易。

2015.10.19 1.在谷歌地球中實現了反射距離的計算，研究了world表格轉到地標中，比較複雜的表格，經測試，有方法可以實現。但對於帶有複雜物件的world轉html後會出現混亂。

2015.10.21 1.再次研究了exif的讀取，添加了讀取相片時把相片相關的文字引數全選匯入地標氣泡框中的程式碼。完善了ini讀取和儲存的功能。在相片讀取生成kmz檔案時，自動把程式的配製寫成為ini檔案，從而實現了用程式碼配製引數時儲存引數的功能，以便實現exif的datagridview的視覺化轉換。 2.新增在讀取相片exif生成kmz的同時生成excel的功能,生成的excel匯入excel專家轉換時提示已經包含列“無”，然後添加了一個判斷是否包含列的程式碼，解決了初始化出錯的問題。

2015.10.24 1.完美了GPS相片轉換的相關功能和介面，採用excel轉kml專家匯入ini檔案的方式來設定軟體的轉換方式，添加了一些選單和功能美化等。下一步，建立好淘寶連結，加密和註冊完善好，錄製好視訊教程等，然後儘早釋出。

2015.10.26 1.修復了ini檔案儲存時datagridview因為沒有資料count為0的錯誤，改從combox中讀取，這樣就可以不依賴於表格而讀取修改ini檔案後儲存。 2.完善了GPS相片轉谷歌的功能，可以根據需要生成點、線面，另外還可以根據ini檔案配製來對點、線、杆塔模型進行設定，非常強大！ 3.修復了GPS相片轉谷歌地球軟體中杆塔模型路徑的錯誤。原來當軟體目錄移動或者更改名稱後，ini配製檔案裡的目錄並沒有隨著更改，於是就會出現找不到杆塔模型的錯誤。通過在讀取配製的最後，判斷是否為預設杆塔模型，如果是預設，則從當前的軟體目錄中讀取正確的設定，避免了杆塔路徑的錯誤。

2015.11.07 1.重大的更新，在zip壓縮時，icon.zip類是有用的類，另一個會出現中文亂碼。測試了很久，總是提示路徑有非法字元，並且生成的kmz檔案不能正常解壓，解壓也會出現中文亂碼。後來在生成kmz時限定為UTF8的編碼格式，這樣就要以用自己編寫的解壓函式解壓了。 2.解壓和壓縮竟然這麼奇葩，當設定了utf8為編碼時，壓縮生成的kmz檔案不能被谷歌地球識別，解壓後的kml連同其它資源可以識別。但如果不設定utf8編碼，則生成的kmz雖然可以被谷歌地球識別，但確無法正常解壓。用rar軟體解壓出錯，中文名亂碼。用自己編寫的函式解壓則出現路徑中有非法字元的錯誤。真的魚和熊掌不能兼得啊。 3.添加了跳動取谷歌地球高程的功能。昨晚很晚有個客戶說要提取3d建築的高程，於是根據客戶要求改寫了一款軟體，在自己電腦上提取很卡很慢，網路很慢的原因。但在客戶電腦上用的飛快，客戶說很好用，信心大增！

2015.11.09 1.為了快速提取指定點高程編寫了一個演算法，已經中心點經緯度座標算給定螢幕點的座標，利用經緯度比值的方法來反算螢幕座標是不可行的，誤差很大。只能採用跳動取點的方法，但這種方法經常出現0值和不正確的座標。查找了幾天都沒找到原因。 2.福建客戶的專案要抓緊了，拖了很久了。 3.從網上找了個快速全文搜尋datatable的函式，測試時發現，把datarow匯入datatable,出現該行已經出現在其它表中了的錯誤，後來網上找了些程式碼搞定。把dt.add(datarow)改為dt.add(datarow.itemarray)就可以了。 4.出現0值可能和緩衝有關，因為0值的出現是隨機的。因此加了個Thread.sleep(10)基本解決問題。

2015.11.14 1.修復了讀取配製的一個高程模式的comBox讀取錯誤 2.解決了生成的kmz，在用自己的解壓函式解壓時提示“路徑中含有非法字元”的錯誤。網上找了個漢字取拼音的類，在儲存為kmz裡，kmz裡面的kml的檔名完全轉換成英文字母的形式，這樣就不存在問題了。 3.Access資料庫的備註格式最大支援64kb文字，超過64kb要用二進位制ole格式。

2015.11.15 1.當圖示連結為http開頭時，zip壓縮會出現無法識別的URI的錯誤。正在解決。 2.已經解決第1點的錯誤。但標籤顏色還是有變化。 3.又被值為空的問題搞了半天。在呼叫excel轉kml專家時，出現了奇怪的問題，總是提示datagridview的行未將物件引用到物件的例項的錯誤。原來是不存在datagridview所在行的問題，但程式碼確讀取了其文字。這時不能用判斷文字是否為""的方法，而應該判斷value是否為null。但奇怪的是，在直接使用excel轉kml專家轉換時並不存在這個問題。

2015.11.18 1.添加了kml和kmz檔案的分析查詢功能 2.在呼叫excel轉Kml專家生成kmz檔案時，zip壓縮報錯。原來是圖示連結以file:///開頭或者其它未知路徑。經過分析，在excel轉Kml專家中加了一個判斷路徑是否存在的程式碼File.Exist完美解決這個錯誤。

2015.11.19 1.添加了filesearch搜尋指定字尾名型別的功能

2015.11.29 1.反覆疊加文字時，重新執行時要記住清空變數 2.生成html表時，描述文字如果有html文字時，不能勾選描述文字，否則會出錯。 3.兩次生成前記得清空一些變數，否則會疊加。 4.修復了生成多邊形時的一些bug

2015.12.01 1.把生成的html表格的標籤th換成td，這樣方便軟體統一解析。還在探索如何用XPath來同時解析th和td標籤。 2.在生成多邊形的kml檔案時，若要用kml轉excel完全解析，把地標內的表格也解析出來時，必須把前幾項名稱什麼的不勾選，否則會重複的解析。 3.vs 2012 智慧提示後為何不能 直接按enter鍵把提示的內容輸入，還的在手動按一下方向鍵選中後 在按enter 才能輸入，這個是VS的"建議完成模式"和"標準模式"，兩者間切換按快捷鍵：Ctrl+Alt+空格鍵

2015.12.04 1.添加了氣泡框中從第幾列開始全選的函式，這樣就可以為自適應查詢帶來方便。當有很多欄位的文字時，前面的屬性風格沒有必要加入到氣泡框中，否則在解析kml檔案時會重複解析。因此設計了一個從第幾列開始選擇的功能，前面預設為屬性風格可以不用選擇。

2015.12.07 1.添加了點的氣泡框中從第幾列開始全選的函式，這樣就可以為自適應查詢帶來方便。當有很多欄位的文字時，前面的屬性風格沒有必要加入到氣泡框中，否則在解析kml檔案時會重複解析。因此設計了一個從第幾列開始選擇的功能，前面預設為屬性風格可以不用選擇。

2015.12.08 1.添加了生成線的一些函式功能，以便於自動化生成，讀取ini配製，設定氣泡文字引數。

2015.12.13 1.修改了生成點時氣泡框的一些引數，可以生成html表格的模式。

2015.12.14 1.修改了儲存ini配製時刪除原來的檔案的功能 2.添加了讀取Ini配製時，不匯入列資料欄位的函式，只進行相應的設定，為自動轉換時自應用欄位使用。

2015.12.27 1.解決了GPS相片轉谷歌時，關鍵字不在字典中的錯誤，原來日期的欄位有幾個，有的相機不記錄當前欄位的日期。因此加個判斷字典是否存在當前值就可以了。 2.相片的名稱不能有下劃線_,否則圖片無法顯示

2015.12.29 1.完善了生成線時顯示線描述文字和線裡面嵌入圖片的功能，距離顯示為四捨五入，保留2位有效數字

2016.1.8 1.增加在生成線段時，匯出線段距離表excel的功能。

2016.1.18 1.根據內蒙古電力客戶的要求，添加了變壓器版本的多表查詢系統，以之前做的贛州市移動資源校驗系統為模組修改了一下，實現了簡單的雙表查詢。 2.匯入excel出現，外部表不是預期的格式，這是因為excel版本的問題。把表格開啟，另存為97-2003版本的xls就可以了。 3.datatable中若出現A8這個單元格的文字A8竟然無法顯示，太奇怪了。改成其它文字則可以，推測是與表格的單元格列名重名的原因，但目前沒解決方法。 4.錯誤為：外部表不是預期的格式 //string strConn = “Provider=Microsoft.Jet.OleDb.4.0;” + “data source=” + Server.MapPath(“ExcelFiles/MyExcelFile.xls”) + “;Extended Properties=‘Excel 8.0; HDR=Yes; IMEX=1’”; //此連線只能操作Excel2007之前(.xls)檔案 string strConn = “Provider=Microsoft.Ace.OleDb.12.0;” + “data source=” + Server.MapPath(“ExcelFiles/Mydata2007.xlsx”) + “;Extended Properties=‘Excel 12.0; HDR=Yes; IMEX=1’”; //此連線可以操作.xls與.xlsx檔案 (支援Excel2003 和 Excel2007 的連線字串) //備註： "HDR=yes;"是說Excel檔案的第一行是列名而不是資料，"HDR=No;"正好與前面的相反。 // "IMEX=1 "如果列中的資料型別不一致，使用"IMEX=1"可必免資料型別衝突。

2016.1.19 1.已經按照內蒙古電力客戶的要求實現多表聯合查詢，並且動態定位變壓器，可以實現按照客戶名、客戶編碼和電能表編號來查詢對應的變壓器。

2016.1.20 1.實現了兩個架構一樣的DataTable表的合併，自動不合並表頭，只保留一行表頭。 2.實現了從資料夾中選擇多個客戶明細表和多個線路座標表，然後對客戶明細表查詢（不包含經緯度），自動識別對應的變壓器，定位到指定的變壓器。

2016.2.6 1.實現了變壓器查詢模組下生成kmz檔案時，提示檔案被佔用時自動生成帶有日期的檔名，這樣採用java版本的world wind軟體監控檔案的生成和改變，一但有新的檔案生成且滿足條件則自動載入到java的world wind中，從而實現了C#查詢模組與java的world wind協同工作的程式。這是非常重大的一次技術進步！

2016.2.17 1.南昌電力客戶要求軟體批量轉換的過程中，出現了“字串錯誤”的bug，發現原來在判斷表格最後一行文字是否為空時，不能用datagridview…vale!=null,而要用value.toString().Trim()!="",因為空文字和沒有內容是兩回事。這樣就修復了bug.

2016.2.24 1.當把2.17號發生的批量轉換的錯誤改正後，問題又來了，在福建客戶定製的軟體查詢時，查詢點時出現未將物件的引用到正確的例項，出錯的內容正好和2.17號的相反，不能使用value.toString().Trim()!=""，因為表格最後索引沒有資料行確引用了不存在的行。思考了很久，最後在搜尋產生的表格最後新增一行空行才搞定，excel轉kml專家也做了一些相應的處理，把計算距離的遮蔽了一段程式碼。這樣查詢點才不會出錯。批量轉換的還沒測試，立馬測試！ 2.經測試，批量生成也沒有任何問題了！

2016.3.15 1.當生成線段時，因為產生了距離表，在表格中會自動新增一列，但在下次開啟表格時，竟然也會重複新增一列，因此修改了一下生成線段時的程式碼，生成後把距離表列刪除。

2016.3.22 1.添加了kml轉excel超強解析xml檔案的功能，可以解析更多複雜的檔案了，並且介面更加美觀。 2.很多bug有待於修復。

2016.4.5 1.完善了kml轉excel的選單匯出資料的邏輯功能。

2016.4.10 1.採用NPOI來匯入xlsx資料時，出現錯誤：The supplied data appears to be in the Office 2007+ XML. POI only supports OLE2 Office documents，意思是不支援2007版本的格式。百度了下，說把HSSFWorkbook換成XSSFWorkbook，但並沒有找到XSSFWorkbook類，難道是NPOI的版本問題，有待於進一步研究。網上資料又說換成XSSFWorkbook後只支援2007版本的表格，可以用如下方法解決： Workbook book = null; try { book = new XSSFWorkbook(excelFile); } catch (Exception ex) { book = new HSSFWorkbook(new FileInputStream(excelFile)); } 2.找到了一個NPOI2.2的版本的DLL,這個版本中有XSSFWorkbook類，經測試可以開啟2007版本的表格，並且我通過try-catch來捕獲異常，添加了可以同時開啟2003和2007版本的表格的程式碼。 3.但是在excel轉kml專家中，必須新增一列“無",且最後也必須新增一空行，此外還要完善初始化介面設定的功能。這樣才能用於實際。 4.因為NPOI2.2版本的ICSharpCode.SharpZipLib為8.6版本，而軟體之前已經用了一個ICSharpCode.SharpZipLib的8.5版本，這樣就不能執行通過，因此把ICSharpCode.SharpZipLib替換成8.6版本了。還沒測試是否會存在其它的異常，最好測試下生成的kmz是否正常。 5.經測試，ICSharpCode.SharpZipLib高版本沒有問題，可以正常生成kmz以及被之前寫的軟體解壓。

2016.4.16 1.完善了基站扇區生成的業務邏輯。 2.勾選單點扇區是預設重複三次每個點，不勾選則規則生成。

2016.5.3 1.在createpoint20151213中做了些改動，實現了查詢生成kml後，描述文字不做為表格的形式加入，這樣查詢後才能展現地標相片，但沒有詳細測試。

2016.5.4 1.贛州有個客戶找我，說電腦是64位的，需要安裝元件才能用excel轉kml專家。恰好我之前開發了NPOI讀取excel表的方式，於是我想徹底把office元件給拋棄，這樣就不會出現煩人的不相容和版本問題了。但之前的讀取方法也不想完全放棄，於是想到用了個try catch來判斷，如果出錯的話，則用NPOI的方法，這樣便完美了。客戶可以不安裝office元件也可以使用了，也不用考慮32位和64位系統及office版本的相容問題了，之前被office的相容和系統相容搞的焦頭爛額，現在終於解決了。不過效果沒有經過大規模的測試，希望今後能測試下。

2016.5.24 1.修改了kml、excel相互轉換匯出點的方法，採用NPOI的匯出方式，經測試4萬多條資料匯出非常快，幾秒鐘就匯出了，並且開啟這個excel表的速度也很快。

2016.5.25 1.添加了匯出線路表的功能，之前匯出的是線路座標串表，現在把線路里的座標串解析出來單獨成表。 2.添加了匯出線路表時，gcj02轉wgs84的功能。因為有個客戶從谷歌搜尋到線路，但線路有偏移，其實它是採用google map的座標系統，這樣只要把谷歌地圖和谷歌地球的偏移糾正過來就可以了。

2016.5.27 1.還有個解析KML的DLL檔案還要拷過去，否則會遇到關鍵字不在字典中的錯誤。 2.實現了線段表合成線表匯出一個表的功能，演算法還有待於優化。 3.要多學習軟體的理論，如介面、泛型、繼承等面向物件的程式設計方法還有設計模式，這樣才有利於軟體的擴充套件。

2016.5.29 1.對excel轉kml專家進行了改版，準備美化介面，簡化使用程式，提高使用者互動和體驗效能。 2.對改版的excel轉kml專家的轉點功能添加了生成shp\autocad\的格式，測試可以成功實現點、線的轉換。目前只在選單的轉點功能中加入了這個功能，預計在轉線的功能中也要加入，這樣就很方便了。 3.轉換時，把路徑拷到沒有中文的路徑中，名字取拼音，然後再生成到沒有中文的目錄下。預設為C盤或者第一個驅動器下。 4.已經加入點、線條、線段一次性生成kml\shp\dxf的功能。

2016.5.30 1.添加了生成kml\shp\cad\mapinfo\gml\gpx等功能 2.添加了點、線、線段、多邊形、基站生成以上檔案的功能，但有部分bug,有待於深入測試。 3.點線測試在dotspatial和globalmapper、autocad2015中能成功開啟

2016.6.5 1.儲存檔案時添加了初始檔名為開啟的檔名，這樣就方便多了 2.要設定一個主面版來呼叫不同的功能，否則每次除錯都要修改run函式，非常不方便，浪費很多時間。 3.功能完善後，介面設計要完善，另外還有座標系的轉換方便也要逐步完善。

2016.6.13 1.添加了改版軟體，雙擊表格時定位到谷歌地球的功能，這樣開啟任意包含經緯度座標的表格都可以設定後雙擊定位了。 2.不過綁定了谷歌地球的模式很不好，得把定位到谷歌地球的功能獨立出來。

2016.6.14 1.添加了快速開啟表格查詢的函式，實現了開啟表格，配製好轉換引數，就可以雙擊查詢轉換了。 2.邏輯結構還要優化，另外和邏輯查詢的功能也要結合起來，這樣就完美了，即可以開啟kml來查詢（kml轉換後的表格是比較穩定的，採用預設的ini配製），也可以通過開啟任意包含經緯度表格的資料來查詢，因為表格的架構不是固定的，所以必須先配製轉換的引數。

2016.6.16 1.實現了一鍵生成點線，點線段檔案並且壓縮成kmz格式，保留點的圖示資源等資料的功能。

2016.6.17 1.實現了把含有多個線段的座標資料完整提取出來合併成一個表的功能，這個功能並沒有去除重複的資料點。

2016.7.1 1.用面向物件的模式重新設計了軟體註冊模組，並且使用了註冊到ini檔案的模式註冊軟體，這樣就避免了在win7以上作業系統問題提示無法訪問登錄檔的問題（需要把軟體提升為管理員許可權）。不過現在只是寫了個註冊模組，然後寫了個簡單的測試程式，並沒有經過嚴格的測試檢驗，此外還沒有把這個功能真正的整合到軟體版本中。 2.這種註冊模式存在容易破解的問題，尤其是使用次數的限制方面，使用者很容易修改使用次數。因此還要繼續把使用次數進行加密和解密，使得使用者無法修改使用次數為小於30次。另外還要把這個Ini檔案也加密，以免使用者開啟手動修改。 3.添加了檔案加密和解密模組，從網上抄襲的程式碼，不過我也節省時間吧，能借力則借力，程式碼以後慢慢研究，已經儲存收藏起來了。經測試可以對Ini檔案進行有效的加密和解密了。

2016.7.8 1.添加了文字加密的模組，但這個文字加密模組問題很大，不能加密中文，或者是其它什麼原因，沒有測試成功。我修改的ini註冊模組也加入了文字加密，但沒有執行成功，也沒有把錯誤的更新刪除，期待下次完美解決。

2016.7.12 1.添加了cj20轉wgs84和wgs84轉cj20的功能，經測試，可以滿足奧維地圖採點後轉谷歌地球的糾偏需求。

2016.7.30 1.修改了一些註冊方面的bug，另外NPOI的版本也改成了2.2版本。

2016.8.10 1.NOPI庫在某些場合下還是會出錯，於是又遮蔽了NOPI庫。可能是表格中列太多，含有超過26列的表格就會出現這個問題，但是否是這個原因還有要進一步的測試才能確定。

2016.8.12 1.反覆生成檔案時，會出現C：\gisTem目標檔案已經存在,然後不能生成檔案。只要在File.Copy中加入一個是否覆蓋檔案就可以了。File.Copy(savepath, gisTemp + Path.DirectorySeparatorChar + targetPingYinFileName,true);後面加了個true就搞定了。

2016830 1.聯想大膝上型電腦的VS2010除錯狀態下無法彈出openFileDialog，非常惱火。但直接執行exe就可以。 2.添加了kml轉sqlite的功能，為手機地圖運用作準備。由於資料庫程式設計還不是很熟練，除錯到深夜基本實現匯入sqlite，但有很多bug要處理。

201691 1.因為系統自帶的geodata裡points表資料庫與kml轉excel軟體匯出的架構不一樣，為了能讓搜尋通用，相容系統自帶表的架構，又把kml轉excel匯出sqlite的資料庫改成了geodata points的表架構。但問題來了，C#的sqlite只支援幾種欄位資料型別，沒有geodata裡points表裡的經緯度Float的資料型別。一開始很擔心能否相容，但經過測試發現，android的sqlite用cursor遍歷資料時，cursor2.getFloat(4))如果是對應的4列裡是Text型別也可以正常查詢工作了，這樣就不用解決資料相容的問題了。

201692 1.改進了一下注冊演算法，其實之前也改過，但版本混亂了，今天給客戶演示時發現了，U盤註冊後還有幾個選單灰色，現在改進了一下。 2.今天客戶測試，一鍵生成三相線時，點和線模型偏移，原因是客戶的原始資料是度分秒寫成主的格式，而我在生成線和模型的函式時忘記了加入把度轉成度分秒來讀取的判斷。

201696 1.添加了生成線段時單獨為線段設定屬性的功能，這樣生成線段時設定線段的屬性列，因為線段比點少1，因此預設線段的屬性列對應的最後一格值無效，有內容不讀取，沒內容也不影響。 2.添加了生成點、線段、模型kmz共同體的功能，添加了一鍵生成點、線段共同體kmz的功能,但沒有時間去測試。一鍵盤生成點線段模型kmz的功能簡單測試沒有問題。

20161004 1.可能要規範下生成KML檔案的編碼為UTF8編碼，因為預設編碼的話在不同電腦不一樣，這樣就有可能出現中文亂碼。 2.通過搜尋File.WriteText，添加了Encoding.UTF8引數，由於時間問題只改了部分。

20161006 1.批量生成時，設定生成點的介面邏輯錯誤，找不到checkedbox2,因此添加了另一個chk,然後關聯正確的邏輯。 2.最好不要頻繁的更換電腦，否則會出現兩臺電腦工作不同步的問題，並且把程式碼資料在兩臺電腦中通過U盤拷來拷去也容易出錯，還會減少硬碟和U盤的使用壽命，因此最好固定一臺電腦工作，另一臺電腦則在出現問題時備用。

20161012 1.一鍵生成點線段等三個功能竟然沒有納入到註冊判斷模組中，這樣就等於開放了這個功能，因此把它們納入到註冊後使用的流程中。

20161021 1.完善了一些錯誤提醒功能，如生成線和生成多邊形時如果沒有開啟表格匯入資料或者引數設定不正確則提示錯誤。 2.修復了生成線條時，屬性迴圈匯入的錯誤。 3.修改了軟體註冊的模組，註冊介面更加簡潔，並且還可以自動把機器碼拷貝到剪下板中，這樣就很方便使用了。

20161026 1.簡化了批量修改的功能，不用反覆選擇儲存檔案對話方塊了，就直接從模板路徑中提取模板表所在的資料夾，然後自動生成到這個資料夾中。另外生成後提示是否開啟這個資料夾的檢視，這樣就知道已經生成了。 2.修復了開啟模板表時，高階地村屬性的combox沒有匯入表頭資料的錯誤。 3.完善了儲存為ini配製檔案的功能，可以儲存radiobutton的設定了。

20161115

經過測試發現，在64位系統中出現“遇到一個問題，需要關閉”這種錯誤無法執行軟體的原因是沒有安裝office2003版本，另外也有可能是系統沒有.netframework4，需要把高版本的解除安裝後才能安裝好。今天就遇到一個使用者存在這個問題，結果搞了很久，發現是沒有安裝office2003的問題，裝上後就ok了。 20161201 因為軟體賣出很多款，註冊裡的usbserailnumberList陣列越來越多，其實也不多，在放在forearch中迴圈遍歷裡，雙重的forearch估計效率很慢,竟然導致U盤插入後也無法識別。辦法就是把新的U盤序列號放到這個陣列的前面，或者重新寫一個短的資料來遍歷，為不同的客戶設定不同的序列遍歷。 20161203 添加了生成杆塔時讓杆塔偏移指定經度和緯度的函式，這樣就可以讓杆塔較完美的匹配三相線了。因為杆塔是以右上角的經緯度座標固定在谷歌地球上的，而線則是以右上角座標向右側偏移形成三相線，這樣就會導致杆塔與線偏移，經這修正，已經和線較吻合了！ 20170120 1.因為在電力杆塔巡線時，無人機拍攝的高清影象取縮圖後不清晰，因此氣泡框內沒有必要壓縮。所以在GPS相片轉谷歌軟體中添加了使用者介面邏輯，可以設定生成壓縮和不壓縮圖片的kmz檔案。 2017222 添加了形如這種表格格式的資料批量處理的功能，多條線的座標資料放在表格裡，然後以某行關鍵字分割成多個數據表格的功能，然後再利用批量生成的功能批量生成kml檔案。 之前的批量生成檔案是每個表格生成一個kml檔案，這樣匯入谷歌地球中很不方便，於是在生成線條的功能中添加了壓縮生成一個kml檔案的功能。 2017223 完善了GPS相片轉谷歌的功能，可以指定地標內的圖片不壓縮、或者取縮圖，或者指定解析度的大小。這樣就可以指定解析度的氣泡圖片的大小，功能更加完善了。 在擴充套件的過程中，採用了函式過載的方法，但這種方法顯然在擴充套件過程中非常不方便，增加了很多的程式碼量，之前沒有用面向物件的方法來處理是一種遺憾，不過現在可以慢慢完善的。 另外，之前寫的解析KML檔案的功能也是沒有采用很好的架構，以至於在擴充套件的過程中遇到很多問題，程式碼段很難定位，程式碼過於混亂，層次結構呼叫不明確等問題。今後有時間的話還是要用面向物件的方法去改寫。另外，技術達到一定的層次後，就要轉向市場的拓展了。其實這些軟體功能都很實用，使用者很多，只有讓使用者多起來，採取適當的營銷策略，才能獲得更多的回報。總之，軟體開發是一件非常高技術含量的工作，並且它是無形的，因此經常不被人理解也是正常的，但付出和回報是有一定的關係的，沒有復出就沒有回報，回報的多少就得看自己的付出和智慧了！ 解析KML過程中又出現“給定的關鍵字不在字典中”中錯誤，然後更新了一下XMLEXPLORER解析的最新庫（超大XML檔案解析的最新DLL）,錯誤就修復了！= 2017224 1.kml轉excel的功能添加了去除重複點的功能，用集思寶GPS採集的資料有資料重複，名稱不一樣，但資料的經緯度座標一樣。根據客戶要求添加了去除重複的功能，但在程式設計中又遇到了奇怪的事情，首先是datagridview的拷貝架構問題，這個問題耗費了不少時間，用datasource的方法會出現不少問題，最後用： DataTable tb1 = GetDgvToTable(dataGridView3); DataTable tb2 = new DataTable(); tb2 = tb1.Copy(); tb2.Rows.Clear(); 這個方法解決。最後，在處理匯入datagridview為excel表格時，又出現問題：//DataGridView tempdgvl = new DataGridView();

        //tempdgvl.DataSource = tb2;

這個根本無法把tb2的資料傳遞給dgv，排查了一個多小時，最後只得寫個匯出datatable的方法。 2. 未能載入檔案或程式集“System.Data.SQLite, Version=1.0.79.0, Culture=neutral, SQLITE他有區分X86與64的如果你用66版本那應是x86的我也一直用這個，如果不行 那你把CONFIG下的這個節點刪了。

201734 有客戶需要按照礦產的分類來生成點資料，一開始的想法是篩選後匯出資料新建多個表格，然後一個一個轉換，但這樣實在是費時費力.還好之前做過分類標識的生成功能,測試了一下,果然有用,看來之前的 付出沒有白費!但問題又來了,生成的資料第一個少一個點,後來修改了一下程式碼,把相應的索引減1就解決了這個問題! 剛好之前軟體有個問題! 2017325 增加了GPS相片轉谷歌地球生成線條和點、線、3d杆塔kmz的功能，重新保留生成線條kml的功能主要是要緩衝區分析中需要用到解析線條的座標資料。 201742 1使用VS2015開啟專案，增加了從SRTM資料包中提取任意區域範圍的高程資料的測試程式碼，因為這個程式碼使用了.net framework4.5,vs2010無法支援這個類庫，因此不得不使用vs2015來操作專案，以便讓這一功能模組發揮作用。但有個問題是，沒辦法匯出vs2015的sln檔案！如果用vs2010開啟NSRTM類庫會出錯，不過簡單修改就可以了，另外會提示重置為.net4.0. 201744 有的bug真的是沒法預料的，不知道是修改了什麼程式碼，導致程式啟動載入窗體後很卡，谷歌地球主視窗可以嵌入到裡面，但谷歌地球衛星地圖控制區竟然不顯示，這是在除錯狀態下的情況，直接執行又可以使用，測試其它嵌入谷歌地球的窗體確載入正常。但又不知道什麼原因導致的，現在也沒辦法解決，只能編譯後再直接在資料夾中找到程式執行，非常麻煩。Bug真的無處不在啊！ 201745 經過艱苦的除錯研究，終於實現了呼叫大奇地圖下載地圖的功能，但測試發現下載的圖很模糊，且下載區域與實際區域不一致等很多bug，看來短期內很難解決之些問題，bug太多了。不過可以肯定，不久內是可以實現這些功能的。 經測試csv檔案其實就是逗號分隔文字，空格分隔則不能識別為多列. 晚飯都沒吃，連續工作了幾個小時，就是為了解決輸出區域高程文字錯誤的問題。之前的生成的高程文字匯入GM生成等高線線，等高線竟然成了小的細胞網格。我開始以為是源資料精度的問題，但直接用GM開啟1度每格的htg源資料生成等高線並沒有問題。於是我又開始研究NSRTM原始碼，發現它再生成DEM高程文字時，還是採用的1201畫素的網格，而實際生成的範圍的網格不一樣，因此導致資料生成後密度度小很多空缺。然後找到問題原因後，我重新定義了生成區域的畫素大小，畫素大小為1201生成區的度數範圍2，然後取整。private static double _rangeDegree = 0.5; private static double _rangeDegreeLon = 0.4; private int DestpixelWidthInt =(int)(_rangeDegreeLon* 12012);//1600,900//目標畫素寬高，1度是1201個點 private int DestpixelHeightInt = (int)(_rangeDegree * 12012); 此外，要加上static才能夠寫下面兩行程式碼，否則會提示無法呼叫的錯誤。 這樣，生成的區域就可以滿足要求了，經過測試，精度還不錯。 還有不少bug沒有處理，如提取生成指定區域後，程式會假死，介面無法顯示操作。還有除錯時谷歌地球無法顯示等問題，都是嚴重的bug，必須解決的。 修改了通過放大截圖拼接的衛星地圖下載的演算法，這個演算法比之前的演算法完美簡單多了，感覺在演算法設計上又提高了一個層次。另外還修復了之前演算法的一些大問題。現在可以下載拼接，但這個截圖的方式拼接後還是有邊框和錯位的問題，因此採用其它截圖的方式來解決問題。 201749 在蘋果電腦64位系統下不會出現的問題，在伺服器windows 2008 server下確會出問題，原始碼可是完整拷貝過去的呢！主要是出現以下錯誤：“{“無法將型別為“EARTHLib.ApplicationGEClass”的 COM 物件強制轉換為介面型別“EARTHLib.IApplicationGE”。此操作失敗的原因是對 IID 為“{2830837B-D4E8-48C6-B6EE-04633372ABE4}”的介面的 COM 元件呼叫 QueryInterface 因以下錯誤而失敗: RPC 伺服器不可用。 (異常來自 HRESULT:0x800706BA)。”}，除錯了幾個小時，終於發現，原來是谷歌地球還沒有啟動時，時鐘timer已經呼叫谷歌地球了，因此引發錯誤。然後我把時鐘設定成啟動谷歌地球后手動開啟，這樣就不會出錯了！另外，我也對dll進行了一個註冊，這個註冊後還是不能用，但因為狀態無法返回，因此也不確定是不是註冊了dll的問題。 如何註冊全部dll:在開始->執行(win+r)下輸入命令:cmd /c for %i in (%windir%\system32*.dll) do regsvr32.exe /s %icmd /c for %i in (%windir%\system32*.ocx) do regsvr32.exe /s %i 另外，vs2015也有很多bug，同樣的程式碼用vs2013開啟執行沒問題，改vs2015開啟就不能運行了！這個微軟真的是個巨大bug公司啊，版本不相容，各種bug實在是太多了！ 添加了一些使用者介面互動邏輯和避免參數錯誤的程式碼。 添加了設定SRTM資料所在目錄的功能，因為在我和蘋果電腦裡只有C盤，新加入的則顯示為H盤，而其它電腦中SRTM資料則可能在D盤或者其它目錄，因此加入這個設定功能非常重要。 重構了大奇地圖下載地圖的方法，然後供這個呼叫。根據客戶要求，實現了下載高程資料和下載衛星影像資料整合在一個按鈕的功能。然後完善了一些介面邏輯處理，減少出錯的情況。 {“無法將型別為“EARTHLib.ApplicationGEClass”的 COM 物件強制轉換為介面型別“EARTHLib.IApplicationGE”。此操作失敗的原因是對 IID 為“{2830837B-D4E8-48C6-B6EE-04633372ABE4}”的介面的 COM 元件呼叫 QueryInterface 因以下錯誤而失敗: RPC 伺服器不可用。 (異常來自 HRESULT:0x800706BA)。”}，也有一種原因是谷歌地球版本的問題，必須使用谷歌地球7.12版本，如果用其它版本則會出錯。 2017415 韓教授說要SRTM1的資料，SRTM3是90m的。於是在網上找了個SRTM1的中國區資料，然後正好也是1度一格的，可以匯入到系統中。但與SRTM3不同的是，SRTM1是36013601個網格組成的資料，因此必須把12011201更改下。然後我就更改了一下基本實現了這個功能，可以靈活適應SRTM1與SRTM3的模組程式碼。 2017512 靜態變數傳遞引數時並沒有被修改，因此導致生成的dem資料取樣模糊，經過反覆測試，終於解決了這個問題，匯入3DMAX中，地形不失真，並且可以進行紋理貼圖。 2017514 添加了大地圖分割後下載的模組程式碼，還有很多bug，技術上使用了backgroundworker的多執行緒技術，採用while來判斷是否執行完畢，for迴圈來分割圖塊。 目前每次都要迴圈很長時間，還存在不少的bug，使用者互動也沒用，下次完善。另外要加強多執行緒技術的學習，這個技術用處很大，可以解決很多執行慢的及耗時的問題。 2017620 因為谷歌地球不支援圖片中帶有中文的路徑引用，因此添加了圖片取縮圖後自動把中文替換成拼音的功能，然後替換名稱中的#號，因為#號也無法讀取。這樣就可以使圖片支援中文了。經測試，excel圖片路徑中帶有中文和#號，可以正常生成能顯示圖片的kmz了！ 客戶又提出匯入奧維地圖無法顯示圖片附件的問題，然後排查了幾個小時，什麼情況都試過了，就差kml檔案的結構了，因為太複雜差點就搞不下去了。最後才發現，原來是這樣的：經過一晚上的測試竟然發現，匯入奧維地圖不顯示圖片附件的原因竟然是檔名轉拼音後有大寫字母，奧維地圖不支援圖片名有大寫的模式！，後面的zhongwen1thumbnail.jpg不能有大寫字母，而轉拼音後在拼音開頭有大寫字母！

2017625 修復了生成點後匯入谷歌地球圖示為X的錯誤，原因是圖示應該放在壓縮kmz檔案的目錄下，而之前確放在了files目錄下。 修復了一鍵生成點線和點線段的這個問題，同樣是這個問題。 經過測試，生成點線匯入奧維中可以顯示點及點內的圖片附件和線。 2017702 kmz檔案匯入奧維地圖後，附件中的圖片非常小並且不能放大，然後又改了圖片的html程式碼width和Height，但在奧維中都沒有用<img style="max - width:500px;中的500改成1500在奧維中也沒有效果。顯然奧維是讀取顯示裡面的原圖的。因此我又加了個改縮圖的功能，在使用者介面中加入可以靈活設定縮圖大小的介面。同時也讓這個可以靈活生成谷歌地球中可以顯示圖片寬度高度的大小的設定功能。軟體的功能又更完善了。ThumbnailMaxImageLength=2000;

20170711 因為生成點、點線段的功能函式變化了，因此批量的相應的程式碼也要跟著改變。之前面向物件設計的方法沒有很好的實現，程式碼結構比較混亂，因此只好通過複製程式碼，重新新增函式的方法來實現，這樣可以實現新的功能，同時又可以保留原來的功能，萬一修改失敗，很容易恢復來原來的版本。 修改了批量生成的函式，讓它能夠實現最近修改的生成點和點線可以匯入奧維的功能。儘管程式碼變的很龐大，但原來的功能還保留著。另外，還沒有時間去測試這個功能，到時聯絡客戶讓客戶去測試一下，最有可能的問題是迴圈處理時很卡的問題，還有變數沒有清空導致的一些錯誤。現在軟體已經比較完善了，下一步實現介面美化和程式碼重構優化。

20170724 今天售出一套軟體kml轉excel，客戶是做河塘測量資料處理的，客戶要求能計算出線條的長度，於是我加入了計算線條長度的模組。首先把座標串文字轉換成gmap的List類，然後再做為GMapRoute的引數構造，然後利用GMapRoute計算距離的功能來計算線條的長度，最後顯示在datatable中。 趁熱打鐵，我順便把計算多邊形長度和麵積的模組也加入到裡面了。方法還是和計算線條長度的方法一樣。

20170804 修改了mainwindow中的一些按鈕關聯程式碼，因為有客戶說起要大奇地理資訊系統9.0的功能，而這個功能已經很久沒有開發了。 林業地理資訊系統那個軟體還是比較完善的，但沒有和這個軟體整合到一起，如果整合到一起形成一套完善的軟體就會有更廣闊的市場。 另外這款軟體一直要依賴谷歌地球，如果能完全不依賴谷歌地球就完美了。雖然之前做過這方面的探索，可惜程式碼是java版本的，然後採用的是監控檔案中kml更新來實現的，不能很好的結合起來。雖然C#版本也有worldwind，但對kml檔案的解析很不完美，並且執行速度和效率也很低，因此就卡在這裡了。如果能改進C#版本的執行速度，這將是非常強大的功能。但java版本的也非常的強大，某些功能上全面超過了C#版本。所以鑑於這些問題，目前還不能很好的整合。 20170908 1.又出現給定的關鍵字不在字典中的錯誤，然後加了一個判斷 if(dic.ContainsKey(mc[j - 1].Groups[1].Value.ToString().Replace("#", “”))) 最後編譯了幾次，但不知道什麼原因dll沒有拷過去還是出錯，後來核對時間後拷貝過去就正確了。 20170919 1.有個使用者臨時加入了群，然後問座標如何支援南半球。我回復說，南半球南緯用負號表示，然後客戶按照我所說的用負號表示。但生成出來的座標出現很大的偏差，經過分析，原來是座標轉換度分秒轉度時的一個嚴重bug.把度提取出來時，沒有求絕對值就計算了，結果加法變成了減法。修正後的程式碼是：degree = Convert.ToDouble(d); if (degree > 0) { ddd = degree + Convert.ToDouble(m) / 60 + Convert.ToDouble(s) / 3600; } else { ddd =Math.Abs(degree) + Convert.ToDouble(m) / 60 + Convert.ToDouble(s) / 3600; ddd = -ddd; } 修復了kml轉mif面的bug，線的也要抓緊搞定。

20171115

"，生成點的表格第一列寬度設定為100，之前客戶說4個字會換行，改成100就不會了。

20171117 1.發現一個bug,就是形如這樣的表格：，在轉換時會出現錯誤，“System.ArgumentException”型別的未經處理的異常在 mscorlib.dll 中發生

其他資訊: 已添加了具有相同鍵的項。這是因為程式碼在處理這個路徑時，通過getfilename來取得檔名稱，而這裡後面的檔名稱2.jpg、2.jpg重複了，於是就出現了新增到字典時的錯誤。不過後來我讓客戶自己去把這個名稱改了，因此暫時不用修復這個bug。這個bug修改起來比較難，主要是要把圖片自動命名成其它的名稱，然後到時逆向轉換時圖片名又可能會出現與之前的不一致的問題。

三點建議: 1、寬度不變，長度能隨圖片長寬比例顯示 2、圖片顯示下面，表格文字顯示上方 3、地圖縮小顯示村，放大才顯示人。和谷歌地圖那樣，縮小隻顯示省份，隨地圖放大逐步顯示地市、區縣、鄉鎮、村居 改好這三點，那就相當完美了 根據客戶的要求，添加了固定寬或者固定高，然後高或寬隨比例自動調整的功能，這樣人物圖片就不會出現變形。因為改了生成縮圖的核心程式碼，程式碼還是網上找的，簡單的測試了一下，壓縮大圖時暫時沒出現記憶體洩露的問題。不過測試的圖片資料比較小，還沒有進行大量圖片的測試，希望不會出現這個問題。不過我已經做好了出現這個問題的應對措施，如果會出現這個問題，則按照原來的轉換方法。 3.發現一個奇怪的bug 圖片路徑已經壓縮，可是這張圖就是顯示為大圖

同一批次轉換，裡面的程式碼和圖都好像沒問題,我研究了裡面的程式碼和對應的圖片，圖片確實已經壓縮了，而且程式碼也沒有問題，但就是第一個點的第一張圖問題顯示大圖。後來我把kmz字尾改為zip，然後解壓後，直接執行裡面的kml檔案，第一個點不會顯示為大圖。 我又把這個kmz檔案拷到其它非桌面的地方，圖片顯示也正常，但拷回桌面就不正常了。後來測試改kmz的檔名，也能正常顯示，而且改回檔名也能正常顯示，真是奇怪的bug.

3.OpenFileDialog無法彈出的解決方法：用新建OpenFileDialog的執行緒的SetApartmentState()方法設定ApartmentState值為ApartmentState.STA，設定此執行緒為單執行緒單元。 程式碼如下所示： Thread threadRec = new Thread(openxlsbuttonclic); threadRec.SetApartmentState(ApartmentState.STA); threadRec.IsBackground = true; threadRec.Start(); 困擾我很長時間的問題解決了，再也不用除錯編譯成功又關閉程式再去資料夾找exe直接執行這種複雜的情況了。單元是程序內部具有相同執行緒訪問要求的物件的邏輯容器。同一單元中的所有物件都可以接收從該單元中的任何執行緒發出的呼叫。.NET Framework 不使用單元，託管物件自己負責以執行緒安全的方式使用所有共享資源。

由於 COM 類使用單元，因此公共語言執行時需要在 COM 互操作 的情況下呼叫 COM 物件時建立並初始化一個單元。託管執行緒可以建立並進入只允許有一個執行緒的單執行緒單元 (STA) 或者包含一個或多個執行緒的多執行緒單元 (MTA)。通過將執行緒的 ApartmentState 屬性設定為 ApartmentState 列舉值之一，可以控制所建立的單元的型別。由於給定執行緒只能初始化 COM 單元一次，因此在第一次呼叫非託管程式碼之後就不能更改單元型別。

201711118 添加了生成Region及Lod動態載入地標的生成程式碼，經過簡單測試可以實現地標隨高度變化的動態載入。方法原理：查閱KML相關的文件，然後使用sharpkml來寫了一個類來生成Region，並且封裝成一個方法。參考了北京行政區劃地標的寫法： 崇文區 #st:countycity 40.38689 39.38689 116.92526 115.92526 0 0 256 -1 0 0 研究發現它的LatLonAltBox裡的引數其實就是根據點的經緯度座標為中心擴充套件0.5度的矩形區域，而 說明：達到指定解析度數值越小，則地標在越高的地方可以;超過指定解析度消失為-1時則不消失 256這個值越小，地標則越高顯示，也就是說最小顯示時要達到的解析度。而後-1則為最大顯示時解析度應該不大於這個數值。這樣就實現了分層動態顯示了。 另外，那個解析度大小與海拔高度的對應關係要重點研究一下，這樣就可以設定海拔引數的變化來控制地標的顯示比較直觀明瞭。 解析度與層級的關係： 感覺這個表應該倒過來的。 3.把生成點的功能中的不按照專案列表來生成裡面的功能改成了氣泡文字顯示在前，圖片顯示在後面的模式

20171206

1.:混合模式程式集是針對“v2.0.50727”版的執行時生成的,在沒有配置其他資訊的情況下,無法在 4.0 原始為:

<?xml version="1.0" encoding="utf-8" ?> 　　修改為: <?xml version="1.0" encoding="utf-8" ?>

20171210 山西電信援藏專案客戶提出GPS相片轉谷歌地球圖片壓縮後保留GPS座標在圖片exif中的一個需求，因為他的資料量比較大，每張圖片有好幾M，然後圖片太多的話佔用的儲存容量就非常的大了。因此他想把圖片壓縮處理後再傳到他那裡轉換。 今天花了幾個小時的程式設計時間，終於實現了把前些時間新增的固定圖片寬度或者高度，或者任意比例這樣的一個壓縮圖片的方法放到了GPS相片轉谷歌地球軟體中，並且在網上找了個寫exif座標資訊的程式碼，然後寫成類匯入過來，經過測試可以使用。然後就是艱苦的編碼了，主要是以前面向物件的程式設計方法用的不是很好，所以程式碼比較混亂，還是處於面向過程的一種編寫方法，if else等邏輯程式碼太長了，所以編寫除錯過程比較複雜。儘管現在慢慢的轉身面向物件的編寫方法，但因為時間關係，沒有時間去修改之前的程式碼，因此只能在這面向過程的混亂的程式碼中快速新增新的程式碼和除錯。功夫不負有心人，經過編寫除錯和測試，已經可以基本實現客戶的需要了。

20171218 GPS相片轉谷歌批量轉換時，如果有圖片沒有GPS資料，則到後面統一一個對話方塊提示，避免每次提示都要按確定關閉。 修改了註冊模組，把註冊模組放到一個單獨的類裡，採用面向物件的程式設計方法，極大的簡化了程式碼，增加了程式碼的可讀性和可擴充套件性。但因為測試需要時間，經過測試大概可以滿足要求，更多問題有後續再改進。

20171222 山西電信客戶測試最新版本出現這個問題，測試環境是win10 64位，一開始我以為是win10 64位系統的問題。後來分析才發現，是ini檔案路徑的問題。改正檔案路徑後還是出現一樣的問題，後來才發現第一次使用軟體時，註冊模組的getUseTime()時，ini檔案不存在，導致提示字串錯誤。然後我加了個判斷檔案是否存在的功能，不存在則建立檔案，但仍然出現這個錯誤。然後我建立檔案後寫一次ini檔案，把time使用次數設定為0.但後面的程式碼不起作用，可能建立檔案後沒有被釋放。然後我只得用File.CreateText來把ini的欄位寫上去，然後就不會出錯了。 面向物件的程式設計思想及方法一定要多運用，靈活運用。這次註冊模組獨立寫成一個類確實非常方便，出現問題升級維護時，只要修改這個類就可以了，不用每個呼叫這個類的程式碼都去改動，所以以後一定要多用面向物件的軟體開發方式，後續升級維護將變的很簡單。 20171226 ”抄襲”網上的程式碼寫了一個顯示進度條的功能，用於顯示GPS相片轉谷歌批量轉換時顯示進度的問題。 修復了幾個bug,解決了插入U盤老提示的問題，解決了點excel\kml相互轉換顯示登錄檔問題.

20171227 當直接用父視窗呼叫processBar時會造成父視窗和子視窗都假死，這時就要用到多執行緒來呼叫。但在用執行緒時又遇到了這樣一個問題，因為生成kml的方法是在excel轉kml專家通用版本下的一個方法，而excel轉kml介面沒有顯示出來就直接用這個方法就會出現：”在建立視窗控制代碼之前,不能在控制元件上呼叫 Invoke 或 BeginInvoke”這個錯誤，而如果讓這個窗體顯示，因為在Form_load中有判斷註冊類的程式碼，就會顯示判斷註冊類的程式碼，顯然這有礙於軟體的使用。但當我把Form_load的程式碼遮蔽掉時，又遇到了新的問題，進度不顯示或者很卡，總之通過普通的方式是不能很靈活的操作這個proccessBar的。後來我發現prcoessBar的maxvalue設定錯誤，改過來還還是折騰了很久。然後就學習如何解決，最後找到了非同步執行的方法，但對非同步操作我還不是很熟練，於是又折騰了很久，終於在蘋果電腦ｗｉｎ８　６４位系統下測試成功。

public class AsyncEvent { /// /// 宣告委託 /// /// /// public delegate T MyAsyncDelegate();

    public delegate T MyAsyncDelegate2<T>(int a, int b);

    /// <summary> 
    /// 回撥函式得到非同步執行緒的返回結果 
    /// </summary> 
    /// <param name="iasync"></param> 
    public static T CallBack<T>(IAsyncResult iasync)
    {
        AsyncResult async = (AsyncResult)iasync;
        MyAsyncDelegate<T> del = (MyAsyncDelegate<T>)async.AsyncDelegate;
        return (T)del.EndInvoke(iasync);
    }

} #region 是否顯示進度條 if(showProssBar) { new Thread((ThreadStart) delegate { while(progressForm==null || progressForm.IsDisposed) { progressForm = new 進度顯示視窗(); progressForm.progressBar1.Maximum = dataGridView1.RowCount; progressForm.TopMost = true; progressForm.ShowDialog(); }

                }
                ).Start();
            while (progressForm == null || progressForm.IsDisposed)
            {

            //MethodInvoker mi = new MethodInvoker(ShowProgressBar);
            //this.BeginInvoke(mi);
           
        }

注意，在開啟processBar視窗時，也要用多執行緒的方法，否則介面會卡死。但用多執行緒時，又有個問題，就是如果視窗沒有建立，下面的程式碼又呼叫了這個視窗，就會出現找不到物件的錯誤。把以就得加入這個程式碼來等待視窗建立完畢：while(progressForm==null || progressForm.IsDisposed) { progressForm = new 進度顯示視窗(); }否則就會出現錯誤。

20171231 The maximum column width for an individual cell is 255 characters匯出2007版本的xlsx時，NPOI問題在xssworkerbook上報錯，測試了幾個小時沒辦法解決，只好換成匯出xls。但又出現字元超出255寬度的錯誤，把設定列寬的程式碼遮蔽就搞定了 添加了datatable指定第幾列中的json資料解析成列然後展開到表格中形成新表匯出的功能，採用了面向物件的程式設計方法，自己新建立了一個類。經過測試，遇到不少問題,debug後基本解決。目前測試一行資料解析生成新表沒有問題。

20180101 1.研究了一天時間，終於解決了動態型別dynamic屬性的自動遍歷的方法。一開始採用反射的方法來獲取： public void ForeachClassProperties(T model)//從json反序列化得到的類中解析出列名 { //DataColumnCollection dcc=new DataColumnCollection(); Type t = model.GetType(); PropertyInfo[] PropertyList = t.GetProperties(); foreach (PropertyInfo item in PropertyList) { string name = item.Name; Dt.Columns.Add(new DataColumn(name, typeof(string))); //object value = item.GetValue(model, null); }

    }

但這種方法傳入dyanmic型別的實體類時，獲取的確是Value、Item、Count這種屬性型別。顯然這種方法是沒有做用的，因為在解析json時,如果json的格式不固定，則根本不知道屬性的數量和具體型別。於是想通過陣列解析文字分割的方法來處理了。但後來在網上找到： foreach (string ss in DynamicObject.Keys) { if(ss!=null) { var ii = DynamicObject[ss]; dr[column + i] = Convert.ToString(ii); i++; } 這種方法，經過測試是可以使用的。

20180313 1.舒蘭林業局客戶提出分層顯示線路的需求，然後我立刻根據客戶要求做了修改。之前實現的是生成點的分層展示的功能，按理線的也是可以的。經測試，生成線條的分層展示沒有問題，程式碼很簡單，只要加入這個程式碼做些修改就可以了：{ if (checkBox16.Checked)//是否開啟Lod kmlregion = KML處理專家.用SharpKml方法建立kml.CreateRegion.createRegion(Convert.ToDouble(dataGridView1[LongitudeColumn, aa].Value.ToString()), Convert.ToDouble(dataGridView1[LatitudeColumn, aa].Value.ToString()), (int)numericUpDown16.Value, (int)numericUpDown17.Value); kmldata = conplacemarkname + creatpointname(LonLatStartRow - 1) + “到” + creatpointname(dataGridView1.RowCount - 3) + “” + kmlregion + “” 2.生成線條的功能比較複雜，要修改多個地方，因為時間的關係下次再補充修改，思路有了，應該半個小時就可以改好，當然還要測試等工作。 已經實現了轉點、線條、線段的Lod分層顯示功能模組 經測試又發現了問題，當座標資料在一個單元格內時（我用kml轉excel轉出的資料），生成線條時出錯。後來排查了很久才發現問題，原來createRegion(Convert.ToDouble(dataGridView1[LongitudeColumn, aa].Value.ToString()), Convert.ToDouble(dataGridView1[LatitudeColumn, aa].Value.ToString()), (int)numericUpDown16.Value, (int)numericUpDown17.Value);這個程式碼的引數已經不存在表格中了，表格中只是很多座標的一串集合文字。這時我只能取第一個座標資料，然後再以這個座標的經緯度來生成Region的Box,程式碼如下： //難怪會出錯，原來在同一列時，沒有單獨的資料 string[] jwd = dataGridView1[LonLatColumn, n].Value.ToString().Split(’ ‘);// string[] jwd1 = jwd[0].Split(’,’);//取第一個座標往外擴充套件1度的區域 kmlregion = KML處理專家.用SharpKml方法建立kml.CreateRegion.createRegion(Convert.ToDouble(jwd1[0]), Convert.ToDouble(jwd1[1]), (int)numericUpDown16.Value, (int)numericUpDown17.Value); 經測試可以正常生成資料。

20180316 測試發現，excel轉kml專家在轉換從kml轉excel中匯出的線條資料時，如果氣泡文字設定中全選線段屬性，就會出現轉換後的kml無法在谷歌地球中開啟的問題： 經過排查很快就發現了問題，當我用記事本開啟生成的kml時，發現description標籤下面有很多xml文字，可能就是解析上出現這個問題， 然後我在轉換時不勾選 描述文字列後，生所kml檔案就不會有問題了。 山西電信客戶反饋說GPS相片轉谷歌地球時，設定轉換後的氣泡內圖片的解析度為任意比的方法沒有效果，經過研究發現，是引數錯誤，現已經修正。這個方法中的關於解析度大小的介面關聯錯誤，設定成介面中其它老的介面了。 20180317 客戶反饋說GPS相片轉谷歌的功能提示“沒有GPS相片”時的資訊框總是在介面後面，這樣就不知道情況，如果不按Enter鍵就沒有反應。因此我把GPS相片轉谷歌這個模組中的資訊框都改成了最前顯示的效果：程式碼如下: MessageBox.Show(errorString, “提示”, MessageBoxButtons.OK,MessageBoxIcon.Information,MessageBoxDefaultButton.Button1, MessageBoxOptions.DefaultDesktopOnly);

20180411 今天有個客戶梅州金科測繪公司給了個河流流域線路圖的kml檔案讓我轉換生成excel,結果遇到了很多問題，第一個問題就是在我單位的電腦上我的軟體無法正常執行超級kml轉excel的功能，出現遇到錯誤需要關閉，但沒有其它錯誤提示，不知道是不是沒有安裝元件的原因。第二個嚴重的問題就是， 提示單元格超出最大的文字數量32787個字元，然後我就試圖把NOPI生成xls的功能改成生成xlsx，即高版本2007以上版本的excel格式。結果改動後還是出現同樣的錯誤，並且這個程式碼改動後還沒有測試，所以暫且不去管它了，只要把X改成H就可以了。 然後我就網上搜索到說改成匯出CSV的格式，於是網上找了些程式碼，結果折騰了半天。匯出的csv亂碼，沒有在一行，反而在一列。我發現網上的程式碼是有問題，但修改後還是這樣。後來才發現，原來是座標串中有逗號文字，這時，必須輸出時加上引號才可以正常輸出。 後來測試又出現問題，發現描述文字中的html程式碼也變成放到同一列多行了，這時我暫時沒時間去處理了，只得把第3列描述文字列暫時遮蔽掉。 string line = “”; foreach (DataRow dr in table.Rows) { line = “”; for (int i = 0; i < table.Columns.Count; i++) { if(i!=2) line +="""+ dr[i].ToString()+""" + “,”; } sw.Write(line); }

        line = line.Substring(0, line.Length - 1) + "\n";

添加了讀取匯出生成的csv檔案的功能，可以實現逆向轉換。但還沒有解決線的顏色的問題。 讀取csv又遇到不少的問題，主要是座標首尾有個引號，導致生成的kml線座標的首尾多了0，0，0這樣的座標空值，使得生成的線首尾都與0，0，0座標連線。後來通過文字替換的功能，把座標串中的引