企业官网建设流程全解析

简介：GDAL1.11_VS2010 是面向使用 Visual Studio 2010 进行 GIS 与遥感开发的工程师所准备的编译版本资源，解决了在旧版 VS 环境下集成地理空间数据处理库的兼容性问题。该版本在标准 GDAL 功能之上，重点强化了对 HDF、HDF5 与 NetCDF 等科学数据格式的读写支持，并同时提供 C# 与 Python 接口，便于不同技术栈的开发者调用。压缩包共 374 个文件，约 11.52MB，涵盖 83 个 dll 动态库、72 个 h 头文件、22 个 exe 命令行工具、93 个 html 接口文档，以及 py、pyd、lib、csv 等配套文件，目录按 csharp、lib、bin、include、python、data 等模块划分，结构清晰。已有 258 人学习下载，适合需要处理遥感影像、气象与海洋环境数据的中高级开发者，可借助头文件与文档快速完成二次开发与驱动扩展。

1. 为什么还有人死磕 GDAL 1.11 + VS2010 这套老组合

如果你手头维护的是一套十多年前的 C++ 桌面端 GIS 或遥感处理程序，编译链锁死在 Visual Studio 2010，而底层又依赖 GDAL 做栅格/矢量读写，那你大概率已经体会过“新版本 GDAL 根本编不过”的绝望。这套 GDAL 1.11 + VS2010 的资源，解决的就是这个具体问题：它提供了一份能在 VS2010 工具链下直接编译通过的 GDAL 源码工程，省去你从现代 GDAL 版本往回移植、改 CMake、补 C++11 特性的折腾。适合谁？维护 legacy 遥感软件的一线工程师、需要给老项目补一个格式驱动但不想升级整个工具链的人，以及被“必须用 VS2010 交付”这条需求卡住的同学。它不是给新项目用的，新项目请直接上 GDAL 3.x + VS2022。

2. 先搞清楚 GDAL 1.11 在 VS2010 下的编译链路

2.1 为什么不能直接拿新版 GDAL 源码丢进 VS2010

GDAL 从 2.0 开始逐步引入 C++11 特性，到 3.x 已经大量使用std::unique_ptr、auto、变参模板，VS2010 的编译器（MSVC 10.0）对这些支持极差，连nullptr都没有。1.11 是最后一个对 C++98 兼容得比较干净的版本，它的核心代码基本停留在 C++03 语法层面，这才让 VS2010 有编译通过的可能。另一个关键点是构建系统：1.11 时代官方同时提供nmake.opt和早期 CMake，而 VS2010 对 CMake 的支持也不完整，所以这份资源大概率走的是nmake命令行编译路线，而不是直接打开.sln。你得先接受一个现实：这不是“双击解决方案然后 F7”的体验，而是一步步配nmake.opt、跑nmake /f makefile.vc。

2.2 编译前必须确认的三件事

第一，VS2010 的命令行环境。不要用普通 cmd，要用 “Visual Studio 2010 命令提示” 快捷方式，或者手动跑vcvars32.bat，否则cl.exe、link.exe不在 PATH 里，nmake 第一步就报 “cl 不是内部或外部命令”。第二，源码目录不能有中文和空格，GDAL 的 makefile 对路径里的空格处理很脆弱，放在D:\gdal111\这种纯英文短路径下最稳。第三，确认你要不要带可选驱动。GDAL 1.11 默认编译会尝试链接一堆第三方库（HDF4、NetCDF、JPEG、PNG 等），如果你没准备这些库的头文件和 lib，要么在nmake.opt里把对应开关关掉，要么先把依赖装齐。我一般建议第一次编译先关掉所有非必需驱动，只保留 GeoTIFF、PNG、JPEG 这几个基础格式，确保能编出一个gdal111.dll，再逐步加驱动。

2.3 配置 nmake.opt 的关键参数

打开源码根目录下的nmake.opt，这是整个编译过程的核心配置文件。下面列出几个必须改的项：

# 安装路径，编译完成后头文件和库会复制到这里 GDAL_HOME = "D:\gdal111\install" # 是否编译为 DLL，1 表示是，0 表示静态库 GDAL_DLL = 1 # 调试/发布，0 为 release，1 为 debug DEBUG = 0 # 第三方库路径，按你实际放的位置改 # 如果暂时没有这些库，把对应驱动开关设为 NO JPEG_SUPPORTED = NO PNG_SUPPORTED = NO TIFF_SUPPORTED = YES GEOTIFF_SUPPORTED = YES # 是否启用 Python 绑定，VS2010 下建议先关 PYTHON_SUPPORTED = NO

改完保存，然后在 VS2010 命令行里cd到源码根目录，执行：

nmake /f makefile.vc MSVC_VER=1600

MSVC_VER=1600对应 VS2010，这个参数不传的话 makefile 可能按默认版本去找库，导致链接失败。编译过程大概几分钟到十几分钟，取决于你开了多少驱动。如果中途报某个.c文件语法错误，先看是不是那个文件属于你关掉的驱动但 makefile 还在尝试编译，检查nmake.opt里的开关是否真的生效。

2.4 编译产物与验证

编译成功后，在源码根目录下会生成gdal111.dll、gdal_i.lib（导入库）、gdal.lib（静态库，如果开了）。执行nmake /f makefile.vc install会把头文件、库、可执行文件复制到GDAL_HOME指定的目录。验证方式很简单，进install\bin目录，跑：

gdalinfo --version

如果输出GDAL 1.11.0, released 2014/04/24之类的版本信息，说明核心库没问题。再跑gdalinfo --formats看驱动列表，确认 GeoTIFF 在列。这一步能过，后面集成到你的 VS2010 工程里就只是配 include 路径和 lib 链接的事了。

3. 把 GDAL 1.11 集成进 VS2010 工程：路径、链接与运行时

3.1 工程属性里的三处配置

在 VS2010 里右键你的项目 → 属性，需要改三个地方。第一，C/C++ → 常规 → 附加包含目录，加上D:\gdal111\install\include。第二，链接器 → 常规 → 附加库目录，加上D:\gdal111\install\lib。第三，链接器 → 输入 → 附加依赖项，加上gdal_i.lib。注意是gdal_i.lib不是gdal.lib，前者是 DLL 的导入库，后者是静态库，混用会导致链接错误。如果你编译的是 Debug 版程序，而 GDAL 编的是 Release 版，运行时可能因为 CRT 版本不一致出问题，常见做法是 GDAL 和你的工程用同一个DEBUG设置，或者统一用 Release 编译业务代码。

3.2 一个最小可运行的读取 GeoTIFF 示例

配好之后，写一段最简单的代码验证集成是否成功：

#include "gdal_priv.h" #include "cpl_conv.h" #include <iostream> int main() { // 注册所有驱动，GDAL 1.11 必须手动调用 GDALAllRegister(); GDALDataset* poDataset = (GDALDataset*)GDALOpen("test.tif", GA_ReadOnly); if (poDataset == NULL) { std::cerr << "打开文件失败" << std::endl; return -1; } // 输出栅格尺寸和波段数 std::cout << "宽: " << poDataset->GetRasterXSize() << " 高: " << poDataset->GetRasterYSize() << " 波段: " << poDataset->GetRasterCount() << std::endl; // 读取地理变换参数 double adfGeoTransform[6]; if (poDataset->GetGeoTransform(adfGeoTransform) == CE_None) { std::cout << "左上角X: " << adfGeoTransform[0] << " 像素宽: " << adfGeoTransform[1] << std::endl; } GDALClose(poDataset); return 0; }

这段代码的逻辑：GDALAllRegister()在 1.11 里是必须的，不调用的话GDALOpen找不到任何驱动，直接返回 NULL。GDALOpen第二个参数GA_ReadOnly表示只读，写操作要用GA_Update。GetGeoTransform返回的 6 个 double 依次是左上角 X、像素 X 分辨率、旋转项、左上角 Y、旋转项、像素 Y 分辨率（通常为负）。参数说明：如果你的 TIFF 没有地理信息，GetGeoTransform会返回CE_Failure，此时adfGeoTransform内容未定义，不要直接用。

3.3 运行时 DLL 的放置

编译通过不代表能跑。gdal111.dll必须放在 exe 同目录，或者系统 PATH 能找到的目录。VS2010 里调试时，工作目录默认是工程目录，不是输出目录，所以要么把 DLL 复制到工程目录，要么在项目属性 → 调试 → 工作目录里改成$(OutDir)。我一般直接在生成后事件里加一行copy /Y "D:\gdal111\install\bin\gdal111.dll" "$(OutDir)"，省得每次手动拷。另外，如果你开了 PNG/JPEG 驱动，对应的libpng.dll、jpeg.dll也要一起放过去，否则GDALAllRegister时那些驱动注册失败，但不影响 GeoTIFF 使用。

4. 避坑与排查：GDAL 1.11 + VS2010 最常见的五类翻车

4.1 编译时报 “fatal error C1083: 无法打开包括文件”

现象：nmake 编译到某个驱动时提示找不到hdf.h、netcdf.h之类的头文件。原因：nmake.opt里对应驱动的_SUPPORTED开关还是 YES，但本机没装那个第三方库。解决：打开nmake.opt，把报错对应的驱动开关改成 NO，重新跑 nmake。如果已经编译了一半，先nmake /f makefile.vc clean清一下再编，否则残留的 obj 可能导致奇怪问题。

4.2 链接时报 “LNK2019: 无法解析的外部符号”

现象：你的工程里调用了GDALOpen，链接时提示找不到符号。原因：附加依赖项里写的是gdal.lib而不是gdal_i.lib，或者库目录指向了源码目录而不是 install 目录。解决：确认链接的是gdal_i.lib，并且该文件确实存在于你配置的库目录下。另一个可能是 GDAL 编译时GDAL_DLL=0生成了静态库，而你的工程按动态链接方式用，符号修饰不一致，这种情况要么改回 DLL 编译，要么在你的工程里定义CPL_DLL宏。

4.3 运行时崩溃在 GDALAllRegister 或 GDALOpen

现象：程序启动后一调用 GDAL 函数就崩，没有明确报错。原因：DLL 版本不匹配，比如你链接的是 Release 版gdal_i.lib，但 exe 同目录下放的是 Debug 版gdal111.dll，或者反过来。解决：确保 lib 和 dll 来自同一次编译、同一套DEBUG设置。用 Dependency Walker 或 VS2010 自带的 depends 工具看一下 exe 实际加载的 DLL 路径，确认没有从系统目录加载到别的版本。

4.4 中文路径下 GDALOpen 返回 NULL

现象：英文路径下能正常打开 TIFF，换成中文路径就失败。原因：GDAL 1.11 在 Windows 下默认用fopen打开文件，对 UTF-8 中文路径支持不完整。解决：在调用GDALOpen之前，用CPLSetConfigOption("GDAL_FILENAME_IS_UTF8", "NO")，然后把中文路径转成系统本地编码（GBK）再传进去。或者更省事的做法：把文件路径统一转成短路径名（8.3 格式）再打开，用GetShortPathNameAPI 转换。

4.5 nmake 报 “makefile.vc(XX) : fatal error U1077”

现象：nmake 执行到某一行报 U1077，后面跟着cl.exe返回错误码。原因：通常是某个源文件编译失败，但 makefile 没有把具体错误打出来。解决：往上翻几行，找到实际报错的.c或.cpp文件名，单独用cl命令编译那个文件看完整错误。常见的是某个驱动代码用了 VS2010 不支持的语法，或者nmake.opt里某个宏定义冲突。如果那个驱动你不需要，直接关掉是最快的绕过方式。

5. 进阶：用 GDAL 1.11 做格式转换与批量处理的几个实用技巧

5.1 用 gdal_translate 做批量格式转换

编译出来的gdal_translate.exe是最常用的工具之一。批量把一堆 TIFF 转成 PNG 或 JPEG，可以写个简单的批处理：

@echo off setlocal enabledelayedexpansion set GDAL_HOME=D:\gdal111\install\bin for %%f in (*.tif) do ( "%GDAL_HOME%\gdal_translate.exe" -of PNG -scale "%%f" "%%~nf.png" )

-of PNG指定输出格式，-scale表示自动拉伸到 0-255 范围，适合把 16 位遥感影像转成 8 位可视化图。注意-scale不加参数时按数据实际范围拉伸，如果影像有异常值（比如 -9999 填充），拉伸结果会很难看，这时要显式指定-scale 0 10000 0 255这样的范围。批处理里%%~nf是取文件名不含扩展名，%%f是完整文件名，这是 cmd 的语法，不是 GDAL 的参数。

5.2 在代码里做重投影的注意事项

GDAL 1.11 的重投影依赖 PROJ.4，编译时如果没带 PROJ，GDALReprojectImage会返回失败。如果你需要重投影功能，编译前要在nmake.opt里设PROJ_STATIC = YES并指定 PROJ 的路径。代码里创建OGRSpatialReference时，1.11 的 API 和 3.x 有区别，SetWellKnownGeogCS和importFromEPSG的返回值检查方式不同，1.11 里importFromEPSG返回OGRErr，要判断是否为OGRERR_NONE。另外，1.11 的OGRSpatialReference没有自动释放机制，用完必须手动Release()，否则内存泄漏。

5.3 验证编译产物完整性的一个习惯

每次重新编译 GDAL 之后，我会强制走一遍这个检查流程：先gdalinfo --version确认版本，再gdalinfo --formats看驱动列表里 GeoTIFF、PNG、JPEG 是否都在，然后拿一个带地理坐标的 TIFF 跑gdalinfo test.tif，看输出的 Corner Coordinates 是否正常。最后写一个十行的小程序调用GDALOpen和GDALClose，确认运行时没有崩溃。这套流程走完，基本能排除 90% 的编译配置问题。从那以后我每次换编译环境或者改nmake.opt，都强制走一遍这个检查，省得在业务代码里浪费时间排查底层库的问题。希望帮到你。

本文还有配套的精品资源，点击获取