使用 turf.js 绘制与其周围的测地线字符串不匹配的 lineArcs
Plotting lineArcs with turf.js that don't match up with their surrounding geodesic strings
背景
我们提供了一些 AIXM 数据（基于 XML 的 GML 超集），这些数据将地图上的多边形区域描述为 GeodesicStrings（坐标列表）和 ArcByCentrePoints（中心点坐标与半径、起点方位角和终点方位角）。我们正在获取这些数据并将其转换为一个简单的坐标列表，然后我们使用 Google 地图折线显示该列表。
问题
当我们用圆弧绘制形状时，圆弧的起点和终点通常与前一行的终点和起点不匹配下一行的。看起来好像径向距离超出了一个似乎与半径不成比例的量。请参见屏幕截图：有趣的是，顶部的较小弧线看起来不错，但较大的弧线是内嵌的。
我们非常确定数据是正确的，因为当我们使用第三方工具对其进行可视化时它看起来很好，所以我们做错了。
实施
我们正在使用 turf.js 库将弧描述转换为一组点，使用它们的 lineArc function. Internally this utilises their destination 函数 "使用 Haversine 公式来解释全局曲率。我们以正确的顺序将这些生成的点与直接从前面和后面的 GeodesicString 元素中获取的点组合起来，为我们提供最终的多边形。
数据
求助！
我知道这个问题在代码上很简单，但我希望我已经充分描述了这个问题，并且一些 GIS 知识比我多（> 0）的好心人可能能够为我指明正确的方向.谢谢:)
我已经做了几次关于调试的演讲，我要说的一件事是你应该保持开放的心态，不应该过于关注错误的可能原因，因为你会浪费很多追踪错误线索的时间。
遗憾的是，在这种情况下，我没有采纳自己的建议。我非常执着于认为问题是由复杂的原因引起的，例如 Haversine 公式的实施问题，以至于我忽略了简单得多的答案。我的代码采用半径的字符串表示形式，包括单位（例如海里或米）并将其转换为公里。可悲的是，我使用 parseInt 而不是 parseFloat 作为其中的一部分，因此立即失去了精度。就这么简单-一个小学生的错误。
非常感谢 Turf JS 的维护者 Stefano Borghi，感谢他为此提供的所有帮助，并帮助我见树见木。
背景
我们提供了一些 AIXM 数据（基于 XML 的 GML 超集），这些数据将地图上的多边形区域描述为 GeodesicStrings（坐标列表）和 ArcByCentrePoints（中心点坐标与半径、起点方位角和终点方位角）。我们正在获取这些数据并将其转换为一个简单的坐标列表，然后我们使用 Google 地图折线显示该列表。
问题
当我们用圆弧绘制形状时，圆弧的起点和终点通常与前一行的终点和起点不匹配下一行的。看起来好像径向距离超出了一个似乎与半径不成比例的量。请参见屏幕截图：有趣的是，顶部的较小弧线看起来不错，但较大的弧线是内嵌的。
我们非常确定数据是正确的，因为当我们使用第三方工具对其进行可视化时它看起来很好，所以我们做错了。
实施
我们正在使用 turf.js 库将弧描述转换为一组点，使用它们的 lineArc function. Internally this utilises their destination 函数 "使用 Haversine 公式来解释全局曲率。我们以正确的顺序将这些生成的点与直接从前面和后面的 GeodesicString 元素中获取的点组合起来，为我们提供最终的多边形。
数据
求助！
我知道这个问题在代码上很简单，但我希望我已经充分描述了这个问题，并且一些 GIS 知识比我多（> 0）的好心人可能能够为我指明正确的方向.谢谢:)
我已经做了几次关于调试的演讲，我要说的一件事是你应该保持开放的心态，不应该过于关注错误的可能原因，因为你会浪费很多追踪错误线索的时间。
遗憾的是，在这种情况下，我没有采纳自己的建议。我非常执着于认为问题是由复杂的原因引起的，例如 Haversine 公式的实施问题，以至于我忽略了简单得多的答案。我的代码采用半径的字符串表示形式，包括单位（例如海里或米）并将其转换为公里。可悲的是，我使用 parseInt 而不是 parseFloat 作为其中的一部分，因此立即失去了精度。就这么简单-一个小学生的错误。
非常感谢 Turf JS 的维护者 Stefano Borghi，感谢他为此提供的所有帮助，并帮助我见树见木。