等高線をGISやWeb地図、現場管理システムなどで利用するために、GeoJSONへ変換したい場面があります。GeoJSONは地物の形状と属性を一つのデータとして扱いやすく、等高線のような線データを共有するときにも利用できます。一方で、単純にファイル形式だけを変換すると、標高値が消える、属性名が変わる、座標位置がずれる、線が分割されるといった問題が起こることがあります。
特に注意したいのが、等高線そのものの形状が残っていても、標高を示す属性が欠落してしまうケースです。画面上では等高線らしい線が並んでいるため変換に成功したように見えますが、属性を確認すると標高値が空欄になっていることがあります。この状態では、標高による色分け、一定標高だけの抽出、標高ラベルの表示、解析処理などに使いにくくなります。
等高線をGeoJSONへ安全に変換するには、変換操作だけを見るのではなく、変換前のデータ構造、座標の扱い、属性型、線形状、変換後の検証までを一連の作業として考えることが重要です。特にRFC 7946に準拠したGeoJSONでは、水平座標はWGS 84を基準とする経度・緯度の十進度で扱い、座標順序は経度、緯度です。元データが平面直角座標などの投影座標であれば、利用目的に応じて適切に座標変換してから書き出す必要があります。
本記事では、実務担当者が等高線をGeoJSONへ変換するときに確認したいポイントを5つの手順に分け、属性欠落や位置ずれを防ぐ考え方を詳しく解説します。
等高線をGeoJSONへ変換する前に確認したい基本
等高線は、同じ標高の地点を結んだ線として地形を表現するデータです。紙図面では線の形と標高ラベルを目で確認できますが、デジタルデータでは線形状と標高値が別の情報として管理されていることがあります。そのため、GeoJSONへ変換するときには「線が変換されたか」だけではなく、「その線が何メートルの等高線なのかを示す属性まで引き継がれたか」を確認する必要があります。
一般的なベクトルデータでは、一つの等高線に対して線形状と複数の属性を持たせられます。たとえば標高、等高線種別、取得時期、データ作成区分、管理番号などです。GeoJSONのFeatureでも、線形状はgeometry、付随する属性はpropertiesとして保持できます。元データに標高値が属性として存在しているのであれば、それをGeoJSON側のpropertiesへ引き継ぐことで、変換後も標高別の検索や表示に利用できます。
ここで注意したいのは、画面上に表示されている標高文字が必ずしも等高線の属性とは限らないことです。標高文字が別の注記データとして保存されている場合、等高線自体には標高属性が入っていない可能性があります。逆に、画面上で標高ラベルを表示していなくても、属性には標高値が格納されていることがあります。
したがって、変換作業を始める前に確認すべき対象は見た目ではなくデータ構造です。線を選択したときに標高属性が確認できるか、すべての等高線に値が入っているか、標高値が数値として管理できる状態かを確認します。
また、GeoJSONでは座標の扱いにも注意が必要です。RFC 7946に準拠するGeoJSONの水平座標は、WGS 84を基準とする経度・緯度の十進度で、座標配列は経度、緯度の順です。元の等高線が平面直角座標などの投影座標で管理されている場合、その座標値をそのままRFC 7946準拠のGeoJSONとして扱うのではなく、元座標系を正しく定義したうえで必要な座標変換を行います。
一部のソフトウェアや閉じた運用では、当事者間の取り決めによって別の座標参照系をGeoJSON風のデータとして扱う例もあります。しかし、その方法は一般的なGeoJSONの相互運用性を下げるため、外部システムへ渡す場合は利用先の仕様とRFC 7946への準拠条件を確認することが重要です。
つまり、等高線のGeoJSON変換では、形状、属性、座標の3つを同時に管理する必要があります。どれか一つだけを確認しても十分ではありません。この基本を押さえたうえで、5つの手順を順番に進めていきます。
手順1 元データの形状と標高属性を確認する
最初の手順は、変換元となる等高線データの状態を確認することです。ここで問題を見落とすと、GeoJSONへの変換処理自体が正常に終了しても、実務では使いにくいデータになる可能性があります。
まず、対象データが線形状として管理されているか確認します。等高線はGeoJSONではLineString、または複数のLineStringを一つのgeometryとして保持するMultiLineStringなどで表現できます。元データによっては短い線分が大量に分割されていたり、複数線が一つの地物として格納されていたり、各頂点に3次元座標を持っていたりすることがあります。
次に重要なのが標高値の保存場所です。属性を確認し、標高に相当する項目を特定します。項目名はデータ作成方法によって異なるため、「標高」という名称だけを探すのではなく、元データの仕様や作成条件と照合して判断する必要があります。100、101、102のように一定間隔で値が並んでいても、それだけで標高項目だと断定しないことが大切です。
標高属性を特定したら、欠損値がないか確認します。一部の等高線だけ標高が空欄になっている場合、そのままGeoJSONへ変換しても、通常は元データにない値が自動的に正しく補われるわけではありません。欠損を見つけた場合は、変換前に原因を確認します。
標高が欠けている等高線を見つけた場合は、周囲の線から機械的に推測して入力する前に、その線の由来を確認します。等高線間隔が一定に見えても、補助曲線など別の表現が混在している可能性があります。標高属性は後工程の解析に直接利用されるため、不確かな値を埋めるより、未確認であることを明確にしたほうが安全な場合もあります。
さらに、標高属性が文字列なのか数値として管理されているのかを確認します。見た目が「100.0」であっても、元データでは文字列として保存されている場合があります。GeoJSONのpropertiesにはJSONで表現できる値を保持できますが、標高を大小比較や範囲抽出に使う予定であれば、数値として出力できる状態に整理しておくほうが扱いやすくなります。
元データで標高が「100m」のような単位付き文字列になっている場合は、数値部分と単位の扱いを整理します。標高値を100のような数値として持ち、単位や高さ基準をデータ仕様として明示すると、後工程での計算や検証がしやすくなります。
線形状についても確認が必要です。極端に短い線、同じ位置に重複している線、不自然に離れた場所へ飛んでいる線などがないか確認します。GeoJSONへの変換はデータ品質を自動的に改善する工程ではないため、元データの異常形状も基本的には引き継がれます。
この段階ではデータを変更し過ぎないことも大切です。変換前の確認と同時に線を統合したり削除したりすると、変換による問題と編集による問題を切り分けにくくなります。まず原本を保存したうえで作業用データを用意し、変換前の地物件数、属性項目、標高範囲、欠損件数などを記録しておくと検証しやすくなります。
たとえば変換前の等高線が2,500地物あり、最低標高が12.5、最高標高が187.5、標高欠損が0件であることが分かっていれば、変換後にも同じ観点で確認できます。こうした基準値を持っておくだけでも、属性欠落を早期に発見しやすくなります。
手順2 座標系と座標値の扱いを整理する
等高線をGeoJSONへ変換するときに、属性と同じくらい重要なのが座標です。標高属性が完全に残っていても、位置がずれていれば現場データとして利用できません。
まず、元の等高線がどの座標参照系で作成されているかを確認します。測量や設計、施工管理で扱われるデータでは、メートル単位の平面座標が使われることがあります。一方、RFC 7946に準拠したGeoJSONでは、水平位置はWGS 84を基準とする経度・緯度の十進度で表現します。そのため、元データが投影座標であれば、元の座標参照系を正しく把握したうえで、必要に応じてGeoJSON用の地理座標へ変換します。
ここで特に避けたいのが、元データに正しい座標参照系が設定されていない状態で変換を進めることです。座標参照系の情報が未設定でも、同じ作業環境では偶然正しく見える場合があります。しかし、誤った定義を与えて座標変換すると、全く異なる場所へ配置される原因になります。
「座標参照系を設定すること」と「座標値を変換すること」は区別して考えます。既存の座標値がどの座標参照系なのかを正しく定義する操作と、ある座標参照系から別の座標参照系へ数値自体を変換する操作は異なります。元データの座標参照系を誤って設定した状態で変換すると、位置ずれが大きくなる可能性があります。
まず元データがどの座標基準で作られたのかを確認し、その定義を正しく対応させます。その後、RFC 7946準拠のGeoJSONとして外部利用するのであれば、経度・緯度のWGS 84系へ適切に変換します。閉じたシステム内で別座標系を扱う場合は、相手側との取り決めと仕様を明示し、一般的なGeoJSONとの混同を避けます。
変換後の座標を確認するときは、等高線だけを見ないことも重要です。道路交差点、構造物角、既知点周辺など、位置を判断しやすい対象と重ねて確認します。広い範囲の等高線は、単独表示では一定量のずれに気付きにくい場合があります。
高さについては、等高線の標高属性とGeoJSON座標の第3要素を同一視しないことが重要です。RFC 7946では、座標配列の任意の第3要素はWGS 84楕円体に対する高さをメートルで表すものとされています。国内の測量や地形図で扱う標高が別の高さ基準に基づいている場合、その標高値を無条件に第3要素へ入れると、値の意味が仕様と一致しない可能性があります。
等高線は一つの線が同じ標高値を表すため、実務上の標高をpropertiesの属性として保持しておく方法が分かりやすく、相互運用性の面でも扱いやすいことがあります。第3座標値を使う場合は、元の高さ基準が何か、必要な高さ変換を行っているか、利用先が第3要素をどのように解釈するかを確認します。
この点は、位置の水平基準と高さ基準を分けて管理するうえで重要です。水平位置がWGS 84の経度・緯度になっていても、元の標高属性がどの高さ基準に基づくかは自動的には変わりません。属性として標高を保持する場合でも、単位と高さ基準を別途記録しておくと安全です。
GeoJSON化によって座標形式が変わる場合、小数点以下の桁数にも注意します。必要以上に座標を丸めると、細かな等高線形状が変化する可能性があります。反対に、元データの精度を超える桁数を残しても、元の測量精度が向上するわけではありません。
重要なのは、変換前の情報を必要な範囲で維持しつつ、利用目的に合った座標として保存することです。Web表示用の軽量化と、測量・施工管理に近い用途では求められる条件が異なるため、同じGeoJSONをすべての用途へ無条件に使い回すのではなく、用途を明確にして変換条件を決めます。
手順3 GeoJSONへ残す属性とデータ型を整える
3つ目の手順では、GeoJSONへ引き継ぐ属性を整理します。属性欠落を防ぐためには、すべての項目を無条件に残すより、必要な項目を明確にしたうえで変換するほうが管理しやすくなります。
最優先で確認するのは標高属性です。等高線をGeoJSONへ変換する目的が地形表示や標高による分類であれば、標高値は中心的な情報です。この項目がFeatureのpropertiesに保存されるようにします。
次に、実務上必要な管理属性を検討します。たとえば等高線の種別、測量時期、作成区分、データ管理番号、更新区分などです。ただし、社内管理用の不要な一時項目や、意味が確認できない作業途中の項目まで公開用GeoJSONへ含める必要はありません。
属性名にも注意します。GeoJSONのpropertiesはJSONオブジェクトであり、日本語のキーもJSONとしては表現できます。ただし、受け渡し先のシステムや後続処理によっては、文字種、文字数、予約語、命名規則など独自の制約がある場合があります。利用先が明確な場合は、その仕様に合わせます。
重要なのは、変換前後で属性名の対応関係が分かるようにしておくことです。たとえば変換元で「標高値」という項目だったものを変換時に別名称へ変更した場合、変換後に属性が消えたように見えることがあります。実際には名称が変わっただけでも、利用者がその対応を知らなければ属性欠落と同じような混乱が起こります。
そのため、可能であれば標高属性は変換作業の途中で何度も名称変更せず、一貫した名称で管理します。名称変更が必要な場合は、変換前の項目名と変換後の項目名を作業記録に残しておきます。
データ型についても確認します。JSONでは数値はnumberとして表現され、GeoJSON自体が整数型と浮動小数点型を別々の型名として定義しているわけではありません。ただし、変換元のGISやデータベースでは整数、実数、文字列などの型が分かれていることがあるため、小数を含む標高を欠落や丸めなしで出力できるよう、元データ側の型と変換設定を確認します。
元データで標高値が「100m」のように単位付き文字列として保存されている場合、そのままでは数値計算に向きません。標高属性には100のような数値を保存し、単位や高さ基準はデータ仕様や別属性として管理するほうが扱いやすくなります。
空欄と0の違いにも注意します。標高0メートルは意味を持つ値であり、属性が存在しない状態とは異なります。欠損値を一律に0へ置き換えてしまうと、本当に標高0の等高線と未入力の等高線を区別できなくなります。
変換前に欠損値がある場合は、その理由を確認します。必要に応じて根拠のある修正を行いますが、根拠なく0や周辺値を代入するのは避けます。GeoJSONのpropertiesではnullを値として扱えるため、欠損をnullとして保持するのか、属性自体を省略するのかなど、利用先の仕様も確認しておくと混乱を減らせます。
識別用のIDを残しておくことも有効です。変換前の各等高線に一意の管理番号があれば、変換後の同じ地物を追跡しやすくなります。GeoJSONのFeatureにはidを持たせることもできますが、運用上の追跡ではproperties内に明示的な管理IDを保持する方法もあります。利用先の仕様に合わせて、一貫した識別子を用意します。
一方で、変換処理や編集によって自動生成される内部番号は、常に同じ値が維持されるとは限りません。長期的な追跡に使うのであれば、作業者側で意味と一意性を管理できるIDを用意するほうが安全です。
さらに、不要な属性を整理するとGeoJSONの容量を抑えやすくなります。等高線は線の頂点数が多くなりやすく、広範囲では形状データだけでもファイルサイズが大きくなります。そこへ多数の長い文字列属性を付加すると、さらに容量が増えます。
ただし、軽量化を優先するあまり標高や管理IDまで削除してはいけません。まず「後で復元しにくい属性」と「表示だけに使う一時的な属性」を区別し、重要情報を残したうえで不要項目を整理します。
この手順を丁寧に行うことで、GeoJSON化したあとに「線はあるが何メートルの等高線か分からない」という最も避けたい状態を防ぎやすくなります。
手順4 等高線をGeoJSONとして書き出す
元データ、座標、属性の準備ができたら、実際にGeoJSONへ書き出します。使用する変換環境によって操作画面は異なりますが、実務上確認すべき考え方は共通しています。
書き出し対象として、まず等高線レイヤーを正しく選択します。複数の線レイヤーが存在する場合、道路線や境界線などを誤って含めないようにします。画面上で同時表示されていることと、書き出し対象になっていることは別なので、出力対象を明確に確認します。
次に、GeoJSONへ含める属性を確認します。変換機能によっては、すべての属性を引き継ぐ場合もあれば、選択した項目だけを書き出せる場合もあります。標高属性、管理ID、必要な分類属性が対象に入っていることを確認します。
変換前に属性名や型を整理した場合は、その状態が書き出し設定に反映されているかを確認します。作業途中で一時ファイルを経由すると、そこで属性が省略されたり表現が変わったりすることがあります。
特に注意したいのが、等高線を一度別形式へ変換し、その後GeoJSONへ変換するような多段階処理です。中間形式が元の属性を保持できなければ、GeoJSONへの最終変換時にはすでに属性が失われています。最終ファイルだけを確認するとGeoJSON変換が原因に見えますが、実際には中間工程で欠落していることがあります。
可能であれば変換工程を単純化し、元データから直接GeoJSONへ書き出します。中間工程が必要な場合は、それぞれの段階で標高属性、管理ID、地物件数などを確認します。
座標変換を同時に行う場合は、出力側の座標条件を再確認します。RFC 7946準拠のGeoJSONとして出力するのであれば、水平座標はWGS 84の経度・緯度で、座標順序は経度、緯度です。平面直角座標などの値を、座標系の説明なしにそのままGeoJSONへ書き出して外部へ渡す運用は避けます。
経度と緯度の順序にも注意が必要です。一般的な会話では「緯度・経度」と呼ぶことが多い一方、GeoJSONの座標配列では経度に相当する値が先、緯度に相当する値が後です。手作業でデータを生成したり別システムから受け渡したりするときに順序を入れ替えると、誤った位置へ表示されます。
第3座標値を出力する場合も意味を確認します。RFC 7946では第3要素はWGS 84楕円体に対する高さをメートルで表すため、元データの標高が別の高さ基準なら、そのまま第3要素へ流用しないようにします。等高線の実務上の標高はpropertiesに保持し、必要に応じて高さ基準を明示する運用が安全です。
等高線の線形状については、LineStringとして保存される場合と、MultiLineStringとして複数の線を一つのgeometryに保持する場合があります。どちらが必ず正しいというわけではなく、元データの構造と利用目的に応じて判断します。
ただし、変換によって一つの等高線が意図せず細かく分割された場合は注意が必要です。同じ標高値を持っていれば表示上は問題なく見えても、地物数が大幅に増え、後工程の選択や解析が複雑になることがあります。
反対に、同じ標高だからという理由だけで離れた複数の等高線を一つに統合すると、個別地物として管理したい場合に不便になることがあります。標高属性が同じであることと、一つの線地物として扱うべきことは同じではありません。
書き出しが完了した時点では、まだ作業完了と判断しません。ファイルが正常に生成され、エラーが表示されなかったとしても、属性や地物の一部が欠落している可能性があります。GeoJSON変換では、書き出した後の検証までを一連の工程として扱います。
手順5 変換後に形状・標高・属性件数を照合する
5つ目の手順では、完成したGeoJSONを読み込み直し、変換元と比較します。属性欠落を防ぐには、この照合作業を省略しないことが重要です。
最初に確認するのは地物件数です。変換前の等高線が2,500地物だったのであれば、変換後の件数を確認します。ただし、LineStringとMultiLineStringの変換方法や分割・統合の有無によって件数が変わる場合もあるため、件数が一致しないことだけで直ちに失敗とは判断しません。
件数が変化した場合は、なぜ変化したのかを説明できる状態にします。一つの複合形状が複数のFeatureへ展開されたのか、複数線がまとめられたのか、それとも本当に一部が欠落したのかを確認します。
次に標高属性を確認します。変換前に確認した最低標高と最高標高が変換後にも存在するか、代表的な中間標高も残っているかを確認します。最低値と最高値だけが一致していても、中間の一部が欠落している可能性があるため、標高別の件数や複数地点を確認するとより確実です。
さらに、標高属性が欠損している地物数を確認します。変換前に欠損が0件だったのに、変換後にnullや属性欠落が発生していれば、変換設定やデータ型の扱いを見直す必要があります。
標高値が数値として保持されているかも確認します。変換前に数値だったものが、変換後に文字列になっていると、並べ替えや条件抽出で期待どおりの結果にならない場合があります。実際に後工程で行う操作を一度試すことで、データ型の問題を早期に発見できます。
たとえば数値として2、10、100を並べ替える場合と、文字列として並べ替える場合では結果が異なることがあります。見た目が同じ数字でも、利用先での解釈が同じとは限らないため、表示だけでなく操作結果も確認します。
形状については、変換元と変換後の等高線を重ねて確認します。山頂部、谷部、急傾斜部、等高線が密集する場所などを重点的に見ます。変換処理の途中で意図しない単純化や頂点削減が入ると、曲線が直線的になったり、細かな地形表現が失われたりする可能性があります。
元データに存在する等高線の特徴的な屈曲部を複数選び、GeoJSONでも同じ位置に同じ形状で存在するか確認すると効果的です。
位置については、既知の地物や基準となるデータと重ねます。等高線全体が一定方向へずれている場合は、元座標参照系の設定や座標変換を疑います。大きく異なる位置へ表示される場合は、経度・緯度の順序や変換前後の座標値を確認します。
一部だけが異常な位置へ飛んでいる場合は、元データ側の異常座標や不正な頂点がそのまま変換された可能性があります。この場合はGeoJSONだけを修正するのではなく、元データまで戻って原因を確認したほうが、再変換や更新時の再発を防ぎやすくなります。
管理IDを残している場合は、変換前後でIDを照合します。件数が一致していても、特定のIDが消えて別のIDが重複していれば問題があります。一意のIDを利用した照合は、見た目だけでは発見しにくい欠落を確認するうえで有効です。
第3座標値を出力した場合は、その値が意図した高さ基準になっているかも確認します。等高線のpropertiesに持たせた標高と第3座標値は、基準が異なれば数値が一致しないことがあります。両者を同じ「標高」として扱わないよう、データ仕様を明確にします。
最後に、実際の利用環境でGeoJSONを開きます。作成した環境では正しく見えても、受け渡し先で属性や座標の解釈が異なる可能性があります。最終的に利用するシステムへ読み込み、等高線の位置、標高属性、ラベル表示、検索、選択など、予定している操作が行えることを確認します。
変換完了の基準は「GeoJSONファイルが作成されたこと」ではありません。「必要な形状、位置、標高属性が保持され、利用先で目的どおり扱えること」を確認して初めて完了と考えることが重要です。
等高線の属性欠落が起こりやすい原因
等高線のGeoJSON変換で属性が欠落する原因は、変換機能そのものだけとは限りません。むしろ、元データの構造や中間工程に原因があるケースもあるため、どの段階で情報が失われたのかを切り分ける必要があります。
代表的なのは、標高が属性ではなく注記として管理されているケースです。図面上では各等高線に100、105、110といった数字が表示されていても、それが線とは独立した文字データであれば、線だけをGeoJSONへ変換しても数字はpropertiesに入りません。
この場合、変換後に属性が消えたのではなく、元の線データに標高属性が存在していなかったことになります。変換前の属性確認が重要なのはこのためです。
次に、変換対象の属性を限定する設定による欠落があります。ファイル容量を減らすために不要項目を削除した際、標高項目まで対象外にしてしまうことがあります。似た名称の属性が複数ある場合も注意が必要です。
たとえば作業用標高、設計標高、取得標高など複数の高さ項目がある場合、どれをGeoJSONへ残すべきか判断せずに整理すると、必要な値を削除する可能性があります。属性を減らす前に、それぞれの意味と高さ基準を確認します。
データ型の変換も原因になります。元データの属性仕様と変換先の扱いが異なる場合、値が文字列化されたり、nullの扱いが変わったり、小数値が意図せず丸められたりする可能性があります。元データに独自の型や複雑な内部属性がある場合は、必要情報をJSONで扱いやすい数値、文字列、真偽値、nullなどへ整理してから変換するほうが安全なことがあります。
項目名の問題もあります。利用先に独自の制約がある場合、長い名称や特定の文字を含む属性名が変換や読込時に変更されることがあります。属性自体は存在していても、別名称になったことで欠落したように見える場合があります。
中間ファイルを経由する処理にも注意が必要です。元データから中間形式へ変換した時点で属性が失われ、その後GeoJSONへ変換している場合、最終工程の設定を変更しても属性は戻りません。
原因を調査するときは、元データ、中間データ、最終GeoJSONの順に同じ等高線を追跡すると分かりやすくなります。管理IDがあれば、そのIDを使って各工程の属性を比較できます。
さらに、選択地物だけを書き出していたという操作ミスもあります。画面上で一部の等高線を選択した状態のまま、選択対象だけをGeoJSONへ書き出す設定にすると、属性欠落ではなく地物そのものの欠落が発生します。
フィルターが有効になっている場合も同様です。標高範囲や区域で一時的に絞り込んでいた状態を忘れ、そのまま出力すると一部の等高線しか含まれません。変換前後の件数確認が、この種のミスを発見するために役立ちます。
属性欠落の原因を探す際には、いきなり再変換を繰り返すのではなく、「元データにはあるか」「中間段階ではあるか」「最終GeoJSONではあるか」という順序で確認します。問題が発生した工程を特定できれば、不要な修正を減らせます。
GeoJSON化した等高線を実務で使いやすくする方法
GeoJSONへ変換した等高線は、単に保存するだけでなく、現場確認、施工記録、地形把握、Web上での共有などさまざまな用途へ展開できます。そのため、変換時には目の前の表示だけでなく、後で誰がどのように利用するのかを考えて属性を設計しておくと便利です。
まず重要なのが、標高値の意味を一貫させることです。同じデータ内で異なる単位が混在したり、異なる高さ基準の値が同じ属性に混ざったりすると、見た目では気付きにくい問題につながります。単位や高さ基準はデータ作成時のルールとして統一し、利用者が確認できるようにします。
特に、GeoJSONの水平座標がWGS 84であることと、propertiesに保存した実務上の標高の基準は別問題です。標高属性がどの基準に基づく値かをメタデータや運用資料で明確にしておくと、第3座標値や他の高さデータとの混同を防ぎやすくなります。
また、等高線だけで地形判断を完結させないことも大切です。等高線は地形を読み取るうえで有効ですが、元になった測量データの精度、取得時期、地形変化の有無によって現況との一致度は変わります。
造成工事、掘削、盛土、法面工事、災害復旧などで地形が変化した場所では、過去に作成した等高線を最新地形として扱わないよう注意します。GeoJSONへ変換したことでデータが新しくなるわけではなく、元データの取得時点は変わりません。
そのため、管理属性として測量日や作成日を持たせられる場合は、利用時の判断材料になります。更新を繰り返す場合には、同じファイル名で上書きするだけでなく、いつの地形を示す等高線なのか区別できる運用が有効です。
現場で複数の担当者が利用する場合は、データ名称の統一も重要です。「最新」「修正版」「最終」のような曖昧な名称を繰り返すと、どれを使用すべきか判断しにくくなります。区域、取得日、更新区分などを組み合わせ、後から見ても識別しやすい名称にすると管理しやすくなります。
GeoJSONの軽量化が必要な場合は、属性削除だけでなく利用範囲や形状の詳細度も見直します。広大な区域の等高線を一つのファイルにまとめるより、作業区域ごとに分割したほうが現場では扱いやすいことがあります。
ただし、区域境界で等高線を分割すると、同じ等高線が複数ファイルに分かれるため、データ統合時には注意が必要です。元データを保管したうえで、用途別に派生データを作成する考え方が安全です。
形状の単純化を行う場合も同様です。表示速度を改善するために頂点数を減らすことはできますが、等高線は地形形状を表す情報です。頂点を減らし過ぎると、尾根や谷、法面などの細かな変化が失われる可能性があります。
特に施工管理や測量成果に近い用途では、表示速度だけを理由に元の形状を大きく変えるのは避け、原本と表示用データを分けて管理するとよいでしょう。単純化した場合は、元データとの差を確認し、用途に支障がない範囲であることを検証します。
GeoJSONを他の現場データと組み合わせる場合には、水平位置だけでなく高さの基準も確認します。GeoJSONの水平座標がWGS 84に統一されていても、等高線の標高、測点の高さ、施工記録の高さが異なる基準であれば、そのまま比較できない場合があります。
データを共有する際には、GeoJSONというファイル形式だけを伝えるのではなく、対象区域、取得時期、標高属性名、標高単位、高さ基準、更新履歴なども合わせて管理すると、利用者の誤解を減らせます。
また、等高線の更新作業を継続する現場では、変換手順を標準化することが有効です。担当者ごとに属性名や座標変換方法が異なると、時期によってGeoJSONの構造が変わり、比較や統合が難しくなります。
変換前に確認する標高属性、出力時の座標条件、残す属性、検証する代表地点などを作業手順として決めておけば、担当者が変わっても同じ観点で品質を確認しやすくなります。
まとめ
等高線をGeoJSONへ変換する作業では、ファイル形式を変更する操作そのものより、変換前後の情報を正しく維持することが重要です。特に標高属性が欠落すると、線の形は残っていても等高線としての利用価値が大きく低下します。
最初に元データの線形状と標高属性を確認し、標高が本当に線の属性として保存されているかを確かめます。次に元データの座標参照系を確認し、RFC 7946準拠のGeoJSONとして扱う場合は、WGS 84を基準とする経度・緯度の座標へ適切に変換します。そのうえでGeoJSONへ残す属性とデータ型を決め、標高や管理IDなど後から復元しにくい情報を確実に引き継ぎます。
高さについては、実務上の標高属性とGeoJSON座標の第3要素を混同しないことが重要です。RFC 7946の第3要素はWGS 84楕円体に対する高さをメートルで表すため、別の高さ基準で作成された等高線の標高を無条件にZ値へ入れないようにします。実務上の標高はpropertiesに保持し、単位や高さ基準を明示すると安全です。
書き出し時には対象レイヤー、属性、座標条件を確認し、中間形式を経由する場合は各段階で属性が残っているかを確認します。そして変換後には、地物件数、標高範囲、欠損値、属性型、線形状、位置を元データと照合します。
この5手順を一連の作業として行えば、「GeoJSONファイルは作れたが標高が入っていない」「別システムで開いたら位置がずれた」「一部の等高線だけ消えていた」といったトラブルを減らしやすくなります。
等高線は地形を把握するための重要な情報ですが、実務では等高線だけでなく、現場写真や測点、施工状況、確認日時などの記録と組み合わせて利用する場面があります。データを変換するときも、最終的にどの現場情報と関連付けるのかまで考えて管理すると、更新や確認がしやすくなります。
現場で取得した写真や位置情報、施工記録を整理しながら地理情報と関連付けたい場合には、LRTK Phoneを活用することで、現地での記録と位置情報を一体的に管理しやすくなります。等高線をGeoJSONとして整備する作業と、現場で蓄積する位置付きの記録を適切に組み合わせることで、地形データを閲覧資料だけでなく、施工状況の確認や現場情報の共有に活用しやすい形で運用できます。