RU:MediaWiki extension

From OpenStreetMap Wiki
Jump to: navigation, search
Доступные языки — MediaWiki_extension
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português português do Brasil română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

Расширение MediaWiki позволяет отображать карты Openstreetmap на вики-страницах веб-ресурсов, созданных на базе движка MediaWiki ( Оба представленных ниже расширения используются как на этой вики, так и на других ресурсах, таких как wikipedia, WikiTravel и др.

О расширении MediaWiki

MediaWiki extensions are bits of php logic which can optionally be dropped into a MediaWiki installation (not by any user, but by the server administrator), to give the wiki new capabilities. Various hooks are available. In this case we are probably most interested in extending the wiki syntax to support a new tag e.g. <map>data|data|data</map> ...which would result in an OSM map appearing when you save the page. See Extending wiki markup


Maps is the MediaWiki extension that provides the ability to visualize geographic data with dynamic, JavaScript based, mapping API's such as Google Maps and OpenLayers in your wiki pages. It has build in support for geocoding, displaying maps, displaying markers, adding pop-ups, and more. Maps allows extensive customization of your maps, either per map, or via a general setting affecting all maps on your wiki.

Due to Maps modular build, modifying the mapping service of a map is as easy as changing a single map property! These mapping services include Google Maps, Yahoo! Maps, OpenLayers and OpenStreetMap. These also allow you to display maps with Google Earth, OpenStreetMaps, Bing maps and others.

As of version 0.5, Maps supports static maps. Static maps are maps in the form of plain images, in contrast to dynamic maps, which reside in a JavaScript mapping API, and allow you to interact in various ways. Working with static maps has several advantages over dynamic maps, including the fact that users don't need to have a client that support JavaScript to view the map.

Semantic Maps

Semantic Maps is an extension built on top of maps, and adds semantic capabilities to it. When using Semantic MediaWiki, it is highly recommended to use Semantic Maps together with maps, since it will make coordinate insertion even easier.

Simple image MediaWiki Extension

There is an extension available to download (well copy & paste) from the Simple image MediaWiki Extension page, which simply puts a map image on the wiki page by referencing the flexible image generating interface created by User:Ojw.

This supports wiki markup of the form

<map lat="51.485" lon="-0.15" z="11" w="300" h="200"|format="jpeg" />

So inside a map tag, you specify parameters 'lat', 'long', 'z' (zoom level), 'w' (width in pixels), 'h' (height in pixels), and 'format'

The extension simply renders an <IMG> tag with the src set to a URL like this one:

Slippy Map MediaWiki Extension

There is an extension available to download as detailed on the Slippy Map MediaWiki Extension page, which embeds an OpenLayers slippy map into a mediawiki article. This was created some time ago by OSMer Harry Wood, but the 'map' extension described above is more feature rich and well maintained by the mediawiki community (but perhaps less OSM-centric)

Although this was obvious enhancement request building on the simple version, slippiness isn't necessarily a good thing. Is slippiness desirable on wiki article (e.g. on wikipedia)? If you're illustrating a textual article, being able to zoom and scroll around with an embedded map is a distraction. A slightly quirky unnecessary feature. Also it's javascript nastiness which is never good for accessibility/browser compatibility. Tim Starling said that to be used on wikipedia, an extension would need to work well in the print mode of the major browsers. It would also need to support a static mode for offline browsing (see It doesn't do this at the moment.

Both tile layers are available: Osmarender, and Mapnik (in theory maplint as well, although this isn't working for some reason) This is an advantage over the simple image extension above. You can't get a Mapnik map as a simple image for example (This is due to the OJW's image generator service only stitching osmarender tiles, because it grabs from the local filesystem on the tah server where it is running)

This links into our tileservers and assumes that we will be able to host the images in this way going forward. How much of this usage pattern can the OSM tile servers cope with? If wikipedia was to use this, they would send tile requests through Wikimedia's squid proxy cluster (OSM would still be the origin server)

Ideas for improvements

Local image caching

The simple image extension creates a straightforward reference to within an <IMG> tag. This is not ideal for several reasons:

A) It puts server load on OSM for other wiki's traffic (include CPU used to generate the image on the fly)
B) OSM's dev server goes down, the other wiki's articles is without a map.
C) OSM's dev machine runs slowly, the maps load slowly on the other wiki's articles
D) Just as a general web design principle, the other wiki typically wants to be hosting all their referenced image resources.

The scale of these problems would depend on how widespread the use of this syntax would be (across how many wikis/articles) a solution which can be fairly simple, is local image caching.

For wikipedia's purposes, they can probably simply send tile requests through wikimedia's squid proxy cluster, which would handle the caching. Other people deploying this extension can do the same (set up their own squid proxy for the image URLs, and modify the extension to reference the proxy)

For other people using MediaWiki without squid proxies, we could provide some logic for local image caching within MediWiki. This would be logic for downloading the image file from the OSM server onto MediaWiki installation (just written to the filesystem?) and then always linking the <IMG> tags to local files. This downloading would happen on the first request (for a particular set of parameter values) and would not need to happen for subsequent requests, except after a timeout of some kind. A longer timeout length would make the caching more effective (less load on OSM, faster response for that wiki's users) but would make the map image potentially less current.

Harry Wood has had a go at building this (code so far is at Cached image MediaWiki Extension), but didn't get to test it yet because php's "fopen" command, which we need to use for programmatically performing the image download, seems to be disabled by default on many apache installations for security reasons.

Providing SVG source

Wikipedia is also interested in hosting 'source' data for images, and then allowing people to make changes to the SVG. This kind of idea might present some workflow problems. Obviously for raw mapping data the user should be referred to OSM. Should wikipedia serve up 'SVG' source files for rendered maps? This would enable contributors to make cosmetic tweaks to the renderings, but how does it fit with bringing in updates from OSM?

MediaWiki's thumbnail facility

MediaWiki supports various nifty bits of syntax for working with images, in particular it allows an image to be thumbnailed on the article page (show a rescaled small version linking to the full size version) just by adding something like 200px into the [[Image]] wiki text. Other options include frames and captions and left/right/center commands.

With the simple image extension, none of these tricks are available. The image appears full size. However this doesn't really matter because, the size of the map image would be dictated by the width/height parameters chosen, and in theory rescaling should never be particularly desireable, since the detail level and text size should be optimised within our rendering logic, to best match the particular zoom level.

Other questions though: Would it be nice to have something similar to 'image pages'? That might tie in well with the idea of having associated SVG resources. What about matching other features of the [[Image]] syntax, such as frames and captions. Or is all that unnecessary complication?

These considerations are largely meaningless with respect to the slippy map extension.


Somebody has already gone to considerable effort to develop something called WikiMiniAtlas for wikipedia, and it is in place already. This is not embedding maps within wiki articles, but providing them as a dropdown feature at the top of the page, for articles which have been geotagged. As such, it's not the same idea as those discussed on this page, and perhaps it doesn't particularly conflict at all. i.e. we'd like both.

We should definitely work with the developers to get our map data represented on there somehow (if not our maps full stop) See also Collaboration with Wikipedia

See Also