GeoJSONのファイル構造を読み解くための5つの見方

GeoJSONは、地図上の点、線、面などの位置情報をJSON形式で表すためのデータ形式です。拡張子が.geojsonや.jsonで渡されることが多く、現地調査、測量、設備管理、不動産確認、土木・建築の位置情報整理など、さまざまな場面で使われます。ただし、初めてGeoJSONファイルを開くと、type、features、geometry、coordinates、propertiesといった項目が並んでおり、どこを見れば地図上の形や属性を判断できるのか分かりにくい場合があります。

この記事では、「geojson 使い方」と検索している実務担当者に向けて、GeoJSONのファイル構造を読み解くための基本的な見方を5つに整理して解説します。専門的な仕様を暗記するのではなく、実務で受け取ったGeoJSONを確認し、内容を把握し、修正や活用につなげるための視点を中心に説明します。

目次

• 全体のtypeを見てファイルの骨格を把握する

• featuresを見て地物のまとまりを確認する

• geometryを見て点・線・面の種類を読み分ける

• coordinatesを見て座標の並びと形状を理解する

• propertiesを見て業務情報と地図形状を結び付ける

• GeoJSONを実務で扱うときの確認ポイント

• まとめ

全体のtypeを見てファイルの骨格を把握する

GeoJSONのファイル構造を読み解くとき、最初に見るべき項目は一番外側にあるtypeです。GeoJSONはJSON形式で書かれているため、波括弧で囲まれた階層構造を持ちます。その一番外側にあるtypeは、そのファイル全体が何を表しているのかを示す入口になります。

GeoJSONの標準的なオブジェクトは、大きく見るとGeometry、Feature、FeatureCollectionのいずれかとして扱われます。実務でよく見かけるGeoJSONでは、最上位のtypeにFeatureCollectionと書かれていることが多いです。FeatureCollectionは、0件以上のFeatureをまとめたデータという意味で考えると理解しやすくなります。たとえば、複数の境界線、複数の調査地点、複数の区域、複数の設備位置などを一つのファイルにまとめる場合、FeatureCollectionという形がよく使われます。

GeoJSONの一例を単純化すると、次のような構造になります。

`json { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.000000, 35.000000] }, "properties": { "name": "調査地点A" } } ] } `

この例では、一番外側のtypeがFeatureCollectionになっています。その内側にfeaturesがあり、featuresの中に個々のFeatureが入っています。さらにFeatureの中にgeometryとpropertiesがあります。geometryは地図上の形を表し、propertiesはその地物に紐づく情報を表します。

GeoJSONを読むときに重要なのは、最初からすべての項目を細かく理解しようとしないことです。まず、最上位のtypeを見て、このファイルが単独の形状なのか、属性付きの地物なのか、複数の地物の集まりなのかを把握します。FeatureCollectionであれば、ファイル内に複数の地物が入っている場合がありますが、条件によっては1件だけ、または0件ということもあります。Featureであれば、一つの地物を中心に構成されている可能性があります。Point、LineString、Polygonなどが最上位にある場合は、propertiesを持たない形状データとして渡されている可能性があります。

実務では、GeoJSONファイルを地図表示やシステム連携に使う前に、最上位のtypeを確認するだけで、後続の作業の見通しが立てやすくなります。たとえば、複数の現地確認地点を扱うはずなのにFeatureCollectionではなくPointだけになっている場合、データの出力条件が想定と違っているかもしれません。反対に、一つの区域だけを扱うつもりだったのにFeatureCollectionの中に多数のFeatureが含まれている場合、不要な地物が混ざっていないか確認する必要があります。

GeoJSONは、見た目にはただの文字列の集まりですが、階層構造を追うことで意味が見えてきます。最上位のtypeは、その階層を読むための地図のような役割を持っています。ファイルを開いたら、まず外側のtypeを確認し、その次にfeaturesやgeometryへ進むという順番を決めておくと、複雑なファイルでも迷いにくくなります。

また、GeoJSONでは大文字と小文字が意味を持ちます。FeatureCollection、Feature、Point、LineString、Polygonなどは決まった書き方として扱われるため、featurecollectionやfeatureのように表記が変わっていると、読み込み側の仕組みによっては正しく認識されないことがあります。実務でファイルを修正する場合は、項目名やtypeの値の表記を安易に変えないことが大切です。

最上位のtypeを見ることは、GeoJSONを読むうえで最も基本的な確認です。ここでファイルの骨格をつかめば、以降のfeatures、geometry、coordinates、propertiesの位置づけも理解しやすくなります。

featuresを見て地物のまとまりを確認する

最上位のtypeがFeatureCollectionである場合、その中にはfeaturesという配列があります。featuresは、GeoJSONファイルの中に含まれるFeatureの一覧です。Featureとは、地図上で意味を持つ対象を、形状と属性情報の組み合わせとして表したものです。調査地点、道路中心線、敷地境界、建物範囲、管理区域、設備位置など、点・線・面として表せる対象はGeoJSON上ではFeatureとして扱うことができます。

featuresは配列なので、角括弧の中にFeatureが並びます。配列という言葉に慣れていない場合は、複数の地物を順番に並べた箱と考えると分かりやすいです。一つ目のFeature、二つ目のFeature、三つ目のFeatureというように、同じような構造を持つデータが繰り返されます。ただし、featuresが空の配列で、対象地物が1件も入っていない状態もあり得ます。

たとえば、現地調査で3か所の確認地点を記録したGeoJSONであれば、featuresの中に3つのFeatureが入っていることが考えられます。境界線を複数区間に分けて記録したデータであれば、featuresの中に複数のLineStringのFeatureが入っているかもしれません。区域ごとに面を分けて管理している場合は、featuresの中に複数のPolygonのFeatureが含まれることもあります。

実務でGeoJSONを受け取ったときは、featuresの数を確認することが重要です。想定している地物数と実際のFeature数が大きく異なる場合、出力範囲や抽出条件に問題がある可能性があります。たとえば、10件の設備点を受け取る予定だったのにfeaturesが1件しかない場合、複数点が一つの形状にまとめられているのか、そもそも出力対象が不足しているのかを確認する必要があります。反対に、1つの敷地範囲だけを扱う予定だったのにfeaturesが数百件ある場合、周辺の不要な地物まで含まれている可能性があります。

featuresの中に入るFeatureは、基本的にtype、geometry、propertiesを持ちます。typeにはFeatureと書かれ、geometryには地図上の形、propertiesにはその地物に関する属性情報が入ります。geometryは形状がない場合にnullになることがあり、propertiesも属性がない場合にnullになることがありますが、実務で扱いやすくするには、地物の意味を判断できる属性を整理しておくことが望まれます。この3つをセットで見ると、一つの地物がどのような形で、どのような意味を持つのかを理解できます。

GeoJSONを読むときは、featuresの中にある各Featureが同じ種類の地物なのか、それとも異なる種類が混在しているのかも確認するとよいです。たとえば、調査地点の点データだけを扱うつもりであれば、すべてのFeatureのgeometry typeがPointになっていることが自然です。一方、現場全体を表すデータでは、点、線、面が混在することもあります。その場合は、propertiesの中に分類情報が入っているかどうかを確認すると、どのFeatureが何を表しているのか判断しやすくなります。

また、featuresが空の配列になっている場合は、GeoJSONとしての形はあるものの、中に地物が入っていない状態です。検索条件に一致する対象がなかった場合や、出力処理で地物が除外された場合などに起こります。地図上に何も表示されないときは、座標や表示範囲だけでなく、featuresの中身が空ではないかを確認することが大切です。

featuresを確認する視点を持つと、GeoJSONファイルを単なる文字列ではなく、地物の一覧として理解できるようになります。どのくらいの数の地物があり、それぞれがどのような構造を持ち、想定した対象が含まれているかを確認することが、実務でのGeoJSON活用の第一歩になります。

geometryを見て点・線・面の種類を読み分ける

featuresの中で次に重要なのがgeometryです。geometryは、地物の地図上の形を表す部分です。GeoJSONを地図に表示したときに、点として表示されるのか、線として表示されるのか、面として表示されるのかは、このgeometryのtypeによって決まります。

代表的なgeometry typeには、Point、LineString、Polygonがあります。Pointは1つの地点を表します。現地調査地点、設備位置、写真撮影位置、境界標の位置などを表すときに使われます。LineStringは複数の座標を順番につないだ線を表します。道路中心線、境界線、配管経路、調査ルートなどを表すときに使われます。Polygonは閉じた面を表します。敷地範囲、建物外形、区域、地番に関する範囲、管理対象エリアなどを表すときに使われます。

GeoJSONには、複数の点、複数の線、複数の面を一つのgeometryとして扱うための種類もあります。MultiPointは複数の点、MultiLineStringは複数の線、MultiPolygonは複数の面を表します。また、複数種類のgeometryをまとめるGeometryCollectionもあります。ただし、実務で構造を読み解くうえでは、まずPoint、LineString、Polygonの違いをしっかり押さえることが重要です。

Pointのgeometryは、coordinatesに一組の座標が入ります。地図上の一点を表すため、構造は比較的単純です。LineStringでは、coordinatesに複数の座標が順番に並びます。座標の順番によって線の流れが決まるため、始点と終点の向きが業務上意味を持つ場合は注意が必要です。Polygonでは、coordinatesに閉じた輪郭の座標列が入ります。面を表す外周や穴はLinearRingと呼ばれる閉じた座標列で表され、標準仕様では先頭と末尾の位置が同じ値である必要があります。

geometryを見るときは、地物の種類と業務上の意味が合っているかを確認します。たとえば、敷地範囲を扱うデータなのにgeometry typeがLineStringになっている場合、それは面ではなく境界線だけを表している可能性があります。地図上では敷地の外周のように見えても、Polygonでなければ面積計算や区域内外の判定にそのまま使えない場合があります。反対に、道路や配管の経路を表すはずのデータがPolygonになっている場合、線ではなく幅を持った範囲として扱われている可能性があります。

実務では、見た目だけで判断すると誤解が生じることがあります。地図表示上は線も面の外周も似て見えることがありますが、GeoJSONのgeometry typeを見ると、データとして線なのか面なのかを確認できます。特に、面積、延長、包含判定、交差判定などの処理を行う場合、geometry typeの違いは結果に大きく影響します。

また、同じFeatureCollectionの中に複数のgeometry typeが混ざっている場合もあります。現地調査の記録では、写真撮影位置をPointで持ち、調査ルートをLineStringで持ち、対象範囲をPolygonで持つような構成も考えられます。このような場合は、propertiesの中に地物種別を示す項目があるか確認し、点・線・面の意味を整理しておくことが重要です。

geometryは、GeoJSONの中で地図表示に直接関係する中心部分です。typeを見ることで形の種類を判断し、coordinatesを見ることで具体的な位置や形状を確認します。geometryを正しく読み分けられるようになると、GeoJSONが表している空間情報の意味をかなり具体的に理解できるようになります。

coordinatesを見て座標の並びと形状を理解する

GeoJSONの中で最も実務的な確認が必要になる部分がcoordinatesです。coordinatesには、地図上の位置を示す数値が入ります。Pointであれば一点の座標、LineStringであれば線を構成する複数の座標、Polygonであれば面の輪郭を構成する座標列が入ります。

GeoJSONを読むときに特に注意したいのは、座標の順番です。標準的なGeoJSONでは、座標は経度、緯度の順で並びます。日本語の実務では緯度、経度の順で話すことも多いため、ここで取り違えが起きやすくなります。たとえば、[139.000000, 35.000000]という座標があった場合、最初の139.000000が経度、次の35.000000が緯度として扱われます。

この順番を逆に解釈すると、地図上でまったく違う場所に表示されることがあります。日本国内の地点を扱っているはずなのに海外や海上に表示される場合、座標順序の取り違えを疑う必要があります。特に、表計算データや測量成果、写真位置情報などをGeoJSONへ変換する作業では、元データの列順とGeoJSONの座標順が一致しているかを必ず確認することが大切です。

Pointのcoordinatesは単純です。たとえば、ある調査地点を表す場合、coordinatesには一組の数値が入ります。高さを含める場合には、経度、緯度に続けて3つ目の値が入ることがあります。標準仕様では、この3つ目の値は高度として扱われる想定ですが、利用する地図ツールや業務システムがその値を表示や解析に使うとは限りません。高さが重要な業務では、3つ目の値の意味、単位、基準面、利用システム側の対応を別途確認する必要があります。

LineStringのcoordinatesでは、複数の座標が順番に並びます。座標列の順番は、線の形だけでなく、線の向きを表すことがあります。道路の起点から終点、調査ルートの進行方向、排水の流れ、施工順序など、向きに意味があるデータでは、座標の並び順が業務上の解釈に関わります。地図上で同じ線に見えても、座標の順番が逆であれば、始点と終点が入れ替わることになります。

Polygonのcoordinatesはさらに注意が必要です。Polygonでは、面の外周を表す座標列があり、標準仕様では最初の座標と最後の座標が同じである必要があります。これは、面を閉じるためです。外周が閉じていない場合、読み込み側で補正されて見えることがあっても、標準的なGeoJSONとしては適切ではなく、エラーや期待しない表示につながる可能性があります。面データを扱う場合は、座標列が閉じているかを確認することが重要です。

Polygonでは、外周だけでなく内側の穴を表す座標列を持つこともあります。たとえば、ある区域の中に除外範囲がある場合、外側の輪郭と内側の輪郭が別々の座標列として表現されます。この構造を知らずに見ると、coordinatesの階層が深く、どれが何を表しているのか分かりにくく感じます。しかし、外側の輪郭と内側の穴が配列として分かれていると考えると、構造を理解しやすくなります。

MultiPolygonになると、さらに複数のPolygonがまとまります。飛び地のある区域や、複数の離れた面を一つの地物として扱う場合に使われることがあります。この場合、coordinatesの角括弧が何重にもなり、見た目には複雑になります。読み解くときは、括弧の数に圧倒されるのではなく、複数の面、各面の外周、必要に応じて内側の穴という順番で階層を整理すると理解しやすくなります。

coordinatesを確認するときは、数値の桁や範囲にも注意が必要です。標準的なGeoJSONでは、座標参照系はWGS 84の経度・緯度で、単位は十進度として扱われます。そのため、日本国内の経度・緯度として自然な範囲に入っているかを確認します。数値が極端に大きい場合や、小数ではなく大きな整数になっている場合は、平面直角座標系など別の座標系の値が変換されずに入っている可能性があります。その場合は、標準的なGeoJSONとして扱う前に、受け渡し元の座標系と変換方法を確認する必要があります。

また、座標の小数桁が多すぎる場合や少なすぎる場合も、目的に応じて確認が必要です。小数桁が極端に少ないと、地図上の位置が粗くなります。反対に、小数桁が非常に多くても、元データの精度や測定方法がそれに見合っていなければ、見かけ上の細かさだけが増えている可能性があります。実務では、座標値の桁数だけで精度を判断せず、測定方法、変換方法、利用目的と合わせて確認することが大切です。

coordinatesは、GeoJSONの中で最も直接的に位置を表す部分です。座標の順番、階層、閉じ方、数値範囲、座標系を確認することで、地図表示のずれや形状の誤解を防ぎやすくなります。

propertiesを見て業務情報と地図形状を結び付ける

GeoJSONのpropertiesは、地図上の形に紐づく属性情報を入れる場所です。geometryが地図上の形を表すのに対し、propertiesはその形が何を意味するのかを説明します。たとえば、調査地点の名称、管理番号、種別、確認日、担当者、状態、備考、写真番号、区域名などがpropertiesに入ることがあります。

GeoJSONを実務で使う場合、geometryだけでは十分ではありません。地図上に点が表示されても、それが何の地点なのか分からなければ業務には使いにくくなります。線が表示されても、それが境界線なのか、通行経路なのか、設備ルートなのかが分からなければ判断に困ります。面が表示されても、対象区域なのか、除外区域なのか、確認済み範囲なのかが分からなければ、活用できる範囲が限られます。propertiesは、こうした意味を補うための重要な情報です。

propertiesは、キーと値の組み合わせで表されます。キーは項目名、値はその内容です。たとえば、nameというキーに調査地点Aという値を入れたり、statusというキーに確認済みという値を入れたりします。項目名は自由に決められることが多いため、業務ごとに異なる構成になりやすい部分でもあります。

propertiesを確認するときは、まずどのような項目が入っているかを見ます。地物を識別するための番号や名称があるか、分類に使える項目があるか、日付や状態などの管理情報があるかを確認します。もし地図上では複数の地物が見えているのに、propertiesに識別情報がない場合、後からどの地物が何を表すのか分からなくなるおそれがあります。

また、propertiesの項目名が実務で理解しやすいかも重要です。項目名が短すぎたり、作成者だけに分かる略称になっていたりすると、別の担当者が見たときに意味を読み取れない場合があります。システム連携の都合で短い項目名を使うことはありますが、その場合でも別途項目定義を整理しておくと、後工程での混乱を防げます。

propertiesには文字列、数値、真偽値、空の値などを入れることができます。ただし、同じ項目に入る値の型がFeatureごとにばらばらになると、集計や検索で問題が起きることがあります。たとえば、あるFeatureでは管理番号が数値で入り、別のFeatureでは文字列で入っている場合、並べ替えや照合の結果が想定と異なることがあります。日付についても、表記形式が統一されていないと、期間検索や並べ替えが難しくなります。

実務でよくある課題は、geometryとpropertiesの対応がずれることです。地図上の位置は正しく見えていても、属性情報が別の地物のものになっていると、判断を誤る原因になります。たとえば、ある設備点に別の設備番号が紐づいていたり、ある区域に別の地番や管理名が入っていたりすると、現地確認や資料作成で大きな混乱につながります。GeoJSONを受け取ったら、代表的な数件について地図上の位置とpropertiesの内容を照合することが大切です。

propertiesには、すべての情報を詰め込めばよいというわけではありません。GeoJSONは地図表示や位置情報の受け渡しに向いた形式ですが、大量の文章、詳細な履歴、添付資料そのものを入れる用途には向かない場合があります。実務では、GeoJSON内には識別子や概要情報を入れ、詳細資料や写真などは別管理にして、共通の番号で紐づける方法も考えられます。

GeoJSONを業務で活用するうえで、propertiesは地図と台帳をつなぐ接点になります。地図上の形を見て終わりではなく、その形にどのような業務情報が紐づいているのかを確認することで、GeoJSONの価値は大きく高まります。

GeoJSONを実務で扱うときの確認ポイント

GeoJSONの基本構造を理解したら、次は実務で使う前の確認が重要になります。ファイルが開けることと、業務で安心して使えることは同じではありません。地図上に表示されたとしても、座標系、属性、形状、データ範囲、更新時点などに問題があれば、判断材料として使うには注意が必要です。

まず確認したいのは、対象範囲が合っているかです。GeoJSONファイルには、必要な範囲だけが入っている場合もあれば、周辺の参考情報や過去データが含まれている場合もあります。地図に重ねたときに、対象地周辺だけでなく広範囲に地物が散らばっている場合、出力範囲が広すぎる可能性があります。反対に、必要な地点や区域が欠けている場合は、抽出条件や変換処理に問題があるかもしれません。

次に、座標の位置ずれを確認します。GeoJSONではcoordinatesに座標値が入りますが、元データの座標系や変換方法が適切でないと、地図上でずれが発生します。見た目のずれが数メートルなのか、数十メートルなのか、まったく別の場所なのかによって原因は変わります。経度緯度の順序違い、測地系の違い、平面座標からの未変換、入力値の桁違いなど、複数の原因が考えられます。

形状の妥当性も確認が必要です。Polygonの外周が閉じているか、線が途中で不自然に飛んでいないか、面が自己交差していないか、点が重複していないかなどを確認します。特に、面データを面積計算や区域判定に使う場合、見た目には表示されていても形状として不正な場合があります。地図表示だけでは問題が見えにくいことがあるため、重要なデータでは形状チェックを行うことが望まれます。

propertiesの内容も、実務利用前に必ず確認します。項目名が揃っているか、必要な識別情報が入っているか、空欄が多すぎないか、日付や分類の表記が統一されているかを見ます。たとえば、同じ状態を表す値でも、確認済み、済、完了などが混在していると、絞り込みや集計で漏れが生じることがあります。GeoJSONを単に表示するだけでなく、業務管理に使う場合は、属性値の揺れを小さくすることが重要です。

ファイルサイズにも注意が必要です。座標点数が多いPolygonやLineStringが大量に含まれているGeoJSONは、表示や読み込みに時間がかかることがあります。現場共有や簡易確認が目的であれば、必要以上に細かい形状を含めないほうが扱いやすい場合があります。一方、境界確認や施工管理など細かさが必要な用途では、単純化しすぎると実務上の判断に支障が出ることがあります。用途に応じて、精細さと扱いやすさのバランスを考える必要があります。

文字コードや日本語項目の扱いも見落としやすい点です。propertiesに日本語の名称や備考が入っている場合、読み込み環境によって文字化けが起きることがあります。ファイルの保存形式や受け渡し方法が原因になることもあるため、受領後は実際に開いて日本語が正しく読めるか確認しておくと安心です。

また、GeoJSONを複数人で更新する場合は、どのファイルが最新なのかを管理することが大切です。ファイル名だけで判断していると、古いデータを使ってしまうことがあります。propertiesに作成日や更新日を入れる、ファイル名に管理しやすい日付を含める、受け渡し時に更新内容を明記するなど、運用面のルールを決めておくと混乱を減らせます。

GeoJSONは軽量で扱いやすい形式ですが、現地判断や資料作成に使う場合は、データの意味と品質を確認する姿勢が欠かせません。type、features、geometry、coordinates、propertiesという構造を読むだけでなく、実際の業務目的に対して十分な内容になっているかを確認することが重要です。

まとめ

GeoJSONのファイル構造を読み解くためには、まず全体のtypeを見て、ファイルの骨格を把握することが大切です。FeatureCollectionであれば、featuresの中に個々のFeatureが並びます。各Featureのgeometryを見ることで、点、線、面のどれを表しているのかが分かります。さらにcoordinatesを確認すれば、実際の位置や形状、座標の並び、座標系の確認につながります。propertiesを見れば、その地物が業務上何を意味するのかを読み取ることができます。

GeoJSONは、構造を知らないまま開くと難しく見えますが、見る順番を決めると理解しやすくなります。最初にtype、次にfeatures、次にgeometry、coordinates、propertiesという流れで確認すれば、地図上の形と業務情報を分けて整理できます。特に実務では、表示できるかどうかだけでなく、対象範囲、座標の位置ずれ、形状の妥当性、属性の整合性、更新時点を確認することが重要です。

「geojson 使い方」を調べている方の多くは、単に形式を知りたいだけでなく、受け取ったデータを地図で確認したい、現地情報と紐づけたい、台帳や調査結果と連携したいという目的を持っています。そのためには、GeoJSONを単なるファイル形式として見るのではなく、地図上の形状と業務情報を結び付けるデータとして理解することが必要です。

現地で取得した位置情報をGeoJSONとして活用する場合は、記録した地点、写真、メモ、属性情報をどのように整理するかが重要になります。スマートフォンや現場向けの位置情報記録ツールを使って現地情報を集める場合でも、出力されたGeoJSONのtype、geometry、coordinates、propertiesを確認し、業務目的に合う形で整理してから共有することが、後工程での誤解や手戻りを減らすことにつながります。