The OpenStreetMap MediaWiki extensions allow our maps to be placed on a page of a wiki, on any installation of MediaWiki (http://mediawiki.org) where the extension has been installed. Two of the extensions below, were created for and installed on this wiki.
- 1 About MediaWiki extensions
- 2 Installed extensions
- 3 Suggested map extensions
- 4 Ideas for improvements
- 5 See Also
About MediaWiki extensions
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
(An overview over all installed extensions can be found here.)
|This extension does not work properly any more. We currently seek replacement (see #MultiMaps).|
Installed on this wiki, this extension is also available to (well copy & paste) from the Simple image MediaWiki Extension page. It 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: http://staticmap.openstreetmap.de/staticmap.php?center=51.485,-0.15&zoom=11&size=300x200&maptype=mapnik
Installed on this wiki, this extension is also available to download as detailed on the Slippy Map MediaWiki Extension page. It 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)
Both tile layers are available: Osmarender, and Mapnik. 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)
Suggested map extensions
Kartographer inserts a Leaflet map onto a wiki page. You can link text on the page to markers on the map. This extension was developed by the Wikimedia Foundation and is used on Wikivoyage and other Wikimedia wikis.
Maps is an up-to-date well maintained and feature rich MediaWiki extension for slippy maps in general. It is not installed on this wiki at the current time. It can display OpenStreetMap via OpenLayers. It has build in support for geocoding, displaying maps, displaying markers, adding pop-ups, and more. Maps allows extensive customization of maps, either per map, or via a general setting affecting all maps on the wiki.
After experiencing problems with Composer when trying to install Maps extension, we went for this extension. It is very basic, allowing the display of maps with a Leaflet frame only. Currently, we try to add the ability to choose from different tile servers so that it can replace the current extensions soon. GitHub issue WikiMedia Phabricator
Ideas for improvements
Local image caching
The simple image extension creates a straightforward reference to openstreetmap.org 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) StaticMapLite goes down, the other wiki's articles are without a map.
- C) StaticMapLite 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.
User:Dschwen 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
OpenStreetMap data is being used in the WikiMiniAtlas as of spring 2012.