foujitatsuの日記

QGISを操作する画面と作成した地図の画像を載せるブログ

基本項目「建築物」の「type」によって塗り分けた基盤地図をつくる

このページで新出のキーワードはない。普通建物 普通無壁舎 堅ろう建物 堅ろう無壁舎のような「建築物(建物)」についての用語は、別ページで詳述している。

 

 

基本項目「建築物」の「type」によって塗り分けた基盤地図をつくる

 

はじめに

 レイヤパネルでレイヤプロパティを見てみると、属性テーブルのある属性の値によって、ポリゴンを塗り分けることができそうだ。これができて、やっとほかの比較対象としたGISソフトウェアと、変わらない地図表示ができたことになる。この塗り分け表示設定の前段として、ベクタレイヤの結合を試してみる。これは複数のBldAレイヤに対する設定で作業を煩雑にしないためのものだが、代わりに、属性テーブルのレコード数が4倍になって、この内容をさがすためにかかる時間は増す可能性もある。

 

1.下準備としてのベクタレイヤの結合

(1)結合するベクタレイヤについて

 2次メッシュ番号「533945」の BldA Polygon の4つのボリュームを詳述しておこう。

  • 0001 BldA Polygon:地物 92310個
  • 0002 BldA Polygon:地物 101756個
  • 0003 BldA Polygon:地物 104258個
  • 0004 BldA Polygon:地物 90866個

 続いて、各BldA Polygon共通の属性テーブルの列名や、その値について記しておく。

  • gml_id:GMLは、JPGIS形式のXMLファイル、そのID
  • fid:Fは、たぶんフィールドだろう
  • ifSpanFr:「Fr」はFromだろうか、値はすべて共通で「2018-10-01」
  • ifSpanTo:(値なし)
  • devDate:値は「ifSpanFr」の翌日で、すべて「2018-10-02」
  • orgGILvl:値は「2500」と「1000」が見える
  • orgMDId:(値なし)
  • vis:  (値なし)
  • type:普通建物 普通無壁舎 堅ろう建物 堅ろう無壁舎 の4種類がある
  • name: (値なし)

 この4つのベクタレイヤを結合してひとつにすると、レコード数は40万となる。結合にはどれぐらいの時間がかかるものだろうか。結合されて1つになった40万レコードのベクタレイヤは、どのような速度で表示ができるものか。

 

(2)ベクタレイヤの結合手順

 難しい手順はないが、本サイトにて初めて行うことなので手順を記しておく。

①ベクタ(O)メニュー「データマネジメントツール(D)」►ベクタレイヤの結合

レイヤパネルにある複数のベクタレイヤから結合するレイヤを選ぶ画面が表示される

ベクタレイヤの結合

②結合するレイヤの選択画面を開く

レイヤパネルにある複数のベクタレイヤから結合するレイヤを選ぶ画面が表示される

ベクタレイヤの結合「結合するレイヤ」

③レイヤパネルにある複数のベクタレイヤから結合するレイヤを選ぶ

2個以上の2次メッシュを1つのプロジェクトで扱うようにQGISはなっていない

結合するベクタレイヤの「複数選択」

 この画面を見て思うことは、QGISが、2個以上の基盤地図の2次メッシュを、1つのプロジェクトで扱うようになっていないのではないかということだ。ソートできないことがつらい。「選択を切り替える」ボタンで、チェックのON/OFFを反転させることができる。

④結合したベクタレイヤをどのように保存するかの選択

「CreateTemporaryLayer」「ファイルへの保存」「式の使用」「Spatialiteテーブルへの保存」

ベクタレイヤの結合「結合したレイヤの保存」

 結合したベクタレイヤをどうするかは、次の4つから選べる。何を選べばQGISによる表示は早いのか。「CreateTemporaryLayer」「ファイルへの保存」「式の使用」「Spatialiteテーブルへの保存」

 SpatiaLiteとは、地図とかの空間情報をSQLiteに格納する拡張であるはずなので、SQLiteは速い(速かった)はずだという浅い知識で「Spatialiteテーブルへの保存」を選んでみる。QGISのインストールにて、SQLite(のようなもの)が、併せてインストールされているのだろう。
 テンポラリーにしろ、ファイルで保存すれば処理速度がはやくないことは想像がつく。

 

(初回の試行)⑤検討して設定した結果「Run(実行)」のまえ

「spatialite:dbname='C:/sqliteGis/533945BldA.sqlite' table="output" (the_geom) sql=」

4つのベクタレイヤを結合してSpatiaLiteで保存する

 これで実行してみる。保存先のメモ「spatialite:dbname='C:/sqliteGis/533945BldA.sqlite' table="output" (the_geom) sql=」

 結合したベクタレイヤの保存をどうするかは『QGIS入門【第2版】』にアドバイスを期待したが、見つけられなかった。

ソフトウェア関係のGIS利用者向けリンク(新しくはない)

qiita.com

シンプルなINSERT(挿入)とSELECT(検索)の比較(2012年と古い記事)

d.hatena.ne.jp

 SQLiteは、データベースとして.sqliteSQLITEファイル)を書き込むため、この処理時間が短いことはなさそうだとわかった。処理対象の BldA Polygon の XML ファイルは、100MB程度のファイルが4つ分である。400MBよりは小さなSQLITEファイルができあがるだろう。

 処理の実行は、20分たって12%と表示されていた。実行してから間もなく2時間というところで、QGIS上の実行済み割合は50%となっている。 この処理は結局(生成されたSQLITEファイルをみた限り)6時間ほどもかかった。ファイルサイズは116MBとなり、大量のXMLの集合だったGMLのときから大幅に改善された。

 このBldAポリゴンのSpatiaLiteは、困ったことに名前を付けて保存するとQGISでエラーが発生する。そこでシェープファイルとして保存することにした。こうなるならば、「④結合したベクタレイヤをどのように保存するかの選択」にて、ファイルへの保存を選んで、ダイレクトにシェープファイルとして保存すればよかったのかもしれない。

 ところが、このSpatiaLiteとシェープファイルには明確な表示速度のちがいがあった。SpatiaLiteのほうが表示は速い。シェープファイルGMLと同様にパラパラと表示が進む。これに対して、SpatiaLiteはドン、ドン、で表示が完了する印象だ。

 

 処理にかかる時間を想像すると、すぐには実行を試せないが、⑥を試してみたい。

(今後、試行)⑥大容量のGMLを「ベクタレイヤの結合」でシェープファイルに保存する

 

 QGISGMLをベクタレイヤ として追加する以外の選択肢として、先に基盤地図情報ビューアを用いてシェープファイルへ変換してしまう方法があった。そのリンクを紹介する。(まだ試せていない)

3.3 基盤地図情報ビューアを用いたshp変換

gis.saloon.jp

 

 

(3)大容量のGMLを結合して処理速度・表示速度はどうなったか

 SpatiaLiteの表示速度には、すでに言及してしまった。これは速い。その他の処理についてはどうか。ひとつずつ確認していくが、いまのところ問題はない。プロパティの設定など快適な処理速度で利用できている。

 大容量のGMLは、QGISで表示させることが向いていないファイルであったようだ。大容量のGMLファイルが複数個あって、表示のたびにファイルの内容を読み込んでいるのだろう。SpatiaLiteからプロパティの「名前を付けて保存」で生成したシェープファイルにて、次節ではBldAポリゴンの「type」による塗り分けを試してみる。

 

 

2.建物の「type」4種類によるポリゴンの塗り分け

 手順を試行錯誤していくことになるが、次のような想定だ。QGISにて塗り分けを「シンボル」と表記していることを先に説明しておく。

 

(1)スタイル設定「分類されたシンボル」によるポリゴンの塗り分け手順

  1. BldAポリゴンの「0001」から「0004」を結合したレイヤにて右クリックでプロパティを選び「スタイル」を表示
  2. 【単一シンボル】▼をクリックして「分類された」を選ぶ
  3. カラム【   】▼をクリックして「type」を選ぶ
  4. 【分類】ボタンを押すと「type」の4種類が表示される
  5. 各「type」のシンボルのカラー設定を適宜変更する

①2次メッシュ「533945」BldA「0001」から「0004」を結合したレイヤのプロパティ

「結合された」と初期設定のレイヤ名が付けられているのがSpatiaLiteファイル

SpatiaLiteから保存したシェープファイルにてプロパティを表示する

 レイヤパネルにて「結合された」と初期設定によるレイヤ名で表示されているのがSpatiaLiteファイルである。

②「単一シンボル」から「分類されたシンボル」への設定変更

プルダウンの上から シンボルなし 単一シンボル 分類された 段階に分けられた ルールに基づいた 反転したポリゴン 2.5D とあって、上から3番目の「分類された」を選ぶ。

レイヤのスタイル設定のなかのシンボル設定の変更

 プルダウンリストの上から シンボルなし 単一シンボル 分類された 段階に分けられた ルールに基づいた 反転したポリゴン 2.5D とあって、上から3番目の「分類された」を選ぶ。

③カラムにて「type」を選ぶ

プルダウンに表示されるのはBldA Polygonの各列の種類

分類に使用するカラムを選ぶ

④【分類】ボタンを押して「type」の4種類を表示する

堅ろう建物 堅ろう無壁舎 普通建物 普通無壁舎の4種類が表示される

【分類】を押すとQGISの属性テーブル参照により選んだカラムの分類項目が示される

 初期設定では「ランダムカラー」によって各分類の色が決まるため、この後で「新しいカラーランプ」を作成する。色は地図太郎の塗り分けを参考にしてみたい。

 

⑤新しいカラーランプの設定(「type」ごとのシンボルの色を設定する) 

「ランダムカラー」以外に用意されたカラーランプから選ぶことも可能

新しいカラーランプを作成する

 ここでは、新しいカラーランプを作成するが、「ランダムカラー」以外に用意されたカラーランプの中から選ぶことも可能だ。新しいカラーランプの作成をやろうとしてみたところ、基本は2色によるグラデーションのため、地図太郎の塗り分けのようなイメージは難しいということがわかった。

 「type」によってベクタレイヤを分割することができるのであれば、そうしてしまって単色でスタイルを変更したほうが簡単かもしれない。

 いったん新しいカラーランプを諦めて「Oranges」というシンボルの色階調を選び、普通建物(すなわち、3階未満の建物及び3階以上の木造等で建築された建物)が、堅ろう建物(鉄筋コンクリート等で建築された建物)よりも目立つ地図としてみた。

縮尺1000分の1にて「type」により塗り分けた地図(QGIS 2.18.18)

 

(2)塗り分けた地図は何かの役に立ちそうか

 前のページにてテーマとした住宅密集地の不燃化について考えながら、「建築物(建物)」を「type」で塗り分けた地図の有用性について考えてみたい。始めに地図太郎の塗り分けをふり返ってみる。

 地図太郎では、堅ろう建物:オレンジ、普通建物:グレー、普通無壁舎:みどり、という配色になっていた。この配色であると、地図から受ける印象は、「堅ろう建物」がどれだけ多くあるかを示す印象となる。

 これに対してQGISでは、堅ろう建物:ペールオレンジ、普通建物:オレンジ、普通無壁舎:赤、という配色にしてある。ここからさらに、2つのBldAレイヤを重ねることで「普通建物」のオレンジを目立たせたのが次の地図になる。

大きな通り沿いには普通建物が少なく、グレーにした堅ろう建物が多い様子がわかる。

縮尺2500分の1にて普通建物をオレンジに塗り区分けた地図(QGIS 2.18.18)

 この地図を見ると、大きな通り沿いには普通建物が少なく、グレーにした堅ろう建物が通り沿いに多い様子がわかる。普通建物は、通りから奥まったエリアに密集している。GISで参照しているデジタル地図以前のマップでは、建物の塗り分けはどうなっていたのだろうか。塗り分けがされていた記憶はある。

太目の囲いに斜線で表されているのが堅ろう建物であって、普通建物と描き分けられていた。

縮尺2500の1にて同じ地域の標準地図をみる(標準地図はWMTSで取得)

 標準地図をみると、色の多さと住所表記や学校名が気になるが、太目の囲いに斜線で表されているのが堅ろう建物であって、普通建物と描き分けられていた。このように見比べると、データをみるためのテーマのちがいによって、データのみせ方で地図の印象はちがってくる。

 

 

3.基本項目「建築物」に注目した基盤地図の課題

 「建築物(建物)」に注目して基盤地図をみた場合の一番の課題は、利用するのに適した縮尺が制限されていることだろう。縮尺が大きくなれば、その地域の建物のことはよくわかるが、ほかの地域や市区町村全体の状況と比較することからは遠ざかる。やはり、数量化することが必要になるだろう。

 ページを何回かに分割して、基本項目による基盤地図の利用を試行してきた。今後のために、現在の課題をまとめておこう。

 

(1)基盤地図情報の加工と表示
 基盤地図情報ダウンロードサービスから取得したGMLQGISへ取り込むことで追加したベクタレイヤは、結合してストレスのない表示速度でQGISが描画できるようにする。このときに用いる工夫は、GMLのベクタレイヤを結合してSpatiaLiteへ加工することや、そこからシェープファイルを生成することだ。このような工夫は、何が正解なのか、まだわからない部分がたくさんあり、今後も試行が続いていくだろうと考えている。

 ヒントとなる記述をArcGISの解説ページから見つけた。(引用)「基盤地図情報ArcGIS で利用するための手段:[基盤地図情報GML)のインポート] ツールでジオデータベースに変換する」

www.esrij.com

 GMLは、ArcGISで利用する前に、ジオデータベースへ変換してからArcGISへインポートするのだということが記されている。ジオデータベースとは、ESRI社によって、シェープファイルよりもArcGISの機能を引き出せるデータ形式だという説明がされている。基盤地図情報から取得できるような大容量のGMLは、データベースへ格納してから利用するのが現実的な解決策なのかもしれない。

www.esrij.com

www.pasco.co.jp

 

(2)行政区域単位への地図基盤情報の加工

 行政区分単位の基盤地図をどのように扱って、テーマが抽出できる検討材料に仕立てていくか。この問いは、ひとつの2次メッシュから得た基盤地図情報でも表示・検討することが困難なほどの、描画の遅さによる表示速度へのストレスがあったことによる。

 東京23区のある区全体を検討しようとすると、自治体範囲の2次メッシュが半分に分割されている場合などがある。このような場合には、行政区分範囲のGMLを結合する必要が生じる。こういうボリュームの作業になってくると、R(アール)言語によって、コマンドラインからQGISを操作することのメリットがわかってくる。

 

 

おわりに

 ベクタレイヤの結合にて、6時間もかかってSpatiaLiteへ保存してみたことには価値があった。地図基盤情報をGMLのままで利用するにとどめないことは、専門家に近いGIS利用者からしたら当たり前のことなのだろう。GMLシェープファイルへ変換したたけでは、QGISでの表示速度が厳しいと感じるが、とりいそぎ、この変換方法をWindows用とMac用の2つのリンクにて示す。筆者はWindowsユーザーのためMacはおまけ。

Windowsの場合)

各種資料|基盤地図情報ダウンロードサービスhttps://fgd.gsi.go.jp/download/documents.html

 

表示ソフトウェア
基盤地図情報ビューア  ZIP形式:6.85MB 2018/07/26 更新

基本項目と数値標高モデルの表示ソフトウェア
Shape形式、拡張DM形式等へのエクスポートも可能です
※簡易的な表示ソフトウェアのため、大量のデータの表示・エクスポートはできません。
※操作がうまくいかない場合は、データを分割して処理してください

基盤地図情報ビューア操作説明書  PDF形式:1.68MB 2018/07/26 更新

 

Macの場合)

 東京大学大学院新領域創成科学研究科 佐藤 弘泰先生の研究室ブログの記事より

Mac環境でgmlをshpに変換 — 東京大学 味埜・佐藤研究室http://www.mwm.k.u-tokyo.ac.jp:8080/Plone/introduction/satoh-folder/8af86d3b52d5/mac74b05883gml3092shp306b590963db

 

 属性テーブルのある列にどれだけのパターンの属性がふくまれているのか、プロパティのスタイルで「分類された」シンボルによる塗り分けをする過程でQGISGUIによって明示してくれた。データベースをSQLで操作すれば当然できることだが、それが作業プロセスのなかで示されることはとても便利だ。

 本件では、BldA Polygonという1種類の基本項目に注目して進んできた。これからは、同様の注目を基本項目にある整備項目ひとつずつに対して行い、基盤地図情報への理解を深める必要性が感じられる。