114514的博客

本文介绍了使用GeoTools将Shapefile导入PostGIS的纯Java解决方案。针对ogr2ogr工具在生产环境中的局限性（依赖GDAL、集成困难、错误处理不足等），提出了基于GeoTools 29.3的技术方案，包含Maven依赖配置、完整可运行的Java工具类代码（支持事务控制、SRID设置和中文编码处理），并详细解析了DataStoreFinder和FeatureWriter等核心API的使用方法。

本文介绍了在Spring Boot 3.5.5项目中集成MyBatis-Plus 3.5.7操作PostGIS空间数据的技术方案。针对PostgreSQL/PostGIS的Geometry字段处理，提供了完整的增删改查流程实现，重点解决了MyBatis-Plus与Spring Boot 3.x的版本兼容性问题。文章详细说明了数据库设计（包含Point类型的空间字段）、项目结构、TypeHandler实现（Geometry与EWKB格式转换）等核心内容

fromshare=blogdetail&sharetype=blogdetail&sharerId=162789976&sharerefer=PC&sharesource=weixin_45011889&sharefrom=from_link，我们已经实现了 Geometry 字段的增删改查，TypeHandler 也能正确工作。关键点：只做一件事——Geometry → WKT，不依赖 MyBatis，不依赖 Spring，职责单一。前端地图组件可以直接消费，无需额外转换。有没有更优雅的方式？

本文深入剖析了MyBatis-Plus中TypeHandler的生效规则，指出常见的失效场景及解决方案。关键结论包括：1）MP自动CRUD需同时使用@TableField和autoResultMap=true；2）手写SQL必须使用resultMap而非resultType；3）@MappedTypes注册不可靠。文中通过5种生效方式的对比和3个真实踩坑案例，强调TypeHandler只在正确的映射规则下生效，推荐统一采用显式配置（MP自动CRUD+XML resultMap）的实践方案。

本文对比了PostGIS中geometry和geography两种空间数据类型的区别与应用场景。geometry基于平面投影，适合国内项目，函数丰富且索引性能更优；geography基于球面计算，距离单位天然为米，适用于全球业务但函数支持较少。针对国内项目，推荐存储使用geometry(4326)，距离计算时转换为geography，兼顾性能与语义清晰度。类型选择直接影响后续查询写法与性能，需根据业务场景谨慎决策。

本文介绍了PostGIS中两种常见空间查询的实现方法：矩形范围查询（BBox）和附近POI查询。针对BBox查询，使用ST_Intersects函数判断点是否在矩形范围内；对于距离查询，通过ST_DWithin函数实现，并特别强调Geometry和Geography类型的单位差异（角度vs米）。文章提供了完整的MyBatis Mapper、Service和Controller实现代码，以及接口测试结果。最后讨论了空间索引(GIST)的创建和优化技巧，包括索引验证方法和常见失效原因。

关闭后，前端拿不到 total，分页组件无法渲染。解决：要么开启（小数据量），要么自定义（推荐）。

格式体积前端解析成本地图组件支持WKT最小需手写 parser✖ 不支持GeoJSON中原生支持全部支持完整 Geometry最大高⚠ 需适配GeoJSON 是Web GIS 的事实标准，前端地图组件可以直接消费，不需要任何转换。