Исходная статья: MediaWiki_extension. Вы можете закончить перевод.
Если вы знаете английский, то можете помочь нам, переведя часть оригинальной статьи. Общие сведения о переводе статей на русский язык можно найти здесь.
Расширение MediaWiki позволяет отображать карты Openstreetmap на вики-страницах веб-ресурсов, созданных на базе движка MediaWiki (http://mediawiki.org). Оба представленных ниже расширения используются как на этой вики, так и на других ресурсах, таких как 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
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 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.
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: http://tah.openstreetmap.org/MapOf/?lat=51.485&long=-0.15&z=11&w=300&h=200&format=jpeg
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)
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 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.
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