GeoJSONをCSVから作る手順と確認ポイント6つ

GeoJSONは、地図上に点、線、面などの位置情報を表すために使われるデータ形式です。CSVで管理している緯度経度、地点名、属性情報を地図で扱える形に変換したいとき、GeoJSONを作成できると、現場確認、台帳管理、共有資料、システム連携の幅が広がります。一方で、CSVからGeoJSONを作る作業は、単に列を変換するだけではありません。座標の順序、座標系、文字コード、属性名、欠損値、データ量、表示確認までを見落とすと、地図上で位置がずれる、属性が読めない、ファイルが読み込めないといった問題につながります。この記事では、CSVからGeoJSONを作る実務担当者に向けて、基本手順と確認ポイントを順番に解説します。

目次

• GeoJSONとCSVの違いを理解する

• CSVからGeoJSONを作る前に整理する項目

• 手順1としてCSVの列構成と文字コードを確認する

• 手順2として座標列と座標順を確認する

• 手順3として点・線・面のどのGeoJSONにするか決める

• 手順4として属性情報を整理して変換する

• 手順5としてGeoJSONの構造を確認する

• 手順6として地図表示と現場利用の観点で確認する

• CSVからGeoJSONを作るときのよくある失敗

• まとめ

GeoJSONとCSVの違いを理解する

CSVは、表形式のデータをカンマ区切りなどで保存するための形式です。地点名、管理番号、緯度、経度、種別、備考などを列として持たせることができ、表計算ソフトや業務システムから出力しやすい点が特徴です。現場台帳、点検一覧、測量メモ、施設一覧など、多くの業務データはCSVに近い形で管理されています。

一方、GeoJSONは位置情報を地図上で扱うための形式です。見た目はテキストデータですが、内部では地物ごとに形状と属性を持っています。ここでいう地物とは、地図上に表示したい対象のことです。たとえば、マンホールの位置を示す点、道路中心線を示す線、敷地境界を示す面などが地物にあたります。GeoJSONでは、それぞれの地物に座標情報を持たせ、さらに名称や管理番号などの属性情報を付与できます。

CSVとGeoJSONの大きな違いは、CSVが表であるのに対し、GeoJSONは地図上の形を表す構造を持っている点です。CSVでは緯度と経度が別々の列に入っていることが多いですが、GeoJSONでは座標が形状情報の中にまとめられます。また、CSVでは行ごとに1件のデータが並びますが、GeoJSONでは各地物がFeatureとして表現され、その集合がFeatureCollectionとして扱われることが一般的です。

実務でCSVからGeoJSONを作る場合は、CSVの各行をどのような地物として扱うかを決める必要があります。緯度経度が1組だけ入っているCSVであれば、各行を点として変換するのが自然です。複数の点をつないで線にしたい場合や、外周を結んで面にしたい場合は、CSV側に点の順番やグループ番号が必要になります。つまり、GeoJSON作成の成否は、変換作業そのものよりも、CSVに地図化できるだけの情報が揃っているかどうかに左右されます。

CSVからGeoJSONを作る前に整理する項目

CSVからGeoJSONを作る前に、まずデータの目的を整理します。どの地物を地図上に表示したいのか、点でよいのか、線や面にする必要があるのか、表示後にどの属性を確認したいのかを明確にします。目的が曖昧なまま変換すると、地図には表示できても、実務で使いにくいGeoJSONになることがあります。

たとえば、施設の位置を確認するだけであれば、名称、管理番号、緯度、経度、分類、更新日程度があれば十分な場合があります。一方、点検業務で使う場合は、点検結果、担当者、異常有無、写真番号、対応状況なども必要になるかもしれません。さらに、施工範囲や境界を扱う場合は、点の順番、閉じた形状になっているか、面として扱ってよいかといった確認が必要です。

次に、座標の種類を確認します。CSVに入っている座標が緯度経度なのか、平面直角座標のような投影座標なのかによって、GeoJSONにそのまま入れられるかどうかが変わります。GeoJSONで一般的な地図サービスに重ねる場合、経度、緯度の順で座標を記述する必要があります。CSV側で緯度、経度の順に列が並んでいる場合、そのまま機械的に出力すると座標順が逆になり、地図上で別の場所に表示される可能性があります。

また、CSVの文字コードも重要です。地点名や備考に日本語が含まれる場合、変換後のGeoJSONで文字化けが起きないようにする必要があります。特に、社内システムや表計算ソフトから出力したCSVは、環境によって文字コードが異なることがあります。GeoJSONとして使う前提なら、変換時に文字コードを統一しておくと、後工程での読み込みエラーを減らせます。

さらに、項目名の整理も欠かせません。CSVの列名に空白、記号、改行、表記ゆれがあると、変換後の属性名が扱いにくくなります。たとえば、「管理番号」「管理No」「管理番号 」のように似た列名が混在していると、データを読む人にもシステムにも分かりにくくなります。GeoJSONに変換する前に、列名を短く、意味が分かりやすく、同じルールで統一しておくことが大切です。

手順1としてCSVの列構成と文字コードを確認する

最初の手順は、CSVの列構成を確認することです。CSVを開き、どの列が位置を表し、どの列が属性を表しているかを整理します。点のGeoJSONを作る場合は、最低限、経度と緯度に相当する列が必要です。行ごとに地点を表すのであれば、各行に座標が1組ずつ入っている必要があります。空欄がある行、数値以外の文字が混ざっている行、余分な単位が入っている行は、変換前に修正します。

CSVでは、座標列に「北緯」「東経」「lat」「lon」「x」「y」など、さまざまな名前が使われます。しかし、列名だけで意味を判断するのは危険です。実際には、xが経度を表している場合もあれば、平面上の東西方向の座標値を表している場合もあります。yについても、緯度を表している場合と、平面上の南北方向の座標値を表している場合があります。列名だけでなく、数値の範囲やデータの出どころを確認することが重要です。

日本国内の緯度経度であれば、緯度はおおむね20度台から40度台、経度はおおむね120度台から150度台に収まることが多いです。もちろん離島やデータの範囲によって例外はありますが、緯度と経度が逆になっていないかを確認する手がかりになります。経度の列に35前後の値が入り、緯度の列に139前後の値が入っているようであれば、列の意味が入れ替わっている可能性があります。

文字コードについても、変換前に確認します。CSVを別の環境で開いたときに日本語が文字化けする場合、GeoJSONに変換しても同じ問題が残ることがあります。地点名、住所、備考、分類名などの日本語を正しく保持したい場合は、変換前の段階で文字コードを統一し、不要な制御文字や改行を取り除きます。特に備考欄に改行やカンマが入っているCSVは、読み込み時に列ずれを起こすことがあるため注意が必要です。

また、CSVの先頭行が見出し行になっているか、列数が全行で揃っているかも確認します。途中の行だけ列数が多い、または少ない場合、変換処理で属性がずれたり、エラーになったりします。見た目では問題がなくても、引用符の閉じ忘れや不要なカンマによって内部的に崩れていることがあります。変換前に数件だけでなく、末尾の行や途中の行も確認しておくと、変換後のトラブルを減らせます。

手順2として座標列と座標順を確認する

次の手順は、座標列と座標順の確認です。CSVからGeoJSONを作る際に最も多い失敗のひとつが、緯度と経度の順番を間違えることです。CSVでは「緯度, 経度」の順で管理されていることがよくありますが、GeoJSONの座標配列では「経度, 緯度」の順で記述します。この違いを見落とすと、地物が想定外の場所に表示されます。

座標順を確認するときは、まずCSV内の数値の範囲を見ます。緯度と経度の値が明らかに異なる地域であれば、値の大小から判断しやすくなります。たとえば、日本国内のデータであれば、35前後の値は緯度、139前後の値は経度である可能性が高いです。このような基本確認を行ったうえで、GeoJSONに出力するときは必ず経度を先、緯度を後に並べます。

ただし、CSVの座標が緯度経度ではない場合もあります。測量成果、設計図面、施工管理データから出力されたCSVでは、平面上の座標値が入っていることがあります。この場合、数値の桁が大きく、緯度経度の範囲には収まりません。一般的な背景地図に重ねるGeoJSONとして使う場合は、必要に応じて座標変換を行う必要があります。座標変換をせずにそのままGeoJSONにすると、読み込めたとしても地図上で想定外の位置に表示されることがあります。

小数点の扱いも確認します。緯度経度を扱う場合、小数点以下の桁数が不足すると位置の精度が落ちます。一方で、元データ以上に桁数を増やしても精度が上がるわけではありません。CSVからGeoJSONに変換するときは、元データの精度を保ちながら、不必要な丸めや文字列化を避けることが大切です。座標が数値ではなく文字列として扱われると、後工程で処理しにくくなる場合があります。

また、空欄や異常値の扱いを決めておく必要があります。座標が空欄の行をGeoJSONに含めると、変換エラーや表示エラーにつながることがあります。明らかに範囲外の座標が入っている行も、そのまま変換すると地図の表示範囲が極端に広がり、目的の場所が見つけにくくなります。欠損している行は除外するのか、別途確認対象として残すのか、変換前に方針を決めておくと安全です。

手順3として点・線・面のどのGeoJSONにするか決める

CSVから作るGeoJSONには、点、線、面などの形状を持たせることができます。最も単純なのは点のGeoJSONです。1行につき1地点があり、緯度経度が1組入っているCSVであれば、各行を点として変換できます。施設位置、点検箇所、標識、測点、写真撮影位置などは、点として表現することが多いです。

線のGeoJSONを作る場合は、複数の点を順番につなぐ必要があります。そのため、CSVには線を構成する点のグループ番号と、点の並び順が必要になります。たとえば、路線ごとに管理番号を持ち、さらにその路線内で1番目、2番目、3番目という順番が分かる列を持たせます。この順番が不明なCSVから線を作ると、線が折り返したり、交差したり、意図しない形になります。

面のGeoJSONを作る場合は、外周を構成する点の順番がさらに重要です。面は閉じた形状である必要があるため、外周を構成する座標列では最初の座標と最後の座標を一致させます。CSV側に始点と終点の関係が整理されていない場合、面として正しく作成できないことがあります。敷地、施工範囲、管理区域、調査範囲などを面で表す場合は、単に点群があるだけでは不十分で、外周線としての順序が必要です。

点、線、面のどれを選ぶかは、表示したい対象の意味で決めます。現場で一点の位置を示したいのに面にしてしまうと過剰ですし、範囲を示したいのに点だけでは伝わりにくくなります。CSVの構造と利用目的を照らし合わせ、無理に複雑な形状へ変換しないことも大切です。初回は点として作成し、必要に応じて線や面へ発展させる方法も実務では有効です。

さらに、複数の形状を一つのGeoJSONに含めるかどうかも考えます。GeoJSONでは異なる形状を含めることもできますが、扱う側のシステムや運用によっては、点だけ、線だけ、面だけに分けた方が管理しやすいことがあります。特にデータ更新や確認作業が発生する場合は、用途ごとにファイルを分けた方が修正範囲を把握しやすくなります。

手順4として属性情報を整理して変換する

GeoJSONの価値は、位置だけでなく属性情報を一緒に持てる点にあります。CSVの各列は、GeoJSONに変換すると属性として保持できます。たとえば、名称、管理番号、区分、状態、点検日、担当部署、備考などを地物ごとに持たせることで、地図上でクリックしたときに必要な情報を確認できます。

ただし、CSVの列をすべて属性として入れればよいわけではありません。実務では、表示や共有に不要な列、内部管理用の列、個人情報に近い列、誤解を招く古い列が含まれていることがあります。GeoJSONは共有や公開に使われることもあるため、変換前に属性として残す項目と削除する項目を選別することが重要です。特に外部共有を想定する場合は、作業者名、連絡先、詳細な住所、自由記述の備考などに注意します。

属性名は、読みやすく、処理しやすい形に整えます。日本語の属性名でも扱える場合はありますが、システム連携や長期運用を考えると、表記ゆれや空白を避けた命名にしておくと安定します。たとえば、同じ意味の項目を「点検日」「確認日」「調査日」と混在させると、後から集計や検索を行うときに手間がかかります。名称ルールを決めておくことで、複数のCSVを同じ形式のGeoJSONに変換しやすくなります。

日付や数値の形式も確認します。CSVでは日付が見た目上は同じでも、内部的には文字列、日付型、数値として扱われていることがあります。GeoJSONに変換した後に検索や絞り込みを行う場合、日付形式がばらばらだと扱いにくくなります。数値についても、単位が混在している列や、数値の後ろに文字が付いている列は注意が必要です。必要に応じて、単位を列名に含める、数値列と備考列を分けるなどの整理を行います。

備考欄の扱いも実務では重要です。備考には有用な情報が含まれる一方で、表記ゆれ、改行、記号、個人名、判断途中のメモなどが混ざりやすい項目です。GeoJSONとして共有する場合は、備考欄をそのまま入れてよいかを確認します。内部利用であっても、長すぎる備考は地図表示時に読みにくくなるため、必要な内容に絞ることが望ましいです。

手順5としてGeoJSONの構造を確認する

CSVをGeoJSONに変換したら、次にファイルの構造を確認します。GeoJSONはテキスト形式であるため、内容を開いて確認できます。基本的には、全体がFeatureCollectionとして構成され、その中に複数のFeatureが入り、各Featureにgeometryとpropertiesが含まれる形になります。geometryには点、線、面などの形状と座標が入り、propertiesにはCSV由来の属性情報が入ります。

点のGeoJSONでは、geometryのtypeがPointになり、coordinatesに経度と緯度の組が入ります。線の場合はLineStringとなり、coordinatesに複数の座標が順番に並びます。面の場合はPolygonとなり、外周を構成する座標列が入ります。こうした構造が崩れていると、地図上で読み込めない、または一部の地物だけ表示されないことがあります。

構文エラーにも注意します。GeoJSONは見た目が単純でも、カンマの位置、括弧の対応、引用符の抜けなどが原因で読み込みに失敗することがあります。CSVから自動変換した場合でも、元データに改行や特殊文字が含まれていると、properties内の文字列が崩れることがあります。変換後は、少なくとも数件のFeatureについて、geometryとpropertiesが意図した形になっているかを確認します。

座標が数値として入っているかも確認します。座標値が引用符で囲まれ、文字列として出力されている場合、読み込み側によっては正しく扱えないことがあります。GeoJSONのcoordinatesでは、経度と緯度を数値として持たせるのが基本です。属性情報の中に座標列を残す場合は文字列でも問題にならないことがありますが、geometryの座標は地図表示に直接使われるため、数値として扱う必要があります。

ファイルサイズも実務上の確認ポイントです。数十件や数百件のGeoJSONであれば扱いやすいですが、数万件以上になると、表示や共有に時間がかかることがあります。属性が多すぎる場合や、線や面の座標点が細かすぎる場合も、ファイルサイズが大きくなります。必要以上に重いGeoJSONは、現場での表示確認や関係者への共有に支障が出ることがあります。必要に応じて、利用目的に合わせて属性を絞る、範囲ごとにファイルを分ける、形状を簡略化するなどの工夫を検討します。

手順6として地図表示と現場利用の観点で確認する

GeoJSONは、作成できた時点で完了ではありません。最終的には、地図上に表示して、想定した位置、形状、属性になっているかを確認する必要があります。まず、対象エリア全体を表示し、地物が大きく外れた場所に出ていないかを確認します。1件でも座標が誤っていると、表示範囲が極端に広がり、全体確認がしにくくなることがあります。

次に、代表的な地点をいくつか選び、背景地図や既知の位置と照合します。CSV上の座標が正しくても、座標順の入れ替わり、座標系の違い、小数点の欠落などがあると、現実の位置とずれます。特に、現場で使うGeoJSONでは、数メートルのずれが判断に影響する場合があります。地図上で見えるから問題ないと判断せず、利用目的に対して十分な位置精度かどうかを確認します。

属性表示も確認します。地図上で地物を選択したとき、名称や管理番号が分かりやすく表示されるか、不要な項目が多すぎないか、文字化けしていないかを見ます。属性名が長すぎたり、内部用の項目が多く含まれていたりすると、現場で必要な情報をすぐに見つけにくくなります。GeoJSONはデータとして正しくても、利用者が読みにくければ実務上の価値が下がります。

線や面の場合は、形状の向きや接続状態も確認します。線が途中で途切れていないか、点の順番が入れ替わって折れ曲がっていないか、面が閉じているかを見ます。特にCSVから線や面を作る場合、点の並び順が間違っていると、変換処理自体は成功しても、地図上では誤った形になります。線や面のGeoJSONでは、表示確認が品質確認の中心になります。

現場利用を想定する場合は、ファイル名や更新日の管理も重要です。同じ対象のGeoJSONが複数存在すると、どれが最新版か分からなくなることがあります。ファイル名に対象範囲、用途、作成日、更新版を含めるなど、運用ルールを決めておくと混乱を防げます。また、CSVを修正してGeoJSONを再作成する場合は、どのCSVから生成したかを追えるようにしておくと、後から原因調査がしやすくなります。

CSVからGeoJSONを作るときのよくある失敗

CSVからGeoJSONを作るときに最も多い失敗は、座標順の間違いです。緯度、経度の順でCSVに並んでいる値を、そのままGeoJSONのcoordinatesに出してしまうと、経度、緯度の順にならず、地図上の位置が大きくずれます。変換作業では、列名を見て安心せず、実際に出力された座標配列の順番を確認することが必要です。

次に多いのが、座標系の混同です。緯度経度ではない座標をそのままGeoJSONに入れてしまうと、一般的な地図表示では正しく扱えない場合があります。設計や測量の現場では、緯度経度以外の座標をCSVで扱うこともあります。そのため、CSVに座標らしい列があるからといって、すぐにGeoJSON化できるとは限りません。元データがどの座標系で作成されたものかを確認し、必要な変換を行うことが大切です。

文字化けもよくある問題です。変換後のGeoJSONを開いたとき、地点名や備考が読めなくなっている場合は、CSVの文字コードや変換時の設定が影響している可能性があります。日本語の属性を含むGeoJSONは、共有先の環境でも正しく読める形式にしておく必要があります。作成した本人の環境では読めても、別の担当者の環境で文字化けすることがあるため、複数環境での確認が有効です。

属性情報を入れすぎる失敗もあります。CSVの全列をそのままGeoJSONに入れると、ファイルが重くなり、表示時の情報も煩雑になります。内部管理用の列や一時的な作業列まで含めると、利用者が必要な情報を見つけにくくなります。GeoJSONに入れる属性は、利用目的に合わせて選ぶことが重要です。

反対に、必要な属性を削りすぎる失敗もあります。地図上に点が表示されても、名称や管理番号がなければ、どの地点なのか判断できません。現場確認や台帳連携で使う場合は、後から照合できるキー項目を残しておく必要があります。表示用の名称だけでなく、元CSVや元台帳に戻れる管理番号を保持しておくと、修正や更新がしやすくなります。

最後に、変換後の確認不足があります。GeoJSONが作成できたというだけで納品や共有をしてしまうと、後から位置ずれ、欠損、属性ミスが見つかることがあります。特に外部へ共有するデータや現場判断に使うデータでは、サンプル確認だけでなく、全体表示、代表地点確認、属性確認、ファイル名確認まで行うことが望ましいです。

まとめ

CSVからGeoJSONを作る作業は、表形式のデータを地図で使える形に変換する実務的な工程です。CSVに緯度経度が入っていれば簡単に見える作業ですが、実際には座標順、座標系、文字コード、属性整理、形状種別、表示確認など、複数の確認ポイントがあります。これらを一つずつ押さえることで、地図上で正しく表示でき、現場や関係者が安心して使えるGeoJSONになります。

まずはCSVの列構成を確認し、座標列がどれかを明確にします。次に、GeoJSONでは経度、緯度の順で座標を扱うことを意識し、CSV側の緯度経度の並びと混同しないようにします。さらに、点、線、面のどの形状として扱うかを決め、線や面にする場合は点の順番やグループ管理を確認します。属性情報は、必要な項目を残しつつ、不要な項目や共有に適さない情報を整理します。

変換後は、GeoJSONの構造が正しいか、座標が数値として入っているか、文字化けがないかを確認します。そして最後に、地図上で位置、形状、属性を実際に見て確認します。GeoJSONはデータ形式として正しいだけでなく、利用目的に対して分かりやすく、更新しやすく、共有しやすいことが大切です。

CSVからGeoJSONを作れるようになると、台帳や一覧表で管理していた情報を地図上で直感的に確認できるようになります。点検箇所、施工範囲、管理施設、測点、写真位置などを空間情報として扱えるため、関係者間の認識合わせにも役立ちます。さらに、現場で取得した位置情報や測量データ、地図表示ツールと組み合わせることで、机上のCSVデータを現場確認や維持管理に活かしやすくなります。まずは小さなCSVを点のGeoJSONに変換し、座標順、属性、表示結果を確認しながら、業務に合った運用ルールへ整えていくことが重要です。