2
地理数据跨越antimeridian的数据库和API的最佳做法
当这些地理特征（线，面和它们的多部分等价物）跨越时线（经度±180°）并且需要作为GeoJSON发送到客户端Web应用程序并从客户端Web应用程序接收时，最佳做法是什么？ 我将开始在服务器端Web API上进行工作，并获得Postgres / PostGIS数据库的支持，以处理历史和预报的热带气旋轨道和风半径。不幸的是，太平洋上的许多气旋都有越过沙漏的趋势，有时在生命周期内多次发生： 作为居住在后脚区附近的新西兰人，我经常在区域数据中经常遇到此问题，以制定一些应对策略，但是我想实际找出什么是最佳实践。不幸的是，目前没有标记为antimeridian的问题，因此很难搜索相关问题。我所看到的那些困扰该问题的问题似乎都在寻求针对特定应用的建议。这个问题简要讨论了跨越地球的GeoJSON多边形无边界情况下的反子午线。这个问题很接近我的要求。 我需要将历史和预报的气旋存储在空间数据库中，但我希望反高度子集会出现问题。例如，一条线从纬度/经度开始，在其方向(0,179)结束时(0,-179)是不明确的：无论是经过小子午线的短路径，还是“包裹”整个星球。这样的路径应如何存储在空间数据库中（特别是我正在使用PostGIS，但我希望解决方案足够通用）？我有一些想法： 无需更改要素几何并将模糊性转移到客户端应用程序。 将跨越子午线的任何特征分割为多部分几何，并在子午线处断开。（GeoJSON规范支持命名的CRS。） 使用不具有这种不连续性的不同旋风盆地或海洋区域的非全局投影 利用从未观察到旋风绕着整个行星传播这一事实，存储旋风的坐标，该旋风的坐标从纬度范围开始(90,-90) 偏移了360°相位（保持其他-180-180°） 利用一个事实，即在非洲南端以南极不可能发生气旋，请使用经度为30°的中断（如上图所示）。 允许坐标超出EPSG 4326的有效范围，例如，对于任何通过后向子午线的要素，> 180°且<-180°。 Delta编码，例如在TopoJSON中（例如，始于，(0,-179)然后下一个坐标为-3西纬）。我不知道在PostGIS中存储数据时是否或如何实现此功能，但这是将数据发送到客户端应用程序的绝佳解决方案。 矢量符号或极坐标的某种形式。（似乎相当困难和不寻常。） 其中，我不喜欢想法2–5，因为它们不是通用的，但是我喜欢它们，因为它们对我的特定应用程序有意义。对于仅在太平洋中处理数据的应用程序，它们可能很有意义，因此我不希望完全打折。 想法6和7是从汤姆·麦克赖特（Tom MacWright）的博客中提出的，该博客值得一读，但对于antimeridian而言并不确定。 Idea 4由GeographicaGS'使用GeodesicLinesToGISPython，而后者又使用fiona.transform.transform_geom了360°的时间偏移。反过来，Fiona正在使用OGR的-wrapdateline。我认为这是一个非常坚实的先例，实际上是相当普遍的。 结合存储问题，我需要考虑应如何将此类功能发送到客户端应用程序，以及我的应用程序应如何考虑回传到该应用程序的数据（例如，人类预报员更改了太平洋气旋的预报轨迹）。交换格式可能是GeoJSON，但不是必须的。 不幸的是，GeoJSON规范并未明确涉及时间轴问题。来自维基百科： 许多地理软件库或数据格式将世界投影到一个矩形。通常，此矩形正好在第180个子午线上精确地分割。这通常使得不可能在第180个子午线上执行简单的任务（例如表示一个区域或一条线）。一些例子： GeoJSON规范在其规范中并未提及对第180条子午线的处理，因此，跨越第180条子午线的线的表示也可以解释为遍历世界。 在OpenStreetMap中，区域（例如俄罗斯边界）在第180个子午线上被分割。 我的理解是，GeoJSON没有特定的跨时间跨度特征的标准表示形式，并且故意将其含糊不清（多部分几何形状可能会解决此问题）。类似地，在OpenStreetMap中，后子午线处有几何划分，尽管我不知道这样的拆分要素是多部分的还是实际上是离散的记录。 这带来了相当大的问题，尤其是从提出跨越此线的边界框或其他空间请求的角度而言，而且在解析和清理输入以及对要素几何的任何更新方面也是如此。这就是为什么我试图确定我可以寻求遵循的最佳实践的原因。