GeoJSONは、点・線・面などの地理情報をJSON形式で表現するためのデータ形式です。地図表示、現地調査データの整理、区域管理、設備台帳、経路情報、範囲指定など、実務のさまざまな場面で使われます。一方で、見た目には単純なテキストファイルでも、座標の順番、座標系、データ構造、属性の入れ方、ファイル容量、精度管理を誤ると、表示位置のずれや読み込みエラー、後工程での手戻りにつながります。
この記事では、「geojson 使い方」で調べている実務担当者向けに、GeoJSONファイルを作成する前に押さえておきたい基本ルールを6つに分けて解説します。専門的な開発者だけでなく、現場データを整理する担当者、地図データを受け渡す担当者、既存の測量成果や点検記録を地図上で活用したい担当者にも分かるように、作成前の確認ポイントを実務目線でまとめます。
GeoJSONの役割と作成目的を最初に決める
GeoJSONファイルを作成する前に、まず決めるべきことは「何を表すためのデータなのか」です。GeoJSONは地図上に情報を載せるための形式として使いやすい一方、目的が曖昧なまま作り始めると、点で表すべき情報を面で作ってしまったり、属性情報が不足したり、後から別の用途に流用しにくいデータになったりします。
たとえば、現地で確認した設備の位置を記録したい場合は、基本的には点のデータが中心になります。道路や水路、配管、調査ルートのように連続した形を示したい場合は、線のデータが向いています。敷地、管理区域、点検対象範囲、危険範囲、利用区分のように広がりを持つ情報であれば、面のデータとして作成するのが自然です。このように、対象物の性質とGeoJSON上の表現方法を最初に対応させておくと、データの意味が伝わりやすくなります。
実務では、同じ場所に関する情報でも、用途によって必要な形が変わります。たとえば、施設の代表位置を地図に表示するだけなら点で十分ですが、敷地境界や管理範囲を確認したい場合は面が必要です。道路の中心線を管理するなら線で表せますが、道路区域そのものを示す場合は面として作る方が適切です。つまり、GeoJSONの作成では、見た目の地図表示だけでなく、後で誰が何を判断するのかまで考える必要があります。
作成目的を決める際は、表示用なのか、分析用なのか、共有用なのか、台帳管理用なのかを分けて考えることが大切です。表示用であれば、読み込みやすさや見た目の分かりやすさが重要になります。分析用であれば、位置の正確さや属性項目の一貫性が重要になります。共有用であれば、他の担当者が読んでも意味が分かる項目名やファイル名が必要です。台帳管理用であれば、更新日、管理番号、状態区分など、継続的に使える属性設計が欠かせません。
また、GeoJSONはあくまでデータ形式であり、図面そのものや測量成果そのものを完全に置き換えるものではありません。詳細な寸法、正式な境界確認、設計上の判断、法的な証明が必要な場面では、元資料や正式な成果物との関係を明確にしておく必要があります。GeoJSONだけを見て判断できる範囲と、元図面や現地確認が必要な範囲を分けておくことで、誤用を防ぎやすくなります。
ファイルを作る前には、最低限、対象範囲、対象物、利用目的、更新頻度、利用者、必要な属性項目を整理しておくと安全です。特に複数人でデータを扱う場合は、作成者だけが分かる名称や略語を避け、後から見ても意味が通じる表現にすることが重要です。GeoJSONは人が読めるテキスト形式でもありますが、構造が大きくなると内容を目視だけで把握するのは難しくなります。そのため、最初の設計段階で分かりやすい形にしておくことが、後工程の負担を大きく減らします。
座標の順番と座標系の前提をそろえる
GeoJSONを作成するときに特に注意したいのが、座標の順番です。GeoJSONの標準的な位置情報では、座標は経度、緯度の順で記述します。普段の会話や多くの位置情報の表記では緯度、経度の順で扱われることも多いため、この違いを理解していないと、地図上で位置が大きくずれる原因になります。日本国内のデータでも、緯度と経度を逆に入力すると、まったく別の場所を示してしまうため、作成前に必ずルールを統一しておく必要があります。
たとえば、ある地点を表す場合、座標配列では先に東西方向を示す値、次に南北方向を示す値を入れる考え方になります。GeoJSONファイル内でこの順番が混在すると、読み込み自体はできても一部の点だけが想定外の場所に表示されることがあります。特に外部の表計算データや現地記録から座標を転記する場合、元データの列名が「緯度」「経度」の順に並んでいることがあります。そのまま機械的に変換すると、GeoJSONとしては順番が逆になるため注意が必要です。
座標系の前提も重要です。RFC 7946に沿ったGeoJSONでは、座標参照系はWGS 84の経度・緯度を10進度で表す前提です。平面直角座標、ローカル座標、図面上のメートル座標などをそのまま入れると、多くの地図表示環境では正しく表示できません。現場や設計で使われる座標値が、必ずしもそのままGeoJSONに向いているとは限らないため、その座標が経度・緯度なのか、メートル単位の平面座標なのか、独自のローカル座標なのかを作成前に確認する必要があります。
古い資料や一部の変換データでは、座標系を示すためにcrsのような項目が含まれることがあります。しかし、現行のGeoJSON仕様では座標参照系の指定方法が整理されており、外部共有や一般的なWeb地図との連携を前提にする場合は、WGS 84の経度・緯度に変換したうえで渡すのが安全です。関係者間で別の座標系を使う合意がある場合でも、その前提をファイル外の仕様書や運用ルールに明記しておかないと、受け取った側が誤って解釈するおそれがあります。
実務では、測量成果、設計データ、施設台帳、点検記録、現地写真の位置情報など、さまざまな出所の座標を組み合わせることがあります。このとき、元データごとに座標の基準が違っていると、GeoJSON化した後に位置が少しずつずれることがあります。小さなずれに見えても、設備管理や境界付近の確認、掘削や点検の対象位置確認では大きな問題になることがあります。特に、道路沿い、河川沿い、敷地境界付近、地下埋設物付近など、位置の意味が重要な場面では、座標変換の前提を記録しておくことが大切です。
高さ情報を扱う場合も注意が必要です。GeoJSONでは座標の3つ目の値として高さを含められますが、標準仕様上はWGS 84楕円体を基準にしたメートル単位の高さとして扱われます。実務で使う標高、地盤高、管底高、階層、計測機器ごとの高さなどとは意味が異なる場合があるため、水平位置と高さの利用目的を分けて考えることが重要です。高さを入れれば必ず三次元的に正しく表現されるわけではないため、標高や高さを属性情報として別に持たせる方が扱いやすい場合もあります。
座標の小数点以下の桁数も、むやみに多ければよいわけではありません。元データの精度を超えて細かい桁を残しても、見かけ上の精密さが増えるだけで、実際の精度が上がるわけではありません。一方で、丸めすぎると位置のずれが大きくなります。用途に応じて、必要な精度を保ちながら、過剰な桁数を避けることが実務上は大切です。GeoJSONを作成する前に、座標の順番、座標系、桁数、変換方法をそろえておくことで、後から原因不明の位置ずれを調べる手間を減らせます。
点・線・面のジオメトリを正しく使い分ける
GeoJSONでは、地理的な形をジオメトリとして表現します。実務でよく使うのは、点、線、面の3種類です。点は単独の位置を示し、線は複数の座標をつないだ経路や線状の対象を示し、面は閉じた範囲を示します。この使い分けを誤ると、地図上ではそれらしく見えても、検索、集計、面積確認、距離確認、重なり判定などで不都合が起きることがあります。
点データは、施設、標識、マンホール、電柱、調査地点、写真撮影位置、異常箇所の代表点などを表すのに向いています。点は構造が比較的単純で、作成しやすく、表示も軽くなりやすい形式です。ただし、点はあくまで代表位置であり、対象物の広がりまでは表現できません。大きな施設や範囲を持つ対象を点だけで管理する場合は、その点が中心位置なのか、入口なのか、確認地点なのか、代表点なのかを属性情報で明確にしておく必要があります。
線データは、道路中心線、歩行経路、配管の概略ルート、水路、点検ルート、移動軌跡などを表す場合に使います。線は座標の並び順に意味が出ることがあるため、始点と終点を意識して作ることが大切です。たとえば、上流から下流へ、起点から終点へ、管理番号の若い側から大きい側へなど、線の方向を一定にすると、後から距離や経路を扱うときに理解しやすくなります。線が交差する場合や途中で分岐する場合は、一本の線で無理に表すのではなく、区間ごとに分けた方が管理しやすいこともあります。
面データは、敷地範囲、調査区域、工区、管理範囲、危険範囲、利用区分、保全対象区域などを表す場合に使います。面を表すPolygonでは、外周を閉じた線として扱い、最初の座標と最後の座標を一致させる必要があります。また、1つのリングは少なくとも4つの位置を持つ必要があります。穴のない面では外周リングを1つ、穴のある面では外周リングに続けて内側のリングを入れる構造になります。
Polygonでは、リングの向きにも注意します。現行仕様では、外周リングは反時計回り、穴を表す内側リングは時計回りが基本です。ただし、互換性のために、向きが異なるPolygonでも読み込み側が直ちに拒否しないことがあります。そのため、表示できるから正しいと判断するのではなく、作成段階でリングの閉じ方と向きを検証しておくと安全です。境界や面積が業務判断に関わる場合は、面として正しい構造になっているかを確認することが大切です。
複数の点、複数の線、複数の面を一つの対象として扱いたい場合もあります。たとえば、離れた複数の区域を一つの管理単位にしたい場合や、複数の線分で構成される路線を一つの情報として扱いたい場合です。このようなときは、MultiPoint、MultiLineString、MultiPolygonのような複数形のジオメトリを使う方法があります。ただし、後工程で扱う環境によっては、単独の点や線や面に分けておいた方が編集しやすい場合もあります。作成時には、データ構造としての正しさだけでなく、利用者が後で編集、検索、集計しやすいかも考える必要があります。
また、GeometryCollectionのように異なる種類の形をまとめられる構造もありますが、実務では慎重に使うべきです。点、線、面が混在した構造は柔軟ですが、処理側が対応していない場合や、編集時に意味が分かりにくくなる場合があります。特別な理由がない限り、点は点、線は線、面は面として整理し、同じ種類のデータをまとまりとして扱う方が安全です。GeoJSONの使い方に慣れていない担当者が関わる場合は、構造をシンプルにしておく方が、共有や確認のミスを防ぎやすくなります。
ジオメトリの選択では、「地図上にどう見せたいか」だけでなく、「そのデータを使って何を判断したいか」を基準にすることが大切です。位置を示すだけなら点、つながりや経路を示すなら線、範囲や面積を示すなら面という基本に立ち返ることで、後から扱いやすいGeoJSONになります。距離や面積を厳密に計算する場合は、GeoJSONの経度・緯度の値をそのまま使うのではなく、使用するGISや分析ツールの計算方法、投影変換の有無も確認しておきましょう。
属性情報は後から使う項目を想定して設計する
GeoJSONでは、形を表すジオメトリだけでなく、propertiesに属性情報を入れることができます。属性情報は、地図上の対象物に意味を持たせるための重要な部分です。位置だけが分かっても、それが何を示しているのか、どの状態なのか、いつ確認したのか、誰が管理するのかが分からなければ、実務データとしては使いにくくなります。GeoJSONを作成する前には、後で検索、表示、分類、集計に使う項目を想定して、属性設計を行うことが大切です。
属性項目には、管理番号、名称、種別、状態、確認日、更新日、担当区分、備考などを入れることがよくあります。ただし、何でも入れればよいわけではありません。不要な項目が多いと、入力の手間が増え、空欄や表記ゆれも増えます。一方で、必要な項目が不足していると、後から元資料を探し直すことになります。作成前に、必須項目と任意項目を分け、どの項目が業務判断に必要なのかを整理しておくことが重要です。
Featureごとに共通して使う識別子がある場合は、properties内の管理番号だけでなく、GeoJSONのidとして持たせる設計も検討できます。ただし、どの値を正式な識別子として扱うかを決めずに複数の番号を混在させると、更新時に混乱します。設備ID、台帳番号、現地番号、図面番号などがある場合は、それぞれの役割を明確にし、検索や更新でどれを主キーとして使うのかを決めておくと安全です。
項目名は、できるだけ一貫した書き方にします。たとえば、同じ意味の項目を「確認日」「点検日」「調査日」のように混在させると、後で検索や集計を行うときに扱いにくくなります。日本語の項目名を使う場合は読みやすい反面、処理環境によっては文字コードや扱いに注意が必要になることがあります。英数字の項目名を使う場合は機械処理に向きますが、担当者が意味を理解しにくいことがあります。実務では、利用者の範囲に合わせて、分かりやすさと処理しやすさのバランスを取る必要があります。
属性値の表記ゆれにも注意が必要です。たとえば、状態を表す値として「良好」「異常なし」「問題なし」が混在していると、人が読む分には似た意味でも、データとしては別の値になります。種別でも「道路照明」「照明」「ライト」のような表記が混ざると、分類が難しくなります。GeoJSONファイルを作成する前に、選択肢として使う言葉を決めておくと、後工程での整理が楽になります。特に複数人で入力する場合は、自由記述を減らし、決まった区分で入力する方が品質を保ちやすくなります。
日付や数値の扱いも統一が必要です。日付は年、月、日の順で一定の形式にそろえると、並べ替えや検索がしやすくなります。数値は単位を属性名に含めるか、別項目で単位を示すなどして、意味が曖昧にならないようにします。たとえば、延長、幅、高さ、深さ、標高、面積などは、単位が分からないと誤解が生じます。見た目には小さな違いでも、実務判断では大きな差になることがあるため、属性設計では単位と形式を明確にすることが大切です。
個人情報や機微な情報を入れすぎないことも重要です。GeoJSONはテキスト形式であり、共有や変換がしやすい反面、意図せず広い範囲に渡る可能性もあります。担当者名、連絡先、個人宅に関する情報、立入制限に関わる詳細、保安上の情報などは、ファイルに含める必要があるか慎重に判断する必要があります。公開用、社内用、現場用、保管用で属性項目を分けることも検討すべきです。
また、propertiesには見た目の設定を直接入れたくなる場合がありますが、表示色や線幅などの表現情報と、対象物そのものの属性は分けて考える方が整理しやすくなります。表示方法は利用環境側で変えることがあり、データ本体に固定しすぎると別の用途で使いにくくなることがあります。GeoJSONは、まず正しい位置と意味を持つデータとして作り、必要に応じて表示側で見せ方を調整する考え方が安全です。
ファイル構造とJSON文法の崩れを防ぐ
GeoJSONはJSONを基礎にした形式であるため、見た目が地理データであっても、まずJSONとして正しい構造になっていなければ読み込めません。カンマの不足、括弧の閉じ忘れ、引用符の不一致、不要な文字の混入などがあると、ファイル全体が読み込めなくなることがあります。GeoJSON作成では、地図上の位置だけでなく、テキストデータとしての文法確認も欠かせません。
GeoJSONのテキストは、基本的に1つのGeoJSONオブジェクトとして扱います。多くの場合、FeatureCollectionというまとまりの中に複数のFeatureを入れます。Featureは、一つの地物を表す単位であり、ジオメトリと属性情報を持ちます。この基本構造を理解しておくと、データを追加したり修正したりするときに混乱しにくくなります。単独の点や線だけを扱う場合でも、後から複数のデータに増える可能性があるなら、最初からFeatureCollectionとして整理しておくと扱いやすくなります。
構造の崩れでよくあるのは、featuresの配列内でFeature同士を区切るカンマが抜ける、最後に不要なカンマを入れる、propertiesの中で文字列を引用符で囲み忘れる、座標配列の階層を間違える、といったものです。特に面データでは、点よりも座標配列の階層が深くなるため、括弧の数が合わなくなりがちです。手作業で編集する場合は、一度に大きく書き換えるのではなく、少しずつ確認しながら修正する方が安全です。
GeoJSONでは、ジオメトリを持たないFeatureを表すためにgeometryをnullにできる場合があります。また、propertiesもJSONオブジェクトまたはnullとして扱えます。ただし、実務で継続的に管理するデータでは、空でもpropertiesをオブジェクトとして用意しておいた方が、後から属性を追加しやすく、処理側の想定もそろえやすくなります。仕様上可能な書き方と、運用上扱いやすい書き方は分けて考えることが大切です。
文字コードにも注意が必要です。日本語の属性名や属性値を含む場合、保存形式や読み込み環境によって文字化けすることがあります。現在は多くの環境で日本語を扱えますが、古い環境や一部の処理では問題が起きることがあります。重要な管理番号や分類コードは英数字で持たせ、日本語の名称や備考は補足として使うなど、実務上の安全策を取ると共有時のトラブルを減らせます。
ファイル名も軽視できません。GeoJSONファイルは共有や更新を前提にすることが多いため、ファイル名だけで内容、対象範囲、作成日、版数がある程度分かるようにしておくと便利です。ただし、長すぎるファイル名や特殊な記号を多用したファイル名は、環境によって扱いにくくなることがあります。実務では、対象名、用途、日付、版数を簡潔に組み合わせる程度が扱いやすいです。
GeoJSONの拡張子は.geojsonがよく使われますが、中身はJSON形式であるため、単に拡張子を変えただけでは正しいGeoJSONになるわけではありません。元データを変換するときは、変換後のファイルがGeoJSONとして正しいtype、features、geometry、propertiesを持っているか確認することが大切です。見た目上はファイルができていても、中身の構造が用途に合っていなければ、後で読み込みや編集に支障が出ます。
作成後には、必ず読み込み確認を行います。テキストとして文法が正しいか、地図上で想定位置に表示されるか、属性が欠けていないか、点や線や面が意図した形になっているかを確認します。確認は作成者だけでなく、実際に使う担当者の視点でも行うと、項目名の分かりにくさや用途とのずれに気づきやすくなります。GeoJSONは軽く扱える形式だからこそ、作成直後の確認を省略しがちですが、ここでの確認が後の手戻りを防ぎます。
精度・容量・運用ルールを決めてから共有する
GeoJSONファイルは作成して終わりではありません。実務では、共有、更新、再利用、変換、保管が続きます。そのため、ファイルを作成する段階で、精度、容量、更新方法、版管理、共有範囲を決めておくことが大切です。特に複数の担当者や部署が関わる場合、運用ルールがないGeoJSONは、いつの間にか古いデータと新しいデータが混在し、どれが正しいのか分からなくなることがあります。
まず考えるべきなのは、必要な位置精度です。GeoJSONは座標を細かく記述できますが、元データの精度以上に正確になるわけではありません。座標の桁数が多いことは、必ずしも位置の不確かさが小さいことを意味しません。現地で簡易的に取得した位置、図面から読み取った位置、測量成果に基づく位置では、信頼できる精度が異なります。これらを同じファイルに入れる場合は、属性情報として取得方法や精度区分を持たせると、利用者が判断しやすくなります。
次に、ファイル容量にも注意します。GeoJSONはテキスト形式で扱いやすい反面、大量の座標を含むとファイルサイズが大きくなりやすい形式です。細かすぎる線や面をそのまま入れると、表示が重くなったり、共有しにくくなったりすることがあります。特に広い範囲の境界線、細かな地形形状、大量の点群に近いデータを扱う場合は、GeoJSONに向いている粒度かどうかを確認する必要があります。表示用であれば形状を適度に簡略化し、詳細確認用の元データとは分けて管理することもあります。
ただし、簡略化しすぎると、境界や対象範囲の意味が変わる場合があります。たとえば、区域の端部、道路や河川に沿った境界、設備に近接する範囲などでは、少しの形状変化が判断に影響することがあります。容量を小さくするための調整は、用途に応じて慎重に行う必要があります。表示速度だけを優先して、実務判断に必要な情報を失ってしまっては本末転倒です。作成前に、表示用、確認用、保管用のどれを作るのかを分けて考えると整理しやすくなります。
更新ルールも重要です。GeoJSONファイルを複数人で編集する場合、誰がいつ更新したのか、どのデータを元にしたのか、古い版をどう扱うのかを決めておく必要があります。ファイル名に日付や版数を入れるだけでなく、属性情報に更新日や確認状態を入れると、地物単位での管理がしやすくなります。全体のファイル更新日だけでは、個別の設備や区域がいつ確認されたのか分からないことがあるためです。
共有範囲にも配慮が必要です。GeoJSONには位置情報が含まれるため、公開してよい情報と内部利用にとどめるべき情報を分ける必要があります。設備の詳細位置、管理上重要な施設、立入制限に関わる場所、個人や特定の利用者に関わる情報が含まれる場合は、共有前に内容を確認することが欠かせません。外部共有用には属性を減らしたファイルを作る、位置を必要な範囲に限定する、内部用と公開用を分けるといった対応が考えられます。
運用では、元データとの関係も明確にしておきます。GeoJSONを編集した後に元の台帳や図面へ反映するのか、元データを更新してからGeoJSONを再作成するのかによって、正本となるデータが変わります。正本が曖昧なまま複数のファイルを更新すると、どの情報が最新か分からなくなります。GeoJSONを地図表示用の派生データとして使うのか、業務上の管理データとして使うのかを決め、更新の流れを整理しておくことが必要です。
最後に、作成したGeoJSONを実際の業務で使う前には、小さな範囲で試してから全体に広げると安全です。少数のデータで構造、座標、属性、表示、検索、共有の流れを確認し、問題がなければ対象範囲を拡大します。最初から大量のデータを作成すると、誤りが見つかったときの修正範囲も大きくなります。GeoJSONは手軽に作れる形式ですが、実務で安定して使うには、作成前のルール決めと作成後の確認が欠かせません。
GeoJSONファイル作成を実務で活かすためのまとめ
GeoJSONファイルを作成する前には、データの目的、座標の前提、ジオメトリの種類、属性設計、ファイル構造、運用ルールを順番に確認することが大切です。GeoJSONは、地理情報を扱うための分かりやすい形式ですが、単に座標を並べれば実務で使えるデータになるわけではありません。どの位置を、どの精度で、どの意味を持たせて、誰に共有するのかを整理して初めて、業務で使いやすいファイルになります。
特に注意したいのは、座標の順番と座標系です。GeoJSONでは経度、緯度の順で座標を扱うことが基本になるため、緯度、経度の順で記録された元データをそのまま使うと位置ずれの原因になります。また、平面座標やローカル座標を扱っている現場では、GeoJSONに変換する前に、WGS 84の経度・緯度として扱える値になっているかを確認する必要があります。位置情報のファイルでは、最初の前提がずれていると、後の修正が大きな手間になります。
ジオメトリの選び方も、実務の使いやすさに直結します。点、線、面を正しく使い分けることで、対象物の意味が伝わりやすくなり、検索や集計もしやすくなります。代表位置だけを示したいのか、経路を示したいのか、範囲を示したいのかを作成前に判断しておくことが重要です。複雑な構造を使えば高度な表現ができますが、共有や編集のしやすさを考えると、必要以上に複雑にしないことも大切です。
属性情報は、GeoJSONを単なる地図表示から実務データへ変える要素です。管理番号、種別、状態、確認日、更新日などを適切に設計しておくと、後から検索、分類、確認がしやすくなります。一方で、表記ゆれや不要な項目が多いと、データ品質が下がります。入力する人が迷わない項目名と値のルールを決め、必要に応じて公開用と内部用を分けることで、安全に運用しやすくなります。
ファイル構造の確認も欠かせません。GeoJSONはJSONとして正しくなければ読み込めません。括弧、カンマ、引用符、座標配列の階層、FeatureCollectionの構造など、基本的な文法を崩さないように確認する必要があります。作成後は、地図上に表示できるかだけでなく、位置、形状、属性、文字化け、ファイル名、版数まで含めて確認すると、共有後のトラブルを減らせます。
GeoJSONの使い方に慣れてくると、現地調査、設備管理、区域整理、点検記録、写真位置の整理など、多くの業務で活用できます。ただし、現場の位置情報を扱う場合は、作成したデータをどのように取得し、どの精度で管理し、どの流れで更新するかが重要になります。スマートフォンや測位機器、GIS、表計算データ、台帳システムなどを組み合わせる場合も、GeoJSONだけで完結させるのではなく、元データ、変換手順、確認方法、共有範囲を明確にしておくことが大切です。作成前のルールを整えておけば、GeoJSONは現場データと地図活用をつなぐ扱いやすい形式として、実務の効率化に役立ちます。