【解説編】GISで扱うデータのファイルフォーマット（シェープファイル）
I. シェープファイルとは
シェープファイルは、世界中で最も流通しているベクトルデータのファイルフォーマットです。国内外を問わず、様々なGISデータがシェープファイル形式でウェブ上に公開されています。GIS界における実質的なデファクトスタンダードとなっており、現状、GISを活用するうえでは避けて通ることのできないファイル形式です。
GISデータフォーマット界の頂点に立つシェープファイルですが、実は多くの問題を抱えています。シェープファイルの仕様は、アメリカのESRI社によって1980年代に提唱されました（※1）。そして、今日までほとんどその仕様を変更していません。そのため、現代のGISやビッグデータ時代の分析環境では時代遅れとなりつつあり、不便な点も多く出てきています。
このnoteでは、シェープファイルの基本的なことを示すとともに、シェープファイルが抱える問題点について紹介したいと思います。
※1 シェープファイルの技術仕様は、ESRIのウェブサイトで公開されています（LINK）。地図作成や分析目的でGISを利用する分には、シェープファイルの細かな技術仕様まで理解する必要はありませんが、GISの開発エンジニアやプログラマーは技術仕様を参照する機会があるかもしれません。
II. シェープファイルの構成
シェープファイルは、同じファイル名が付けられた複数のファイルを1組として構成されます。下図は、シェープファイルをWindowsのエクスプローラーで見たものです。フォルダの中には12個のファイルがありますが、シェープファイルとしては赤枠で囲んだ2つだけです。
シェープファイルを構成する各ファイルには、それぞれ役割が割り当てられています。主なものを下の表にまとめました。
この中で重要なものは上位4つです。
そのうち、「.shp」、「.dbf」、「.shx」は、シェープファイルを構成するために必須のものとなっています。
.shpファイルは道路のラインや建物の形状といった、フィーチャの幾何情報を格納するファイルです。シェープファイルのメインといえるものになります。
.dbfファイルはフィーチャの属性情報を扱います（※2）。QGISで属性テーブルを開いた時に表示される情報がこれになります。
.shxファイルはshpとdbfの対応付けを行っているファイルです。このファイルのおかげで、複数に分かれたファイルが1つのシェープファイルにまとまっているとも言えます。
.prjファイルは座標系情報を格納したファイルです。拡張子は「projection」の略ですね。prjファイルは欠けていても、上記3つのファイルだけでシェープファイルとしては成立します。しかし、座標系情報がなければ正しい場所に地図を描画できないので、実質的にはほぼ必須のファイルと言えます（※3）。しかし、公共機関が公開するシェープファイルであっても、prjファイルの付いていないものが少なくありません。prjファイルが無い場合、GISソフトが持つ「投影法を定義」機能を利用して描画に用いる座標系を指定できます。
その他のオプションファイルは、各GISソフトが処理効率を上げるために付加したファイルフォーマットです。使用するGISソフトによって独自に付加されるものもあり、例えば表中の「.sbn」や「.sbx」はArcGISでシェープファイルを出力した時に保存されます。表に示した以外にも、幾つかのオプションファイルがあります。
※2 「.dbf（ディービーエフ）」は dBASE IV というデータベース形式のファイルです。これはMS Excel等の表計算ソフトでも開くことができます。GIS上では属性データの編集作業が非常に不便です。そのため、以前はdbfファイルをExcelで開いて編集する荒業が使われていました（shpファイルとの対応関係が崩れる可能性があるので非推奨です）。しかし、最新のExcelではdbfファイルを開くことはできてもdbf形式で保存できないので、この荒業は使えなくなりました。しかし、探せばdbfファイルを扱えるようにするExcelアドインを見つけることができますし、MS AccessやLibreOfficeなどの表計算ソフトやDBソフトではdbf形式の読み書きが可能です。今でもこのような荒業は横行しているのでしょうか。
※3 厳密にいえば、prjファイルはESRIのソフトウェアが対応する座標参照系についてサポートします。よって、ArcGISで使えるがQGISでは使えないような座標系を定義していた場合、prjファイルがあってもQGISでは正しく描画できません。逆に、QGISでは使えるがESRIがサポートしていない座標参照系の場合、prjファイルに座標系の定義を保存できません。この場合、qpjファイルが保存されます。しかし、qpjファイルを他のGISソフトウェアが認識できるかどうかは微妙なところです。
III. シェープファイルの読み込み
シェープファイルは複数のファイルから構成されますが、GISソフトに読み込む場合はshpファイルだけ指定すれば、ソフトウェアの方でシェープファイル全体を読み込んでくれます。QGISではダイアログから追加するほかに、shpファイルをドラッグ&ドロップすることでも読み込むことができます。
R や Python などでシェープファイルを扱う場合も、普通はshpファイルを読み込みファイルに指定します。例えばRの場合、次のようなコードによってシェープファイルを読み込みます（sfパッケージの使用を想定）。
library(sf)
shp <- st_read("point.shp", option="ENCODING=CP932", stringsAsFactors=FALSE)また最近のQGISでは、zip圧縮されたままのシェープファイルも読み込めるようになっています（※4）。ただし、それが可能なのはシェープファイルが直接zip圧縮されている場合のみです（下図の左）。右のようにzipの中にフォルダがあり、その中にシェープファイルが入っているような構成だと、正しく読み込むことができません（※5）。
※4 シャープファイルの圧縮ファイルであることを示すため「.shz」や「.shp.zip」などの拡張子が使われることもあります。
※5 これも、公開する機関やデータ項目によって、どちらの構成も見られます。
上述のように、シェープファイルは同名からなる複数のファイルで構成され、同じディレクトリ内にあることでひとまとまりだと認識されます。逆に言えば、ファイルの一部のみをリネームしたり、別のフォルダに移動させたりすると、そのファイルはシェープファイルとして認識されません。特に「.shp」、「.dbf」、「.shx」のいずれかが欠損すると、GISソフトはシェープファイルとして認識できなくなります（※6）。
下図では、pointシェープファイルのshxファイルの名前を「polygon」に変更してみました。その状態でQGISで開こうとすると、無効なデータソースと警告され読み込むことができません。ファイル名を「point」に戻せば、読み込めるようになります。シェープファイルをリネームする場合は、構成するファイル全ての名前を変更しなければなりません。
※6 QGISの場合、dbfファイルは欠損していてもシェープファイルをマップビュー上に描画できます。ただし、属性情報は読み込めていないため、レイヤの属性テーブルを開いても何も表示されません。
IV. シェープファイルの問題点
シェープファイルは現在最も普及しているGISファイルですが、その使い勝手はお世辞にも良いものとはいえません。上で見たように、ファイル管理が面倒なのも扱いにくい理由の1つになりますが、その他にも次のような問題点があります。
1. ファイル管理が面倒
2. シェープファイルを構成する各ファイルのファイルサイズは2GBが上限
3. フィールド名には10バイト（日本語5文字）しか使えない
4. 異なるジオメトリは1つのファイルに共存できない
--- --- --- --- --- --- --- ---
1. ファイル管理が面倒
II.やIII.で見たように、シェープファイルは複数のファイルで構成されるため、ファイル管理が面倒という問題があります。shp、dbf、shxのどれかが欠けたり名前が変わったりすると、シェープファイルとして機能しなくなるのは非常に脆弱です。このような仕様を知らないと、GIS活用の前段階であるシェープファイルのコピーや移動といった事務的作業すら困難になります。
また逆に、prjファイルについては無くなってもシェープファイルとして成立してしまう点が問題です。このことは、不完全なシェープファイルが流通することを意味し、実際、様々なところでprjファイルの無いシェープファイルが公開されています。
prjファイルが無いとデータを正しい位置に表示させることができませんが、表示位置が正しいことを判断できるかどうかは利用者次第です（※7）。座標系を再定義するにしても、座標系に関する外部情報が無ければ、勘や手探りで正しい座標系を探すほかありません。
※7 prjファイルの無いシェープファイルを開くと、「座標系の定義が無い」とエラーが示されることが多いです。しかし、常にエラーが出るとは限りませんし、そのエラーに気付けるかどうかという問題もあります。また、※3で言及したように、prjファイルが存在しても座標系を正しく認識できない場合はあります。シェープファイルが正式に座標参照系の定義ファイルを持たないことによる欠点がここに表出しています。
--- --- --- --- --- --- --- ---
2. シェープファイルを構成する各ファイルのファイルサイズは2GBが上限
データの大規模化や詳細化が進行するにつれ、ファイルサイズの上限が2GBという制約は大きな問題になりつつあります。特にこの制約に引っ掛かりやすいのがDBFファイルです。例えば、フィーチャ数が多くなりがちであるメッシュデータ、特に100mメッシュなどでは、属性項目を幾つか追加するだけですぐに2GBに達してしまいます。
GISソフトウェアにおいては、扱うファイルのサイズが大きくなると動作が重くなったり不安定になりやすいというソフトウェア側の理由によって大容量データを避ける傾向があり、結果として2GB以下の制約内で問題なく作業できている場合も多いかもしれません。しかし、シェープファイルを利用している限り、いつか2GBの壁にあたるときが来るでしょう。
--- --- --- --- --- --- --- ---
3. フィールド名には10バイト（日本語5文字）しか使えない
シェープファイルでは、フィールド名には10バイトまでしか利用できません。これは、半角英数字で10文字、全角の日本語では5文字しか使えないということです（※8）。フィールド名にはそのフィールドを説明するワードを付けることが多いと思いますが、たった5文字でそれを表現しなければならないのはとても不便ですね。
下図の上段は、シェープファイルに国勢調査のデータをテーブル結合したものです（Source：地図で見る統計）。「S_NAME」フィールドより右が、結合されたフィールドです。この段階ではまだ結合結果をシェープファイルに保存していないので、フィールド名に日本語が5文字以上入っています。
そして、テーブル結合した状態でシェープファイルにエクスポートしたものが下段になります。シェープファイルとして保存されたことにより、フィールド名が10バイトまでに問答無用で削られてしまいました。
※8 正確には文字コードがShift-JISの場合。文字コードをUTF-8にすると、利用可能な日本語文字数は3文字になります。
このほか、属性情報の格納にdBASE形式を用いていることにより、属性テーブルの中身に対しても幾つかの制約があります。例えば、フィールド数（列数）は255個まで、1つのセルに格納できるテキストは半角英数字で最大254文字（日本語なら127文字）、日付型に時刻を格納できない（日時データとして有効なのはYYYYMMDDまで）、フィールドにNULL値の入力がサポートされていない（NULLが使えるかどうかはソフトウェア次第）など、細かな制限が幾つかあります。
--- --- --- --- --- --- --- ---
4. 異なるジオメトリは1つのファイルに共存できない
シェープファイルは、一つのファイルの中に異なるジオメトリを共存させることができません。ジオメトリとは、ポイント、ライン、ポリゴンといったベクトルデータが持つ幾何的な種類のことです。ポイントのシェープファイルにはポイントフィーチャのみ、ポリゴンのシェープファイルにはポリゴンフィーチャのみが格納されます。具体例でいえば、道路データ（ライン）と交差点データ（ポイント）は別々のシェープファイルになるといった具合です。
この仕様がもたらす不便は、各ジオメトリ間の関係性をモデル化したり分析に応用したりすることができないということです。関係性とは現実世界における地物の空間的なルールのことで、その代表的なものがトポロジです。トポロジの例として、建物代表点は街区ポリゴンに包含されていること、交差点は道路中心線上に存在すること、といったルールが考えられます。このルールが記述できないと、道路線上にない交差点といった意味の分からないデータの存在が許されてしまう可能性があります。
V. ポストシェープファイルはあるか？
シェープファイルは旧世代のデータフォーマットであり、現代のGISの発展や普及の足枷になりつつあります。それならば、シェープファイルに代わる新しいデータフォーマットはあるのでしょうか？
シェープファイルを生み出したESRI社は、シェープファイルに代わるフォーマットとしてジオデータベースファイルを提唱しています。ESRI社が販売する基盤地図データは、ジオデータベース形式で提供されています。ArcGIS環境で利用する分には申し分ないフォーマットですが、他のGISソフトや分析ツールが対応しているかどうかは微妙なところです。
QGISでは、GeoPackageが用意されており、QGISの標準フォーマットでもあります。QGISでは、シェープファイルではなく、このGeoPackageを使うことが推奨されています。GeoPackageも、ArcGISのジオデータベースと同じような位置付けで、QGIS内で利用する分には問題ないのですが、他のGIS環境との互換性の面ではシェープファイルに劣ります。
現在最も勢いのあるファイルフォーマットはGeoJSONだと思います。これは、JavaScript Object Notation （JSON） をベースに、地理空間情報を扱えるように拡張したフォーマットです。GeoJSONはWebマッピングでは主流となっており、主要なGISソフトウェアにおいても入出力に対応しています。現状、シェープファイルの代替の最有力候補と言えるでしょう。GISソフトだけでなく、多くのプログラム言語においても読み書きに対応したパッケージやライブラリが開発されている点が強みです。
GISデータを扱うフォーマットは他にも幾つかありますが、シェープファイルと対抗できそうなものは、上記の3つくらいでしょう（※9）。それぞれ、ArcGISやQGIS等の個々の環境で作業する分には、シェープファイルより優れた性能を有しています。しかし、複数の環境を横断する場合やデータの公開・頒布において、すなわち流通フォーマットとしてはまだまだシェープファイルに依存せざるを得ないでしょう。
これまで地理・地図データと称して公開されるデータの多くが、PDFや画像ファイル（位置情報のないTIFFやPNG）でした。それが近年ようやくGISに対する理解や認知が広まり、シェープファイルの公開へと変わりつつあります。そのような状況下で、シェープファイルの活用を否定するのはなかなか難しいものがあります。
また、2022年より高校で地理が必修化され、GIS教育も強化される予定ですが、そこで「シェープファイルはGISの標準フォーマットではあるが課題も多く抱えており次世代ファイルフォーマットに移行すべき」というところまで教えなければ、シェープファイルの存在感のみが益々強まってしまいます。果たして、そこまで教えられる教員はどのくらいいるのでしょうか。
シェープファイルが覇権を握る時代は、もうしばらく続きそうです。
※9 ベクトルタイルもGISデータのありかたを変えるものとして注目される技術です。ベクトルタイルはデータの配信技術であり、GISデータそのものを配布するものではないため、シェープファイルの直接的な代替とは異なると考え、本文からは外しました。
記事の内容でもそれ以外でも、地理やGISに関して疑問な点があれば、可能な限りお答えしたいと思います。