top of page

14条地図GeoJSONをLeaflet表示する6つの実装手順

タイマーアイコン.jpeg
この記事は平均7分15秒で読めます
万能の測量機LRTKの説明

著者: LRTKチーム

14条地図GeoJSONをブラウザ上の地図に表示できるようにすると、筆界や地番に関する確認作業を、紙図面や静的な画像だけに頼らず進めやすくなります。特に、用地調査、現地確認、資料作成、関係者説明などでは、対象範囲を地図上で重ねて確認できることが利点になります。ただし、14条地図GeoJSONは、そのまま読み込めば必ず実務に使いやすい表示になるわけではありません。座標の扱い、属性、ポリゴン形状、表示縮尺、読み込み方法、現地資料との照合などを順に整える必要があります。この記事では、実務担当者が14条地図GeoJSONをLeaflet表示する際に押さえておきたい流れを、6つの実装手順として整理します。


目次

14条地図GeoJSON表示の前提を整理する

手順1:GeoJSONの中身と座標の扱いを確認する

手順2:表示用データとして軽く整える

手順3:地図画面の初期表示と読み込み方法を決める

手順4:ポリゴンの見た目と地番表示を調整する

手順5:クリック確認と属性表示を実装する

手順6:現地確認で使える運用形に仕上げる

まとめ:表示できる地図から使える現場資料へつなげる


14条地図GeoJSON表示の前提を整理する

14条地図GeoJSONを地図表示に使う前に、まず整理しておきたいのは、表示の目的です。単にブラウザ画面に図形を出すだけなら、GeoJSONを読み込んでポリゴンを描画するだけでも実現できます。しかし、実務で必要になるのは、地番を探しやすいこと、隣接筆との関係を確認しやすいこと、現地写真や調査メモと結び付けやすいこと、そして誤解を生みにくい資料として扱えることです。


ここでいう14条地図GeoJSONは、不動産登記法第14条第1項地図などの地図情報を、ブラウザ地図で扱いやすいGeoJSON形式にしたデータを想定しています。元データの取得方法、変換方法、収録範囲、属性項目はデータの作成元や加工手順によって異なるため、同じ名称で呼ばれていても中身が完全に同じとは限りません。実装前には、どの資料をもとにしたデータなのか、どの時点のデータなのか、どのような変換を経ているのかを確認しておく必要があります。


14条地図は、土地の位置や区画を確認するための重要な資料ですが、現地の利用状況や構造物の位置、境界標の有無をそのまま保証するものではありません。したがって、地図上に表示したからといって、現地確認や関係資料の照合が不要になるわけではありません。ブラウザ地図への表示は、調査の入口や確認作業の効率化に役立つものであり、最終判断の根拠を一つに固定するものではない、という前提を持つことが大切です。


GeoJSONは、点、線、面などの地物を座標と属性で扱える形式です。14条地図GeoJSONでは、土地の区画に相当するポリゴンや、それに付随する地番などの属性を扱うケースが多くなります。実装では、図形として正しく表示されることと、属性情報が実務で読める形になっていることの両方が必要です。ポリゴンが表示されても、どの筆なのか分からなければ確認作業には使いにくくなります。反対に、属性が残っていても、図形の位置や重なり方が分かりにくければ、現地説明や資料化で迷いが出ます。


また、地図表示では背景地図との重ね合わせを考えることが多くなります。ただし、背景地図や航空写真、道路図などは、それぞれ作成時期、精度、表現方法が異なります。14条地図GeoJSONと重ねたときに見た目がずれているように見えても、どちらか一方が必ず間違っているとは限りません。地図表示では、見た目の一致だけで判断せず、座標の扱い、データ作成時期、現地状況、既存資料を合わせて確認する姿勢が欠かせません。


実装の目的を決める際は、誰が、どの場面で、何を確認する画面なのかを明確にします。社内で地番を探すための簡易確認画面なのか、現地調査時に現在地周辺の筆を把握するための画面なのか、関係者への説明資料を作る前段階なのかで、必要な機能は変わります。実務では、最初から多機能にしすぎるよりも、地番検索、クリック確認、表示切替、メモ連携など、使う場面がはっきりした機能から整えるほうが安定します。


14条地図GeoJSONの表示は、技術的には地図描画の作業ですが、実務上は資料整理の作業でもあります。どのデータを表示しているのか、いつ取得したデータなのか、加工前のファイルを保存しているのか、加工時に属性を削っていないかといった管理が、後で効いてきます。表示できた段階で満足せず、元データ、加工済みデータ、表示用データの区別を付けておくことが、後戻りを防ぐ基本になります。


手順1:GeoJSONの中身と座標の扱いを確認する

最初の手順は、GeoJSONの中身を確認することです。ブラウザ地図に読み込む前に、ファイルの構造、地物の種類、座標の並び、属性の項目を把握しておきます。GeoJSONでは、面を表すPolygon、複数の面をまとめたMultiPolygon、線や点などが含まれる場合があります。14条地図GeoJSONとして取得または変換したデータでも、地域や変換条件によって属性項目の持ち方や図形のまとまり方が異なることがあります。


特に重要なのが座標の扱いです。GeoJSONの座標は、基本的に経度、緯度の順で記録されます。一方、Leafletでは地図上の位置指定に緯度、経度の順で扱う場面があるため、GeoJSONの座標配列とLeafletの緯度経度指定を混同しないことが重要です。また、測量や設計の実務では、平面直角座標系など、メートル単位で扱う座標に慣れていることがあります。この感覚の違いに気付かないまま実装すると、地図上に表示されない、極端に離れた位置に表示される、南北や東西の向きが想定と違う、という問題が起こります。


表示前には、GeoJSONの座標値が緯度経度として妥当な範囲にあるかを確認します。日本国内を想定するなら、経度と緯度の値が常識的な範囲に入っているかを見るだけでも、座標系の取り違えに気付きやすくなります。座標値が数万や数十万のような値で並んでいる場合は、メートル単位の座標である可能性があるため、そのままブラウザ地図に重ねるのではなく、表示用の座標へ変換する工程を挟む必要があります。


次に、属性項目を確認します。地番、所在、筆の識別に使う番号、面積に関する項目、更新や管理に関する項目など、どの情報が含まれているかを見ます。実装では、クリック時に見せる項目、ラベルとして表示する項目、検索に使う項目を分けて考えると整理しやすくなります。すべての属性を画面に出すと見づらくなり、必要な情報が埋もれてしまいます。反対に、表示用に削りすぎると、後から照合したいときに不足が出ます。


この段階では、元データに直接手を入れないことも重要です。元データは取得時点の状態を保管し、表示や軽量化のために加工する場合は、別ファイルとして扱います。実務で問題になりやすいのは、いつの間にか加工済みデータだけが残り、元の属性や図形を確認できなくなるケースです。ファイル名には、取得日、対象区域、加工内容、表示用か保管用かを分かるように入れておくと、後で迷いにくくなります。


図形の状態も確認しておきます。ポリゴンが閉じているか、極端に細い形や飛び地のような形が含まれていないか、同じ地番に複数の面が存在していないか、穴のあるポリゴンが含まれていないかを見ます。表示ライブラリ側で描画できる場合でも、データの形が複雑すぎると、クリック判定やラベル配置で扱いにくくなります。特に、多数の筆を一括表示する場合は、読み込み速度や操作感にも影響します。


14条地図GeoJSONをLeaflet表示する実装では、最初に画面作りへ進みたくなりますが、実際にはこの確認工程が後の安定性を左右します。座標が合っているか、属性が使えるか、図形が表示向きかを確認してから実装に入ることで、画面上の不具合を原因不明のまま追い続ける時間を減らせます。


手順2:表示用データとして軽く整える

次の手順は、GeoJSONを表示用データとして整えることです。14条地図GeoJSONは、対象範囲が広くなるほどファイルサイズが大きくなり、ブラウザ上での読み込みや操作が重くなることがあります。最初の検証では全データを読み込んでもよいですが、実務画面として使うなら、表示範囲や目的に合わせてデータを軽くすることを考える必要があります。


表示用データを整えるときは、まず対象範囲を絞ります。現場で必要なのが特定の町丁目や調査対象地の周辺だけであれば、広い区域を一括で読み込む必要はありません。必要以上に広いデータを読み込むと、初期表示に時間がかかり、地図の移動や拡大縮小も重くなります。現地調査用であれば、対象筆だけでなく周辺筆もある程度含めると隣接関係を確認しやすくなりますが、広げすぎると使い勝手が落ちます。


次に、属性項目を整理します。表示に必要な項目と保管用に残す項目を分け、画面用のファイルでは必要最小限に近づけます。たとえば、クリック表示に使う地番、区域名、管理上の識別子、メモ連携に使うキーなどは残し、画面上で使わない長い説明項目や内部的な項目は、表示用では省く判断もあります。ただし、後で原本と照合できるように、識別に必要な項目は必ず残します。見た目を軽くするために、照合キーまで削ってしまうと、運用段階で困ります。


図形の簡略化も検討します。ポリゴンの頂点数が多い場合、画面上では見た目に大きな差がない範囲で頂点を減らすことがあります。ただし、14条地図に関わる表示では、形状を不用意に簡略化すると、境界線の印象が変わるおそれがあります。実務資料として使う場合は、簡略化したデータを境界判断の根拠として扱わない、簡略化前のデータを必ず保管する、簡略化の有無を内部管理する、といった運用上の注意が必要です。


ファイルを分割する方法も有効です。ひとつの大きなGeoJSONを一括で読み込むのではなく、区域ごと、表示範囲ごと、縮尺ごとに分けることで、必要な部分だけを読み込めます。初期段階では単一ファイルで実装し、使う範囲が広くなった段階で分割を検討すると進めやすくなります。最初から複雑な読み込み構成にすると、実装や管理が難しくなるため、まずは小さな範囲で確実に動く形を作るのが現実的です。


文字コードや改行、ファイル名にも注意します。属性に日本語が含まれる場合、文字化けが起きると地番や区域名が読めなくなります。ローカル環境で見えていても、公開環境や別端末で文字化けすることがあります。表示用ファイルを作ったら、複数の環境で開いて、文字が正しく表示されるか確認しておくと安心です。ファイル名には日本語を使っても管理しやすい場合がありますが、読み込み時のパス指定で問題が出ないよう、半角英数字を中心にした管理名を併用すると安定します。


表示用データを整える目的は、元データを変えることではなく、地図画面で扱いやすくすることです。元データ、整形済みデータ、公開または共有用データを分けるだけで、作業の透明性が高まります。どの段階のデータを見ているのか分かるようにしておけば、表示のずれや属性の不足が見つかったときも、原因を追いやすくなります。


手順3:地図画面の初期表示と読み込み方法を決める

表示用データを用意したら、地図画面の初期表示を設計します。ここでは、画面を開いたときにどの位置を中心にするか、どの縮尺から始めるか、GeoJSONをいつ読み込むかを決めます。実務担当者向けの画面では、最初に対象区域が見えることが大切です。毎回、地図を大きく移動して対象地を探すような作りでは、現場や打合せで使いにくくなります。


初期表示の中心は、対象データの範囲から自動的に決める方法と、あらかじめ指定しておく方法があります。単一現場の確認画面なら、対象筆や対象区域が画面に収まるように固定しておくと分かりやすくなります。複数区域を扱う画面なら、読み込んだGeoJSONの外接範囲に合わせて自動調整するほうが便利です。ただし、自動調整に頼る場合でも、データに極端に離れた図形が含まれていると、縮尺が広がりすぎて対象地が小さく表示されることがあります。


読み込み方法は、画面に直接データを埋め込む方法と、別ファイルとして読み込む方法に分けられます。検証や小規模なサンプルでは、画面内にデータを直接入れても動作確認できます。しかし、実務で扱う場合は、GeoJSONを別ファイルとして管理するほうが更新しやすくなります。地図画面のコードと地図データを分けておけば、対象区域の差し替えや属性修正を行うときに、画面全体を触らずに済みます。


別ファイルとして読み込む場合は、ファイルの置き場所とアクセス方法を整理します。社内だけで使うのか、現場端末からも見るのか、通信環境が不安定な場所で使うのかによって、構成は変わります。通信環境が前提になる画面では、現地で読み込めないと使えません。現地確認で使うなら、事前に必要なデータを端末側へ保存しておく運用や、軽量な範囲データを用意する運用も検討します。


初期表示では、背景の見せ方も重要です。筆界ポリゴンだけを表示すると、区画の関係は見えますが、道路、建物、河川、造成地などの現地感が分かりにくくなります。一方で、背景情報が濃すぎると、14条地図GeoJSONの線や地番が埋もれます。背景はあくまで位置を把握する補助とし、表示対象のポリゴンが読みやすい線幅や透過度になるよう調整します。背景地図の利用条件やクレジット表記が必要な場合は、実装時に確認しておくことも大切です。


また、初期表示時にすべての地番ラベルを出すかどうかも考えます。広い範囲で全ラベルを表示すると、文字が重なって読みにくくなり、画面操作も重くなります。実務では、一定以上に拡大したときだけ地番を表示する、クリックした筆だけ属性を表示する、検索した地番を強調する、といった方法が使いやすくなります。最初からすべてを出すより、必要なときに必要な情報を出す設計が向いています。


地図画面は、表示の入口です。入口が分かりにくいと、後でどれだけ機能を足しても使われにくくなります。画面を開いた瞬間に対象区域が見え、ポリゴンが読みやすく、地番確認へ自然に進める状態を目指すことが、実装の土台になります。


手順4:ポリゴンの見た目と地番表示を調整する

GeoJSONが地図上に表示できたら、次は見た目の調整です。14条地図GeoJSONの主な表示対象は、土地の区画を表すポリゴンです。線の太さ、塗りの透明度、選択時の表示、隣接筆との境界の見え方を整えることで、確認作業のしやすさが大きく変わります。


まず、通常表示の線は、細すぎず太すぎない設定にします。線が細すぎると、背景に埋もれて見えにくくなります。線が太すぎると、隣接する筆界がつぶれて見えたり、実際の位置よりも強い境界線として印象付けられたりします。塗りは薄く透過させ、背景との関係を見ながら区画の面が分かる程度にします。塗りを濃くしすぎると、道路や建物の位置関係が見えにくくなります。


次に、選択時や検索時の強調表示を決めます。クリックした筆、検索で一致した筆、調査対象として指定した筆は、通常表示と違う見た目にすると確認しやすくなります。強調表示では、線を少し太くする、塗りを少し濃くする、周囲より前面に出すなどの方法があります。ただし、強調しすぎると隣接関係が分かりにくくなるため、対象筆を目立たせながら周辺筆も読めるバランスが大切です。


地番表示は、実務で特に使われる部分です。地番をポリゴンの中央付近に出すと分かりやすいですが、細長い筆や複雑な形の筆では、文字が外に出たり、隣の筆に重なったりすることがあります。広域表示では文字を出さず、拡大時に表示する方法が無難です。また、地番が長い場合や枝番が多い区域では、ラベルが密集しやすくなります。常時表示よりも、クリック時表示や検索結果表示を中心にしたほうが見やすいこともあります。


ポリゴンの重なりや隙間も確認します。GeoJSON上の図形が正しくても、画面上の描画順や線幅によって、重なって見えることがあります。隣接筆の境界線が二重に見える場合や、同じ場所に複数の面が重なっているように見える場合は、データの持ち方と描画順の両方を確認します。表示上の問題なのか、データ自体の問題なのかを分けて考えることが重要です。


色の使い方は、後の資料化にも影響します。調査対象、隣接地、確認済み、要確認、除外など、状態を色で分ける場合は、意味を増やしすぎないようにします。画面上では便利に見えても、色の種類が多すぎると関係者に説明しにくくなります。実務画面では、通常表示、選択表示、注意表示、確認済み表示くらいに整理すると、誤解が少なくなります。


見た目の調整では、画面上で美しく見えることだけを目標にしないことが大切です。14条地図GeoJSONの表示は、土地の位置関係を確認するためのものです。境界線を強く見せすぎると、現地での確定的な線のように受け取られる可能性があります。資料として使う場合は、表示は確認補助であり、現地や関係資料との照合が必要であることを説明文や運用ルールで補うと安全です。


手順5:クリック確認と属性表示を実装する

ポリゴンの見た目を整えたら、次はクリック確認と属性表示を実装します。14条地図GeoJSONを実務で使う場合、地図上の筆をクリックして、地番や所在などの属性を確認できることが重要です。単に図形を見るだけでは、地図に詳しい人以外が使いにくく、資料確認のたびに別ファイルを開く手間も残ります。


クリック時に表示する情報は、必要な項目に絞ります。地番、所在、識別番号、調査メモ、確認状態など、作業に直結する項目を中心にします。属性が多い場合でも、すべてを一度に表示すると見づらくなります。基本情報を先に見せ、詳細は必要に応じて展開する設計にすると、画面が整理されます。現場で使う場合は、長い文章よりも、短く読み取れる項目名と値の組み合わせが向いています。


クリック判定では、細いポリゴンや小さな筆を選びやすくする工夫が必要です。都市部や細分化された区域では、筆が小さく、指やマウスで正確に選ぶのが難しいことがあります。拡大時にクリックしやすくする、選択した筆を強調する、直前に選択した筆の情報を固定表示するなど、操作ミスを減らす仕組みが役立ちます。現場端末で使う場合は、画面サイズが小さいことも考慮します。


属性表示では、元データの表記ゆれにも注意します。同じ意味の項目でも、データによって項目名が異なる場合があります。画面側で表示名を統一し、利用者には分かりやすい名称で見せると混乱が減ります。ただし、元データの項目名や値を完全に消してしまうと、照合が難しくなる場合があります。必要に応じて、内部的な識別子や元項目名を保持しておくと安心です。


検索機能を組み合わせると、さらに使いやすくなります。地番や区域名で検索し、一致した筆を地図上で強調表示できれば、広い範囲の中から対象地を探しやすくなります。検索では、完全一致だけでなく、枝番を含む表記、全角半角、空白の有無などに気を付ける必要があります。実務では、手元資料に書かれた地番の表記と、GeoJSON属性の表記が完全に一致しないこともあります。検索条件を少し柔軟にするだけで、作業性が上がります。


クリック確認にメモ機能を連携する場合は、元のGeoJSONを直接書き換えるか、別の管理データとして保存するかを検討します。簡易な確認画面では、表示だけに留めるほうが安全です。確認済み、要確認、写真あり、現地未確認などの状態を持たせたい場合は、表示用GeoJSONとは別に作業記録を管理し、識別子でひも付ける方法が扱いやすくなります。これにより、元データの改変を避けながら、現場作業の記録を蓄積できます。


属性表示の目的は、地図と台帳的な情報をつなぐことです。見た目の地図だけでは分からない情報を、クリック操作で確認できるようにすることで、調査担当者、設計担当者、管理担当者の間で認識を合わせやすくなります。特に、地番を起点に資料を探す業務では、クリック確認の品質がそのまま作業効率に影響します。


手順6:現地確認で使える運用形に仕上げる

最後の手順は、地図表示を現地確認で使える運用形に仕上げることです。ブラウザ上で14条地図GeoJSONを表示できても、実務の中で継続して使うには、更新、共有、確認記録、注意書き、端末対応を考える必要があります。実装が完成したように見える段階こそ、運用面の詰めが重要になります。


まず、データ更新の流れを決めます。14条地図GeoJSONを差し替えるとき、誰が取得し、誰が表示用に整え、誰が画面に反映し、誰が確認するのかを決めておきます。更新のたびに手順が変わると、古いデータを見続けたり、属性が欠けたデータを使ったりするリスクが高まります。更新日、対象区域、加工内容、確認者を記録するだけでも、運用の信頼性は上がります。


次に、表示画面に注意書きを入れることを検討します。14条地図GeoJSONの表示は、現地確認や資料照合を支援するものです。境界の最終判断や権利関係の判断を画面表示だけで行うものではない、という説明を画面内や資料出力時に添えると、誤解を防ぎやすくなります。地図表示は分かりやすいため、利用者が見た目だけで判断してしまうことがあります。だからこそ、補助資料としての位置付けを明確にしておく必要があります。


端末対応も確認します。事務所の大きな画面では見やすくても、現場の小さな端末では地番が読みにくい、クリックしにくい、画面が重いということがあります。現地で使うなら、拡大縮小のしやすさ、選択情報の見やすさ、通信が不安定な場合の動き、屋外での視認性を確認します。地図画面は、作った環境では快適でも、実際に使う環境では不便になることが珍しくありません。


共有範囲も整理します。社内の確認用なのか、協力会社との共有用なのか、関係者説明のための閲覧用なのかで、表示する属性や操作機能を変えるべき場合があります。すべての情報を全員に見せるのではなく、目的に応じて表示項目を分けることが望ましいです。特に、個別案件のメモや内部確認状況を含める場合は、共有前に内容を確認する運用が必要です。


現地写真や点検記録とつなげる場合は、地図上の筆と写真の位置関係をどう扱うかを決めます。写真に位置情報がある場合でも、撮影位置と対象物の位置は一致しないことがあります。道路上から隣接地を撮影した写真、離れた場所から全景を撮影した写真、対象筆の内部で撮影した写真では、意味が異なります。地図上に写真を重ねる場合は、撮影位置、対象筆、確認内容を分けて管理すると誤解が少なくなります。


また、表示速度の確認も欠かせません。対象区域が増えると、最初は軽快だった画面が徐々に重くなることがあります。読み込みが遅いと、現地では使われなくなります。区域分割、必要時読み込み、ラベル表示の制御、属性項目の整理などを組み合わせ、実際に使う端末で操作感を確認します。実務では、機能が多い画面よりも、必要な確認がすぐできる画面のほうが使われます。


運用形に仕上げる段階では、画面だけで完結させようとしないことも大切です。14条地図GeoJSONの表示画面は、資料管理、現地写真、調査メモ、報告書作成とつながって初めて効果を発揮します。表示画面で確認した内容を、どのように記録し、誰に共有し、どの資料へ反映するかまで決めておくことで、単なる地図ビューアではなく、調査業務の入口として活用できます。


まとめ:表示できる地図から使える現場資料へつなげる

14条地図GeoJSONをLeaflet表示する実装では、GeoJSONを読み込んでポリゴンを描画するだけでなく、座標、属性、表示範囲、見た目、クリック確認、運用管理を順番に整えることが重要です。最初にデータの中身と座標を確認し、表示用に軽く整え、地図画面の初期表示と読み込み方法を決めます。そのうえで、ポリゴンの線や塗り、地番ラベル、選択時の見せ方を調整し、クリックによる属性確認や検索機能を加えると、実務で扱いやすい画面になります。


一方で、地図上にきれいに表示できたとしても、それだけで現地状況や境界に関する判断が完結するわけではありません。14条地図GeoJSONは、確認作業を効率化するための有効なデータですが、現地写真、既存資料、境界標の有無、関係者からの情報などと合わせて確認する必要があります。表示画面には、補助資料としての位置付けを明確にし、更新日や加工内容を管理することが大切です。


実装を進めるときは、小さな対象範囲で確実に表示し、属性確認と操作性を整えてから、区域拡大や機能追加に進むと失敗しにくくなります。最初から広範囲、多機能、高精度な画面を目指すと、座標ずれ、表示の重さ、属性不足、運用ルールの未整理が同時に起こりやすくなります。まずは、対象筆を見つける、周辺筆を確認する、クリックで地番を読む、現地メモと照合するという基本動作を安定させることが現実的です。


14条地図GeoJSONの活用は、机上の資料確認だけでなく、現地確認との接続で価値が高まります。現場で撮影した写真、位置情報、調査メモを地図上の筆や確認地点と結び付けられれば、後からの整理や報告が楽になります。ブラウザ地図で筆界や地番を確認し、現地で取得した情報を記録できる流れを作ることで、用地調査や確認作業の手戻りを減らしやすくなります。


現地での写真記録や位置情報の取得まで含めて運用を整えたい場合は、スマートフォンや現地調査用アプリ、写真管理ツール、位置情報記録ツールなどを組み合わせる方法も検討できます。14条地図GeoJSONの表示で対象範囲を把握し、現地で取得した写真やメモを識別子や位置情報とひも付ける流れにすると、地図確認から現場記録、報告資料作成までをつなげやすくなります。


LRTKで現場の測量精度・作業効率を飛躍的に向上

LRTKシリーズは、建設・土木・測量分野における高精度なGNSS測位を実現し、作業時間短縮や生産性の大幅な向上を可能にします。国土交通省が推進するi-Constructionにも対応しており、建設業界のデジタル化促進に最適なソリューションです。

LRTKの詳細については、下記のリンクよりご覧ください。

 

製品に関するご質問やお見積り、導入検討に関するご相談は、

こちらのお問い合わせフォームよりお気軽にご連絡ください。ぜひLRTKで、貴社の現場を次のステージへと進化させましょう。

bottom of page