我正在Postgres / PostGIS数据库的支持下开始在服务器端Web API上进行工作，以处理历史和预报的热带气旋径迹和风半径。不幸的是，太平洋上的许多气旋都有越过沙漏的趋势，有时在生命周期内多次发生过：
作为居住在沙漏附近的新西兰人，我经常在区域数据中经常遇到此问题有一些应对策略，但我想实际找出什么是最佳实践。不幸的是，目前没有标记为antimeridian的问题，因此很难搜索相关问题。我所看到的那些困扰该问题的问题似乎都在寻求针对特定应用的建议。这个问题简要讨论了跨越地球的无边界GeoJSON多边形的情况下的反时间轴。这个问题与我要问的问题非常接近。
我需要将历史和预报的旋风存储在空间数据库中，但是我预计an子会出现问题。例如，从纬度/经度
(0,179)开始并在(0,-179)结束的直线相对于其方向来说是模棱两可的：无论是经过小子午线的短路径还是整个地球的“包裹”。这样的路径应如何存储在空间数据库中（特别是我正在使用PostGIS，但我希望解决方案足够通用）？我有一些想法：不更改要素几何并将歧义性转移到客户端应用程序。
将跨越子午线的任何要素拆分为一个多部分几何体，并在子午线处断开。 （GeoJSON规范支持命名的CRS。）
处理不具有这种不连续性的不同旋风盆地或海洋区域的非全局投影
利用旋风永远不会被观测到绕着整个行星旅行，存储旋风分离器的坐标，其起始位置为纬度范围
(90,-90)，相差360°（保持其他相位为-180-180°）利用以下事实：南半球旋风极不可能发生非洲的南端，请在30度经度处折断（如上图所示）。
允许坐标超出EPSG 4326的有效范围，例如> 180°且<-180°（表示通过antimeridian的任何要素）。Delta编码，例如TopoJSON（例如，从
(0,-179)开始，然后下一个坐标为-3北纬西）。我不知道在PostGIS中存储数据时是否或如何实现此功能，但这对于将数据发送到客户端应用程序来说是一个很好的解决方案。矢量表示法或极坐标的某种形式。 （似乎很困难且与众不同。）其中，我不喜欢想法2–5，因为它们不是通用的，但我喜欢它们是因为它们对我的特定应用程序有意义。对于仅处理太平洋数据的应用程序来说，它们可能很有意义，因此我不想将它们作为选项完全抛弃。
想法6和7摘自Tom MacWright的博客，这值得
Idea 4由GeographicaGS的
GeodesicLinesToGISPython使用，而后者又使用q3602079q，具有360°的子午线偏移。反过来，Fiona使用OGR的fiona.transform.transform_geom。我想这是一个非常扎实的先例，而且实际上相当通用。结合存储问题，我需要考虑应如何将此类功能发送到客户端应用程序，以及我的应用程序应如何考虑发布回其的数据（例如，人类预报员更改了太平洋气旋的预报轨迹）。交换格式可能是GeoJSON，但不一定是。
不幸的是，GeoJSON规范并未明确涉及时间轴问题。这来自维基百科：
许多地理软件库或数据格式将世界投影为矩形；通常，此矩形正好在第180个子午线上精确地分割。这通常使得不可能在第180个子午线上执行简单的任务（例如表示一个区域或一条线）。一些示例：
GeoJSON规范在其规范中并未提及对第180条子午线的处理，因此，穿过第180条子午线的线表示也可以解释为四处走动
在OpenStreetMap中，区域（如俄罗斯边界）在第180个子午线上被分割。
我的读起来是，GeoJSON没有特定的跨时距特征的标准表示，并且故意将其含糊不清（多部分几何形状可能会解决此问题）。类似地，在OpenStreetMap中，an子午线处有几何分割，尽管我不知道这样的分割要素是多部分的还是实际上是离散的记录。跨越这条线，而且还要解析和清理输入以及对要素几何的任何更新。这就是为什么我试图确定可以寻求遵循的最佳实践的原因。
#1 楼
纯粹从数据存储和分析的角度而言，用于PostGIS的geography类型在设计时考虑到了子午线（在多个设计目标中）。有几种专门为geography类型设计的函数。例如，考虑跨越斐济Taveuni的LineString（与Great Circle Mapper映射），它跨越了时空：
SELECT ST_Length('LINESTRING(179.9 -17, -179.8 -16.7)'::geography);
该测地线的长度约为46公里。同样，即使经度坐标在+179到-179之间跳跃，ST_Area也可以在该岛的Polygon上正常工作。最后一个坐标的经度> 180：在第一个示例中，它被转换回完全相同的
geometry类型，但现在具有GeoJSON输出。您可以选择忽略NOTICE（或例如geography），然后将各种有趣的几何图形转换为geography类型。在PostGIS外部的地图上显示
SET client_min_messages TO WARNING;类型是另一回事，希望在这方面有更好的答案。评论
一个局限性是，地理区域的长度不得超过/大于180º（请参阅高级常见问题解答）。但是，您可以仅对顶点使用此规则，然后做一些愚蠢的事情：LINESTRING（179.9 -17，60 -16.9，-60 -16.8，-179.8 -16.7），这些环绕。
– Mike T
16年5月4日，11：15
#2 楼
当然，首选答案是（1），即让客户做“正确的事”。可以考虑的一个很好的例子是表示由此kml文件近似的表示南极洲的多边形<kml>
<Folder>
<name>Antarctica</name>
<Placemark>
<name>Antarctica</name>
<Polygon>
<tessellate>1</tessellate>
<outerBoundaryIs>
<LinearRing>
<coordinates>
-58,-63.1,0
-74,-72.9,0
-102,-71.9,0
-102,-74.9,0
-131,-74.3,0
-163,-77.5,0
163,-77.4,0
172,-71.7,0
140,-65.9,0
113,-65.7,0
88,-66.6,0
59,-66.9,0
25,-69.8,0
-4,-70,0
-14,-71,0
-33,-77.3,0
-46,-77.9,0
-61,-74.7,0
-58,-63.1,0
</coordinates>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</Placemark>
</Folder>
</kml>
经度中断发生处的增量编码或移位将不会发生。 t帮忙提供这样的数据。将其工作到特定于南极洲的投影会起作用，但是这并不是一般解决方案。 “概述”模式）。在这里看到
评论
我对Google Earth不太了解，所以我不知道如何启用轮廓模式。但是在这里，您有一个有效的多边形，该多边形跨越了子午线，并且在您的图像中我们看到Google Earth无法正确渲染该多边形：因此，如果Google Earth无法应对，那么如何证明将歧义传递给客户端应用程序是最佳实践呢？它？顺便说一句，QGIS给我提供了SRID 4326中此多边形的渲染问题，但是如果我在反子午线处引入了一条线（除非...好了，这条线），我就没有渲染问题。如果使用南极立体投影，则原始效果会很好。
– alphabetasoup
16年5月7日在0:18
很公平。但是，鉴于kml坐标仅限于纬度和经度，在这个特定示例中，用户（用户）无法采取任何措施来帮助Google Earth。 Google Earth维护人员有责任在客户端解决此问题。 （不幸的是，他们这样做的意愿很小！）
– cffk
16年5月7日，0：46
评论
这是一个非常好的问题，以前我使用的是从90度开始的手工坐标系，但我只关心一个很小的区域。确实没有任何东西可以适当地“环绕”；我猜这是因为没有重要的陆地跨越180，几乎没有人需要在其上绘制地图，整个问题很少受到关注。好问题。我认为您对第4点很感兴趣，尽管实际上没有理由使用mod来恢复坐标不能超出360。 Delta听起来像是最可扩展的解决方案，甚至可以在数据压缩方面带来一些好处，但是正如您所说的，将责任转移给了客户。
自1.0 RC起，有关GeoJSON的一些注释现在已过时。一个示例是，不推荐使用GeoJSON中的CRS定义（sgillies.net//2014/08/06/pruning-crs-from-geojson.html）。我会最终对其进行编辑。