MULTIPOLYGONレコードをPostGIS（v2.2.2）からQGIS（v2.18.9）を介してシェープファイルに変換しようとしていますが、下の画像に表示されているように、ソースジオメトリと結果のシェープファイルが一致しません（赤いレイヤーがソースです）緑のレイヤーが結果のシェープファイルです）。GDAL v2.0.0からogr2ogrを介して変換を実行しても、同じ結果が得られます。この変換は完了するまでに約40分かかります。
ソースジオメトリをPOLYGONにダンプして変換を実行すると、結果のシェープファイルは正しく、変換がはるかに高速になります（ダンプには7秒+ 17秒）。しかし、5つの機能ではなく、305188になりました。
ソースのMULTIPOLYGONレコードは、必要に応じて、隣接するセルのST_Unionによって作成されます。
何か不足していますか？正しい変換を実行する方法はありますか？なぜこれが起こっているのか誰でも説明できますか？
ソースジオメトリ
矢印でマークされた穴のあるエクスポートされたシェープファイル
詳細があります：
pgsql2shpは、QGISやogr2ogrのような同じ結果のシェープファイルを生成します。
@dbaston-私はほとんどのデータを切り取って、上の画像に表示されている領域の周りの部分を残しました（周り（ 'POINT（-89.45 29.99）'、4326））。私はこの小さなサンプルを変換し、同じ結果を得ました。あなたまたは誰かが同じサンプルで変換を試したい場合は、ここでダンプを取得できます：
PostgreSQL v9.5からのサンプルデータバックアップ
31時間後、ST_IsValidは完全なデータセットのすべてのジオメトリでtrueを返しました。上記のリンクから入手できる小さいサンプルでも同じ結果が得られました。ただし、返された同じ小さいデータセットについてQGISで有効性を確認します。
ring 1 of polygon 712 not in exterior ring
ring 2 of polygon 712 not in exterior ring
ring 3 of polygon 712 not in exterior...PostGISとQGISの有効性チェックに違いがあるのはなぜですか？
さらに確認するために、上の画像で青でマークされている部分を除くすべてのポリゴンパーツを削除しました。私はそのWKT形式を確認しましたが、問題はありません。そして今、この機能だけを備えたシェープファイルへの変換は正しかった。
これは意味がありますか？隣接するセルでST_Unionによって作成されたより多くのデータセットをチェックしたところ、シェープファイルに変換するときに同じ問題が存在することがわかりました。同じデータをGeoJSONに変換すると、正しい結果が得られます。
MULTIPOLYGONは、次の式を使用してPOLYGONジオメトリから作成されました。
st_multi(st_union(st_buffer(geom,0)))ogr2ogr、pgsql2shpそれぞれに問題がある場合もあります。問題を小さな入力に減らすことができれば、バグレポートとして役立ちます。
