启用PostGIS扩展后用ogr2ogr导入GeoJSON出现SRID不匹配问题

流程差异的核心原因 #

两种操作流程的区别在于ogr2ogr导入数据时数据库是否已存在PostGIS扩展，导致工具对空间数据的存储逻辑完全不同：

1. 先导入数据再启用PostGIS
   此时数据库没有geometry类型，ogr2ogr只能将GeoJSON的空间数据以原始二进制形式存储为bytea类型。启用PostGIS后，执行ST_Contains时，函数会自动解析bytea中的GeoJSON数据，识别其自带的SRID（4326）；而你写的未指定SRID的POINT字符串，会被PostGIS隐式赋予与目标几何一致的SRID（4326），因此两边SRID匹配，查询正常。

2. 先启用PostGIS再导入数据
   此时数据库已支持geometry类型，ogr2ogr会直接创建带SRID约束的geometry列（从GeoJSON中读取SRID=4326并绑定到列）。但你查询时使用的'POINT (-##.## ##.## )'是无SRID的WKT，默认SRID为0，与列中几何的SRID=4326不匹配，触发PostGIS严格的SRID一致性检查，因此报错。

修正方案 #

不需要删除重建数据库，只需调整查询语句，确保两边几何的SRID一致：

• 方法1：给POINT指定SRID（推荐）

  SELECT district, ST_Contains(ST_SetSRID(ST_MakePoint(-##.##, ##.##), 4326), wkb_geometry) FROM table;
  

• 方法2：使用带SRID的WKT格式

  SELECT district, ST_Contains('SRID=4326;POINT (-##.## ##.## )', wkb_geometry) FROM table;
  

关于PostGIS扩展无法禁用的说明 #

PostgreSQL扩展一旦创建了依赖对象（比如包含geometry列的表），就无法直接禁用或删除，必须先删除所有依赖的表、函数等对象，这是正常的数据库约束行为，并非操作错误。

内容的提问来源于stack exchange，提问作者Brettk80