简介postgis-bundle-pg15-3.5.0x64.zip 是一份面向 PostgreSQL 15 的 64 位 PostGIS 3.5.0 安装包专为需要在 PostgreSQL 中存储、处理与分析地理空间数据的开发者、数据科学家和 GIS 工程师准备。相比 Oracle Spatial 等商业方案PostGIS 完全开源且符合 OGC 规范可让 PostgreSQL 变身功能完整的空间数据库广泛用于 WebGIS、空间数据中台与地理分析业务。压缩包共包含 1335 个文件以 sql 数据库扩展脚本、dll 核心运行库、csv 与 tif 示例数据为主另有 control 扩展控制文件、bat 安装脚本、exe 辅助工具、多份说明文档及矢量/栅格样例整体约 130.74MB目录结构清晰便于离线部署与二次查阅。目前已有 190 人学习下载。安装后可快速启用 PostGIS、PostGIS Tiger Geocoder、Pointcloud、pgRouting 等扩展结合包内示例数据既能验证几何运算、坐标转换和空间连接等基础能力也能体验栅格处理与路径分析等进阶场景。配套的说明文档还能帮助离线排错使初学者可顺利上手有经验者也能将其作为稳定组件库直接融入生产环境适合在 PostgreSQL 中构建轻量级 GIS 中间层或空间分析平台。1. PostGIS 3.5.0 配 PostgreSQL 15这个 x64 的 zip bundle 到底能帮你省多少事很多刚接触空间数据库的朋友第一次听说 PostGIS 是在翻 PostgreSQL 资料时看到的知道它能让数据库处理经纬度、几何图形、路网拓扑但真要装的时候往往卡在“从哪里下、下了以后怎么和 pg15 对上号”。postgis-bundle-pg15-3.5.0x64.zip就是为 64 位 Windows 上的 PostgreSQL 15 准备的一整套 PostGIS 3.5.0 运行时和扩展文件它不是那种双击 next 的图形安装器而是一个绿色目录包解压后通过控制文件、批处理脚本和 SQL 扩展机制把空间能力挂进数据库。对做土地、规划、物流、GIS 二次开发的人来说这份资源解决的核心痛点是不需要自己编译源码、不需要手工找依赖 dll就能在 pg15 上把几何类型、空间索引和路网分析函数跑起来。它适合两类人一是刚搭好 PostgreSQL 15 想尽快拥有空间库能力的开发者和数据分析师二是要给离线环境批量部署 PostGIS 的运维同事。2. 为什么是扩展而不是独立数据库PostGIS 的 extension 机制与版本边界2.1 从 postgis.control 看懂 PostGIS 的运行方式把 zip 解压后你会看到一堆.control文件postgis.control、postgis_tiger_geocoder.control、pointcloud.control、address_standardizer.control、pgrouting.control。这些看起来不起眼的文本文件是 PostgreSQL 扩展机制的入口。PostgreSQL 从 9.1 开始支持CREATE EXTENSION它要求每个扩展包在share/extension目录下放一个同名.control文件里面写明扩展名、默认版本、依赖关系、需要的动态库。拿postgis.control来说典型内容会包含comment、default_version以及类似relocatable true的声明还有requires字段指向postgis_raster之类的子扩展。当你执行CREATE EXTENSION postgis;PostgreSQL 会去这个目录找控制文件、找对应的postgis--3.5.0.sql脚本再加载postgis-3.dll把函数和类型注册进当前数据库。这套机制的好处是PostGIS 不是一个独立进程而是寄生在 PostgreSQL 里的一组函数和数据类型。几何类型geometry、地理类型geography、空间索引 GiST 支持全部通过扩展脚本写入系统目录。这意味着你可以按需开启不需要的库就不建性能和体积都可控。bundle 里同时出现pgrouting.control和pointcloud.control说明这个包还额外集成了 pgRouting 路线分析模块和点云模块装完 PostGIS 后可以一起启用省得再去单独匹配版本下载。版本匹配是最容易被忽略的PostGIS 3.5.0 是为 pg15 编译的动态库postgis-3.dll是用 PostgreSQL 15 的头文件和 ABI 构建的你把它丢到 pg16 上大概率报版本符号错误这就是“扩展机制看着简单、实则绑定严格”的第一道边界。2.2 OGC 规范在函数命名上的落地从 ST_ 前缀到地理坐标系PostGIS 能成为开源 GIS 数据库的事实标准核心原因是它实现了 OpenGIS Simple Feature for SQL 规范。规范要求空间函数带ST_前缀即 Spatial Type 的缩写比如ST_AsText、ST_GeomFromText、ST_Intersects、ST_Distance。这套前缀约定让从 Oracle Spatial、MySQL Spatial 迁移过来的人能很快上手SQL 方言差异降到最低。bundle 里的 SQL 脚本会把几百个ST_函数注册进数据库同时创建spatial_ref_sys元数据表里面存的是几千条 SRID 定义包括 WGS84 的 4326、Web 墨卡托的 3857。spatial_ref_sys表本身就是一个权威坐标系字典比你去网上找 EPSG 对应关系可靠得多。PostGIS 3.5.0 在类型设计上也做了取舍geometry类型用平面坐标系计算geography类型用椭球面计算二者存储相同的数据精度和性能取向不同。默认推荐用geometry只有做跨国距离、跨大洲航线这类需要考虑地球曲率时才切geography。熟悉这套设计的工程师都知道许多空间数据“算错了”不是 PostGIS 的锅而是把 4326 经纬度数据当平面算距离结果差几倍。所以装完 PostGIS 的第一件事我一般会建议新手先理解 SRID 和坐标系再谈函数调用否则后期的数据精度问题会成为巨大的排查黑洞。2.3 版本绑定的边界为什么这个 bundle 不能随便跨版本用PostGIS 3.5.0 要求 PostgreSQL 15 或者更高版本这是编译期的硬绑定。Windows 下的 zip bundle 和 Linux 下通过 apt/yum 装的版本还不太一样Linux 发行版可能用postgresql-15-postgis-3这样的独立包而 Windows 这个 zip 包是 WinGIS 社区维护的预编译产物。判断一个 bundle 是否正确除了看版本号还要看目录结构是否完备lib下要有postgis-3.dll、geos.dll、proj.dll、gdal.dll这一串依赖share/extension下要有成对的.control和--3.5.0.sql脚本。GEOS 提供拓扑算法和几何操作PROJ 负责坐标系转换GDAL 负责栅格读写这三个 dll 缺失任何一个装完扩展可能提示成功但跑ST_Transform或栅格相关函数时直接报“无法找到指定模块”。这是典型的“安装十分钟、排错一整天”的坑。所以下载后第一件事不是急着解压建库而是先核对目录结构确认这套 dll 都在再开始安装流程。3. 从 zip 到可以跑ST_GeomFromText安装与建库完整实操3.1 解压与目录部署别急着双击 .bat先看三个目录在 Windows 10 或 Windows 11 上下载完postgis-bundle-pg15-3.5.0x64.zip以后我习惯先右键属性确认文件大小并勾选“解除锁定”再解压到固定目录。为什么会卡在这一步Windows 系统会从 Zone.Identifier 标识文件来自网络后续运行脚本时杀毒软件或系统策略可能拦截 dll 加载表现是权限报错或者“已阻止此应用”实际上就是流标记在作怪。解压到C:\pgsql\postgis-bundle这一类不带空格的路径下能省掉后续很多“路径中是否有空格导致找不到文件”的麻烦。常见做法是解压后得到以下结构C:\pgsql\postgis-bundle |---bin |---lib |---share |---extension |---contrib |---postgisbin目录下有shp2pgsql.exe、pgsql2shp.exe、raster2pgsql.exe这三个加载工具它们是从 shapefile 导入和导出数据的主力lib目录存放运行时 dllshare\extension专门放.control和 SQL 脚本。如果你原本的 PostgreSQL 15 安装在C:\Program Files\PostgreSQL\15建议直接把 bundle 解压到这个目录的对应位置让扩展文件并入 PostgreSQL 自己的搜索路径。这样做的原因是 PostgreSQL 查找扩展时优先看它编译时指定的SHAREDIR如果 bundle 解压在独立目录就必须把bin加进系统PATH并在数据库里手动指定dynamic_library_path否则CREATE EXTENSION会报找不到控制文件。如果你不想合目录用独立目录方式也可以我一般会做一个固定符号链接或设定环境变量PGSHARE但为了少踩坑第一次部署还是走“并入 PostgreSQL 安装目录”这条路最稳。合并之后检查一下share\extension下的文件数量和版本号是否对齐重点看postgis--3.5.0.sql和postgis.control是否在同一目录这两个文件如果有一个查找不到扩展创建就是个死局。3.2 用批处理一键建库makepostgisdb_using_extensions.bat 的真实用法bundle 里自带了一个makepostgisdb_using_extensions.bat这个脚本是给你省事用的它做的事情等价于先连上 PostgreSQL 服务器创建一个新数据库然后在这个库里执行CREATE EXTENSION postgis。不过直接双击运行它大概率会失败因为脚本需要知道你的 PostgreSQL 超级用户密码和端口。我一般会先打开命令提示符手动执行里面的关键逻辑这样每个环节的结果都能看到。先确认 PostgreSQL 的 bin 目录在 PATH 里set PATHC:\Program Files\PostgreSQL\15\bin;%PATH%接着用psql验证连接psql -U postgres -h localhost -p 5432 -c select version();如果提示密码输入你的 PostgreSQL 超级用户密码。连接成功后再执行建库命令CREATE DATABASE gisdb WITH ENCODING UTF8 OWNER postgres;然后连接这个新库创建扩展psql -U postgres -d gisdb -c CREATE EXTENSION postgis;看到CREATE EXTENSION字样返回说明核心空间扩展已经装好。想验证安装是否完整用一行 SQL 查版本SELECT postgis_full_version();返回结果里会包含POSTGIS3.5.0、GEOS...、PROJ...这些字样。注意脚本默认用的做法往往是先创建数据库再切进去如果你的服务器上已经有现成的业务库也可以直接在业务库里创建扩展不需要单独建库。如果脚本里还有-U和-P参数位的填写说明把它们替换成你的实际用户和密码即可。3.3 加载可选模块address_standardizer、tiger_geocoder、pgrouting 的启停顺序PostGIS 装完之后bundle 里还有几个可选扩展。它们的加载顺序有讲究。第一个是postgis_tiger_geocoder这是美国地址匹配模块依赖postgis和fuzzystrmatch。启用它之前先创建依赖扩展CREATE EXTENSION fuzzystrmatch; CREATE EXTENSION postgis_tiger_geocoder;第二个是address_standardizer地址标准化模块它有一个配套的address_standardizer_data_us.control用于加载美国地址数据规则。如果你处理的是国内地址这个模块用处不大但也不能随意DROP因为它可能被 tiger_geocoder 引用。第三个是pgrouting.control对应的路由扩展用于最短路径和路网分析CREATE EXTENSION pgrouting;pgrouting 启用后可以用pgr_dijkstra这类函数做路径规划。请注意如果CREATE EXTENSION pgrouting报参数错误多半是依赖的lib下的pgrouting-3.5.dll没有随主扩展一起注册此时需要检查动态库路径。加载顺序我建议固定为postgis→postgis_raster如果要做栅格→postgis_topology如果要做拓扑→pgrouting→postgis_tiger_geocoder。这样后加载的扩展能找到先加载的类型和函数。不要反着来否则会出现type topology does not exist这类莫名其妙的错误折腾半天才发现是顺序问题。3.4 shapefile 数据入库shp2pgsql 加载器的参数和中文编码坑扩展建好后空间数据怎么进数据库最常用的路径是通过shp2pgsql工具把 ESRI Shapefile 转成 SQL 再导入。这个工具的经典用法是shp2pgsql -s 4326 -d -I -W UTF-8 C:\data\parcels.shp gisdb.public.parcels | psql -U postgres -h localhost -d gisdb逐段拆开看-s 4326是指定源数据坐标系 WGS84这样导入后几何字段会带上正确的 SRID-d是导入前先删除同名表-I是在几何列上自动创建 GiST 空间索引这是查询性能的关键。-W UTF-8是声明 shapefile 的.dbf属性表编码。这里有个血泪经验国产数据经常是 GBK 或 GB2312 编码如果你不清除编码导入后中文属性全部乱码而且这个乱码是不可逆的只能删表重导。我一般会先看.cpg文件里写的什么字符集如果它的内容和实际不符就以实际内容为准多试一次。导入后查一下记录数SELECT count(*), ST_SRID(geom) FROM parcels GROUP BY ST_SRID(geom);如果记录数和原始数据对得上SRID 是 4326这一步算成功。反过来导出数据用pgsql2shp工具pgsql2shp -f C:\data\export_parcels.shp -u postgres -P yourpassword gisdb SELECT * FROM parcels这个工具的参数相对简单但注意-P密码在命令行里是明文多人共用服务器时要小心操作历史泄露。4. 避坑指南PostGIS bundle 安装失败的四个高频现场4.1 现象执行 CREATE EXTENSION postgis 报错 “could not open extension control file”这是新手最常遇到的错误之一。打开数据库执行CREATE EXTENSION postgis;后PostgreSQL 返回类似could not open extension control file C:/Program Files/PostgreSQL/15/share/extension/postgis.control: No such file or directory。原因多数是你把 bundle 解压到了独立目录但忘记把它并入 PostgreSQL 的share目录或者解压到了share\contrib而非share\extension。PostgreSQL 在 Windows 下查找控制文件时会走它自己编译时的相对路径它不知道你额外解压了一个目录到别处。解决方法是把 bundle 中的share\extension目录内容全部复制到 PostgreSQL 安装目录下的share\extension注意是“复制内容”而不是“复制这个文件夹”。复制后在命令行执行ls C:\Program Files\PostgreSQL\15\share\extension\postgis.control确认文件在这个路径下再重新执行建扩展命令。4.2 现象create extension 成功但调函数报错 “could not load library postgis-3.dll”扩展创建成功的提示有了但一执行SELECT ST_Point(0,0);就报动态库加载失败。这类问题往往不是数据库本身的问题而是系统缺少 Visual C 运行库。PostGIS 3.5.0 的 dll 是用 Visual Studio 2015-2022 工具链编译的对应的运行库叫Microsoft Visual C 2015-2022 Redistributable (x64)。机器上如果只有 2013 或更早的运行库dll 加载时会静默失败。解决步骤是先下载并安装最新的 vc_redist.x64.exe装完不用重启数据库直接重新执行SELECT postgis_full_version();验证。如果还不行打开事件查看器查 Windows 日志里 Application 分类下的错误里面会写成因模块的完整路径和错误偏移量。还有一个此时容易被忽略的点dll 依赖的libstdc或libgcc在 Windows 上通常不需要但如果是从非官方渠道下载的 bundle可能带一套 MinGW 依赖冲突后症状和缺运行库一样。遇到这种问题优先换官方 WinGIS 预编译包不要再花时间在未知来源的包上。4.3 现象shp2pgsql 导入时中文乱码或几何字段为空的玄学导入后打开属性表中文全部变成“锟斤拷”或者几何字段geom是 NULL但记录数不少。中文乱码的根因在.dbf的编码声明和-W参数不一致。-W UTF-8只对按 UTF-8 编码的源文件有效如果你的 shapefile 实际是 GBK必须用-W GBK。很多从 ArcGIS 导出的数据.cpg文件写的是 UTF-8但 dbf 内部还是 GBK这种不一致是最难的。我一般会在导入前用文本编辑器打开.dbf的二进制头找字段定义里的字符集标记或者用一个很小的 Python 脚本判断编码然后决定-W参数。几何字段为 NULL 的根因通常是-s指定了错误的 SRID或者 shapefile 几何类型与库内已有的字段约束冲突。之前遇到一个案例数据是面状地块但误配了-s 3857后续做距离查询时结果差得离谱还有一次是geom字段已经有了CHECK约束导入的多边形自相交记录被约束拦下表现为导入成功但几何为空。解决方法是导入前先跑一遍shp2pgsql -s 4326 -G C:\data\parcels.shp temp_parcels用-G参数生成的是使用geography类型的导入脚本它会比geometry更严格地检查数据合法性把非法几何在导入时暴露出来。4.4 现象pgRouting 的 CREATE EXTENSION 报错 “undefined symbol: pgr_dijkstra”主 PostGIS 扩展创建成功但CREATE EXTENSION pgrouting;时提示找不到符号或者函数创建成功后调用即崩溃。这不是偶然pgrouting是独立编译的它的 dll 依赖lib\pgrouting-3.5.dll但它在运行时还依赖libpq.dll和postgis-3.dll。如果postgis-3.dll不被系统路径找到符号解析就会失败。解决方法是把 bundle 的lib目录整个加进系统 PATH并且在 PostgreSQL 的配置里指定动态库路径。在postgresql.conf中找到dynamic_library_pathdynamic_library_path C:/pgsql/postgis-bundle/lib:$libdir改完重启 PostgreSQL 服务。注意这里的路径分隔符在 Windows 上可以接受正斜杠推荐这么写避免反斜杠转义问题。改完配置再执行一次CREATE EXTENSION pgrouting;一般能解决。如果还不行检查是否在同一个会话里多次切换数据库导致 dll 句柄混乱干净的做法是重开一个 psql 会话再做验证。5. 安装之后的进阶验证用一组 SQL 指标判断你的 PostGIS 真正健康可用扩展建完、数据导入完成不等于一切正常。我习惯在交工前跑一套五个指标的验证 SQL它能覆盖空间函数、坐标系、空间关系、索引行为和栅格能力把“看起来装了”变成“确实能用”。首先是函数可用性执行SELECT ST_AsText(ST_GeomFromText(POINT(116.4 39.9), 4326)) AS wkt_point;正常返回POINT(116.4 39.9)说明几何类型和 WKT 解析器正常。接着验证坐标转换SELECT ST_AsText(ST_Transform(ST_GeomFromText(POINT(116.4 39.9), 4326), 3857));返回的坐标值落在大约x12958175、y4855646附近说明 PROJ 库正确加载。这一步同时验证了 4326 到 3857 的投影参数在spatial_ref_sys表里有定义。第三项验证空间关系SELECT ST_Intersects( ST_GeomFromText(POLYGON((0 0,0 10,10 10,10 0,0 0)), 4326), ST_GeomFromText(POINT(5 5), 4326) ) AS is_intersects;正常返回t。接下来是空间索引是否可用。基于一张真实表parcels执行EXPLAIN SELECT count(*) FROM parcels WHERE ST_DWithin(geom, ST_GeomFromText(POINT(116.4 39.9), 4326), 0.01);计划里出现Index Cond: (geom ...)以及Bitmap Index Scan说明 GiST 索引被正确使用如果只有一个Seq Scan检查是否漏建索引。最后看栅格扩展和拓扑扩展是否随主包一起注册SELECT name, default_version, installed_version FROM pg_available_extensions WHERE name IN (postgis,postgis_raster,postgis_topology,pgrouting);如果postgis_raster的installed_version是空说明还需要单独执行一次CREATE EXTENSION postgis_raster;。这五个指标全部通过的机器才能放心交给业务方。从那以后我每装完一次 PostGIS不管是给别人部署还是自己练手都会强制把这条验证链路走一遍。整套流程熟练之后从拿到 zip 到五指标全绿大概不到二十分钟。中间最浪费时间的那一步永远是版本目录没对齐就急着建库结果在排错上多花一晚上。希望这份拆解能让你把时间花在真正该做的事情上比如空间分析本身而不是和 dll 打架。希望帮到你。本文还有配套的精品资源点击获取