GeoJSONは、行政区域、施設、道路、点検位置、調査範囲などの地理情報をJSON形式で扱える便利なデータ形式です。行政区域データは、市区町村界、町丁目界、字界、都道府県界などを地図上で確認したり、区域別の集計や現地確認、対象地点の分類に活用したりできます。
ただし、行政区域データは、ファイルを読み込んで地図に表示できれば十分というものではありません。境界の意味、座標参照系、ポリゴン構造、データ量、属性情報、更新時期を確認しないまま使うと、集計結果の誤り、説明資料の誤解、現場判断のずれにつながることがあります。この記事では、「geojson 使い方」を調べている実務担当者に向けて、行政区域データをGeoJSONで扱うときに確認したい6つの注意点を解説します。
行政区域データは境界線そのものではなく業務用の地理データとして扱う
GeoJSONで行政区域データを扱うとき、最初に確認したいのは、そのデータが何を目的に作られたものかです。行政区域データという名称だけを見ると、都道府県、市区町村、町丁目などの境界がそのまま正確に入っているように感じるかもしれません。しかし実際には、表示、統計、区域判定、資料作成など、用途に応じて整備・加工された地理データであることが多く、法律上の境界や土地の権利境界を厳密に保証するものとは限りません。
地図上に線が表示されると、その線が唯一の正しい境界のように見えます。しかし、行政区域データの形状は、縮尺、作成方法、元資料、整備時期、簡略化の有無によって変わります。海岸線、河川、山間部、埋立地、道路沿い、区画整理中の地域などでは、画面上の境界と現地感覚が一致しないことがあります。そのため、地図上で確認できる線は、業務判断を助ける参考情報として扱う姿勢が必要です。
たとえば、営業エリアの可視化、自治体別の件数集計、点検対象の概略分類、調査範囲の説明資料づくりであれば、行政区域データは非常に役立ちます。一方で、土地の権利境界、施工範囲の確定、境界立会い、許認可に関わる厳密な判断では、行政区域データだけを根拠にするのは避けるべきです。画面上のポリゴンをそのまま正とみなすと、後から関係者間で認識のずれが生じる可能性があります。
GeoJSONの行政区域データを使う前には、使い道を明確にします。単に地図に重ねて見せたいのか、住所や座標から区域を判定したいのか、区域ごとに数量を集計したいのか、現地調査の対象範囲を確認したいのかによって、必要な精度や処理方法は変わります。表示用であれば軽量化されたデータで十分な場合がありますが、区域判定や面積計算を行う場合は、形状の省略や簡略化が結果に影響することがあります。
行政区域の階層にも注意が必要です。都道府県、市区町村、町丁目、大字、小字など、どの粒度のデータを使うかによって、地図の見え方もデータ量も大きく変わります。細かい区域ほど現場に近い確認がしやすくなりますが、その分ポリゴン数や頂点数が増え、処理が重くなります。広域の傾向を見るだけであれば市区町村単位で十分なこともあり、現地調査の範囲整理では町丁目や大字単位が必要になることもあります。
実務では、見た目の分かりやすさと業務上の正確性を分けて考えることが重要です。資料に載せる地図では、細かすぎる境界線がかえって読みにくさにつながることがあります。画面操作で使う地図では、ズーム段階に応じて表示する区域の粒度を切り替える設計が有効です。分析用のデータは必要な精度を保ち、表示用のデータは扱いやすいように軽量化するという考え方を持つと、実務で運用しやすくなります。
つまり、行政区域データは「境界を表す便利な地理データ」ではありますが、「すべての用途でそのまま厳密な境界として使えるデータ」ではありません。GeoJSONの読み込み方を覚えるだけでなく、データの目的、精度、作成背景、利用範囲を確認してから使うことが、トラブルを防ぐ第一歩です。
座標参照系と緯度経度の向きを必ず確認する
GeoJSONを扱ううえで特に重要なのが、座標の扱いです。GeoJSONでは、点、線、面の位置を数値の配列として表現します。行政区域データでは、ポリゴンの各頂点が連続した座標として記録され、その座標列によって区域の形が描かれます。ここで確認すべきなのが、座標参照系と座標の並び順です。
実務担当者が混乱しやすいのは、緯度と経度の順番です。一般的な会話では「緯度、経度」と言うことが多いため、北緯を先に、東経を後に書く感覚になりがちです。しかし、標準的なGeoJSONでは、座標は経度、緯度の順で扱います。日本国内であれば、経度はおおむね120度台から150度台、緯度はおおむね20度台から40度台になります。データを読み込んだときに日本から大きく外れた場所へ表示される場合は、緯度経度の順番を逆に扱っていないか確認する必要があります。
座標参照系については、現在一般的に参照されるGeoJSON仕様では、WGS 84に基づく地理座標系を使い、単位は十進度で表します。そのため、外部システムやWeb地図と連携するGeoJSONでは、経度と緯度の値が入っている前提で処理されることが多くあります。平面直角座標系やWebメルカトルなど、メートル単位の座標で管理されている元データを使う場合は、GeoJSONとして出力する前に座標変換が済んでいるか、または社内独自のGeoJSON風データとして扱うべきものかを確認しなければなりません。
この点は、行政区域データを現地測量データ、工事図面、点群、写真位置、設備台帳などと重ねる場合に特に重要です。座標系が一致していないと、画面上の重なりがずれたり、区域判定の結果が誤ったりします。概略表示では気づきにくいずれでも、境界付近の施設や調査点を扱う場面では判断に影響します。
座標変換を行うときは、単に緯度と経度を入れ替えるだけでは不十分です。測地系、座標参照系、単位、変換手順、変換後の精度を確認する必要があります。古い資料や複数部署で管理されてきたデータを統合する場合、見た目は同じ緯度経度でも基準や加工履歴が異なることがあります。変換前の座標系と変換後の座標系を記録しておかないと、後からずれの原因を追跡しにくくなります。
実務では、いきなり全域のデータを読み込むのではなく、小さな範囲でテスト表示することが有効です。対象区域の庁舎、駅、橋、交差点、現場付近の既知点などを使い、行政区域データが想定どおりの場所に表示されるかを確認します。数件のポリゴンで表示位置を確認してから本格処理に進むと、座標順序や座標参照系の誤りを早い段階で見つけやすくなります。
区域判定でも、座標の扱いは結果を左右します。点がどの区域に含まれるかを判定する場合、点データとポリゴンデータが同じ座標参照系でなければ、正しい結果は得られません。現場で取得した位置情報が緯度経度で、行政区域データが別の座標系のままになっている場合、判定結果は信頼できません。表示できたから正しいと判断せず、座標の意味と基準を最初に確認する習慣が大切です。
ポリゴンの構造と穴あき領域を正しく理解する
行政区域データをGeoJSONで扱う場合、多くのデータはPolygonまたはMultiPolygonとして表現されます。Polygonは、区域の外周を座標列で囲むことで面を表す形式です。単純な四角形であれば理解しやすいですが、実際の行政区域は、海岸線、河川、飛び地、離島、湖沼、隣接区域などが絡むため、構造が複雑になります。この構造を理解しないまま処理すると、表示漏れや集計誤りが起きやすくなります。
まず押さえたいのは、一つの行政区域が一つの面だけで構成されるとは限らないことです。離島や飛び地を含む自治体では、一つの区域が複数の面に分かれることがあります。この場合、GeoJSONではMultiPolygonとして表現されることがあります。表示処理や集計処理を作るときに、一つの区域につき一つの外周だけがあると決めつけると、一部の領域が抜け落ちる可能性があります。
次に、穴あきポリゴンにも注意が必要です。Polygonには外周だけでなく、内部の除外領域が含まれる場合があります。たとえば、ある区域の中に別の区域が入り込んでいる場合や、湖沼、対象外領域などを除外する場合です。GeoJSONのPolygonでは、最初のリングが外周を表し、それ以降のリングが内側の穴を表します。これを正しく解釈しないと、本来は含めてはいけない領域まで対象区域として扱ってしまう可能性があります。
ポリゴンを構成する線はLinearRingとして扱われます。LinearRingは閉じたLineStringで、仕様上、始点と終点は同じ座標である必要があります。データを加工するときに最後の座標を不要だと思って削除したり、座標列の順序を崩したりすると、ポリゴンが壊れることがあります。壊れたポリゴンは、地図上で表示できない、線が交差する、面として認識されない、区域判定が失敗するなどの原因になります。
リングの向きにも注意が必要です。標準的なGeoJSONでは、外周リングは反時計回り、穴を表す内周リングは時計回りという向きが示されています。ただし、古いデータや既存ツールで作られたデータには、この向きに従っていないものもあります。多くの表示ライブラリでは問題なく描画できる場合がありますが、データ検証、面積計算、独自の内外判定、他形式への変換では影響することがあります。加工後は表示だけでなく、区域判定や面積計算も確認することが大切です。
行政区域データでは、境界線が非常に細かく分割されていることがあります。海岸線や河川沿いの区域では、わずかな凹凸を表すために大量の頂点が含まれることがあります。これにより形状は細かく表現できますが、処理負荷も増えます。ポリゴンを簡略化する場合は、表示を軽くできる一方で、境界付近の判定結果が変わる可能性があります。特に、境界付近の施設や調査点を区域判定する用途では、簡略化の影響を慎重に確認する必要があります。
ポリゴン同士の重なりや隙間にも注意しましょう。隣接する区域が画面上ではきれいに接しているように見えても、データの作り方によっては小さな隙間や重なりが含まれることがあります。表示上は気づかない程度でも、点がどの区域にも入らない、複数区域に入ってしまう、といった判定問題につながる場合があります。複数の提供元や時期の異なるデータを組み合わせる場合は、境界の整合性を必ず確認します。
実務でGeoJSONの行政区域データを扱う場合は、単純な市街地だけでなく、複雑な区域もテスト対象にすると安全です。離島を含む区域、飛び地がある区域、海岸線が複雑な区域、湖沼を含む区域、細長い区域などを選んで確認すると、処理の弱点が見つかりやすくなります。GeoJSONのポリゴンは見た目には単純な面でも、外周、内周、複数面、頂点数、座標順序、隣接関係など多くの要素を持っています。
データ量が大きい場合は表示用と分析用を分けて考える
行政区域データをGeoJSONで扱うと、想像以上にファイルサイズが大きくなることがあります。都道府県単位であれば比較的軽く扱える場合でも、市区町村、町丁目、字界など細かい粒度になると、ポリゴン数と頂点数が増え、読み込み、描画、検索、判定に時間がかかります。最初は問題なく表示できても、対象範囲を広げた瞬間に動作が重くなることがあります。
GeoJSONは人が読めるテキスト形式であり、構造を確認しやすいという利点があります。一方で、座標値を大量に持つため、細かな行政区域データでは容量が膨らみやすくなります。地図画面で全件を一度に読み込む設計にすると、初回表示に時間がかかり、操作性が落ちます。ブラウザ上で動く業務システムやタブレット端末では、端末性能や通信環境によって体感速度が大きく変わります。
このような場合は、表示用データと分析用データを分けて考えることが有効です。表示用データは、ユーザーが地図上で区域を把握するためのデータです。ズーム段階に応じて形状を簡略化したり、広域では粗い境界を使ったりすることで、画面操作を軽くできます。一方、分析用データは、区域判定や集計、面積計算に使うため、必要な精度を保つことが求められます。見た目を軽くするために分析用データまで過度に簡略化すると、結果の信頼性が下がる可能性があります。
表示用では、どの段階でどの粒度の区域を見せるかも大切です。全国や地方全体を表示しているときに、町丁目単位の細かいポリゴンをすべて描画する必要はありません。広域では都道府県や市区町村単位を表示し、拡大したときに細かな区域を表示するほうが自然です。利用者は必要な情報を段階的に確認でき、画面の負荷も抑えられます。
検索や集計では、毎回GeoJSON全体を読み込んで処理するのではなく、必要な範囲だけを取り出す設計が望ましい場合があります。対象の都道府県だけ、市区町村だけ、現場周辺だけを読み込めるようにすると、処理が軽くなります。大量の区域データを扱う業務では、最初から分割単位を決めておくと運用しやすくなります。
ファイルの分割方法にも注意が必要です。都道府県単位、市区町村単位、業務エリア単位、ズーム段階単位など、目的に応じた分け方があります。細かく分けすぎると管理が煩雑になり、まとめすぎると読み込みが重くなります。実務では、利用者がどの範囲をよく見るのか、どの粒度で検索するのか、どの端末で使うのかを考えながら設計することが大切です。
GeoJSONを加工するときは、不要な属性を削除することも有効です。行政区域データには、区域名、コード、階層、更新情報、元データの管理情報などが含まれることがあります。表示や判定に使わない属性まで全件に持たせると、ファイルサイズが大きくなります。ただし、後から必要になる属性を削除してしまうと再加工が必要になります。表示用、分析用、保管用を分けて管理すると安全です。
軽量化を優先しすぎると、行政区域データの意味が損なわれることがあります。境界線を大きく簡略化した結果、実際には別の区域に属する地点が表示上は隣の区域に見えることがあります。業務資料として使うときは、地図が概略表示であることを明記するなど、利用者が誤解しない工夫も必要です。データ量の問題は単なる性能問題ではなく、利用者が正しく確認できるかという運用上の問題でもあります。
属性情報の表記ゆれと行政区域コードを整理する
GeoJSONの行政区域データでは、形状だけでなく属性情報も重要です。属性情報には、区域名、行政区域コード、都道府県名、市区町村名、町丁目名、階層、更新日、元データの管理情報などが入ることがあります。地図上に色を塗るだけであれば形状が中心になりますが、実務では検索、集計、帳票出力、他データとの結合に属性情報を使うことが多くあります。
よくある問題が表記ゆれです。同じ区域名でも、全角と半角、旧字体と新字体、スペースの有無、丁目の表記、数字の表記、接尾語の有無などが異なる場合があります。人が読むだけなら問題に気づきにくいですが、データ結合では別の値として扱われることがあります。住所台帳、顧客データ、現場一覧、写真管理情報などと行政区域データを結合するときに、区域名だけをキーにすると一致しないケースが出てきます。
そのため、行政区域データを業務で使う場合は、できるだけコードを使って管理することが望ましいです。行政区域コードや社内で定義した区域コードを使えば、名称が多少変わっても同じ区域として扱いやすくなります。ただし、コード体系や区域の対応関係も変更されることがあるため、コード、名称、階層、更新時期をセットで管理する必要があります。名称だけで判断するよりも、コードを中心にして属性を整理したほうが、後工程でのミスを減らしやすくなります。
属性名の付け方にも注意が必要です。GeoJSONではpropertiesに属性情報を自由に持たせることができますが、自由度が高い分、部署や担当者ごとに項目名がばらばらになりがちです。たとえば、市区町村名を表す項目が、あるデータでは自治体名、別のデータでは市町村名、さらに別のデータでは区域名になっていると、処理のたびに読み替えが必要になります。長期的に使うなら、属性名のルールを決めておくことが大切です。
加工時に元の属性を失わないことも重要です。表示用に簡略化したデータでは属性を最小限にしてもよい場合がありますが、元データとの対応が分からなくなると、後から修正や検証ができません。少なくとも、元の区域を識別できるコード、名称、階層、データ基準日、加工日などは保管用データに残しておくと安心です。加工済みデータだけが残り、元データに戻れない状態は避けるべきです。
集計業務では、属性の階層も重要になります。町丁目単位の件数を市区町村単位に集計する、現場数を都道府県別にまとめる、区域ごとに点検対象を色分けする、といった処理では、上位区域との対応関係が必要です。GeoJSONの各地物に上位区域のコードや名称を持たせておくと、集計がしやすくなります。ただし、同じ名称の町丁目が別の市区町村に存在することもあるため、単独の名称だけで階層を判断しないように注意が必要です。
検索機能を作る場合も、属性情報の整理が効いてきます。利用者は正式名称だけでなく、略称、読み、数字表記の違いなどで検索することがあります。GeoJSONそのものにすべての検索用情報を持たせると重くなる場合がありますが、検索用の別データを用意するなどして、利用者が目的の区域を見つけやすくする工夫が必要です。行政区域データは地図で見るものですが、実務では検索して呼び出す場面も多いため、属性設計を軽視できません。
属性情報の品質は、見た目の地図だけでは分かりにくいものです。ポリゴンが正しく表示されていても、属性が間違っていれば、集計や判定の結果は誤ります。区域名の取り違え、コードの欠落、上位区域の誤り、古い名称の混在などがあると、報告資料や管理台帳に影響します。行政区域データを受け取ったら、地図表示だけでなく、属性の件数、重複、欠損、表記ゆれも確認することが大切です。
GeoJSONの行政区域データを実務で使うには、形状と属性を一体で管理する必要があります。形状は地図上の位置を示し、属性は業務上の意味を示します。どちらか一方だけが正しくても、実務データとしては不十分です。特に、他の台帳や現場データと結合する場合は、属性情報の整理が成否を左右します。名称で見える分かりやすさと、コードで管理する正確さを両立させることが重要です。
更新時期と現地の状況差を前提に運用する
行政区域データは、一度入手して終わりではありません。市区町村合併、町名変更、区画整理、住居表示の実施、埋立地の追加、境界の変更などによって、区域情報は変わることがあります。頻繁に変わるものではないとしても、業務システムや資料で長く使う場合は、更新時期を確認し、必要に応じて差し替える運用が必要です。
GeoJSONとして保存した行政区域データは、ファイルとして扱いやすいため、社内で複製されやすいという特徴があります。担当者の端末、共有フォルダ、業務システム、資料作成用の作業環境などに同じようなファイルが散らばることがあります。その結果、どれが最新なのか分からなくなり、古い区域データを使った資料が作成されることがあります。行政区域データは、ファイル名だけでなく、基準日、入手日、加工日、元データの出典を分かる形で管理することが大切です。
特に注意したいのは、ファイルの更新日時とデータの基準日が同じとは限らないことです。ファイルの更新日時が新しくても、内容は古い行政区域のままということがあります。反対に、元データが新しくても、社内で加工したGeoJSONが更新されていなければ、実際に使っているデータは古いままです。ファイルの保存日時だけで判断せず、属性情報や管理メモにデータの基準日を残しておくと、後から確認しやすくなります。
現地の状況との差にも注意が必要です。行政区域データは、行政上の区域を表すものであり、現地で見える道路、河川、建物、造成地、仮設物、施工中の構造物と常に一致するわけではありません。開発中の地域、造成地、山間部、河川改修の周辺、道路新設の周辺では、現地の見た目と地図データの形状に差が出ることがあります。現地確認や施工管理に使う場合は、行政区域データを背景情報として扱い、必要に応じて現地で取得した座標、写真、測量結果と照合します。
区域判定の結果を業務判断に使う場合も、更新時期の確認が欠かせません。点検対象がどの自治体に属するか、調査対象がどの区域に含まれるか、現場写真をどの行政区域に紐づけるかといった処理では、データが古いと誤分類につながります。境界付近の点ほど影響を受けやすいため、境界近くの判定結果には注意を払う必要があります。
運用上は、行政区域データを更新する手順を決めておくことが大切です。新しいデータを入手し、形式を確認し、座標参照系を確認し、属性項目をそろえ、既存データとの差分を確認し、表示テストと区域判定テストを行い、利用者に切り替え時期を知らせる流れを標準化しておくと、更新時の混乱を減らせます。担当者ごとの手作業に依存すると、更新漏れや加工ミスが起きやすくなります。
過去データを扱う場合は、最新の行政区域データだけでよいとは限りません。過去の調査結果や点検履歴を当時の区域で管理したい場合、現在の区域に置き換えると意味が変わることがあります。市区町村合併や町名変更があった場合、過去の報告書と現在の地図が一致しないこともあります。履歴管理が必要な業務では、いつ時点の区域データで判定したのかを残しておくことが望ましいです。
GeoJSONの行政区域データは、差し替えや加工がしやすい反面、更新履歴を意識しないと混乱しやすい形式でもあります。ファイルを置き換えるだけで済むように見えても、実際には属性名、コード、ポリゴン構造、簡略化方法、分割方法、関連する台帳との結合条件にも影響します。更新時には、新しいファイルを置くだけでなく、既存業務への影響を確認することが必要です。
行政区域データを安全に運用するには、常に「このデータはいつ時点の、何を目的としたデータなのか」を説明できる状態にしておくことが重要です。現地の状況とデータ上の区域が異なる可能性を前提にし、境界付近の判断では追加確認を行う。これだけでも、GeoJSONを使った行政区域データ運用の信頼性は高まります。
まとめ
GeoJSONは、行政区域データを扱ううえで便利な形式です。座標と属性を一つのデータとして持てるため、地図表示、区域判定、集計、現地確認、資料作成など、さまざまな業務に応用できます。特に「geojson 使い方」を調べている実務担当者にとって、行政区域データは取り組みやすい題材です。しかし、便利で分かりやすいからこそ、画面に表示できた時点で正しいと判断してしまう危険もあります。
行政区域データを扱うときは、まずそのデータが厳密な境界そのものではなく、目的に応じて整備された地理データであることを理解する必要があります。表示用なのか、区域判定用なのか、集計用なのかによって、求められる精度や加工方法は変わります。次に、座標参照系と経度緯度の順番を確認し、他の現場データや台帳データと重ねたときにずれが出ないようにします。
行政区域のポリゴンは、単純な面だけではありません。離島、飛び地、穴あき領域、細かな境界、複数面など、複雑な構造を持つことがあります。表示確認だけでなく、区域判定や集計処理でも正しく扱えるかを確認する必要があります。データ量が大きい場合は、表示用と分析用を分け、操作性と正確性を両立させる工夫が求められます。
属性情報の整理も欠かせません。区域名だけに頼ると、表記ゆれや同名区域によって結合ミスが起きることがあります。行政区域コードや社内コードを活用し、名称、階層、更新時期を分かる形で管理することで、長期的に使いやすいデータになります。また、行政区域は変化するため、更新時期や現地状況との差を前提に、データの基準日と更新手順を管理することも重要です。
GeoJSONの行政区域データは、地図をきれいに表示するためだけのものではありません。現場の情報を区域単位で整理し、台帳や写真、点検記録、測量結果と結びつけることで、実務判断を支える基盤になります。一方で、境界付近の判断や高精度な位置管理が必要な場面では、行政区域データだけで完結させず、現地で取得した正確な座標情報や公式資料と組み合わせることが大切です。
行政区域データをGeoJSONで扱う際は、表示できることをゴールにせず、目的、座標、構造、容量、属性、更新時期を一つずつ確認しましょう。この6点を押さえておけば、地図表示だけでなく、集計、検索、区域判定、現地確認まで含めて、より安全にGeoJSONを活用できます。