GeoJSONをJSONに変換する方法：ジオメトリを削除してプロパティのみを抽出
GeoJSONの正体：なぜそのデータは多すぎることが多いのか
GeoJSONは単なるJSONですが、非常に特殊で、多くの場合かさばる構造を持っています。どのファイルも通常、データを`FeatureCollection`でラップしており、その中には`Feature`オブジェクトの配列が含まれています。各`Feature`は、`geometry`と`properties`という2つの主要な部分で構成されています。`geometry`ブロックは、座標配列やPoint、Polygonといった形状タイプ、そして数千行にも及ぶ複雑な座標リングなど、すべての空間データが格納される場所です。一方、`properties`ブロックこそが、あなたが通常関心を持つ部分、つまり各形状に結びついた名前、ID、人口、タイムスタンプといった実際の属性データです。 この構造は、データを「地図」を解さないシステムに渡す必要がある場合に問題となります。例えば、GISツールから米国の全4,200郡の境界線データセットをエクスポートしたとします。結果として得られるGeoJSONファイルは、各郡のポリゴンが数千の座標ペアで定義されているため、簡単に18MBにもなり得ます。もしあなたの目的が、レポートやAPIで郡名、FIPSコード、人口を使うことだけなら、95%もの無駄なデータを引きずっていることになります。そのジオメトリ情報は単なるノイズでしかありません。さらに悪いことに、一部のパーサーは地理空間キーを認識できないという理由で、ファイルを完全に拒否することさえあります。このような非空間的な用途では、ジオメトリを削除することはデータ損失ではなく、賢いデータ準備なのです。
GeoJSONとプレーンJSONの構造的な違い
変換について具体的に見ていきましょう。最初に手にするであろう、最小限のGeoJSON `Feature`は次のようになります。 { "type": "Feature", "geometry": { "type": "Point", "coordinates": [-87.6298, 41.8781] }, "properties": { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } } ジオメトリを削除した後の目標は、`properties`キーの内部にネストされた、クリーンでシンプルなJSONオブジェクトです。 { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } 入力が`FeatureCollection`（複数のフィーチャーを含むファイル）の場合、目標は各フィーチャーのプロパティオブジェクトだけを含む単一のJSON配列を生成することです。 [ { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" }, { "city": "Houston", "population": 2304580, "timezone": "America/Chicago" } ] これこそが、ほとんどのAPI、スプレッドシートのインポーター、データベースローダーが理解できるように作られている形式です。API呼び出しの失敗をデバッグしたことがある人なら、パーサーが`geometry`や`type`のような予期しないトップレベルキーで詰まってしまうイライラをよくご存知でしょう。最終的な結果は、ほぼすべてのツールで扱えるクリーンなJSON配列になります。重要な点が一つあります。もしフィーチャーの`properties`の値が`null`だったらどうでしょう？これは有効なGeoJSONです。優れたコンバーターなら、クラッシュしたり、最悪の場合、黙ってそのフィーチャーをスキップしたりせずに、空のオブジェクト`{}`を生成します。雑なコンバーターは、いつもこのテストに失敗します。
CocoConvertを使ったGeoJSONからJSONへの変換
手早く、コーディング不要の解決策として、/convert/geojson-to-jsonにあるCocoConvertのGeoJSONからJSONへのコンバーターは、まさにこの作業のために設計されています。プロセスはシンプルです。`.geojson`または`.json`ファイル（GeoJSONは`.json`拡張子をよく使うため、両方受け付けます）をアップロードし、オプションを選択して、不要な部分を削ぎ落とした結果をダウンロードするだけです。 このコンバーターは、デフォルトで容赦ありません。`features`配列を見つけ出し、すべてのフィーチャーから`properties`オブジェクトを取得し、それらをクリーンなJSON配列にまとめ上げます。`geometry`キー、`type`キー、そして`FeatureCollection`ラッパーはすべて置き去りにされます。もしファイルにコレクションではなく単一の`Feature`しか含まれていない場合、出力は配列ではなく単一のJSONオブジェクトになります。 CocoConvertは無料プランで最大50MBまでのファイルに対応しており、これは10,000フィーチャー未満のほとんどのデータセットには十分な容量です。しかし、州全体の道路網のような巨大なファイル（これは簡単に200MB以上になることがあります）を扱う場合は、次に紹介するコマンドラインツールを使う必要があります。プライバシーに関しては、コンバーターはサーバー上でファイルを処理しますが、セッション終了後にはデータを保存しません。これは、属性に個人識別子のような機密情報が含まれる場合に重要な詳細です。 デフォルトでは、ダウンロードされるファイルには`.json`拡張子が付きます。設定パネルを使えば、カスタムファイル名を指定したり、最小化された一行の出力ではなく、インデント付きで人間が読みやすい出力を得たりと、より細かな制御が可能です。
大容量ファイルや自動化のためのコマンドライン代替案
50MBを超えるファイルを扱ったり、スクリプトでこの変換を自動化したりする必要がある場合、コマンドラインがあなたの味方になります。主な武器は2つ、`jq`とPythonの組み込み`json`モジュールです。 純粋なJSON変換に関しては、速度とシンプルさで`jq`に勝るものはありません。 jq '[.features[].properties]' input.geojson > output.json このワンライナーは、ウェブツールとまったく同じことを行います。各フィーチャーを反復処理し、`properties`オブジェクトを抜き出し、その結果をJSON配列でラップします。`jq`は主要なOS（macOSなら`brew install jq`、Debian/Ubuntuなら`apt install jq`）に簡単にインストールでき、データをすべてメモリに読み込むのではなくストリーミング処理するため、ギガバイトサイズのファイルでも臆することなく処理できます。 フィーチャーの`id`が重要である場合（GeoJSONでは`properties`の内部ではなく、それと並列に存在します）、それをマージすることができます。 jq '[.features[] | {id: .id} + .properties]' input.geojson > output.json より複雑なロジックが必要な場合は、Pythonが答えです。 import json with open('input.geojson') as f: gj = json.load(f) result = [feature['properties'] for feature in gj['features']] with open('output.json', 'w') as f: json.dump(result, f, indent=2) この短いスクリプトを使えば、出力を書き込む前にフィーチャーをフィルタリングしたり、キーの名前を変更したり、奇妙なエッジケースを処理したりと、完全な制御が可能です。何より素晴らしいのは、`json`モジュールがPythonの標準ライブラリの一部であるため、追加で何もインストールする必要がないことです。 はっきり言って、私のおすすめはこうです。ファイルが1つだけで、コードに触らず30秒で結果が欲しいならCocoConvertを使いましょう。データパイプラインを自動化したり、何百ものファイルを処理したりする場合は、`jq`かPythonを使うべきです。
単純なコンバーターを壊すエッジケースへの対処法
実世界のGeoJSONは、仕様書にあるクリーンな例よりも散らかっていることがよくあります。ここでは、単純なコンバーターを壊す可能性のある、よくある落とし穴を紹介します。 **Nullジオメトリ:** `"geometry": null`を持つフィーチャーに頻繁に遭遇します。これらは完全に有効で、単に位置データが欠落しているレコードを表すことがよくあります。堅牢なコンバーターは、フィーチャー全体を破棄するのではなく、そのプロパティを抽出しなければなりません。先ほど紹介した`jq`やPythonの方法は、これを正しく処理します。 **ネストされたプロパティ:** `properties`オブジェクト自体が、`"properties": {"address": {"street": "Main St"}}`のようにネストされたJSONオブジェクトを含むことがあります。ジオメトリを削除しても、これらのネスト構造はフラット化されず、そのまま保持されます。もし（例えばCSV用に）完全にフラットな構造が必要な場合は、それは別途実行する必要がある別の変換作業です。 **一貫性のないキー:** コレクション内のあるフィーチャーには`"name"`キーがあるのに、他のフィーチャーにはない、ということはよくあります。結果として得られるJSON配列は、単に異なる形状のオブジェクトを持つことになります。これは有効なJSONですが、厳密に型付けされたシステムでは問題になる可能性があります。CocoConvertはそこにあるものを忠実に抽出します。スキーマを正規化しようとはしません。 **`GeometryCollection`:** 一部のファイルは`GeometryCollection`タイプを使用しており、これは標準の`FeatureCollection`とは異なる構造を持っています。CocoConvertを含む多くのツールは`FeatureCollection`を想定しているため、トップレベルで`GeometryCollection`に遭遇すると失敗する可能性があります。 **エンコーディングの問題:** これは古典的なGISデータの頭痛の種です。GeoJSONの仕様はUTF-8エンコーディングを厳格に義務付けています。しかし、古いソフトウェアからエクスポートされたファイルには、Latin-1やWindows-1252の文字が含まれていることがあります。これはパースエラーを引き起こします。変換を試みる前に、`iconv`のようなツールを使ってエンコーディングを上流で修正しなければなりません。
ジオメトリを保持すべき場合（と、別の変換方法）
ジオメトリの削除はデータのみのワークフローには最適ですが、時にはそれが絶対的に間違った選択であることもあります。空間データを保持しつつ、単に別の形式にしたい場合はたくさんあります。 もしLeafletやMapboxGLのようなウェブマッピングライブラリにデータを供給しているなら、ストップ。何も変換しないでください。これらのライブラリは両方ともGeoJSONをネイティブで消費するため、プレーンJSONに変換すると、地図を描画するために必要な座標そのものを削除してしまうことになります。 時には、カスタムチャート用に`{lat, lng, name}`オブジェクトのフラットな配列のように、座標は必要だけれども別の形にしたい、ということがあります。それはジオメトリの削除ではなく、再形成タスクです。`jq`はこの作業に最適です。 jq '[.features[] | {lat: .geometry.coordinates[1], lng: .geometry.coordinates[0], name: .properties.name}]' input.geojson > output.json ここで座標の順序に細心の注意を払ってください。GeoJSONは厳密に`[経度, 緯度]`、つまり(x, y)です。これは多くの人々やシステムが期待する順序とは逆です。これを間違えると、データが地球の反対側に表示されるという、笑えるけどイライラする結果になります。 もし目標がGeoJSONをTopoJSON、Shapefile、KMLといった他の地理空間フォーマットに変換することなら、別のツールが必要です。CocoConvertはこれらのジオメトリを保持する変換は行いません。そのためには、コマンドラインの強力なツール`ogr2ogr`（GDALの一部）や、優れたウェブツールであるMapshaperのような専用ツールを使うべきです。それらがその仕事に適したツールです。 /convert/geojson-to-jsonにある私たちのGeoJSONからJSONへのツールは、プロパティを抽出するという一つのタスクに特化しています。その一つのことを、うまくこなすのです。
下流工程で使う前に出力を検証する
ピカピカの新しいJSONファイルを下流のシステムに渡す前に、2分だけ時間を取って検証しましょう。この簡単な一手間が、後の数時間にわたるデバッグ地獄からあなたを救ってくれます。 テキストエディタでファイルを開いてみてください。トップレベルは配列（`[`で始まっている）ですか？各要素はオブジェクト（`{`で始まっている）ですか？そして重要な点として、`geometry`や`type`キーは見当たりませんか？見当たらないはずです。「coordinates」という文字列でさっと検索して、一致がゼロ件であるべきです。 次に、レコード数を確認します。入力のGeoJSONに847個のフィーチャーがあったなら、出力のJSON配列にも正確に847個のオブジェクトがなければなりません。数が一致しない場合、コンバーターがフィーチャーを脱落させた可能性があり、その原因は不正な入力か、nullの不適切な処理である可能性が高いです。 では、データ自体を抜き打ちでチェックしましょう。新しいJSONの最初、最後、そして中間のランダムなレコードのプロパティ値を、元のGeoJSONファイルと比較します。名前、ID、数値がすべて一致していれば、変換がクリーンに行われたと確信できます。 自動化されたパイプラインでは、JSONSchemaを使いましょう。Node.js用の`ajv`やPython用の`jsonschema`のようなツールを使えば、配列内のすべてのオブジェクトが期待するキーとデータ型を持っているかをプログラムで検証できます。これは、変化するデータに対して定期的に実行されるプロセスにとって不可欠です。 そして最後にもう一つ。データがデータベースに向かうのであれば、インポート後にテーブルに対して`COUNT`クエリを実行してください。行数が期待通りですか？この30秒のチェックこそが、変換からインポートまでの一連の流れが完璧に機能したことの最終確認となります。