GeoJSONの時系列データを地図に載せる6つの工夫

GeoJSONは、点・線・面といった地理情報をJSONベースで表現できる形式です。地物の形状と属性をまとめて扱いやすいため、地図表示やデータ連携の実務でよく使われます。一方で、現場の移動履歴、巡回記録、設備点検、災害状況、物流、環境観測、工事進捗のように「いつ」の情報が加わると、単に地図へ載せるだけでは伝わりにくくなります。

時系列データを扱うときは、座標だけでなく、時間の持たせ方、データ量、更新頻度、表示粒度、ユーザーが読み取るべき変化まで考える必要があります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONの時系列データを地図に載せるときに役立つ6つの工夫を、公開・運用を見据えた視点で解説します。

目次

• GeoJSONの時系列データで最初に整理すべきこと

• 工夫1：時刻情報をpropertiesに統一して持たせる

• 工夫2：時間の粒度をそろえて表示の意味を明確にする

• 工夫3：表示期間と範囲でGeoJSONを分割する

• 工夫4：時間に応じて地物の見せ方を変える

• 工夫5：軌跡と状態変化を分けて考える

• 工夫6：更新・履歴・欠測を前提にデータ設計する

• 時系列GeoJSONを実務で扱うときの注意点

• まとめ：時系列データは「地図に載せる前の設計」で見やすさが決まる

GeoJSONの時系列データで最初に整理すべきこと

GeoJSONは、地理的な形状と属性情報をひとまとまりにして表現できる便利な形式です。点であれば観測地点や車両位置、線であれば移動経路や道路区間、面であれば区域や影響範囲を表せます。Featureとして表す場合は、形状を示すgeometryと、任意の属性を格納するpropertiesを持たせます。時系列データを扱う場合は、このpropertiesの中に時刻や期間、状態、観測値などを入れる設計がよく採られます。

ただし、GeoJSONの仕様そのものに、時系列専用の標準項目が用意されているわけではありません。そのため、時刻項目の名前や形式、期間の表し方は、利用するシステムや組織のルールに合わせて設計する必要があります。ここを曖昧にすると、表示はできても、後から検索、絞り込み、集計、別システムとの連携が難しくなります。

時系列データをGeoJSONに入れるだけでは、見やすい地図にはなりません。たとえば、1台の車両が数秒ごとに記録した位置情報をすべて点として表示すると、地図上は点だらけになります。過去1年分の点検結果をそのまま重ねると、古い情報と新しい情報が混ざり、どれを見ればよいのか分からなくなります。雨量や水位のような観測値を時刻付きで表示する場合も、時点ごとの差分を見たいのか、一定期間の傾向を見たいのかで、最適な表現は変わります。

まず整理したいのは、その地図でユーザーに何を読み取ってもらうかです。現在位置を知りたいのか、移動の流れを把握したいのか、時間による広がりを見たいのか、異常が発生したタイミングを確認したいのかによって、GeoJSONの作り方も地図上の見せ方も変わります。時系列データでは、座標と時刻が並んでいることよりも、時間による変化をどう解釈できるかが重要です。

次に、扱う時間の種類を決めます。ある瞬間の位置を表すのか、開始時刻と終了時刻を持つ期間を表すのか、日単位や月単位の集計結果を表すのかで、propertiesに入れる項目は変わります。現場写真の撮影位置であれば撮影時刻が重要です。作業区域であれば作業開始日と終了日が重要です。交通量や人流のような集計データであれば、集計対象の時間帯を明示しないと誤解が生まれます。

また、GeoJSONはテキスト形式で扱いやすい一方、データ量が増えるとファイルサイズや描画負荷が大きくなりやすい形式です。すべての時点を1つのファイルにまとめると、表示が重くなり、検索や絞り込みもしにくくなります。時系列データでは、地図に載せる前に、期間、空間範囲、更新頻度、属性項目を整理しておくことが大切です。ここを曖昧にしたまま実装すると、最初は表示できても、データが増えるにつれて運用が難しくなります。

工夫1：時刻情報をpropertiesに統一して持たせる

GeoJSONで時系列データを扱うときは、時刻情報をpropertiesに分かりやすく持たせる設計が基本になります。geometryは形状を表す領域なので、時刻、状態、観測値、識別子などの業務情報はpropertiesに入れるのが自然です。点の位置に撮影時刻を付ける、線の移動経路に開始時刻と終了時刻を付ける、面の対象区域に有効期間を付ける、といった考え方です。

実務では、時刻の項目名を最初に統一しておくことが非常に重要です。あるデータではdate、別のデータではtimestamp、さらに別のデータではcreated_atのように項目名がばらばらになると、地図側で条件分岐が増え、後から統合しにくくなります。瞬間を表す時刻であればtimestamp、期間を表す場合はstart_timeとend_timeのように、意味が分かる名前にそろえると扱いやすくなります。組織内で日本語の項目名を使う場合でも、表記ゆれを防ぐルールを決めておくと、後の処理が楽になります。

時刻の形式も統一が必要です。年月日だけでよいのか、時分秒まで必要なのか、時差をどう扱うのかを決めます。地図上で時系列スライダーや時刻による絞り込みを行う場合、文字列の見た目ではなく、機械的に比較・変換しやすい形式にしておくことが大切です。たとえば、ISO 8601やRFC 3339に沿った形式を採用し、タイムゾーンをZや+09:00のように明示しておくと、後から扱いやすくなります。

現場で入力された日時をそのまま入れると、全角半角の違い、区切り文字の違い、秒の有無、タイムゾーンの有無などが混在しがちです。地図に載せる前の整形で、必ず同じ形式に変換しておきます。日付だけを使う場合でも、日付なのか、ある日の代表時刻なのか、集計期間の開始日なのかを明確にしておくと、誤解を避けやすくなります。

さらに、時刻には「記録された時刻」と「現象が発生した時刻」がある点にも注意が必要です。たとえば、作業者が現場で異常を見つけた時刻と、その記録がシステムに送信された時刻は異なる場合があります。災害、点検、物流、測量のような現場データでは、この違いが重要になることがあります。どちらの時刻を地図の時間軸に使うのかを明確にし、必要であればobserved_timeとreceived_timeのように分けて持たせます。

地物を識別するIDも、時系列データでは欠かせません。同じ車両、同じ設備、同じ作業区域、同じ観測点の履歴を追うには、時刻だけでなく対象を結び付けるキーが必要です。1つの点が1つの記録を表す場合でも、propertiesにvehicle_id、site_id、sensor_id、asset_idのような識別子を持たせておくと、後で対象ごとの履歴表示や集計がしやすくなります。時系列地図では、時刻とIDの組み合わせがデータの骨格になります。

工夫2：時間の粒度をそろえて表示の意味を明確にする

時系列GeoJSONを見やすくするためには、時間の粒度をそろえることが重要です。粒度とは、秒単位、分単位、時間単位、日単位、月単位のように、どの細かさで時間を扱うかという考え方です。粒度がばらばらのデータを同じ地図に載せると、ユーザーは同じ意味の情報として見てよいのか判断できなくなります。1分ごとの移動点と、1日ごとの点検結果を同じ時系列スライダーで動かすと、時間の変化が不自然に見えることがあります。

たとえば、車両の移動履歴では、数秒ごとの位置情報を記録していても、地図上で常に全点を表示する必要はありません。目的が大まかな移動ルートの把握であれば、1分ごと、5分ごと、あるいは一定距離ごとの点に間引いても十分な場合があります。逆に、事故や急停止の検証であれば、秒単位の記録が必要になることもあります。重要なのは、データの細かさをそのまま表示の細かさにしないことです。記録粒度と表示粒度を分けて考えることで、地図は見やすくなります。

設備点検や巡回管理では、日単位の表示が向いていることが多いです。点検の実施日時が分単位で記録されていても、ユーザーが確認したいのは「今日点検した場所」「今週未点検の場所」「前回点検から一定期間が経過した場所」かもしれません。その場合、時刻を細かく表示するよりも、日付や経過日数で色分けするほうが実務に合います。GeoJSONのpropertiesには詳細な時刻を保持しつつ、地図表示では用途に合わせて丸めた時間を使う設計が有効です。

環境観測や人流分析のように、時間帯ごとの傾向を見たいデータでは、集計単位を明示する必要があります。午前、午後、1時間ごと、平日、休日など、どの単位でまとめた値なのかが分からないと、地図上の色や大きさが何を意味するのか曖昧になります。propertiesには、観測値だけでなく、集計開始時刻、集計終了時刻、集計単位を入れておくとよいです。これにより、後から別の粒度で再集計したり、凡例や注釈を自動的に表示したりしやすくなります。

時間の粒度をそろえることは、地図の操作性にも影響します。時系列スライダーを使う場合、秒単位で長期間のデータを動かすと、操作が細かすぎて実用的ではありません。日単位のデータに対して分単位のスライダーを用意しても、ほとんどの位置で変化が起きず、使いにくい表示になります。データの性質とユーザーの判断単位を合わせて、時間の刻みを設計することが、時系列地図の分かりやすさにつながります。

工夫3：表示期間と範囲でGeoJSONを分割する

GeoJSONの時系列データでよくある失敗は、すべての履歴を1つの巨大なファイルにまとめてしまうことです。小規模な検証では問題なく表示できても、対象期間が長くなり、地点数や履歴数が増えると、読み込みが遅くなります。地図を開いた瞬間に全期間のデータを読み込む必要があるのか、ユーザーが選んだ期間だけ読み込めばよいのかを考えることが大切です。

時系列データは、期間ごとに分割すると扱いやすくなります。日別、週別、月別、年度別のように、業務の確認単位に合わせてGeoJSONを分けます。たとえば、作業履歴であれば日別や週別、設備点検であれば月別、広域の変化であれば年度別が向いている場合があります。地図側では、ユーザーが選んだ期間に対応するファイルだけを読み込めばよいため、初期表示が軽くなります。

空間範囲での分割も有効です。全国や広域のデータを扱う場合、表示している範囲に関係なく全データを読み込むのは非効率です。地域、管理区域、現場単位、図郭、格子などで分けておくと、必要な範囲だけを読み込めます。特に、時系列データは時間方向にも空間方向にも増えていくため、期間と範囲の両方で分割する設計が効果的です。

分割するときは、ファイル名や取得条件のルールも重要です。たとえば、年月、地域コード、データ種別を含む名前にしておくと、地図側から機械的に参照しやすくなります。人が見て分かる名前にすることも大切ですが、プログラムで扱いやすい規則性を持たせることが運用では重要です。後から自動更新や定期生成を行う場合、命名規則が曖昧だと処理が複雑になります。

ただし、分割しすぎると管理が難しくなります。細かく分ければ読み込み量は減りますが、ファイル数が増え、取得回数も増えます。地図を少し動かすたびに多数のファイルを読み込む設計では、かえって表示が遅くなることもあります。どの程度の期間、どの程度の範囲で分けるかは、データ量、更新頻度、ユーザーの操作方法を見ながら決める必要があります。

また、時系列の表示では、直近データと過去データの扱いを分けると運用しやすくなります。直近数時間や当日分は頻繁に更新されるため小さな単位で持ち、確定済みの過去データは月別や地域別にまとめるといった方法です。現在の状況を素早く表示しながら、必要に応じて過去履歴も参照できる構成にすると、実務で使いやすい地図になります。

工夫4：時間に応じて地物の見せ方を変える

時系列データを地図に載せる目的は、時間による変化を見えるようにすることです。そのためには、単に点や線を表示するだけでなく、時刻や状態に応じて見せ方を変える工夫が必要です。よく使われる方法は、色、透明度、大きさ、線の太さ、表示順、ラベルの出し分けです。これらを適切に組み合わせると、時間の流れや新旧の違いが直感的に伝わります。

たとえば、直近のデータを濃く、古いデータを薄く表示すると、地図上で新しい情報が目立ちます。移動履歴では、現在に近い点を大きく表示し、過去の点を小さくすることで、移動の方向を読み取りやすくなります。一定期間を過ぎた点検結果を目立つ色にする、未対応の異常を強調する、完了済みの作業を落ち着いた表示にするなど、時間と業務状態を組み合わせた表現も有効です。

ただし、色だけに頼りすぎると、凡例が複雑になり、視認性も落ちます。時刻、状態、重要度、分類をすべて色で表そうとすると、ユーザーは意味を覚えきれません。時系列地図では、色は主に状態や新旧の差を表し、大きさや透明度で強弱を付けるなど、役割を分担させることが大切です。凡例を見なくても大まかな意味が分かり、必要なときに詳細を確認できる設計が理想です。

時間を操作するUIを用意する場合は、地図上の表現と連動させます。時点を1つ選ぶ表示では、その時点に有効な地物だけを表示します。期間を選ぶ表示では、期間内の地物をすべて出しつつ、時刻の新旧で見分けられるようにします。再生機能を使う場合は、データの出現や消滅が自然に見えるように、急に大量の地物が切り替わらない工夫も必要です。

面データの時系列表示では、特に注意が必要です。区域や影響範囲を時間ごとに重ねると、前後関係が分かりにくくなります。古い面を薄くする、新しい面を前面に出す、選択した時点だけ表示する、差分だけを表示するなど、目的に応じた表現を選びます。面は地図上の面積を大きく占めるため、点や線よりも表示の優先順位を慎重に考える必要があります。

地物の見せ方を変えるときは、propertiesに表示判断に使う値を持たせておくと便利です。timestampだけで毎回計算してもよいですが、status、age_class、priority、valid_from、valid_toのような項目を持たせると、地図側の処理が分かりやすくなります。データ生成時に分類しておくのか、地図表示時に計算するのかは、更新頻度や柔軟性によって決めます。

工夫5：軌跡と状態変化を分けて考える

時系列GeoJSONでは、移動軌跡と状態変化を同じものとして扱ってしまいがちです。しかし、実務ではこの2つを分けて考えたほうが分かりやすくなります。軌跡は「どこを通ったか」を表す情報です。状態変化は「その時点で何が起きていたか」を表す情報です。車両の走行、作業者の移動、ドローンや船舶の位置、巡回ルートなどでは、位置の連続と状態の変化が同時に存在します。

移動軌跡を表す場合、点の連続として持つ方法と、線として持つ方法があります。点の連続は、各時点の位置や速度、方位、状態を詳しく表せます。一方で、点が多くなると表示が重くなり、見た目も複雑になります。線は移動の全体像を把握しやすいですが、線だけでは各時点の情報が分かりにくくなります。そのため、実務では線で大まかな経路を示し、必要な地点だけ点として表示する設計がよく合います。

状態変化を扱う場合は、すべての点に同じ項目を持たせるより、変化が起きたタイミングを明確にすることが大切です。たとえば、作業中、停止中、移動中、異常発生、復旧済みといった状態を記録する場合、状態が変わった時刻と位置を分かるようにしておくと、後から分析しやすくなります。地図上では、状態が変わった地点だけを強調し、通常の移動点は控えめに表示することで、重要な出来事に注目できます。

線データにも時間を持たせることができます。ある区間を何時から何時まで移動したのか、どの時間帯に通過したのかをpropertiesに入れれば、時系列表示の対象になります。ただし、1本の線に長い期間を持たせると、線上のどの位置がどの時刻に対応するのか分かりにくくなります。移動の詳細を表したい場合は、線を短い区間に分け、各区間に開始時刻と終了時刻を持たせると、時間との対応が明確になります。

一方で、必要以上に細かく線を分割すると、データ量が増え、管理も難しくなります。移動の方向や速度感を表したいのか、通過した道路や区域を示したいのか、作業完了区間を示したいのかによって、適切な分割単位は異なります。軌跡の目的を決めてから、点と線のどちらを主役にするかを選びます。

状態変化を地図で見せるときは、時間だけでなく業務上の意味を重視します。たとえば、同じ「停止」でも、信号待ち、休憩、故障、作業中では意味が違います。GeoJSONのpropertiesには、単なる数値やコードだけでなく、表示や検索に使いやすい分類を持たせると便利です。後から凡例を作る、絞り込み条件を作る、集計する、といった作業がしやすくなります。

工夫6：更新・履歴・欠測を前提にデータ設計する

時系列データは、一度作って終わりではありません。現場から新しい記録が追加され、過去の記録が修正され、通信状況によって欠測が発生し、後からまとめて送信されることもあります。そのため、GeoJSONを設計するときは、更新、履歴、欠測を前提にしておく必要があります。きれいにそろったデータだけを想定していると、実運用で破綻しやすくなります。

まず、更新時に既存データを上書きするのか、履歴として追加するのかを決めます。現在位置を表示するだけなら、最新の1件を上書きしてもよい場合があります。しかし、移動履歴や点検履歴を残したい場合は、過去の記録を消さずに追加していく必要があります。GeoJSON上では、同じ対象IDに対して複数の時刻のFeatureが存在する形になります。このとき、どれが最新かを判断できるようにtimestampやversion、updated_timeのような情報を持たせておくと安心です。

修正履歴も重要です。現場で入力ミスがあり、後から位置や時刻が修正されることがあります。修正後の値だけを残すのか、修正前の値も履歴として残すのかは、業務要件によります。監査や報告が必要なデータでは、いつ誰が修正したのかを追える設計が求められることがあります。地図表示だけを見ると不要に思える項目でも、運用全体では必要になる場合があります。

欠測への対応も欠かせません。移動体の位置情報では、通信が切れて記録が飛ぶことがあります。観測データでは、機器の停止や電波状況により値が取得できないことがあります。このような場合、地図上で単純に点を線でつなぐと、実際には移動していない区間や不明な区間まで連続しているように見えてしまいます。欠測がある場合は、線を途切れさせる、欠測区間を別の表示にする、propertiesにdata_qualityやmissing_flagのような情報を持たせるといった工夫が必要です。

時系列データでは、遅れて届くデータも考慮します。現場端末が圏外だったため、数時間後にまとめて送信されることがあります。この場合、受信時刻だけで並べると、実際の発生順と異なる表示になります。発生時刻と受信時刻を分けて持たせておけば、地図上では発生時刻で表示し、運用監視では受信時刻で確認するといった使い分けができます。

また、データの有効期間を持たせる設計も有効です。ある区域が一時的に通行止めだった、ある設備が一定期間だけ利用停止だった、ある作業範囲が特定の期間だけ有効だった、といった場合は、単一のtimestampよりもvalid_fromとvalid_toのような期間情報が適しています。時系列スライダーで任意の時点を選んだとき、その時点に有効な地物だけを表示できるようになります。

運用を考えると、GeoJSONは配信用の形式として位置付け、元データは別に管理する設計も検討したほうがよいです。GeoJSONは地図表示やデータ交換に使いやすい形式ですが、大量の履歴更新や複雑な検索を行う元台帳としては扱いにくい場合があります。元データを管理し、必要な期間や範囲だけGeoJSONとして出力する流れにすると、表示用データを最適化しやすくなります。

時系列GeoJSONを実務で扱うときの注意点

ここまで6つの工夫を紹介しましたが、実務で時系列GeoJSONを扱うときには、さらにいくつかの注意点があります。まず大切なのは、GeoJSONに何でも入れすぎないことです。propertiesには自由に属性を追加できますが、地図表示に使わない情報まで大量に入れると、ファイルが重くなります。個人情報や機密情報が含まれる場合もあるため、配信用GeoJSONには必要な項目だけを含めるのが基本です。

座標の扱いにも注意が必要です。GeoJSONでは、原則として座標を経度、緯度の順で扱います。日本語の業務資料や現場入力では緯度、経度の順に書かれることも多いため、取り込み時に順序を誤ると、意図しない場所に地物が表示されます。また、GeoJSONの座標はWGS 84の十進度を前提にするため、別の座標系で管理しているデータは、配信用GeoJSONにする前に変換が必要です。

座標の精度にも注意が必要です。時系列データでは、位置が細かく記録されるほど、個人や車両の行動が推測されやすくなります。業務上必要な精度と、公開・共有してよい精度は必ずしも同じではありません。社内利用、委託先共有、一般公開など、利用範囲に応じて座標を丸める、範囲化する、集計値にするなどの対応が必要です。

表示速度を考える場合、地図に載せる地物数を意識します。数百件なら問題なくても、数万件、数十万件になると、ブラウザでの描画は重くなります。時系列データでは、同じ場所に多くの履歴が重なることも多いため、すべてを同時に表示するのではなく、期間選択、対象選択、範囲選択、集約表示を組み合わせることが現実的です。ユーザーが最初に見る画面では概要を表示し、詳細は選択時に読み込む設計にすると、操作感を保ちやすくなります。

凡例と説明文も重要です。時系列地図では、色や透明度が何を意味するのか、点と線の違いは何か、表示されていない期間はデータがないのか、選択対象外なのかを明確に伝える必要があります。地図だけで完結させようとせず、画面上の説明、凡例、絞り込み条件、ポップアップ表示を組み合わせます。特に実務担当者向けの地図では、見た目の美しさよりも、判断に迷わないことが大切です。

ポップアップに表示する情報も整理します。クリックしたときに、時刻、対象ID、状態、観測値、更新時刻、備考などをすべて表示すると、必要な情報が埋もれます。まず最も重要な時刻と状態を見せ、詳細は必要に応じて開く構成が見やすくなります。時系列データでは、同じ地点に複数の記録が重なることがあるため、クリック時に最新のみを表示するのか、履歴一覧を表示するのかも決めておきます。

データの作成段階では、異常値の扱いも考えます。明らかに遠くへ飛んだ座標、未来の日付、時刻の逆転、同一時刻の重複、空のgeometry、不正な座標順などは、地図表示で問題を起こします。GeoJSONを出力する前に、最低限の検査を行う仕組みを用意しておくと、運用時のトラブルを減らせます。時系列データでは、1件の誤った時刻が全体の並びを崩すこともあるため、時刻の検査は特に重要です。

また、地図表示に使うGeoJSONと、分析に使うデータは目的が異なります。分析ではできるだけ生データに近い形が必要な場合がありますが、地図表示では軽さと分かりやすさが優先されます。表示用には間引き、集約、分類、項目削減を行い、必要に応じて元データに戻れるようにIDで結び付けておくと、実務で扱いやすくなります。

まとめ：時系列データは「地図に載せる前の設計」で見やすさが決まる

GeoJSONは、地図に点、線、面を載せるために扱いやすい形式です。しかし、時系列データを扱う場合は、単にpropertiesに時刻を入れるだけでは不十分です。時刻情報の持たせ方、時間の粒度、データ分割、表示表現、軌跡と状態変化の分離、更新や欠測への対応を考えることで、実務で使いやすい地図に近づきます。

特に大切なのは、ユーザーがその地図で何を判断するのかを最初に決めることです。現在の状況を見たいのか、過去の変化を追いたいのか、異常の発生地点を知りたいのか、作業の進捗を確認したいのかによって、GeoJSONの設計は変わります。地図はデータを置く場所ではなく、判断を助ける画面です。時系列データでは、この考え方がより重要になります。

実務でGeoJSONを使う場合は、最初から完璧なデータモデルを作ろうとするよりも、小さな範囲で試し、表示速度、見やすさ、更新のしやすさを確認しながら改善するのが現実的です。時刻項目を統一し、対象IDを持たせ、期間や範囲で分割し、必要な情報だけを表示する。この基本を押さえるだけでも、時系列地図の使いやすさは大きく変わります。

現場の位置情報を扱う場面では、スマートフォンや測量機器、センサー、業務システムなどから取得した座標、写真、記録時刻、作業メモを、地図上で一体的に扱いたいケースが増えています。公開用・共有用のGeoJSONでは、必要な項目に絞り、時刻形式と座標の扱いをそろえ、更新や欠測に対応できる設計にしておくことが重要です。時系列データは、地図に載せる前の設計次第で、見やすさと運用しやすさが大きく変わります。