2017331
1.读懂了代码，创建了自己的测试项目，试图把wpf的程序改成可以与我现有程序兼容的winform程序。目前还在初级偿试中。
2.测试中遇到了很多错误，如DLL导入问题，命名空间问题，然后通过百度和自己思考一一解决了。还有什么代码安全问题，这些问题需要在编程中逐步积累，有的还是第一次遇上。
3.wpf的demo窗体程序竟然不能直接编译为类库，编译时会出错。也不知道微软是怎么想的，可能它和winform程序不兼容或是自己还没找到正确的方法呢！
4.我的想法是把它改成一个可以读取任意区域数据的软件，然后导出文本或者excel的高程数据，这样就可以不依赖于谷歌地球了，极大的提高了提取高程区域的效率和应用范围，然后就可以和卫星地图下载的程序套合在一起，实现一步生成卫图和地形DEM，然后可以导入三维软件中进行仿真。当然这目前只是个设想，要动手去实现还要付出很多努力。
5.另外，要能像worldwind这样读取DEM自动生成地形，大面积动态访问就非常完美了。所以也要多研究下，让world读取本地的srtm来创建地形。看来这一方面的进步还要一两年时间，但可以预见，今后一定会有更大的突破！
6.经过一天的测试，终于实现了读取指定区域范围的数据然后生成一段高程文本的功能。一开始用messagebox来调试，但数据量估计太大了，显示不出来，然后又有其它的一些问题。最后采用输出文件的方法，终于实现了输出高程文本的功能。但输出的文本1度1格的有50多M，还是打不开。不过用Global Mapper可以打开，打开时选择逗号分割，创建3D风格，打开后完美生成了光栅图！
7.Global Mapper输出DEM时可以设置采样间距，单位为米，这样输出的DEM文件会比较小，然后就可以导入到3DMAX中来处理了，进行3D打印等！
201741
1.实现了指定经度跨度和纬度跨度来提取区域高程的功能，非常强大。这样就可以完全不依赖于谷歌地球来离线提取数据了，然后与卫星地图下载结合起来，就可以轻松实现地形模型叠加卫星图片的功能，实现虚拟仿真的功能。
201745
1.晚饭都没吃，连续工作了几个小时，就是为了解决输出区域高程文本错误的问题。之前的生成的高程文本导入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* 1201*2);//1600,900//目标像素宽高，1度是1201个点
private int DestpixelHeightInt = (int)(_rangeDegree * 1201*2);
此外，要加上static才能够写下面两行代码，否则会提示无法调用的错误。
这样，生成的区域就可以满足要求了，经过测试，精度还不错。
2.生成bitmap的功能还没修改，直接屏蔽了，不然会出现索引错误。反正现在用不上，下一步深入研究再改。
2017415
1.韩教授说要SRTM1的数据，SRTM3是90m的。于是在网上找了个SRTM1的中国区数据，然后正好也是1度一格的，可以导入到系统中。但与SRTM3不同的是，SRTM1是3601*3601个网格组成的数据，因此必须把1201*1201更改下。然后我就更改了一下基本实现了这个功能，可以灵活适应SRTM1与SRTM3的模块代码。
2017512
1.静态变量传递参数时并没有被修改，因此导致生成的dem数据采样模糊，经过反复测试，终于解决了这个问题，导入3DMAX中，地形不失真，并且可以进行纹理贴图。
2.添加了方便测试的代码，可以不用把dll拷到其它地方就可以运行测试。