GeoJSONは、地物の位置や形状を地図上に表示するために使いやすいデータ形式です。点、線、面の情報をテキストとして扱えるため、Web地図、現場管理システム、台帳、測量データの確認、位置情報付き記録の整理など、さまざまな実務で使われています。しかし、いざGeoJSONを読み込ませても地図に何も表示されない、表示位置が大きくずれる、一部だけ表示されない、エラーは出ていないのに画面が空白になる、といったトラブルは珍しくありません。
GeoJSONが表示されない原因は、必ずしも地図側の不具合とは限りません。座標順序、座標系、ファイル構造、ジオメトリの種類、プロパティ、ファイル配信、文字コード、データ量、表示範囲など、確認すべき点が複数あります。この記事では、「geojson 使い方」を調べながら実務でGeoJSONを扱う担当者に向けて、表示されない原因を切り分けるための7つのチェックを解説します。
GeoJSONが表示されないときは原因を一つずつ切り分ける
GeoJSONが表示されないとき、最初に避けたいのは、原因を一気に推測して複数箇所を同時に変更してしまうことです。座標を直し、ファイル名を変え、地図側の設定も変え、さらにデータを軽量化するという進め方をすると、最終的に表示されたとしても、どの修正が効いたのか分からなくなります。次に同じトラブルが起きたときに再現できず、運用手順として残しにくくなります。
GeoJSONの表示不具合は、大きく分けると、データそのものの問題、座標や座標系の問題、読み込み方法の問題、地図表示側の問題に分かれます。たとえば、ファイルの形式としては正しくても、座標が想定地域ではなく海外や海上に飛んでいれば、画面上には何も表示されていないように見えます。逆に、座標は正しくても、ファイル配信時の設定や読み込み制限に引っかかっていれば、地図側にはデータが届きません。
実務では、まずGeoJSONがデータとして成立しているかを確認し、その次に座標の意味を確認し、最後に表示環境や配信環境を確認する流れが安全です。特に、測量、施工管理、施設管理、用地確認などで扱う位置情報は、座標系の前提が異なるデータが混在しやすくなります。緯度経度として表示するべきデータなのか、平面直角座標系などの投影座標として扱うべきデータなのかを曖昧にしたまま読み込むと、地図上で大きなズレが発生します。
また、GeoJSONは見た目がテキストなので、表計算ファイルやCSVのような感覚で一部を編集しがちです。しかし、カンマや括弧の位置が一つ崩れるだけで、ファイル全体が読み込めなくなることがあります。属性名や値の一部を修正したつもりでも、引用符の閉じ忘れ、不要な改行、全角記号の混入によって、地図側で読み込みに失敗することがあります。表示されない場合は、地図の設定だけでなく、GeoJSONの中身そのものを丁寧に確認することが大切です。
チェック1 座標の順序が経度、緯度になっているか確認する
GeoJSONで最も多い表示トラブルの一つが、座標の順序の間違いです。GeoJSONでは、緯度、経度ではなく、経度、緯度の順で座標を記述します。日本国内の位置であれば、多くの地域で経度は120度台から150度台付近、緯度は20度台から40度台付近になるため、この順序が逆になると、まったく別の場所を指してしまいます。
実務担当者が地図や住所検索に慣れている場合、「緯度経度」という言い方の影響で、緯度を先に書いてしまうことがあります。たとえば、ある地点を緯度35付近、経度139付近として把握していると、そのまま35、139の順でGeoJSONに入れてしまいがちです。しかしGeoJSONでは139、35の順にする必要があります。順序が逆でも、数値としては一見成立しているため、ファイル形式のエラーとして検出されないことがあります。そのため、読み込みエラーは出ないのに地図上には表示されない、または想定外の場所に表示されるという状態になります。
点データであれば座標順序の確認は比較的簡単です。GeoJSON内のcoordinatesを見て、最初の値が経度らしい数値、次の値が緯度らしい数値になっているかを確認します。線や面の場合は座標配列が多くなるため、先頭の数点だけでなく、複数箇所の座標を確認することが重要です。特に、別形式から変換したデータでは、一部の処理だけが緯度経度順で出力されていたり、変換前のフィールド名に引きずられて順序を誤っていたりすることがあります。
座標の順序を確認するときは、地図上で代表点を一つ選び、その座標が実際の場所を指しているかを見ると効果的です。現場の中心点、敷地の角、道路交差点、建物の代表点など、位置が分かりやすい点を使って確認します。表示されないGeoJSONの中から一つの座標を取り出し、経度と緯度を入れ替えた場合にどちらが正しい位置に近いかを確認すれば、順序ミスを早く見つけられます。
また、高さ情報を含む3次元座標の場合も注意が必要です。GeoJSONでは、経度、緯度、高さのように3番目の値として高さを持つことがあります。このとき、高さの値を緯度や経度と誤って扱うと、地図側で正しく解釈できない場合があります。表示側が高さに対応していない場合でも、2次元表示では経度と緯度だけを利用できることがありますが、データ変換時に配列の順序を崩してしまうと、表示不能や位置ズレの原因になります。まずは2次元の経度、緯度として正しく読めるかを確認し、そのうえで高さ情報の扱いを検討するのが安全です。
チェック2 座標系が地図表示に合っているか確認する
GeoJSONの表示で座標順序と並んで重要なのが、座標系の確認です。標準的なGeoJSONでは、座標はWGS 84の経度、緯度を基本として扱います。一方、測量や設計、施工管理の現場では、平面直角座標系などの投影座標、ローカル座標、工事基準点をもとにした独自座標が使われることがあります。これらをそのままGeoJSONとして読み込むと、地図上に表示されない、またはまったく違う場所に飛ぶ原因になります。
たとえば、GeoJSONのcoordinatesに数千、数万、数十万といった値が入っている場合、それは経度緯度ではなく、投影座標やローカル座標の可能性があります。経度であれば通常は180を超えず、緯度であれば90を超えません。したがって、coordinatesの値がその範囲から外れている場合、Web地図にそのまま載せられる緯度経度ではないと考えるべきです。この確認だけでも、多くの表示トラブルを早期に切り分けられます。
現場データでは、図面CAD、測量成果、出来形管理データ、点群関連データなど、元の座標系が明確に定義されているとは限りません。担当者間では「現場座標」「平面座標」「図面座標」と呼ばれていても、GeoJSONに変換する段階で、その座標がどの座標系なのかを明文化していないことがあります。座標系が分からないまま地図に重ねると、表示できたとしても正しい位置かどうか判断できません。
座標系の不一致を直すには、まず元データの座標系を確認します。測量成果であれば、どの座標系、どの原点、どの高さ基準、どの単位で作られているかを確認します。設計図や施工図から出力されたデータであれば、図面上の座標が地理座標と結び付いているか、単なる図面内座標なのかを確認します。ローカル座標しかない場合は、基準点や既知点を使って地図上の位置と対応付ける作業が必要になります。
また、単位の違いにも注意が必要です。メートル単位の座標として扱うべき値を度単位の経度緯度として読み込んだり、逆に度単位の座標をメートル座標のように扱ったりすると、表示位置が大きく狂います。座標変換を行う場合は、変換前の座標系、変換後の座標系、座標順序、単位をセットで確認することが大切です。GeoJSONの使い方としては、単に形式を整えるだけでなく、座標がどの空間を表しているのかを理解しておく必要があります。
チェック3 GeoJSONの基本構造が崩れていないか確認する
GeoJSONは、見た目はテキストですが、決められた構造を持つデータ形式です。地図に表示されない場合は、type、features、geometry、properties、coordinatesといった基本要素が正しく入っているかを確認します。特に、複数の地物をまとめて扱う場合は、FeatureCollectionとして全体をまとめ、その中にFeatureを並べる構造が一般的です。この構造が崩れていると、地図側がデータを読み込めません。
よくあるミスは、括弧の閉じ忘れ、カンマの付け忘れ、余分なカンマ、引用符の不一致です。GeoJSONはJSONを基礎にしているため、文字列は引用符で囲む必要があり、配列やオブジェクトの区切りも正しく記述する必要があります。属性を追加したときにカンマを入れ忘れたり、最後の要素の後ろに不要なカンマを残したりすると、全体が無効なデータとして扱われることがあります。画面上の地図が空白になる場合でも、原因は地図設定ではなく、単純な構文エラーであることがあります。
また、typeの値の大文字小文字も確認が必要です。GeoJSONでは、Point、LineString、Polygon、MultiPoint、MultiLineString、MultiPolygon、GeometryCollectionなどの指定があります。これらを小文字で書いたり、スペースを入れたり、似た別表記にしたりすると、読み込み側が正しく解釈できないことがあります。FeatureCollectionやFeatureも同様に、正確な表記が必要です。
propertiesの扱いにも注意します。propertiesは属性情報を入れる場所であり、表示名、管理番号、分類、日付、備考などを格納できます。ただし、geometryの中に属性を入れてしまったり、coordinatesと同じ階層に本来入るべきではない項目を置いたりすると、地図側の処理でエラーになることがあります。属性は表示に直接関係しないと思われがちですが、読み込み処理が厳しい環境では、想定外の構造が原因でデータ全体が読み込めないこともあります。
構造確認では、まず最小構成のGeoJSONに絞って表示できるかを見ると効果的です。大量の地物や複雑な属性を含むファイルで表示されない場合、同じファイルから代表的な点を一つだけ抜き出し、単純なPointとして表示できるかを確認します。最小構成で表示できるなら、座標や地図側の基本設定は大きく間違っていない可能性があります。その後、線、面、複数地物、属性付きデータへ段階的に戻していくと、どの要素で失敗しているかを特定しやすくなります。
チェック4 点、線、面のジオメトリ指定が正しいか確認する
GeoJSONでは、地物の種類によってcoordinatesの階層構造が異なります。点は一つの座標、線は座標の並び、面は閉じた線の並びとして表現します。この階層構造を誤ると、データとして読めなかったり、読めても地図上に表示されなかったりします。特に、Point、LineString、Polygonの違いを曖昧にしたまま手作業で編集すると、表示不具合が起こりやすくなります。
Pointは一つの地点を表すため、coordinatesには一組の経度、緯度を入れます。LineStringは複数の地点を結ぶ線を表すため、coordinatesには座標の配列を入れます。Polygonは面を表すため、外周を構成する座標列をさらに配列として入れます。Polygonでは、外周の最初の座標と最後の座標を同じにして、輪を閉じる必要があります。この閉じ忘れがあると、表示側によっては面として描画されなかったり、意図しない形になったりします。
面データでは、外周と穴の扱いにも注意が必要です。敷地、区画、建物外形、区域などをPolygonで表す場合、外側の輪と内側の抜き部分を区別して記述します。この階層を間違えると、穴が塗りつぶされたり、外周が崩れたり、表示されない原因になります。実務では、境界線データを面データに変換するときに、線は見えているのに面としては表示できないというトラブルが起きることがあります。この場合、座標列が閉じているか、面として成立しているかを確認する必要があります。
MultiPolygonやMultiLineStringのように、複数の面や線を一つの地物として扱う場合は、さらに配列の階層が深くなります。単独のPolygonとして扱うべきデータをMultiPolygonの構造で出力していたり、その逆になっていたりすると、読み込み側の設定と合わないことがあります。見た目には似た座標配列でも、GeoJSONとしての意味は異なるため、typeとcoordinatesの階層が一致しているかを確認することが重要です。
また、線や面の座標数が不足している場合も表示されません。LineStringは線として成立するために複数の座標が必要です。Polygonは面として閉じた輪を作るために、十分な座標数が必要です。点が一つしかないのにLineStringとして指定されていたり、二点だけでPolygonを作ろうとしていたりすると、ジオメトリとして不完全になります。変換処理やデータ抽出の途中で座標が欠落していないかも確認しましょう。
チェック5 表示範囲とズーム位置がデータに合っているか確認する
GeoJSONが正しく読み込まれていても、地図の表示範囲がデータの位置に合っていなければ、画面上では何も表示されていないように見えます。特に、地図の初期表示位置が固定されている場合、GeoJSONが別の地域にあると、利用者は空白の地図を見て「表示されていない」と判断してしまいます。実際には読み込み自体は成功していて、単に表示範囲外にあるだけというケースがあります。
この確認では、GeoJSON内の座標の最小値と最大値を見て、おおよその範囲を把握します。点データであれば代表点の経度緯度を確認します。線や面であれば、外接範囲を確認し、地図の初期位置がその範囲を含んでいるかを見ます。表示側に自動で範囲を合わせる機能がある場合でも、データが不正な座標を一つ含んでいると、範囲が異常に広がり、結果として対象地物が小さくなりすぎて見えないことがあります。
たとえば、ほとんどの座標が日本国内にあるのに、一点だけ経度や緯度がゼロ付近になっている場合、地図の表示範囲が大きく引き伸ばされることがあります。数値の入力ミス、空欄をゼロとして変換した処理、座標列の一部欠落などが原因です。このような外れ値があると、GeoJSON自体は読み込めても、意図した場所に見えない、または非常に小さく表示されることがあります。
ズームレベルも確認しましょう。広域表示では点や細い線が目立たず、面の色や線幅の設定によっては背景に埋もれて見えないことがあります。逆に、極端に拡大した状態では、対象地物が画面外に出ていることがあります。表示できないと感じたら、まずデータの中心座標に地図を移動し、適切な縮尺で確認します。点、線、面ごとに見え方が違うため、スタイル設定がある場合は、線幅、塗り、透明度、点の大きさも合わせて確認するとよいです。
表示範囲の問題は、データの正しさと操作画面の使いやすさの両方に関係します。実務システムでGeoJSONを扱う場合は、読み込み後に自動でデータ範囲へ移動する、読み込んだ地物数を表示する、範囲外の場合に警告を出すなどの設計があると、利用者が迷いにくくなります。単にファイルを読み込むだけでなく、表示されたかどうかを利用者が確認しやすい仕組みも大切です。
チェック6 ファイルの配信設定と読み込み条件を確認する
GeoJSONの中身が正しくても、ファイルの配信設定や読み込み条件が合っていないと、地図上には表示されません。Web上でGeoJSONを読み込む場合、ファイルの置き場所、読み込み権限、通信の制限、ファイル形式の認識、パス指定などが関係します。画面上では単に表示されないだけに見えても、実際にはファイル取得に失敗していることがあります。
まず確認したいのは、GeoJSONファイルに正しくアクセスできるかどうかです。ファイルのパスが間違っている、ファイル名の大文字小文字が違う、配置先が変わっている、アクセス権限が不足している、といった基本的なミスは意外に多くあります。手元では表示できていたのに、公開環境では表示されない場合は、ローカル環境と公開環境でファイルの参照先が違っている可能性があります。
次に、ファイルの種類として正しく配信されているかを確認します。GeoJSONはテキストデータですが、配信側の設定によっては、地図側や読み込み処理が期待する形式として扱われないことがあります。読み込み処理が厳密な場合、ファイル拡張子やContent-Typeの扱いが原因で失敗することがあります。GeoJSONのContent-Typeにはapplication/geo+jsonが使われますが、実際の表示可否は利用する地図ライブラリや読み込み処理の実装にも左右されます。静的ファイルとして配信する場合や、管理画面からアップロードして配信する場合は、ファイルが意図した形式で返されているかを確認する必要があります。
また、別の場所にあるファイルを読み込む場合、通信上の制限により取得できないことがあります。これはGeoJSONの構文とは別の問題です。開発環境では読み込めるが本番環境では読み込めない、同じサーバー内では読み込めるが外部の保管先では読み込めない、といった場合は、データそのものではなく、読み込み条件に原因がある可能性があります。実務では、地図担当者、システム担当者、データ作成担当者の間で責任範囲が分かれやすいため、どの段階で失敗しているのかを明確にすることが重要です。
ブラウザ上で確認する場合は、ファイル取得の成否、応答内容、エラーメッセージを確認します。データが取得できていないのか、取得はできているがGeoJSONとして解釈できていないのか、解釈はできているが描画されていないのかを分けて考えると、調査が早くなります。表示されないという一つの症状でも、原因は通信、構文、座標、スタイルのどこかに分かれます。まずはGeoJSONが地図側に届いているかを確認するのが基本です。
チェック7 データ量、属性、文字コードによる不具合を確認する
GeoJSONは扱いやすい形式ですが、データ量が大きくなりすぎると表示が重くなります。大量の点、細かすぎる線、複雑な面、多数の属性を含むファイルを一度に読み込むと、地図の表示に時間がかかったり、画面が固まったように見えたりします。表示されない原因が構文エラーではなく、処理負荷であることもあります。
特に、測量データ、境界データ、点群から派生したデータ、細かい区画線などは、座標点数が多くなりがちです。見た目には単純な線や面でも、内部には非常に多くの頂点が含まれている場合があります。地図上で広域表示するだけなら、それほど細かい形状は不要なこともあります。表示用途に合わせて座標点数を整理し、必要に応じて簡略化することで、読み込みや描画が安定します。
属性情報が多すぎる場合も注意が必要です。propertiesに長い説明文、不要な管理項目、空欄の多いフィールド、重複した情報が大量に入っていると、ファイルサイズが大きくなります。地図表示だけが目的であれば、表示に必要な属性と管理上必要な属性を分けて考えるとよいです。すべての元データをGeoJSONに詰め込むのではなく、表示用の軽いデータを別に作ることで、運用しやすくなります。
文字コードも見落としやすいポイントです。GeoJSONはUTF-8で扱うことが基本です。日本語の属性名や備考を含むGeoJSONでは、編集ソフトや変換処理によって文字コードの扱いが変わると、文字化けや読み込み不具合が発生することがあります。表示名や分類名に日本語を使う場合は、保存時の文字コードを統一し、不要な制御文字や特殊な記号が混入していないかを確認します。属性値に改行、引用符、タブ、全角記号が含まれる場合も、変換処理によっては構造を崩す原因になります。
また、空のgeometryやnull値の扱いにも注意します。台帳や一覧データからGeoJSONを作る場合、位置情報が未入力のレコードまでFeatureとして出力されることがあります。このようなFeatureが混在すると、読み込み側によってはエラーになったり、一部の地物が描画されなかったりします。実務では、位置情報を持たないレコードを除外する、別の一覧として扱う、エラーとして検出するなど、変換前の整理が必要です。
GeoJSONを安定して使うための実務ポイント
GeoJSONを安定して使うためには、表示されないときだけ対処するのではなく、作成段階から確認しやすいデータにしておくことが大切です。特に、複数人でデータを作成、編集、確認する運用では、ファイルの命名、座標系の明記、属性項目のルール、変換手順、確認手順をそろえておくと、トラブルを大きく減らせます。
まず、GeoJSONに変換する前の元データを整理します。どのデータが正本なのか、どの時点のデータなのか、どの座標系なのか、誰が作成したのかを分かるようにしておくと、表示不具合が起きたときに戻って確認できます。現場では、同じ名称のファイルが複数存在したり、修正版、最終版、確認済み版が混在したりすることがあります。表示できない原因が技術的な問題ではなく、古いファイルや別現場のファイルを読み込んでいたというケースもあります。
次に、GeoJSON化した後の確認手順を標準化します。代表点が正しい位置にあるか、線や面が意図した範囲にあるか、属性が文字化けしていないか、不要な地物が混ざっていないか、データ量が過大でないかを確認します。最初から全件を確認するのは難しくても、代表的な地点、境界、面、属性を選んで確認するだけで、重大なミスを見つけやすくなります。
また、表示用と保管用のデータを分ける考え方も有効です。保管用には詳細な属性や高精度な形状を残し、表示用には必要な属性と適切な形状精度に整理したGeoJSONを用意します。これにより、地図表示の負荷を抑えつつ、元データの情報量も失わずに済みます。特に、現場で素早く確認したい用途では、軽くて読み込みやすい表示用データが役立ちます。
GeoJSONは便利な形式ですが、万能ではありません。精密な測量成果、巨大な点群、複雑な3次元形状、詳細な設計情報をそのまま表現するには向かない場合もあります。用途に応じて、GeoJSONで扱う範囲を決めることが大切です。地図上で位置と概要を確認するのか、詳細な測量精度を管理するのか、現場写真や点検記録と紐づけるのかによって、必要なデータ設計は変わります。
現場の位置情報活用では取得段階から整えることが重要
GeoJSONが表示されない原因を直すには、座標順序、座標系、構造、ジオメトリ、表示範囲、配信設定、データ量や文字コードを順番に確認することが重要です。多くのトラブルは、地図に読み込む直前ではなく、データ作成や変換の段階で発生しています。そのため、表示できないGeoJSONをその場で直すだけでなく、どの工程でズレや欠落が起きたのかを振り返ることが、再発防止につながります。
実務でGeoJSONを使う場面では、位置情報の取得、整理、変換、共有、表示までが一連の流れになります。現場で取得した位置が曖昧だったり、写真や点検記録と座標の紐づきが後付けだったりすると、後工程でGeoJSONに変換しても、正しい表示や活用が難しくなります。逆に、取得時点で座標、写真、メモ、対象物の情報がきちんと整理されていれば、地図表示や共有の精度が高まり、確認作業もスムーズになります。
地図上に点や線や面を表示するだけであれば、GeoJSONは扱いやすい入口になります。しかし、現場管理で本当に重要なのは、その位置情報が正確で、誰が見ても同じ場所を確認でき、後から記録として追跡できることです。座標系が不明なままのデータ、手入力で作った不安定なデータ、写真と位置が別々に管理されたデータでは、表示できたとしても業務で使い切れない可能性があります。
現場で取得した高精度な位置情報を、写真、点群、図面確認、記録管理へつなげたい場合は、取得段階から位置情報を一体で扱える仕組みを選ぶことが効果的です。GeoJSONを地図に表示する段階で悩まないためにも、データを作る最初の現場計測から、座標と記録を正しく残す考え方が重要です。