GeoJSONは、点・線・面などの地理空間データをJSONで扱える便利な形式です。緯度経度を持つデータをWeb地図や業務システムに渡しやすく、現地調査、施設管理、防災、都市計画、設備点検など幅広い場面で使われています。一方で、GeoJSONをCesiumJSのような3D地図上に表示しようとすると、2D地図では目立たなかった設定差が表面化します。表示位置がずれる、地形に埋まる、高さが反映されない、線や面がちらつく、想定した色や太さで見えないといった問題は、データ自体の不備だけでなく、3D表示側の解釈や設定不足によって起こることがあります。
この記事では、geojsonで検索して実務に必要な解決策を探している担当者に向けて、Cesiumで3D表示する時につまずきやすい5つの設定を整理します。単なる機能紹介ではなく、なぜその設定が問題になるのか、どのように確認すればよいのか、実務ではどのような考え方で扱えばよいのかまで踏み込んで解説します。
座標系と座標順序の設定を誤ると表示位置がずれる
GeoJSONをCesiumで3D表示する時に最初につまずきやすいのが、座標系と座標順序の問題です。現行のGeoJSON仕様を前提にする場合、座標は基本的に「経度、緯度」の順で記述します。日本語では「緯度経度」と言うことが多いため、表計算データやCSVからGeoJSONを作成する際に、緯度と経度を逆に入れてしまうことがあります。2D地図でも位置ずれは起こりますが、3D表示では地形、建物、カメラ位置、表示範囲が関係するため、原因の切り分けがさらに難しくなります。
たとえば、東京周辺のデータを表示したつもりなのに何も見えない場合、単に読み込みに失敗しているのではなく、地球上の別の場所に描画されている可能性があります。東京付近なら、経度はおおむね139度前後、緯度は35度前後です。これを逆にすると、緯度139度という地理的に不正な値になり、処理系によっては明確なエラーではなく、表示されない、想定外の位置へ飛ぶ、カメラ移動の対象範囲が異常になるといった挙動につながります。
さらに注意したいのは、元データの座標系です。GeoJSONとして公開・交換するデータは、通常、WGS84相当の経度・緯度の度単位で扱う前提にしておく必要があります。しかし、測量データ、行政データ、施設管理データには、平面直角座標系、Webメルカトル、独自のローカル座標が使われていることがあります。そのようなデータを座標変換せずにGeoJSONへ入れると、数値は入っていてもCesium上では正しい場所に表示されません。特に、メートル単位の座標値をそのまま経度・緯度として扱うと、地球上の座標として成立しない大きな値になり、画面上では何も起こっていないように見えることがあります。
実務では、まずGeoJSONのcoordinatesに入っている値が何を表しているかを確認します。日本国内の経度・緯度であれば、経度はおおむね120〜150度台、緯度は20〜50度台に収まります。一方で、数万、数十万、数百万といった値が入っている場合は、平面座標や別の投影座標である可能性が高くなります。この段階でCesium側のスタイルや表示設定を調整する前に、座標変換の工程を見直す必要があります。
「EPSG:4326だから大丈夫」とだけ判断するのも危険です。GISソフトやライブラリによって、座標参照系の名称、軸順序、出力形式の扱いが異なることがあります。GeoJSONとして出力する時は、最終的な配列が[longitude, latitude]、つまり[経度, 緯度]になっているかをサンプル数件で確認します。列名がlat、lng、latitude、longitude、x、yのように混在している場合は、変換処理で取り違えが起きやすくなります。
また、GeoJSONの中で複数のデータソースを統合する場合も注意が必要です。あるデータは経度・緯度、別のデータは平面座標、さらに別のデータは高さ付き座標という状態で混在していると、読み込み自体は成功しても、表示位置がばらばらになります。3D表示では、点や線や面が地形の上にあるのか、建物の輪郭なのか、地下埋設物なのかといった意味も重要です。座標系の統一は見た目だけでなく、業務判断の正確性にも直結します。
Cesium側では、GeoJSONの読み込み後にデータ範囲へカメラを移動する処理を入れると、座標設定のミスとカメラ設定のミスを切り分けやすくなります。データが正しい場所に読み込まれていても、カメラが地球全体を見ている状態や、別地域を向いている状態では、利用者には「表示されていない」と見えます。表示確認用に、既知の地点へ1点だけ置いた小さなGeoJSONを用意しておくと、座標順序、座標系、カメラ移動の確認がしやすくなります。
GeoJSONの3D表示で最初に見るべきなのは、描画スタイルではなく座標の意味です。経度・緯度の順序、座標系、値の範囲、カメラ位置の4点を確認するだけで、多くの表示トラブルは初期段階で解消できます。
高さの扱いを理解しないと地形に埋まる
GeoJSONをCesiumで3D表示する時に、2番目につまずきやすいのが高さの扱いです。2D地図では、GeoJSONの座標に高さが含まれていなくても問題なく表示できます。点は地図上の位置に置かれ、線は道路や境界線として表示され、面は区域として塗られます。しかし、3D地図では地形の起伏、建物、地下・地上の区別、カメラ角度があるため、高さをどの基準で扱うかを決めないと、意図しない見え方になります。
GeoJSONの座標には、経度、緯度に加えて3番目の値として高度や標高に相当する値を入れられます。ただし、GeoJSON自体は「その高さを実務上どの基準で取得したのか」「地表からの相対値なのか」「楕円体高なのか」「別の標高モデルに基づく値なのか」までを厳密に管理してくれる形式ではありません。高さの意味は、データ仕様と表示側の設定で明確にしておく必要があります。
Cesiumで特に重要なのが、地形に追従させるかどうかです。GeoJsonDataSource.loadでは、線や面を地面に貼り付けたい場合にclampToGroundを指定できます。ただし、既定で常に地形に貼り付くと考えるのは危険です。地形に沿わせたい行政区域や調査範囲と、各頂点の高さを表したい構造物や軌跡では、選ぶべき設定が異なります。
よくある問題は、ポリゴンが地形や地表表現と重なり、埋まって見える、ちらつく、カメラ角度によって消えたように見えるケースです。区域を示す面を表示したいだけなのに、地形とほぼ同じ位置に重なると、どちらを前面に描画するかが不安定に見えることがあります。2D地図では面の塗りつぶしが上に表示されるため気づきにくいのですが、3Dでは奥行き、深度、地形の凹凸が関係するため、色がまだらに見えたり、ズームすると見え方が変わったりします。
この問題を避けるには、まずGeoJSONの用途を明確にします。地形に沿って行政区域や調査範囲を表示したいのか、地表より少し上に浮かせて視認性を高めたいのか、建物や構造物の高さを表現したいのかによって、設定は変わります。単に区域を示すだけであれば、地形に追従させる設定が自然な場合があります。一方で、現場確認用に色付きの範囲を強調したい場合は、表示用のデータとしてわずかに上へ持ち上げる、または枠線や透明度で視認性を補う設計が有効です。
線データでも高さの問題は起こります。道路中心線、境界線、管路、電線、移動軌跡などを3D上に表示する場合、地表に貼り付けるのか、一定高度で表示するのか、各頂点の高さを使うのかによって見え方が変わります。地表に貼り付けると、山間部では地形の凹凸に沿って線が曲がります。これは地形追従の線としては自然ですが、計測された実際の軌跡や構造物の高さを表したい場合には不正確になることがあります。逆に一定高度で表示すると、谷では宙に浮き、丘では地面に近づきすぎるように見えることがあります。
点データの場合も、アイコンやラベルが地表や建物に隠れる、カメラを傾けると見えにくくなるといった問題が起きます。設備点検や現地写真の位置を示すマーカーでは、地物そのものの位置と、画面上で見やすい注記位置を分けて考えることが大切です。位置を正確に示す点はデータ上の座標に置き、ラベルや吹き出しは視認性を優先して少し上に表示するなど、意味の違いを整理しておくと誤解を防げます。
面を立体的に押し出す場合も注意が必要です。CesiumのEntityとしてポリゴンを扱う場合、height、extrudedHeight、perPositionHeightなどの設定によって、高さ一定の面、各頂点の高さを使う面、押し出し形状などを表現できます。しかし、区域ごとの件数や危険度などの統計値を高さに割り当てる場合、その高さは実物の高さではありません。現場担当者が見る画面では、立体の高さが現実の高さなのか、指標を可視化したものなのかを凡例や説明で明確にする必要があります。
高さの確認では、いきなり大きなGeoJSONを読み込むのではなく、代表地点を数点だけ抽出して試す方法が有効です。平地、傾斜地、建物密集地、高架や橋の近くなど、条件の異なる地点で表示を確認すると、高さ設定の問題が見えやすくなります。現場で取得した高さ情報を使う場合は、端末や測位方式によって値にばらつきがあります。必要に応じて、異常値を除外する、桁や単位を確認する、地表面からの相対高さへ変換する、表示用に丸めるといった前処理を行います。
3D表示における高さは、見た目の演出ではなく、データの意味を決める重要な設定です。GeoJSONに高さを入れるかどうか、入れた高さをどう解釈するか、地形に沿わせるか、少し上に表示するかを明確にしておくことで、表示結果の信頼性は大きく変わります。
点・線・面ごとのスタイル設定で見え方が大きく変わる
GeoJSONは、Point、LineString、Polygonなど複数の形状を扱える形式です。しかし、Cesiumで3D表示する場合、形状ごとのスタイル設定を適切に分けないと、視認性が大きく低下します。2D地図では、点をアイコン、線を色付きの線、面を半透明の塗りで表示すれば十分なことが多いですが、3Dではカメラの角度、地形、陰影、重なり、距離によって見え方が変化します。
CesiumのGeoJsonDataSourceでは、読み込み時のオプションとして点のmarkerSize、markerSymbol、markerColor、線や面のstroke、strokeWidth、面のfillなどを指定できます。また、GeoJSON側にシンプルスタイル仕様に沿ったプロパティがある場合は、それらが使われることがあります。ただし、propertiesに任意の属性を入れれば自動で望みどおりの色や高さになるわけではありません。業務用の見え方を作るには、読み込み後にEntityの見た目を調整する設計も必要になります。
まず点データでは、サイズ、高さ、ラベルの関係が重要です。現場写真の撮影位置、点検対象の設備、観測地点などをGeoJSONの点として表示する場合、小さすぎる点はズームアウト時に見失われます。一方で、大きすぎる点は密集したエリアで重なり、個々の位置が分からなくなります。3D表示では遠近感があるため、カメラから遠い点が小さく見え、近い点が大きく見える設定は自然です。しかし、業務画面では遠くの重要な点も認識したい場合があります。その場合は、距離による表示切り替え、クラスタリング、選択時の強調などを検討します。
ラベルも注意が必要です。GeoJSONの属性情報を使って地点名や管理番号を表示すると便利ですが、すべての点に常時ラベルを出すと画面はすぐに読みにくくなります。3D空間では、奥のラベルが手前の地物と重なったり、建物や地形の上で文字が浮いて見えたりします。実務では、通常時は点だけを表示し、選択時や一定以上に拡大した時だけラベルを出す設計が扱いやすいです。属性情報を豊富に持つGeoJSONほど、画面上に常時出す情報と、クリック後に詳細表示する情報を分けることが重要です。
線データでは、線幅、地形追従、表示優先度がポイントです。道路、河川、境界、移動経路、インフラの配線や配管など、線で表されるデータは業務上多くあります。3D表示では、線が地形と同じ高さにあると、角度によって地表に隠れたりちらついたりします。線幅を太くすれば見やすくなるように思えますが、太すぎる線は実際の位置精度を誤解させることがあります。境界線や測量線のように正確性が求められるデータでは、視認性と精度表現のバランスが必要です。
線の色設定も単純ではありません。背景となる地表や建物が明るい場合と暗い場合で、同じ線色の見え方は変わります。複数種類の線を同時に表示する場合、色だけで区別しようとすると、利用者によって判別しにくくなることがあります。線種、透明度、表示のオンオフ、選択時の強調、凡例を組み合わせることで、業務画面として読み取りやすくなります。
面データでは、塗りつぶしと枠線の設定が特に重要です。Polygonで表現される区域、敷地、建物外形、調査範囲、危険範囲などは、塗りを強くしすぎると下の地形や他の情報が見えなくなります。逆に透明度を上げすぎると、どこが範囲なのか分かりにくくなります。3D表示では視点を傾けるため、面が手前の地形と重なったり、奥行きによって面積感が変わったりします。塗りだけに頼らず、枠線を併用すると範囲を認識しやすくなります。
ただし、枠線の太さや輪郭表現は実行環境によって見え方に差が出ることがあります。したがって、線幅だけで重要度を表現するのではなく、色、透明度、高さ、選択時の強調、凡例を組み合わせるのが安全です。公開前の確認では、開発者のPCだけでなく、実際に利用するブラウザ、OS、端末、モニターで見え方を確認します。
スタイル設定では、GeoJSON内のpropertiesをどう活用するかも重要です。propertiesには名称、種別、状態、更新日時、担当部署、計測値などを入れられます。これらを表示スタイルに反映すれば、点検済みと未点検で色を変える、危険度が高い区域を強調する、古いデータを薄く表示するといった表現ができます。ただし、属性値の表記ゆれがあるとスタイル分けが崩れます。「未確認」「未確認 」「未確認中」のような値が混ざっていると、意図した分類になりません。表示前に属性値を正規化することは、見た目の品質だけでなく、業務上の判断ミスを防ぐうえでも重要です。
点、線、面を同じGeoJSONに含める場合は、全体の表示優先度を設計する必要があります。点を最前面で目立たせたいのか、面の範囲を重視したいのか、線の経路を追いやすくしたいのかによって、色、透明度、高さ、表示タイミングが変わります。すべてを同時に強調すると、結局どの情報も読み取りにくくなります。3D表示では「表示できること」と「理解しやすいこと」は別です。GeoJSONのスタイル設定は、単に色を付ける作業ではなく、利用者が何を判断するための画面なのかを設計する作業だと考えるべきです。
データ量と描画負荷を考えないと動作が重くなる
GeoJSONは扱いやすい反面、大量データの3D表示では負荷が高くなりやすい形式です。ファイルとして読みやすく、構造も分かりやすいため、多くの点や線や面をそのまま読み込んでしまいがちです。しかし、Cesiumの3D地図では、地形、3D Tiles、建物、カメラ操作、属性表示など多くの処理が同時に動いています。そこへ巨大なGeoJSONを一括で読み込むと、初期表示が遅い、画面操作が重い、ブラウザが固まる、端末によって表示できないといった問題が発生します。
特に重くなりやすいのは、頂点数の多い線や面です。行政区域、河川、道路境界、敷地外周などは、見た目には単純な線や面に見えても、内部では非常に多くの座標点を持っていることがあります。細かい形状を忠実に残したGeoJSONを広域で表示すると、描画すべき頂点が膨大になります。2D表示では許容できたデータでも、3Dではカメラの傾きや地形との関係が加わるため、負荷が大きく感じられることがあります。
実務で重要なのは、表示目的に応じて解像度を変える考え方です。広域表示では細かな形状をすべて見せる必要はありません。市区町村全体を俯瞰する画面で、数センチ単位の境界の凹凸まで表示しても、利用者は認識できません。逆に、現場周辺を拡大して確認する画面では、詳細な形状が必要になります。GeoJSONを1種類だけ用意して全ズーム段階で使うのではなく、広域用には簡略化したデータ、詳細確認用には精度の高いデータというように分ける設計が有効です。
点データも数が増えると問題になります。数千件程度なら表示できても、数万件、数十万件になると、点そのものの描画だけでなく、ラベル、クリック判定、属性表示、絞り込み処理が重くなります。現場写真、設備台帳、センサー記録、移動ログなどは、時間とともに件数が増えやすいデータです。最初は快適に動いていた画面が、運用開始から数か月後に重くなることもあります。この場合、表示側の色や線幅だけで解決しようとするのではなく、取得条件や表示範囲を制御する必要があります。
たとえば、現在の表示範囲内のデータだけを読み込む、一定以上に拡大した時だけ点を表示する、古いデータは初期表示から除外する、カテゴリごとにオンオフできるようにする、といった方法があります。GeoJSONを使う場合でも、すべてのデータを最初から画面に渡す必要はありません。利用者がその時点で判断に必要な情報だけを表示するほうが、操作性も理解しやすさも向上します。
面データでは、複雑な穴あきポリゴンや多数のマルチポリゴンにも注意が必要です。土地、建物、区域、災害想定範囲などのデータには、外周だけでなく内側に除外領域を持つものがあります。これらを3D表示で塗り分ける場合、形状の解釈や描画順の処理が重くなることがあります。さらに、面を地形に沿わせる設定や高さを持たせる設定を組み合わせると、負荷は増えます。表示が遅い場合は、ファイル容量だけでなく、座標点の数、ポリゴンの複雑さ、属性の多さを確認します。
propertiesに大量の属性を入れすぎることも、見落とされがちな負荷要因です。表示に使わない説明文、履歴、内部管理情報、長い文字列などがすべて含まれていると、ファイルサイズが大きくなり、読み込みや通信に時間がかかります。属性情報は便利ですが、3D表示に必要な項目と、詳細画面や別システムで参照すればよい項目を分けることが重要です。GeoJSONを画面表示用のデータとして使うのか、データ交換用の完全な情報として使うのかを明確にしないと、表示パフォーマンスに影響します。
また、データ量の問題は利用端末の性能にも左右されます。社内の高性能な開発環境では快適に動いても、現場で使う端末や通信環境では重くなることがあります。屋外作業、移動中の確認、通信が不安定な場所での利用を想定する場合、軽量化は特に重要です。3D表示は視覚的な情報量が多いため、少しの遅延でも操作しにくく感じられます。カメラを動かすたびに描画が止まるようでは、現場では使われなくなってしまいます。
パフォーマンス対策では、問題が読み込み時に起きているのか、描画時に起きているのか、操作時に起きているのかを分けて考えます。ファイルを開くまでに時間がかかるなら、容量や通信の問題が疑われます。表示後にカメラ操作が重いなら、頂点数、地形追従、ラベル数、描画設定の問題が考えられます。クリックや検索が遅いなら、属性情報や選択処理が関係しているかもしれません。原因を分けずに設定を変更すると、見た目は変わっても根本的な改善にならないことがあります。
巨大なデータを長期運用する場合は、GeoJSONのまま一括配信する設計にこだわらないことも大切です。表示範囲ごとの分割、サーバー側での絞り込み、ズーム段階に応じた簡略化、用途に応じた別形式の利用などを検討します。GeoJSONは便利な交換形式ですが、あらゆる規模の3D表示に常に最適な配信形式というわけではありません。
GeoJSONをCesiumで安定して使うには、データを読み込めるかどうかではなく、業務で継続利用できる軽さに整えられているかを見る必要があります。表示範囲、ズーム段階、属性量、形状の細かさを設計し、必要に応じて分割・簡略化することで、3D地図は実務に耐える操作感になります。
3D表示に向いたGeoJSONへ整える前処理が重要になる
GeoJSONの3D表示で発生する問題の多くは、Cesium側の表示設定だけでなく、表示前のデータ整備にも原因があります。座標系、高さ、スタイル、データ量を個別に調整しても、元のGeoJSONが不安定であれば、画面上の不具合は繰り返し発生します。実務でGeoJSONを扱う場合は、3D地図に読み込む前のチェックと前処理を標準化しておくことが重要です。
まず確認すべきなのは、GeoJSONとしての構造が正しいかどうかです。FeatureCollectionになっているか、各Featureにgeometryがあるか、geometry.typeとcoordinatesの構造が一致しているか、propertiesが想定どおりに入っているかを確認します。構造に不備があると、読み込みに失敗するだけでなく、一部の地物だけが表示されないことがあります。複数の処理工程を経て作られたGeoJSONでは、空のgeometry、nullのcoordinates、想定外のtypeが混ざることがあります。
次に、座標値の妥当性を確認します。経度・緯度の範囲から外れていないか、緯度と経度が逆になっていないか、極端な外れ値がないかをチェックします。数万件の点データの中に1件だけ異常な座標があると、データ全体の範囲が大きく広がり、カメラ移動や自動ズームの挙動がおかしくなることがあります。画面上では、正しい地点が非常に小さく表示されたり、何もない広大な範囲へ飛ばされたように見えたりします。異常値の除外は、3D表示の安定性に直結します。
ポリゴンデータでは、リングの閉じ方や自己交差にも注意が必要です。区域を表すPolygonでは、外周の始点と終点が一致している必要があります。また、穴を持つポリゴンでは、外周と内周の扱いを正しく保つ必要があります。線が自分自身と交差している形状や、極端に細かい形状は、塗りつぶしや地形追従の結果が不安定になることがあります。2Dではなんとなく表示されていても、3Dでは面の向き、深度、描画順の問題が出やすくなります。
属性情報の整備も欠かせません。GeoJSONのpropertiesは自由度が高いため、さまざまな項目を入れられますが、自由度が高いほど表記ゆれや欠損が起こりやすくなります。スタイル分けに使う項目は、値の種類をあらかじめ決めておくことが大切です。たとえば、状態を表す項目で「完了」「済」「対応済み」が混在していると、本来同じ分類にしたいデータが別扱いになります。3D表示では色や高さやアイコンで状態を表すことが多いため、属性値の整理は見た目の一貫性に直結します。
高さを持つGeoJSONでは、高さの単位と基準を明確にします。高さの値がメートルなのか、地表からの相対値なのか、測位機器が出力した値なのか、別システムで補正した値なのかをデータ仕様として決めておく必要があります。さらに、測位や計測によって得られた高さには誤差が含まれることがあります。建物や設備の高さを表す場合は、誤差がどの程度許容されるのか、表示上どのように扱うのかを決めておきます。高さの異常値が混ざると、点が空中に飛んだり、線が地中に潜ったりし、利用者に不信感を与えます。
前処理では、用途別にGeoJSONを分けることも有効です。編集用、保存用、表示用をすべて同じデータにすると、不要な属性や細かすぎる形状まで画面に渡され、重くなります。保存用のデータには詳細な履歴や管理情報を残し、表示用のGeoJSONには画面で必要な最低限の属性と適切な形状だけを持たせると、運用しやすくなります。3D表示用のGeoJSONは、元データをそのまま出すものではなく、利用者が判断しやすい形に加工した表示データと考えるとよいです。
更新頻度も考慮すべきです。現場で毎日更新される点検データと、年に数回しか更新されない区域データでは、配信や読み込みの設計が異なります。頻繁に更新されるデータを巨大なGeoJSONとして毎回全件読み込むと無駄が多くなります。一方で、あまり更新されない背景的なデータは、あらかじめ軽量化して安定的に読み込めるようにしておくと便利です。データの性質ごとに分けて管理することで、3D表示の負荷と運用コストを抑えられます。
また、現場で取得したデータをGeoJSON化する場合は、取得時点の精度管理も重要です。後から表示設定で補正しようとしても、元の位置情報が粗い、座標が不安定、高さがばらついていると、正確な3D表示には限界があります。写真、メモ、点検結果、設備位置などを現地で記録する場合は、どの程度の位置精度が必要なのか、後で3D地図上に重ねた時に業務判断に使えるのかを考えておく必要があります。GeoJSONはあくまでデータの入れ物であり、入れる情報の精度が低ければ、表示結果もそれ以上にはなりません。
前処理の品質を上げるには、チェック項目を運用に組み込むことが効果的です。座標系、座標順序、高さ、形状、属性、データ量、外れ値を確認する流れを作っておけば、担当者が変わっても一定の品質を保てます。毎回手作業で原因を探すのではなく、GeoJSONをCesiumに投入する前に自動または半自動で検証する仕組みを用意することで、トラブル対応の時間を大きく減らせます。
GeoJSONの3D表示は、読み込み処理だけで完結するものではありません。正しい座標に、正しい高さで、適切なスタイルを与え、必要な量だけ軽く表示するためには、事前のデータ整備が欠かせません。前処理を軽視せず、表示用データとして整えることが、安定した3D活用への近道です。
まとめ：GeoJSONの3D活用は現場データの精度設計から始まる
GeoJSONをCesiumで3D表示する時につまずきやすい設定は、座標系、座標順序、高さ、スタイル、データ量、前処理に集約されます。どれも一見すると細かな設定項目に見えますが、実際には3D地図を業務で使えるかどうかを左右する重要な要素です。表示されない、位置がずれる、地形に埋まる、ちらつく、重いといったトラブルは、単独の原因ではなく、複数の設定が重なって起こることが多いです。
特に重要なのは、GeoJSONを単なるファイル形式としてではなく、現場の情報を3D空間に正しく配置するためのデータ設計として捉えることです。経度・緯度の順序が正しいか、元データの座標系が合っているか、高さの基準が明確か、点・線・面の意味に合ったスタイルになっているか、表示に必要なデータ量へ整理されているかを確認することで、3D表示の品質は大きく向上します。
また、3D表示は見た目のインパクトが大きいため、利用者は表示された位置や高さを直感的に信じやすくなります。だからこそ、データの精度や設定の意味を曖昧にしたまま運用するのは危険です。現場の設備、調査地点、工事範囲、点検結果、防災情報などをGeoJSONで扱う場合、画面上の数メートルのずれが判断ミスにつながることもあります。3Dで見えるようにすること自体が目的ではなく、現場判断に使える精度で表示することが目的です。
GeoJSONを安定して3D活用するには、Cesium側の設定だけでなく、データ取得の段階から考える必要があります。現地でどのように位置を記録するか、どの精度で座標を残すか、高さ情報をどう扱うか、属性をどの形式で保存するかによって、後工程の表示品質が決まります。後から座標を補正したり、属性を整理したりすることもできますが、最初から3D表示を見据えてデータを取得できれば、手戻りは大きく減ります。
公開前には、既知の地点での表示確認、座標順序の確認、clampToGroundなどの高さ設定の確認、点・線・面ごとのスタイル確認、実利用端末での負荷確認を行います。GeoJSONの3D表示は、正しい仕様理解と現場データの精度設計を組み合わせることで、単なる可視化ではなく、業務判断に使える3D地図へ近づきます。