14.3. データ形式とフィールドの探究

14.3.1. ラスタデータ

GISラスタデータは、地表面上、大気中、地下の特徴や現象を表す離散的なセルの行列です。ラスタグリッドの各セルは同じサイズで、セルは通常、長方形(QGIS では常に長方形)です。典型的なラスタデータセットには、航空写真や衛星画像などのリモートセンシングデータ、標高や気温などのモデル化されたデータなどがあります。

ベクタデータとは異なり、ラスタデータは通常、各セルに関連するデータベースレコードを持ちません。これらのデータは、ピクセル解像度とラスタレイヤのコーナーピクセルの X/Y 座標によってジオコーディングされています。これにより、QGISはマップキャンバス上にデータを正確に配置することができます。

GeoPackage形式は、QGISで作業する際にラスタデータを保持するのに便利な形式です。一般的で強力な機能を持つGeoTiff形式も良い選択肢になります。

QGISは適切にデータを表示するために、ラスタレイヤ内部(例: GeoTiff )や関連付けられた ワールドファイル のジオリファレンス情報を利用しています。

14.3.2. ベクタデータ

Many of the features and tools available in QGIS work the same, regardless the vector data source. However, because of the differences in format specifications (GeoPackage, ESRI Shapefile, MapInfo and MicroStation file formats, AutoCAD DXF, PostGIS, SpatiaLite, Oracle Spatial, MSSQL Spatial, SAP HANA Spatial databases and many more), QGIS may handle some of their properties differently. Support is provided by the OGR Simple Feature Library. This section describes how to work with these specificities.

注釈

QGISではポイント(マルチポイント)、ライン(マルチライン)、ポリゴン(マルチポリゴン)、円形ストリング、複合曲線、カーブポリゴン、マルチカーブ、マルチサーフェスの地物タイプをサポートしており、全ての地物タイプはオプションでZ値やM値を持つことができます。

一部のドライバは円形ストリング、複合曲線、カーブポリゴン、マルチカーブ、マルチサーフェスの地物タイプなどをサポートしていないものがあることに注意してください。QGISはこれらを変換します。

14.3.2.1. GeoPackage

GeoPackage (GPKG)形式はプラットフォームに依存しない形式で、SQLiteデータベースコンテナとして実装されており、ベクタデータとラスタデータの両方を格納するために使用することができます。この形式はOpen Geospatial Consortium (OGC)によって定義され、2014年に公開されました。

GeoPackageはSQLiteデータベース内に以下のものを格納するために使用できます:

  • ベクタ 地物

  • 画像のタイルマトリックスセットラスタ マップ

  • 属性データ(非空間データ)

  • 拡張情報

QGISバージョン3.8以降では、GeoPackageはQGISのプロジェクトを保存できるようになりました。GeoPackageレイヤはJSONフィールドを持つことができます。

GeoPackageはQGISにおいてベクタデータのデフォルトの形式です。

14.3.2.2. ESRIシェープファイル形式

例えばGeoPackageやSpatiaLiteと比較するといくつかの制限はありますが、ESRIシェープファイル形式は未だに最も使われているベクタファイル形式の一つです。

ESRIシェープファイル形式のデータセットはいくつかのファイルからなります。下記の3つは必須です。

  1. .shp ファイルは地物のジオメトリを持ちます。

  2. .dbf ファイルはdBase形式で属性を保持します。

  3. .shx インデックスファイル

ESRIシェープファイル形式のデータセットは、投影法に関する情報を持った .prj 拡張子を持つファイルを含めることもできます。投影法ファイルがあると便利ですが、これは必須ではありません。シェープファイル形式のデータセットには追加のファイルを含めることもできます。詳細については、ESRIの技術仕様 https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf を参照してください。

GDAL 3.1 では圧縮されたESRIシェープファイル形式( shzshp.zip )の読み書きをサポートしています。

ESRIシェープファイル形式のデータセットのパフォーマンスを向上させる

ESRIシェープファイル形式のデータセットの描画パフォーマンスを向上するには、空間インデックスを作成します。空間インデックスによってズーム、パン両方の速度が向上します。QGISで使用される空間インデックスは .qix 拡張子を持ちます。

空間インデックスを作成するには、以下の手順で操作します:

  1. ESRIシェープファイル形式のデータセットを読み込む( ブラウザパネル 参照)

  2. 凡例内のレイヤ名をダブルクリックするか、右クリックしてコンテキストメニューから プロパティ... を選択し、 レイヤプロパティ ダイアログを開く

  3. ソース タブで、 空間インデックスの作成 ボタンを押す

.prj ファイルの読み込みに関する問題

.prj ファイルを持ったESRIシェープファイル形式のデータセットを読み込んでもQGISがそのファイルから座標参照系を読み取れない場合は、レイヤの レイヤプロパティ ► ソース タブで setProjection CRSの選択 ボタンをクリックし、適切な投影法を手動で定義する必要があります。これは、 .prj ファイルが CRS ダイアログで表示されるようなQGISで使用される投影法パラメータを完全には指定していないことが多いためです。

同じ理由で、QGISで新しいESRIシェープファイル形式のデータセットを作成すると、2 つの異なる投影ファイルが作成されます:ESRIソフトウェアと互換性のある、限定された投影パラメータの .prj ファイルと、CRSのすべてのパラメータを指定する .qpj ファイルです。QGISが .qpj ファイルを見つけた時には、これが .prj ファイルの代わりに使用されます。

14.3.2.3. 区切りテキストファイル

区切りテキストファイルは、そのシンプルさと読みやすさから非常に一般的であり広く使われています。データはプレーンテキストエディタで閲覧・編集が可能です。区切りテキストファイルは表形式のデータで、列は決められた文字で区切られ、行は改行で区切られます。通常、最初の行には列名が含まれています。区切りテキストファイルの一般的なタイプは、列がカンマで区切られた CSV(Comma Separated Values)です。区切りテキストファイルは位置情報を含むこともできます( 区切りテキストファイルへのジオメトリ情報の保存 を参照してください)。

QGISでは、区切りテキストファイルをレイヤや通常のテーブルとして読み込むことができます( ブラウザパネル区切りテキストファイルをインポートする を参照)。まずは、ファイルが以下の条件を満たしていることを確認しましょう。

  1. ファイルにはフィールド名を区切ったヘッダー行が必要です。これはデータの最初の行(理想的にはテキストファイルの最初の行)でなければなりません。

  2. ジオメトリを有効にする場合には、ファイルにはジオメトリを定義するフィールドが含まれている必要があります。これらのフィールドには任意の名前を付けることができます。

  3. (ジオメトリが座標で定義されている場合は)XとYの座標フィールドは数値で指定する必要があります。座標系は重要ではありません。

  4. 文字列以外の列を持つCSVファイルがある場合、これに付随するCSVTファイルが必要です( CSVTファイルを使用したフィールドの書式制御 のセクションを参照してください)。

QGISサンプルデータセット( サンプルデータのダウンロード のセクション参照)内の標高点データファイル elevp.csv は、有効なテキストファイルの例です。

X;Y;ELEV
-300120;7689960;13
-654360;7562040;52
1640;7512840;3
[...]

このテキストファイルの注意点をいくつか挙げます:

  1. このテキストファイル例では、 ; (セミコロン)を区切り文字として使用しています(フィールドの区切りには任意の文字を使用可能です)。

  2. 最初の行は見出しです。ここには XY および ELEV というフィールドが含まれています。

  3. テキストフィールドを区切るための引用符( " )は使われていません。

  4. X座標は X フィールドに含まれています

  5. Y座標は Y フィールドに含まれています

区切りテキストファイルへのジオメトリ情報の保存

区切りテキストファイルには、主に2つの形式でジオメトリ情報を含めることができます:

  • ポイントジオメトリデータの場合は、別々の列に座標(例えば XcolYcol... )として含める

  • 任意のジオメトリタイプの場合は、単一の列にジオメトリの well-known text (WKT) 表現として含める

曲線ジオメトリ(円形ストリング、カーブポリゴン、複合曲線)の地物をサポートしています。以下は、WKTとしてコード化されたジオメトリを持つ区切りテキストファイルのジオメトリタイプの例です:

Label;WKT_geom
LineString;LINESTRING(10.0 20.0, 11.0 21.0, 13.0 25.5)
CircularString;CIRCULARSTRING(268 415,227 505,227 406)
CurvePolygon;CURVEPOLYGON(CIRCULARSTRING(1 3, 3 5, 4 7, 7 3, 1 3))
CompoundCurve;COMPOUNDCURVE((5 3, 5 13), CIRCULARSTRING(5 13, 7 15,
  9 13), (9 13, 9 3), CIRCULARSTRING(9 3, 7 1, 5 3))

区切りテキストファイルはジオメトリの Z 座標や M 座標もサポートしています:

LINESTRINGZ(10.0 20.0 30.0, 11.0 21.0 31.0, 11.0 22.0 30.0)

CSVTファイルを使用したフィールドの書式制御

CSVファイルを読み込む際、別の指定がない限りは、OGRドライバは全てのフィールドを文字列(テキスト)と仮定します。CSVTファイルを作成することで、さまざまな列のデータ型をOGR(そしてQGIS)に伝えることができます。

タイプ

名前

整数値

Integer

4

小数点付き数値

Real

3.456

日付

Date (YYYY-MM-DD)

2016-07-28

時刻

Time (HH:MM:SS+nn)

18:33:12+00

日付と時刻

DateTime (YYYY-MM-DD HH:MM:SS+nn)

2016-07-28 18:33:12+00

CSVTファイルは、データ型が引用符で囲まれ、コンマで区切られた 一行 のプレーンテキストファイルです。例えば

"Integer","Real","String"

各列の幅や精度を指定することもできます。例

"Integer(6)","Real(5.5)","String(22)"

このファイルは .csv ファイルと同じフォルダに同じ名前で保存されますが、拡張子は .csvt です。

更なる情報については GDAL CSV Driver を参照してください。

14.3.2.4. PostGISレイヤ

PostGISレイヤはPostgreSQLデータベースに格納されています。PostGISの長所は空間インデックス作成、フィルタリングそしてクエリ機能です。PostGIS を使用すると、選択や識別などのベクタレイヤに対する関数はQGIS のOGRレイヤを使用した場合よりも正確に動作します。

ちなみに

PostGISレイヤ

通常、PostGISレイヤはgeometry_columnsテーブルのエントリがあることによって識別されます。QGISでは、geometry_columnsテーブルのエントリを持たないレイヤもロードすることができます。これには、テーブルとビューの両方が含まれます。ビューの作成については、PostgreSQLのマニュアルを参照してください。

このセクションでは、QGISがPostgreSQLレイヤにアクセスする方法について、いくつかの詳細を説明します。ほとんどの場合、QGIS は単純にロード可能なデータベーステーブルのリストをユーザーに提供し、要求に応じてテーブルを読み込むだけです。しかし、PostgreSQLのテーブルをQGISに読み込むことができない場合には、以下の情報がQGISのメッセージを理解するための助けとなり、PostgreSQLのテーブルやビュー定義を修正してQGISで読み込めるようになるための方向性が得られるかもしれません。

注釈

A PostgreSQL database can also store QGIS projects.

主キー

QGISは、PostgreSQLレイヤがユニークなキーとして使用できる列を含んでいることを要求します。テーブルの場合、これは通常、テーブルに主キーまたはユニーク制約を持つ列を必要とすることを意味します。QGISでは、この列は int4型(4バイトサイズの整数)である必要があります。または、ctid 列を主キーとして使用することもできます。テーブルにこれらの項目がない場合、oid 列が代わりに使用されます。列にインデックスが作成されると、パフォーマンスが向上します(PostgreSQLでは主キーが自動的にインデックス化されることに注意してください)。

QGISには、デフォルトで有効になっている idで選択 チェックボックスがあります。このオプションは属性なしのid を取得しますが、多くの場合、これは主キーによる検索よりも高速です。

ビュー

PostgreSQLのレイヤがビューである場合でも同様の要件がありますが、ビューは必ずしも主キーやユニーク制約のある列を持っているとは限りません。ビューをロードする前に、QGISダイアログで主キーフィールド(整数である必要があります)を定義する必要があります。適切な列がビューに存在しない場合、QGISはレイヤをロードしません。このような場合には、適切な列(整数型で、主キーであるかまたはユニーク制約があり、できればインデックス付き)を確実に含むようにビューを変更することが解決策となります。

テーブルに関しては、 idで選択 のチェックボックスがデフォルトで有効になっています(チェックボックスの意味については上記参照)。複雑なビューを使用する場合には、このオプションを無効にした方がよいかもしれません。

注釈

PostgreSQL foreign table

PostgreSQL foreign tables are not explicitely supported by the PostgreSQL provider and will be handled like a view.

QGIS layer_style テーブルとデータベースのバックアップ

pg_dump コマンドと pg_restore コマンドを使用してPostGISデータベースのバックアップを作成したい場合、QGISで保存されたデフォルトのレイヤスタイルがその後のリストアに失敗する場合には、リストアコマンドの前にXML オプションを DOCUMENT に設定する必要があります。

SET XML OPTION DOCUMENT;

データベース側でのフィルタ

QGISでは、サーバサイドであらかじめ地物をフィルタリングすることができます。 設定 ► オプション ► データソース ►checkbox 可能であればサーバ側で式を実行する にチェックを入れると、サーバ側でフィルタリングされます。データベースに送信されるのは、サポートされている式のみです。サポートされていない演算子や関数を使用した式は、ローカル側での評価に滑らかにフォールバックします。

PostgreSQLのデータ型のサポート

PostgreSQLプロバイダでサポートされているデータ型には、以下のものが含まれます:整数、浮動小数点、論理値、バイナリオブジェクト、可変長文字、幾何データ、 日付/時刻、配列、 hstore(キー/バリュー型)、JSON

14.3.2.5. PostgreSQLへデータをインポートする

データは、DBマネージャプラグインやコマンドラインツールのshp2pgsql、ogr2ogrなど、いくつかのツールを使用してPostgreSQL/ PostGISにインポートできます。

DBマネージャ

QGISには、 dbManager DBマネージャ という名前のコアプラグインが付属しています。これはデータをロードするために使用することができ、スキーマもサポートしています。詳細は DB Manager Plugin を参照してください。

shp2pgsql

PostGISには shp2pgsql というユーティリティコマンドが含まれており、これを使用してシェープファイル形式のデータセットをPostGIS対応のデータベースにインポートすることができます。例えば、 lakes.shp という名前のシェープファイル形式のデータセットを gis_data という名前のPostgreSQLデータベースにインポートするには、次のコマンドを使用します:

shp2pgsql -s 2964 lakes.shp lakes_new | psql gis_data

これにより、 gis_data データベース内に lakes_new という名前の新規レイヤが作成されます。この新しいレイヤは空間参照識別子(SRID)が2964になります。空間参照系と投影法についての詳細は、 投影法の利用方法 を参照してください。

ちなみに

PostGISからデータセットをエクスポートする

PostGISのデータセットをシェープファイル形式へとエクスポートするツール pgsql2shp もあります。このツールはPostGISディストリビューションに付属しています。

ogr2ogr

shp2pgsqlDBマネージャ の他にも、PostGISにデータを読み込ませるツールがあります。 ogr2ogr です。これはGDALのインストールに含まれています。

シェープファイル形式のデータセットをPostGISにインポートするには、次のコマンドを使用します:

ogr2ogr -f "PostgreSQL" PG:"dbname=postgis host=myhost.de user=postgres
password=topsecret" alaska.shp

このコマンドは、シェープファイル形式のデータセット alaska.shp をホストサーバー myhost.de 上のPostGISデータベース postgis にユーザー postgres 、パスワード topsecret を使用してインポートします。

PostGISをサポートするためには、OGRはPostgreSQLのライブラリと共にビルドされている必要があることに注意してください。これを確認するためには、次のように入力します( nix の場合):

ogrinfo --formats | grep -i post

デフォルトの INSERT INTO メソッドの代わりにPostgreSQLの COPY コマンドを使用したい場合には、以下の環境変数を設定します( nixosx では利用可能):

export PG_USE_COPY=YES

ogr2ogrshp2pgsl のように空間インデックスを作成することはありません。インポート後に追加のステップとして、通常のSQLコマンド CREATE INDEX を使用して手動でインデックスを作成する必要があります(次のセクション パフォーマンスの改善 で説明します)。

パフォーマンスの改善

PostgreSQLデータベースからの地物の取得は、特にネットワーク経由では時間がかかります。データベース内の各レイヤにPostGIS空間インデックスがあることで、PostgreSQLレイヤの描画パフォーマンスを向上させることができます。PostGISは空間検索を高速化するためにGiST (Generalized Search Tree) インデックスの作成をサポートしています(GiSTインデックスの情報は https://postgis.net にあるPostGISドキュメントから引用しています)。

ちなみに

レイヤのインデックス作成にはDBマネージャを使用することができます。最初にレイヤを選択し、 テーブル ► テーブルの編集 をクリックして、 インデックス タブを開き、 空間インデックスの追加 ボタンを押します。

GiSTインデックスを作成するための構文は以下のとおりです:

CREATE INDEX [indexname] ON [tablename]
  USING GIST ( [geometryfield] GIST_GEOMETRY_OPS );

巨大なテーブルでは、インデックスの作成には長時間かかることに注意してください。インデックスが作成されたら、 VACUUM ANALYZE を実行してください。詳細な情報については、PostGISドキュメント( 文献とWeb参照 のPOSTGIS-PROJECT )を参照してください。

下記の例では、GiSTインデックスを作成しています:

[email protected]:~/current$ psql gis_data
Welcome to psql 8.3.0, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

gis_data=# CREATE INDEX sidx_alaska_lakes ON alaska_lakes
gis_data-# USING GIST (the_geom GIST_GEOMETRY_OPS);
CREATE INDEX
gis_data=# VACUUM ANALYZE alaska_lakes;
VACUUM
gis_data=# \q
[email protected]:~/current$

14.3.2.6. 経度 180° をまたぐベクタレイヤ

多くの GIS パッケージは、経度180度線を横切る地理参照系(緯度/経度)でベクタ地図をラップしません( http://postgis.refractions.net/documentation/manual-2.0/ST_Shift_Longitude.html )。この結果、そのような地図を QGIS で開くと、お互いに近いはずの2地点が大きく離れた場所のように見えます。 図 14.26 では、マップキャンバス左端の小さな点(チャタム諸島)は、地図上はニュージーランド本島の右側に位置しているべきものです。

../../../_images/vectorNotWrapping.png

図 14.26 180° 経線を横断する緯度/経度での地図

この問題の回避方法は、PostGIS の ST_Shift_Longitude 関数を使って経度の値を変換することです。この関数は、ジオメトリの各地物の各コンポーネントの点/頂点を読み、その経度が < 0° の場合には 360° を加算します。その結果、 0° - 360° のデータが 180° 中心の地図にプロットされます。

../../../_images/vectorWrapping.png

図 14.27 ST_Shift_Longitude 関数を適用して経度 180° をまたぐ

利用方法

  • 例えばDBマネージャプラグインを使用して、データをPostGISにインポートします( PostgreSQLへデータをインポートする 参照)。

  • PostGISコマンドラインインターフェイスを利用して、次のコマンドを発行します(例文中の "TABLE" はあなたのPostGISテーブルの実際の名前にして下さい): gis_data=# update TABLE set the_geom=ST_Shift_Longitude(the_geom);

  • すべてうまくいくと、更新された地物の数についての確認が表示されます。その後、地図を読み込むと違いを確認できます( Figure_vector_crossing_map )。

14.3.2.7. SpatiaLiteレイヤ

ベクタレイヤをSpatiaLite形式で保存したい場合には、 既存のレイヤから新しいレイヤを作成する の説明に従ってください。 形式 として SpatiaLite を選択し、 ファイル名レイヤ名 を入力してください。

また、形式として SQLite を選択し、 カスタムオプション ► データソース フィールドに ``SPATIALITE=YES``を追加することでもSpatiaLite形式で保存できます。このカスタムオプションは、GDALにSpatiaLiteデータベースを作成するように指示します。 https://gdal.org/drivers/vector/sqlite.html も参照してください。

QGISはSpatiaLiteで編集可能なビューもサポートしています。SpatiaLiteデータの管理には、 DBマネージャ コアプラグインを使用することもできます。

新しいSpatiaLiteレイヤを作成したい場合は 新しいSpatiaLiteレイヤを作成する を参照して下さい。

14.3.2.8. GeoJSONに特有のパラメータ

GeoJSON形式で レイヤをエクスポートする 場合、いくつか特有の レイヤオプション があります。これらのオプションは、ファイルに書き出すGDALのオプションに由来するものです:

  • COORDINATE_PRECISION 座標を書き込む際の小数点区切り文字以下の最大桁数を指定します。デフォルトは15です(注:緯度経度座標の場合には6で十分です)。末尾に続くゼロは切り捨てられます。

  • RFC7946 デフォルトではGeoJSON 2008が使用されます。この値がYESに設定されると、更新されたRFC 7946標準が使用されます。デフォルトはNOです(従ってGeoJSON 2008が使用されます)。 主な違いについては https://gdal.org/drivers/vector/geojson.html#rfc-7946-write-support を参照してください。簡単に言えば、RFC 7946標準ではEPSG:4326のみが許可され、他のCRSは変換されます。また、ポリゴンは向きの右手ルールに従うように書かれ、"bbox" 配列の値は [west, south, east, north] であり、[minx, miny, maxx, maxy] ではありません。そして、FeatureCollection、Feature、Geometryオブジェクトではいくつかの拡張メンバ名が禁止されており、デフォルトの座標精度は10進数で7桁です。

  • WRITE_BBOX をYESに設定すると、フィーチャーやフィーチャーコレクションのレベルでジオメトリのバウンディングボックスを含めます。

GeoJSONの他に、"GeoJSON - Newline Delimited" ( https://gdal.org/drivers/vector/geojsonseq.html 参照)へと出力するオプションもあります。フィーチャーコレクションのフィーチャーの代わりに、1種類のもの(おそらくは単一のフィーチャー)を改行区切りで連続的に並べます。

GeoJSON - Newline Delimited にもいくつかの特有のレイヤオプションがあります。

  • COORDINATE_PRECISION 上記を参照してください(GeoJSONのものと同様です)。

  • RS レコードの開始を RS=0x1E の文字とするかどうかを決めます。違いは、フィーチャーがどのように区切られるかにあります。 改行(LF)文字のみ(Newline Delimited JSON, geojsonl)か、レコード区切り(RS)文字がレコードの前に置かれて改行文字で区切られるか(GeoJSON Text Sequences, geojsons)です。 デフォルトはNOです。拡張子が指定されない場合は、ファイルに .json 拡張子が付きます。

14.3.2.9. SAP HANA Spatial Layers

This section contains some details on how QGIS accesses SAP HANA layers. Most of the time, QGIS should simply provide you with a list of database tables and views that can be loaded, and it will load them on request. However, if you have trouble loading an SAP HANA table or view into QGIS, the information below may help you understand the root cause and assist in resolving the issue.

Feature Identification

If you'd like to use all of QGIS' feature editing capabilities, QGIS must be able to unambiguously identify each feature in a layer. Internally, QGIS uses a 64-bit signed integer to identify features, whereas the negative range is reserved for special purposes.

Therefore, the SAP HANA provider requires a unique key that can be mapped to a positive 64-bit integer to fully support QGIS' feature editing capabilities. If it is not possible to create such a mapping, you might still view the features, but editing might not work.

Adding tables

When adding a table as a layer, the SAP HANA provider uses the table's primary key to map it to a unique feature id. Therefore, to have full feature editing support, you need to have a primary key to your table definition.

The SAP HANA provider supports multi-column primary keys, but if you'd like to get the best performance, your primary key should be a single column of type INTEGER.

Adding views

When adding a view as a layer, the SAP HANA provider cannot automatically identify columns that unambiguously identify a feature. Furthermore, some views are read-only and cannot be edited.

To have full feature editing support, the view must be updatable (check column IS_READ_ONLY in system view SYS.VIEWS for the view in question) and you must manually provide QGIS with one or more columns that identify a feature. The columns can be given by using Layer ► Add Layer ► Add SAP HANA Spatial Layer and then selecting the columns in the Feature id column. For best performance, the Feature id value should be a single INTEGER column.