用于用户提供坐标的通用 JavaScript 解析器答案

【问题标题】：Generic JavaScript parser for user supplied coordinates用于用户提供坐标的通用 JavaScript 解析器
【发布时间】：2013-03-08 02:23:53
【问题描述】：

是否有 JavaScript 库可以帮助解析用户提供的各种格式的坐标？

我有一个带有搜索框的地图站点，可用于搜索地名，但通过查看统计数据，我发现很多人尝试直接使用各种格式的坐标，就像他们能够做到的那样在谷歌地图上。

我看到的典型纬度和经度变化是：

-43 02 42.845 S 172 38 33.790 E
n 19°49'2.30e 41°51'29.20
41°46'57.90"S
172° 1'20.39"E 43 02 42.845 S
42.897S 172.720E
42.31.303 172.23.379
19.817306°, 41.858111°

有很多变化，这只是一个示例。还有用户尝试基于 NZTM 和 NZMG 的各种新西兰格式。

理想情况下，我想找到一个库，有人可能从一些基本的纬度和经度开始，然后扩展功能以支持我看到的其他格式。

有人知道那里有什么吗？

【问题讨论】：

您是否在屏幕上显示“请以 +/-ddd mm ss.s 格式输入纬度然后经度”或单独的纬度和经度字段？否则，您将有非常复杂的逻辑来整理混乱。最后两个完全模棱两可，尽管您可能会猜到第一个数字是纬度，因为这是惯例。
我没有说明需要的经纬度格式。事实上，该功能从来都不是为此而设计的——我只是对一些用户尝试使用该功能的方式做出反应（可能来自他们使用谷歌地图的经验）。我实际上希望尽可能灵活，允许支持尽可能多的格式。我想我可以想出一些通用的搜索提供程序库，它使用正则表达式来查看格式是否符合该特定提供程序的标准。应该使其易于扩展并添加对格式的更多支持，而不会变得过于复杂。

标签： javascript parsing geocoding latitude-longitude

【解决方案1】：

要从原始文本输入解析数字坐标，有 npm 包 coordinate-parser 和 otto-dev。对于WGS84 纬度-经度对及其分钟和十进制表示而言，它感觉很强大。

const CoordinateParser = require('coordinate-parser')
const text = `60 40' 31.35" N, 23 50' 55.75" E`
const pos = new CoordinateParser(text)
const lat = pos.getLatitude() // 60.675374
const lng = pos.getLongitude() // 23.848819

虽然适用于 WGS84，但坐标解析器不处理 UTM 坐标，例如 NZTM 或 ETRS89 TM35FIN 上的坐标，例如 N 6730758, E 327874。解析器将大数字视为毫秒或密集格式的 DDMMSS.xxx 而不是米，从而产生无效结果。

对于 UTM 坐标，有 utm-coordinate-parser。它识别常见的东-北对，例如 6730758 N 327874 E 以及 x-y 对 x:327874 y:6730758。免责声明：我是包作者。

const utmp = require('utm-coordinate-parser')
const text = 'N 6730758; W -327874'
const pos = utmp.parse(text)
const x = pos.x // 327874
const y = pos.y // 6730758

【讨论】：

【解决方案2】：

实际上，我刚刚发布了名为 Magellan 的 JavaScript 库，它可以处理您上面列出的纬度/经度坐标的格式设置和验证。检查一下，看看它是否是您想要的。

链接：https://dbarbalato.github.io/magellan/

作为一个简短的说明，它不会处理您上面列出的每种格式，但如果有足够的兴趣，我愿意扩展功能。

【讨论】：

嗨，戴夫，看起来很有前途！我可能需要试一试，看看我是否可以重新考虑它以允许插入格式。感谢分享！我会告诉你我的进展情况。

【解决方案3】：

一般形式应该是：

var m;
if( m = input.match(/format regex here/)) { /* do stuff with m */ }
else if( m = input.match(/another format/)) { /* do stuff with m */ }
...
else {throw new Error("Format not recognised!");}

构建所需的正则表达式由您决定，但它们应该太难了，因为它们是相对简单的格式。

【讨论】：

我在想一些更通用的东西，我可以根据需要插入更多格式解析器，但基本上你的想法是正确的。我认为我的问题之前可能已经解决了，所以如果已经有一个库/解决方案可以处理比我迄今为止遇到的更多格式并且我可以继续构建，为什么还要重新发明轮子。