根据最近一些用户反应，geodatatool（地图资源下载工具）3.8由于文件太大，下载起来比较困难！因此我将geodatatool中打包的PYTHON编写的哨兵2预处理包移除，这个包占用了整个工具的一半空间。

PYTHON写的东西又大、又慢，还不稳定！如果您不需要做哨兵2预处理的话，请使用小文件的包！下载起来比较快！以后会将这个功能移到数据自动批处理工具1.0中，并将其与主程序分离！避免其影响主程序的大小和稳定！

个人感觉这种不涉及图形，又需要跨平台的工具，ESA用c开发应该更合适，维护成本也不会有太大差别。程序无论从体积还是效率来说都不是一个级别!

顺便说另外一个话题，有网友谈到pyQGIS程序效率比较慢。我心想：要你看过他底层是什么，你就会说不慢才怪呢！调用层级是：PYTHON脚本调用PYHTON各类的第三方脚本库、然后调用python自身的脚本库、然后通过解释器解释语法，然后调用PYTHON本身的C接口库、然后调用第三方的c接口，然后调用真正的GIS处理C库（如：GDAL，proj）、GIS处理C库再去调用真正的数据驱动处理数据，说的我都晕了!而PYTHON的GUI程序比这个还复杂、层级还多！所以QGIS的PYTHON 程序慢不是QGIS的问题，是PYHTON程序的结构问题。而且Python的开发模式就是各种包松散的互相堆砌，也没有一个完整的官方体系审核，其实也没法有太庞大了谁会免费维护这样的体系啊!加上Python本身定位就是给非专业开发人员用的，这体系不乱才怪呢!而且程序效率稳定性都会很差!

但有人会说ArcPy就比较快啊!我想也只是比较快,因为QGIS没有ARCGIS那么多钱能将PYHTON这种凌乱的架构重头梳理优化，他们还是用的各个开源库的原始版本！但即使优化，相对C编写出来的QGIS核心模块来说也一定是后者快！

  传说那种完全没有设计架构，胡乱堆砌代码随心所欲的编写方式，由于使用了PYTHON这种开放的语法结构和包容的编译环境成为现实！写代码的的方式和我做面条一样：水多了添面，面多了添水，最后和了一大盆面，不知道该咋办好。反正倒是能吃饱，至于时间和资源浪费就管不了。现实做项目中也是：很多时候软件写的烂，最后就只能靠硬件堆砌硬件及服务器来解决，从小软件到大型系统都是如此！