简介postgis-bundle-pg14-3.5.0x64.zip 是面向 PostgreSQL 1464 位用户的 PostGIS 3.5.0 扩展安装包用于为对象关系型数据库补齐空间数据存储、查询与分析能力适合 GIS 开发、空间数据库运维及城市规划、环境监测、交通物流等场景的工程师与系统管理员。压缩包共 1335 个文件约 130.92MB以 951 个 sql 脚本、79 个 dll 动态库、75 个 csv 示例数据、50 个 tif 栅格影像为主另含 control 扩展定义、pl 脚本、xsd/xml 规范文件及少量 exe 工具覆盖库文件、文档与示例资源。已有 95 人学习下载。解压后可按脚本完成扩展注册与数据库配置快速将 PostgreSQL 升级为符合 OpenGIS 规范的成熟 GIS 数据库直接用于空间索引、几何类型转换与空间关系运算等开发实践。1. 为什么我建议你手动装一次 postgis-bundle-pg14-3.5.0x64.zip上周帮一个做城市管网的朋友排查问题他的 PostgreSQL 14 里CREATE EXTENSION postgis一直报could not open extension control file折腾了一下午。最后发现是当初用图形化安装器勾选 PostGIS 时扩展文件根本没落到share/extension目录里。这种翻车场景我见过太多次所以当有人丢给我postgis-bundle-pg14-3.5.0x64.zip这个包时我第一反应是这玩意儿才是把 PostgreSQL 14 变成空间数据库最稳的一条路。它不是什么新东西就是一套为 64 位 PG14 编译好的 PostGIS 3.5.0 二进制集合解压后能看到makepostgisdb_using_extensions.bat、loaders.cache、CH、fonts.conf、im-multipress.conf以及一堆.control文件——postgis.control、address_standardizer.control、postgis_tiger_geocoder.control、pointcloud.control、pgrouting.control。这些文件名就是它的全部家当也决定了它能解决什么问题让你不依赖联网、不依赖安装器直接把空间数据类型、空间索引、地理编码、路网分析这些能力塞进已有的 PG14 实例。适合谁适合手里已经有 PostgreSQL 14 在跑、又不想重装数据库、还想把 GIS 能力接进来的开发和运维。如果你正被postgis安装失败折磨这个包值得你花二十分钟跟着走一遍。2. 拆开压缩包看门道control 文件与 loaders.cache 各管什么2.1 从 .control 文件读懂扩展的注册机制PostgreSQL 的扩展不是把 DLL 丢进去就能用的它靠.control文件向数据库声明“我是谁、我依赖谁、我的 SQL 脚本在哪”。你解压后看到的每一个.control都对应一个可独立启用的扩展。postgis.control是主扩展提供几何类型、空间索引和绝大多数空间函数address_standardizer.control负责地址标准化做地理编码前通常要先装它postgis_tiger_geocoder.control是美国 TIGER 数据的地理编码器国内项目一般用不上但留着不影响pointcloud.control处理点云数据激光雷达那类场景会用到pgrouting.control是路网分析扩展做最短路径、服务区分析时必装。理解这一点很关键你不需要一次性把所有扩展都CREATE EXTENSION按业务需要逐个启用能减少后期升级时的依赖纠缠。2.2 loaders.cache 与字体配置文件的真实用途loaders.cache是 GDAL 数据格式驱动的缓存文件PostGIS 在调用ST_FromGDALRaster或栅格导入导出时会读它。如果这个文件缺失或路径不对你会遇到rt_raster_from_gdal_dataset相关的报错。fonts.conf和im-multipress.conf则是给地图渲染和标注用的字体配置做ST_AsSVG、ST_AsGeoJSON之外的图像输出时才会被间接引用。很多教程只让你复制 DLL结果栅格功能一用就崩根子就在这几个非代码文件没放对位置。我一般会把整个解压目录先原样保留再按下面的步骤往 PostgreSQL 目录里映射而不是东一个西一个地拷。2.3 确认你的 PostgreSQL 14 是 64 位且版本匹配动手前先跑一条命令确认环境别急着复制文件。版本对不上是postgis安装失败里占比最高的一类。# 查看 PostgreSQL 版本和架构输出里要能看到 64-bit pg_config --version pg_config --configure # 更直接的方式连进数据库查 psql -U postgres -c SELECT version();逻辑说明pg_config --version给出的是编译版本号必须是 14.xSELECT version()会明确带出64-bit字样。如果这里显示 32 位或者主版本不是 14后面所有步骤都别做了包和实例对不上硬装只会污染现有环境。参数上唯一要留意的是pg_config是否在 PATH 里Windows 下通常在C:\Program Files\PostgreSQL\14\bin没配 PATH 就用绝对路径调用。3. 把 bundle 落进 PG14目录映射与扩展启用全流程3.1 定位 PostgreSQL 的 share 与 lib 目录PostGIS 的文件分两类去处.control和 SQL 脚本进share/extensionDLL 和依赖库进lib。先用pg_config把这两个路径问出来别凭记忆猜。# 分别拿到 share 和 lib 的绝对路径 pg_config --sharedir pg_config --pkglibdir逻辑说明--sharedir一般返回C:\Program Files\PostgreSQL\14\share扩展的 control 和 sql 就放它下面的extension子目录--pkglibdir返回C:\Program Files\PostgreSQL\14\lib所有.dll放这里。参数上要注意如果你用的是 EDB 安装器装的 PG14这两个路径可能带postgresql\14这样的层级以命令实际输出为准。把这两个路径记下来下一步复制时直接引用。3.2 按类型复制文件并处理依赖 DLL解压postgis-bundle-pg14-3.5.0x64.zip后你会看到lib、share、bin这样的目录结构不同打包方式略有差异但核心文件就那些。复制时按类型走不要整个文件夹覆盖避免把原有配置冲掉。# 假设解压到了 D:\postgis-bundlePG 安装目录是默认路径 # 复制扩展控制文件和 SQL 脚本 xcopy D:\postgis-bundle\share\extension\* C:\Program Files\PostgreSQL\14\share\extension\ /E /Y # 复制动态库 xcopy D:\postgis-bundle\lib\* C:\Program Files\PostgreSQL\14\lib\ /E /Y # 复制 GDAL 数据目录含 loaders.cache到 share 下 xcopy D:\postgis-bundle\share\gdal\* C:\Program Files\PostgreSQL\14\share\gdal\ /E /Y逻辑说明第一条把postgis.control、pgrouting.control等和对应的--1.0.sql脚本送进extension目录这是CREATE EXTENSION能找到扩展的前提第二条把postgis-3.dll、libgeos.dll、libproj.dll等运行库放进lib缺一个都会在加载时报The specified module could not be found第三条容易被忽略loaders.cache必须落在share/gdal下栅格功能才正常。参数上/E表示连子目录一起复制/Y覆盖时不询问批量操作时省事但第一次做建议去掉/Y逐项确认。3.3 用 makepostgisdb_using_extensions.bat 建库并启用扩展包里那个makepostgisdb_using_extensions.bat是给你做模板用的它演示了如何在一个新库里按顺序启用扩展。我一般不会直接双击运行而是打开看它调了哪些 SQL再按自己需求改。-- 先建一个专门放空间数据的库 CREATE DATABASE gisdb WITH ENCODING UTF8; -- 连到 gisdb 后按依赖顺序启用扩展 \c gisdb CREATE EXTENSION postgis; CREATE EXTENSION address_standardizer; CREATE EXTENSION pgrouting; CREATE EXTENSION pointcloud; -- 验证查 PostGIS 版本和几何类型是否可用 SELECT PostGIS_Version(); SELECT ST_AsText(ST_GeomFromText(POINT(116.39 39.9), 4326));逻辑说明CREATE EXTENSION postgis是核心它会自动带上postgis_topology等依赖address_standardizer和pgrouting按业务需要加pgrouting 依赖 postgis所以顺序不能反pointcloud独立用不到就不装。验证语句里PostGIS_Version()返回 3.5.0 说明主扩展就位ST_GeomFromText能跑通说明几何类型和函数库都加载成功。参数上4326是 WGS84 坐标系 SRID国内做经纬度数据基本都用它如果返回的坐标不对先查 SRID 是否写错。3.4 用 loaders.cache 验证栅格能力是否就绪矢量跑通不代表栅格能用单独验一下 GDAL 驱动缓存。-- 建一张带栅格列的表触发 GDAL 加载 CREATE TABLE dem_test (rid serial primary key, rast raster); INSERT INTO dem_test (rast) VALUES (ST_MakeEmptyRaster(10, 10, 0, 0, 1, -1, 0, 0, 4326)); SELECT ST_Width(rast), ST_Height(rast) FROM dem_test;逻辑说明ST_MakeEmptyRaster创建一个 10x10 的空栅格如果loaders.cache路径不对这一步会报could not load library或 GDAL 相关错误。返回宽度高度都是 10 就说明栅格基础能力正常。参数里1, -1是像素的 X、Y 方向分辨率4326同样是坐标系。这一步过了说明fonts.conf、loaders.cache这些非代码文件都放对了位置。4. 避坑与排查postgis安装失败最常见的五类现场4.1 现象CREATE EXTENSION 报 control file 找不到原因.control文件没进share/extension或者 PG 实例读的是另一个sharedir。解决用pg_config --sharedir确认路径把postgis.control和postgis--3.5.0.sql一起放进去缺 SQL 脚本同样会失败。注意文件名里的版本号必须和 control 里声明的一致改过名就对不上了。4.2 现象加载 DLL 时报模块找不到原因lib目录里缺依赖库常见的是libgeos_c.dll、libproj.dll、libjson-c.dll没跟着复制。解决把 bundle 里lib下所有 DLL 一次性复制过去别只挑postgis-3.dll。如果还报错用 Dependency Walker 或dumpbin /dependents看缺哪个再从包里找。4.3 现象栅格函数报 GDAL 相关错误原因loaders.cache没放对位置或文件里的路径还是打包机的绝对路径。解决把loaders.cache放到share/gdal下用文本编辑器打开检查里面的路径必要时改成你机器上的实际路径。这个文件是纯文本改起来不复杂但容易被忽略。4.4 现象pgrouting 启用时报依赖 postgis 不存在原因启用顺序反了pgrouting 依赖 postgis 提供的类型和函数。解决先CREATE EXTENSION postgis;再CREATE EXTENSION pgrouting;。如果已经装错先DROP EXTENSION pgrouting;再按顺序重来别硬扛。4.5 现象升级 PG 小版本后 PostGIS 突然不可用原因PG 小版本升级有时会重置lib和share目录把手工放进去的文件清掉。解决升级前备份 bundle 文件升级后重新复制一遍再跑SELECT PostGIS_Version();确认。我一般会把 bundle 解压目录留一份在非系统盘升级完直接再复制一次比重新找包快得多。5. 进阶用 makepostgisdb_using_extensions.bat 做可复现的建库模板makepostgisdb_using_extensions.bat这个文件很多人解压后看都不看其实它是最值得改造成自己模板的东西。它本质是一串psql调用把建库和启用扩展的步骤串起来。我习惯把它改成带参数的形式让不同项目能复用同一套初始化逻辑。echo off REM 用法makepostgisdb_using_extensions.bat 库名 set DBNAME%1 if %DBNAME% set DBNAMEgisdb psql -U postgres -c CREATE DATABASE %DBNAME% WITH ENCODING UTF8; psql -U postgres -d %DBNAME% -c CREATE EXTENSION postgis; psql -U postgres -d %DBNAME% -c CREATE EXTENSION address_standardizer; psql -U postgres -d %DBNAME% -c CREATE EXTENSION pgrouting; psql -U postgres -d %DBNAME% -c SELECT PostGIS_Version();逻辑说明把库名做成参数避免每次手改脚本每条psql独立执行某一步失败能立刻定位最后一条版本查询兼做验收。参数上-U postgres按你实际超级用户改-d指定目标库。这个模板跑通一次后新项目初始化就是一条命令的事。我还会在脚本末尾加一句psql -U postgres -d %DBNAME% -c \dx列出所有已装扩展方便核对。验证方法上除了PostGIS_Version()我还会跑一个真实的空间查询确认索引生效CREATE TABLE poi (id serial primary key, name text, geom geometry(Point, 4326)); CREATE INDEX idx_poi_geom ON poi USING gist (geom); INSERT INTO poi (name, geom) VALUES (A, ST_GeomFromText(POINT(116.39 39.9), 4326)); EXPLAIN ANALYZE SELECT name FROM poi WHERE ST_DWithin(geom, ST_GeomFromText(POINT(116.40 39.91), 4326), 0.01);逻辑说明建 GiST 空间索引后ST_DWithin这类距离查询才能走索引EXPLAIN ANALYZE输出里出现Index Scan using idx_poi_geom就说明空间索引真正生效了。如果显示 Seq Scan检查索引是否建在正确的几何列上、SRID 是否一致。参数0.01是度为单位的大致距离4326 下约 1 公里出头实际项目按需换算。从那以后我每次拿到新的 PostGIS bundle都强制先跑一遍pg_config对路径、再复制、再建库验证三步缺一不可。这套流程帮我省掉了至少五次重装数据库的时间。希望帮到你。本文还有配套的精品资源点击获取