2
地理的データがantimeridianに及ぶデータベースおよびAPIのベストプラクティス
地理的特徴（ライン、ポリゴン、およびそれらの同等のマルチパート）がantimeridian（±180°経度）にまたがり、GeoJSONとしてクライアントWebアプリケーションに送信および受信する必要がある場合、それらを保存するためのベストプラクティスは何ですか？ 私は、Postgres / PostGISデータベースのサポートを受けて、サーバー側のWeb APIで作業を開始し、熱帯低気圧の履歴と風の半径を予測します。太平洋の多くのサイクロンは、時には寿命の間に複数回、反時計回りを通過する不幸な傾向があります。 ニュージーランドのアンティリディアンの近くに住んでいる私は、地域のデータでこの問題に何度も対処し、対処戦略を立てましたが、実際にベストプラクティスと考えられるものを見つけたいと思います。残念ながら、antimeridianでタグ付けされた既存の質問はないため、関連する質問を検索するのは困難です。私がこの問題に苦労しているのを見た質問はすべて、非常にアプリケーション固有のアドバイスを求めているようです。この質問では、境界のない地球に広がるGeoJSONポリゴンの場合の反時計回りについて簡単に説明します。この質問は、私が尋ねていることにかなり近いものです。 空間的データベースに歴史的サイクロンと予測サイクロンを保存する必要がありますが、反時計回りに問題があると予想しています。たとえば、緯度/経度(0,179)で始まり、で終わる線(0,-179)は、その方向に関してあいまいです。それは、反時計回りを横切る短い経路を取るか、惑星全体を「包む」かです。このようなパスを空間データベースにどのように保存する必要がありますか（具体的には私はPostGISを使用していますが、ソリューションが十分に汎用的であることを望みます）。私が持っているいくつかのアイデア： フィーチャジオメトリに変更を加えず、クライアントアプリケーションへの曖昧さをシフトします。 antimeridianを横切るフィーチャを、antimeridianでブレークするマルチパートジオメトリに分割します。（GeoJSON仕様は名前付きCRSをサポートしています。） 仕事以外のグローバル予測などの不連続を持っていない別のサイクロン流域や海洋地域のために サイクロンが惑星全体を巡回することが一度も観察されていないという事実を利用して(90,-90) 、360°の位相でオフセットされた緯度範囲から始まるサイクロンの座標を保存します（他の-180-180°を維持） サイクロンがアフリカの南端の南にある可能性が非常に低いという事実を利用して、経度30°でブレークを使用します（上記のマップのように）。 座標がEPSG 4326の有効範囲を超えて拡張できるようにします。たとえば、反時計回りを通過するすべてのフィーチャに対して、180度以上-180度未満です。 TopoJSONと同様に、デルタエンコーディング（例：で始まり(0,-179)、次の座標は-3緯度西です）。PostGISにデータを保存するときにこれを実装するかどうか、または実装する方法がわかりませんが、これはクライアントアプリケーションにデータを送信するための優れたソリューションです。 何らかの形式のベクトル表記または極座標。（かなり難しくて珍しいようです。） これらのうち、アイデア2〜5は一般的なものではないので好きではありませんが、私の特定のアプリケーションにとって意味があるので好きです。太平洋のデータのみを処理するアプリケーションの場合、それらは非常に理にかなっている可能性があるため、オプションとして完全に割引したくはありません。 アイデア6および7は、Tom MacWrightのブログから取り上げられました。このブログは読む価値はありますが、反時計回りに関しては決定的なものではありません。 アイデア4はGeographicaGS 'GeodesicLinesToGISPythonによって使用されfiona.transform.transform_geom、360°の反時計回りオフセットで使用されています。次に、FionaはOGRを使用してい-wrapdatelineます。これは非常に堅実な先例であり、実際にはかなり一般的だと思います。 ストレージの問題に関連して、そのような機能をクライアントアプリケーションに送信する方法、およびアプリケーションがそこにポストバックされるデータを考慮する方法を検討する必要があります（たとえば、太平洋のサイクロンの予測トラックを変更する人間予報士）。交換形式はおそらくGeoJSONになりますが、そうである必要はありません。 残念ながら、GeoJSON仕様は、反時計回りの問題について明示的ではありません。ウィキペディアからこれ： 多くの地理的ソフトウェアライブラリまたはデータ形式は、世界を長方形に投影します。多くの場合、この長方形は180番目の子午線で正確に分割されます。これにより、180番目の子午線上で単純なタスク（エリアやラインを表すなど）を実行できなくなることがよくあります。いくつかの例： GeoJSON仕様では、仕様で180番目の子午線の処理に言及していないため、180番目の子午線を横切る線の表現は、世界中を回っていると解釈できます。 OpenStreetMapでは、領域（ロシアの境界など）は180番目の子午線で分割されます。 私の読書では、GeoJSONには反時計回りに広がる特徴の特定の標準表現はなく、意図的に曖昧なままになっています（マルチパートジオメトリによって問題が解決される可能性があります）。同様に、OpenStreetMapにはantimeridianにジオメトリ分割がありますが、そのような分割されたフィーチャがマルチパートであるか、実際に個別のレコードであるかはわかりません。 これは、特にバウンディングボックスまたはこの行にまたがる他の空間要求を作成するという観点からだけでなく、入力の解析とサニタイズおよびフィーチャジオメトリの更新においても、かなり問題があります。これが、私が従うことができるベストプラクティスを決定しようとしている理由です。