15.3. データ形式とフィールドを探究する

15.3.1. ラスタデータ 

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

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

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

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

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

注釈

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

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

15.3.2.1. GeoPackage 

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

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

ベクタ 地物
画像のタイルマトリックスセット や ラスタ マップ
属性データ（非空間データ）
拡張情報

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

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

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

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

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

.shp ファイルは地物のジオメトリを持ちます。
.dbf ファイルはdBase形式で属性を保持します。
.shx インデックスファイル

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

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

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

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

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

ESRIシェープファイル形式のデータセットを読み込む（ブラウザパネル参照）
凡例内のレイヤ名をダブルクリックするか、右クリックしてコンテキストメニューからプロパティ... を選択し、レイヤプロパティダイアログを開く
ソースタブで、空間インデックスの作成ボタンを押す

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

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

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

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

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

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

ファイルにはフィールド名を区切ったヘッダ行が必要です。これはデータの最初の行（理想的にはテキストファイルの最初の行）でなければなりません。
ジオメトリを有効にする場合には、ファイルにはジオメトリを定義するフィールドが含まれている必要があります。これらのフィールドには任意の名前を付けることができます。
（ジオメトリが座標で定義されている場合は）XとYの座標フィールドは数値で指定する必要があります。座標系は重要ではありません。
文字列以外の列を持つCSVファイルがある場合、付随するCSVTファイルを持つことができます（ CSVTファイルを使用したフィールドの書式制御のセクションを参照してください）。

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

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

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

このテキストファイル例では、 ; （セミコロン）を区切り文字として使用しています（フィールドの区切りには任意の文字を使用可能です）。
最初の行は見出しです。ここには X 、 Y および ELEV というフィールドが含まれています。
テキストフィールドを区切るための引用符（ " ）は使われていません。
X座標は X フィールドに含まれています
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ファイルを読み込む際GDALドライバは、別の指定がない限り、全てのフィールドを文字列（テキスト）と仮定します。CSVTファイルを作成することで、さまざまな列のデータ型をGDAL（そしてQGIS）に伝えることができます。

タイプ	名前	例
整数値	Integer	4
ブール値	Integer(Boolean)	true
小数点付き数値	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
CoordX	CoordX	8.8249
CoordY	CoordY	47.2274
Point(X)	Point(X)	8.8249
Point(Y)	Point(Y)	47.2274
WKT	WKT	POINT(15 20)

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

"Integer","Real","String"

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

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

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

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

ちなみに

フィールド型を検知する

CSVTファイルを使用してデータ型を伝える代わりに、QGISはフィールド型を自動的に検出し、想定されるフィールド型を変更する可能性を提供します。

15.3.2.4. PostGISレイヤ 

PostGISレイヤはPostgreSQLデータベースに保存されます。PostGISの利点は、空間インデックス、フィルタリング、クエリする能力です。PostGISを使用すると、selectやidentifyなどのベクタ関数は、QGISのGDALレイヤを使用した場合よりも正確に動作します。

ちなみに

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 に設定する必要があります。

layer_style テーブルのPLAINバックアップを作ります
そのファイルをテキストエディタで開きます
SET xmloption = context; の行を SET XML OPTION DOCUMENT; に変えます
ファイルを保存します
psqlを使ってテーブルを新しいデータベースにリストアします

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

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

PostgreSQLのデータ型のサポート 

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

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

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

DBマネージャ 

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

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 を使用してインポートします。

GDALはPostGISをサポートするためにPostgreSQLと一緒にビルドされなければならないことに注意してください。(|nix|で)入力することでこれを確認できます:

ogrinfo --formats | grep -i post

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

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$

15.3.2.6. SpatiaLiteレイヤ 

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

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

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

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

15.3.2.7. 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 拡張子が付きます。

15.3.2.8. 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 型のカラムとしてください。

15.3.3. 経度 180° をまたぐレイヤ 

多くのGISパッケージは、地理参照系（緯度経度）が180度の経線を越えるレイヤをラップしません。その結果、このようなレイヤをQGISで開くと、近くに表示されるはずの2つの場所が大きく離れて表示されることがあります。図 15.27 では、マップキャンバスの左端にある小さな点（チャタム諸島）は、ニュージーランド本島の右側のグリッド内にあるはずです。

../../../_images/vectorNotWrapping.png — 図 15.27 180° 経線をまたぐ緯度経度による地図

15.3.3.1. PostGISで解決する 

回避策として、PostGIS と ST_ShiftLongitude 関数を使用して経度値を変換する方法があります。この関数は、ジオメトリ内のすべての地物のすべてのコンポーネントのすべての点/頂点を読み取り、その経度座標を -180...0°から180...360°に、そしてその逆にシフトします。この関数は対称であるため、結果は-180...180°のデータを0...360°で表現し、0...360°のデータを-180...180°で表現します。

../../../_images/vectorWrapping.png — 図 15.28 **ST_ShiftLongitude** 関数を適用した経度180°越え

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

PostGISのコマンドラインインターフェイスを使って、以下のコマンドを実行します：

-- In this example, "TABLE" is the actual name of your PostGIS table
update TABLE set geom=ST_ShiftLongitude(geom);

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