excel、kml相互转换升级日志

大奇软件研发中心，版权所有，欢迎转载

软件作者：兴国县朱明软件工作室，官方网站：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.20
1.改写了一个JAVA的GPS纠偏算法的代码，可以完全实现kml导入谷歌maps的无偏移效果，精度很不错。
原文地址：http://blog.csdn.net/junfeng120125/article/details/9966857

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，但在奥维中都没有用 最后编译了几次，但不知道什么原因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
原始为:

　　修改为:

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(int a, int b);

    /// 
 
    /// 回调函数得到异步线程的返回结果 
    /// 
 
    ///  
    public static T CallBack(IAsyncResult iasync)
    {
        AsyncResult async = (AsyncResult)iasync;
        MyAsyncDelegate del = (MyAsyncDelegate)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坐标连线。后来通过文本替换的功能，把坐标串中的引号替换就搞定了。

20180412
经过一晚上的努力，终于实现了kml文件与csv格式逆向转换的功能，经测试可以导出修改后再生成kml,并且保留线的颜色和宽度等风格。excel转kml专家中设置时要注意，取消“单一地标风格”的勾，然后再设置线为同一坐标中，再设置线的名称以及在高级设置中设置线的颜色和宽度对应的列，然后生成线段就可以转换了。非常强大 。
同样在处理csv中的xml文本时遇到问题，导出时干脆把xml文本给设置为空。

转换效果非常不错。不过属性标签丢失，这个后续还要研究下，之前解决了，但不是很完美，好像会出现一些bug和错误。
客户测试发现从谷歌地球中画的线条数据导出出现异常，
分析发现原来还有几列NStyle和HStyle也有xml文本，所以也要把这几个数据清空才能正常导出。
4.客户给了一个奇怪的kml文件，无法导出点线坐标数据。经过分析发现，原来里面的数据标签格式是
gx:Track
gx:coord116.6064049 24.19964733 0
这样的格式，所以不能用解析kml的方法解析。然后我就写了一个解析这个数据的方法，可以解析这种数据格式了。
导出点时出现，无法访问已经关闭的流。 NOPIHelp.cs类中屏蔽这行代码ms.Position = 0;就可以了。

20180618
1.突然发现excel转kml专家出现乱码：
问题可能出在： string strConn = “Provider=Microsoft.Ace.OleDb.12.0;” +“data source=” +
Path + “;Extended Properties=‘Excel 12.0; HDR=YES; IMEX=1’”;
只好改成NOPI的版本。之前测试没发现问题，难道是软件清理时把office相关的一些组件给清理掉了？好在及时发现，不然新版本如果存在这样的错误，我的软件就可能给用户造成不好的映像啊。

20180723
在生成线段时，又遇到了bug，坐标的第一列总是会自动替换成距离数据。但排查代码没有发现问题，我后来才发现，问题出在columncount上，这个变量定义了局部和全局变量，导致在代码的前段用的局部变量，后面用的是全局变量，而全局变量的默认值是0，所以后面的索引就把距离数据放到了第一列了。

20180727
1.
这个问题好像是没有安装office2003的原因，之前遇到过很多次，都忘记了怎么处理。要不没安装.net framework4.5也会出现错误。

20180731
程序在GPS相片批量转谷歌时出现：
一开始以为是运行环境的问题，比如office版本或者是.net版本的问题，而调试中也确实出现了提示性错误，说office版本14不兼容什么的System.IO.FileNotFoundException: 未能加载文件或程序集“office, Version=
后来测试发现其实这个影响不大，原来又是字典值的问题,图片的exif信息不全，我没有判断空值就调用了。
然后为每个都加入了判断是否为空值的问题。

20180814
1.添加了两种打开表格的模式，这样就可以采用NPOI和OFFICE两种方法打开了。实际工作中，我们可能遇到的只是一些简单的文本文件带有坐标，这时如果要转换成excel表又太麻烦了。于是我添加了几个打开不同格式文本文件的功能模块，这样坐标写在文本文件中也可以转换，非常方便。其实文本文件的格式还很多，要想全面还是有些难度，以后慢慢添加修改。
2.添加了打开多种类型经纬度文本表的功能模块，这样就可以满足日常处理中的大部分要求。
3.网友发来一个经纬度表，这个表是这样的格式的：
4.显然里面的坐标有点不一样，然后我就专门写了一个转换这个表的功能模块，就是把坐标转换成Kml多边形里可以识别的坐标，然后根据已有的转换功能生成就可以了。