JA:Mapnik

Mapnikはオープンソースのマップレンダーで、OSMのSlippy Mapのメインレイヤーを描画するのに使われています。

Mapnikは、地図を描画するフリーなツールキットです。これはC++で書かれており、Pythonへのバインディングがあります。AGGライブラリを使うことで、アンチエイリアスによりサブピクセルまでの正確さで描画します。ESRI shapes、PostGIS、TIFFラスタイメージなどを読むことができます。現在のところ、すべての依存するものをapt-getで簡単に取って来ることができるので、Linux上でソースからmapnikをビルドするのが一番簡単です。でも0.5リリースバイナリからは、Windows版が入手可能になり、Mac OS 10.4, 10.5でもビルドに成功するようになりました。

公式ホームページは、mapnik.orgで、tracサイトはtrac.mapnik.orgとirc://irc.freenode.net #mapnikにあります。

バグとレンダリングの提案

どんなバグ、グラフィックに関する提案または描画されていないフィーチャなどに対する要求等は、"slippy_map"の下にあるtracに報告してください。 ticketを書く前に、同じものがないかtrac tickets with component "slippy_map"で、確認してください。

概要

OSM データはMapnikが使いやすいフォーマットに、osm2pgsqlで変換されます。osm2pgsqlは変換したデータをPostGISデータベースに載せます。これとその他のデータソースに基づいて、OSMはMapnikを使って、256 × 256 px のタイルを描画します。これらタイルは、タイルサーバー(tile.openstreetmap.org)から提供されます。Slippy MapのJavaScriptは、例えばhttp://tile.openstreetmap.org/7/63/42.pngのようなURLで、次のようなイメージを参照します:

詳しくはSlippy map tilenamesを見てください。

データソース

Mapnikの主レイヤの主データソースはOSMデータをosm2pgsqlで変換したものです。 でも、Mapnik はOSM以外のデータも地図を作るのに使います。海岸線は、例えばVMAP0からのデータを使って作られます。詳しくは、Coastline#Main_Mapnik_Layerを見てください。

準備

これは進行中の仕事なので、以後変わることがあります。

このプロセスは、もし世界全体を処理するつもりなら、かなりの量のディスクスペースを必要とします。 個々の国くらいなら、普通のマシンで扱えるでしょうが、地球全体ならここに必要条件の目安があります。(2009年4月4日のもの) これはインデックス領域を含んでいます:

全部で約30GBバイトです。osm2pgsqlでスリムモードを使っているなら、約20GBがテンポラリテーブルに必要でしょう。インデックスも同様に必要で、インデックスを含めた全体のデータベースの量は61GBになるでしょう！

新しいニュース：2010年4月現在で、europe.osm.bz2をスリムモードで処理した場合は90GBのディスク領域が必要になるでしょう。

メモリが十分にあるなら（>12GB）、通常モードを試せます。ふさわしいマシンでは、処理は3～4時間で終わります。メモリが十分にないなら、どんなメモリの量でも動くスリムモードを使う必要があります。3GBのメモリを使用すると、処理は24時間程度かかりました。この値は使っているディスクによって大きく変わってきますが。

Note: スリムモードは差分ファイル（例えば、1分毎の差分）を適用したい場合に必要になります。

RAMモードで地球全体をインポートしたときのメモリ使用量を表したグラフがあります：

テンポラリテーブル以外に6.1GBのディスク領域が地球のダンプに必要なことに注意してください。

データセット

タイルのレンダリングには2つの大きなデータセットが必要です。これらを先にダウンロードし始めるのは良いアイディアでしょう。

Planet.osm

Planet.osmはOpenStreetMapデータベースのスナップショットです。See Planet.osm

$ wget http://planet.openstreetmap.org/planet-latest.osm.bz2

Note: テストのために小さな領域をレンダリングしたいのなら、適当な.osmファイルをインポートして試せます。地球全体をレンダリングする必要はありません。これは、何時間も3GB以上のデータのダウンロードや地球全体のインポートに時間を費やす前にレンダリングがちゃんと動いているか確認するために推奨されています。適当な.osmファイルを入手するには、JOSMでダウンロードして保存したり、Planet.osm#Extractsにリストアップされている小さなデータを使うことができます。

世界の境界

小縮尺では、Mapnikは外部の海岸線データを使います。See Coastline#Main_Mapnik_Layer

$ wget http://tile.openstreetmap.org/world_boundaries-spherical.tgz (50 MB)
$ wget http://tile.openstreetmap.org/processed_p.tar.bz2 (357 MB)
$ wget http://tile.openstreetmap.org/shoreline_300.tar.bz2 (48 MB)

これらをダウンロードして、Mapnikスクリプトをチェックアウトしてから（以下のdetailsを参照）、mapnik/world_boundariesという名前のディレクトリを作成してアーカイブを展開してください。world_boundariesディレクトリ以下にありそうなの全てのファイルとディレクトリを移動してください。

2010年6月から、以下の2つの追加ファイルが必要になりました：

$ wget http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/10m-populated-places.zip (1.5 MB)
$ wget http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/110m/cultural/110m-admin-0-boundary-lines.zip (38 KB)

PostgreSQL / PostGIS

Mapnikは空間データベースとしてPostgreSQL / PostGISを使えます。Mapnikと一緒に使うためにPostgreSQL / PostGISをインストール、設定するための説明は、Mapnik/PostGISのインストールページを見てください。

osm2pgsql

osm2pgsqlはOpenStreetMapのデータをPostgreSQLに変換するコンバータとデータローダです。

インストールの説明は、osm2pgsqlを見てください。

球体メルカトル投影でosm2pgsqlを初めて使う前に（以下を参照）、この投影法のための設定ファイルを初期化する必要があります。以下のように、osm2pgsqlに含まれる.sqlファイルを実行することで初期化できます：

[Syntax on Windows]
$ psql -d gis -f c:\osm2pgsql\900913.sql

[Syntax on Linux]
$ wget http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/900913.sql?format=raw -O 900913.sql
$ psql -d gis -f ./900913.sql

Enabled Intarray (差分を使う場合)

psql gis < /usr/share/postgresql/8.3/contrib/_int.sql

加えて、osm2pgsqlが使用するデータベースのスキーマがMapnikのものと一致していることを確認する必要があります。一致していなければ、直ちにおかしなことが起こるでしょう。

スキーマは、osm2pgsqlにはdefault.styleで、Mapnikにはosm.xml (resp. osm-template.xml)に記述されています。 svnソースからビルドしたものでないosm2pgslパッケージのdefault.styleはたぶん古いでしょう。 ですので、Mapnik OSMをsvn(see below)から取得する場合は、default.styleをrepository browser経由でアップデートする必要があります。

Mapnikのインストール

Mapnikをインストールするには、この説明に従ってください：Mapnik/Installation

Fedora 10でのもっと詳細なインストール手順は、次の手順に従ってください：Mapnik/Fedora Installation

データの読み込み

単にosm2pgsqlを（mapnikを実行するユーザとして）呼び出してください：

$ osm2pgsql -m -d gis planet-latest.osm.bz2

このプロセスはかなり大量（512MB程度）の空きメモリを必要とします。メモリが足りなくなった場合、予測できない落ち方をします。（例えば、.osmファイルにエラーが存在する、など。）空きメモリとスワップ領域が十分にあることをosm2pgsqlを実行する前に確認してください。

"-m"オプションは推奨されている球体メルカトル投影を有効にします。これはバージョン0.55、SVN R8320以降ではデフォルトとなっています。いくつかの古いツールは今でも"latlong"や球体でないメルカトル投影などの違ったデータを期待します。これらやその他の投影法を選ぶコマンドラインオプションがあります。

また、最新版のosm2pgsqlはインポート時に単純な矩形領域によるフィルタを設定できます。これによって、小さな領域をレンダリングしたいときにとても高速になります。例えば、イギリスのうちロンドンだけを抽出してインポートしたいなら：

$ osm2pgsql --bbox -0.5,51.25,0.5,51.75 -m -d gis uk-080213.osm.bz2

起こりうる問題

投影法が間違っている

地図のタイルが全て10～20km北か南にずれているなら、たぶんosm2pgsqlのインポート時に"-m"オプションを付け忘れているでしょう。osm2pgsqlのバージョン0.55以降では、球体メルカトル（-m）はデフォルトの投影法になりました。

データファイルを開けない

gzip圧縮された7GB以上のファイルを読み込もうとすると、エラーが発生して失敗するでしょう。これはzlibのバグのために、open()にO_LARGEFILEフラグを渡さないためです。回避策としては、このバグが解消された外部のgzipプロセスを使うことです。ファイル名として"-"を指定すると、osm2pgsqlは標準入力からデータを読み込みます。

gzip -dc planet-080213.osm.gz | osm2pgsql -m -

メモリ不足

以下に似たメッセージが表示されて読み込みに失敗するなら、

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Mid: Ram, scale=100

Reading in file: -
Entity: line 1: parser error : Extra content at the end of the document

^
- : failed to parse
Error occurred, cleaning up

osm2pgsqlをスリムモードで動かす必要があるでしょう。このモードは、中間オブジェクトをメモリではなくディスクに置きます。 スリムモードで動かすには、osm2pgsqlに'-s'スイッチをつけます：

osm2pgsql -m -s -d gis planet-080213.osm.gz

pgSQLでの不正な投影法

次で始まるエラーメッセージが表示されることがあります：

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
SELECT AddGeometryColumn('planet_osm_point', 'way', 900913, 'POINT', 2 );
  failed: ERROR:  AddGeometryColumns() - invalid SRID
CONTEXT:  SQL statement "SELECT AddGeometryColumn('','', $1 , $2 , $3 , 
$4 , $5
)"
PL/pgSQL function "addgeometrycolumn" line 4 at SQL statement

これは投影法が初期化されておらず、osm2pgsqlフォルダにある900913.sqlを実行する必要があるという意味です。 実行するには：

wget http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/900913.sql && psql -f 900913.sql gis

この作業の後、データベースを再起動する必要がありました：

sudo /etc/init.d/postgresql restart

ロックアウト

何時間か経ってからインポートが次のようなエラーで終了するかもしれません：

ANALYZE planet_osm_line;
 failed: ERROR:  deadlock detected
DETAIL:  Process 28511 waits for AccessExclusiveLock on relation 1064115 of database 18309; blocked by process 12776.
Process 12776 waits for ShareLock on transaction 572766655; blocked by process 28511.

Error occurred, cleaning up

このメッセージは、あるバージョンのPostgreSQLで、解析中に自動バキュームが試行されたために失敗したようだ、ということです。解決法は、自動バキュームを無効にすることです。データはインポート後に更新されていないので、バキューム処理は何も役に立つことをしません。postgresql.confでこの設定をするには：

autovacuum = off

その後、データベースサーバを再起動してください。

sudo /etc/init.d/postgresql-8.1 restart

注意：Debian/Ubuntuでは、/etc/cron.d/postgresql-common を更新して2つのpg_maintenanceタスクをコメントアウトする（行頭に'#'をつける）必要があります。これは一定時間ごとにバキュームを実行するためです。

# Run VACUUM ANALYSE on all databases every 5 hours if pg_autovacuum is not
# running
# 2 0,5,10,15,20 * * 1-6 root if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --analyze >/dev/null; fi

# On Sunday you may wish to run a VACUUM FULL ANALYSE as well
# If you do not run a 24/7 site, you may want to uncomment the next line 
# so as to do a regular VACUUM FULL.  If you need 24/7 connectivity, save
# VACUUM FULL for when you think you really need it.
# 10 3 * * Sun root if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --full --analyze >/dev/null; fi

postgresで他に何もしていないのなら、これらを再び有効にすることを忘れないでください。さもなければ、性能はだんだん低下するでしょう。

アクセスが拒否された

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
SELECT AddGeometryColumn('planet_osm_point', 'way', 900913, 'POINT', 2 );
 failed: ERREUR:  droit refusé pour la relation geometry_columns
CONTEXT:  instruction SQL « DELETE FROM geometry_columns WHERE
		f_table_catalog = '' AND f_table_schema = 'public' AND f_table_name = 'planet_osm_point' AND f_geometry_column = 'way' »
PL/pgSQL function "addgeometrycolumn" line 94 at EXECUTE statement
instruction SQL « SELECT AddGeometryColumn('','', $1 , $2 , $3 , $4 , $5 ) »
PL/pgSQL function "addgeometrycolumn" line 4 at SQL statement

Error occurred, cleaning up

ユーザはgisデータベースを更新する権限がありません。osm2pgsqlを実行するユーザはpostgresqlデータベースをセットアップしたユーザである必要があります。

認証に失敗した

postgresにpgsqlコマンドで接続できない場合（例えば、これはUbuntu 9.10とpostgres 8.3で起こります）：

 $ psql -W gis username
 psql: FATAL:  Ident authentication failed for user "username"

ユーザにパスワードを設定した後：

 $ sudo -u postgres -s -H
 postgres@aoeu$ psql 
 Welcome to psql 8.3.5, the PostgreSQL interactive terminal.
 ALTER ROLE username PASSWORD 'mypassword';

以下の記述をpg_hba.confに追加する必要があります（例えば/etc/postgresql/8.3/mainにあります）：

 local   all         all                               trust   
 host    all         all         127.0.0.1/32          trust
 host    all         all         ::1/128               trust

これで、localhostからパスワード認証を使えるようになります。

local allやhost allで始まる部分をコメントアウトする必要があることに注意してください。私はUbuntu 8.10では以下のセクションをコメントアウトする必要がありました：

# "local" is for Unix domain socket connections only 
#local   all         all                               ident sameuser
# IPv4 local connections:
#host    all         all         127.0.0.1/32          md5
# IPv6 local connections:
#host    all         all         ::1/128               md5

解釈できない要素

次のエラーメッセージが表示された場合、

Unknown Element name : changeset

osm2pgsqlを新しいバージョンに更新する必要があります。

Mapnikでのレンダリング

上の手順でダウンロード済みの小縮尺データと海岸線データを展開します：

$ tar xzf world_boundaries-spherical.tgz
$ unzip processed_p.zip
$ mv coastlines/* world_boundaries/
$ rmdir coastlines

上記の作業は全ての図形ファイルをworld_boundariesディレクトリに残します。

MapnikをOSMのsubversionディレクトリからチェックアウトします：

$ svn checkout http://svn.openstreetmap.org/applications/rendering/mapnik
$ cd mapnik

"set-mapnik-env"スクリプトのコピーを手元に作って、ローカルファイル名、データベース名、タイルフォルダの場所などと一致するように編集します。全ての設定項目はこのスクリプト中に書かれています。

osm-template.xmlからosm.xmlファイルを作ります。これは次の手順で行います：

$ source ./set-mapnik-env
$ ./customize-mapnik-map >$MAPNIK_MAP_FILE

（注意：最新版のset-mapnik-envには"export MAPNIK_DBNAME='osm'"と記述があるのですが、先ほどの手順ではDBNAMEを'gis'としています。もしDBNAMEが間違っているのなら、set-mapnik-envを修正してもう一度customize-mapnik-mapを実行してください。）

generate_(tiles|image).pyで矩形領域と縮尺レベルを設定することによって、どの領域が描画されるのかを決めることができます。

これで次を実行できるようになりました。

$ ./generate_tiles.py

generate_tiles.pyは適したサーバで提供されるタイルを精製します。（デフォルトでレンダリングされる領域と縮尺レベルを調べるには、ファイルを見てください。bboxとmin, max zoomです。違う領域を選択したいのなら、openstreetmap.orgを開いて"export"タブをクリックしてください。手動で領域を選択することが出来ます。必要な領域を描画すると、4つのテキストボックスが表示されて[left,bottom,right,top]が表示されます。） マルチコアマシンを使っているのなら、タイルの生成を高速化するために、例えば4つなどに領域を分割して複数のインスタンスが同時に実行することができます。

もしくは

$ ./generate_image.py

generate_image.pyは指定された矩形領域の単一画像を生成します。 すなわち、基本的には複数のタイルを作ってそれらを1つの大きな画像にします。 これは、単に特定の領域を含む画像が必要で、面倒なタイルの扱いをしたくない人には便利でしょう。

タイルに関するトラブルシューティング

タイルのレンダリング時にいくつか起こりうる問題があります：

1. 生成されたタイルや画像が海岸線を表示する場合で、道や道の名前、都市や他の地物がない場合、データベースユーザが確かにログインできるか確認してください。スクリプトやmapnikはデータの読み込みに失敗したときに何もメッセージを表示せず、海岸線だけをレンダリングします。他の原因としては、mapnikのビルド時にpostgisのサポートを有効にしなかったケースが考えられます。
2. 先ほどの2つのスクリプトをsvnの最新版とmapnik 0.5を使っていて、古いバージョンを試そうとすると、いくつかのエラーが表示されるでしょう。（これらのスクリプトは'convert'コマンドを実行しようとします。ImageMagickをインストールするか、'convert'を使わないようにする必要があるでしょう。）
3. アジアの地名が普通の文字でなく箱として表示されるなら、osm.xmlファイルのフォント名を変えてみてください。（set-mapnik-envを参照。）AR PL ShangHeiSun Uni RegularはLinuxではうまく行くようです。これは /usr/share/fonts/chinese/TrueType/uming.ttf にあるでしょう。このファイルをmapnikのフォントディレクトリ（たぶん /usr/local/lib/mapnik/fonts でしょうが、Mapnik Python拡張のpaths.pyを確認してください。）にコピーしてください。

ディスク領域を節約する

地球全体（すなわち、bbox = (-180.0, -90.0, 180.0, 90.0)）をレンダリングしているのなら、いくつか劇的にディスク領域を節約する方法があります。

1. 使う予定のあるタイルだけがあることを確認します。
   1. 例えば、縮尺レベル10における最大のx座標とy座標は1023です。ですので、最後のタイルは TILEDIR/10/1023/1023.png のはずです。
   2. しかし、このx座標、y座標を超えるタイルがレンダリングされることがあります。（私はy座標が1300まであったことがあります。）
   3. それぞれの縮尺レベルで、これらをまず削除してください。
2. 高い縮尺レベル（8かそこら）では、タイルは重複しているでしょう。（すなわち、何もない海や湖、地物のない陸地で。）
   1. サポートしているOSでは、シンボリックリンクを作って1セットの空の水や陸地タイルにできます。

節約する例（私(athlon02)の場合）：

1. 縮尺レベル9では、ディスク領域は3.8GB（メモリが足りているなら）使用されていました。これが今では1.4GBです。
2. 縮尺レベル10では、ディスク領域は最初12～13GBでした。これが今では4.58GBです。
3. 数値自体は環境によって異なるでしょう。

レンダリングをカスタマイズする

カスタマイズするための標準のスタイルシートがあります。

陰影

cyclemapのように、contoursを地図に加えることができます。この陰影はNASAが提供しているパブリックドメインのSRTM (Shuttle Radar Topograhy Mission)を基にしています。同じデータを基にした丘の陰影や標高による色づけを地図に加えることも可能です。

スタイルシート

スタイルシートは地物がどのような見え方になるかを指定するXML文書です。例えば道路の種類によって色や線の太さを変える、といったことです。書式はあまり簡潔ではなく、理解するのは簡単ではありません。しかし強力で柔軟性があります。現在のslippy mapで我々が使っているバージョンは、たぶん次のSVNヘッドにあるosm.xmlでしょう： applications/rendering/mapnik/osm.xml

次のサイトではオンラインでmapnikのスタイルシートを変更して遊ぶことができます： http://tile.openstreetmap.nl/~panman/styledit/

名前が地域化されたレンダリング

標準のnameタグの代わりにname:*があるときにその名前をレンダリングするには、データを前処理するか、postgisデータベースを後から修正することができます。

default.styleをカスタマイズする

例えば自転車道やネットワークデータをデータベースに追加するなど、default.styleを編集しているのなら、osm2pgsqlはカレントディレクトリのdefault.styleを使わないことに注意してください。代わりに /usr/share/osm2pgsql/default.style を使います。

自分でカスタマイズしたdefault.styleファイルを指定するには、--styleパラメータを使う必要があります。 詳しい情報を表示するには osm2pgsql -h を実行してください。