玄天黄地

学生時代、箸にも棒にも掛からなかったアホの子が、やっと普通のアホになれるか？

ＰＦ

先日、Foss4G Advent Calendar の一環で、「PostGIS にウチの DB を入れてみる」という話を書きました。

PostGIS に入れただけで PF を名乗るのは若干おこがましいのですが、外部の PF 群（たとえば瀬戸さんが紹介しておられる記事のようなものとか）と緩やかに、しかし、確実に連携しようと思えば、ウチの DB が昭和末期の使いにくい形式のままではよろしくない訳です。ウチの DB は、道路網をネットワークとしてモデル化したものですが、それを厳密に言うならば、ネットワークが一次元複体として数学的に完全に記述できていて、それが計算機空間上に完全に実装できていることが必要になるでしょう。これができていれば、PF 上で地理空間情報処理を行う場合に、データ不備によるエラーが発生しないことを保証できるようになります。現行は、そのレベルに至っていませんが、実データの構造が Old Fashined であるために検証が困難となっていることから、そもそも「道路ネットワークが一次元複体として完全に記述できているか」とか「その一次元複体は計算機空間上に完全に実装できている形としてファイルに表現されているか」みたいなことが 100% までは保証されていない現状にあります。

道路ネットワークは意外に変化していくので、データの幾何学的正当性を保証するに当たって、位置精度や位相精度と並んで、時間精度を保証することも重要です。時間精度が要求されるならば、あまり凝ったことはできません（ B/C の観点で得策でない）が、その場合は位相精度を保証することが何よりも重要になると考えます。
実は、位置精度はあまり高いものを要求してもうまくいきません。工事図面は、相対位置は極めて高い精度で記述されていますが、絶対位置は必ずしも高くない場合があります。また、工事が完了して以降に累積している地殻変動は殆どの場合補正されていません。一方、地殻変動は局所的な相対位置を変えないので（厳密に言えば、地震が起きていない限り、局所的な相対位置の変化は通常計測の検出限界を大きく下回ります）、これは位相精度を保つことと非常に相性が良いことになります。結局、絶対位置は地理院地図と整合的であることが目安になると思っています。自動運転用の地図はもっと位置精度についても要求水準が高いかも知れませんが、個々の自動車から見てたかだか数百ｍの範囲内において相対位置が正確であれば良いのであって、運転中に自車の絶対位置を（毎秒20mとかで移動しているのに）数cm単位で気にしても意味がありません。むしろ、前車との車間距離がどうなのか、左のドアミラーは道路脇の電柱にぶつからないで済むのか、などの相対距離の方が遙かに重要です。

位相精度の方は、数学的に（実測することなく）完全に検証可能です。ただし、データ構造を完全に UML で記述でき、かつ、その通りに実装されていることが条件になります。この実装は、PostGISでならば相当レベル可能であろうと期待できます。なによりも、SQL で検証できる範囲において、データの検証を客観的かつ透明に実施できます。

IT の先端を走る人には、何を今更低レベルなことを言っているのだ、という感想を持つ人もいるでしょう。それでも、インフラ的なデータを（だから PF なのですね）現実的な価格で持続可能なサービスに持っていこうと思うならば、そしてそれを技術的に必ずしもハイレベルではない人材だけで回そうとするならば、この程度のことから始めるのが良い（このレベルでもハードルがそこそこ高い）と思うのでした。

PostGIS に初めて挑戦

これは FOSS4G Advent Calendar 2020 の記事です（2020-12-08 記述ですが、2020-12-17 以降に加筆修正します）。

QGIS は2011年から使っている私ですが、QGIS 以外の FOSS4G 関連ソフトウェアは使ったことがありませんでした。仕事場の後輩筋の中には、PostGIS も含めてヘビーユーザはもちろん居りますが、上級マネジャーだからという理由で自分は手を動かさずに来てしまいました。（要するにサボリですね）
 
さて数ヶ月前、今の仕事場周りの DX 対応を議論していた際に、仕事場で使うデータが相互に連携できていない点をどうするか、という問題が話題になったことがありました。データ単体は、最低限度の機械可読性は満足できているのですが、相互に関係するデータを組み合わせようとすると、突然ハードルが上がります。理由は簡単で、個々の DB を整備した人たちが、自己完結なデータしか作ってこなかったのです。当時（昭和末～平成中期まで）は、個別のプロジェクトで整備される DB に、関連する DB との整合性はあまり考慮されない空気があったのでしょう（その頃は私は別組織で働いていましたので、正確なところは分かりませんが）。令和の世になって、遅ればせながら関連データベースが簡単にマッシュアップできなければならないという認識が広がった時点で、そういうデータ整備をしてこなかったよね、という気づいた訳です。
 
今の仕事場関連のデータは、根拠法令があります。アナログ時代から厳然と存在している法令ですから、規程ぶりはデジタルに適しているとは限りません。ただ、「基礎となる地物があって、それに紐付く付属的な構造物が沢山ある」という体系は、アナログかデジタルかは関係ないと考えます。私の仕事場は、基礎となる地物の構造を表現する DB を管理していますので、根拠法令の考え方を IT 的に表現できればよいことになります。別に珍しい話ではなく、会計法の考え方を IT 的に表現できれば良い財務ソフトができる、というのと何も変わらないでしょう。
付属的な構造物は、他組織が整備する DB に格納されています。これまでは必ずしも連携が良くなかったのですが、「お互いに、根拠法令の考え方に忠実に IT 化しましょう」という申し合わせが成立すれば、DB 群は相互に整合するはずです。現在、ウチの組織では、自らが整備している DB を特定の顧客にガチガチにチューニングした様式で整備していますが、相互に整合する DB 群を使うべき相手はそれよりもずっと広いので、DB の構築方法も変更しなければなりません。

長々と抽象的な話を書いて参りましたが、このような経緯で、 PostGIS にウチの DB を入れてみることにしたのです。
 
ーーー
 
PostGIS に DB を投入する試みは、11月下旬に一旦成功したと部下から報告がありました。まあ、短期間で最低限度のデモが可能となるよう、最初の仕様は絞ったので、できて当たり前です（←技術力がないのに、偉そうなことを言う奴）。こういう試みの必要性を、関係業界に広く周知するために、これまでもプレゼンは書いてきたのですが、実際のデータとシステムを用意してプレゼンできなければならないので、自分のマシンにも PostGIS を入れてみることにしたのでした。サンプルデータを import するところまでは自力でやりましたが、本番環境（それなりに大量のデータ）を restore するところだけは部下の手を借りました。

第一段階として、年内に QGIS から PostGIS に格納された業務DB を読み出して、関係する他のデータと組み合わせて見える化する、というところまではなんとかできるようになりました。
第二段階は、仕事関係の組織（親会社的な組織）の高級指揮官にデモを見せて、仕事場の DX に使えることを示すことと、実際にベータテストを引き受けてくれる部署からできるだけ大量のフィードバックをもらう仕事が続く予定です。
 
ーーーー

DX を実行する部門（同時に DX の恩恵を受けるはずの部門）は、平時の仕事が IT から遠い部分が多いので、高い技術レベルを求めてもすぐにはうまくはいかないと思っています。こちらはバックヤードに PostGIS を使ったデータサービスを立ち上げることになりますが、ユーザには QGIS の使い方、QGIS から DB を直結させてネット越しに利用する際の方法などを説明することはできても、それ以上を求めるのは無理だと思っています。そういう意味では、PostGIS が稼働するデータサービスの部分と、実際の利用場面で用いられるアプリの部分とは、完全に分離できるようにシステムを設計しなければうまくいかないでしょう。関連 DB 群はデータサービスの側に属しますが、その DB を更新する人々はサービス側という認識を持つ必要はなく、部分最適な考え方として、目の前の DB に日々正しいデータを入れることに専念してもらうことになるはずです（まるで、レジ係の人が正しくレジ打ちをするかのように）。

DX で業務改善といっても、現場の隅々がいきなり IT に強くなるわけではないので、部分最適が全体最適と矛盾しないように、全体最適を適用する側の方で工夫する必要が出てきます。私のいる組織は強権的なことができないからこそ、こういう解になります。これが独裁的な組織ならば、有無を言わせず新しい（効率的な）システムに従わせれば済む話なのです。
 
ーーーー
 
少し大きなことを申しましたが、こういう「こっそり仕込んだ大きな話」に PostGIS のような Open Source Software が使用できるようになったことが、DX が成立する（少なくともトライできる）背景要因として大きいと思います。もしも、これを 2005 年に Oracle でやろうとしていたならば、「こんなに大金をつぎ込むんだから、現場も不退転の決意で新しいシステムに馴染め」とか、「現場が混乱しないで済むように、徹底的に業務プロセスの改善方法を示せ」とか、「業務が完全に遂行できることを、あらかじめ実データを使って実演しろ」といった注文が来ていたかも知れません。そこには Lean Startup や Agile Software/System Development の考え方が入る余地がありませんから、うまくいかなかったのではないかと思います。私は、遅れてくることにはこういう良いこともあるんだ、と逆説的に捉えることにしました。
 
ーーーー
 
公開直後に追記（不細工！）
 
現場側に QGIS を持ってきたのには訳があります。
実は、「数ヶ月前、今の仕事場周りの DX 対応を議論していた際に、仕事場で使うデータが相互に連携できていない点をどうするか、という問題が話題になった」仕事会合において、 現場のあるセクションで、QGIS を普段使いしているチームが見つかったのです。そのチームでは、自己流DX を QGIS を利用してトライしていて、データ側がきれいでないためにうまくいかないでいる、という状況でした。
なので、QGIS とある程度相性が良い PostGIS でデータ側を対処しようと思い立ったのでした。

引っ越しました

「はてな」から、『ダイアリーからブログへ引っ越してね』というお願いメールが何度か届いたので、引っ越しました。見た目を昔に合わせるのは、面倒なので当分やらないと思います。記事も、ほかに SNS を持っているので、更新は進まないと思いますが、過去記事の中に多少備忘録として使えるものがあるので、残しておこうと思います。
こういうときに、黒歴史的なことを書かない習慣にしていることは大事ですね。

ところで、自分の認識では数人もいなかったはずの『ファン』が 45人もいます。その大半は虚偽アカウントのようで、id:xxxxx をクリックすると 404 not found が表示されます。運営に「可能ならばなんとかしてね」という趣旨のお願いをだしておきましたが、どうなることやら。

役所で FOSS4G を広めるには？

　今年も Advent Calendar の季節が到来しました。
　Kubo Mayumi さんのご厚意でエントリさせていただいたので、割当日よりも少し遅れましたが、少し思うところを書いてみます。
　今年のネタは、11月の FOSS4G Tokyo でも少し話題になった、FOSS4G を（特に役所に）広めるには、です。これは、私の前職（国土交通大学校測量部長）にも関係しています。役所の都合で書いていますので、オープンソースソフトウェアの開発者の方々から見ると【何か虫のいいことを書いているなぁ】という印象を持たれるかもしれません。それでも、そういう「手前勝手」の中に、良いソフトが拡がるために必要な条件が潜んでいると思っています。

仮定

　役所で使う場合には、いくつかの仮定が必要です。これは、役所に限らず、キャズムの右側にいる人にある程度まで共通しています。

  1. 利用者の大半（場合によっては全員）が IT の知識を十分なレベルまでは持っていない
  2. 研究者だったら「ググれカス」で済むような案件でも、調べられない（調べる暇やスキルがない）

安定していること

　最初に、仕事場で使うソフトウェアは、安定していることが何よりも重要です。
　当たり前のようですが、これは極めて重要です。ボスに「良いソフトがあります」と言ってデモをすることになったときに、ボタっと落ちたのでは台無しです。
　実は、バグが少ないことだけでは十分ではなく、実質的なバージョンアップの頻度が少ないことも重要です。ここで「実質的な」とは、「使い勝手の変更を求めるような」くらいの意味で書いています。OS（Windows 7 を想定）やブラウザ（Firefox を想定）は、更新頻度は高いですが、使用感が殆ど変化しないので、頻繁にアップデートが起きる割には気になりません（Windows Update は馴らされているだけかも知れませんが）。

セキュリティホールがないこと

　セキュリティ的に大丈夫かどうかは、今や大きな問題です。スペックがどれだけ良くても、セキュリティ的に不安があるソフトウェアは、早晩、システム管理者から利用を禁止されてしまいます。実際に、私が国土交通大学校で「布教」を行った際にも、セキュリティをどう見るのか、といった質問は少なからずありました。
　オープンソースだからセキュリティが弱いということはないと思います。プロプライエタリでないソフトウェアでも、Apache や php など、セキュリティ的に問題ないと見られているものはちゃんとあります。一時的なセキュリティホールが見つかることはあると思いますが、有志が素早く塞いでいます。
　ただ、Apache などは、以下の条件を満たしていると思います。

  1. 専門家のコミュニティが機能していて
  2. 保守を専門に請け負ってくれる専門家が多数いる

　日本における FOSS4G の場合、OSGeo.jp がこのような役割を相当量果たしてくれています。継続的にサポートが得られ、最近では良い解説本も登場しています。このようなコミュニティの存在は貴重です。

教育システム

　ソフトウェアをブラックボックスだと思い込むならば、教育システムは不要かもしれません。
　Apache はその好例です。私自身は、自分で Apache をインストールし立ち上げたこともありますが（威張るほどのことではありませんね）、普通の役人はそういうことはしません。その場合であっても、Apache のようなソフトウェアであれば、維持管理は専門の技術者に委託することができます。役人は教育を受ける必要がないのです。
　しかし、GIS は自分たちでも使いこなす必要があります。すなわち、教育システムが必須です。このとき、残念ながら「ググれカス」が成立しない場合が多いです。GIS が本業ではないと思っている役人に「ググれカス」と言うと、相当数が逃げてしまいます（Late Majority も多いので）。
　私自身、2014-Nov の FOSS4G Tokyo では自分のことを Early Majority であると申しましたが、これは QGIS に限った話であって、その他の Open Source Software では Late Majority だったり Laggard だったりします（威張ってはいけませんね）。

コアになる人材がみつかるか

　地理院の場合は、@_hfu_ さんがいてくれる御蔭で、コア人材は当分の間維持できると思います。まあ、@_hfu_ さんはどうみてもキャズムの左側の人材ですが（笑）、彼以外にも何人かコア人材がいます。
　組織によっては、コアになる人材がいない（まだ資質を発現していない）ところもあります。国土交通大学校では、QGIS を普及させる上で組織のコアになる人材を育てることを目的とした研修も開催していましたが、参加してくれた人は、もともとポテンシャルを持っている人が多かったように思います。
　一方、コアになり得る人材が、技術として何を選ぶ（好む）かは分かりません。たとえば、@_hfu_ さんにとって、FOSS4G を盛り上げることは第一目的ではなく、あくまで、国土地理院の業務を上手く回すことが第一目的だと思います。その目的に FOSS4G が適っている限り、FOSS4G は使われ続けるでしょう。しかし、もしもその目的から外れると、使わなくなるかもしれません（この、恐ろしい話は、もちろん @_hfu_ さんとは事前に相談していません）。
　彼でも誰でも、自分の業務を回すことが第一目的の人にとっては、特定のソフトを使うことは第一義ではないのですね。


　それよりも、コアとなる人材（その多くは early adopter だと思います）が、大多数の同僚（彼らはキャズムの右にいる）と乖離してしまわないことが重要です。私が見る限り、自分以外の同僚全てがキャズムの右にいるために、必ずしも万全の幸せを享受できていない人もいるように思います。キャズムの右にいる人でも、キャズムの近くにいるならば、キャズムの左にいる人とチャネルを維持することはできます。そのような人もコアになる人材に数えて良いかも知れません。私の立ち位置はこのあたりのようだと思っています。

発注時の話

　昔と違って、役所では随意契約ができなくなりました。つまり「あの会社にお願いするのが一番良いと分かっているのだけど、そういうような指定ができない」のです。
　そこで、ソフトウェア開発まわりの発注をかける場合は、まず、仕様書をしっかり書き、仕様書の内容を満たす能力がある人（一般には複数）の中から、価格競争で受注者を選ぶことになります。
　ここで、不適格な会社を受注させないという観点で良い仕様書を書くことは、決して容易ではありません。仕様書を書く側が、当該ソフトウェアのことをよく知っていない限り、良い仕様書を書くことが難しいわけですね。コアになる人材がいない場合は、このレベルのことが難しい場合もあります。
　しかし、キャズムの左側にいる技術者の多くにとっては、そういう仕様書を書くことの難しさには興味を感じないのではないでしょうか。フェイス・トゥ・フェイスで、よく分かる者同士で話し合えば、落としどころは見えてくるのに、発注者のいないところで（あるいは、理解の悪い発注者の前で）書面を書いたりするのは効率が悪く感じる人もいるのではないかという気がします。一般に発注者は、受注者が持っているような技術力を持っていませんので、難しい表現だと通じないこともあります。が、難しいことをやさしく言うために時間を割くんだったら、プログラムの１行でも書いている方が楽しい、と考える人もいるでしょう。ただ、以前に比べると、このあたりの事情は変わりつつあるように思います。分かりやすい資料を作ることが、ハイクラス技術者の楽しみになってきているように思えます。slideshare のようなメディア、TeD のようなイベントの存在が影響しているのかもしれません。

で？

　世の中に真に必要な技術だったら、自然に（なんだかんだ言っても）広まっていくのかもしれません。
　GIS は、まだ、そこまでに到っていない技術です。ここでは、それをどう広めるか、という話として書いてみました。そこに、工夫の余地があるわけですし、発注者の甘えをどこまで補うかという受注者の苦悩がある、のかもしれません。

QGIS Dufour でレンダリング

　初心者にも優しいGISであるQGIS、最新版（CodeName Dufour, ver.2.0.1）になってさらに使いやすくなりました。この項では、そのうち、QGISのレンダリング機能について紹介します。
　地図のレンダリングは、例えば書籍【Infographics】や【Illustrator で地図を表現する3行レシピ】など、既にいくつか良書があります。Illustratorを使えば様々なレンダリングができたとしても驚くべきことではありません。それを、QGISでどこまでできるか、が本稿の主眼です。


　図１は地理院地図です。地理院地図は平成25年10月30日からウェブ公開されています。この地理院地図の公開にあたっては、内部処理でOpenLayersが利用されていますので、外部からのアクセスがしやすくなりました。私は既に11月1日のFOSS4G TokyoにおけるLightning Talkで、QGISのOpenLayersPluginを用いてQGIS上で地理院地図を表示させる方法について話しました（図２）。

この方法では、予め地理院がレンダリングしたタイル画像を順に読み出して配置しているに過ぎません。これをベクタデータ（shapeファイル）でどこまで再現できるかが今回の勝負です。
　地理院地図は、地理院が無償公開している基盤地図情報よりも明らかに詳細なデータを使用しています。完全に同じものではないのですが、国土基本情報というものがあり、標準地域２次メッシュ単位で170円で販売されています。試しにつくばエリアを2メッシュほど購入してみました。各メッシュはShapeファイルで350Mbytesほどあります。販売データには、位置情報以外の情報は何も付与されていません。つまり、建物記号や土地利用記号などのシンボルデータ、個々のshapeの色、線幅などの情報も付与されていません。従って、これをいきなりQGISで開くと、図３のように悲惨なことになります（笑）。

　最初はレイヤがアルファベット順に並んでいるので、上から順に一つずつプロパティを確かめて線幅、塗りつぶし色、透明度などを順番に設定していきます。その過程で、上下関係を入れ替えた方が良いレイヤも幾組かありますので、入れ替えていきます。レイヤの上下関係は、おおざっぱに言って、

  1. 注記、点図形、線図形、面図形の順
  2. 人工物、自然物、仮想物の順

という原則に従いますが、強調対象が何かによっては多少順序が入れ替わることもあります。このあたりは、昔の紙地図原図（つまりマイラと呼ばれたフィルム）の重ね合わせ順序と本質的に似ています。その上で、他の地物と表示の強さについてバランスを考慮する必要があります。色の濃淡を何度も微妙に変更する必要があり、しかも一箇所いじると他のレイヤも変更したくなります。ともかく、ある程度試行錯誤を繰り返してできたのがこの図４です。

　図４はまったく自己流の色設計ですが、こういうレベルまで来ると、既存の地図の真似がしたくなります。で、地理院地図の真似をしてみたのが図５です。図１と比べると、完全には一致していないことが分かりますが、それでも図１と並べなければかなり近いイメージになっています。ちなみに、基盤地図情報ではここまでの絵は出せません。そもそもレイヤ数もずっと少ないです。

　さて、地図レンダリングにあたって、図５は図４より少しだけ工夫していますので、そのあたりを説明します。
　まず道路です。図５の道路は、図１の道路と同様に、道路種別で色を塗り分けた上で、道路の幅員に応じた表示となっています。QGIS Dufourでは、道路縁と道路中心線を使っています。道路縁は、文字通り道路縁を高い位置精度で取得して得られるベクタデータです。道路中心線は、道路縁よりは若干位置精度は低いと推定されますが、道路のネットワーク構造を考える場合に欠かせないベクタデータです。道路の属性（国道、都道府県道、市町村道、高速道路などの種別と、幅員区分）は、道路中心線の方に付与されています。
　図５では、1) 道路縁を道路中心線より優先させて描画することとした上で、2) 道路中心線はライン属性を二重とし（図６）、3) 下側属性を道路幅員で分類して線幅を決め（図７）、4) さらに線の色を道路種別で分類し（図８）、5) 上側属性として細い線を表示する（図９）、という段階を踏んでいます。ここで、3)4) と二種類の分類を続けてできる点が最新版のQGIS（Dufour, ver.2.0.1）の特徴です。Wroclaw（ver.1.7.4）まではこのような機能はありませんでした（私は日本語環境が不安だったver.1.8は使っていません）。特に、図８で示す case when – then – else – end 文の威力は大きいと思います。これがある御蔭で、道路縁の内側を幅員に応じて塗りつぶすことができ、その際の色を道路種別に応じて変更できているのです。図５では、画面中央の新井付近で県道（黄色）が細い川を横切っています。この黄色い帯がなければ、道路の路面も河川の青が表示されてしまいます。




　ただし、道路中心線の幅員区分は５段階に分類されているだけなので、道路中心線の幅員区分から機械的に発生させた幅広の着色線は道路縁の位置とはぴったり一致してくれません。これは、表示縮尺を一桁拡大してみればよく分かります（図10）。位置精度に拘らないレンダリングをしたい場合は、道路縁を表示させるのではなく、道路中心線に３番目のライン属性を設け、先ほどの?で下側属性を道路幅員で分類して線幅を決めたのと同様に、そのさらに下側に道路幅員で分類してやや太めの線幅の線を灰色や茶色で引く手法もあります。これでも完全には解決しませんが、その例を念のために示します（図11）。


　このほか、【樹木に囲まれた居住地】というポリゴンがあります。これは、集落を含むようなポリゴンで、内部に何軒かの家屋があり、数本の道路が通っています。このポリゴンは薄い色で表現しますが、建物や道路が不明瞭になってはならないので、低めのコントラストで最下層のレイヤとして配置することになります（図12、薄いオレンジ色のポリゴン）。

　このように、QGIS Dufourは地図レンダリングエンジンが大幅に強化されたことがわかります。ここまで凝ったレンダリングをする場合は、設定にそれなりの時間を要します。せっかく位置精度の高いデータを配布しているわけですから、標準的な線属性も.qmlなどで一緒に配布するのも面白いかも知れません。ただし、.qmlだけではレイヤの上下関係は指定できないので、実際には.qgsで配布する方が良いことになります。すると、QGIS専用の設定となりますので、地理院配布よりもOSGeo.jpなどサードパーティ配布の方が適していると言えます。
　さて、ここまでレンダリングしてみると、国土基本情報の側にさらに注文したいことが見えてきます。例えば、実際の道路に工事その他による変更があった場合、道路縁や道路中心線は細かいセグメントに分割されます。しかし、ネットワーク解析を行う場合には、細かいセグメント分割は不要です。従って、交差点から次の交差点までは１路線１セグメントである方が有難いことになります（これは、QGISの上でユーザが加工することも不可能ではありませんので、国土地理院の宿題だとは言わないことにしておきます）。また、道路縁には不可視属性のフィールドがあり、これが１の場合は表示しない扱いとするべきですが、不可視属性をもつセグメントは実際よりも長めであるように思えます。あるいは盛り土の法面情報が不十分なのかも知れません。このあたりは属性情報をどこまで正確に取得するかという話になります。位置精度も位相精度も間違ってはいないので、微妙な話です（この場合も、QGISの上でユーザが加工することで、不可視属性を持つセグメントの長さをクリップすることは可能です）。

　ここまで、QGIS Dufourがレンダリングエンジンとしても使えることを見てきました。ここまでできるとなれば、これまでIllustratorで行っていた地図レンダリングのかなりの部分をQGISでもできることになりますので、これまたプロプライエタリソフトの初級〜中級の部分をFOSS4Gが置き換え可能になる良い例と考えます。地図データを大規模配信する場合は、現時点ではMapServerやGeoServerを（PostGISなどと組み合わせて）使うのでしょうけど、MapServerの設定をどのようにするか、アタリを付けるレベルであればQGISで簡便に確認できるような気がします。Dufourはこういう点でも今までのバージョンから大きく進化しており、まさにメジャーバージョンが２に上がっただけのことはあると考えています。

iframe に電子国土を（その１）

たしかに、こうすれば電子国土の地図タイルが表示されるようだ。


　tmizu23 さんのサイト http://d.hatena.ne.jp/tmizu23/20121212 の情報を参考にしました。

　Google Gadget を使わなければならないが、はてなの場合はこうしないと html 文のタグがサニタイズされてしまう。