- tinyworldmapは、オフラインファーストおよび低帯域幅のWebアプリ向けの世界地図で、Leafletと一緒に使うよう設計されている
- 全ズームレベルをサポートし、最も完全なバージョンはgzip 450KBで、10年前の低性能な携帯電話でも体感できる遅延が出ないよう、クライアントレンダリングをプロファイリングしてテストしている
- 基本地図には、OpenStreetMapに追加された人口上位10,000都市が表示され、執筆時点で人口48,000人以上の都市と町を含む
- 利用方法は、OpenStreetMapタイルを置き換えるベースマップ、またはオフライン時にOSMタイル要求をローカル生成タイルに切り替えるフォールバック地図の2種類
- 地図データはOpenStreetMapと同様にODBLライセンスに従い、LeafletフッターなどにOpenStreetMapとtinyworldmapのクレジット表記が必要
tinyworldmapの目的と範囲
- tinyworldmapは、オフラインファーストおよび低帯域幅のWebアプリ向けの世界地図
- Leafletと一緒に使うよう設計されており、すべてのズームレベルをサポートする
- 最も完全なバージョンはgzip 450KB、展開後は1.1MB
- クライアント側レンダリングは10年前の低性能な携帯電話で広範にプロファイリングおよびテストされ、体感できる遅延はなかった
- デモはNightly demo、Stable demo、v3 announcementで提供されている
基本地図データ
- デフォルト設定では、OpenStreetMapに追加された人口上位10,000都市を表示する
- 執筆時点で、この範囲には人口48,000人以上のすべての都市と町が含まれる
Leafletで使う2つの方法
地図スタイルとカスタム地図
- コンストラクタは
renderオプションを受け取り、地図の見た目を変更できる
- 各レイヤーの
styleオプションは、CanvasのCanvasRenderingContext2Dに適用される
- たとえば
state_bordersレイヤーにfillStyleを指定してスタイルを変更できる
let render = {
state_borders: {
style: {fillStyle: '#f00'}
}
}
new L.GridLayer.TinyWorld({maxZoom: 19, render}).addTo(map)
- 組織で道路地図、都市地図、他言語の地図、OSMまたは非OSMデータを含むカスタムコンテンツ地図が必要な場合は、
business@tinyworldmap.comへ見積もりを依頼できる
より小さい地図ファイルのオプション
-
境界線なしバージョン
tiny-world-cities-10000.js(on)は、完全版から州境、国境、海岸線を除いたデータを含む- このバージョンではgzip基準で300KB、展開後基準で825KB削減される
- 境界線なしバージョンには、含まれるデータがすべて高精度であるという利点がある
- 完全版の国境線は高ズームレベルでは正確ではないため、国境線や海岸線に合わせた図形をオーバーレイすると不自然に見えることがある
- そのような場合は、境界線なしバージョンのほうが見た目が良いことが多い
-
都市ラベルなしバージョン
- 都市ラベルのないファイルは2種類ある
tiny-world-borders.js(on): 州境を省略tiny-world-nocities.js(on): 州境を維持- 都市ラベルは、展開後で410KB、圧縮後で172KBを占める
-
都市数を減らしたバージョン
- 都市ラベル付きファイルには、2,000個、4,000個の都市バージョンも用意されている
- ファイル名の
10000を2000または4000に変更すればよい
- | 含まれる都市数 | 人口基準 |
- | --- | --- |
- | 10,000 | 48,000人超 |
- | 4,000 | 137,000人超 |
- | 2,000 | 287,000人超 |
ライセンスとクレジット表記
- tinyworldmapのデータは、OpenStreetMapデータと同様にODBLライセンスに従う
- ODBLはクレジット表記を要求する
- 案内どおりに設定していれば、LeafletフッターにOpenStreetMapとtinyworldmapのクレジット表記が含まれているはず
- そうでない場合は、OpenStreetMapとtinyworldmapのクレジット表記を別途追加する必要がある
1件のコメント
Hacker News の意見
アイデアは気に入った。あまりに遠くまで縮小して、たった今リクエストした大陸タイルをサーバーがレンダリングするまで待たなければならない問題を解決してくれるので良い
ただ、Detroit 郊外の West Bloomfield Township と Waterford Charter Township の相対的な位置は分かるのに、それがどの州にあるのか、あるいは Great Lakes が存在するのかも分からない、というユースケースが何なのかはよく分からない
海岸線にははるかに多くのデータを使い、大都市圏の細分化にはもっと少なく使うとよさそう
他に入れられる情報をあまりにも多く覆い隠してしまう
素晴らしいが、海岸線のディテール が低すぎる。英国のいくつかの町は海の上に浮かんでいて、逆に Greenland と Northern Canada が頂点を全部持っていっている
Mercator 投影によるディテールレベルはすでに考慮しているようだが、人がほとんど住んでいない地域の優先度を下げるとよさそう
QRank の SQLite DB も以前 HN に投稿されたことがある
[1] https://qrank.wmcloud.org/
[2] https://github.com/hikeratlas/qrank
Netherlands のある州が国の本土から切り離され、島のように表示されているが、実際にはそうではない。なのに、その州内の都市名は5つも把握していて、そのうちいくつかはほとんど重なっている
一方で Afsluitdijk を入れているのは個人的には不要なディテールに思えるが、どの陸地を描くかと単なる海上インフラをプログラムで区別するのが難しいのは理解できる
issue tracker にチケットを立てるべきだろうが、モバイルでログインしていないので今は HN コメントが最善だ。同じように感じる人がいれば、このコメントを根拠に比率調整、都市間の最小距離の導入、全体のファイル縮小といった改善を提案してもよいと思う
French Polynesia は地図上に存在すらしない
もともとそうしなかった理由は、古いスマートフォン、特に Firefox for Android で多数のポリゴンを描画するとクラッシュする可能性があったためだ。その後、描画手順を最適化したが、注意は必要
[1] https://tinyworldmap.com/beta.html
これは基本的な 品質管理 で検出すべき部分だ
似たものを作った。オフラインファーストで、とても小さく、ベクターベースだが、国際化 に重点を置いている
UN のすべての言語で提供している。ただし Spanish は単に忘れていて抜けており、数時間で作れるはずなので恥ずかしい
国名と都市名には、UN に登録された正式名称を使っている。そのため UK の正式な短縮名は “United Kingdom of Great Britain and Northern Ireland” だ
https://map.ache.one/en
軽量な地図を描き、国際化を扱うのは比較的簡単だった。公開データソースとライブラリがいくつもあるからだ
本当に難しいのは、純粋に 行政上の定義 だ。大半の国に紐づくデータがあると、地図ソースと必ず食い違う部分が出てきて、最終的には独自に調整した地図を作る必要がある
「国」とは何かについて合意がない。Western Sahara は公式には国だが、実質的には Morocco がずっと占領してきたし、Somalia では Somaliland と Puntland が事実上の独立国のように動いているが、公式な承認はない。Greenland や Niue などはその中間のどこかにある
国単位でやってみた経験では、汚いハックを含む手作業のプロセスで、きちんと合わせられたかをテストするのが一番大変だった。特に適切な 一般化レベル と、人々が自分の地域の地図に期待する見た目が難しい
この地図を大きく改善するためにかける労力に価値があると見ているのか気になる
星印は Dar Es Salaam にあるのに、ラベルは Dodoma になっている。Dodoma が実際の首都だが、国の中央寄りにある
かわいい。以前、完全に同じではないが似たものを作ったことがある
https://web.archive.org/web/20020611095429/http://www.cs.man.ac.uk/~hancockd/CityZen/index.html
線分2万本、場所3,350か所、ビューアとクイズまで全部合わせて 162KB だった
フィードバックに感謝。選択の背景を説明すると、最近までこのプロジェクトの主な焦点は国の形ではなかった
長い間 README にあった国境なし版が唯一のバージョンで、全世界を追加できるとは思っていなかった。ところが可能だった
フィヨルドを削除し、要望の多かった島々を含めてほかの場所により多くのディテールを入れた nightly 版を公開した。全体的に解像度も高い
もともとそうしなかった理由は、古いスマートフォン、特に Firefox for Android で多数のポリゴンを描画するとクラッシュする可能性があったため。その後、描画手順を最適化したが、注意は必要
[1] https://tinyworldmap.com/beta.html
人口上位 10,000 都市が最善のフィルターなのかはよく分からない
この方法だと大きな国の都市が優先され、小さな国では大半の都市が漏れる可能性が高い
国ごとに上位 X 都市を入れる補助フィルターが必要。そのほうが小国の主要都市も拾えそう
首都、地方の中心都市、世界都市、地域内での中心性といった基準は、基本条件を補完するのに役立つかもしれない
この議論には 地理学者や地図製作者のほうが有用な助言をくれそう
世界で最大の 集落 10,000 件を選ぶと人口 48,000 人まで下がるというのが興味深かった
この数字が驚くべきものなのかどうか、まだ判断しているところ
200 件に増やしても、なお 10 万人以上。Wikipedia 基準で 333 位のカリフォルニア州デイリーシティは人口 100,007 人: <https://en.wikipedia.org/wiki/List_of_United_States_cities_b...>
このような規模分布は、ほかの多くのスケーリング状況と同様に、ログ・ロググラフではおおむね線形に近い
中国では、人口 100 万未満の都市が出てくるまで 106 位まで行く必要がある。米国にはそのような都市は 9 つしかない
インドは今確認したところ、人口 100 万超の都市が 46 あり、100 位のマレガオンは 47.1 万人、300 位のアウランガーバードもなお 10 万人を超える
ただし「都市」は非常に恣意的な定義。世界最大級の都市の一部は、別の国の基準では大都市圏、さらには州や省に相当する場合もある
面積基準で最大の都市は、むしろ人口が非常に少ない。グリーンランドのセルメルソークは人口 24,148 人、面積 575,300km²で、ロードアイランド州の約 144 倍、米国の州の中ではテキサス州とアラスカ州だけがそれより大きい。アラスカ州も 12% 程度大きいだけ
都市地理学は複雑な分野なので、通常は大都市統計圏、市街地面積、人口といった複数のスケールや定義を合わせて比較する。そうすることで政治的境界の恣意性を和らげ、総人口や経済的影響力をよりよく反映できる
国境がこれほど粗いのにファイルサイズがこの程度というのは、かなり驚き
全体のデータサイズは、有用性とファイルサイズのバランス点をかなり下回っているように思える。たとえば 2 倍のサイズでも、国境はここまでギザギザにはならなかったはず
「国境と海岸線を除いた完全版の全データがあり、それによりサイズが 200KB 減る」という説明を見ると、約 29% が国境・海岸データで、71% が都市名と位置ということになる
個人的には多くの都市を削除できそうに思う。特に互いに重なっている都市は、灰色の陸地と都市名が見える程度まで拡大しないと見えないので、その代わりに海岸線をより正確にしたほうがよさそう
一般的な世界地図上の位置がどれほど頻繁に必要なのかもよく分からない。たとえば今見ている関心地点の Web サイトでは、そこへ行くために使う周辺の高速道路や公共交通機関の路線を含む軽量地図のほうが、より頻繁に必要なのではないか
地球全体を数 km² 単位で分けたバージョンを作れば、10 分の 1 のサイズでもかなり有用なディテールを盛り込めそう。地球全体の低ポリゴン地図にも国際宇宙ステーションの追跡のような用途はあるだろうが、ずっとまれに見える
人口が 4 万人未満でも、首都は必ず含め、何らかの形で星印を付けるべき
本当にすばらしい。スマートフォンでこれほど速く読み込まれるのは印象的
空間データを Paths に圧縮するアイデアがとても良い
ODbL ライセンスを避けるなら、OSM の代わりに Natural Earth データを使うのもよさそう
空間データを Paths に変換するツールも含めると本当に良さそう