GeoJSONに3D座標を入れる前に知るべきZ値の注意点4つ

GeoJSONは、点、線、面といった地物をJSON形式で扱えるため、地図表示、現場管理、測量成果の受け渡し、写真位置の整理、点検記録の可視化などで広く使われています。多くの場面では経度と緯度の2D座標だけで十分ですが、標高、高さ、深さ、構造物の上下関係、写真を撮影した位置の高さまで扱いたい場合は、座標に3つ目の値を加えたくなることがあります。

ただし、GeoJSONに3つ目の値を入れれば、そのまま安全な3Dデータになるわけではありません。現行のGeoJSON仕様では、座標の3要素目は任意の高度要素として扱えますが、仕様に沿って解釈する場合はWGS 84参照楕円体に対するメートル単位の高さです。一方、国内の実務では、標高、楕円体高、ジオイド補正後の高さ、現場独自の仮基準高、設計面からの差分など、複数の高さの考え方が混在します。この違いを整理しないままZ値を入れると、平面位置は合っているのに高さだけ合わない、3D表示ではそれらしく見えるのに数量計算や検査には使えない、といった問題につながります。

また、GeoJSONは軽量で扱いやすい形式である一方、すべてのGIS、地図ビューア、変換処理、編集ツールがZ値を同じように保持し、計算し、表示するとは限りません。2D前提の処理を通すと、Z値が無視されたり、保存時に落ちたり、属性側の高さ情報と座標側のZ値が食い違ったりする可能性があります。

この記事では、「geojson」で検索している実務担当者に向けて、GeoJSONに3D座標を入れる前に必ず確認しておきたいZ値の注意点を4つに分けて解説します。単に座標配列へ3つ目の数値を入れる方法ではなく、現場データとして後工程まで誤解なく使うための考え方を中心に整理します。

目次

• GeoJSONのZ値は入れられるが基準までは自動で伝わらない

• 注意点1としてZ値の基準を必ず定義する

• 注意点2として2D前提の処理でZ値が落ちる可能性を見る

• 注意点3として高さ情報と属性情報の役割を分ける

• 注意点4として3D表示と実務精度を混同しない

• GeoJSONでZ値を扱うときの実務フロー

• まとめ

GeoJSONのZ値は入れられるが基準までは自動で伝わらない

GeoJSONの座標は、一般的には経度、緯度の順で記述されます。さらに、位置を表す配列には3つ目の値として高度または標高に相当する値を含めることができます。たとえば点であれば、経度、緯度、高さの3要素を持つ座標として記録できます。線や面でも、各頂点に3つ目の値を持たせることで、地形の高低差や構造物の上下方向の情報を表現できます。

ここで最初に押さえるべきなのは、GeoJSONとしての3要素目は単なる自由欄ではないということです。現行仕様に準拠して相互運用性を重視するなら、3要素目はWGS 84参照楕円体に対するメートル単位の高さとして考えるのが基本です。国内の測量や施工管理でよく使う標高や工事基準面からの相対高さをそのまま入れる場合は、少なくとも当事者間でその意味を明確にしておく必要があります。

GeoJSONの座標配列だけを見ても、そのZ値が楕円体高なのか、ジオイド補正後の標高なのか、現場基準からの相対高さなのかまでは十分に伝わりません。3番目の数値が10.5と書かれていても、それが海面に近い基準からの高さなのか、測位機器が出した楕円体高なのか、設計面との差分なのかで、実務上の意味は大きく変わります。

また、階層番号、点検ランク、時刻、測線上の距離などを座標配列の3要素目に入れる運用は避けるべきです。そうした情報は高さではなく属性として扱うほうが安全です。GeoJSONでは座標配列を3要素より長く拡張する運用も見られますが、追加要素の意味は標準的に解釈されるとは限らず、処理系によっては無視される可能性があります。M値やタイムスタンプのような情報も、座標配列へ詰め込むより、properties側に分けて持たせたほうが後工程で誤解されにくくなります。

GeoJSONを地図表示だけに使う場合、Z値の曖昧さがすぐに問題化しないこともあります。平面図上に点や線を重ねるだけであれば、経度と緯度が合っていれば見た目は成立します。しかし、3D表示、縦断確認、土量比較、構造物高さの検査、写真や点検記録との突き合わせに使う場合は、Z値の意味が曖昧なままだと実務リスクになります。

さらに、現行のGeoJSONでは座標参照系はWGS 84を基本とし、旧仕様で使われていたcrsメンバーによる座標参照系の指定は前提にしません。案件内の合意で別の座標系や高さ基準を使うことはあり得ますが、その場合でも、GeoJSONファイルを見た第三者や別システムが自動的に正しく解釈してくれるとは考えないほうが安全です。

そのため、GeoJSONに3D座標を入れる前には、Z値を入れられるかではなく、Z値をどう定義し、どの工程まで維持し、どの処理で使うのかを先に決める必要があります。これを決めないままファイルだけ作ると、後から確認したときに、どの値が正しい高さだったのか、どの段階で変換されたのか、どの基準で比較すべきなのかが分からなくなります。

GeoJSONのZ値は便利ですが、万能な3Dデータ形式ではありません。位置情報を軽く扱える利点がある一方で、高さの基準、精度、用途、後工程の対応状況を利用者側で管理する必要があります。この前提を理解しておくことが、Z値を安全に扱う第一歩です。

注意点1としてZ値の基準を必ず定義する

GeoJSONに3D座標を入れるときに最も重要なのは、Z値の基準を明確にすることです。高さは単なる数値ではなく、必ず何らかの基準面や基準点との関係で意味を持ちます。Z値が高さを表しているとしても、その高さが何を基準にしているかが分からなければ、実務では正しく使えません。

現場でよく問題になるのは、楕円体高、標高、設計面からの相対高さ、現場独自の仮基準高が混在することです。測位で得た高さをそのままZ値に入れた場合と、ジオイドや既知点を使って補正した値を入れた場合では、同じ地点でもZ値が異なることがあります。さらに、施工管理では設計高さとの差分を扱うこともあります。この差分をZ値として入れてしまうと、見た目には高さ情報に見えても、実際には絶対的な高さではなく、計画面からどれだけ上下しているかを表す値になります。

この違いは、データを作った本人には当たり前でも、受け取る側には伝わりません。GeoJSONの座標配列だけを見ても、3番目の値が仕様どおりの楕円体高なのか、標高として扱うべき値なのか、相対高さなのか、補正済みなのか、未補正なのかは判断しにくいものです。そのため、Z値を入れる場合は、ファイル内の属性、別紙の仕様、業務内のデータ定義書などで、Z値の意味を明確にしておく必要があります。

特に複数人でデータをやり取りする場合は、Z値の単位も明記すべきです。GeoJSONの仕様に沿うなら高さの単位はメートルと考えるのが基本ですが、実務データの中にはセンチメートル単位の値や、別の単位系から変換された値が混ざる可能性があります。単位が曖昧なまま小数値だけが並んでいると、受け取り側が誤った倍率で解釈する危険があります。

小数点以下の桁数も注意点です。不要に細かい桁を残すと精度が高いように見えてしまいますが、数値の桁が多いことは測定精度が高いことを意味しません。実際の取得精度、補正方法、基準点の精度、現場条件、変換処理の影響を考え、信頼できる桁を説明できる状態にしておく必要があります。

また、Z値の基準を決めるときは、平面座標の基準と高さ基準を分けて考える必要があります。GeoJSONでは経度と緯度を使うことが多いため、平面位置はWGS 84の地理座標として扱われます。一方、高さ方向は楕円体、ジオイド、現場基準面、設計面などに依存します。横方向の座標が正しく変換されていても、高さ方向の基準が合っていなければ、3D的には整合していないデータになります。

たとえば、複数の測量成果を重ねる場合、平面位置がほぼ重なっているのに高さだけ数十センチ、場合によってはそれ以上ずれることがあります。このとき、原因が現場の変化なのか、測定誤差なのか、高さ基準の違いなのかを切り分けるには、Z値の基準が記録されていなければなりません。記録がなければ、後から正しい補正や比較を行うことが難しくなります。

Z値をGeoJSONに入れる前には、少なくとも、このZ値は何を表すのか、単位は何か、基準面または基準点は何か、補正済みか未補正か、どの精度で扱うべきかを決めておくと安全です。これらをファイル作成時に明確にしておけば、後工程で地図表示、3D表示、数量確認、点検記録、施工管理に使うときも、誤解を減らせます。

高さ情報は、見た目以上に業務判断へ影響します。特に土木、建設、設備、インフラ点検の現場では、数値の意味が曖昧な高さデータはそのまま使えません。GeoJSONにZ値を入れるときは、座標の3つ目の値として保存できるかどうかよりも、現場で説明できる高さとして定義できているかを先に確認することが大切です。

注意点2として2D前提の処理でZ値が落ちる可能性を見る

GeoJSONにZ値を入れても、すべての処理でZ値が保持されるとは限りません。実務では、作成、変換、編集、結合、分割、簡略化、表示、出力など、さまざまな工程を通してGeoJSONを扱います。そのどこかで2D前提の処理が入ると、Z値が失われたり、計算に使われなかったりする可能性があります。

よくあるのは、ファイルを読み込んだ時点ではZ値が残っているものの、編集して保存し直したときに2D座標として出力されてしまうケースです。点の座標が経度と緯度だけになり、3番目の値が消えてしまっても、平面地図上では同じ位置に表示されるため、気づきにくいことがあります。見た目の地図表示だけを確認していると、Z値が欠落していることに後工程まで気づかないまま進んでしまいます。

GeoJSONを別形式に変換してから再びGeoJSONに戻す工程でも注意が必要です。中間形式が2D前提の場合、高さ情報が保持されないことがあります。座標変換、範囲切り出し、図形の簡略化、ポリゴンの修正、線の分割、複数ファイルの結合などの処理も同様です。処理の目的が平面表示であれば、Z値は不要な値として扱われる場合があります。

Z値が落ちるリスクは、点よりも線や面で見えにくくなります。点であれば属性と照合して高さの欠落に気づきやすいことがありますが、線や面では頂点ごとのZ値が消えても、平面形状はそのまま残ります。道路中心線、境界線、構造物外形、造成範囲などを2Dで見るだけなら問題ないように見えてしまいます。しかし、縦断方向の確認や高さ差の評価に使う段階で、必要なZ値がなくなっていたことが分かると、再作業が発生します。

この問題を防ぐには、GeoJSONを作成した直後だけでなく、処理工程ごとにZ値が保持されているかを確認する必要があります。特に、別の担当者へ渡す前、別形式へ変換する前、編集して保存した後、納品用に整形した後は、座標配列の3番目の値が残っているかを確認するべきです。単に地図上で開けるかどうかではなく、ファイルの中身としてZ値が存在しているかを確認することが重要です。

また、Z値を使う処理と使わない処理を分けて考えることも大切です。地図上で範囲を確認するだけの工程では2Dで十分かもしれません。一方、現場の高さ確認、3D表示、断面確認、出来形の比較に使う工程ではZ値が必要です。全工程でZ値を必ず使うわけではないからこそ、どの工程ではZ値を維持しなければならないのかを決めておく必要があります。

実務では、元データを保管しておくことも重要です。加工後のGeoJSONだけを残していると、Z値が欠落したときに復元できない場合があります。測位結果、点群から抽出した座標、現場写真の位置情報、設計データから生成した座標、変換前の原始データなど、Z値の根拠となる元データは加工済みファイルとは別に管理しておくと安全です。

GeoJSONの検査時には、すべての座標にZ値が入っているかも確認したいところです。点群由来のデータや複数ソースを結合したデータでは、一部の地物だけZ値があり、別の地物にはZ値がないという混在が起こることがあります。点では3D、線では2D、面では一部だけ3Dという状態になると、後工程での解釈が不安定になります。必要に応じて、Z値ありのデータとZ値なしのデータを分ける、または属性で状態を明示するなどの整理が必要です。

bboxを付ける場合も注意が必要です。2Dの範囲だけを表すbboxと、Z方向を含む3Dのbboxでは配列の意味が変わります。地物本体の座標は3Dなのにbboxだけ2Dのままなのか、Z方向の最小値と最大値まで含めるのかを案件内で統一しておかないと、範囲検索やデータ検査で誤解が生じることがあります。

GeoJSONは扱いやすい形式である反面、処理する側がZ値をどこまで尊重するかは一定ではありません。3D座標を入れたつもりでも、実務の途中で2Dデータに戻ってしまうことがあります。Z値を使う目的があるなら、作成時だけでなく、編集、変換、共有、納品までの各段階で、Z値が維持されているかを確認する運用が欠かせません。

注意点3として高さ情報と属性情報の役割を分ける

GeoJSONでZ値を扱うときは、座標として持たせるべき高さと、属性として持たせるべき情報を分けることが重要です。Z値は座標配列の一部として扱われるため、地物の位置そのものを表す値として考えるのが自然です。一方で、現場では高さに関連する情報が多く存在します。設計高さ、実測高さ、差分、許容値、測定時刻、測定方法、品質区分、点検結果などをすべてZ値に詰め込むことはできません。

たとえば、ある点のZ値に実測高さを入れる場合、設計高さとの差分は属性として持たせたほうが分かりやすいことがあります。逆に、Z値に設計高さを入れてしまうと、現場で測った高さと混同される可能性があります。どちらをZ値にするかは用途によりますが、少なくとも同じファイル内で意味が混在しないように統一する必要があります。

線や面でも同じです。構造物の外形を表す面にZ値を入れる場合、それが地表面の高さなのか、天端の高さなのか、底面の高さなのかによって意味が変わります。面の各頂点にZ値を入れれば立体的に見えることがありますが、その面が実際にどの面を表しているのかが曖昧だと、3D表示や数量計算で誤解を招きます。必要であれば、属性にどの高さを表す地物なのかを記録しておくべきです。

高さに関する複数の値を管理したい場合、Z値だけに頼ると限界があります。実測値と設計値を比較したい場合、座標配列の3番目に両方を入れることはできません。片方をZ値、もう片方を属性にするか、両方を属性として持たせ、Z値は表示用または代表値にするかを決める必要があります。ここを曖昧にすると、後からファイルを見た人が、Z値を基準値として扱うべきなのか、測定値として扱うべきなのか判断できません。

属性情報との役割分担は、データ更新時にも重要です。座標のZ値は地物の位置情報として扱われるため、編集や変換の対象になりやすい一方、属性は別の目的で更新されることがあります。点検結果を更新しただけのつもりでファイルを保存したら、座標側のZ値が変換処理によって丸められていた、ということもあり得ます。高さに関する重要情報をどこに置くかによって、更新時の確認項目も変わります。

実務では、Z値と属性の両方に同じような高さ情報が入っていることもあります。この場合、どちらが正なのかを決めておかないと、値が食い違ったときに判断できません。たとえば、Z値が12.30で属性の実測高さが12.28だった場合、丸めの違いなのか、更新漏れなのか、別基準の値なのかが分からなくなります。重複して持たせる場合は、Z値は表示用、属性は管理用など、役割を明確にする必要があります。

Z値を使わない環境への受け渡しも考慮する必要があります。受け取り側が2D前提であっても、属性に高さ情報が入っていれば、最低限の確認や再利用ができる場合があります。逆に、Z値にしか高さを持たせていないと、Z値が落ちた瞬間に高さ情報そのものが失われます。重要な高さ情報については、用途に応じて属性にも保持する運用を検討する価値があります。

ただし、何でも属性に入れればよいわけではありません。属性項目が増えすぎると、ファイルの意味が分かりにくくなります。実務で必要なのは、Z値、設計高さ、実測高さ、差分、基準、測定状態などを、誰が見ても同じように解釈できる形で整理することです。属性名も重要です。単にheightとするよりも、実測高さなのか、設計高さなのか、相対高さなのかが分かる名称にしたほうが安全です。ただし、属性名にどの言語を使うか、どの表記ルールにするかは、組織や案件内で統一する必要があります。

階層、施設区分、測点番号、点検ランク、撮影時刻のような情報は、Z値ではなく属性に分けるほうが基本です。Z値は高さとして扱い、意味の違う情報はproperties側に置くことで、GISや変換処理が座標として扱う値と、業務で判断するための値を分離できます。

GeoJSONのZ値は、位置そのものを表すための値として使うと整理しやすくなります。一方、判断や管理に必要な高さ関連情報は属性として補足することで、後工程での誤解を減らせます。Z値と属性の役割を分けることは、単なるデータ設計の話ではなく、現場の確認、共有、納品、再利用を安全にするための基本です。

注意点4として3D表示と実務精度を混同しない

GeoJSONにZ値を入れると、3D的に表示できる場面があります。点が上下方向に配置されたり、線が地形に沿って見えたり、面が立体的に見えたりすると、データの完成度が高く見えます。しかし、3D表示できることと、実務上の高さ精度が十分であることは同じではありません。ここを混同すると、見た目に引っ張られて誤った判断をしてしまいます。

3D表示は、データの傾向や位置関係を把握するには有効です。高低差のある現場を直感的に理解したり、写真位置と地形の関係を確認したり、構造物と周辺地物の上下関係を説明したりする場面では役立ちます。しかし、表示画面上でそれらしく見えているからといって、Z値が正しい基準で取得され、十分な精度で補正され、後工程の計算に使える状態であるとは限りません。

特に、3D表示では縦方向が強調されることがあります。わずかな高低差を見やすくするために上下方向の倍率が変更されている場合、実際よりも起伏が大きく見えることがあります。逆に、表示の都合で高低差が目立たなくなる場合もあります。見た目だけで危険箇所、勾配、段差、沈下、盛土量を判断するのは避けるべきです。実務判断では、数値の基準、取得精度、表示倍率、処理方法を確認する必要があります。

Z値の桁数と精度を混同しないことも大切です。GeoJSONの中に小数点以下の細かい値が入っていると、高精度なデータのように見えます。しかし、数値の桁が多いことは、測定精度が高いことを意味しません。測定方法、補正方法、現場条件、基準点の精度、データ変換の過程によって、実際に信頼できる桁は変わります。不要に細かい桁を残すと、利用者が過度に信頼してしまうことがあります。

Z値を使って差分を確認する場合も注意が必要です。過去データと現在データを重ねて高さ差を見る場合、両者の高さ基準が同じでなければ、差分は現場変化ではなく基準の違いを表している可能性があります。地形変化、構造物の沈下、施工後の出来形確認などでは、比較対象同士の基準、取得方法、処理条件をそろえることが前提になります。

面データにZ値を持たせる場合は、面の内部がどのように解釈されるかにも注意が必要です。頂点にZ値があるからといって、面全体の高さが正確に表現されるとは限りません。面の中間部分の高さは、表示や処理の方法によって補間されることがあります。複雑な地形や構造物を少ない頂点の面で表すと、実際の起伏や段差が表現されない場合があります。3D表示で面が見えていても、数量計算や詳細な高さ確認に使えるとは限らないのです。

線データでも同じような問題があります。道路、管路、境界線、移動軌跡などにZ値を入れると、縦方向の変化を表現できます。しかし、頂点間の高さ変化は処理の都合で単純な補間として扱われることがあり、実際の曲線的な変化や途中の段差を正確に表すには、十分な点密度が必要です。点数が少ないと、見た目には滑らかな線でも、実際の現場形状を表していないことがあります。

実務でZ値を使うなら、3D表示は確認手段の一つとして位置づけるべきです。最終判断は、データの取得条件、基準、精度、処理履歴、検査結果を合わせて行う必要があります。3Dで表示できることは便利ですが、それだけで施工判断、数量判断、点検判断、納品判断を行うのは避けるべきです。

GeoJSONのZ値は、視覚化と実務利用の橋渡しに役立ちます。しかし、3Dに見えることが正確さの証明になるわけではありません。見た目の分かりやすさと、数値としての信頼性を分けて考えることが、Z値を扱う上での重要な注意点です。

GeoJSONでZ値を扱うときの実務フロー

GeoJSONでZ値を安全に扱うには、ファイルを作る前の設計が重要です。いきなり座標に3つ目の値を入れるのではなく、まずZ値を使う目的を整理します。地図上で高さのある点を表示したいのか、現場写真と高さを紐づけたいのか、設計値と実測値を比較したいのか、3D表示で説明資料に使いたいのか、施工や点検の判断に使いたいのかによって、必要な精度や属性設計が変わります。

目的が決まったら、次にZ値の定義を決めます。仕様に沿ってWGS 84参照楕円体からの高さとして扱うのか、標高として扱うのか、測位で得た高さを補正した値として扱うのか、現場基準からの相対高さとして扱うのかを明確にします。ここで決めた内容は、ファイルの仕様、属性、作業手順の中に残す必要があります。担当者間で口頭共有するだけでは、後からデータを見た人が判断できません。

次に、属性設計を行います。Z値だけで十分なのか、設計高さや実測高さ、差分、測定日、測定方法、品質区分、垂直基準の名称などを属性として持たせる必要があるのかを検討します。高さに関する値が複数ある場合は、どれを座標のZ値にし、どれを属性にするのかを明確にします。同じ意味の値を複数箇所に持たせる場合は、どちらを正として扱うのかも決めます。

データ作成時には、すべての対象地物に対してZ値の有無が統一されているかを確認します。点だけにZ値があり、線や面にはない状態が意図したものなら問題ありません。しかし、意図せず一部の座標だけZ値が欠けている場合は、後工程で不具合につながります。特に複数のデータを結合した場合は、Z値の有無、基準、単位が混在しやすいため注意が必要です。

編集や変換を行う場合は、作業前後でZ値が維持されているかを確認します。地図上で同じ位置に表示されることだけを確認しても不十分です。座標配列の中に3番目の値が残っているか、数値が丸められていないか、一部の地物だけ2D化されていないかを確認します。必要であれば、処理前後のファイルを比較し、Z値の欠落や変化を検出できるようにしておくと安心です。

共有や納品の段階では、受け取り側がZ値を必要としているか、またZ値を保持して扱えるかを確認します。相手が2D表示だけを目的としている場合でも、高さ情報が重要であれば、属性として残す、別途説明を添える、元データを保管するなどの対応が必要です。Z値を使う前提のデータであれば、受け取り側にもZ値の基準と使い方を明示しなければなりません。

運用中の更新ルールも重要です。現場で再測定した場合、Z値を更新するのか、属性の実測高さだけを更新するのか、過去値を残すのかを決めておきます。更新ルールが曖昧だと、同じファイル内に古いZ値と新しい属性値が混在することがあります。更新者、更新日、更新理由を属性として残す運用も、後からデータを追跡する上で有効です。

GeoJSONを3D的に扱う場合でも、必ずしもすべての情報をGeoJSONだけに詰め込む必要はありません。点群、写真、図面、帳票、測定ログなど、他のデータと組み合わせて管理したほうが安全な場合もあります。GeoJSONは位置と属性を軽く扱うための形式として使い、詳細な高さ管理や検査根拠は別データで補うという考え方も実務的です。

重要なのは、GeoJSONを単独の完成データとして見るのではなく、現場で取得し、整理し、確認し、共有し、再利用する流れの中で位置づけることです。Z値はその流れの中で意味を持ちます。作成時の都合だけでなく、後工程で誰がどのように使うかを考えて設計することで、3D座標を含むGeoJSONをより安全に活用できます。

まとめ

GeoJSONに3D座標を入れること自体は難しくありません。座標配列に経度、緯度に続いてZ値を入れれば、点、線、面に高さ情報を持たせることができます。ただし、実務で重要なのは、Z値を入れられるかどうかではなく、そのZ値を正しく定義し、保持し、解釈し、後工程で安全に使えるかどうかです。

最初の注意点は、Z値の基準を必ず定義することです。仕様に沿った楕円体高として扱うのか、標高なのか、現場基準からの相対高さなのか、設計面との差分なのかが曖昧なままでは、同じ数値でも意味が変わります。単位、基準、補正状態、信頼できる桁を明確にしておくことで、受け渡し時の誤解を減らせます。

次の注意点は、2D前提の処理でZ値が落ちる可能性を考えることです。GeoJSONにZ値を入れても、編集、変換、保存、結合、分割の過程で3番目の値が消えることがあります。平面地図では問題なく見えるため、Z値の欠落は気づきにくいものです。作成直後だけでなく、処理工程ごとにZ値が残っているかを確認する運用が必要です。

さらに、高さ情報と属性情報の役割を分けることも重要です。Z値は位置情報として扱い、設計高さ、実測高さ、差分、測定条件、品質区分などは属性で補足することで、後工程での解釈が安定します。Z値と属性に似た値を重複して持たせる場合は、どちらを正として扱うのかを決めておく必要があります。

最後に、3D表示と実務精度を混同しないことです。Z値を入れると立体的に表示できる場合がありますが、見た目が正しそうに見えることと、測定精度や高さ基準が実務に耐えることは別です。3D表示は確認や説明には役立ちますが、施工判断、数量判断、点検判断には、基準、精度、処理履歴、元データの確認が欠かせません。

GeoJSONは、現場情報を軽く扱い、地図や属性と結びつける上で便利な形式です。一方で、Z値を含めた瞬間に、高さ基準、精度管理、データ欠落、属性設計、後工程の対応といった確認項目が増えます。3D座標を安全に扱うには、ファイル形式だけでなく、業務フロー全体でZ値を管理する視点が必要です。

現場で取得した位置情報や高さ情報を、写真、点検記録、図面、施工管理に無理なくつなげたい場合は、取得時点からZ値の意味を整理しておくことが大切です。GeoJSONに3D座標を入れる前には、見た目の3D化だけを目的にせず、現場で説明できるZ値として管理できるかを確認することが、実務で失敗しないための第一歩です。