JA:MediaWiki extension

MultiMaps

主な記事：Wiki:Maps#Slippy maps地図のインストール時において Composer (software) に問題が発生したことから、 この拡張機能はSlippy Map MediaWiki 拡張機能を置換するものに選ばれました。たいへん基本的であり、地図の表示は Leaflet 枠のみで行います。この OSM ウィキに特化して、タイルのソース表示の切り替えをオプションとして追加しました^[1]が、コードのホスト先が Wikimedia であるため、現実には前述のオプションをどの MediaWiki ウィキでも利用可能です。

この拡張機能は2020年夏から SlippyMap 拡張機能の代わりに導入されました^[2][3]。Template:Slippymap が提供するインターフェースを使うと、この拡張機能の個別の構文を知らなくても地図もマーカも表示できます。注意事項として、ユーザーの皆さんはこの構文を使わないでください。拡張機能の構文が変更されるたび、すべてのページを変更しなければならなくなるか、または新規の拡張機能と置換されます。既にどちらの事例も発生しており、数え切れないページがボットによって書き換えられました。もしも Template:Slippymap が提供していない機能を使いたい場合は、ご自分で拡張するか新しいテンプレートを作成するかしてください。今後、自動処理の大規模な変更を避けるためです。

サンプル:

Kartographer

Kartographer（カートグラファー）はOpenStreetMap の標準的なタイルのレイヤーを表示できないため、導入していません^[4]。ウィキページに Leaflet 地図を挿入するもので、ページ内の文字列から地図上のマーカにリンクを張れます。この拡張機能はウィキメディア財団が開発し、利用先はウィキボヤージュその他のウィキメディアのウィキ群です。

Maps

Maps はslippy maps 全般向きで、メンテナンスが行き届いた機能の多い MediaWiki 拡張機能です。この原稿の段階ではOSM ウィキにはまだ未導入 です。OpenStreetMap の表示に OpenLayers を使います。位置座標、地図の表示、マーカの表示、ポップアップの追加その他の機能があります。Maps では地図の凝った改造が可能で、 Map の機能もしくは全般の機能設定を使い、そのウィキにあるすべての地図を変更します。

Maps は静的な地図つまり単なる画像形式の地図も扱います。対照的に動的な地図は JavaScript 地図表示 API を用いて利用者の操作を可能にします。静的な地図には、動的な地図にはない利点がいくつかあり、そのひとつは、利用者の環境が JavaScript に対応していなくても地図を表示できることです。

バージョン 3.0 以降は Maps のインストールに必要なソフトウェアは Composer ですが、 OSM の採用する Chef management では使えません。2018年10月に OSM ウィキにインストールしようとしてうまくいきませんでした^[5]。

ローカルの画像キャッシュ処理

単体の画像拡張機能であれば、直接的に

<IMG>タグを付与してopenstreetmap.org と紐付けできます。

A) 他のウィキにおけるトラフィックが OSM サーバーに負荷をかける (アクセスにより地図画像を生成するため CPU を使うから)

B) StaticMapLite がダウンすると、他のウィキでは記事に地図が表示されない。

C) StaticMapLite の処理遅延により、他のウィキでは地図の読み込みが遅くなる。

D) 単に一般的なウェブ設計の原則として、他のウィキは参照する画像リソースをすべて自前でホストしたがる。

問題の深刻度は果たしてこの構文の利用がどこまで浸透するか (使用先のウィキや記事の総量) に影響を受けます。わりに簡単な解決策としては、ローカルに画像のキャッシュ処理を実施する方法があり得ます。

ウィキペディアの目的に照らすと、単純にタイルの要求をウィキメディアの squid proxy クラスタ経由で送り、キャッシュ処理を依頼する方法があります。あるいはこの拡張機能を実装する人々も、同じ手順 (画像 URL に対応する自前の squid proxy を立て、拡張機能を修正してプロキシを呼びにいくようにする ) が使えるかもしれません。

MediaWiki の利用者だけれど squid プロキシは使わない場合、私たちから提供して MediWiki 内にローカルの画像キャッシュ処理のロジックを置くことも可能ではあります。具体的には画像ファイルを OSM サーバから MediaWiki インストールへダウンロードするというロジック (書き込み先は filesystem のみ?) で、さらに毎回<IMG>タグをローカルのファイルにリンクさせます。この方法においてダウンロード処理は、初回の (特定のパラメーター値のセットに対する) 要求時にのみ発生し、それ以降には必須ではなくなるか、ある種のタイムアウトを設定する場合は除外するかです。タイムアウトを長めに設定するとキャッシュ処理の効率は向上 (OSM への負担は軽減、先方のウィキのユーザーの待ち時間は短縮) しても、地図画像の鮮度はやや落ちる可能性があります。

Harry Wood からこの構築に承認が降りていた (現状のコードの収納先は Cached image MediaWiki Extension) という事実はあるものの、この原稿の時点ではテスト段階に至らず、原因は php の "fopen" コマンドにあり、画像ダウンロードをプログラム上で実行するために使う必要があるのに、セキュリティ上の理由から apache インストール先の多くでは既定で無効にされているようです。

SVG ソースの提供

ウィキペディアではまた、「画像のソースデータ」収容にも関心を寄せており、それによって人々が SVG に改編を加えることを可能にしようとしています。ただし、この種の発想にはワークフローに問題を生じる可能性があります。生の地図データ側の発想では、ユーザーを OSM へ案内するべきです。ではウィキペディアのサーバーで地図処理用の「SVG」ソースファイルの収容を認めるべきか？ これを認めると、一方で投稿者はレンダリングにちょっとした見た目の改編を追加できるようになるけれど、他方、OSM からの更新との共存をどう扱うのでしょうか？

MediaWiki のサムネール 機能

MediaWiki には画像処理に使えるちょっと便利な構文をいろいろ用意しており、特に記事のページで画像をサムネール表示する構文は (縮小した画像を置いてフルサイズ版の画像にリンク) 、単に [[Image]]ウィキ文に「200px」などサイズ指定を書くだけで実現します。オプションはほかに枠やキャプションの有無、左右中央の配置指定の left/right/center コマンドがあります。

単純な画像用拡張機能を使っただけでは、これらの小技は使えず、画像はフルサイズで表示されます。ただしあまり気にしなくて良いのも事実で、地図画像の表示サイズは選択した幅/高さのパラメーターで決まり、理論上は画像の縮小表示は歓迎されないからで、その理由としては特定のズーム率をベストマッチさせるには、縮小率と文字サイズの詳細は私たちの処理ロジック内部で扱うべきだからです。

それでもまだ疑問が残ります。 もしかして 'image pages' のようなものを設置する方が良いのでしょうか？ それなら関連の SVG リソースを置くという発想とうまく連動するはずです。 [[Image]]構文のその他の機能、たとえば枠線やキャプションも対照させてはどうか。あるいは無用に複雑化するだけでしょうか？

ただし slippy map 拡張機能に関しては、これらの考慮はほぼ無意味です。

WikiMiniAtlas

User:Dschwen によってこれまでに通称 WikiMiniAtlas (ウィキミニアトラス) という体系がウィキペディア向けに開発され、既に活用されています。これはウィキのページの内部 に地図を埋め込むのではなく、位置情報をタグ付けした記事のページ上部にドロップダウン機能として設置するものです。そのためこのページで別途、取り上げている拡張機能とは異なり、機能が衝突するわけでもなく、どちらも OSM に保持したいものです。

今後も開発者と協力して、当然ながらウィキに地図が何らかの形で掲載できるように努力していきます (それがたとえ私たち OSM の地図 ではないとしても)。関連の Collaboration with Wikipedia もご参照ください。

OpenStreetMap データは2012年春時点で WikiMiniAtlas に使用されました。