GeoJSONの拡張子.jsonと.geojsonの違いを整理する4点

GeoJSONを扱うときに、ファイル名の最後が「.json」になっている場合と「.geojson」になっている場合があります。どちらも見た目は似ており、開けば同じようなJSON形式のテキストに見えるため、実務では「このまま使ってよいのか」「拡張子を変換する必要があるのか」「受け渡し先にはどちらで渡すべきか」と迷いやすいところです。

結論から言えば、GeoJSONの本質は拡張子ではなく中身の構造にあります。ただし、拡張子は人やシステムがファイルの用途を判断するための大切な手がかりになります。この記事では、geojsonで検索している実務担当者に向けて、.jsonと.geojsonの違いを4つの観点から整理します。

目次

• GeoJSONの拡張子でまず理解したい基本

• 1点目：.jsonと.geojsonは中身の形式を直接変えるものではない

• 2点目：.geojsonは地理空間データであることを明示しやすい

• 3点目：.jsonは汎用性が高い一方で説明が必要になりやすい

• 4点目：実務では連携先と運用ルールで使い分ける

• GeoJSONファイルを扱うときに確認したい実務上の注意点

• まとめ：拡張子より中身、ただし運用では拡張子が効く

GeoJSONの拡張子でまず理解したい基本

GeoJSONは、地物の位置や形状、属性情報をJSON形式で表現するためのデータ形式です。点、線、面といった地理空間情報を、テキストとして読み書きしやすい形で表現できるため、地図表示、現地調査、設備管理、区域管理、ルート管理、測量成果や業務台帳との連携など、幅広い業務で使われます。

GeoJSONという名前から、専用の特殊なバイナリ形式を想像する人もいますが、実際にはJSONを土台にしたテキストデータです。そのため、ファイルを開くと波かっこ、角かっこ、文字列、数値、キーと値の組み合わせで構成されています。一般的なJSONファイルと同じようにテキストとして確認でき、プログラムでも扱いやすい形式です。

GeoJSONの代表的な構造には、複数の地物をまとめるFeatureCollection、個別の地物を表すFeature、形状を表すgeometry、属性情報を格納するpropertiesがあります。たとえば、現地で取得した点の位置であればPoint、道路や配管のような線状の対象であればLineString、敷地や区域のような面状の対象であればPolygonとして表現します。これらの情報が一定のルールに従って記述されているものがGeoJSONです。

ここで重要なのは、GeoJSONであるかどうかは、単にファイル名の最後が.geojsonかどうかだけで決まるわけではないという点です。ファイル名がsample.geojsonであっても、中身がGeoJSONの構造になっていなければ、実務上は正しいGeoJSONとは言えません。逆に、ファイル名がsample.jsonであっても、中身がGeoJSONの構造に従っていれば、GeoJSONとして扱える場合があります。

つまり、.jsonと.geojsonの違いを理解するには、拡張子そのものだけを見るのではなく、データ形式としての中身、読み込む側の仕様、ファイルを受け渡す相手、保存や管理のルールを合わせて考える必要があります。拡張子は中身を保証するものではありませんが、中身を推測し、処理方法を決めるための合図にはなります。

実務では、この合図が意外に重要です。フォルダの中に設定ファイル、帳票用のデータ、APIの応答結果、地図用のデータが混在している場合、すべてが.jsonになっていると、どれが地図に載せるためのファイルなのか判別しづらくなります。一方で、地理空間データに.geojsonという拡張子を付けておけば、ファイル名を見ただけで用途が伝わりやすくなります。

GeoJSONの拡張子をめぐる混乱は、多くの場合「形式としての違い」と「運用上の違い」が混ざっていることから生まれます。形式としては、.jsonでも.geojsonでも中身はJSONテキストとして成立します。しかし、運用上は、.geojsonのほうが地理空間データであることを明確に示しやすく、.jsonのほうが汎用的なデータとして扱いやすいという違いがあります。

なお、標準仕様として広く参照されるRFC 7946では、GeoJSONはJSONベースの地理空間データ交換形式として定義されています。また、配信時のメディアタイプとしてはapplication/geo+jsonが登録されており、その登録情報では拡張子としてgeojsonが示されています。ただし、実務ではシステム都合により、GeoJSON構造を持つデータが.jsonとして保存・配布されることもあります。

この記事では、この違いを4点に分けて整理していきます。特に、ファイルを受け取る側、作成する側、保管する側、システム連携を担当する側の視点で見ると、どちらを選ぶべきかが判断しやすくなります。

1点目：.jsonと.geojsonは中身の形式を直接変えるものではない

最初に押さえるべきポイントは、.jsonと.geojsonという拡張子の違いだけで、ファイルの中身が自動的に変わるわけではないということです。拡張子はあくまでファイル名の一部であり、データの内容そのものを変換する機能を持っているわけではありません。

たとえば、中身が正しいGeoJSON形式で記述されたファイルがあるとします。そのファイル名がarea.jsonであっても、area.geojsonであっても、テキストとしての中身が同じであれば、データ構造は同じです。GeoJSONとして必要なtype、features、geometry、coordinates、propertiesなどの構造が正しく記述されていれば、拡張子が.jsonであってもGeoJSONとして読み込める環境はあります。

一方で、拡張子を.geojsonに変更しただけでは、普通のJSONがGeoJSONに変わるわけではありません。たとえば、顧客一覧、設定情報、集計結果、任意の配列データなどを記録したJSONファイルの拡張子を.geojsonに変更しても、中身に地理空間情報の構造がなければGeoJSONとしては扱えません。地図に表示しようとしても、形状情報が見つからなかったり、座標の構造が合わなかったりしてエラーになる可能性があります。

この点は、現場での変換作業でも誤解されやすいところです。「.jsonを.geojsonに変換する」という表現が使われることがありますが、実際には単なるリネームで済むケースと、データ構造そのものをGeoJSON形式に組み替える必要があるケースがあります。すでに中身がGeoJSON形式であれば、拡張子の変更だけで運用しやすくなる場合があります。しかし、中身がGeoJSON形式でない場合は、緯度経度や属性を適切な構造に整え、FeatureやFeatureCollectionとして組み直す必要があります。

ここで実務担当者が確認すべきなのは、ファイルを開いたときにGeoJSONらしい構造があるかどうかです。複数の地物をまとめたデータであれば、全体のtypeがFeatureCollectionになっているか、featuresの中にFeatureが並んでいるか、それぞれのFeatureにgeometryとpropertiesがあるかを確認します。単一の形状を扱う場合でも、geometryのtypeがPoint、LineString、Polygonなどになっており、coordinatesに座標値が入っているかを見ると判断しやすくなります。

また、GeoJSONでは座標の順序にも注意が必要です。一般的な地図画面や住所情報では「緯度、経度」の順で話されることが多いですが、標準的なGeoJSONでは位置を「経度、緯度」の順で記述します。必要に応じて高さを3番目の値として持たせることもあります。この順序を取り違えると、データが意図しない場所に表示されることがあります。拡張子が.geojsonであっても、この中身のルールが守られていなければ、正しい地理空間データとして使うことはできません。

文字コードや数値の扱いも確認対象です。GeoJSONはテキストデータなので、文字化けが起きると属性情報の読解に支障が出ます。また、座標値は小数を含む数値として記録されるため、桁数を丸めすぎると位置精度が落ちます。拡張子の違いだけに注目していると、こうした中身の品質確認が抜け落ちてしまいます。

したがって、1点目の結論は明確です。.jsonと.geojsonは、ファイルの実体を自動的に別物にするものではありません。GeoJSONかどうかを決めるのは、拡張子ではなく中身の構造です。ただし、拡張子はその中身をどう扱うべきかを周囲に伝えるための重要な目印になります。この前提を理解しておくと、以降の使い分けも整理しやすくなります。

2点目：.geojsonは地理空間データであることを明示しやすい

2点目は、.geojsonという拡張子の役割です。.geojsonは、ファイルがGeoJSON形式の地理空間データであることを明示するために使われます。中身がJSON形式であることに加えて、地図や位置情報に関係するデータだと伝えられる点が大きな特徴です。

実務では、ファイル名を見ただけで用途が分かることが非常に重要です。現地調査の結果、区域ポリゴン、設備点検地点、道路中心線、境界線、管理対象エリアなど、地理空間データには多くの種類があります。これらをすべて.jsonとして保存してしまうと、他の業務データとの区別がつきにくくなります。たとえば、setting.json、result.json、area.json、points.jsonのようなファイルが並んでいる場合、どれが地図用のデータなのか、どれが単なる設定や集計結果なのかを毎回開いて確認しなければなりません。

これに対して、area.geojson、survey_points.geojson、route.geojsonのように拡張子を.geojsonにしておけば、ファイル一覧を見た段階で地理空間データだと分かります。これは小さな違いに見えますが、複数人で作業する現場では大きな効果があります。担当者が変わったとき、外部にデータを渡すとき、過去の成果物を探すとき、地図表示用のファイルだけを抽出したいときに、拡張子が判断材料になります。

また、システムによっては.geojsonという拡張子を見て、地理空間データとして読み込み候補に表示する場合があります。すべての環境が同じ挙動をするわけではありませんが、拡張子が.geojsonであれば、地図データとして扱うべきファイルだと認識されやすくなります。逆に、.jsonのままだと汎用JSONとして扱われ、読み込み時にファイル種別を手動で指定する必要が出ることがあります。

Web配信やAPI連携でも、.geojsonは意味を持ちます。拡張子だけでなく、配信時のメディアタイプとしてapplication/geo+jsonを指定できる場合があります。これにより、受け取る側が「これは一般的なJSONではなく、GeoJSONとして解釈するデータだ」と判断しやすくなります。ただし、配信設定は環境によって異なるため、拡張子を.geojsonにしただけで必ず正しく扱われるとは限りません。拡張子、配信時のメディアタイプ、中身の構造を合わせて確認することが大切です。

.geojsonと表記するときにも注意があります。実務文書や仕様書では、拡張子としての表記を明確にするために、ドットを含めて.geojsonと書くと誤解が少なくなります。検索キーワードとしてgeojsonと入力する人は多いですが、社内ルールや納品仕様では「GeoJSON形式のファイルは.geojson拡張子とする」のように書いておくと、担当者ごとの判断の揺れを減らせます。

.geojsonを使う利点は、単に見た目が分かりやすいことだけではありません。データ管理の自動化にも向いています。たとえば、特定のフォルダに入った.geojsonファイルだけを検査する、更新された.geojsonファイルだけを地図配信用に処理する、成果物一覧から地理空間データだけを抽出する、といった運用が考えられます。このとき、拡張子が統一されていると処理条件を作りやすくなります。

ただし、.geojsonを使えばすべて安心というわけではありません。中身が壊れていたり、座標の順序が間違っていたり、属性名が作業ルールと合っていなかったりすれば、地図上では正しく扱えません。.geojsonは地理空間データであることを伝える便利な目印ですが、品質を保証するものではないという理解が必要です。

それでも、地理空間データとして受け渡すことが明確な場合は、.geojsonを選ぶ価値は高いです。特に、地図表示、現地調査成果、区域データ、線形データ、点検地点データなど、用途が地理空間に限定されているファイルでは、.geojsonにしておくことで関係者に意図が伝わりやすくなります。2点目の結論は、.geojsonは中身を変える拡張子ではないものの、地理空間データであることを明示し、運用上の誤解を減らすために有効だということです。

3点目：.jsonは汎用性が高い一方で説明が必要になりやすい

3点目は、.jsonを使う場合の考え方です。.jsonはJSON形式の汎用的な拡張子です。GeoJSONもJSONを土台にしているため、中身がGeoJSON形式であれば.json拡張子のまま扱えるケースがあります。特に、APIの応答、システム内部のデータ保存、汎用的なデータ連携では、.jsonとして出力されることがあります。

.jsonの利点は、さまざまな用途で受け入れられやすいことです。地理空間データ専用ではない仕組みでも、JSONファイルであれば保存、送信、検査、読み込みの対象にしやすい場合があります。データ基盤や業務システムの中には、拡張子として.jsonのみを想定しているものもあります。そのような環境では、GeoJSONの中身を持っていても、ファイル名は.jsonにしておくほうが自然な場合があります。

また、ひとつのファイルの中に地理空間情報だけでなく、設定値や処理条件、検索条件、表示条件などを含める運用では、.jsonとして扱うほうが実態に合うこともあります。ただし、この場合は純粋なGeoJSONなのか、GeoJSONを含む独自のJSONなのかを区別する必要があります。GeoJSONとして読み込む側は、決められた構造を期待します。独自のキーで包まれていたり、featuresが別の階層に入っていたりすると、そのままではGeoJSONとして認識されないことがあります。

.jsonを使う最大の注意点は、ファイル名だけではGeoJSONかどうかが伝わりにくいことです。たとえば、points.jsonというファイル名だけでは、点の属性一覧なのか、地図上の地点データなのか、別の処理結果なのか判断できません。受け取った人が地図に読み込むべきファイルだと気づかない可能性もあります。これを避けるためには、ファイル名、フォルダ名、説明文、仕様書、メタデータなどで「このJSONはGeoJSON形式です」と明記する必要があります。

ファイル名の付け方でも工夫できます。単にdata.jsonとするより、survey_points_geojson.json、area_boundary_geojson.jsonのように、GeoJSONであることが分かる名前にする方法があります。ただし、これはあくまで補助的な方法です。拡張子としては.jsonのままなので、自動処理や検索では.geojsonほど明確ではありません。長期的に地理空間データとして管理するなら、.geojsonに統一したほうが分かりやすい場面もあります。

受け渡し先との関係も重要です。相手先の取り込み仕様が.jsonしか受け付けない場合、こちらの都合で.geojsonにしてしまうと、かえって読み込みに失敗する可能性があります。逆に、相手がGeoJSONファイルとしての納品を期待している場合、.jsonで渡すと確認の手間が増えたり、仕様違反と判断されたりすることがあります。拡張子は中身を変えませんが、受け取る側の処理条件に影響することがあります。

.jsonでGeoJSONを扱う場合は、検証方法を明確にしておくと安心です。ファイルを地図に読み込めるかどうかだけで判断するのではなく、構造がFeatureCollectionになっているか、各Featureにgeometryがあるか、座標配列が正しいか、propertiesに必要な属性が入っているかを確認します。仕様上、Featureのgeometryがnullになり得る場合もありますが、地図上に形状を表示する用途では、形状情報が適切に入っているかを確認することが重要です。

また、.jsonという汎用拡張子は、業務上の責任範囲を曖昧にしやすい面もあります。地図担当者はGeoJSONとして見ているが、開発担当者は一般的なJSONとして扱っている、データ管理担当者は単なる中間ファイルとして保管している、というように認識が分かれることがあります。これを防ぐには、ファイルの用途と形式を明文化することが必要です。

3点目の結論は、.jsonは汎用性が高く、システム連携では便利な場面がある一方で、GeoJSONであることが伝わりにくいということです。中身がGeoJSONであれば.jsonでも扱える可能性はありますが、関係者に意図を伝えるための説明や命名ルールが必要になります。

4点目：実務では連携先と運用ルールで使い分ける

4点目は、実務でどちらを選ぶべきかという判断基準です。.jsonと.geojsonの違いは、技術的な中身だけでなく、誰に渡すのか、どのシステムで読むのか、どのように保管するのかによって意味が変わります。そのため、単純に「常に.geojsonが正しい」「常に.jsonで十分」と決めるのではなく、利用場面に応じて選ぶことが大切です。

まず、地理空間データとして人に渡す場合は、.geojsonを選ぶのが分かりやすいです。地図に載せるための点、線、面のデータであることが一目で伝わり、受け取った側も地図関連のデータとして扱いやすくなります。納品物、共有フォルダ、調査成果、区域データ、現場記録の受け渡しなどでは、.geojsonを使うことで認識のずれを減らせます。

一方で、APIやシステム内部の処理では.jsonが使われる場面もあります。APIの応答としてGeoJSON構造を返す場合でも、URLや保存ファイルの拡張子が.jsonになっていることはあります。この場合、重要なのは拡張子よりも、応答の中身がGeoJSON形式になっているか、受け取る側がGeoJSONとして解釈する設計になっているかです。配信時のメディアタイプや仕様書の記述も合わせて確認する必要があります。

データ保管の観点では、検索性と分類性が判断基準になります。地理空間データを大量に保管するフォルダやデータ管理領域では、.geojsonに統一すると、後から探しやすくなります。ファイル名の末尾だけで地図用データを抽出できるため、整理や棚卸しもしやすくなります。逆に、汎用JSONの中にGeoJSON以外のデータも多く含まれる環境では、.jsonのまま保管し、別の管理項目で形式を示す運用も考えられます。

現場でよくあるのは、作成側と利用側で前提が違うケースです。作成側は「GeoJSONなので.geojsonで出したい」と考えていても、利用側の取り込み画面が.jsonしか選択対象にしない場合があります。逆に、作成側の出力が.jsonしか選べなくても、利用側では.geojsonを前提にマニュアルが作られている場合があります。このような場合は、拡張子の変更だけで対応できるのか、中身の変換が必要なのかを分けて考える必要があります。

単なるリネームで対応できるのは、中身がすでに正しいGeoJSON形式になっている場合です。たとえば、data.jsonの中身がFeatureCollectionとして正しく構成されているなら、必要に応じてdata.geojsonへ変更して運用できる可能性があります。ただし、拡張子変更後に読み込み確認を行うことは欠かせません。ファイル名を変えただけで処理が通ると思い込むと、受け渡し先の条件や配信設定で失敗することがあります。

中身の変換が必要なのは、単なるJSONの中に緯度、経度、名称、属性などが並んでいるだけの場合です。このようなデータは、見た目はJSONでもGeoJSONではありません。GeoJSONとして使うには、各レコードをFeatureに変換し、geometryにPointなどの形状を設定し、propertiesに属性情報を入れる必要があります。この作業を行わずに拡張子だけを.geojsonに変更しても、地図データとしては正しく扱えません。

チーム内で運用するなら、拡張子のルールを明文化しておくと効果的です。たとえば、地図上に直接読み込む完成データは.geojson、処理途中の汎用データは.json、APIの応答例は.jsonだが仕様上はGeoJSON構造とする、というように定義しておくと、担当者ごとの判断の揺れを減らせます。このルールは難しいものである必要はありません。誰が見ても同じ判断ができることが重要です。

外部にデータを渡す場合は、相手先の指定を優先します。納品仕様、取り込み仕様、データ連携仕様に拡張子が書かれているなら、それに合わせるべきです。指定がない場合でも、地理空間データとして渡す意図が明確なら.geojsonを選ぶと親切です。ただし、相手側が汎用JSONとして処理することを想定している場合は、.jsonのほうが適していることもあります。迷う場合は、ファイルの中身がGeoJSON形式であることを説明文やファイル名に含めると安全です。

4点目の結論は、拡張子の選択は単なる好みではなく、連携先、保管方法、読み込み環境、チーム内ルールによって決めるべきだということです。地理空間データとして明示したいなら.geojson、汎用JSONとして扱う必要があるなら.jsonを選び、そのうえで中身がGeoJSONとして正しいかを確認するのが実務的な判断になります。

GeoJSONファイルを扱うときに確認したい実務上の注意点

ここまでの4点を踏まえると、GeoJSONの拡張子をめぐる問題は、単に「どちらが正しいか」ではなく「どの場面で、何を伝えるために使うか」の問題だと分かります。実務では、拡張子の選択に加えて、いくつかの確認事項を押さえておくとトラブルを防ぎやすくなります。

まず確認したいのは、ファイルの中身が有効なJSONとして成立しているかどうかです。GeoJSONはJSONを土台にしているため、カンマの付け忘れ、引用符の不足、波かっこの閉じ忘れなどがあると、そもそも読み込めません。地図表示の前に、JSONとして構文エラーがないかを確認することが基本です。拡張子が.geojsonであっても、JSONとして壊れていれば利用できません。

次に、GeoJSONとして必要な構造を満たしているかを確認します。複数の地物を扱うなら、FeatureCollectionの中にfeaturesがあり、それぞれのFeatureにgeometryとpropertiesがあるかを見ます。geometryのtypeとcoordinatesの階層が合っているかも重要です。Point、LineString、Polygonではcoordinatesの構造が異なるため、形状タイプに合わない配列になっていると正しく表示できません。

座標の順序も実務上の大きな落とし穴です。住所や現地調査では「緯度、経度」の順で扱うことが多いため、GeoJSONにするときにそのまま入れてしまうミスが起こります。しかし、標準的なGeoJSONの座標は「経度、緯度」の順です。日本国内のデータでこの順序を間違えると、まったく別の場所に表示されたり、表示範囲外に飛んでしまったりします。地図に表示されない場合は、拡張子より先に座標順序を疑うべきです。

測地系や座標の前提も確認が必要です。RFC 7946に基づくGeoJSONでは、WGS84の経度・緯度を十進度で表すことが前提です。業務で扱う平面直角座標やローカル座標をそのまま入れると、一般的な地図上では正しく表示されないことがあります。測量成果や設計データからGeoJSONを作成する場合は、座標変換が必要になることがあります。拡張子を.geojsonにしただけでは、座標系の問題は解決しません。

属性情報の扱いも重要です。propertiesには、名称、分類、管理番号、調査日時、状態、担当者、メモなど、地物に付随する情報を入れられます。ただし、属性名が統一されていないと、後工程で集計や検索が難しくなります。name、名称、titleのように同じ意味の項目が混在すると、地図表示では見えても業務データとして扱いにくくなります。GeoJSONを実務で使うなら、属性名と値のルールも合わせて決めておくべきです。

ファイルサイズにも注意が必要です。GeoJSONはテキスト形式で読みやすい反面、非常に多くの座標を含むデータでは容量が大きくなりやすいです。細かすぎる境界線、多数の点、複雑なポリゴンをそのまま格納すると、読み込みや表示に時間がかかる場合があります。用途に応じて形状を簡略化したり、範囲ごとにファイルを分けたり、必要な属性だけに絞ったりする工夫が必要です。

ファイル名の付け方も実務品質に関わります。単にdata.geojsonとするより、対象地域、データ内容、作成日、用途が分かる名前にしておくと、後から見直すときに便利です。ただし、ファイル名に情報を詰め込みすぎると長くなりすぎるため、フォルダ構成や管理台帳と組み合わせて整理すると扱いやすくなります。拡張子だけに頼らず、ファイル名全体で意味が伝わるようにすることが大切です。

受け渡し時には、.jsonか.geojsonかだけでなく、データの前提条件も共有します。座標の順序、座標の前提、地物の種類、属性項目の意味、更新日、作成目的、読み込み確認の有無などを簡単に添えておくと、受け取った側の手戻りを減らせます。特に外部の関係者に渡す場合、ファイルを開けるかどうかだけでなく、正しく解釈できるかどうかが重要です。

システム連携では、拡張子と配信時のメディアタイプがずれることにも注意が必要です。ファイル名は.geojsonなのに配信側では汎用JSONとして扱われている、またはファイル名は.jsonなのに中身はGeoJSONとして設計されている、ということがあります。どちらが問題になるかは受け取る側の実装によります。地図表示や自動処理でうまく動かない場合は、ファイル名、中身、配信設定の3つを切り分けて確認すると原因を見つけやすくなります。

バージョン管理や更新履歴も見落とせません。GeoJSONはテキスト形式なので差分を確認しやすい反面、座標が大量にある場合は変更箇所が分かりにくくなります。現場で更新されたデータ、机上で編集されたデータ、検証済みのデータが混在すると、どれが正なのか判断できなくなります。完成版と作業版を分ける、更新日を明記する、公開用のファイルだけ.geojsonにするなど、運用上の工夫が必要です。

最終的には、拡張子の選択はデータ品質管理の一部として考えるのがよいです。.geojsonにすることで地理空間データだと伝える、.jsonにすることで汎用JSONとして連携しやすくする、どちらの場合も中身の検証とルール化が欠かせません。GeoJSONは扱いやすい形式ですが、扱いやすいからこそ、命名や座標、属性、受け渡し方法の小さなズレが後の作業に影響します。

まとめ：拡張子より中身、ただし運用では拡張子が効く

GeoJSONの拡張子.jsonと.geojsonの違いを整理すると、もっとも大切なのは「拡張子だけで中身が変わるわけではない」という点です。GeoJSONかどうかは、ファイル名ではなく、Feature、geometry、coordinates、propertiesなどの構造が正しく記述されているかで判断します。.jsonであっても中身がGeoJSON形式ならGeoJSONとして扱える場合があり、.geojsonであっても中身が正しくなければ利用できません。

一方で、実務では拡張子が大きな意味を持ちます。.geojsonは地理空間データであることを分かりやすく示せるため、共有、納品、保管、検索、自動処理に向いています。地図に載せるためのデータ、現地調査成果、区域やルートのデータなど、用途が明確に地理空間である場合は.geojsonを使うと関係者に意図が伝わりやすくなります。

.jsonは汎用的な拡張子として、API連携やシステム内部の処理に向いています。GeoJSONもJSONを土台にしているため、システム上の都合で.jsonとして扱うことがあります。ただし、.jsonのままではGeoJSONであることが伝わりにくいため、ファイル名、仕様書、説明文、管理項目などで補足する必要があります。

実務で迷ったときは、まず中身がGeoJSONとして正しいかを確認し、そのうえで受け渡し先が何を期待しているかを見ます。地理空間データとして人や地図関連の処理に渡すなら.geojson、汎用JSONとしてシステムが受け取るなら.jsonが候補になります。どちらを選ぶ場合でも、座標の順序、座標の前提、属性名、ファイルサイズ、配信設定、更新履歴まで確認しておくと、後工程のトラブルを減らせます。

GeoJSONは、位置情報を業務データとして扱ううえで便利な形式です。拡張子の違いを正しく理解しておけば、現地で取得した点や線、面のデータを、地図表示、管理台帳、報告資料、システム連携へつなげやすくなります。公開前には、拡張子だけで判断せず、中身の構造、座標順序、座標系、属性、受け渡し先の仕様を確認してから運用することが大切です。