GeoJSONのGeometryCollectionで迷わない使い分け4例

GeoJSONを扱っていると、Point、LineString、Polygon、MultiPolygonなどは比較的イメージしやすい一方で、GeometryCollectionをどの場面で使うべきか迷うことがあります。便利そうに見える反面、使いすぎるとデータ構造が読みづらくなり、地図表示、属性管理、検索、編集、変換の工程で扱いにくくなることもあります。本記事では、geojsonを実務で扱う担当者向けに、GeometryCollectionの基本的な考え方と、使い分けに迷いやすい4つの例を整理します。

目次

• GeometryCollectionとは何をまとめる形式なのか

• 使い分け例1：1つの施設を点・線・面でまとめたい場合

• 使い分け例2：調査結果を一時的にまとめて受け渡す場合

• 使い分け例3：編集単位と表示単位が違う場合

• 使い分け例4：変換や出力の都合で複数形状が残る場合

• GeometryCollectionを避けたほうがよい場面

• FeatureCollectionやMulti系ジオメトリとの違い

• 実務で迷わない判断基準

• 現場データ管理では取得時点の整理も重要

GeometryCollectionとは何をまとめる形式なのか

GeometryCollectionは、GeoJSONの中で複数種類のジオメトリを1つのgeometryとしてまとめるための形式です。通常、Pointは点、LineStringは線、Polygonは面というように、1つのgeometryには1種類の形状を入れます。一方でGeometryCollectionでは、Point、LineString、Polygonなどの異なるジオメトリを、同じgeometryの中にまとめて持つことができます。

たとえば、ある現場設備を表すときに、設備の代表位置は点で表したい、設備の管理範囲は面で表したい、接続する通路や配管の中心線は線で表したい、というケースがあります。このように、1つの対象を説明するために複数の形状が必要になる場合、GeometryCollectionを使うと、それらを1つのまとまりとして表現できます。

ただし、GeometryCollectionは「何でも入れられる便利な箱」と考えると危険です。GeoJSONを扱う実務では、形状そのものだけでなく、属性、編集、検索、表示、変換、ファイルサイズ、座標系、運用ルールまで含めて考える必要があります。GeometryCollectionに複数形状を詰め込むと、見た目には1つのFeatureとして扱えても、中に入った個々の形状に別々の属性を持たせにくくなります。

GeoJSONでは、属性情報は通常Featureのpropertiesに入ります。つまり、GeometryCollectionの中に点、線、面を入れても、それぞれのジオメトリごとに独立したpropertiesを自然に持たせる構造ではありません。もちろん、properties内に独自の対応表を作ることはできますが、その場合は読み取る側の実装に依存しやすくなります。標準的な地図表示やデータ変換の流れでは、個々のジオメトリに直接属性が付いているほうが扱いやすいことが多いです。

そのため、GeometryCollectionは「複数の形状をまとめる必要があり、かつそれらを同じ属性・同じ管理単位として扱ってよい場合」に向いています。逆に、点ごと、線ごと、面ごとに名称、状態、更新日、管理者、点検結果などを別々に管理したい場合は、GeometryCollectionではなく、複数のFeatureに分けてFeatureCollectionで扱うほうが安全です。

実務で重要なのは、データを作る時点だけでなく、その後に誰がどのように使うかを考えることです。画面に表示するだけなら問題なく見えても、検索したい、編集したい、集計したい、別形式へ変換したい、現場で再利用したいとなった瞬間に、GeometryCollectionの中身が扱いづらくなることがあります。GeometryCollectionを選ぶ前に、そのデータが単なる表示用なのか、台帳管理にも使うのか、現場で更新されるのか、他のシステムへ渡すのかを確認しておくと失敗を減らせます。

使い分け例1：1つの施設を点・線・面でまとめたい場合

GeometryCollectionが比較的自然に使える例の1つが、1つの施設や対象物を複数の形状で表す場合です。たとえば、公園、設備エリア、仮設ヤード、管理施設、道路付属物のまとまりなどでは、代表点、管理範囲、関連する線形を同時に持ちたいことがあります。代表点はラベル表示や一覧検索に使い、面は範囲確認に使い、線は接続経路や中心線の確認に使うというように、用途が分かれることがあります。

このとき、点、線、面がすべて同じ施設を表しており、名称や管理番号、担当部署などの属性も共通でよいなら、GeometryCollectionを使う考え方は成立します。1つのFeatureのpropertiesに施設名、施設ID、種別、更新日などを持たせ、geometryとしてGeometryCollectionを入れることで、「このFeatureは1つの施設を表す」と整理できます。

この使い方の利点は、対象のまとまりが分かりやすいことです。データを見る人は、1つのFeatureを選択したときに、その施設に関係する複数の形状をまとめて確認できます。代表点だけをクリックしたつもりでも、同じ施設の範囲や関連線が一緒に選択されるような扱いにできれば、利用者にとって理解しやすい場面もあります。

ただし、この使い方にも注意点があります。点、線、面のいずれかだけを個別に更新したい場合や、それぞれに異なる状態を持たせたい場合には、GeometryCollection内で完結させると管理が難しくなります。たとえば、代表点は現地確認済み、面は未確定、線は設計変更中というように状態が分かれるなら、それぞれを別Featureにしたほうが自然です。

また、地図表示のスタイル設定にも注意が必要です。点、線、面は表示方法が異なります。点はアイコンや円で表示し、線は色や太さを指定し、面は塗りと境界線で表します。GeometryCollectionを1つのFeatureとして扱う場合、表示側が中のジオメトリ種類に応じて適切に描き分けられる必要があります。対応が弱い環境では、一部の形状だけ表示されない、スタイルが期待どおり反映されない、選択範囲が分かりにくいといった問題が起きることがあります。

施設を点・線・面でまとめたい場合は、まず「これは本当に1つの対象なのか」を確認するとよいです。同じ施設を補足的に表す複数形状であり、属性も共通でよく、更新単位も大きく変わらないならGeometryCollectionを検討できます。一方で、形状ごとに意味や管理責任が異なるなら、無理にまとめず、FeatureCollection内で複数Featureとして表現したほうが後工程で扱いやすくなります。

実務では、GeometryCollectionを使う場合でも、propertiesに「代表形状の種類」や「データ用途」を入れておくと運用しやすくなります。たとえば、主に検索で使う代表点が含まれているのか、範囲確認用の面が主なのか、表示補助として線が入っているのかを属性で示しておくと、後からデータを確認する人が判断しやすくなります。GeoJSONはシンプルに見える形式ですが、長く使うデータほど、意味の分かる属性設計が効いてきます。

使い分け例2：調査結果を一時的にまとめて受け渡す場合

GeometryCollectionは、確定した台帳データよりも、一時的な調査結果や中間データをまとめる場面で使いやすいことがあります。現場調査や机上確認の過程では、まだ点、線、面のどれとして整理すべきか決まっていない情報が混在することがあります。ある場所は点で記録し、別の場所は線で範囲を示し、さらに別の箇所は面で囲っておく、といった状況です。

たとえば、現地で気になる箇所を記録する際、ひび割れの位置は線、陥没の範囲は面、写真撮影位置は点として残すことがあります。これらが最終的には別々のレイヤーや台帳に整理されるとしても、調査直後の共有用データとしては、1つのまとまりにして渡したいことがあります。このような一時的な受け渡しでは、GeometryCollectionが役立つ場合があります。

ただし、この場合も「一時的」という位置づけを明確にしておくことが大切です。GeometryCollectionに入れたまま正式データとして長期運用し始めると、後から分類や属性付けを行うときに手間が増えることがあります。調査メモ、一次判定、レビュー用、変換前データなど、用途をpropertiesに明記しておくと、正式な台帳データと混同しにくくなります。

一時データでGeometryCollectionを使う利点は、調査時点のまとまりを崩さずに共有できることです。たとえば、1つの点検対象に対して、異常箇所の点、影響範囲の面、確認ルートの線がある場合、それらを1つのFeatureにまとめれば、点検対象単位でデータを受け渡せます。受け取る側は、1つの対象に関連する複数の形状を同時に確認できます。

一方で、集計や抽出には弱くなりやすいです。たとえば、すべての面だけを抽出したい、線の長さだけを集計したい、点の件数だけを数えたいという処理では、GeometryCollectionの中を分解して確認する必要があります。通常のFeatureCollectionで点、線、面が別Featureになっていれば、ジオメトリ種類ごとの処理は比較的単純です。GeometryCollectionでは、見た目上は1つのFeatureでも、中に複数種類のgeometryが含まれるため、処理側で追加の分岐が必要になります。

このため、調査結果を一時的にまとめる場合は、次の工程でGeometryCollectionを解体する前提を持っておくと安全です。レビュー時はGeometryCollectionでまとまりを保ち、正式登録時には点、線、面を別Featureに分ける、といった流れです。これにより、現場の記録しやすさと、後工程の管理しやすさを両立できます。

また、一時的なデータであっても、座標の精度や位置の意味は明確にしておく必要があります。点が代表位置なのか、写真位置なのか、異常箇所の中心なのかによって、同じPointでも意味が変わります。線が移動経路なのか、ひび割れなのか、境界の一部なのかも重要です。GeometryCollectionにまとめると、形状の意味がpropertiesだけでは伝わりにくくなることがあるため、属性名や説明文で補う工夫が必要です。

使い分け例3：編集単位と表示単位が違う場合

GeometryCollectionで迷いやすい場面に、編集単位と表示単位が異なるケースがあります。地図上では1つの対象として見せたいが、内部的には複数の形状を持っているという状況です。たとえば、利用者には「1つの工区」「1つの設備」「1つの点検対象」として表示したい一方で、その対象は点、線、面の組み合わせで構成されていることがあります。

表示単位を優先するなら、GeometryCollectionで1つのFeatureとしてまとめる考え方があります。地図上で対象を選択したときに、関連する点、線、面を一括で選択できるため、利用者には分かりやすく見える場合があります。特に、閲覧中心の用途では、データ構造よりも画面上の理解しやすさが重視されることがあります。

しかし、編集単位を考えると話は変わります。点の位置だけを修正したい、線形だけを更新したい、面の範囲だけを差し替えたいという作業が頻繁に発生するなら、GeometryCollectionのまま編集するより、形状ごとにFeatureを分けたほうが作業しやすくなります。GeometryCollection内の一部だけを編集できる環境もありますが、すべての運用環境で同じように扱えるとは限りません。

編集履歴の管理にも違いが出ます。1つのGeometryCollectionに複数形状を入れている場合、どの形状がいつ変更されたのかを細かく追いにくくなることがあります。propertiesに更新日を1つだけ持たせると、点を更新したのか、線を更新したのか、面を更新したのかが分かりません。編集単位が重要なデータでは、形状ごとにFeatureを分け、それぞれに更新者、更新日、確認状況などを持たせるほうが実務的です。

一方で、表示用にまとめたい需要もあります。その場合は、管理用データと表示用データを分ける考え方が有効です。管理用には点、線、面を別Featureとして保持し、表示用に必要なときだけGeometryCollectionを生成するという流れです。これなら、日常の編集や台帳管理は分かりやすく保ちつつ、閲覧画面では1つの対象として見せることができます。

この考え方は、GeoJSONを単なるファイル形式として見るのではなく、データ運用全体の中で見ることにつながります。編集しやすい構造と表示しやすい構造は、必ずしも同じではありません。GeometryCollectionは表示単位をまとめるには便利ですが、編集単位を細かく扱いたい場合には向かないことがあります。

実務担当者が判断するときは、「誰がどこで編集するのか」を先に確認するとよいです。現場担当者が頻繁に位置を更新するのか、管理者が承認後に固定するのか、閲覧者は見るだけなのかによって、適した構造は変わります。閲覧中心で、対象を一括選択できることが重要ならGeometryCollectionが候補になります。編集中心で、形状ごとの更新や承認が重要なら、別Featureとして整理するほうが安全です。

使い分け例4：変換や出力の都合で複数形状が残る場合

GeometryCollectionは、意図して設計する場合だけでなく、データ変換や出力の結果として現れることもあります。別の形式からGeoJSONへ変換したとき、元データの1レコードに複数種類の形状が含まれていると、GeometryCollectionとして出力されることがあります。また、図面由来のデータや現場記録のデータでは、1つの対象に点、線、面が混在していることがあり、変換時にそれらを1つにまとめる処理が行われる場合があります。

このようなGeometryCollectionは、必ずしも悪いものではありません。変換元の構造をなるべく崩さずにGeoJSON化した結果として、自然に発生することがあります。問題は、そのまま後工程で使ってよいかを確認せずに運用してしまうことです。変換直後のGeoJSONは、表示できるから正しいとは限りません。中にどのようなgeometryが含まれているか、属性との対応が保たれているか、表示・検索・編集に支障がないかを確認する必要があります。

特に注意したいのは、GeometryCollectionの中にさらに複雑な形状が含まれている場合です。Polygon、MultiPolygon、LineString、MultiLineStringなどが混在していると、表示上は問題なく見えても、面積計算や長さ計算、重なり判定、範囲検索などの処理で想定外の結果になることがあります。処理側がGeometryCollectionを十分に考慮していない場合、一部の形状だけが対象になったり、逆に全体を一括処理して意味が曖昧になったりします。

変換や出力の都合でGeometryCollectionができた場合は、まず中身を確認し、正式な利用目的に合わせて整理することが大切です。閲覧用にそのまま使うのか、形状ごとに分解するのか、代表形状だけを残すのか、属性を分けて再構成するのかを判断します。この工程を省くと、後から「なぜ検索に出てこないのか」「なぜ集計数が合わないのか」「なぜ一部だけ表示されないのか」といった問題につながります。

また、変換元のデータでは1つの図形グループとして扱われていても、GeoJSON上ではFeatureとgeometryの考え方に合わせて再設計したほうがよい場合があります。図面上のまとまりとGISデータ上の管理単位は同じとは限りません。図面では見た目を整えるために複数要素をまとめていても、GISではそれぞれを別の地物として扱うほうが自然なことがあります。

この例でGeometryCollectionを使う場合は、「変換結果として残しているだけなのか」「運用上の意味があって採用しているのか」を区別することが重要です。前者であれば、正式登録前に整理する対象として扱うべきです。後者であれば、なぜGeometryCollectionである必要があるのかをデータ仕様に書いておくと、後から関係者が迷いにくくなります。

GeoJSONを受け取る側の実務では、GeometryCollectionが含まれていたら、まず警戒するくらいでちょうどよいです。エラーと決めつける必要はありませんが、処理や運用に影響しやすい形式であることは確かです。受領データのチェック項目として、GeometryCollectionの有無、含まれるジオメトリ種類、属性の意味、後工程での扱い方を確認しておくと、トラブルを早めに防げます。

GeometryCollectionを避けたほうがよい場面

GeometryCollectionは便利な形式ですが、実務では避けたほうがよい場面も多くあります。代表的なのは、形状ごとに属性を分けたい場合です。たとえば、点には撮影日時、線には延長、面には面積や区域名を持たせたい場合、GeometryCollectionにまとめると属性構造が複雑になります。propertiesに独自の配列や対応表を入れて管理する方法もありますが、読み取る側がその独自仕様を理解していなければ正しく使えません。

また、検索やフィルタリングを重視する場合も注意が必要です。点だけを検索したい、面だけを抽出したい、線だけを一覧化したいといった操作では、GeometryCollectionの中身まで見に行く必要があります。一般的な運用では、Feature単位で検索や選択を行うことが多いため、1つのFeatureの中に複数種類のgeometryが入っていると、検索条件の設計が複雑になります。

編集頻度が高いデータにも向きません。現場で位置を修正する、属性を更新する、承認ステータスを変える、差し戻しを行うといった運用では、編集単位が明確であることが重要です。GeometryCollectionにまとめると、どの部分を編集対象とするのか、どの部分が承認済みなのかが分かりにくくなることがあります。

さらに、外部とのデータ連携が多い場合も慎重に考える必要があります。GeoJSONを読み込む環境のすべてがGeometryCollectionを同じように扱えるとは限りません。仕様上は存在する形式でも、表示、編集、変換、スタイル設定、空間解析の各機能で対応状況が異なることがあります。相手先の処理環境が分からない場合は、できるだけ単純なPoint、LineString、Polygon、またはMultiPoint、MultiLineString、MultiPolygonで整理したほうが安全です。

GeometryCollectionを避けるべきか判断するには、後工程の処理を想像することが有効です。面積を計算する必要があるのか、長さを集計するのか、点の件数を数えるのか、地物ごとに台帳を作るのか、現場で再編集するのか。これらの処理があるなら、GeometryCollectionではなく、形状ごとにFeatureを分けるほうが扱いやすくなります。

特に、正式な管理台帳や長期保管データでは、分かりやすさと再利用性が重要です。GeometryCollectionはデータ作成者にとっては便利でも、数か月後、数年後に別の担当者が見ると意図が分かりにくいことがあります。なぜ複数形状が1つにまとまっているのか、どの形状が主でどれが補助なのか、どれを更新してよいのかが曖昧になりやすいからです。

そのため、GeometryCollectionは標準形として常用するよりも、必要な場面で限定的に使う形式と考えるのが実務的です。単純な構造で表せるなら、無理にGeometryCollectionを使う必要はありません。データは複雑にできるからよいのではなく、使う人が迷わず扱えることが大切です。

FeatureCollectionやMulti系ジオメトリとの違い

GeometryCollectionを正しく使い分けるには、FeatureCollectionやMulti系ジオメトリとの違いを理解しておく必要があります。名前が似ているため混同しやすいですが、それぞれ役割が異なります。

FeatureCollectionは、複数のFeatureをまとめるための入れ物です。各Featureは、それぞれgeometryとpropertiesを持てます。つまり、点、線、面を別々のFeatureとして持たせ、それぞれに別の属性を付けられます。実務で複数の地物を扱う場合は、FeatureCollectionが基本になります。点検箇所、道路区間、管理範囲、撮影位置などをそれぞれ独立した地物として扱いたいなら、FeatureCollectionで複数Featureに分けるのが自然です。

一方、GeometryCollectionは、1つのgeometryの中に複数のgeometryを入れる形式です。FeatureCollectionがFeatureの集合であるのに対し、GeometryCollectionはgeometryの集合です。この違いは属性管理に大きく影響します。FeatureCollectionではFeatureごとにpropertiesを持てますが、GeometryCollectionでは中の各geometryに標準的なpropertiesを持たせる構造ではありません。

MultiPoint、MultiLineString、MultiPolygonのようなMulti系ジオメトリは、同じ種類の形状を複数まとめるための形式です。複数の点を1つのMultiPointとして扱う、複数の線を1つのMultiLineStringとして扱う、複数の面を1つのMultiPolygonとして扱うといった使い方です。GeometryCollectionとの大きな違いは、Multi系は同じ種類の形状だけをまとめる点です。

たとえば、同じ管理対象に複数の面がある場合は、GeometryCollectionではなくMultiPolygonを使うほうが自然な場合があります。飛び地になっている区域、複数に分かれた敷地、離れた範囲を1つの地物として扱う場合などです。同じ属性を持つ複数の面であれば、MultiPolygonとして表現したほうが、面としての処理が分かりやすくなります。

同様に、複数の線が同じ道路区間や同じネットワーク要素を表しているなら、MultiLineStringを検討できます。複数の点が同じ観測対象の代表点群であり、同じ属性でよいならMultiPointを使える場合があります。異なる種類の形状が混在して初めて、GeometryCollectionの出番になります。

実務で迷ったときは、まず同じ種類の形状だけで表せるかを考えるとよいです。同じ種類で表せるならMulti系ジオメトリを検討します。形状ごとに属性を分けたいならFeatureCollectionで別Featureにします。異なる種類の形状を同じ属性・同じ管理単位でまとめたい場合に限って、GeometryCollectionを検討します。

この整理をしておくと、GeoJSONの設計が安定します。GeometryCollectionは最後の選択肢というわけではありませんが、最初に選ぶ形式でもありません。まずはFeatureCollectionとMulti系で表現できないかを確認し、それでも複数種類のgeometryを1つのgeometryとしてまとめる必要がある場合に使うと、後工程での混乱を減らせます。

実務で迷わない判断基準

GeometryCollectionを使うかどうか迷ったときは、いくつかの観点で判断すると整理しやすくなります。最初に確認したいのは、属性を共通化できるかどうかです。点、線、面に同じ名称、同じ管理番号、同じ状態、同じ更新情報を持たせて問題ないなら、GeometryCollectionを使える余地があります。反対に、それぞれに違う属性を持たせたいなら、別Featureに分けるほうが自然です。

次に、編集単位を確認します。複数形状を常に一体として編集するならGeometryCollectionでも扱えます。しかし、点だけ、線だけ、面だけを個別に編集する可能性があるなら、GeometryCollectionにまとめないほうが安全です。編集単位とデータ単位がずれると、運用で混乱しやすくなります。

表示だけが目的なのか、分析や集計にも使うのかも重要です。表示だけであれば、GeometryCollectionでも問題が少ない場合があります。しかし、面積、延長、件数、重なり、近接、範囲検索などの処理を行うなら、形状種類を明確に分けておくほうが扱いやすくなります。GeoJSONは表示用にも交換用にも使われますが、用途によって適した構造は変わります。

また、連携先の対応状況も確認すべきです。自分たちの環境では表示できても、受け取り側の環境で同じように扱えるとは限りません。外部へ渡すデータ、長期保管するデータ、複数部署で共有するデータでは、できるだけ単純で予測しやすい構造にすることが大切です。GeometryCollectionを使う場合は、事前に受け取り側が対応できるか確認しておくと安心です。

データ仕様書や運用ルールに残すことも重要です。GeometryCollectionを採用するなら、どのような場面で使うのか、どのジオメトリ種類を含めてよいのか、主たる形状は何か、個別属性を持たせない理由は何かを明記しておくと、後から判断がぶれにくくなります。担当者が変わっても同じルールで扱えることが、実務データではとても大切です。

判断を簡単にまとめるなら、GeometryCollectionは「異なる種類の形状を、同じ対象の一部として、同じ属性で、一体的に扱いたい場合」に向いています。逆に、「形状ごとに意味が違う」「属性が違う」「編集単位が違う」「集計したい」「外部連携が多い」場合は避けるのが無難です。

GeoJSONの設計では、表現できることと、運用しやすいことは別です。GeometryCollectionは仕様上便利な表現ですが、実務では分解しやすさ、説明しやすさ、引き継ぎやすさが重要になります。特に現場データでは、あとから写真、測点、図面、点群、出来形、検査記録などと結びつくことがあります。最初のGeoJSON設計が複雑すぎると、後続のデータ連携で苦労することがあります。

現場データ管理では取得時点の整理も重要

GeoJSONのGeometryCollectionを使い分けるうえで、ファイルを作る段階だけでなく、現場でデータを取得する段階の整理も重要です。点、線、面が混在する理由の多くは、現場で取得した情報の意味がまだ整理されていないことにあります。写真位置、測点、境界、施工範囲、異常箇所、確認ルートなどが同じ場所に重なると、どれをFeatureとして分けるべきか迷いやすくなります。

現場での記録時に、これは代表点なのか、実測点なのか、範囲を示す面なのか、移動や接続を示す線なのかを意識しておくと、GeoJSON化したときの構造が整理しやすくなります。後から机上で分類し直すこともできますが、取得時点の意味が曖昧だと、正しい分解や属性付けが難しくなります。

GeometryCollectionは、複数形状をまとめる形式として便利ですが、現場情報の曖昧さを隠すために使うべきではありません。点、線、面の意味が未整理なままGeometryCollectionに入れてしまうと、見た目にはまとまっていても、後から活用しにくいデータになります。現場で使うデータほど、位置と意味を同時に記録することが大切です。

たとえば、写真の撮影位置と対象物の位置は同じではありません。撮影者が立った位置はPointで表せますが、写真に写っている対象の範囲はPolygonやLineStringで表す必要があるかもしれません。これらを同じGeometryCollectionに入れることはできますが、撮影位置と対象範囲は意味が違います。属性や管理単位を分けたいなら、別Featureにしたほうが後で検索しやすくなります。

また、施工管理や点検管理では、位置情報が後から判断材料になります。どこで撮影したのか、どの範囲を確認したのか、どの線上を移動したのか、どの区域が対象なのかを明確にしておくことで、GeoJSONの構造も自然に決まります。GeometryCollectionを使うかどうかは、単なる形式選択ではなく、現場情報をどう管理するかという設計の一部です。

現場で取得したデータをGeoJSONとして共有する場合は、最初から完璧な構造にする必要はありません。ただし、正式データにする前には、GeometryCollectionのままでよいのか、FeatureCollectionに分解すべきか、Multi系ジオメトリに整理すべきかを確認する工程を入れると安心です。特に複数人がデータを扱う場合、構造が分かりやすいことは品質管理にもつながります。

このような現場データの取得と整理を効率化するには、位置情報を正確に記録し、写真や点群、測点などと結びつけて扱える環境が役立ちます。GeoJSONの構造を考える前段階として、現場でどの位置にどの情報を記録したのかを明確に残せれば、後から点、線、面の使い分けもしやすくなります。LRTK Phoneのように、現場の位置情報取得とデータ管理を支援する仕組みを活用すれば、GeoJSONを含む空間データの整理も、より実務に沿った形で進めやすくなります。