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. Extensions like this technically could be even be used on wikipedia, and/or various other interesting wiki-based projects such as WikiTravel or Wikivoyage.
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
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. Probably should be though. It defaults to google maps, but can also 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 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.
Semantic Maps is an extension built on top of the above 'maps' extension, 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.
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)
Described at Extension:Mapsources; this allows a link like Special:Mapsources/lat,long to point to a special page which links to various map sites and (optionally) displays an OSM / Leaflet slippy map. Primarily used by Wikivoyage.
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) 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.
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.