5
编译使用ArcGIS地理处理工具的Python脚本（至.exe）？
我已经使用Python编写代码已有几个月了，并且已经为主要的地理处理任务开发了一些相当复杂的脚本。话虽这么说，但由于我来自SQL / VBA / VBScript背景，因此我仍在学习很多东西。 我知道编译后的代码通常比语言解释器要处理的代码运行得更快，因此我对将地理处理Python脚本编译为.EXE文件以处理大数据的可能性感兴趣。 这有可能吗？如果是，那么编译正在导入arcgisscripting或arcpy模块的Python（.py）脚本的最佳方法是什么？ 我花了几分钟试图找到我想做的事，搜索结果返回了这篇文章，其中包括：http : //www.ehow.com/how_2091641_compile-python-code.html 编译器似乎可以工作，但是在执行生成的.EXE文件时，出现了一个神秘错误，表明某些文件不可用。 Python脚本可以从命令行正常运行，但是我想知道如果我能够编译.py文件，是否可以看到一些细微的改进。同样，我正在处理一些需要20多个小时才能处理的大型数据集（从输入的水质采样点确定流域）。我会采取一切我可以改进的方式。 使用一组测试站点，与从ArcCatalog的新工具箱中将脚本设置为脚本工具相比，从命令行在ArcGIS外将脚本运行速度提高了10％。我一直从命令行运行脚本，而没有在专用计算机上打开的任何ArcGIS实例。 因此，是否可以编译导入arcgisscripting模块并调用ArcToolBox工具的Python脚本？ 编辑 感谢您的输入，这对我很有帮助。该脚本主要是一种协调许多ArcGIS工具并以所需格式/位置/具有适当属性的输出的方式。我认为通过写临时文件夹而不是临时栅格文件的临时个人地理数据库，可以减少一些麻烦，因此可以将它们存储为ESRI GRID格式和IMG格式。我将检查探查器的建议。 我办公室里有一些人对Python提出质疑，主要是说与经过编译的Visual Basic程序或VB.NET程序相比，“经过编译的代码比通过解释器运行的代码要快得多”，但这是一个很好的观点，无论哪种方式，工具都将花费时间。而且，似乎对于当今的计算机而言，解释代码可能不会比编译后的代码慢那么多，以保证可以加倍努力。 编辑 -使用光栅格式更新程序的优化。 想跟进我对该Python程序的“优化”，并且通过将临时栅格写入GRID格式而不是个人地理数据库中，从而节省了2个小时的处理时间。不仅如此，数据大小的磁盘空间消耗显着减少。我最初编写所有栅格的过程（它们只是转换为栅格的点要素，然后是分水岭的栅格），仅这些文件就产生了37.1 GB的数据。将后两个数据输出以GRID格式写入文件夹时，数据减少到667 MB。 我很想知道文件GDB如何处理这些数据，尽管主要是通过数据大小来实现的。但是，将我的处理时间从9.5小时减少到7.5小时肯定足以倡导以GRID格式处理地理数据库之外的栅格。