GeoJSONとShapefileの違いを3分で整理する基礎知識

目次

• GeoJSONとShapefileの違いをまず一言で整理する

• GeoJSONはWebで扱いやすい地理空間データ形式

• Shapefileは業務データ交換で使われてきた定番形式

• 形状データと属性データの持ち方の違い

• 座標系と文字コードで注意すべき違い

• ファイル構成と受け渡しやすさの違い

• Web表示やシステム連携での使いやすさ

• 測量・土木・設備管理で使い分ける考え方

• 変換時に起きやすいトラブルと確認ポイント

• GeoJSONとShapefileを実務で安全に扱うためのまとめ

GeoJSONとShapefileの違いをまず一言で整理する

GeoJSONとShapefileは、どちらも地図上の点、線、面といった地理空間データを扱うための形式です。たとえば、現場位置、道路中心線、敷地境界、管路ルート、点検箇所、区域ポリゴンなどをデータとして保存し、地図やGIS上で表示する場面で使われます。そのため、初めて「geojson」と検索した実務担当者にとっては、どちらも似たものに見えるかもしれません。

大きな違いを一言で表すなら、GeoJSONはWebやシステム連携で扱いやすいJSONベースのテキスト形式、Shapefileは従来のGIS業務で広く使われてきた複数ファイル構成の形式です。GeoJSONは中身をテキストとして確認しやすく、Web地図や業務システムに組み込みやすい特徴があります。一方、Shapefileは長年のGIS実務で利用されてきた形式で、官公庁、建設、測量、インフラ管理、環境調査などのデータ交換で見かけることが多い形式です。

ただし、どちらが常に優れているという話ではありません。GeoJSONは扱いやすい一方、大容量データや精度が求められる業務運用では、座標系、属性設計、表示速度に注意が必要です。Shapefileは古くから使われているため互換性の面で便利な場面がありますが、ファイル構成、文字コード、属性名、座標系情報の扱いなどで注意点があります。つまり、目的がWeb表示なのか、GIS解析なのか、現場での確認なのか、発注者や協力会社とのデータ受け渡しなのかによって、適した形式は変わります。

この記事では、GeoJSONとShapefileの違いを、実務担当者が判断しやすいように基礎から整理します。専門的な仕様を細かく追いかけるよりも、実際にデータを受け取る、変換する、地図に表示する、現場情報と紐づけるといった場面で何を確認すればよいかに重点を置いて解説します。

GeoJSONはWebで扱いやすい地理空間データ形式

GeoJSONは、地理空間情報をJSON形式のテキストで表現するデータ形式です。点、線、面といった形状情報と、その形状に紐づく属性情報を一つの構造の中で扱えます。中身は人が読めるテキストで記述されているため、ファイルを開くと座標や名称、種別、管理番号などの情報を確認しやすい点が特徴です。

GeoJSONでよく扱われる形状には、点、複数の点、線、複数の線、面、複数の面などがあります。たとえば、電柱やマンホールの位置は点、道路や配管は線、敷地や管理区域は面として表現できます。さらに、それぞれの形状には属性を持たせることができます。属性には、名称、種別、状態、点検日、管理番号、備考など、業務上必要な情報を入れられます。

実務でGeoJSONが便利なのは、Web地図との相性がよいことです。ブラウザ上で地図を表示し、そこに点検箇所や測量成果、区域情報を重ねたい場合、GeoJSONは比較的扱いやすい形式です。地図表示用のプログラムや業務システムがGeoJSONを読み込めるようにしておけば、位置情報と属性情報をまとめて表示できます。たとえば、現場一覧を地図に表示し、クリックすると点検結果や写真番号を確認できるような仕組みにも使いやすいです。

また、GeoJSONは単一ファイルとして扱えることが多く、メールや共有フォルダ、業務システムへのアップロードでも管理しやすい傾向があります。Shapefileのように複数の関連ファイルをまとめて扱う必要がないため、受け渡し時に一部のファイルが欠ける事故を避けやすくなります。小規模から中規模のデータであれば、現場確認用の地図データ、簡易な台帳データ、Web表示用データとして使いやすい形式です。

一方で、GeoJSONにも注意点があります。標準的なGeoJSONでは、座標は経度、緯度の順で記録され、地理座標として扱うことが基本です。しかし実務では、変換途中のデータや独自運用のファイルがGeoJSONという名前で流通することもあります。座標値の桁や範囲が経度緯度として妥当か、元データの座標系が何か、変換時に座標順が入れ替わっていないかを確認することが重要です。

また、GeoJSONはテキスト形式であるため、非常に多くの頂点や複雑な面を含むデータではファイルサイズが大きくなりやすく、表示や読み込みが遅くなることがあります。Web表示に使いやすいからといって、受け取ったデータをそのまま公開用や業務判断用に使えるとは限りません。座標系、属性内容、形状の妥当性を確認したうえで、用途に合う範囲に整理して使うことが大切です。

Shapefileは業務データ交換で使われてきた定番形式

Shapefileは、GIS業務で長く使われてきた地理空間データ形式です。測量成果、道路台帳、設備管理、行政区域、土地利用、地形情報など、さまざまな分野で見かける機会があります。現在でも、既存データの提供形式や、発注者と受注者のデータ交換形式として使われることがあります。

Shapefileの大きな特徴は、一つのデータが複数のファイルで構成されることです。代表的には、形状を格納するファイル、形状の索引を格納するファイル、属性情報を格納するファイルが一組になって機能します。さらに、座標系情報や文字コード情報、メタデータを補うファイルが付属する場合もあります。利用する側は、これらの関連ファイルを同じフォルダ内にそろえて管理する必要があります。

この複数ファイル構成は、慣れていない担当者にとっては分かりにくい点です。たとえば、見た目には一つのデータ名でも、実際には複数の拡張子を持つファイル群で構成されています。そのうち一部だけを送付したり、圧縮時に漏れたり、フォルダを整理するときに分離したりすると、GISソフトで正しく読み込めなくなることがあります。Shapefileを受け渡すときは、関連ファイル一式をまとめて扱う意識が欠かせません。

Shapefileは多くのGIS環境で読み込みに対応しているため、既存資産との互換性という点では有利な場面があります。古い業務データ、過去の納品成果、行政系の空間データ、測量や設計の中間成果などでShapefileが使われている場合、無理に別形式へ置き換えるよりも、まずは正しく読み込み、座標系と属性を確認することが実務上は現実的です。

ただし、Shapefileは仕様上の制約も意識する必要があります。属性名の長さ、扱えるデータ型、文字コード、ファイルサイズ、座標系情報の明示方法などで、現代的なWeb連携や柔軟な属性管理と比べると注意点が多くなります。特に、属性名が短縮されて意味が分かりにくくなる、文字化けが起きる、座標系が別資料にしか書かれていない、といった問題は実務でよく起こります。

また、Shapefileでは点、線、面といった形状種別をレイヤーごとに分けて扱うのが基本です。設備管理のように点設備、管路、管理区域が混在する業務では、用途に応じてファイルやレイヤーを分ける必要があります。形式として使えるかどうかだけでなく、後から検索、編集、更新しやすい構成になっているかを確認することが重要です。

形状データと属性データの持ち方の違い

GeoJSONとShapefileの違いを理解するうえで、形状データと属性データの持ち方は重要です。地理空間データは、地図上の位置や形を示す形状情報と、それが何であるかを説明する属性情報で成り立っています。点であれば座標、線であれば連続した座標列、面であれば閉じた座標列が形状情報です。属性情報には、名称、分類、管理番号、点検結果、施工区分などが入ります。

GeoJSONでは、形状と属性が一つのテキスト構造の中にまとまっています。一つひとつの地物に対して、形状を表す部分と属性を表す部分がセットで記述されます。そのため、ファイルを確認したときに、この点はどの名称なのか、この線はどの路線なのか、この面はどの区域なのかを追いやすい構造です。プログラムで読み取る場合も、形状と属性をまとめて扱いやすく、Webシステムへの組み込みにも向いています。

Shapefileでは、形状情報と属性情報が別々の関連ファイルに分かれて管理されます。利用者がGIS画面で見るときは一体化して表示されますが、ファイル構造としては複数のファイルが連携している状態です。この仕組みにより、GISソフト上では安定して扱える一方、ファイルの一部が欠けると属性が読めない、座標系情報が分からない、形状と属性の対応関係を確認しにくい、といったリスクがあります。

属性の柔軟性という面では、GeoJSONのほうが現代的なデータ連携に向いている場面があります。属性の中に文字列、数値、真偽値などを持たせることができ、必要に応じて配列や入れ子構造を使うこともできます。ただし、実務で複雑な入れ子構造を多用すると、別のシステムや担当者が読み取りにくくなる場合があります。GeoJSONだから自由に書けばよいのではなく、属性名や値のルールを決めておくことが大切です。

Shapefileの属性は表形式に近い考え方で扱われます。行と列で整理されるため、台帳データとして理解しやすい反面、属性名の長さや扱える値の型に制約が出ることがあります。たとえば、長い日本語の項目名をそのまま使いたい場合や、階層的な情報を持たせたい場合には不向きなことがあります。実務では、Shapefileで受け取った属性名が短縮されており、別紙の項目定義を見ないと意味が分からないということもあります。

どちらの形式でも、形状と属性が正しく対応しているかを確認することが重要です。地図上に表示できたからといって、属性が正しいとは限りません。点検箇所の位置は合っていても管理番号がずれている、路線形状は正しくても路線名が別の線に入っている、区域ポリゴンは表示されても面積区分が誤っている、といった問題は起こり得ます。形式の違いだけでなく、データ内容の整合性を確認する視点が必要です。

座標系と文字コードで注意すべき違い

GeoJSONとShapefileを扱うときに、最も実務トラブルにつながりやすいのが座標系です。座標系とは、地球上の位置をどの基準で数値化するかというルールです。同じ地点でも、使う座標系が異なれば座標値は変わります。座標系を誤って解釈すると、地図上で数十メートル、数百メートル、場合によってはそれ以上のずれが生じることがあります。

GeoJSONでは、標準仕様上はWGS 84の経度、緯度を十進度で扱うことが基本です。Web地図と重ねる用途では、この前提が特に重要になります。経度と緯度の順序を逆にしたり、平面直角座標系の値をそのままGeoJSONとして扱ったりすると、想定外の位置に表示される原因になります。GeoJSONを受け取ったときは、座標値の範囲、座標の順序、元データの座標系を確認することが安全です。

一方で、実務ではGeoJSONという拡張子や名前であっても、作成過程が不明なデータが流通することがあります。たとえば、平面直角座標系やローカル座標の値を変換しないまま保存したデータ、古い仕様や独自ルールを前提にしたデータ、変換ツールの設定が誤っているデータなどです。そのため、GeoJSONだから必ずそのままWeb地図に正しく重なる、と決めつけるのは危険です。

Shapefileでは、座標系情報が付属ファイルに記録されている場合があります。しかし、そのファイルが欠けていたり、内容が実際のデータと一致していなかったり、受け渡し時に座標系の説明が別紙扱いになっていたりすることがあります。Shapefileを受け取ったときは、地図上に読み込めたかどうかだけで判断せず、既知の基準点、道路、建物外形、行政界などと重ねて位置を確認することが大切です。

文字コードも見落としやすいポイントです。GeoJSONはテキスト形式で扱われるため、比較的文字コードを統一しやすい傾向があります。日本語の属性名や属性値も扱えますが、システムや編集環境によっては文字化けが起きることがあります。特に、複数の担当者が異なる環境で編集したデータをやり取りする場合は、文字コード、改行、特殊文字の扱いに注意が必要です。

Shapefileでは、属性情報の文字コードが原因で日本語が文字化けすることがあります。道路名、施設名、点検区分、施工者名、備考などに日本語が含まれる場合、読み込む環境によって表示が崩れることがあります。文字化けした状態で変換や編集を行うと、後から元に戻せなくなることもあります。Shapefileを受け取ったら、まず属性テーブルを開き、日本語が正しく表示されているかを確認するのが安全です。

座標系と文字コードは、見た目の地図表示だけでは気づきにくい問題です。特に、ShapefileをGeoJSONへ変換してWeb地図に表示する場合、元データの座標系を正しく解釈できていなければ、現場位置がずれて表示されます。また、属性の文字化けに気づかず公開用データにしてしまうと、現場担当者が誤った情報を確認する原因になります。形式変換の前後では、位置と文字の両方を点検することが重要です。

ファイル構成と受け渡しやすさの違い

GeoJSONとShapefileの実務上の分かりやすい違いは、ファイル構成です。GeoJSONは基本的に一つのファイルとして扱えることが多く、形状と属性が同じファイル内にまとまっています。そのため、社内共有、システム登録、Web表示、簡易確認などでは扱いやすい形式です。ファイルを一つ指定すれば読み込めるため、データの取り違えや添付漏れを減らしやすいという利点があります。

Shapefileは一つの名前を持つデータであっても、実際には複数のファイルが必要です。拡張子の異なる関連ファイルが同じフォルダにそろっていないと、正しく読み込めないことがあります。たとえば、形状は表示されても属性が読めない、座標系が不明になる、文字コードが判別しにくいといった問題が起きます。Shapefileを送るときは、関連ファイル一式をまとめ、圧縮して渡す運用が一般的に安全です。

受け渡しのしやすさでは、GeoJSONのほうが分かりやすい場面が多いです。特に、GISに詳しくない担当者がデータを扱う場合、一つのファイルで完結することは大きなメリットです。現場確認用のデータ、打合せ用の位置情報、Web上での簡易表示、軽量な区域データなどでは、GeoJSONの単純さが役立ちます。

一方で、Shapefileの複数ファイル構成には、既存のGIS業務との互換性という実務的な価値があります。過去の成果や既存の台帳がShapefileで管理されている場合、協力会社や発注者とのやり取りも同じ形式のほうが円滑なことがあります。無理にGeoJSONへ変換すると、属性名の変化、座標系の変換ミス、面の構造の変化などが発生する可能性もあります。目的がGIS上での編集や解析であれば、Shapefileのまま扱うほうが確認しやすい場面もあります。

また、データ量にも注意が必要です。GeoJSONはテキスト形式なので、中身を確認しやすい一方、複雑な形状や大量の頂点を含むデータでは重くなりやすいです。Shapefileにもファイルサイズなどの制約がありますが、従来のGIS環境での表示や編集に慣れている担当者にとっては扱いやすい場合があります。Web表示を目的にするなら、データを必要な範囲に絞る、形状を単純化する、属性を整理するなどの前処理が重要になります。

受け渡し時には、形式名だけでなく、データの目的、座標系、属性定義、更新日、作成範囲、作成方法を一緒に伝えることが大切です。GeoJSONであってもShapefileであっても、ファイルだけを渡して「見れば分かる」という運用はトラブルの原因になります。特に土木、測量、設備管理のように、位置の正確さや管理番号の整合性が重要な業務では、ファイル形式よりもデータの前提条件を明確にすることが欠かせません。

Web表示やシステム連携での使いやすさ

Web地図や業務システムで位置情報を表示したい場合、GeoJSONは扱いやすい選択肢です。地図上に点検箇所を表示する、線形データを重ねる、区域ごとに色分けする、クリックした地物の属性を表示する、といった用途に向いています。テキスト形式で構造が分かりやすいため、システム側で読み込み、必要な属性を画面に出す処理を組みやすいことも特徴です。

GeoJSONは、Web上でデータを受け渡すときにも使いやすい形式です。サーバーから地図表示画面へ地物情報を渡す、現場で入力した位置情報を保存する、別の業務システムへ点検結果を連携するなど、位置と属性をまとめて扱う場面で便利です。ファイルとして保存するだけでなく、システム間のデータ交換形式として使われることもあります。

Shapefileは、Web表示のためにそのまま使うよりも、いったん別形式へ変換して使うことが多い形式です。Shapefileのままでは複数ファイルを扱う必要があり、Web画面で直接読み込む運用には向かない場合があります。そのため、既存のShapefileを元データとして管理し、公開用や閲覧用にはGeoJSONなどの扱いやすい形式へ変換する流れがよくあります。

ただし、変換すれば自動的に最適なWebデータになるわけではありません。ShapefileからGeoJSONに変換しただけでは、頂点数が多すぎて表示が重い、属性が多すぎて画面が使いにくい、文字化けが残っている、座標系が合っていない、といった問題が残ることがあります。Web表示用のGeoJSONを作る場合は、元データの情報量をそのまま詰め込むのではなく、利用目的に合わせて整理する必要があります。

システム連携では、属性名の設計も重要です。GeoJSONは属性を柔軟に持てますが、担当者ごとに項目名を変えてしまうと、検索、集計、表示、更新がしにくくなります。たとえば、同じ管理番号でも「番号」「管理No」「id」「施設番号」のように表記が揺れると、システム側で扱いにくくなります。GeoJSONを使う場合でも、属性名、必須項目、値の形式、空欄の扱いを事前に決めておくことが大切です。

Web表示では、見た目の分かりやすさとデータの正確さの両方が必要です。位置が少しずれていても地図上ではそれらしく見えることがありますが、現場での確認や施工判断、点検記録の整理では大きな問題になることがあります。特に、構造物、道路、配管、境界、危険箇所などを扱う場合は、Web地図に表示できたことを完成とせず、現地写真、測量成果、台帳情報、既存図面と照合する工程を入れることが望ましいです。

測量・土木・設備管理で使い分ける考え方

測量、土木、設備管理の実務では、GeoJSONとShapefileを目的に応じて使い分けることが重要です。どちらか一方だけを覚えれば十分というより、元データ、編集用データ、確認用データ、共有用データで形式を分ける考え方が実務的です。

たとえば、既存の道路台帳や設備台帳がShapefileで管理されている場合、元データとしてはShapefileを維持し、必要な範囲だけをGeoJSONに変換して現場確認やWeb表示に使う方法があります。この場合、Shapefileは管理・編集用、GeoJSONは閲覧・共有用という役割分担になります。元データを不用意に変換して上書きするのではなく、変換後データは用途を限定して管理するほうが安全です。

現場での確認を重視する場合、GeoJSONは扱いやすい形式です。点検箇所、撮影位置、出来形確認位置、仮設物の配置、補修範囲などを地図上に表示し、担当者が属性を確認する用途に向いています。データを軽量化しておけば、現場端末や社内の閲覧画面でも使いやすくなります。特に、複数人が同じ位置情報を見ながら打合せをする場合、GeoJSONの単一ファイルとしての扱いやすさは有効です。

一方、測量成果や設計検討、解析用データとしては、Shapefileを含むGIS向け形式が必要になる場面があります。既存のGIS環境で読み込み、属性テーブルを確認し、他のレイヤーと重ね、空間的な集計や抽出を行う場合には、Shapefileの互換性が役立つことがあります。特に、過去データとの整合性を確認する場合や、発注者が指定する形式がある場合は、その指定に従う必要があります。

設備管理では、点、線、面が混在することが多いため、データ形式だけでなくレイヤー構成も重要です。点として管理する設備、線として管理する管路やケーブル、面として管理する施設範囲や点検区域を分けて整理する必要があります。GeoJSONでもShapefileでも、点と線と面をどのように分けるかを決めておかないと、後から検索や表示がしにくくなります。

また、土木や建築に近い現場では、図面由来の座標、測量由来の座標、地図由来の座標が混在しやすいです。図面上では正しく見える線が、地理座標に変換するとずれることがあります。現場で取得した位置情報と既存GISデータを重ねる場合も、測位精度や座標系の違いを理解しておく必要があります。GeoJSONとShapefileの違いを知ることは、単なるファイル形式の知識ではなく、位置情報を正しく扱うための入口です。

変換時に起きやすいトラブルと確認ポイント

GeoJSONとShapefileは相互に変換されることがあります。既存のShapefileをWeb表示用にGeoJSONへ変換する、現場で作成したGeoJSONをGIS編集用に変換する、といった場面です。変換自体は一般的なGISソフトや変換ツールで行えますが、変換後の確認を省略すると実務上のトラブルにつながります。

最も多い問題は座標系のずれです。Shapefileの座標系情報が正しく読み取られないままGeoJSONへ変換すると、地図上で位置がずれることがあります。逆に、GeoJSONに入っている座標が標準的な経度緯度ではないのに、経度緯度として扱ってしまうと、想定外の場所に表示されます。変換前に元データの座標系を確認し、変換後に既知の地点と重ねて確認することが必要です。

次に注意したいのが文字化けです。Shapefileの属性に日本語が含まれる場合、変換時に文字コードが合わず、属性値が崩れることがあります。文字化けしたままGeoJSONへ変換すると、Web表示や台帳連携でそのまま誤った文字が使われます。変換前後で属性テーブルやGeoJSONの中身を確認し、名称や備考が正しく表示されているかを見ることが大切です。

属性名の変化にも注意が必要です。Shapefileでは属性名に制約があるため、長い項目名が短縮されていることがあります。GeoJSONへ変換した後も、その短縮名が引き継がれると、Web画面や業務システム上で意味が分かりにくい項目名になります。たとえば、現場担当者が見て理解できない項目名では、せっかく地図に表示しても使いづらくなります。変換後に表示用の項目名を整理する工程を入れると、実務で使いやすいデータになります。

形状の崩れも確認が必要です。面データでは、穴あきポリゴン、複数ポリゴン、自己交差、閉じていないリングなどが問題になることがあります。Shapefile上では表示できていた面が、GeoJSONへ変換したときに期待どおり表示されないこともあります。線データでは、線の分割単位や方向、重複線、細かなノイズが問題になることがあります。点データでは、同一点に複数の属性が重なっている場合や、微妙な位置ずれが見落とされることがあります。

ファイルサイズも重要です。詳細な境界線や複雑な地形データをそのままGeoJSONにすると、ファイルが大きくなり、Web表示が遅くなることがあります。実務で閲覧用に使う場合は、必要な範囲だけに切り出す、表示縮尺に応じて形状を簡略化する、不要な属性を削るなどの整理が必要です。ただし、簡略化しすぎると境界や施設位置の意味が変わる場合があるため、用途に合わせた判断が必要です。

変換後の確認では、元データと変換後データを重ねて見比べることが有効です。位置、形状、属性件数、属性名、文字化け、面積や延長の概算、代表地点の座標などを確認すると、変換ミスに気づきやすくなります。特に、納品、公開、協議資料、現場指示に使うデータでは、変換できたことではなく、業務目的に対して正しく使えることを確認する必要があります。

GeoJSONとShapefileを実務で安全に扱うためのまとめ

GeoJSONとShapefileは、どちらも地理空間データを扱うための重要な形式です。GeoJSONはWeb表示やシステム連携に向いており、単一ファイルで扱いやすく、中身をテキストとして確認しやすい特徴があります。Shapefileは従来のGIS業務で広く使われてきた形式で、既存データや発注者指定の成果、過去の台帳との互換性が求められる場面で使われます。

実務で大切なのは、形式名だけで判断しないことです。GeoJSONだから新しくて安全、Shapefileだから古くて使いにくい、という単純な整理では不十分です。Web地図に表示するならGeoJSONが便利な場面が多いですが、元データの座標系や属性が誤っていれば、表示結果も誤ったものになります。Shapefileは複数ファイル構成や文字コードの注意点がありますが、既存のGIS業務では今でも扱いやすい場面があります。

受け取ったデータを確認するときは、まず何のためのデータかを整理することが大切です。閲覧用なのか、編集用なのか、解析用なのか、現場確認用なのか、納品用なのかによって、適した形式と確認項目は変わります。次に、座標系、文字コード、属性定義、形状種別、データ件数、作成日、更新日、作成範囲を確認します。これらが分からないまま変換や共有を進めると、後工程で手戻りが発生しやすくなります。

GeoJSONを使う場合は、標準的な座標の前提を確認したうえで、属性名を分かりやすく統一し、必要な情報だけを整理して持たせることが重要です。Web表示や現場共有では、利用者がすぐ理解できる項目名と値にしておくことで、データの使いやすさが大きく変わります。また、大容量データをそのまま表示しようとせず、用途に合わせて範囲や形状を整理することも大切です。

Shapefileを使う場合は、関連ファイル一式を欠けなく管理し、座標系情報や文字コードを確認することが重要です。ファイルを送付するときは、必要なファイルをまとめて扱い、受け取り側が座標系や属性の意味を理解できるように説明を添えると安全です。属性名が短縮されている場合は、項目定義を別途整理しておくと、後工程での誤解を防ぎやすくなります。

GeoJSONとShapefileの違いを理解しておくと、地図データを受け取ったときに何を確認すべきか、Web表示に使うには何を変換すべきか、現場で共有するにはどこを整理すべきかが見えやすくなります。特に、測量、土木、設備管理、点検、施工管理のように、位置と属性の整合性が重要な業務では、データ形式の選択がそのまま作業効率や確認精度に関わります。

現場で取得した位置情報や点検記録を、あとから地図上で確認し、関係者と共有し、台帳や報告資料に活かすには、最初のデータ整理が重要です。GeoJSONはその入口として扱いやすい形式ですが、座標系、属性、形状、ファイルサイズ、受け渡し条件を確認しなければ、誤った位置情報を広げてしまう可能性があります。GeoJSONとShapefileは対立する形式ではなく、元データの管理、現場確認、Web共有、納品条件に合わせて使い分けることで、地理空間データを日々の業務に取り入れやすくなります。