PostgreSQL上のPostGISの目的は何ですか？

PostgreSQLはすでに空間データ型、演算子、インデックス付けをサポートしています。

PostGISは、PostgreSQLの拡張機能として存在することを必要にした正確に何を提供しますか？

PostgreSQLの空間機能だけを使用しないのはなぜですか？

宇宙を2001年初頭に巻き戻し、PostGISの発明者に未来を見せるだけでなく、PgSQLのPSCに未来を見させた場合、おそらくPostGISはPgSQLの一連のパッチになるでしょう。しかし、少なくとも、コアへのパッチとして開始した場合、最初に遭遇することは次のとおりです。

• コアPgSQLエリアはホールをサポートしていませんが、GISモデルは本当にホールを必要としています。それを変更できますか？

そして、コアPgSQLは次のように言っていました。「もちろん、そうではありません。領域には既存の十分に理解されたセマンティックスがあり、そのような後方互換性のない変更を加えることはできません」

コアではない開発者として、PostGISは数年間、月間および6か月間のリリースを打ち切ることができましたが、PgSQLコアは年次および長期のリリースとともにpl延していました。また、プロジェクトにコミット権があるため、必要な機能をいつでも追加できましたが、PgSQLでコミット権を取得するには非常に長い時間がかかります。

PostGISがPgSQLコアを見渡して「コアに追加機能を持たせてよかった」と自分自身に言うほど十分な外部価値を実証していた頃には、 PgSQL（互換性のないライセンスの下では言うまでもありません）は、マージのアイデアが実際に可能ではなかったことを示しています。

代わりに、PostGISはPgSQLがモジュール式で拡張可能なままでいるのを支援するReally Large Complex Extensionsの標準的な例になりました。「これがPostGISのようなものにどのように影響するか」は、コアPgSQLがいくつかの変更を評価するときによく尋ねられる質問です。これは良いことでもあり、おそらくPostGISがコアの一部であるほど良くはありませんが、十分です。

他にも、PgSQLコアには見られない依存関係の長いリスト、一般的にコードの一貫性が低く、APIの清浄度が改善に絶望していたなどの理由があります。構想でさえ、PostGISは大きすぎてPgSQLが一口で飲み込めません。

それは単に真実ではありません。PostgreSQLは空間データ型をサポートしていません。幾何学的型をサポートします。これらはいくつかの点ではまったく問題ありませんが、実際の座標系とはまったく別のものです。ネイティブ型

• 空間参照システムID / SRSIDはありません。
• 再投影することはできません。
• でも上の回転楕円体、彼らは非常に限られた機能を提供します。
• それらは標準化されていません。
• GISTインデックスは提供しません。

更新

インデックスの質問については、FAQにあります

PostgreSQL R-Treeインデックスがサポートされないのはなぜですか？

PostGISの初期バージョンはPostgreSQL R-Treeインデックスを使用していました。ただし、PostgreSQL R-Treeはバージョン0.6以降完全に破棄されており、R-Tree-over-GiSTスキームで空間インデックスが提供されています。

テストでは、ネイティブRツリーとGiSTの検索速度が同等であることが示されました。ネイティブPostgreSQL R-Treeには、GIS機能で使用するのに望ましくない2つの制限があります（これらの制限は、一般的なR-Treeの概念ではなく、現在のPostgreSQLネイティブR-Treeの実装によるものです）。

• PostgreSQLのRツリーインデックスは、サイズが8Kを超える機能を処理できません。GiSTインデックスでは、機能自体をバウンディングボックスに置き換える「損失の多い」トリックを使用できます。

• PostgreSQLのRツリーインデックスは「nullセーフ」ではないため、nullジオメトリを含むジオメトリ列でのインデックスの構築は失敗します。[GiSTインデックスはnullセーフです]

PostGISは、PostgreSQLオブジェクトリレーショナルデータベース用の空間データベースエクステンダーです 。場所クエリをSQLで実行できるようにする地理オブジェクトのサポートを追加します。

SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';

基本的な位置認識に加えて、PostGISは、Oracle Locator / SpatialやSQL Serverなどの他の競合する空間データベースではめったに見られない多くの機能を提供します。詳細については、PostGIS機能リストを参照してください。

PostGIS機能リストは、これらの機能も拡張します。

PostGISは、PostgreSQLデータベースに追加のタイプ（ジオメトリ、地理、ラスターなど）を追加します。また、これらの空間タイプに適用される関数、演算子、およびインデックスの機能強化も追加されています。これらの追加の関数、演算子、インデックスバインディング、およびタイプは、PostgreSQLの中核となるDBMSの能力を強化し、高速で機能豊富で堅牢な空間データベース管理システムにします。

機能リスト

PostGIS 2+シリーズは以下を提供します：

• 細分化されたラスター処理のためのSQLラスターマップ代数の力を使用して、スプライシング、ダイシング、モーフィング、再分類、および収集/結合のためのベクターおよびラスターデータの両方の処理および分析機能
• ベクトルおよびラスターデータの両方の空間再投影SQL呼び出し可能関数コマンドラインツールとGUIパッケージツールの両方を介したESRIシェープファイルベクトルデータのインポート/エクスポートのサポート、および他のサードパーティのオープンソースツールを介したより多くの形式のサポート

• 多くの標準形式からラスターデータをインポートするためのパッケージ化されたコマンドライン：GeoTiff、NetCDF、PNG、JPG

• ベクトルデータのレンダリングとインポートは、SQLを使用してKML、GML、GeoJSON、GeoHash、WKTなどの標準のテキスト形式の関数をサポートします。

• 幾何学的領域ごとのピクセル値の押し出し、領域ごとの統計の実行、ジオメトリごとのラスターのクリッピング、ラスターのベクトル化のためのシームレスなラスター/ベクターSQL呼び出し可能関数3Dオブジェクトのサポート、空間インデックス、および機能ネットワークトポロジーのサポート/ 米国国勢調査タイガーデータの活用

さらに、この投稿で既に言及したポイント/パーツへ。PostGIS Webサイトで言及されているように追加します

PostGISはCであるため、CおよびC ++の他のライブラリを使用でき、自由に使用できます。PostGISは以下に依存します：

• 多くのジオメトリ処理アルゴリズム用のGEOS
• 座標再投影関数のProj.4
• ラスタ処理およびフォーマットサポート用のGDAL
• XML解析用のLibXML2
• JSON解析用のJSON-C
• 拡張3Dサポートおよび追加のジオプロセシングアルゴリズム用のSFCGAL