Code for History

"Code for History"はIT技術を歴史学上の問題の解決に使うコミュニティです。強調したいのは、我々にとってIT技術は「手段」であって「目的」ではありません。「目的」は歴史学上の問題を解決する事であって、必要であればITでない手段も活用します。常に最優先なのは、問題を解決することです。

maxZoom以上にタイルを拡大できるGoogleMaps, Leaflet向けTMSレイヤライブラリを作りました。OpenLayers対応も検討中。

久しぶりの更新です。
表記の通りのライブラリを、githubで作りました。

https://github.com/kochizufan/ZoomTMSLayer

とりあえずはGoogle Maps API向けで作りましたが、Leaflet、OpenLayers対応版も作りたいと思ってます。
パッチやテストの追加は大歓迎です。

※9/16追記:Leafletにもなんちゃって対応してみましたが、GMaps版に比べなんか動作が重くて汚いです。とりあえずテスト版で。あとプロジェクト名変更しました。


タイルをズームすれば画素も荒くなって見栄えが悪くなるのに何でこんなもの作ったかというと、最大ズームが元データの解像度と一致してると、ベースマップと重ね合わせて比較した時に、ああ、もう数ズーム拡大できれば大縮尺でしか確認できないあのPOIとの位置関係比較ができるのに、というケースを何度も経験したためです。
画像の美麗さを損なわないためにズーム等邪道だ、等と原理的な事を言う人が居るのも知ってますが、原理的な物の考え方は大嫌いだし、また原理的でなくす事で得られる/生じるバリューも存在するわけなので、別にズームできてもいいやん、嫌ならしなきゃいいやん、と個人的には思ってます。

しかしながら、サービス側が大縮尺へのタイルを準備するとなると、TMS(Tile Map Service)サービスは一つ大きいズームに対応する度に、必要なタイル数が指数級数的に増えていくので、ストレージや配信、管理コストの増大も馬鹿になりません。
かなり大きな縮尺まで対応しようとすると、簡単に数百万〜数億タイル数のオーダに載ってしまいます。
一応新たな価値も生むとはいえ、所詮は汚い画像のためにインフラコストを費やすのも馬鹿馬鹿しい話です。
たかだかズームなんてクライアントサイドでも出来る事なので、各TMSにはもっとも奇麗に見えるレベルまでのズームを用意してもらって、それ以上の拡大はクライアントサイドでやればいいよね、という発想で作ってみました。


実際の稼働例は以下のような感じです。

Google Maps
http://kochizufan.s3.amazonaws.com/g_sample.html

Leaflet版
http://kochizufan.s3.amazonaws.com/l_sample.html

歴史的農業環境WMS配信サービス(関東平野)の迅速測図/東京5000分の1タイルをサンプルに使わせていただいております。ありがとうございます。
こちらの迅速測図/東京5000分の1タイルはズーム17までしかないのですが、それ以上のズームまで表示できるようになっています。
また頭打ちを作る事もでき、迅速測図は青天井で拡大できるようにしていますが、東京5000分の1はズーム19が最大ズームになるようにしています。


個人的考え方として、今後のWeb地図の動向は、大きな地図プロバイダが大規模な地図を配信するだけでなく、MapBoxのように個々人が小さな地図を配信していく時代になると思っていて、その基盤としてTMSが使われていくと思っている。
が、TMSの一つのネックが大縮尺に対応すればするほどストレージ/インフラコストが青天井になる点で、その解決策の一つとして、このタイルズームライブラリが使われるといいなと思ってます。

© Code for History