Skip to main content

説明

GeoJSON データは、単一の FeatureCollection ドキュメントとしてやり取りされ、ClickHouse ではこれを 3 つのカラム — idgeometryproperties — に対応付けます。各 Feature につき 1 組です。ドキュメントを読み込むと、Feature ごとに 1 行が生成されます。書き込むと、1 行ごとに 1 つの Feature が生成されます。

データの読み取り

FeatureCollection を読み込むと、地物 ごとに 1 行が生成され、次の固定スキーマになります。 各ジオメトリは ClickHouse の Geometry 型 (Variant) に格納されます。サポートされている GeoJSON ジオメトリ型 は PointLineStringMultiLineStringPolygonMultiPolygon です。これ以外の 2 つの GeoJSON ジオメトリ型、GeometryCollectionMultiPointGeometry 型では表現できません。これらを geometry カラムに読み込むと、デフォルトでは例外が発生しますが、代わりに NULL を挿入するように変更することもできます。詳しくは下の サポートされない ジオメトリ型 の処理 を参照してください。デフォルトでは、geometry カラムが NULL になるのは 地物 の geometry が明示的な JSON null の場合だけです。input_format_geojson_unsupported_geometry_handling = 'null' を指定すると、サポートされない ジオメトリ型 の場合も NULL になります。 ドキュメントの構造は検証されます。最上位の typeFeatureCollection でなければならず、features の各要素は typeFeature でなければなりません。デフォルトでは、coordinates は GeoJSON の shape の不変条件を満たす必要があります。つまり、LineString (および MultiLineString の各 line) は少なくとも 2 つの Point を持つ必要があり、Polygon の リング (および MultiPolygon の各 リング) は閉じていて、少なくとも 4 つの Point を持つ必要があります (Geometry validation を参照) 。不正なドキュメントは黙って読み込まれることはなく、拒否されます。 キーの順序は柔軟です。最上位の typefeatures 配列の前でも後でもよく、geometry object 内では coordinatestype の前でも後でもかまいません。 スキーマ推論では上記の固定スキーマが返されるため、DESCRIBESELECT ... FROM format(...) は table definition なしで動作します。 複数のジオメトリ型が含まれる、次の GeoJSON ファイル london.geojson を例にします。
ファイルに対してクエリを実行し、ジオメトリ型を確認できます。
Query
Response
ファイル拡張子 .geojson は自動的に検出されるため、フォーマット引数は省略できます。
Query
Geometry オブジェクトの基底型は、variantType を使って確認できます:
Query
Response
また、基になるデータは次のように抽出できます:
Query
Response
Geometry のサブカラムにアクセスすると、その行にその型の値が入っている場合はその値が返され、そうでない場合はその型のデフォルト値 — Point では (0,0)、配列ベースの型では [] — が返されます。どの型が設定されているかを判別するには、variantType(geometry) を使用します。 GeoJSON データをテーブルに取り込むこともできます。
Query
次に、地物タイプでクエリを実行します:
Query
Response
テーブル定義がなくても、GeoJSONデータのスキーマを推論できます。
Query
Response

サポートされていないジオメトリ型の処理

GeometryCollectionMultiPoint など、一部の有効な GeoJSON ジオメトリ型は、ClickHouse の Geometry 型では表現できません。そのようなジオメトリを geometry カラムに格納する必要がある場合の動作は、input_format_geojson_unsupported_geometry_handling 設定で制御できます。設定可能な値は次のとおりです。
  • 'throw' — 例外をスローする (デフォルト)
  • 'null'geometry カラムに NULL 値を挿入し、パースを続行する
この処理が適用されるのは、geometry カラムが読み取られる場合に限られます。geometry が要求された出力カラムに含まれていない場合 (たとえば SELECT id FROM ...) 、サポートされていないジオメトリであっても形式が正しいかどうかの検証は行われますが、この処理はトリガーされません。つまり、ジオメトリ値は実体化されないため、例外はスローされず、NULL も挿入されません。

制限事項

読み取り時には固定スキーマに収まる内容しか反映されないため、一部の GeoJSON 情報は保持されません。
  • 生成されるのは idgeometryproperties のみで、その他のドキュメント構造はカラムとして公開されません。
  • 位置の 3 番目の座標 (標高) とそれ以降の座標は破棄されるため、位置は [longitude, latitude] になります。
  • bbox と外部メンバー (トップレベルの namecrs、または Feature 内の追加メンバーなど) は無視されます。
  • 数値の id はテキストとして保存されるため、文字列と数値の区別は失われます。id が存在しない場合や null の場合は NULL になります。
  • GeometryCollectionMultiPoint は表現できません。詳しくは サポートされていないジオメトリ型の扱い を参照してください。

データの書き込み

結果セットを書き込むと、単一の GeoJSON FeatureCollection が生成され、各行が 1 つの Feature になります。 結果のカラムは、次のように各 Feature にマッピングされます。 geometry 型のカラムには、Geometry のバリアントまたは特定の geo 型を使用でき、それぞれ次の GeoJSON ジオメトリ型 に対応します。 Ring は GeoJSON の ジオメトリ型 ではありません。linear リングPolygon の構成要素であるため、Ring の値は単一リングの Polygon として書き込まれます。

上で作成した london テーブルを引き続き使用すると、通常の属性カラムをエクスポートした際に、idgeometry 以外のすべてのカラムがプロパティになります。
Query
Response
properties という名前の object 型カラムが 1 つだけある場合は、それが直接書き出されるため、GeoJSONファイルを読み込んでそのまま書き戻すと、元のドキュメントが再現されます (このファイルに対して推論されるカラムは idgeometryproperties です) :
Query
Response
数値の id カラムは、JSON の数値として記述されます (NULLNullable id は完全に省略されます) :
Query
Response
Ring は、単一リングの Polygon として表記します:
Query
Response

ファイルへの書き込み

INTO OUTFILEを使用して、クライアント側からGeoJSONファイルに書き出します。
Query
サーバーは、file テーブル関数を使って自らファイルに書き込めます (.geojson 拡張子によりフォーマットが自動的に自動選択されます) :
Query

制限事項

ClickHouse の geo types には座標参照系の情報がないため、出力では座標がすでに WGS84 の経度/緯度で、RFC 7946 で規定されている [longitude, latitude] の順序になっているものと見なされます。再投影や軸の入れ替えは行われないため、投影座標や (latitude, longitude) として格納されたデータは、構造上は有効でも仕様には準拠しない GeoJSON になります。
出力に反映されるのは、ClickHouse に格納されている内容のみです。
  • 読み取り時に失われた情報 — 位置の標高、bbox、外部メンバー、および id の文字列と数値の区別 — は復元できません。詳しくは 読み取りの制限事項 を参照してください。
  • 座標は、Float64 の値から、往復変換可能な最短表現で書き出されます。
  • JSON カラムから直接取得した properties オブジェクトは、JSON 型の canonical なキー順で出力されるため、入力時の順序と異なる場合があります。
ジオメトリは格納されているとおりに正確に書き出され、座標順序と 巻き方向 は保持されます。デフォルトでは、書き込み時に GeoJSON shape の妥当性が検証されます (Geometry validation を参照) 。そのため、1 点しか持たない LineString や閉じていない Polygon ring など、有効な GeoJSON shape ではないジオメトリは、書き出したドキュメントを再度読み込めるように拒否されます。代わりにそのようなジオメトリをそのまま出力し、構造上は有効でも仕様には準拠しない GeoJSON を生成するには、format_geojson_validate_geometry = 0 を設定してください。右手系ルール (巻き方向) の不変条件は、いずれの場合も強制されません。また、null と空の properties オブジェクトの違いは保持されます。

ジオメトリの検証

設定 format_geojson_validate_geometry は、このフォーマットで RFC 7946 のジオメトリ形状ルールを、読み書きの両方向で適用するかどうかを制御します。既定では有効です。 有効な場合、GeoJSON の形状ルールに違反するジオメトリは拒否されます。たとえば、点が 2 つ未満の LineString (または MultiLineString 内のライン) 、点が 4 つ未満の Polygon または MultiPolygon のリング、先頭と末尾の点が異なるリング (閉じていないリング) 、あるいは空の MultiLineStringPolygonMultiPolygon です。これらのルールは、そのようなドキュメントを読み取る場合にも、そのような ClickHouse の値を書き出す場合にも同様に適用されるため、書き出したドキュメントは常に再度読み込めます。 無効な場合、これらの形状ルールはどちらの方向でも適用されません。退化したジオメトリは、そのまま読み取られ、そのまま書き出されます。これにより、有効な GeoJSON ジオメトリではない ClickHouse のジオメトリ値でも、このフォーマットを通して往復できますが、その代わりに有効な GeoJSON ではないドキュメントが生成されます。 この検証は構造面のみを対象とします。確認するのは、点の数とリングが閉じているかどうかだけです。形状の幾何学的な正しさまでは検査しないため、構造的には有効でも幾何学的には退化しているジオメトリは、どちらの方向でも受け入れられます。たとえば、面積が 0 の polygon、自己交差するリング、または holes (内側のリング) が外側のリングの外にある polygon です。同様に、polygon のリングの 右手系ルール (巻き方向) も適用されることはありません。 1 つの検査はこの設定とは無関係です。有限でない座標 (NaNInf) は、JSON の数値として表現できないため、常に拒否されます。
最終更新日 2026年7月23日