Code for History大塚恒平です。
歴史的民俗学的な地域史研究などに有用な、ITも含む活動を行うワンマンアーミーとして活動を行っております。
これまでバカの1つ覚えのように毎年Maplatを紹介してきたわけですが、今年はその他の開発物にも目を向けて一度全部紹介したいと思います。
フラッグシップ？のMaplatすら、基本作りたいもの優先の作りっぱでドキュメントとか未整備なので、他の開発物は輪をかけて推して知るべしですが、もしご興味のある開発物がありましたら、ぜひご協力いただけると嬉しいです。
Weiwudi (タイル地図アプリ向けPWAオフライン対応フレームワーク)
Maplatについでよく紹介しているWeiwudi(魏武帝:ウェイウディ)は、Webサイトをオフライン対応させる技術であるPWA(Progressive Web App)に、タイル地図アプリを対応させるフレームワークです。
こちらはネット上のリソースに誘導するにとどめます。
Qiita記事
SpeakerDeck
残念ながらまだベクトル地図には対応していないのが難点ですが、つい先日、関連Advent Calendarのベクトルタイルカレンダー2021で、ベクトルタイルへの対応を宣言したところです。
Gyeonghwon (Canvas地図APIでも、アニメーションマーカーを可能にするライブラリ)1
古き良き（悪き？）HTML divによるタイル地図の時代には、地図マーカーもdivで張り付けているだけだったので、マーカー画像をアニメーション画像にするだけでアニメーションマーカーが実現可能でした。
しかしCanvasの時代になって、単にアニメーション画像を使うだけではアニメーションマーカーが実現できなくなりましたが、それを可能にするライブラリがGyeonghwon(甄萱:キョンフォン)です。
OpenLayerで動いているサンプル:
https://code4history.dev/Gyeonghwon/index.html
特定の地図APIのみへの対応ではなく、CanvasのContextを受け渡してマーカーを作れる系のAPIであればどれでも対応可能(のはず)です。
つまり、特に地図関連の処理をしているわけではなくContextを各画像の内部定義に従い定期的に書き替えているだけなので、ユースケースがあるのかどうかわかりませんが、同じくCanvasの中で画像をアニメーションさせたい場合は流用できると思います。
対応しているフォーマットは、アニメーションGIF/PNG/WebPです。
Quyuan (GeoJSONを食わせてマーカーに必要なリソース群を生成するテンプレート)
GeoJSONからマーカーを作る場合、どんな処理が必要でしょうか？
- GeoJSON内に含まれる地物の数だけループを回し
- 地物の種別に従いマーカー画像を決定2し
- クリックしたときの表示するHTMLを生成し
- それらのマーカーやHTMLを各地図APIの流儀で地図面上に落とす
だけですが、このうち地図API毎に固有なものは4.だけで、1.～3.については共通化できます。
さらに2.や3.については基本文字列を生成する処理3で、最悪特殊なユースケースでも文字列から他のデータ形式にするのはパースすれば容易なので、地物データから文字列を生成するテンプレートを適用すれば、2.、3.も同じ処理化できます。
Quyuan(屈原:チュユェン)はこれを行うライブラリで、GeoJSONとそれを処理するためのいくつかのテンプレートを含んだハッシュを食べさせてやると、処理後の文字列の配列を返してくれます（わあシンプル！）。
あとは、各地図APIの流儀に従い文字列セットをループ回して処理するだけ。
実際のサイトにおける動作例:
このサイトのマーカーリソースは全部QuYuanで生成しています
https://code4history.dev/TatebayashiStones/
これだけだとなんなので、マーカーを作る際に便利ないくつかの便利処理も用意しています。
- 複数の画像が含まれていた場合、Swiperを使い、画像をスライダー化してくれる関数
- RICOH THETAなどによる球面画像が含まれている場合、それを見ることができるビューア
将来的には3Dオブジェクトのビューアなども、便利機能に加えたいなと思っています。
Torii (リレーショナルな位置情報付き文化財データをGeoJSONとExcelのダブルマスタで管理可にするユーティリティ)
上記資料の14ページ4に記載しているような、技術者が得意なQGIS/GeoJSONの組み合わせでのデータ管理と、非技術者が得意なExcelでのデータ管理を双方マスタデータとして、一方を更新後に実行すれば自動的に修正がもう一方のマスタにも反映されるような仕組みを作りました。
Torii(鳥居:トリイ)として公開しています。
これを実行すると、
- ExcelとGeoJSONどちらを変更しても5、中間データを介して、双方のマスタを変更に一致するように反映してくれる。
これにより、双方のマスタはどちらを変更しても常に等価になり、技術者や位置情報をいじりたい時はQGIS、非技術者や部分一括変換などを行いたい時はExcelと管理ツールを使い分けられる。 - GeoJSONのフォーマットは、QGISで編集した時、プログラムで編集した時など、微妙に改行位置やスペースの入る入らないなど差が生じるため、gitで管理しても変更箇所が検知できないが、このプログラムを実行することで、フォーマットが揃いgitで変更箇所を管理できる。
変更箇所が検知できるということは自動マージもでき、自動マージした結果をExcelに反映もできるので分散管理が容易になる。 - 画像ファイルを決まった仕様で画像フォルダに置くと、検知して自動で画像管理テーブル内のレコードの生成とサムネイルの生成を行ってくれる。
- Web等で公開しやすい、リレーション関係を解決して1つのファイルにしたGeoJSONファイルを生成してくれる。
これにより、そのGeoJSONをQuYuenなどを用いて読み込み表示するindex.htmlを準備し、github pagesで公開までしておけば、Webでの更新公開作業なども容易になる6。
といった効用があります。
実際に、『「たてばやしの野仏巡り」全5巻相当のデータのオープンデータ化＆現況調査プロジェクト』で使われており、『奈良市の道端の地蔵堂や小祠、石仏などをオープンデータ化するプロジェクト』にも適用予定です。
Harumi (あいまいな情報からの年号特定もできる、日本の年号<=>西暦変換ライブラリ)
GISにはかすりもしない非GISプロジェクトですが、紹介しておきます。
石造物を調査していて、年号干支の一部しか読み取れない状況から年号を特定したいケースがままあったので、あいまいな情報から年号の候補を出すライブラリを作り、Harumi(春海:ハルミ)として公開しました。
読み取れた元号、十干十二支、年数字の一部を指定してやると候補を羅列するところまでできています。
Webで実行できるようにもしたいと思います。
実行の様子はこんな感じ:
元々これがやりたくて作ったライブラリなので個人的には以上、なのですが、せっかくデータベース作ったので、日本の年号、ユリウス暦、グレゴリオ暦の年月日の相互変換などにも対応したいと思っています。
Maplat (古地図処理ライブラリ)
将来予定のライブラリ除いて、一応動くライブラリのトリとしては、一応Maplatにも触れておきましょうか。
Maplat関連の情報は、以下にまとまっています。
- 最新のフライヤー: 英語、日本語
- 最近の発表 (Geoアクティビティコンテスト2021 奨励賞受賞)
- Maplat関連のQiitaの過去投稿 Qiitaの検索さんに丸投げ
この1年ちょっとの間の大きな変化は、以下の感じです。
- 線を線に変換する機能が、豊橋市のバスロケーションシステム「のってみりん」にて採用
- 線を線に変換する座標変換方式で、古地図をWMTSのラスタタイルフォーマットに変換して出力可能に
- PWAによるオフライン対応機能をWeiwudiとして切り出し7
- 国土地理院Geoアクティビティコンテスト2021で奨励賞受賞8
今後もMaplatは発展をしていきますので、よろしくお願いいたします。
開発予定のプロダクト群
まだ十分に動くものにはなっていないものの、開発予定のライブラリについて紹介します。
もし似たようなアイデアを既にお持ちの方がおられれば、ご協力いただいてもよいですし、逆にこちらが協力する形も可能かと思います。
Dongju (ベクトルタイルダウンロードユーティリティ)
Weiwudiをベクトルタイル対応させるために、そのダウンロードロジックそのものをファイルシステムにも保存可能なツールとして、Dongju(東柱:トンジュ)を整備するつもりです。
開発が止まっているMapboxタイルのダウンロードユーティリティ、mapbox-style-downloaderを元に、Mapbox以外のデータソースにも対応させる形で、進めています。
Wenruo (Mbtilesのダウンロード=>IndexedDB展開ライブラリ)
こちらのWenruo(文若:ウエンルオ)リポジトリではまだ何も実装していませんが、WeiwudiをMbtiles対応させる際に、MbtilesをダウンロードしてindexedDBに蓄積させるロジック自体は、PWA用途以外でも使いたいユースケースがあるかもしれないと思い、独立ライブラリ化する方向で今のところ考えています。
Hoshu (複数の平板GeoJSON同士のリレーションを定義し単独の構造化GeoJSONとするライブラリ)
こちらのHoshu(芳州:ホウシュウ)リポジトリではまだほぼ何も実装していませんが、QGIS等では実現できる複数の平板GeoJSON同士に対しリレーションを定義し、それに従って複数のGeoJSONを読み込み1つの構造化GeoJSONとして再構成するライブラリを考えていました。
ただ、そのやりたい機能自体はToriiの中の機能4.として実装してしまったので、引き続き作ろうと思えばそこからロジックを抜き出す形になるのですが、他のユースケースがあるかどうかよくわからないので、継続開発するかは少し黄信号が灯っています。
もしやるなら、GeoJSONを構造化するだけでなく、LOD(Linked Open Data)のどれかのフォーマットにも変換できるようにするとか、付加価値をつけるかもしれません。
2022年もよろしくお願いいたします。
そんなこんなで、自分以外誰が使うのかもわからないオープンソースGIS/非GISライブラリを粗製乱造しているCode for Hsitoryですが、2022年も空気読まず突っ走りますので、また来年もよろしくお願いいたします。