GeoJSONは、地図上の点・線・面と、その対象に紐づく属性情報をまとめて扱うためのデータ形式です。現場調査、用地管理、施設管理、区域整理、地図連携などで使われることが多く、実務では「この座標列は何を表しているのか」「FeatureとPolygonの違いは何か」「閉じた面として正しく読めるのか」といった確認が欠かせません。この記事では、GeoJSONを初めて業務で扱う担当者でも理解しやすいように、FeatureとPolygonを実例ベースで5ステップに分けて解説します。
GeoJSONを理解する前に押さえる基本構造
GeoJSONは、地図上の情報をJSON形式で表現するためのデータ形式です。JSONは、文字列、数値、配列、オブジェクトを組み合わせて情報を表す形式で、GeoJSONではそこに地理空間情報の考え方が加わります。地理空間情報というと難しく聞こえますが、実務で見ると「この点はどこか」「この線はどこを通るか」「この区域はどの範囲か」を機械が読める形にしたものです。
GeoJSONでよく登場する単位には、FeatureCollection、Feature、geometry、propertiesがあります。FeatureCollectionは複数のFeatureをまとめる全体の入れ物です。たとえば、複数の敷地、複数の施設、複数の調査地点、複数の管理区域をひとつのファイルにまとめたい場合、全体はFeatureCollectionとして表現されます。その中に、ひとつひとつの対象物を表すFeatureが並びます。
Featureは、地図上に表示したい対象を表す基本単位です。ただし、Featureだけでは位置や形は決まりません。Featureの中にはgeometryという項目があり、そこに点、線、面などの形状情報が入ります。さらにpropertiesという項目には、名称、番号、分類、管理者、調査日、備考といった属性情報を入れます。つまり、GeoJSONでは「形」と「意味」を分けて管理し、それらをFeatureという単位でひとまとめにする考え方になっています。
たとえば、ある敷地をGeoJSONで表す場合、geometryには敷地境界の座標列が入り、propertiesには敷地名、地番、用途、調査日、確認状況などが入ります。地図に表示するときはgeometryを見て面を描画し、クリックしたときの情報表示や帳票化ではpropertiesを見て属性を表示する、という使い方ができます。
GeoJSONを読むときに最初につまずきやすいのは、座標列だけを見てしまい、Feature全体の意味を見落とすことです。座標列は確かに重要ですが、それが何を表す座標なのかはpropertiesやFeatureの単位を合わせて見ないと判断できません。反対に、属性情報だけが充実していても、geometryが間違っていれば地図上では正しい場所に表示されません。GeoJSONを実務で扱うときは、形状情報と属性情報の両方を同時に確認する意識が必要です。
GeoJSONのgeometryには、Point、LineString、Polygon、MultiPolygonなどの種類があります。Pointはひとつの地点、LineStringは連続した線、Polygonは閉じた面を表します。今回のテーマであるPolygonは、敷地、区画、区域、建物外形、調査範囲、管理範囲などを表す場面でよく使われます。面を扱うため、座標の順番、始点と終点の一致、内側の穴の表現など、点や線よりも確認すべき点が多くなります。
標準的なGeoJSONでは、座標は「経度、緯度」の順で記述します。日本語の会話では「緯度経度」と言うことが多いため、実務ではこの順番を取り違えるミスが起こりやすいです。たとえば、北緯35度、東経139度付近の地点であれば、GeoJSON上ではおおむね「139, 35」の順になります。これを逆にして「35, 139」と書くと、まったく別の場所を指すデータになってしまいます。Polygonでも同じで、すべての頂点座標についてこの順序が守られている必要があります。
GeoJSONはテキストとして読める形式なので、専用データ形式に比べて中身を確認しやすい利点があります。一方で、見た目が単なる文字列であるため、括弧の対応、カンマの位置、座標列の階層、属性名の表記ゆれなど、小さなミスでも読み込みエラーや表示ずれにつながります。業務で使う場合は、構造を理解したうえで、データ作成時と受け渡し時に確認することが重要です。
Featureは地物と属性をまとめる入れ物
GeoJSONにおけるFeatureは、地図上で扱うひとつの対象を表す単位です。地物という言葉が使われることもありますが、実務では「管理したい対象物」と考えると理解しやすいです。調査地点、道路区間、敷地、建物、農地、設備、境界区域など、地図上に置きたいものはFeatureとして表現できます。
Featureの役割は、geometryとpropertiesをひとつにまとめることです。geometryは対象の場所や形を示し、propertiesは対象の意味や説明を示します。この二つが分かれているため、同じPolygon形状でも、propertiesを変えることで「敷地」「作業範囲」「立入禁止区域」「点検対象区域」など、異なる意味を持たせることができます。逆に、同じ属性項目を持っていても、geometryがPointであれば点、LineStringであれば線、Polygonであれば面として扱われます。
Featureの基本形は次のようになります。
json { "type": "Feature", "properties": { "name": "第1調査区域", "category": "調査範囲", "status": "確認済み" }, "geometry": { "type": "Polygon", "coordinates": [ [ [139.7000, 35.6800], [139.7010, 35.6800], [139.7010, 35.6810], [139.7000, 35.6810], [139.7000, 35.6800] ] ] } }
この例では、typeがFeatureになっているため、これはひとつの地物を表しています。propertiesにはname、category、statusという属性が入っています。これらは地図上の形を決める情報ではありませんが、対象を識別したり、業務上の意味を伝えたりするために重要です。geometryにはPolygonが指定され、coordinatesに面の外周を表す座標列が入っています。
実務でFeatureを扱うときは、propertiesの設計がとても重要です。地図上で表示できれば十分だと思って座標だけを作ると、後から「どの現場のデータか分からない」「調査日が分からない」「担当者や更新状態を追えない」といった問題が発生します。特に複数部署で共有するGeoJSONでは、属性項目が不足していると、地図データとしては読めても業務データとして使いにくくなります。
propertiesに入れる項目は、目的に応じて決めます。たとえば現地調査の区域データであれば、区域名、管理番号、調査日、調査者、確認状態、備考などが考えられます。施設管理であれば、施設種別、管理部門、点検周期、最終確認日、リスク区分などが必要になるかもしれません。土地や区画を扱う場合は、区画番号、用途、面積、境界確認状況、関連資料番号などが役立ちます。
ただし、propertiesに何でも入れればよいわけではありません。属性が多すぎると、更新管理が複雑になり、入力漏れや表記ゆれが増えます。実務では、まず識別に必要な項目、地図表示に必要な項目、検索や集計に必要な項目を優先して決めると整理しやすくなります。名称だけでなく、機械的に一意に判別できる管理番号を持たせることも有効です。
Featureを理解するうえで大切なのは、Featureは単なる形状データではないという点です。Polygonの座標列だけを切り出して見ても、それが何の区域なのかは分かりません。propertiesと組み合わせて初めて、地図上の意味を持つデータになります。GeoJSONを確認するときは、typeがFeatureになっているか、geometryが期待どおりの形状か、propertiesが業務に必要な情報を持っているかをセットで見る必要があります。
また、複数のFeatureを扱う場合はFeatureCollectionの構造になります。FeatureCollectionの中にはfeaturesという配列があり、その中にFeatureが複数並びます。たとえば、10か所の調査区域をひとつのGeoJSONファイルにまとめる場合、FeatureCollectionの中に10個のFeatureが入ります。それぞれのFeatureが個別のgeometryとpropertiesを持つため、地図上では10個の区域として表示でき、属性も個別に管理できます。
FeatureCollectionは、データ全体をまとめる便利な入れ物ですが、すべてのFeatureの属性設計がばらばらだと後工程で扱いにくくなります。あるFeatureにはstatusがあり、別のFeatureには状態という別名の項目がある、といった状態では、検索や集計が難しくなります。GeoJSONを業務データとして整える場合は、Feature単位の構造だけでなく、FeatureCollection全体で属性名や値のルールをそろえることが重要です。
Polygonは区域や敷地を表す面データ
Polygonは、GeoJSONで面を表すためのgeometryです。点を表すPointや線を表すLineStringに比べて、Polygonは実務上の意味が大きくなりやすい形状です。なぜなら、面は「範囲」を表すからです。敷地、建物外形、作業区域、調査区域、規制区域、農地、管理エリア、危険範囲など、現場で判断が必要になる多くの情報はPolygonで表現できます。
Polygonの基本は、外周を構成する座標列です。面を作るには、複数の頂点を順番に結び、最後に最初の座標へ戻って閉じる必要があります。GeoJSONのPolygonでは、座標列の最初と最後が同じ座標になるように記述します。これにより、線ではなく閉じた面として扱われます。
次の例は、単純な四角形のPolygonです。
json { "type": "Polygon", "coordinates": [ [ [139.7000, 35.6800], [139.7020, 35.6800], [139.7020, 35.6820], [139.7000, 35.6820], [139.7000, 35.6800] ] ] }
coordinatesの中に、さらに配列が入っている点に注目してください。Polygonでは、外周の座標列をひとつの輪として扱います。この輪をリングと考えると分かりやすいです。上の例では、外側の配列の中にひとつのリングがあり、そのリングの中に5つの座標があります。四角形なのに5点あるのは、最後の座標で最初の座標に戻って面を閉じているためです。
Polygonでよくある誤りは、最後の座標を省略してしまうことです。見た目上は四角形に見える座標列でも、GeoJSONとしては閉じたリングになっていなければ、正しいPolygonとして扱えない場合があります。読み込み側の仕組みによっては自動補正されることもありますが、業務データとしては最初と最後を明示的に一致させるのが安全です。
もうひとつ重要なのが、座標の順番です。Polygonの外周は、頂点を順に並べて表現します。座標の順番が入れ替わると、辺が交差したり、想定とは異なる形になったりすることがあります。たとえば、四角形の角を順番に回るのではなく、対角線方向に飛ぶような順番で並べると、蝶ネクタイのように交差した面になってしまいます。これは地図上の表示不具合だけでなく、面積計算や区域判定にも影響します。
Polygonには穴を表すこともできます。たとえば、大きな管理区域の中に除外区域がある場合、外周のリングに続いて、内側のリングを記述します。外周が対象範囲全体を表し、内側のリングがくり抜く範囲を表します。実務では、敷地の中に対象外部分がある場合や、区域内に除外地がある場合などに使われます。
json { "type": "Polygon", "coordinates": [ [ [139.7000, 35.6800], [139.7040, 35.6800], [139.7040, 35.6840], [139.7000, 35.6840], [139.7000, 35.6800] ], [ [139.7010, 35.6810], [139.7020, 35.6810], [139.7020, 35.6820], [139.7010, 35.6820], [139.7010, 35.6810] ] ] }
この例では、最初のリングが外周、次のリングが内側の穴を表します。座標列の階層が一段増えるため、慣れていないと読み間違えやすい部分です。単純なPolygonなのか、内側に除外範囲を持つPolygonなのかは、coordinatesの中にリングがいくつあるかを見ると判断できます。
Polygonを業務で扱う際には、見た目だけでなく意味も確認する必要があります。たとえば、地図上で区域が表示されていても、それが外周なのか、内側の除外範囲を含むのか、複数区域のうちのひとつなのかを確認しなければ、誤った判断につながります。特に面積集計、重なり判定、区域内外判定、現地案内などに使う場合は、Polygonの構造ミスがそのまま業務ミスになります。
Polygonと似た概念に、複数の面をまとめて扱うMultiPolygonがあります。離れた複数の区域をひとつの対象として扱いたい場合には、単独のPolygonではなく、複数のPolygonをまとめる形が使われることがあります。たとえば、同じ管理番号に属する区域が離れた場所に複数ある場合などです。実務では、ひとつのFeatureにひとつのPolygonを入れるのか、MultiPolygonでまとめるのか、あるいはFeatureを分けるのかを事前に決めておく必要があります。
Polygonは便利ですが、正しく作るには測量成果、図面、現地確認、座標系、データ作成手順の整合が重要です。紙図面や画像をなぞって作ったPolygonと、現地で取得した座標から作ったPolygonでは、精度や根拠が異なります。GeoJSONの形式だけを見ればどちらもPolygonですが、業務上の信頼性は作成方法によって大きく変わります。そのため、propertiesに作成方法や確認状態を持たせることも有効です。
実例で見るFeatureとPolygonの読み方
ここでは、実務でよくある「調査区域をGeoJSONで管理する」ケースを想定して、FeatureとPolygonを読み解いていきます。次の例は、ひとつの調査区域を表すGeoJSONです。
json { "type": "Feature", "properties": { "area_id": "A-001", "area_name": "北側調査区域", "purpose": "現況確認", "survey_date": "2026-05-20", "status": "確認済み", "memo": "境界付近は再確認予定" }, "geometry": { "type": "Polygon", "coordinates": [ [ [139.7000, 35.6800], [139.7030, 35.6800], [139.7030, 35.6820], [139.7015, 35.6830], [139.7000, 35.6820], [139.7000, 35.6800] ] ] } }
まず見るべきなのは、一番外側のtypeです。ここではFeatureになっているため、このデータはひとつの地物を表しています。次にpropertiesを見ると、area_idがA-001、area_nameが北側調査区域、purposeが現況確認、survey_dateが2026-05-20、statusが確認済みとなっています。これにより、このFeatureが単なる面ではなく、特定の調査区域を表す業務データであることが分かります。
次にgeometryを確認します。geometryのtypeはPolygonです。つまり、このFeatureは点や線ではなく、面として表現される対象です。coordinatesを見ると、外周を構成する座標列が並んでいます。最初の座標は[139.7000, 35.6800]で、最後の座標も同じです。これにより、面が閉じていることが確認できます。
このPolygonは四角形ではなく、5つの頂点を持つ多角形です。最後の点は閉じるための重複なので、実際の角は5点です。座標を順番に見ると、南西付近から東へ進み、北東側へ上がり、中央寄りの北側の点を経由し、西側へ戻り、最初の点に戻る形になっています。地図に表示しなくても、座標列の流れを見ることで、おおまかな形を想像できます。
実務では、GeoJSONを受け取ったら、まずこのようにtype、properties、geometry、coordinatesを順番に確認するとよいです。いきなり座標の正しさだけを検証しようとすると、何のためのデータか分からないまま細部に入ってしまいます。最初にFeatureとしての意味を確認し、その後にPolygonとしての形を確認する流れが安全です。
次に、複数の区域をまとめたFeatureCollectionの例を見てみます。
json { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "area_id": "A-001", "area_name": "北側調査区域", "status": "確認済み" }, "geometry": { "type": "Polygon", "coordinates": [ [ [139.7000, 35.6800], [139.7030, 35.6800], [139.7030, 35.6820], [139.7000, 35.6820], [139.7000, 35.6800] ] ] } }, { "type": "Feature", "properties": { "area_id": "A-002", "area_name": "南側調査区域", "status": "未確認" }, "geometry": { "type": "Polygon", "coordinates": [ [ [139.7000, 35.6770], [139.7030, 35.6770], [139.7030, 35.6790], [139.7000, 35.6790], [139.7000, 35.6770] ] ] } } ] }
この例では、一番外側のtypeがFeatureCollectionです。featuresの中にFeatureが2つ入っており、それぞれが北側調査区域と南側調査区域を表しています。どちらもgeometryはPolygonですが、propertiesのarea_idやarea_nameが異なるため、別々の区域として扱えます。
ここで重要なのは、FeatureCollection全体ではなく、個々のFeatureが業務上の単位になることです。地図上に2つの面が表示されたとしても、それぞれに属性が紐づいていなければ、どちらが確認済みでどちらが未確認なのか分かりません。上の例ではstatusがFeatureごとに異なるため、地図表示時に状態別に見分けたり、未確認区域だけを抽出したりできます。
読み方の手順としては、まず全体がFeatureCollectionかどうかを確認します。次にfeaturesの数を見て、対象がいくつあるかを把握します。そのうえで、各Featureのpropertiesを見て識別情報を確認し、geometryのtypeが期待どおりかを確認します。最後にcoordinatesを見て、座標順、閉じ方、位置の妥当性を確認します。
実務でよくあるトラブルとして、propertiesのarea_idはA-001なのに、geometryが別区域の座標になっているという不整合があります。これはデータ加工時に属性と形状の対応がずれた場合に起こります。GeoJSONはFeatureの中に属性と形状をまとめられるため本来は対応管理に向いていますが、外部データから変換したり、複数のファイルを結合したりするときには注意が必要です。
また、同じFeatureCollection内でgeometryの種類が混在することもあります。調査地点はPoint、調査ルートはLineString、調査区域はPolygonというように、用途によって混在が必要な場合もあります。しかし、区域データとして受け渡すはずのファイルにPointやLineStringが混ざっていると、後工程で想定外の処理になることがあります。業務上「このファイルはPolygonだけを含む」と決めている場合は、全Featureのgeometry typeを確認する必要があります。
GeoJSONを実例で読むときは、見た目の地図表示だけに頼らないことも大切です。地図上では正しく見えても、propertiesの項目名が不統一だったり、座標の桁数が必要以上に粗かったり、閉じ方が不完全だったりする場合があります。逆に、テキスト上では複雑に見えても、構造を順番に追えば、Feature、properties、geometry、Polygon、coordinatesという関係で整理できます。
業務利用で失敗しない確認ポイント
GeoJSONのFeatureとPolygonを業務で使う場合、単にファイルが読み込めるかどうかだけでは不十分です。地図に表示できることと、業務判断に使えることは同じではありません。特にPolygonは範囲を表すため、位置のずれ、形状の誤り、属性の不足が、現地確認、施工範囲、管理区域、面積集計、報告資料に影響します。
最初に確認したいのは、座標の順番です。標準的なGeoJSONでは経度、緯度の順で座標を書きます。日本語の感覚で緯度、経度の順に入力すると、表示位置が大きく外れる可能性があります。データを受け取ったときは、対象地域のおおよその経度と緯度を把握し、座標値が自然な範囲にあるか確認します。日本国内の多くの地域であれば、経度はおおむね120度台から150度台、緯度は20度台から40度台に収まることが多いため、極端に逆転していないかを見つけやすくなります。
次に、Polygonの始点と終点が一致しているかを確認します。Polygonは閉じた面なので、外周リングの最初と最後の座標が同じである必要があります。座標が閉じていない場合、読み込み側でエラーになることや、意図しない補正が行われることがあります。補正された結果が必ず正しいとは限らないため、元データの段階で閉じた座標列にしておくことが重要です。
座標の並び順も重要です。Polygonの頂点は外周に沿って順番に並んでいる必要があります。現地で取得した点を登録順のまま並べたり、表計算データの行順が崩れたりすると、線が交差した不正な面になることがあります。地図上で面がねじれて見える場合や、面積が想定と大きく異なる場合は、座標の順番を疑うべきです。
Polygonでは、外周リングと内側リングの扱いも確認します。穴を持つPolygonの場合、coordinatesの中に複数のリングが入り、最初のリングが外周、次以降が内側の穴を表します。リングの向きについては、作成ツールや検証ツールが警告を出す場合があります。地図表示だけで問題が見えない場合でも、変換、面積計算、他システム連携の前には検証しておくと安全です。
属性情報の確認も欠かせません。propertiesに必要な項目が入っていないと、地図表示後の検索、分類、帳票作成、更新管理が難しくなります。特に業務で使うGeoJSONでは、名称だけでなく、管理番号、対象種別、確認状態、更新日、作成方法などを検討する価値があります。ただし、不要な項目を増やしすぎると入力負荷が高くなるため、実際に使う項目を中心に設計します。
属性名の表記ゆれにも注意が必要です。たとえば、あるFeatureではarea_id、別のFeatureではareaId、さらに別のFeatureでは区域番号という項目名になっていると、機械的な処理が難しくなります。人が見れば意味が分かっても、データ処理では別項目として扱われます。FeatureCollection内では、同じ意味の属性名を統一することが基本です。
Polygonの意味とpropertiesの意味が一致しているかも確認します。たとえば、propertiesでは「北側区域」と書かれているのに、geometryが南側の座標を持っている場合、地図上の形だけでは気づきにくいことがあります。データ結合、手作業編集、座標変換、複数ファイルの統合を行った後は、属性と形状の対応関係を確認することが重要です。
座標の精度も実務では大きな意味を持ちます。GeoJSONは座標の桁数を自由に記述できますが、元データの精度以上に細かい桁を書いても、実際の精度が上がるわけではありません。逆に、座標を丸めすぎると境界位置がずれる可能性があります。用途が概略表示なのか、現地確認なのか、施工や測量に近い判断なのかによって、必要な精度は変わります。GeoJSONの形式だけで精度を保証できるわけではないため、取得方法や作成方法の記録も大切です。
面積を扱う場合は、単純にGeoJSONの座標列だけで判断しないよう注意が必要です。GeoJSONの座標は地球上の位置を表すため、面積計算には座標の扱い方や計算方法が関係します。地図上で見た面積、平面上で計算した面積、業務上採用する面積が必ず一致するとは限りません。面積を契約、報告、施工数量、管理数量に使う場合は、どの方法で算出した値かを明確にする必要があります。
データ受け渡し時には、文字コード、改行、拡張子、ファイル名、更新日時、作成者、バージョン管理も確認すると安全です。GeoJSON自体はテキスト形式ですが、ファイルの管理が雑だと、古いデータを使ってしまったり、途中編集されたデータを正式版と誤認したりします。現場で使う場合は、ファイル名に日付や管理番号を含める、正式版と作業版を分ける、更新履歴を残すといった運用が役立ちます。
さらに、GeoJSONを他の形式から変換して作る場合は、変換前後で形状が変わっていないかを確認する必要があります。座標の順番、座標系の扱い、属性名、文字列の扱い、面の穴の扱い、複数面の扱いなどは、変換処理で崩れることがあります。変換後に地図上で重ね合わせて確認し、代表的なFeatureについてpropertiesとgeometryを直接見ると、早い段階で問題を発見できます。
実務でGeoJSONを安定して使うには、作成、確認、共有、更新の流れを決めておくことが重要です。誰が座標を作るのか、誰が属性を入力するのか、誰が最終確認するのか、どの状態のデータを正式版とするのかを決めておくことで、属人的なミスを減らせます。GeoJSONは扱いやすい形式ですが、運用ルールなしに使うと、同じ名前のファイルが複数できたり、属性設計がばらばらになったりしやすいです。
特に現場と事務所でデータをやり取りする場合は、現地で取得した位置情報と、事務所で作成した図面由来の情報を混在させる場面があります。このとき、どちらの情報が最新か、どちらを正とするか、どの程度の位置精度があるかを明確にしないと、GeoJSON上では同じPolygonに見えても判断を誤る可能性があります。propertiesに取得方法、確認日、確認者、信頼度のような情報を持たせると、後から確認しやすくなります。
まとめ：現場の位置情報を扱うならGeoJSONの構造理解が重要
GeoJSONのFeatureとPolygonを理解することは、単にファイル形式を覚えることではありません。実務では、地図上の対象物をどの単位で管理し、どの属性を持たせ、どの座標列で表現し、どのように共有するかが重要になります。Featureは地物と属性をまとめる入れ物であり、Polygonは区域や敷地などの面を表すgeometryです。この関係を理解すると、GeoJSONの読み書きが大きく整理しやすくなります。
Featureを見るときは、propertiesとgeometryの両方を確認します。propertiesには対象の名称、番号、状態、調査日、備考などの意味情報が入り、geometryには地図上の位置や形状が入ります。Polygonを見るときは、座標の順番、始点と終点の一致、外周と穴の構造、座標値の妥当性を確認します。これらを順番に見れば、複雑に見えるGeoJSONでも、業務で必要な情報を読み取れるようになります。
GeoJSONは、現場調査、施設管理、用地管理、区域整理、施工範囲の共有など、さまざまな場面で使いやすい形式です。一方で、座標の順序を誤る、Polygonが閉じていない、属性名がばらばら、形状と属性が対応していない、といった小さなミスが業務全体に影響することがあります。表示できるかどうかだけでなく、業務判断に使える品質になっているかを確認する姿勢が大切です。
GeoJSONをより実務的に活用するには、現地で取得した位置情報をどのようにFeature化し、PolygonやPointとして整理し、属性付きのデータとして共有するかが鍵になります。特に、現場の状況をその場で記録し、事務所や関係者と位置情報を共有したい場合は、取得から確認、共有までの流れをできるだけ簡潔にすることが重要です。
現場で取得した座標、図面から作成した境界、既存GISから変換した区域データは、GeoJSON上では同じように見えることがあります。しかし、作成方法、確認状態、精度、更新日が異なれば、業務上の意味も異なります。FeatureとPolygonの構造を理解したうえで、属性情報と運用ルールを整えれば、GeoJSONは単なる地図表示用ファイルではなく、調査、管理、確認、共有をつなぐ実用的な位置情報データとして活用しやすくなります。