PostGIS / PostgeSQLでの空間データのストレージの構成

画像 地図、図表、計画の開発に携わっている1つのオフィスに到着すると、私は1つのことに非常に驚きました。すべての資料の中央リポジトリがありませんでした。 ユーザーはそれぞれ独自のベストプラクティスを使用して作業しました。 また、別のプロジェクトから何かを取得する必要がある場合は、フラッシュドライブで実行するか、ネットワーク経由でファイルをコピーする必要がありました。 これにより、多くのワークステーションで異なる新鮮さの複製という形で信じられないほどの「ゴミ」が作成されました。



この混乱のすべてを観察した後、個々のプロジェクトへのアクセス権を区別し、さらにプロジェクトに加えられた変更を監視することで、すべてを「くし」にして地図作成資料の保管を集中化することにしました。



PostGIS拡張機能を備えたPostgeSQL DBMSを選択したため、データベースに地理データ(オブジェクトジオメトリ)を保存できます。 選択の決定要因の1つは、ユーザーが追加の「クランチ」なしでデータベースを操作するために使用するソフトウェア製品の機能です。 プラスは、プロジェクトのオープン性と、同じレイヤーでのマルチユーザー作業の可能性です。



DBMS自体については説明しません-良いことも悪いことも、すでにたくさん書かれています。 設定については説明しませんので。



PostGIS拡張機能自体について説明します。



PostGISは2001年にRefractions Researchによってリリースされ、無料のオープンソースソフトウェア製品でありながら、商用ソリューションと競合しています。 PostGISの主な利点は、空間演算子および関数と組み合わせてSQL言語を使用できることです。 シンプルなデータストレージに加えて、PostGISでは、あらゆる種類の操作を実行できます。



実際、さらにデータベース内の空間データのストレージの組織に従事します。 構造の視覚化の便宜上、pgAdmin3が使用されます。



デジタルカードでの作業の詳細は、本格的なカードを取得するには、さまざまなオブジェクトを含む複数のレイヤーが必要なことです。 たとえば、都市には、建物と道路の少なくとも2つのレイヤーが必要です。 複数の都市があり、それぞれに独立したデータが含まれているとします。 各都市について、データベースに個別のスキーマを作成します。

 CREATE DATABASE goroda OWNER postgres; CREATE SCHEMA gorod1 OWNER postgres; CREATE SCHEMA gorod2 OWNER postgres;
      
      











次に、これらの既存のデータを作成されたスキームに入力します。これには、無料のローダーのいずれかを使用します:shp2pgsql、 OGR2OGR 、QuantumGIS SPIT、 PostGISなどのshpローダー

テーブルの所有者を割り当てます。

 ALTER TABLE road1 OWNER TO postgres; ALTER TABLE building1 OWNER TO postgres;
      
      









その結果、次のフォームを取得します。



road1テーブルとbuilding1テーブルに加えて、パブリックスキーマにはさらに2つが作成されました。geometry_columnsとspatial_ref_sysです。 geometry_columnsテーブルには、空間情報を含むデータベーステーブルに関する情報が格納されます。 spatial_ref_sysテーブルには、空間データベースで使用される座標系の数値識別子とテキスト記述が含まれます。



テーブルの所有者が整理されたら、ユーザー次第です。 まず、それらを作成します。

 CREATE USER user1 WITH PASSWORD 'psswd1'; CREATE USER user2 WITH PASSWORD 'psswd2';
      
      









これらのテーブルを使用する権利を公開します。

 GRANT SELECT ON TABLE road1 TO user1; GRANT SELECT ON TABLE building1 TO user1;
      
      









このフォームでは、権利は読み取り専用です。



編集のために次の権限を設定できます。

更新-既存のオブジェクトを変更する機能。

INSERT-新しいオブジェクトを追加します。

DELETE-オブジェクトを削除します。

実際、すべてが標準SQLのようなものです。





したがって、これらの特権を組み合わせて、既存のオブジェクトを作成または変更する権限のみ、または完全に編集する権限をユーザーに設定できます。



次に、空間情報を使用してテーブルに権限を設定します。

 GRANT SELECT ON geometry_columns TO user1; GRANT SELECT ON spatial_ref_sys TO user1;
      
      









SELECTのみを選択した場合、ユーザーはレイヤーのみを表示します。 ALLの場合、独自のテーブルを作成できます(たとえば、バス停のあるレイヤー)。 2番目のユーザーに次の特権を付与します。

 GRANT ALL ON geometry_columns TO user2; GRANT ALL ON spatial_ref_sys TO user2;
      
      









ユーザーがテーブルにレコードを作成する(マップを編集する)ために、テーブルシーケンスを使用できるようにします。

 GRANT USAGE ON SEQUENCE road1_gid_seq TO user1; GRANT USAGE ON SEQUENCE building1_gid_seq TO user1;
      
      









2番目のユーザーについても同じことができます。

データベースは複数のスキームを使用しているため、テーブルに権限を割り当てるときは、schema.tableへのフルパスを示します。



これで、空間データと、それらへの異なるアクセス権を持つユーザーを持つデータベースが作成されました。完全から「見た目」までです。 実際、これが必要なものでした。



次の記事では、空間オブジェクトを持つテーブルの監査について検討します。



All Articles