Leaflet 与 WKT 互转用 Wicket 在 Well-Known Text 和几何图层之间搭建桥梁【免费下载链接】Leaflet JavaScript library for mobile-friendly interactive maps 项目地址: https://gitcode.com/gh_mirrors/le/LeafletWicket 是一个专注于在 Well-Known TextWKT文本格式与 Leaflet 几何对象之间进行双向翻译的轻量级库典型场景是把数据库或 GIS 服务中导出的POINT(...)这类坐标字符串直接转成可上图的L.marker()实例或反向把地图上的几何对象序列化为 WKT 文本。读完本文你将掌握 WKT 各几何类型的文本结构、它们与 Leaflet 几何图层Marker / Polyline / Polygon的对应关系以及在本仓库的 Leaflet 源码中这些转换目标的底层构造规则。Wicket 是什么WKT 与 Leaflet 对象之间的翻译层仓库插件目录 wicket.md 对它的定位是一句非常凝练的概括“A modest library for translating between Well-Known Text (WKT) and Leaflet geometry objects (e.g. betweenL.marker()instances andPOINT()strings)”——即一个在 WKT 与 Leaflet 几何对象之间做转换的小型库例如在L.marker()实例与POINT()字符串之间互相翻译。这意味着 Wicket 解决的是 GIS 数据接入 Web 地图时的“文本 ↔ 对象”断层问题读入方向WKT → Leaflet从 PostGIS、Shapefile 导出工具、WMS/WFS 服务等渠道拿到的坐标往往是 WKT 文本Wicket 将其解析并构造出对应的 Leaflet 图层对象可直接addTo(map)展示写出方向Leaflet → WKT用户在地图上绘制、编辑得到的几何对象可反向序列化为 WKT 字符串便于回写数据库或与其他 GIS 工具交换。该插件由 K. Arthur Endsley 开发插件目录条目声明其与 Leaflet 1.x 兼容compatible-v1: true对 Leaflet 0.xcompatible-v0为空与 Leaflet 2.xcompatible-v2: false未声明兼容因此使用时建议锁定 Leaflet 1.x 版本线。需要说明Leaflet 核心本身并不内置 WKT 解析能力WKT 文本必须借助这类转换插件Wicket、leaflet-omnivore 等或自行实现解析器才能进入地图。这也是 Wicket 这类“overlay-data-formats”分类插件存在的意义。先认识 WKTGIS 中最通用的坐标文本格式WKTWell-Known Text是 OGC 制定的用于表示矢量几何对象的纯文本标记语言用括号和关键词描述点、线、面及其集合。与 Leaflet 几何对象对应的常见 WKT 类型如下WKT 类型文本示例对应的 Leaflet 对象POINTPOINT(116.39 39.90)L.marker()或L.circleMarkerLINESTRINGLINESTRING(116.39 39.90, 116.41 39.91)L.polyline()POLYGONPOLYGON((0 0, 4 0, 4 4, 0 4, 0 0))L.polygon()MULTIPOINTMULTIPOINT(1 1, 2 2)多个L.marker()可用L.featureGroup聚合MULTILINESTRINGMULTILINESTRING((1 1, 2 2), (3 3, 4 4))L.polyline()多维坐标数组MULTIPOLYGONMULTIPOLYGON(((0 0, 4 0, 4 4, 0 4, 0 0)), ((1 1, 2 1, 2 2, 1 2, 1 1)))L.polygon()三维坐标数组注意 WKT 的坐标顺序是X经度在前、Y纬度在后即POINT(经度 纬度)而 Leaflet 的LatLng约定是纬度在前、经度在后见下文源码分析。这种顺序差异正是 Wicket 这类转换库需要内部处理的核心细节之一。转换目标端的源码依据Leaflet 几何对象如何接收坐标Wicket 的转换结果最终都要落到 Leaflet 的几何对象上因此理解这些对象的坐标输入规则就理解了 WKT 文本被“翻译”成什么形态。以下结论均可在本仓库源码中直接验证。1.POINT→ Marker坐标点与LatLngL.marker()的构造函数接收一个地理坐标点源码 Marker.js 中声明为Marker(latlng: LatLng, options?)。而LatLng本身是“纬度 经度”的载体其构造在 LatLng.js 中有多种等价写法new LatLng(50.5, 30.5); // (lat, lng) new LatLng([50.5, 30.5]); // 数组形式 new LatLng({lat: 50.5, lng: 30.5}); // 对象形式lon 亦可源码中LatLng对数组与对象形式做了显式分支处理LatLng.js第 41–85 行并统一把lat、lng强制转为数值。因此 Wicket 把POINT(116.39 39.90)翻译成 Leaflet 侧对象时本质上是做了一次坐标序重排WKT 的(lng, lat)→ Leaflet 的(lat, lng)最终产出new Marker([39.90, 116.39])或等价形式。这正是原文档示例“L.marker()实例 ↔POINT()字符串”这一转换方向的具体含义。2.LINESTRING/MULTILINESTRING→ Polyline一维与二维坐标数组L.polyline()接收“地理点数组”其源码 Polyline.js 注释明确指出传入一维点数组得到普通Polyline传入“点数组的数组”则得到MultiPolyline// 单线每个元素是一个 [lat, lng] const polyline new Polyline([ [45.51, -122.68], [37.77, -122.43], [34.04, -118.2] ], {color: red}).addTo(map); // 多线二维数组 const multi new Polyline([ [[45.51, -122.68], [37.77, -122.43]], [[40.78, -73.91], [41.83, -87.62]] ]);对应关系LINESTRING的坐标序列翻译为第一维数组MULTILINESTRING的每一条子线翻译为二维数组中的一个元素。Polyline还提供了getLatLngs()与setLatLngs()Polyline.js第 74–85 行这为反向转换Leaflet → WKT提供了取回坐标点的标准入口遍历getLatLngs()返回的嵌套数组即可重组出LINESTRING/MULTILINESTRING文本。3.POLYGON/MULTIPOLYGON→ Polygon闭合环与孔洞约定L.polygon()继承自Polyline其源码 Polygon.js 对坐标数组做了明确的层级约定一层数组 单个多边形外环两层数组 外环 内环孔洞三层数组 MultiPolygon多个多边形每个可含孔洞。源码注释同时给出一个关键提醒传入的多边形顶点不应包含“与首点相同的多余末点”应主动过滤掉闭合冗余点。而 WKT 的POLYGON文本恰好习惯显式写出闭合点如POLYGON((0 0, 4 0, 4 4, 0 4, 0 0))的最后一个0 0与首点重复。Polygon._convertLatLngs()Polygon.js第 76 行起实现了“末点等于首点时自动移除”的归一化逻辑——这从侧面印证WKT 转换到 Leaflet 时即使保留闭合点也不会破坏图层但 Leaflet 官方推荐在数据层面提前过滤。因此一个典型的 WKT→Leaflet 面转换流程是POLYGON((...))拆出外环与孔洞坐标序列 → 坐标序重排 → 组装为二维数组传给L.polygon()MULTIPOLYGON则再套一层数组。集成方式与使用要点Wicket 以独立插件形式引入与 Leaflet 1.x 配合使用的基本接入思路为!-- 先引入 Leaflet 1.x -- link relstylesheet hrefleaflet.css / script srcleaflet.js/script !-- 再引入 Wicket含 Leaflet 适配 -- script srcwicket.js/script script srcwicket-leaflet.js/script随后即可把 WKT 字符串交给 Wicket 解析并添加至地图例如把POINT(116.39 39.90)翻译为一个可上图的 marker 图层。使用中需重点关注的约定如下坐标系顺序WKT 一律为“经度 纬度”Leaflet 为“纬度 经度”双向转换都必须完成这次顺序翻转否则点位会落到错误位置闭合规则POLYGON的 WKT 文本通常带闭合冗余点Leaflet 侧虽能容忍Polygon会自动归一化但建议在解析时过滤以获得干净的坐标数组版本匹配插件目录声明compatible-v1: true、compatible-v2: false应搭配 Leaflet 1.x 使用当前仓库主干已包含 Leaflet 2.0 方向的演进见 CHANGELOG.md 中的 2.0.0-alpha 记录若升级主版本需先确认插件兼容性动态更新反向写出Leaflet → WKT时可利用Polyline.getLatLngs()取回坐标或监听绘制编辑事件后重新序列化保证回写数据库的 WKT 与地图状态一致。小结Wicket 解决的是 Web GIS 开发中非常高频的“数据交换格式 ↔ 可视化图层”转换问题以 WKT 为中间语言让 Leaflet 能直接消费来自传统 GIS 体系的坐标文本也能把用户绘制的结果导出回标准格式。结合本仓库源码可以看到转换的落点——LatLng坐标序与多形态构造、Polyline一维/二维数组、Polygon外环/孔洞/多面层级——都是 Leaflet 已定义良好的输入契约Wicket 的价值就在于把这些契约与 WKT 的文本语法对齐从而省去手写解析器与序列化器的成本。【免费下载链接】Leaflet JavaScript library for mobile-friendly interactive maps 项目地址: https://gitcode.com/gh_mirrors/le/Leaflet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Leaflet 与 WKT 互转：用 Wicket 在 Well-Known Text 和几何图层之间搭建桥梁
Leaflet 与 WKT 互转用 Wicket 在 Well-Known Text 和几何图层之间搭建桥梁【免费下载链接】Leaflet JavaScript library for mobile-friendly interactive maps 项目地址: https://gitcode.com/gh_mirrors/le/LeafletWicket 是一个专注于在 Well-Known TextWKT文本格式与 Leaflet 几何对象之间进行双向翻译的轻量级库典型场景是把数据库或 GIS 服务中导出的POINT(...)这类坐标字符串直接转成可上图的L.marker()实例或反向把地图上的几何对象序列化为 WKT 文本。读完本文你将掌握 WKT 各几何类型的文本结构、它们与 Leaflet 几何图层Marker / Polyline / Polygon的对应关系以及在本仓库的 Leaflet 源码中这些转换目标的底层构造规则。Wicket 是什么WKT 与 Leaflet 对象之间的翻译层仓库插件目录 wicket.md 对它的定位是一句非常凝练的概括“A modest library for translating between Well-Known Text (WKT) and Leaflet geometry objects (e.g. betweenL.marker()instances andPOINT()strings)”——即一个在 WKT 与 Leaflet 几何对象之间做转换的小型库例如在L.marker()实例与POINT()字符串之间互相翻译。这意味着 Wicket 解决的是 GIS 数据接入 Web 地图时的“文本 ↔ 对象”断层问题读入方向WKT → Leaflet从 PostGIS、Shapefile 导出工具、WMS/WFS 服务等渠道拿到的坐标往往是 WKT 文本Wicket 将其解析并构造出对应的 Leaflet 图层对象可直接addTo(map)展示写出方向Leaflet → WKT用户在地图上绘制、编辑得到的几何对象可反向序列化为 WKT 字符串便于回写数据库或与其他 GIS 工具交换。该插件由 K. Arthur Endsley 开发插件目录条目声明其与 Leaflet 1.x 兼容compatible-v1: true对 Leaflet 0.xcompatible-v0为空与 Leaflet 2.xcompatible-v2: false未声明兼容因此使用时建议锁定 Leaflet 1.x 版本线。需要说明Leaflet 核心本身并不内置 WKT 解析能力WKT 文本必须借助这类转换插件Wicket、leaflet-omnivore 等或自行实现解析器才能进入地图。这也是 Wicket 这类“overlay-data-formats”分类插件存在的意义。先认识 WKTGIS 中最通用的坐标文本格式WKTWell-Known Text是 OGC 制定的用于表示矢量几何对象的纯文本标记语言用括号和关键词描述点、线、面及其集合。与 Leaflet 几何对象对应的常见 WKT 类型如下WKT 类型文本示例对应的 Leaflet 对象POINTPOINT(116.39 39.90)L.marker()或L.circleMarkerLINESTRINGLINESTRING(116.39 39.90, 116.41 39.91)L.polyline()POLYGONPOLYGON((0 0, 4 0, 4 4, 0 4, 0 0))L.polygon()MULTIPOINTMULTIPOINT(1 1, 2 2)多个L.marker()可用L.featureGroup聚合MULTILINESTRINGMULTILINESTRING((1 1, 2 2), (3 3, 4 4))L.polyline()多维坐标数组MULTIPOLYGONMULTIPOLYGON(((0 0, 4 0, 4 4, 0 4, 0 0)), ((1 1, 2 1, 2 2, 1 2, 1 1)))L.polygon()三维坐标数组注意 WKT 的坐标顺序是X经度在前、Y纬度在后即POINT(经度 纬度)而 Leaflet 的LatLng约定是纬度在前、经度在后见下文源码分析。这种顺序差异正是 Wicket 这类转换库需要内部处理的核心细节之一。转换目标端的源码依据Leaflet 几何对象如何接收坐标Wicket 的转换结果最终都要落到 Leaflet 的几何对象上因此理解这些对象的坐标输入规则就理解了 WKT 文本被“翻译”成什么形态。以下结论均可在本仓库源码中直接验证。1.POINT→ Marker坐标点与LatLngL.marker()的构造函数接收一个地理坐标点源码 Marker.js 中声明为Marker(latlng: LatLng, options?)。而LatLng本身是“纬度 经度”的载体其构造在 LatLng.js 中有多种等价写法new LatLng(50.5, 30.5); // (lat, lng) new LatLng([50.5, 30.5]); // 数组形式 new LatLng({lat: 50.5, lng: 30.5}); // 对象形式lon 亦可源码中LatLng对数组与对象形式做了显式分支处理LatLng.js第 41–85 行并统一把lat、lng强制转为数值。因此 Wicket 把POINT(116.39 39.90)翻译成 Leaflet 侧对象时本质上是做了一次坐标序重排WKT 的(lng, lat)→ Leaflet 的(lat, lng)最终产出new Marker([39.90, 116.39])或等价形式。这正是原文档示例“L.marker()实例 ↔POINT()字符串”这一转换方向的具体含义。2.LINESTRING/MULTILINESTRING→ Polyline一维与二维坐标数组L.polyline()接收“地理点数组”其源码 Polyline.js 注释明确指出传入一维点数组得到普通Polyline传入“点数组的数组”则得到MultiPolyline// 单线每个元素是一个 [lat, lng] const polyline new Polyline([ [45.51, -122.68], [37.77, -122.43], [34.04, -118.2] ], {color: red}).addTo(map); // 多线二维数组 const multi new Polyline([ [[45.51, -122.68], [37.77, -122.43]], [[40.78, -73.91], [41.83, -87.62]] ]);对应关系LINESTRING的坐标序列翻译为第一维数组MULTILINESTRING的每一条子线翻译为二维数组中的一个元素。Polyline还提供了getLatLngs()与setLatLngs()Polyline.js第 74–85 行这为反向转换Leaflet → WKT提供了取回坐标点的标准入口遍历getLatLngs()返回的嵌套数组即可重组出LINESTRING/MULTILINESTRING文本。3.POLYGON/MULTIPOLYGON→ Polygon闭合环与孔洞约定L.polygon()继承自Polyline其源码 Polygon.js 对坐标数组做了明确的层级约定一层数组 单个多边形外环两层数组 外环 内环孔洞三层数组 MultiPolygon多个多边形每个可含孔洞。源码注释同时给出一个关键提醒传入的多边形顶点不应包含“与首点相同的多余末点”应主动过滤掉闭合冗余点。而 WKT 的POLYGON文本恰好习惯显式写出闭合点如POLYGON((0 0, 4 0, 4 4, 0 4, 0 0))的最后一个0 0与首点重复。Polygon._convertLatLngs()Polygon.js第 76 行起实现了“末点等于首点时自动移除”的归一化逻辑——这从侧面印证WKT 转换到 Leaflet 时即使保留闭合点也不会破坏图层但 Leaflet 官方推荐在数据层面提前过滤。因此一个典型的 WKT→Leaflet 面转换流程是POLYGON((...))拆出外环与孔洞坐标序列 → 坐标序重排 → 组装为二维数组传给L.polygon()MULTIPOLYGON则再套一层数组。集成方式与使用要点Wicket 以独立插件形式引入与 Leaflet 1.x 配合使用的基本接入思路为!-- 先引入 Leaflet 1.x -- link relstylesheet hrefleaflet.css / script srcleaflet.js/script !-- 再引入 Wicket含 Leaflet 适配 -- script srcwicket.js/script script srcwicket-leaflet.js/script随后即可把 WKT 字符串交给 Wicket 解析并添加至地图例如把POINT(116.39 39.90)翻译为一个可上图的 marker 图层。使用中需重点关注的约定如下坐标系顺序WKT 一律为“经度 纬度”Leaflet 为“纬度 经度”双向转换都必须完成这次顺序翻转否则点位会落到错误位置闭合规则POLYGON的 WKT 文本通常带闭合冗余点Leaflet 侧虽能容忍Polygon会自动归一化但建议在解析时过滤以获得干净的坐标数组版本匹配插件目录声明compatible-v1: true、compatible-v2: false应搭配 Leaflet 1.x 使用当前仓库主干已包含 Leaflet 2.0 方向的演进见 CHANGELOG.md 中的 2.0.0-alpha 记录若升级主版本需先确认插件兼容性动态更新反向写出Leaflet → WKT时可利用Polyline.getLatLngs()取回坐标或监听绘制编辑事件后重新序列化保证回写数据库的 WKT 与地图状态一致。小结Wicket 解决的是 Web GIS 开发中非常高频的“数据交换格式 ↔ 可视化图层”转换问题以 WKT 为中间语言让 Leaflet 能直接消费来自传统 GIS 体系的坐标文本也能把用户绘制的结果导出回标准格式。结合本仓库源码可以看到转换的落点——LatLng坐标序与多形态构造、Polyline一维/二维数组、Polygon外环/孔洞/多面层级——都是 Leaflet 已定义良好的输入契约Wicket 的价值就在于把这些契约与 WKT 的文本语法对齐从而省去手写解析器与序列化器的成本。【免费下载链接】Leaflet JavaScript library for mobile-friendly interactive maps 项目地址: https://gitcode.com/gh_mirrors/le/Leaflet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考