GISデータとは？形式・座標系・取り込み設計を実装目線で解説【2026年8月時点】

GISデータとは、位置を持つ図形と、その図形に紐づく属性、そして座標が何を基準にしているかを示す座標系の三点がそろったデータを指します。実装でつまずくのは形式の名前ではありません。届いたファイルに座標系の情報がない、属性名が途中で切れている、住所しかなく座標が入っていない、といった取り込みの現場です。本記事では形式の使い分け、座標系の指定、公開データの取り込み、住所の座標化、空間インデックスの設計を順に整理しました。版番号は2026年8月22日の実測です。

まとめ｜GISデータの形式選定と座標系・取り込み設計の要点

先に結論を置きます。決めるのは三つです。受け渡しに使う形式と自社で持ち続ける形式を分けること、座標系をデータの一部として必ず受け取ること、住所しかないデータは正規化してから座標化すること。この三つを取り込み口で固めれば、後工程の作り直しは起きません。

形式は二段構えにします。外部から届くのはShapefileかGeoJSONで、これは避けられない。ただし自社の保管をShapefileのままにすると、属性名10文字とファイル2GBという上限に必ず当たります。保管はGeoPackageかPostGISへ寄せ、Shapefileは入口と出口だけで使う。座標系は日本測地系2011の地理座標系（EPSG:6668）で持ち、距離や面積を測るときだけ平面直角座標系へ投影する運用が扱いやすいでしょう。

地図をどう画面に出すかは本記事の範囲外です。配信方式と描画ライブラリの選定は兄弟記事のWeb GISとは？タイル配信とベクタタイル・ライブラリ選定を実装目線で解説にまとめてあります。そもそも地図機能を自社システムに載せるべきかという段階なら、判断ハブのGISとは？地理情報システムの仕組み・種類と業務システムへの組み込み判断を先に読んでください。

GISデータとは何か、図形・属性・座標系の三点セットで分解する

GISデータという言葉は、地図に載るデータ全般を指す広い使われ方をします。実装では図形と、図形に紐づく属性、そして座標系の三つに分けたほうが整理しやすい。座標系だけが目に見えないため、受け渡しで欠落しがちです。

ベクタデータは点・線・面の図形と属性テーブルが対で成り立つ構造

ベクタデータは、座標値の並びで図形を表す持ち方です。施設や設備の位置は点、道路や配管は線、行政界や敷地は面で表し、それぞれの図形に1行の属性が対応します。属性側は普通のテーブルなので、名称・管理番号・点検日といった業務項目をそのまま持てる。

この持ち方の利点は三つあります。拡大しても輪郭が崩れないこと、面積や距離を計算できること、属性の条件で絞り込めること。顧客の所在地も設備の配置も点と属性の組で表せるため、業務システムが扱うデータの大半はこちらに寄ります。

ラスタデータは一定間隔の画素の格子で、標高や衛星画像が代表例

ラスタデータは、一定間隔の格子に値を並べた持ち方です。標高、傾斜、土地被覆、航空写真、気象の推計値。1画素が地上の何メートルに相当するかという分解能が、判断できる細かさの上限を決めます。

ある地点の値を読む処理は速い一方、境界線を厳密に扱う用途には向きません。画素の境目より細かい判定はできないため、敷地の境界を1メートル単位で争う場面で根拠にすると説明がつかなくなります。

二つの持ち方の選び分けは、境界を扱うか値を読むかの処理で決まる

判断はデータの中身ではなく、実行する処理の中身で決めます。「この区画の面積は何平方メートルか」「この線の総延長は何キロか」を答える処理ならベクタ。「この地点の標高は何メートルか」「この範囲の平均値はいくつか」ならラスタになります。

両方が要る要件では、片方へ寄せて変換せず別々に持ちます。ラスタをベクタへ変換すると画素の階段が図形として固定され、以後の面積計算がその階段を引きずるためです。

ファイル形式の使い分けはShapefileの制約から逆算して決める

形式の選定は、交換用と保管用を分けて考えると迷いが減ります。以下では上限値と前提条件を形式ごとに見ていきます。

Shapefileが今も残る理由と、10文字と2GBという二つの上限

Shapefileは複数のファイルの組で一つのデータを表す古い形式で、図形の.shp、索引の.shx、属性の.dbfが最低限そろって初めて読めます。属性を持つ.dbfがdBASE由来のため、制約はここに集中しました。Esriのドキュメントでは、フィールド名は10文字以内、フィールド数は255まで、構成ファイルはそれぞれ2GBまでと明記されています。

さらにNULLを持てず、空の数値は極端な負値へ、文字は空白へ置き換わる。日付型は時刻を持てません。日本語の属性名は文字コードの取り違えで化けるため、受け入れ時に.cpgファイルの有無を確認する手順が要ります。それでも残っているのは、行政の配布データと商用ソフトの入出力が今もこれを前提にしているからです。届く形式としては付き合いますが、保管先には選びません。

GeoJSONはWGS84固定が前提、規模が効いてくる境目を見る

GeoJSONはRFC 7946で規定された形式で、座標参照系はWGS84（経度・緯度の順）に固定されました。独自の座標系を宣言する仕組みは仕様から外れています。平面直角座標系の数値をそのまま入れて渡すと、受け取り側では地球の裏側に落ちる。この事故は今も定期的に起きます。

テキスト形式なのでバージョン管理システムで差分が見え、Webのやり取りにそのまま載ります。ただし全体を読み込む前提のため件数が増えると重くなる。数千件までは扱いやすく、数万件を超えるならタイル化かデータベース格納へ切り替えます。

GeoPackage 1.4は単一ファイルのSQLiteで索引まで持ち運べる

OGCのGeoPackageは、SQLiteのファイル一つにベクタもラスタも属性もまとめて入れられる形式です。バージョン1.4.0が2024年2月6日に公開され、日時形式の条件緩和とR-treeインデックストリガの更新が入りました。属性名の長さ制限がなく、日本語もそのまま持てます。

受け渡しの事故が減る点が実務では効きます。Shapefileは構成ファイルを一つ落とすだけで読めなくなりますが、GeoPackageは一つで完結する。空間索引を内包できるため、渡した先でそのまま検索が動きます。

ラスタはGeoTIFFとCOGで、置き場所と読み方が変わってくる

GeoTIFFは画像ファイルに座標系と位置情報を埋め込んだ形式で、標高や航空写真の受け渡しに使われる形です。これをクラウドに置いて配るなら、Cloud Optimized GeoTIFF（COG）を選びます。OGC標準のv1.0が2023年7月に公開され、2019年9月のGeoTIFF標準および1995年の元仕様と後方互換を保っています。

COGは内部をタイル状に並べ、縮小画像を同じファイルへ内包します。HTTPのRange取得で必要な範囲だけを読めるため、数ギガバイトの画像でも全体を落とさずに表示できる。既存ソフトからは普通のGeoTIFFに見えます。

形式の変換はGDALのogr2ogrとgdal_translateで足ります。最新版は2026年8月18日公開の3.13.3です。

座標系と測地系の指定漏れが、地図のずれと距離の誤差を同時に生む

形式の次に決めるのが座標系です。値そのものではなく前提を扱うため、取り込み口の仕様に落とし込まないと後から確認できません。

JGD2011の地理座標系EPSG:6668と平面直角座標系19系の関係

日本の業務データで基準になるのは日本測地系2011（JGD2011）です。経緯度で持つ地理座標系はEPSG:6668、メートルで持つ平面直角座標系は第I系から第XIX系までの19系がEPSG:6669から6687に順に割り当てられています。前身のJGD2000は地理座標系が4612、平面直角座標系が2443から2461でした。

使い分けは単純です。全国をまたぐ保管は6668、面積や距離の計算と図面との突き合わせは対象地域の系。どの系かは都道府県単位でほぼ決まります。複数県にまたがる案件では、保管を6668に統一し、計算のときだけ県ごとの系へ投影する形が扱いやすい。

旧日本測地系のまま重ねると数百メートル単位でずれてしまう理由

2002年より前に作られたデータは旧日本測地系（EPSG:4301）で記録されています。基準となる楕円体と原点が違うため、同じ経緯度の値でも実際に指す場所が数百メートル動く。地図に重ねると建物が隣の街区に立ち、数値だけを見ても異常に見えない点が厄介です。

対処は運用側で決めます。受け入れ時に測地系を記録し、変換してから保存する。EPSGコードを取り込みの必須項目に置き、不明なデータは既知の基準点と重ねて確認が取れるまで取り込まない。これは地図固有の話ではなく、取り込み処理の設計そのものです。前処理の組み方はETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説の考え方がそのまま当てはまります。

距離や面積の計算は投影してから、Webメルカトルで生じる歪み

緯度経度のまま二点間の距離を引き算で求めると誤差が出ます。日本付近では経度1度と緯度1度の実距離が違うためです。PostGISならgeography型を使うか、ST_Transformで平面直角座標系へ投影してから測る。この一手間を省いた見積り機能が、後で数パーセントの狂いになります。

画面表示に使うWebメルカトル（EPSG:3857）にも注意が要ります。この座標系は緯度が高いほど面積と距離が引き伸ばされるため、表示用の座標で面積を計算すると実際より大きな値が出る。表示は3857、計算は平面直角、保管は6668という三段の使い分けにしておくと事故が起きません。表示側の座標の扱いはWeb GISとは？タイル配信とベクタタイル・ライブラリ選定を実装目線で解説で扱っています。

公開データの取り込みは、更新周期と出典表示の条件を先に確認する

行政界や道路といった下敷きは公開データから持ってきます。取り込む前の確認は、そのデータが何を含むかと、商用のシステムに載せてよいかの二点です。マーケティング分析で人口密度や都市規模を地域の属性として持たせる場合の統計上の定義と地域コードの扱いは、ジオグラフィックデータとは？人口密度・都市規模の統計定義と地域コードによる顧客データの結合で整理しています。

国土数値情報・基盤地図情報・地理院タイルの守備範囲はどう違うか

国土交通省の国土数値情報は、行政界・土地利用・公共施設・鉄道・避難施設などをテーマ別に配布しており、更新は年度単位が中心です。国土地理院の基盤地図情報は建物・道路・水域といった基図で、位置の下敷きに使う。地理院タイルは背景地図としてそのまま表示に載せる配信です。

選び分けは用途で決まります。主題として重ねるデータが要るなら国土数値情報、正確な位置の下敷きが要るなら基盤地図情報、背景が見えれば足りるなら地理院タイル。各機関のデータを横断して探す入口としてはG空間情報センターのカタログがあります。

出典の明示と加工の記載、商用のシステムへ載せるときの必須条件

国土数値情報の利用約款は商用利用を認めており、複製や公衆送信も行えます。条件は二つ。出典を「出典：国土交通省国土数値情報ダウンロードサイト」と当該ページのURLの形で記載すること、そして編集や加工をした場合はその旨を併せて記載し、国が作成したかのような態様で公表しないことです。

画面のどこに出典を出すかは設計時に決めます。年度更新のデータは取り込みのたびに世代を分けて保持し、画面上で「いつ時点のデータか」を出せるようにしておくと問い合わせ対応が楽になる。自治体が庁内で共用する構成については統合型GISとは？個別GIS・公開型GISとの違いと自治体の調達判断を参照してください。

住所から座標を得るジオコーディングは、住所の正規化で精度が決まる

業務データの多くには座標がなく、住所しかありません。地図に載せるにはこの文字列を座標へ変換します。精度が一律にならないため、変換の成否を二値で扱うと後で困る箇所です。

ABRジオコーダーで住所を正規化し、町字IDと緯度経度を得る

デジタル庁のアドレス・ベース・レジストリ（ABR）とABRジオコーダーは、入力した住所文字列をレジストリと突き合わせ、正規化された住所・町字ID・緯度経度を返します。提供形態はCLI・API・Webクライアントの三つ。v2.1（2024年11月）で京都の通り名、2024年7月公開のV2で地番マスターを使った変換に対応しました。

自前の環境で回せる点が実務では効きます。SaaSの地図APIが持つ住所変換は、結果を自社データベースへ保存できるかどうかが規約で制限される場合があり、台帳に緯度経度の列を持たせる要件だと引っかかることがある。マネージド側の機能と料金はAmazon Location Serviceとは？機能・料金・Google Mapsとの違いで比較しています。

表記ゆれと丁目・地番の書き分けで変換できない住所への現実的な対処

変換できない住所は必ず残ります。ビル名や部屋番号の混在、旧町名、全角と半角の混在、「一丁目」と「1-」の書き分け、番地の枝番。これらを完全一致だけで処理すると、実データでは何割も落ちます。段階的に丸める設計にしてください。完全一致、丁目まで、町字まで、と順に緩め、どの段階で当たったかを精度レベルとして列に持たせます。

精度レベルを持たせておくと後段の処理を分岐できます。建物単位の判断には完全一致だけを使い、エリア別の集計には町字レベルまで含める、といった書き分けです。座標がどう測られるかという入力側の話はLBSとは？GPS・Wi-Fi測位の仕組みと位置情報サービスの事例にまとめています。

空間インデックスの設計次第で、件数が増えても検索が止まらない

空間検索は普通の等値検索と効き方が違うため、索引の作り方とクエリの書き方を最初に固めておくほうが安全です。

GiSTインデックスと境界矩形による二段階の絞り込みの仕組み

PostGISはPostgreSQLの拡張として動きます。2026年8月22日時点の正式版は3.6.4（2026年6月8日）で、3.7系は3.7.0beta2（8月10日）とベータ段階です。空間検索の土台になるのはGiSTインデックスで、図形そのものではなく図形に外接する矩形を木構造に並べて持ちます。

検索は二段階で進みます。まず矩形同士の重なりで候補を絞り、残った候補にだけ厳密な判定をかける。SQL上では重なり演算子が一段目、ST_Intersectsなどの関数が二段目です。索引を作らないと全件に厳密判定が走り、数万件を超えたあたりから体感で遅くなる。索引の種類ごとの得意分野はPostgreSQLにおけるGINインデックスとは何か？その特徴と基本概要および役割も参考になります。

ST_Transformを条件に書くと索引が効かなくなる書き方

よく起きるのは、列の側を変換してしまう書き方です。検索条件のなかで格納列にST_Transformをかけると、行ごとに計算が発生して索引が使われません。寄せるのは検索側の値のほうです。

CREATE INDEX idx_facilities_geom
  ON facilities USING GIST (geom);

SELECT id, name FROM facilities
WHERE geom && ST_Transform(:bbox_3857, 6668);

同じ理由で、距離の判定をST_Distanceの比較で書くのも避けます。ST_DWithinを使えば内部で索引の効く形に展開される。書いたクエリで索引が使われているかはEXPLAINで確かめる習慣にしておくと、件数が増えてから慌てずに済みます。

件数が増えたときのデータの分割と、事前集計で逃がす設計の順序

索引だけで足りなくなったら、次はデータの分割です。時系列の属性を持つならパーティション、全国規模なら地域単位。それでも広域表示が重いなら、ズームアウト時に全点を返さず、グリッド単位で集計した結果を別テーブルへ持たせます。

手を付ける順序は守ってください。索引、クエリの書き方、分割、事前集計の順です。逆から始めると、まだ要らない仕組みを作り込んだうえに元の遅さが残ります。

自社システムへ取り込むか、GIS製品に持たせるかを分ける条件

最後に、ここまでの設計を自社で抱えるかを決めます。空間データをデータベースへ入れる判断は、地図の見栄えではなくどのデータが主役かで決まります。

自社のデータ基盤へ空間データを取り込む判断が成立する三つの条件

次の三つがそろうなら、PostGISを自社側に置いて取り込む構成が見合います。ひとつ、顧客や設備や案件といった基幹データが主役で、地図はその表示手段であること。ふたつ、更新が日次以上で発生すること。みっつ、閲覧と編集の権限を業務システムと同じ体系で管理すること。

この構成では、空間データも業務データと同じ基盤に載せて運用します。取り込み・品質チェック・世代管理を一本の流れで組む設計になるため、データ分析基盤構築・MLOps構築支援のように基盤側から入る進め方が実装の順序と噛み合います。

GIS製品に任せてファイルの受け渡しに留めるべき場面の見分け

逆の条件も明確です。地図そのものが成果物で、更新が月次以下、扱う人が数名に収まるなら既存のGIS製品で足ります。この規模でデータベースを立てても運用の手間が増えるだけです。製品の価格帯と選定軸はGISソフトの比較｜無料・商用・クラウドの選定軸と受託開発への切替点に整理しました。

判断が割れるのは中間です。更新は週次、利用者は十数名、地図と基幹データが半々というケース。ここは製品でファイルを作り、基幹側には集計結果だけを持たせる折衷から始め、往復が破綻した時点で取り込みへ切り替えます。

取り込みで失敗する典型は、座標系が不明のまま蓄積を続ける運用

実際に手戻りが大きいのは、座標系を記録しないまま取り込みを続け、後から測地系の違うデータが混在していると判明する事例です。混ざると、どの行がどの基準で入ったのかを事後に判別する手段がほぼなく、全件の再取り込みになります。

防ぐ手立ては地味です。取り込み口でEPSGコードを必須項目にし、不明なら受け付けない。加えて取り込み日・出典・加工内容をメタデータとして同じテーブルに残す。この二つを最初に決めておけば、数年後にデータの素性を説明できる状態が保てます。

よくある質問

GISデータはどこから無料で入手できますか？

国土交通省の国土数値情報、国土地理院の基盤地図情報と地理院タイル、各機関のデータを横断して探せるG空間情報センターが主な入手先です。自治体が独自に公開しているオープンデータもあります。いずれも利用条件が個別に定められているため、約款の確認を先に行ってください。

ShapefileとGeoJSONはどちらで受け渡すべきですか？

相手が行政や既存のGIS製品ならShapefile、Webシステム間ならGeoJSONが通りやすい形です。GeoJSONは座標系がWGS84に固定されるため、平面直角座標系の値をそのまま渡すと位置が飛びます。社内で持ち回るだけならGeoPackageが安全でしょう。

座標系が分からないデータはどう扱えばよいですか？

そのまま取り込まないのが原則です。Shapefileなら.prjファイル、GeoPackageならメタデータの表に座標系の定義が入っています。記載がない場合は、既知の地点と重ねて旧日本測地系とJGD2011のどちらで矛盾がないかを確認してから決めます。

住所しかない台帳を地図に載せる手順は何ですか？

住所文字列の正規化、座標への変換、精度レベルの記録という三段で組みます。デジタル庁のABRジオコーダーを使えば、正規化された住所と町字IDと緯度経度を得られます。変換できなかった行を目視で直す工程を、初回だけは見込んでおいてください。

公開データを商用のシステムに組み込んでよいですか？

国土数値情報は約款で商用利用を認めており、出典の記載と、加工した場合はその旨の記載が条件です。国が作成したかのような見せ方は禁じられています。他機関のデータは条件が異なるため、データセットごとに確認する運用にしてください。

関連記事

• GISとは？地理情報システムの仕組み・種類と業務システムへの組み込み判断：地図機能を載せるかどうかの判断ハブ。
• Web GISとは？タイル配信とベクタタイル・ライブラリ選定を実装目線で解説：データを画面へ配る側の設計。
• GISソフトの比較｜無料・商用・クラウドの選定軸と受託開発への切替点：製品の価格帯と選定軸。
• 統合型GISとは？個別GIS・公開型GISとの違いと自治体の調達判断：庁内共用データの整備と調達。
• Amazon Location Serviceとは？機能・料金・Google Mapsとの違い：マネージドの地図機能と課金。
• LBSとは？GPS・Wi-Fi測位の仕組みと位置情報サービスの事例：座標が測られる入力側の仕組み。
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：取り込み処理の組み立て方。
• PostgreSQLにおけるGINインデックスとは何か？その特徴と基本概要および役割：索引の種類ごとの得意分野。