14条地図GeoJSONをPMTiles化したい実務担当者の多くは、「地番ポリゴンを広域で軽く表示したい」「現地調査や不動産調査の下調べでブラウザ閲覧しやすくしたい」「大量のGeoJSONを地図配信用データとして扱いやすくしたい」という課題を持っています。PMTilesはタイル化されたデータを単一ファイルとして扱える形式で、ブラウザ地図で必要な範囲を読み込みやすくする有力な選択肢です。([Protomaps Documentation][1])
ただし、PMTiles化は元データの位置精度や属性品質を自動的に改善する工程ではありません。法務省が一般公開している登記所備付地図データは、不動産登記法第14条第1項の地図だけでなく、同条第4項の「地図に準ずる図面」に係る電子データも含むものとして説明されています。公開データは利活用を目的とするもので、地図証明書・図面証明書に代替するものではありません。([法務省][2])
そのため、14条地図GeoJSONをPMTiles化する前には、変換コマンドを実行する前の設計が重要です。準備が不足していると、背景地図とのずれ、属性欠落、ファイル肥大化、更新しにくいファイル構成、現地で使いにくい閲覧画面といった問題が起きやすくなります。本記事では、geojson 14条地図で検索している実務担当者向けに、14条地図GeoJSONをPMTiles化する前に確認すべき5つの準備を、公開・運用まで見据えて解説します。
14条地図GeoJSONをPMTiles化する前に押さえるべき前提
本記事では便宜上「14条地図GeoJSON」と表現しますが、実務ではまず元データの由来を確認する必要があります。法務省の登記所備付地図データそのものは地図XMLフォーマットで公開され、GeoJSONやシェープファイルとして利用する場合は、変換済みデータを取得するか、自身で変換することになります。G空間情報センターの変換済みGeoJSON・シェープファイルは、法務省提供データを既存ツールで機械的に変換したもので、公共座標系が付与された図郭のみを変換していること、内容・品質は保証できないことが明記されています。([G空間情報センター][3])
この前提を押さえないままPMTiles化すると、「GeoJSONなので地図に正しく重なるはず」「PMTilesにすれば軽く正確に表示できるはず」といった誤解につながります。PMTilesは地図タイルを扱いやすくするための保存・配信形式であり、元データの座標、属性、図形の妥当性を保証するものではありません。PMTilesの公式ドキュメントでも、PMTilesはZ/X/Yで参照されるタイルデータの単一ファイル形式であり、HTTP Range Requestsにより必要な部分を取得できる形式として説明されています。([Protomaps Documentation][1])
また、PMTilesは閲覧・配信に向いた成果物であって、属性を後から自由に編集する作業用データではありません。公式ドキュメントはPMTilesを読み取り専用形式とし、アーカイブをインプレースで更新することはできず、更新には全体の再書き込みが必要だと説明しています。([Protomaps Documentation][1]) つまり、PMTiles化の前に属性名、レイヤ構成、ズーム設計、分割単位を決めておくことが、公開後の使いやすさを左右します。
特に注意したいのは、14条地図と地図に準ずる図面が同じ文脈で扱われやすい点です。デジタル庁の変換コンバータ説明では、公共座標系のデータは経度・緯度へ換算される一方、任意座標系のデータは座標値の換算をしないとされています。また、地図に準ずる図面は相対的な座標を持つものの、実世界の位置座標を持たないため、GeoJSONに変換してもGIS上の地図に重ねて表示することはできないと説明されています。([デジタル庁][4])
したがって、PMTiles化の準備とは、単に作業フォルダや変換ツールを用意することではありません。元データの範囲、座標の性質、属性の使い方、図形品質、公開・更新手順を先に整理し、「表示できたが実務では使いにくい」という状態を避けるための工程です。
準備1：利用目的とタイル設計を決める
最初に決めるべきことは、14条地図GeoJSONをPMTiles化して何に使うのかです。同じ地番ポリゴンでも、庁内確認用、現地調査用、住民向け閲覧用、開発候補地の調査用、不動産関連業務の下調べ用では、必要なズーム、属性、表示速度、検索性が異なります。目的が曖昧なまま変換すると、すべての情報を残そうとしてファイルが重くなったり、逆に軽量化しすぎて必要な地番が確認しにくくなったりします。
たとえば、広域で土地の分布や地番のおおまかな位置を見たい場合、低いズームでは筆ごとの細かい形状をすべて表示しなくても足りることがあります。市区町村全体を俯瞰する段階では、境界線を細かく描画するよりも、対象地域の広がりを軽く表示できることが重要です。一方、現地で特定の筆を確認する用途では、拡大した段階で筆界線と地番が読み取れる必要があります。つまり、ズームごとに何を見せるかを事前に決めることが、PMTiles化の第一歩です。
タイル設計では、最小ズームと最大ズームの考え方が重要です。最大ズームを高くすれば細部まで表示しやすくなりますが、タイル数やデータ量、変換時間は増えやすくなります。14条地図GeoJSONは細かなポリゴンを多く含むため、必要以上に高いズームまで詳細なデータを持たせると、閲覧側の描画負荷も高くなります。反対に、最大ズームを低くしすぎると、筆界や地番の確認が難しくなり、詳細確認には使いにくくなります。
地番ラベルをどう表示するかも、タイル設計に関わります。ポリゴンだけをタイル化する場合と、地番表示用の代表点や簡略なラベル用レイヤを別に用意する場合では、データ構造が変わります。ポリゴンの属性から画面上で地番を表示することもできますが、密集地ではラベルが重なりやすく、常時表示するとかえって読みにくくなります。地番検索を重視するなら、PMTiles内の表示用属性とは別に検索用の索引を用意する設計も検討できます。
利用者の端末も想定しておく必要があります。庁内のPCで見るだけなのか、現地でスマートフォンやタブレットから見るのか、通信環境が安定している場所で使うのかによって、許容できるファイルサイズや描画負荷は変わります。現地利用を想定するなら、見た目の美しさだけでなく、読み込みの安定性、タップ時の属性表示、現在地との重ね合わせ、必要な範囲だけを素早く確認できることが重要です。
この段階で、対象範囲も明確にします。全国、都道府県、市区町村、業務対象エリアのどれをPMTiles化するのかによって、設計は大きく変わります。最初から広域全体を作ろうとすると、検証に時間がかかり、問題の原因も追いにくくなります。実務では、代表的な市街地、山間部、筆数が多い地域、データが複雑な地域を選び、小さな範囲で試作してから本番範囲へ広げる進め方が安全です。
準備2：座標系と位置精度の扱いを確認する
14条地図GeoJSONをPMTiles化する前に、座標系の確認は必須です。一般的なGeoJSON仕様では、座標参照系としてWGS 84、単位として10進度が用いられるとされています。([IETF Datatracker][5]) しかし、登記所備付地図データ由来のGeoJSONを扱う場合は、どの変換手順で作られたGeoJSONか、元の図面が公共座標系か任意座標系かを確認しなければなりません。
公共座標系のデータであれば、適切な変換を経ることで一般的なWeb地図上に重ねられます。一方、任意座標系の図面は、図形としての形状は持っていても、実世界の正確な位置に対応しているとは限りません。デジタル庁のコンバータ説明でも、地図に準ずる図面は実世界の位置座標を持たないため、GeoJSON形式に変換してもGISで地図上に重ねて表示できないとされています。([デジタル庁][4]) 表示できることと、位置が正しいことは別問題です。
座標系を確認する際は、まずデータの入手元と変換条件を確認します。G空間情報センターの変換済みGeoJSONを使うのか、地図XMLから自前で変換したGeoJSONを使うのかで、確認すべき点は異なります。変換済みデータを使う場合でも、機械変換であり品質保証はされていないこと、出典明記が求められていることを前提に、配信前の目視確認を行います。([G空間情報センター][3]) 自前変換の場合は、公共座標系の系番号、測地系、座標軸、変換先の座標系を記録しておくことが重要です。
次に、既知の道路、河川、公共施設、行政界付近、筆界が明確な場所などと重ね、目視で大きなずれがないかを確認します。数値上は変換できていても、変換設定、座標軸の扱い、元データの性質によって、想定外のずれが出ることがあります。市街地、農地、山林、海岸部、行政界付近など、地物の密度や地形条件が異なる場所で確認すると、問題に気づきやすくなります。
位置精度については、利用者に過度な期待を持たせない設計も必要です。法務省は、公開データは法務局の証明機能を有するものではなく、地図証明書・図面証明書の代替ではないと説明しています。([法務省][2]) したがって、閲覧システムで利用者に見せる場合は、データの抽出時点、精度の限界、利用上の注意、正式な証明が必要な場面では法務局の証明書等を確認すべきことを明示しておくと安全です。
座標系の準備では、変換前のGeoJSON、変換後の中間データ、PMTiles化後の表示結果を同じ確認地点で比較できるようにしておくと便利です。どの段階でずれが発生したのかを追えるため、原因切り分けが容易になります。PMTiles化は最終成果物を作る工程ですが、座標系の問題は最初の段階で見つけるほど修正しやすくなります。
準備3：属性項目と地番情報の見せ方を整理する
14条地図GeoJSONをPMTiles化するとき、図形だけでなく属性をどう扱うかが実務上の使いやすさを大きく左右します。地番ポリゴンは、境界線が見えるだけでは十分でないことが多く、利用者はクリックやタップによって地番、所在に関係する文字列、図面の種別、管理用の識別子、更新確認に必要な情報などを確認したいと考えます。ただし、元のGeoJSONに含まれる属性をすべてそのままタイルに入れると、ファイルサイズが増え、通信量や描画負荷が大きくなります。
まず行うべきことは、属性項目の棚卸しです。GeoJSONの各フィーチャにどのようなキーがあり、どの項目が実務に必要で、どの項目が内部処理用なのかを整理します。地番表示に必要な項目、検索に必要な項目、クリック時に表示したい項目、将来の更新や照合に必要な項目は、それぞれ役割が異なります。表示には不要でも、元データとの突合や差分確認に使う識別子は残しておいたほうがよい場合があります。
属性名の統一も重要です。複数地域の14条地図GeoJSONを扱う場合、同じ意味の項目でも名称や値の入り方が異なることがあります。地番に相当する項目、所在地を示す項目、図郭や管理単位を示す項目などが地域や変換過程によって異なると、PMTiles化後の表示や検索処理が複雑になります。変換前に属性名を統一し、空欄や異常値の扱いを決めておくと、閲覧画面の実装が安定します。
地番の見せ方では、表記ゆれへの対応が欠かせません。地番には親番、枝番、複数筆、符号、補助的な表記が含まれることがあります。検索利用を想定するなら、画面に表示する地番と、検索に使う正規化済みの地番を分けて持つことも検討できます。表示用には元の表記を尊重し、検索用には余分な空白、全角半角、ハイフン、枝番表記の違いを吸収した値を用意するという考え方です。
クリック時に表示する属性は、少なすぎても多すぎても使いにくくなります。現地調査や不動産調査で最初に必要なのは、対象地番を素早く確認できることです。画面上に内部コードや長い管理項目が大量に出ると、利用者は何を見ればよいかわからなくなります。閲覧用には、地番、所在を示す情報、データの種別、データ作成・抽出・更新に関する情報、注意事項への導線など、判断に役立つ項目に絞るとよいでしょう。
属性を削減するときは、後から必要になりそうな項目まで消してしまわないよう注意します。PMTilesは閲覧に向いた配信用成果物であり、元データの完全な保管先として使うものではありません。元のGeoJSONや正規化済みの中間データは別に保管し、PMTilesには閲覧と操作に必要な属性を入れるという役割分担が有効です。元データ、加工済みデータ、配信用データを分けて管理すれば、将来の再生成や更新にも対応しやすくなります。
準備4：ジオメトリの品質とデータ容量を点検する
14条地図GeoJSONはポリゴン数が多く、境界線も細かくなりやすいため、PMTiles化の前にジオメトリの品質を点検する必要があります。不正な形状、自己交差、極端に小さなポリゴン、穴の扱いの不整合、重複した頂点、閉じていないリングなどが含まれていると、変換中にエラーが出たり、タイル化後に表示が欠けたりすることがあります。変換ツールが自動的に補正する場合もありますが、補正結果が実務上正しいとは限りません。
まず確認したいのは、GeoJSONとして機械的に読み込めるかどうかです。ファイルが大きい場合、テキストとして開けることと、地理データとして正しく読み込めることは別です。文字コード、改行、座標配列、属性値の型、FeatureCollectionの構造、フィーチャ数などに問題があると、PMTiles化以前の段階で処理が止まることがあります。複数ファイルを一括処理する場合は、代表ファイルだけでなく全体を機械的に点検することが大切です。
次に、ポリゴンの複雑さを確認します。筆界は細かな折れ点を多く含むことがあり、そのままタイル化するとデータ量が増えます。ズームアウト時には細部まで描画しても視認できないため、低いズームでは形状を簡略化する設計が有効です。ただし、簡略化を強くかけすぎると、細長い筆が見えにくくなったり、隣接する筆との見た目の関係が変わったりすることがあります。地番確認では境界線の見え方が判断に影響しやすいため、簡略化はサンプル地域で確認しながら調整します。
データ容量の点検では、ファイル全体の大きさだけでなく、地域ごとの偏りを見ることが重要です。市街地や密集した住宅地では筆数が多く、ポリゴンも細かくなります。一方、山林や農地では一筆が大きい場合もあり、表示密度が異なります。全体の平均だけを見ていると、特定の地域だけタイルが重くなり、閲覧時に読み込みが遅くなることがあります。変換前に、フィーチャ数、頂点数、属性量を地域別に把握しておくと、重い場所への対策を立てやすくなります。
重複や隙間の扱いも確認しておきます。隣接するポリゴンが完全に接していない、同じ地番らしきポリゴンが重複している、行政界付近でデータが二重に見えるといった現象は、元データ、変換処理、結合処理のいずれかに由来します。PMTiles化後はタイル境界をまたいで表示されるため、元データの不整合とタイル化による見え方の問題を混同しやすくなります。可能な限り、元GeoJSONの段階で確認しておくことが大切です。
また、地番ポリゴンは面データとして表示するだけでなく、境界線を強調して見せることが多いです。その場合、ポリゴンの塗り、線の太さ、線の色、選択時のハイライトなどの表現が必要になります。PMTiles化そのものはデータ作成工程ですが、最終的なスタイルを想定しておかなければ、必要なレイヤ分けや属性が不足することがあります。ポリゴン用レイヤ、境界線表示用レイヤ、ラベル用レイヤを分けるかどうかも、データ容量と表示品質に関わる判断です。
品質点検は、完璧なデータを作るためだけの工程ではありません。どの程度の不整合を許容し、どの問題は公開前に修正し、どの問題は注意書きや運用で補うのかを決めるための工程です。14条地図GeoJSONは実務上価値の高いデータですが、利用目的に応じた品質管理をしなければ、見た目だけ整った扱いにくい地図になってしまいます。
準備5：配信範囲、更新手順、閲覧環境を固める
PMTiles化の前に、配信範囲と更新手順を決めておくことも重要です。PMTilesは単一ファイルとして扱いやすい反面、更新単位を誤ると運用が重くなります。広域を一つのファイルにまとめると管理は単純に見えますが、一部地域だけ更新したい場合でも大きなファイルを再生成し、差し替える必要が出ることがあります。公式ドキュメントでも、PMTilesはアーカイブをインプレースで更新できない読み取り専用形式として説明されています。([Protomaps Documentation][1])
現実的には、業務の更新単位に合わせて分割を考えるのが安全です。市区町村単位で利用するなら市区町村ごと、都道府県単位で管理するなら都道府県ごと、現場案件ごとに使うなら案件範囲ごとにPMTilesを作る設計が考えられます。重要なのは、閲覧時の軽さだけでなく、再生成、差し替え、確認、公開停止、過去版の保管まで見据えることです。PMTilesファイル名やフォルダ構成にも、地域コード、作成日、データ版、用途がわかる規則を持たせておくと、後から混乱しにくくなります。
更新手順では、元データの取得日、抽出時点、変換条件、属性加工の内容、除外したデータ、座標変換の条件、タイル生成時の設定を記録します。担当者が変わったときに同じ成果物を再現できなければ、運用は不安定になります。法務省の公開データは特定時点で抽出された情報であるため、利用者向けにデータ時点を示すことも重要です。([法務省][2])
出典表示と利用条件も確認します。G空間情報センターの変換済みデータページでは、登記所備付地図データを利用する場合の出典明記について記載されています。([G空間情報センター][3]) さらに、法務省は公開データについて、利用規約に抵触しない範囲で利用でき、ダウンロード時に利用規約を確認して同意することになると説明しています。([法務省][2]) 一般公開や外部共有を行う場合は、出典、データ時点、注意事項を閲覧画面や配布資料に明示しておくと安全です。
閲覧環境の確認も欠かせません。PMTilesを表示する地図ビューアでは、背景地図、ズーム制御、レイヤ切り替え、属性ポップアップ、地番検索、現在地表示、選択中の筆のハイライトなど、利用目的に応じた機能が必要になります。PMTilesファイルが正しく生成できても、閲覧画面で必要な操作ができなければ実務には使えません。変換前に閲覧画面の要件を決め、サンプルデータで確認しながらPMTilesの中身を調整するのが安全です。
現地利用を想定する場合は、通信環境と端末性能の確認が特に重要です。屋外では通信が不安定になることがあり、建物の影や山間部では読み込みに時間がかかることもあります。データが重いと、現在地を表示しながら地番ポリゴンを操作するだけで端末に負荷がかかります。PMTiles化によって配信効率は上げられますが、端末側の描画負荷が消えるわけではありません。筆界線を表示するタイミング、地番ラベルの出し方、タップ時に取得する属性量などを調整し、現地での操作感を確認する必要があります。
権限管理や公開範囲も整理しておきます。庁内や社内の限定利用なのか、関係者のみが閲覧するのか、一般公開を想定するのかで、表示する属性や注意書きが変わります。地番情報は業務上有用ですが、利用者が誤解しないよう、データの性質、更新時点、利用上の制約を明示することが大切です。公開範囲が広いほど、表示速度だけでなく、説明責任や問い合わせ対応まで含めた運用設計が必要になります。
PMTiles化で失敗しないための運用チェック
ここまでの5つの準備を踏まえると、14条地図GeoJSONのPMTiles化は、技術的な変換作業というよりも、地図データを実務利用に合わせて整える工程だとわかります。失敗しやすいパターンは、元データをそのまま変換し、表示できた時点で完了としてしまうことです。画面上に筆界が表示されると成果が出たように見えますが、実際には座標のずれ、属性の不足、ズーム時の重さ、検索できない地番、更新しにくいファイル構成など、運用段階で問題が表面化することがあります。
PMTiles化前のチェックでは、まず小さな範囲で試作し、表示、検索、属性確認、現地利用を一通り試すことが重要です。対象地域の中でも、筆数が多い場所、境界が複雑な場所、山林や農地が多い場所、行政界に近い場所を含めると、問題を見つけやすくなります。軽い地域だけで試作すると、本番データで急に重くなったときに原因を追いにくくなります。
次に、元GeoJSONとPMTiles化後の表示結果を比較します。変換後の地図だけを見ていると、元からある問題なのか、変換で生じた問題なのかを判断できません。元データの段階で筆界がどう見えていたか、属性がどう入っていたか、座標がどの位置にあったかを確認できる状態にしておくと、トラブル対応がしやすくなります。変換設定を変更した場合も、前回成果物と比較し、ファイルサイズ、表示速度、見た目、属性の変化を確認します。
閲覧側のスタイルも、PMTiles化の成果を左右します。線を太くしすぎると密集地で境界がつぶれ、薄くしすぎると現地で見えにくくなります。塗りを強くすると背景地図が読みにくくなり、透明にしすぎると選択状態がわかりにくくなります。地番ラベルは便利ですが、広域表示で常に出すと画面が文字で埋まり、操作性が落ちます。ズームに応じて表示内容を切り替える前提で、データとスタイルを合わせて設計することが重要です。
PMTilesを作成した後は、成果物だけでなく作成過程を残すことが大切です。元データの保存場所、加工済みGeoJSON、属性定義、除外条件、座標変換条件、タイル生成設定、確認結果をまとめておけば、後日同じ作業を繰り返せます。特に14条地図GeoJSONは、地域ごとにデータ量や属性の状況が異なるため、属人的な手作業で整えると再現が難しくなります。業務で継続利用するなら、手順書化と自動化を視野に入れるべきです。
注意したいのは、PMTiles化を最終目的にしないことです。PMTilesは地図データを配信しやすくする形式であり、利用者に価値を届けるための手段です。実務担当者にとって本当に必要なのは、対象地番を素早く探せること、現在地や周辺地物と照らして確認できること、必要な属性を誤解なく読めること、更新時にも同じ品質を保てることです。変換が成功したかどうかだけでなく、業務の現場で判断に使えるかどうかを基準に確認しましょう。
まとめ：現地で使える14条地図活用へつなげる
14条地図GeoJSONをPMTiles化する前には、利用目的、座標系、属性、ジオメトリ品質、配信運用の5つを整理することが重要です。これらを先に決めておけば、変換後の表示速度や操作性だけでなく、検索しやすさ、更新しやすさ、現地での確認しやすさまで改善しやすくなります。反対に、準備を飛ばして変換だけを急ぐと、PMTilesファイルは作れたものの、地番が探しにくい、背景地図とずれる、属性が足りない、重くて現場で開けない、更新のたびに手戻りが出るといった問題につながります。
実務で14条地図GeoJSONを扱う場合、まずは小さな範囲で試作し、座標の重なり、属性表示、地番検索、ズームごとの見え方、端末での操作感を確認するのがおすすめです。そのうえで、対象範囲を広げ、データの分割単位や更新手順を固めていくと、安定した運用に近づきます。PMTiles化は大量の地番ポリゴンを軽く扱うための有効な方法ですが、成果物の品質は変換前の設計に大きく左右されます。
特に現地調査で使う場合は、地図データだけでなく、現地の位置情報、写真、調査メモ、測量成果、正式な証明資料とどう突き合わせるかが重要になります。14条地図GeoJSONをPMTiles化して閲覧性を高めることは、机上確認と現地確認をつなぐ第一歩です。ただし、公開データの性質や精度の限界を明示し、必要に応じて法務局の証明書や現地確認と併用することで、実務で誤解の少ない地図活用につなげられます。