Navicat 不提供 GIS 数据的可视化编辑能力，仅支持通过手动输入 WKT（如 POINT(120.1 30.2)）或 WKB 文本方式修改空间字段，无法拖拽绘制、缩放地图或实时交互；双击字段默认显示 WKB 二进制乱码，启用“Show Value as Text”仅可查看不可编辑；导出 SQL 时空间类型易被降级为 TEXT，需手动校验与修复。
Navicat 本身不提供 GIS 数据的可视化编辑能力——它能显示、插入、导出空间字段，但无法像 QGIS 或 ArcGIS 那样拖拽点/线/面、缩放地图、实时绘制几何对象。所谓“可视化修改”，实际是「用文本方式输入 WKT（如 POINT(120.1 30.2)）或 WKB，再依赖数据库引擎解析并校验」。
为什么双击空间字段后只看到乱码或十六进制
MySQL 的 POINT、PostgreSQL 的 geometry 字段在 Navicat 表数据视图中默认以 WKB（二进制）形式渲染，看起来像一串 0x0101000000...；即使你启用了 WKT 显示（右键列→Show Value as Text），也仅能查看，不能交互式编辑。
- MySQL 8.0+ 支持
ST_AsText(location)查看，但 Navicat 不自动调用该函数做展示 - PostgreSQL + PostGIS 中，
geometry列在数据网格里常显示为(binary)，除非你手动在查询窗口写SELECT ST_AsText(geom) FROM table; - SQL Server 的
geometry::STGeomFromText()同理，Navicat 不做隐式转换
真正可操作的“可视化修改”路径：WKT 输入 + SQL 校验
你只能手动输入标准 WKT 字符串，并确保格式、SRID、括号嵌套完全正确。这不是图形化操作，而是结构化文本输入。
- MySQL 场景：在数据网格中双击
POINT字段 → 输入POINT(121.4737 31.2304)（注意无引号、空格分隔经纬度、小数点格式） - PostgreSQL 场景：输入
SRID=4326;POINT(121.4737 31.2304)，否则可能因 SRID 缺失导致后续ST_DWithin查询失效 - SQL Server 场景：必须用构造函数语法，例如
geometry::STGeomFromText('POINT(121.4737 31.2304)', 4326)，直接输POINT(...)会报错 - 输错时 Navicat 通常不即时提示，要等保存（Ctrl+S）才弹出数据库原生错误，如
Invalid GIS data provided to function st_geometryfromtext
导出/导入时空间字段极易被降级为 TEXT
这是最隐蔽的坑：你明明建了 POINT 字段，用 Navicat 导出 SQL 结构（右键表→Dump SQL File → Structure Only），结果脚本里变成 location TEXT。
- 触发条件：连接的是旧版 MySQL（如 5.6）、未启用
innodb_file_per_table、或 Navicat 没正确识别引擎类型 - 验证方法：导出后打开 SQL 文件，搜索
POINT或GEOMETRY，若不存在，说明已被降级 - 绕过方式：改用查询窗口执行
SHOW CREATE TABLE your_table;手动复制建表语句，而非依赖可视化导出 - 批量修复：对已降级的表，需用
ALTER TABLE t MODIFY location POINT NOT NULL SRID 4326;（MySQL 8.0.23+）重新定义，不能靠 Navicat 表设计器完成
真正的 GIS 可视化编辑必须脱离 Navicat——它只是个数据库管道，不是 GIS 工具。如果你需要画多边形、测距离、叠加底图，得把数据导出为 GeoJSON，丢进 QGIS；或者用数据库自带的 WebGIS 插件（如 PostgreSQL 的 pgAdmin 4 内置地图预览）。Navicat 能做的，仅限于让 WKT 文本不输错、让 SRID 不遗漏、让导出 SQL 不掉类型——这些恰恰是最容易被忽略的细节。
