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

14.3.1. ラスタデータ

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

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

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

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

14.3.2. ベクタデータ

QGISで利用できる機能やツールの多くは、ベクタデータのソースに関係なく同じように動作します。ただし、フォーマット（GeoPackage、ESRIシェープファイル、MapInfoやMicroStationファイル形式、AutoCAD DXF、PostGIS、SpatiaLite、DB2、Oracle Spatial、MSSQL空間データベース、SAP HANA空間データベース、その他多数）の仕様が異なるため、QGISでは一部のプロパティの扱いが異なる場合があります。フォーマットのサポートは OGR Simple Feature Library によって提供されています。このセクションでは、この差異をどのように扱うかについて説明します。

注釈

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 インデックスファイル

An ESRI Shapefile format dataset can also include a file with a .prj suffix, which contains projection information. While it is very useful to have a projection file, it is not mandatory. A Shapefile format dataset can contain additional files. For further details, see the the ESRI technical specification.

GDAL 3.1 では圧縮されたESRIシェープファイル形式（ shz や shp.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. 最初の行は見出しです。ここには X 、 Y および ELEV というフィールドが含まれています。

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

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

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

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

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

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

  • 任意のジオメトリタイプの場合は、単一の列にジオメトリの 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で読み込めるようになるための方向性が得られるかもしれません。

注釈

PostgreSQLデータベースにもQGISのプロジェクトを保存できます。

主キー

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

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

ビュー

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

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

注釈

PostgreSQL外部テーブル

PostgreSQL外部テーブルはPostgreSQLプロバイダによって明示的にサポートされてはおらず、ビューのように扱われます。

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

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

  1. Make a PLAIN backup of the layer_style table

  2. Open the file within a text editor

  3. Change the line SET xmloption = content; into SET XML OPTION DOCUMENT;

  4. Save the file

  5. Use psql to restore the table in the new database

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

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

shp2pgsql や DBマネージャ の他にも、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 コマンドを使用したい場合には、以下の環境変数を設定します（ nix と osx では利用可能）:

export PG_USE_COPY=YES

shp2pgsl は空間インデックスを作成しますが、 ogr2ogr では空間インデックスを作成しません。インポート後に追加のステップとして、通常の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インデックスを作成しています:

gsherman@madison:~/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
gsherman@madison:~/current$

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

Many GIS packages don't wrap vector maps with a geographic reference system (lat/lon) crossing the 180 degrees longitude line (https://postgis.net/docs/ST_Shift_Longitude.html). As result, if we open such a map in QGIS, we could see two widely separated locations, that should appear near each other. In 図 14.26, the tiny point on the far left of the map canvas (Chatham Islands) should be within the grid, to the right of the New Zealand main islands.

../../../_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空間レイヤ

このセクションでは、QGISがSAP HANAのレイヤにアクセスする方法について、いくつかの詳細を説明します。ほとんどの場合、QGISは単純にロード可能なデータベーステーブルのリストをユーザーに提供し、要求に応じてテーブルを読み込むだけです。しかし、SAP HANAのテーブルまたはビューをQGISに読み込むことができない場合には、以下の情報が参考となり、根本的な原因を理解し問題解決の助けとなるでしょう。

地物の識別

QGISの地物編集機能の全てを利用したい場合には、QGISがレイヤ内の各地物を明確に識別できる必要があります。内部的には、QGISは地物の識別に64ビットの符号付き整数を使用します。負の値の範囲は特別な目的のために予約されています。

従って、QGISの地物編集機能を完全にサポートするためには、SAP HANAプロバイダには64ビットの正の整数にマッピングできるユニークキーが必要です。もしもこのようなマッピングを作成できない場合には、地物を表示することはできますが、編集できない可能性があります。

テーブルの追加

レイヤとしてテーブルを追加する際に、SAP HANAプロバイダはテーブルの主キーを使用して、主キーをユニークな地物IDにマッピングします。 従って、地物編集機能を完全にサポートするためには、テーブルの定義に主キーが必要です。

SAP HANAプロバイダはマルチカラムの主キーをサポートしていますが、ベストな性能を得たい場合には、主キーは INTEGER 型の単一カラムとしてください。

ビューの追加

レイヤとしてビューを追加する際に、SAP HANAプロバイダは地物を一義的に特定するカラムを自動的に特定することはありません。さらに、一部のビューは読み取り専用で、編集できません。

地物編集機能を完全にサポートするためには、ビューは更新可能である必要があり（システムビュー SYS.VIEWS において、問題となっているビューのカラムの IS_READ_ONLY を確認してください）、地物を識別するための一つ以上のカラムをQGISで手動で指定する必要があります。このカラムは、 レイヤ ► レイヤを追加 ► SAP HANA空間レイヤを追加 を使用して、 地物ID カラムで選択することで指定できます。ベストな性能を得たい場合には、 地物ID の値は単一の INTEGER 型のカラムとしてください。