OGR SQL 方言
GDALDataset は GDALDataset::ExecuteSQL() メソッドを使ってデータソースに対してコマンドを実行することができます. 理論的にはどんな種類のコマンドでもこの方法で処理できますが, 実際にはこのメカニズムはアプリケーションに対して SQL SELECT の機能の一部を提供するために使用されます. このページでは OGR に実装された一般的な SQL 実装と, ドライバー固有の SQL サポートに関する問題について説明します.
OGRSQL 方言は, GDALDataset::ExecuteSQL() の方言パラメータとして渡される OGRSQL 文字列, または ogrinfo または ogr2ogr ユーティリティの -dialect オプションスイッチでリクエストすることができます.
代わりの方言である SQLite 方言は, OGRSQL 方言の代わりに使用することができます. 詳細については SQL SQLite方言 ページを参照してください.
OGRLayer クラスは OGRLayer::SetAttributeFilter() メソッドを使用して返される地物に属性クエリフィルタを適用することもサポートしています. 属性フィルタの構文は OGR SQL SELECT 文の WHERE 句と同じです. したがって, WHERE 句に関するすべてのことは SetAttributeFilter() メソッドのコンテキストで適用されます.
SELECT
SELECT ステートメントは, レイヤーの地物 (RDBMS のテーブル行に類似) を取得するために使用されます. クエリの結果は地物の一時的なレイヤーとして表されます. データソースのレイヤーは RDBMS のテーブルに類似し, 地物の属性は列値に類似しています. OGR SQL SELECT ステートメントの最も単純な形式は次のようになります:
SELECT * FROM polylayer
この場合, "polylayer" という名前のレイヤーからすべての地物が取得され, それらの地物のすべての属性が返されます. これは基本的にレイヤーに直接アクセスするのと同等です. この例では, "*" はレイヤーから取得するフィールドのリストで, "*" はすべてのフィールドを取得することを意味します.
この少し洗練された形式は, レイヤーからすべての地物を取得しますが, スキーマにはジオメトリ列と EAS_ID および PROP_VALUE 属性のみが含まれます. OGR SQL 方言では, ジオメトリ列は常に結果に含まれるため, SQL ステートメントに表示する必要はありません.
SELECT eas_id, prop_value FROM polylayer
WHERE 句で取得する地物を制限し, 結果をソートするより野心的な SELECT は次のようになります:
SELECT * from polylayer WHERE prop_value > 220000.0 ORDER BY prop_value DESC
この SELECT ステートメントは, ジオメトリと eas_id 属性の異なる値の数を含む 1 つの属性 ("count_eas_id" のような名前) を持つ 1 つの地物のみを生成します.
SELECT COUNT(DISTINCT eas_id) FROM polylayer
一般的な構文
SELECT ステートメントの一般的な構文は次のようになります:
SELECT [fields] FROM layer_name [JOIN ...] [WHERE ...] [ORDER BY ...] [LIMIT ...] [OFFSET ...]
リスト演算子
フィールドリストは, 出力地物にソースレイヤーから持ち込まれるフィールドのカンマ区切りリストです. フィールドリストに表示される順序で出力地物に表示されるため, フィールドリストを使用してフィールドの順序を変更することができます. 特殊文字 * は "すべてのフィールド" を意味します. * EXCLUDE ([fields]) 構文を使用して, 括弧内にリストされていないすべてのフィールドを選択することができます.
フィールドリストの特殊な形式は, DISTINCT キーワードを使用します. これは, 指定された属性のすべての異なる値のリストを返します. DISTINCT キーワードが使用されると, フィールドリストには 1 つの属性のみが表示されます. DISTINCT キーワードは, どの種類のフィールドに対しても使用できます. 現在, OGR SQL では文字列値に対する DISTINCT テストは大文字小文字を区別しません. DISTINCT キーワードを使用した SELECT の結果は, 1 つの列 (操作されたフィールドと同じ名前) を持つレイヤーであり, 異なる値ごとに 1 つの地物があります. ジオメトリは破棄されます. 異なる値はメモリ内で組み立てられるため, 大量のメモリが使用される可能性があります.
SELECT DISTINCT areacode FROM polylayer
列に適用できるいくつかの集計演算子もあります. 1 つのフィールドに集計演算子が適用されると, すべてのフィールドに集計演算子が適用される必要があります. 集計演算子は次のとおりです:
COUNT: インスタンスの数
AVG: 数値の平均:
SUM: 数値の合計
MIN: レキシカルまたは数値の最小値
MAX: レキシカルまたは数値の最大値
STDDEV_POP: (GDAL >= 3.10) 数値 母集団標準偏差. Date/DateTime/Time フィールドに適用されると, 秒単位の値が返されます.
STDDEV_SAMP: (GDAL >= 3.10) 数値 標本標準偏差. Date/DateTime/Time フィールドに適用されると, 秒単位の値が返されます.
この例では, 地積の物件価値に関するさまざまな集計情報が生成されます:
SELECT MIN(prop_value), MAX(prop_value), AVG(prop_value), SUM(prop_value),
COUNT(prop_value), STDDEV_POP(prop_value) FROM polylayer WHERE prov_name = 'Ontario'
COUNT() 演算子を DISTINCT SELECT に適用して, 異なる値の数を取得することも可能です. たとえば:
SELECT COUNT(DISTINCT areacode) FROM polylayer
特別な場合として, COUNT() 演算子にフィールド名の代わりに "*" 引数を指定することができます. これはすべてのレコードをカウントするための短い形式です.
SELECT COUNT(*) FROM polylayer
フィールド名はテーブル名で接頭辞を付けることもできますが, これは結合を行う場合にのみ本当に意味があります. JOIN セクションでさらに説明されています.
フィールド定義は算術演算および関数演算子を使用した複雑な式にすることもできます. ただし, DISTINCT キーワードや MIN, MAX, AVG, SUM などの集計演算子は式フィールドに適用できません. ブール値の結果となる式 (比較, 論理演算子) も使用できます.
SELECT cost+tax from invoice
or
SELECT CONCAT(owner_first_name,' ',owner_last_name) from properties
関数
SUBSTR 関数は文字列から部分文字列を抽出するために使用できます. 構文は次のようになります: SUBSTR(string_expr, start_offset [, length]). string_expr の start_offset から始まる部分文字列を抽出します (1 が string_expr の最初の文字, 2 が 2 番目の文字, など...). start_offset が負の値の場合, 部分文字列は文字列の末尾から抽出されます (-1 が文字列の最後の文字, -2 が最後の文字の前の文字, ...). length が指定されている場合, 文字列から最大 length 文字が抽出されます. それ以外の場合, 文字列の残りが抽出されます.
注意: 現時点では, 文字はバイトと同等と見なされており, UTF-8 のようなマルチバイトエンコーディングには適していないかもしれません.
SELECT SUBSTR('abcdef',1,2) FROM xxx --> 'ab'
SELECT SUBSTR('abcdef',4) FROM xxx --> 'def'
SELECT SUBSTR('abcdef',-2) FROM xxx --> 'ef'
hstore_get_value() 関数は, 'key=>value,other_key=>other_value,...' のようにフォーマットされた HSTORE 文字列からキーに関連付けられた値を抽出するために使用できます.
SELECT hstore_get_value('a => b, "key with space"=> "value with space"', 'key with space') FROM xxx --> 'value with space'
フィールド名別名の使用
OGR SQL は, 以下の例に示すように, AS キーワードを使用して SQL92 仕様に従ってフィールドの名前を変更することをサポートしています:
SELECT *, OGR_STYLE AS STYLE FROM polylayer
フィールド名別名は, 列仕様の最後の操作として使用できます. したがって, 演算子内でフィールドの名前を変更することはできませんが, 次の 2 つのように列式全体の名前を変更することができます:
SELECT COUNT(areacode) AS "count" FROM polylayer
SELECT dollars*100.0 AS cents FROM polylayer
フィールドの型を変更する
OGR SQL は, 以下の例に示すように, SQL92 に準拠した CAST 演算子を使用して列の型を変更することをサポートしています:
SELECT *, CAST(OGR_STYLE AS character(255)) FROM rivers
現在, 次のターゲット型へのキャストがサポートされています:
boolean
character(フィールド長). デフォルトでは, フィールド長=1.
float(フィールド長)
numeric(フィールド長, フィールド精度)
smallint(フィールド長) : 16 ビット符号付き整数
integer(フィールド長)
bigint(フィールド長), 64 ビット整数, SQL92 の拡張
date(フィールド長)
time(フィールド長)
timestamp(フィールド長)
geometry, geometry(ジオメトリタイプ), geometry(ジオメトリタイプ,epsg_code)
フィールド長と/またはフィールド精度を指定することは任意です. character() の幅として可変幅を示すために, 幅としてゼロの明示的な値を使用できます. 'integer list', 'double list' および 'string list' OGR データ型への変換はサポートされていません. これは SQL92 仕様に準拠していません.
CAST 演算子は WHERE 句を含む式のどこにでも適用できますが, 出力フィールドのフォーマットの詳細な制御は, CAST 演算子がフィールド定義リストのフィールドで最も外側の演算子である場合にのみサポートされます. 他のコンテキストでは, 数値, 文字列および日付データ型間の変換には依然として有用です.
WKT 文字列をジオメトリにキャストすることが許可されています. geometry_type は POINT[Z], LINESTRING[Z], POLYGON[Z], MULTIPOINT[Z], MULTILINESTRING[Z], MULTIPOLYGON[Z], GEOMETRYCOLLECTION[Z] または GEOMETRY[Z] にすることができます.
文字列リテラルと識別子の引用
文字列リテラルと識別子の引用に関しては, 厳密な SQL92 ルールが適用されます.
文字列リテラル (定数) はシングルクォート文字で囲む必要があります. 例: WHERE a_field = 'a_value'
識別子 (列名およびテーブル名) は特殊文字を含まないか SQL 予約キーワードでない場合は引用符なしで使用できます. それ以外の場合は, ダブルクォート文字で囲む必要があります. 例: WHERE "from" = 5.
WHERE
WHERE 句の引数は, ソースレイヤーからレコードを選択するために使用される論理式です. WHERE 文内での使用に加えて, WHERE 句の処理は, OGRLayer::SetAttributeFilter() を介した通常のレイヤーの OGR 属性クエリにも使用されます.
SELECT ステートメントのフィールド選択句の式で使用できる算術演算子およびその他の関数演算子に加えて, WHERE コンテキストでは論理演算子も使用でき, 式の評価値は論理値 (true または false) である必要があります.
使用可能な論理演算子は =, !=, <>, <, >, <=, >=, LIKE および ILIKE, BETWEEN および IN です. ほとんどの演算子は自明ですが, != は <> と同じであり, 文字列の等価性は大文字小文字を区別しませんが, <, >, <= および >= 演算子は大文字小文字を区別します.
GDAL 3.1 以降, LIKE は大文字小文字を区別し, ILIKE は大文字小文字を区別しません. 以前のバージョンでは, LIKE も大文字小文字を区別しませんでした. GDAL 3.1 で以前の動作が必要な場合は, OGR_SQL_LIKE_AS_ILIKE を YES に設定できます.
GDAL 3.9 以降, OLCStringsAsUTF8 機能を宣言しているレイヤー (つまり, String 型のフィールドの内容が UTF-8 でエンコードされている) では, UTF-8 文字が LIKE および ILIKE 演算子によって考慮されます. ILIKE の大文字小文字を区別しない比較の場合, これは ASCII, Latin-1 Supplement, Latin Extended-A, Latin Extended-B, Greek and Coptic および Cyrillic Unicode カテゴリに制限されます.
LIKE および ILIKE 演算子の値引数は, 値文字列が一致するパターンです. このパターンでは, パーセント (%) は任意の文字数に一致し, アンダースコア ( _ ) は任意の 1 文字に一致します. ESCAPE escape_char 可能なエスケープ文字句を追加することで, パーセントまたはアンダースコア文字をエスケープ文字で先行させることで通常の文字として検索できます.
String Pattern Matches?
------ ------- --------
Alberta ALB% Yes
Alberta _lberta Yes
St. Alberta _lberta No
St. Alberta %lberta Yes
Robarts St. %Robarts% Yes
12345 123%45 Yes
123.45 12?45 No
N0N 1P0 %N0N% Yes
L4C 5E2 %N0N% No
IN は, 値のリストを引数として受け取り, 属性値が提供されたセットに属しているかどうかをテストします.
Value Value Set Matches?
------ ------- --------
321 IN (456,123) No
'Ontario' IN ('Ontario','BC') Yes
'Ont' IN ('Ontario','BC') No
1 IN (0,2,4,6) No
BETWEEN 演算子の構文は "field_name BETWEEN value1 AND value2" であり, "field_name >= value1 AND field_name <= value2" と等価です.
上記のバイナリ演算子に加えて, フィールドが null かどうかをテストするための追加の演算子があります. これらは IS NULL および IS NOT NULL 演算子です.
基本的なフィールドテストは, AND, OR および単項論理 NOT を含む論理演算子を使用して, より複雑な述語に組み合わせることができます. 優先順位を明確にするために, サブ式を括弧で囲む必要があります. いくつかのより複雑な述語は次のとおりです:
SELECT * FROM poly WHERE (prop_value >= 100000) AND (prop_value < 200000)
SELECT * FROM poly WHERE NOT (area_code LIKE 'N0N%')
SELECT * FROM poly WHERE (prop_value IS NOT NULL) AND (prop_value < 100000)
WHERE 制限
フィールドはすべて主テーブル (FROM 句にリストされているテーブル) から取得する必要があります.
<,>,<=および>=を除くすべての文字列比較は大文字小文字を区別しません.
ORDER BY
ORDER BY 句は, 返される地物を 1 つまたは複数のフィールドで昇順または降順に並べ替えるために使用されます. ASC または DESC キーワードが提供されていない場合, 昇順 (増加) 順序がデフォルトです. 例:
SELECT * FROM property WHERE class_code = 7 ORDER BY prop_value DESC
SELECT * FROM property ORDER BY prop_value
SELECT * FROM property ORDER BY prop_value ASC
SELECT DISTINCT zip_code FROM property ORDER BY zip_code
SELECT * FROM property ORDER BY prop_value ASC, another_field DESC
ORDER BY 句は, 地物セットを 2 回通過させます. 1 つ目は, 地物 ID に対応するフィールド値のインメモリテーブルを構築するためのものであり, 2 つ目は, ソートされた順序で地物 ID で地物を取得するためのものです. 地物 ID で効率的にランダムに地物を読み取れない形式では, これは非常に高価な操作になる可能性があります.
文字列フィールド値のソートは, 他の多くの OGR SQL の部分とは異なり, 大文字小文字を区別します.
LIMIT および OFFSET
GDAL 2.2 以降, LIMIT 句を使用して返される地物の数を制限することができます. 例:
SELECT * FROM poly LIMIT 5
OFFSET 句を使用して, 結果セットの最初の地物をスキップすることができます. OFFSET の後の値はスキップされる地物の数です. たとえば, 結果セットから最初の 3 つの地物をスキップするには:
SELECT * FROM poly OFFSET 3
両方の句を組み合わせることができます:
SELECT * FROM poly LIMIT 5 OFFSET 3
JOINs
OGR SQL は, 1 対 1 の JOIN の制限された形式をサポートしています. これにより, 問い合わせられている主テーブルとそれと共有キーを持つ副テーブルの間でレコードを参照することができます. たとえば, 都市の位置のテーブルには, 国名を取得するための参照として使用できる nation_id 列が含まれているかもしれません. 結合されたクエリは次のようになります:
SELECT city.*, nation.name FROM city
LEFT JOIN nation ON city.nation_id = nation.id
このクエリは, 都市テーブルのすべてのフィールドと, nation テーブルから取得された国名を持つ追加の "nation.name" フィールドを持つテーブルになります. これは, nation テーブル内のレコードを参照して, "id" フィールドの値が city.nation_id フィールドと同じ値であるレコードを探します.
JOIN にはいくつかの追加の問題があります. 1 つは, フィールド名にテーブル修飾子の概念があることです. たとえば, city レイヤーの nation_id フィールドを示すために, nation_id ではなく city.nation_id を参照します. テーブル名修飾子は, フィールドリストおよび JOIN 句内の ON 句でのみ使用できます.
ワイルドカードもやや複雑です. 通常の * ワイルドカードを使用して, 主テーブル (city この場合) および副テーブル (nation この場合) のすべてのフィールドを選択できます. ただし, 主テーブルまたは副テーブルのフィールドのみを選択するには, アスタリスクの前にテーブル名を付けます.
クエリレイヤーのフィールド名は, フィールドリストでテーブル名が修飾子として指定されている場合, テーブル名で修飾されます. さらに, 以前のフィールドと競合する場合, フィールド名はテーブル名で修飾されます. たとえば, 次の選択は, city および nation テーブルの両方に nation_id および name フィールド名がある場合, name, nation_id, nation.nation_id および nation.name フィールドを持つ結果セットになる可能性があります.
SELECT * FROM city LEFT JOIN nation ON city.nation_id = nation.nation_id
一方, nation テーブルに continent_id フィールドがある場合でも, city テーブルにはない場合, そのフィールドは結果セットで修飾する必要はありません. ただし, 選択されたものが次のステートメントのように見える場合, すべての結果フィールドはテーブル名で修飾されます.
SELECT city.*, nation.* FROM city
LEFT JOIN nation ON city.nation_id = nation.nation_id
上記の例では, nation テーブルは city テーブルと同じデータソースにありました. ただし, OGR の JOIN サポートには, 異なるデータソース (異なる形式の可能性がある) のテーブルに対して JOIN する機能が含まれています. これは, 2 番目のテーブル名にデータソース名を修飾することで示されます. この場合, 2 番目のデータソースは通常の OGR セマンティクスを使用して開かれ, クエリ結果が不要になるまで 2 番目のテーブルにアクセスするために使用されます.
SELECT * FROM city
LEFT JOIN '/usr2/data/nation.dbf'.nation ON city.nation_id = nation.nation_id
非常に有用ではないかもしれませんが, 一部の SELECT ステートメントを簡素化するためにテーブルエイリアスを導入することも可能です. これは, 同じ名前のテーブルが異なるデータソースから使用されている状況を明確にするのにも役立ちます. たとえば, 実際のテーブル名が複雑な場合, 次のようなことをしたいかもしれません:
SELECT c.name, n.name FROM project_615_city c
LEFT JOIN '/usr2/data/project_615_nation.dbf'.project_615_nation n
ON c.nation_id = n.nation_id
1 つのクエリで複数の JOIN を行うことができます.
SELECT city.name, prov.name, nation.name FROM city
LEFT JOIN province ON city.prov_id = province.id
LEFT JOIN nation ON city.nation_id = nation.id
ON の後の式は通常, "{primary_table}.{field_name} = {secondary_table}.{field_name}" の形式であり, その順序です. 複数の比較演算子を含むより複雑なブール式を使用することも可能ですが, 以下の "JOIN 制限" セクションで言及されている制限があります. 特に, 複数の JOIN (3 つ以上のテーブル) の場合, JOIN で比較されるフィールドは, 主テーブル (FROM 後のテーブル) およびアクティブ JOIN のテーブルに属している必要があります.
JOIN 制限
JOIN は, 2 番目のテーブルが使用されているキー フィールドにインデックスが付いていない場合, 非常に高価な操作になる可能性があります.
JOIN フィールドは, 現時点では WHERE 句や ORDER BY 句で使用できません. JOIN は, 基本的にすべての主テーブルのサブセットが完了した後, および ORDER BY パスの後に評価されます.
JOIN フィールドは, 後の JOIN でキーとして使用できません. したがって, city の省 ID を使用して省レコードを検索し, 次に省 ID から国 ID を使用して国レコードを検索することはできません. これは望ましいことであり, 実装できる可能性がありますが, 現在はサポートされていません.
JOIN されたテーブルのデータソース名は, 現在のプロセスの作業ディレクトリに対して評価されます. 主データソースへのパスではありません.
これは, RDBMS の意味での真の LEFT または RIGHT JOIN ではありません. JOIN キーに対する 2 番目のレコードが存在するかどうかにかかわらず, 主レコードの 1 つだけが結果セットに返されます. 2 番目のレコードが見つからない場合, 2 番目の派生フィールドは NULL になります. 複数の一致する 2 番目のフィールドが見つかった場合, 最初のフィールドのみが使用されます.
UNION ALL
SQL エンジンは, UNION ALL で結合された複数の SELECT を処理できます. UNION ALL の効果は, 右の SELECT ステートメントによって返された行を左の SELECT ステートメントによって返された行に連結することです.
[(] SELECT field_list FROM first_layer [WHERE where_expr] [)]
UNION ALL [(] SELECT field_list FROM second_layer [WHERE where_expr] [)]
[UNION ALL [(] SELECT field_list FROM third_layer [WHERE where_expr] [)]]*
UNION ALL 制限
OGR における UNION ALL の処理は, SQL 標準と異なります. SQL 標準では, 各 SELECT の列が同一でない場合にも受け入れられます. その場合, 各 SELECT ステートメントのすべてのフィールドのスーパーセットを返します.
さらに, 制限があります: ORDER BY は各 SELECT に対してのみ指定でき, UNION の結果のレベルでは指定できません.
特殊フィールド
OGR SQL クエリプロセッサは, 地物の一部の属性を組み込みの特殊フィールドとして扱い, 他のフィールドと一緒に SQL ステートメントで使用できます. これらのフィールドは, それぞれ SELECT リスト, WHERE 句および ORDER BY 句に配置できます. 特殊フィールドはデフォルトでは結果に含まれませんが, SELECT リストに追加することで明示的に含めることができます. フィールド値にアクセスするとき, 特殊フィールドは, 同じ名前のデータソース内の他のフィールドよりも優先されます.
地物 ID (FID)
通常, 地物 ID は地物の特別なプロパティであり, 地物の属性として扱われません. 場合によっては, クエリや結果セットで地物 ID を通常のフィールドとして利用できると便利です. これを行うには, FID という名前を使用します. レイヤーに名前付きの FID 列がある場合 (OGRLayer::GetFIDColumn() != ""), この名前も使用できます.
フィールドワイルドカードの展開には地物 ID は含まれませんが, 次のような構文を使用して明示的に含めることができます:
SELECT FID, * FROM nation
ジオメトリ フィールド
OGR SQL 方言は, データソースのジオメトリ フィールドをデフォルトで結果セットに追加します. ユーザーはジオメトリを明示的に選択する必要はありませんが, それを行うことも可能です. ジオメトリが必要な唯一のフィールドの場合が一般的な使用ケースです. この場合, SQL ステートメントで使用するジオメトリ フィールドの名前は, OGRLayer::GetGeometryColumn() によって返される名前であり, ogrinfo 出力の "Geometry Column = ..." でもあります. メソッドが空の文字列を返す場合, 特別な名前 "_ogr_geometry_" を使用する必要があります. 名前はアンダースコアで始まり, SQL 構文では, ダブルクォートの間に現れる必要があります. さらに, コマンドラインインタプリタは, ダブルクォートをエスケープする必要がある場合があり, 最終的な SELECT ステートメントは次のようになります:
SELECT "_ogr_geometry_" FROM nation
OGR_GEOMETRY
一部のデータソース (MapInfo tab など) は, 同じレイヤー内で異なるタイプのジオメトリを処理できます. OGR_GEOMETRY 特殊フィールドは, OGRGeometry::getGeometryName() によって返されるジオメトリ タイプを表し, さまざまなタイプを区別するために使用できます. このフィールドを使用することで, ジオメトリの特定のタイプを次のように選択できます:
SELECT * FROM nation WHERE OGR_GEOMETRY='POINT' OR OGR_GEOMETRY='POLYGON'
OGR_GEOM_WKT
ジオメトリの Well Known Text 表現も特殊フィールドとして使用できます. ジオメトリの WKT を選択するには, OGR_GEOM_WKT を選択リストに含めることができます. たとえば:
SELECT OGR_GEOM_WKT, * FROM nation
OGR_GEOM_WKT と LIKE 演算子を WHERE 句で使用することで, OGR_GEOMETRY を使用するのと同様の効果を得ることができます:
SELECT OGR_GEOM_WKT, * FROM nation WHERE OGR_GEOM_WKT
LIKE 'POINT%' OR OGR_GEOM_WKT LIKE 'POLYGON%'
OGR_GEOM_AREA
OGR_GEOM_AREA 特殊フィールドは, OGRSurface::get_Area() メソッドによって計算された地物のジオメトリの面積を返します. OGRGeometryCollection および OGRMultiPolygon の場合, 値はそのメンバーの面積の合計です. 非サーフェス ジオメトリの場合, 返される面積は 0.0 です.
たとえば, 指定された面積より大きいポリゴン地物のみを選択するには:
SELECT * FROM nation WHERE OGR_GEOM_AREA > 10000000
OGR_STYLE
OGR_STYLE 特殊フィールドは, OGRFeature::GetStyleString() によって返される地物のスタイル文字列を表します. このフィールドと LIKE 演算子を使用して, クエリの結果をスタイルでフィルタリングすることができます. たとえば, 注釈地物を次のように選択できます:
SELECT * FROM nation WHERE OGR_STYLE LIKE 'LABEL%'
OGR_STYLE フィールド名を特殊フィールド名として使用して, 通常は他のフィールドまたは文字列リテラルをエイリアスすることで, OGRFeature::SetStyleString() 値を設定する別の方法として使用することができます.
SELECT *, 'BRUSH(fc:#01234567)' AS OGR_STYLE FROM source_layer
デフォルトでは, OGR_STYLE フィールドは通常のフィールドとして表示されます. これを避けたい場合, GDAL 3.10 以降では, フィールド仕様の最後に HIDDEN キーワードを追加することで非表示にすることができます.
SELECT * EXCLUDE(my_style_field), my_style_field AS OGR_STYLE HIDDEN FROM source_layer
CREATE INDEX
一部の OGR SQL ドライバーは, 属性インデックスの作成をサポートしています. 現在, これには Shapefile ドライバーが含まれています. インデックスは, fieldname = value の形式の非常に単純な属性クエリを加速します. これは JOIN 機能で使用されるものです. nation テーブルの nation_id フィールドに属性インデックスを作成するには, 次のようなコマンドを使用します:
CREATE INDEX ON nation USING nation_id
Index 制限
新しい地物がレイヤーに追加されたり削除されたりするときに, インデックスは動的に維持されません.
非常に長い文字列 (256 文字より長い?) は現在インデックス化できません.
インデックスを再作成するには, レイヤーのすべてのインデックスを削除してから, すべてのインデックスを再作成する必要があります.
インデックスは, 複雑なクエリでは使用されません. 現在, 加速されるのは単純な "field = value" クエリのみです.
DROP INDEX
OGR SQL DROP INDEX コマンドは, 特定のテーブルのすべてのインデックスを削除するか, 特定の列のインデックスのみを削除するために使用できます.
DROP INDEX ON nation USING nation_id
DROP INDEX ON nation
ALTER TABLE
次の OGR SQL ALTER TABLE コマンドを使用できます.
-"ALTER TABLE tablename ADD [COLUMN] columnname columntype" は, 新しいフィールドを追加します. レイヤーが OLCCreateField 機能を宣言している場合にサポートされます. -"ALTER TABLE tablename RENAME [COLUMN] oldcolumnname TO newcolumnname" は, 既存のフィールドの名前を変更します. レイヤーが OLCAlterFieldDefn 機能を宣言している場合にサポートされます. -"ALTER TABLE tablename ALTER [COLUMN] columnname TYPE columntype" は, 既存のフィールドのタイプを変更します. レイヤーが OLCAlterFieldDefn 機能を宣言している場合にサポートされます. -"ALTER TABLE tablename DROP [COLUMN] columnname" は, 既存のフィールドを削除します. レイヤーが OLCDeleteField 機能を宣言している場合にサポートされます.
columntype 値は, 上記で説明した CAST 演算子でサポートされているタイプの構文に従います.
ALTER TABLE nation ADD COLUMN myfield integer
ALTER TABLE nation RENAME COLUMN myfield TO myfield2
ALTER TABLE nation ALTER COLUMN myfield2 TYPE character(15)
ALTER TABLE nation DROP COLUMN myfield2
DROP TABLE
OGR SQL DROP TABLE コマンドは, テーブルを削除するために使用できます. これは, ODsCDeleteLayer 機能を宣言しているデータソースでのみサポートされます.
DROP TABLE nation