Let’s have a look at all the new awesomeness:

Google Maps v3 support

Maps has had some very basic support for Google Maps v3 since version 0.5.3, back when the v3 API was still in beta. Right now the v3 API is out of beta, and the v2 one has been deprecated a few months back, so it was definitely time to further implement support for v2. This new version of Google Maps brings many improvements, focusing mostly on performance (loading speed of the maps, esp on mobile devices), but also several other cool things such as streetview support and easy adding of layers such as traffic. Since the v2 API has been deprecated it makes only sense that the default mapping service in Maps has changed from Google Maps v2 to Google Maps v3. It’s not really a new feature, but awesome nonetheless: you don’t need an API key for Google Maps v3! So when setting up Maps on a new wiki (using Google Maps), you won’t have to bother with any API key configuration any more, it’ll just work Support for the former is still there, so if you want to retain the exact same functionality as you have with v0.7 of Maps (or earlier), you can still get those maps using service=googlemaps2 (or format=googlemaps2 in SMW queries). One feature has been removed from the v2 implementation, which is the overlays control. This has to do with internal changes and performance optimizations discussed later on in this blog post. Be sure to check out the Google Maps v3 Maps documentation to discover all the cool features it supports.

Improved form inputs

Since it’s first release Semantic Maps has had form inputs using Google Maps v2, Yahoo! Maps and OpenLayers. These inputs allow for entering geographical coordinates in Semantic Forms forms via a nice GUI with a map and an option to geocode an address. Nothing much has changed to these inputs since that initial release, until now. All input, including a new Google Maps v3 one, now have a “set location” button next to the coordinates box, which sets the map to that location, as was already the case with the geocoding button next to the address field. Some minor layout improvements have also been made, and hitting enter in the coordinates or geocoding fields will result in what you’d expect, rather then submitting the form. The OpenLayers form input now also supports geocoding, making use of the new GeoNames API; more on that later.

Use of the MediaWiki resource loader

MediaWiki 1.17 introduces a resource loader for JavaScript and CSS, which both Maps and Semantic Maps now make use of for all their JS and CSS resources. The resource loader does several neat things, the most important thing being delaying loading (and execution) of resources until after page load as well as combining and minifying them, which is very important for performance (page load time). This means that when you have over 9000 maps on your page, it’ll actually load before protons decay away, initially showing only gray boxes where the maps should be, and then one-by-one loading the maps into them. The resource loader does several other cool things, such as automatic right-to-left conversion of CSS and neat conversion of i18n messages from PHP to JS. Making use of the RL when available but at the same time retaining compatibility with pre-RL MediaWiki turned out to be a bit difficult and it would greatly complicate the code, so I decided to simply not do this. This obviously means you will need MediaWiki 1.17 in order to use (Semantic) Maps 0.8.x and later. Can’t use 1.17 yet for some reason? Don’t panic! I’ll continue to support the 0.7.x for a while longer, fixing bugs as they are found. Don’t expect any new features there though.

Support for the new GeoNames API

Maps has a new geocoding service: the new GeoNames API. It already had support for GeoNames, but it seems this service is now only offered as legacy support. (I’m not completely sure about this, if someone better familiar with the service knows, please poke me.) A big change with the new service is that you need a GeoNames API account to use it, which you can create here. You then need to set your accounts user name in your LocalSettings.php file. Maps still has the ‘geonames’ service as default for #geocode and OpenLayers maps. If you set the account name, the new service will be used, if not, Maps will fall back to the old one, so you can upgrade to 0.8 without geocoding suddenly failing because you don’t have a GeoNames account. For more info see the GeoNames documentation for Maps.

JavaScript overhaul

Similarly to the form inputs in Semantic Maps, all the JavaScript in both Maps and Semantic Maps has seen quite little attention since the initial releases of the extensions. Many additions have been made to add new functionality, but the structure has remained the same ever since. All of it has now been rewritten to jQuery plugins, making it a lot more orderly and easy to extend.

More internal improvements

Not only the JavaScript has seen significant improvements, but some legacy code has also been thrown out of the PHP, making it a lot less complex, more easy to track the code flow and definitely makes it easier to add new functionality. This rewrite is very much a follow up to internal improvements made in versions 0.6, 0.7 and 0.7.3, and completes getting rid of some bad old architecture in the core Maps code. Future releases will therefore most likely focus a lot more on simply adding new features

And more…

For a full list of changes, see the release announcement. These do not list the huge amount of internationalization updates and small improvements made by a lot of contributors by reporting issues and providing patches. Thanks to all!

How stable is it?

A lot of internal changes have been made, but at the same time, most of these have been made about 3 months back. Several wikis have been using alpha versions of 1.0 ever since, and a release candidate was made a few days back. Since there are no known issues at this point, I decided to release 1.0. So yes, it should be pretty stable, although you might run into minor issues with less frequently used components. If you do, please report it, so they can be addressed quickly in a 1.0.1 release.

Legacy support for 0.7.x

As an extension developer and MediaWiki consultant, I’m quite aware that a lot of people are not in positions to update their MediaWiki to 1.17 just yet, preventing them from upgrading Maps and Semantic Maps. For this reason I decided way back when starting the development of version 1.0 to continue limited support of version 0.7.x for a while. Versions 0.7.4 to 0.7.7 have been released especially for this purpose, and I’ll continue to backport important fixes. Don’t expect any new features to show up for 0.7.x though.

What’s next?

Although the current set of functionality is pretty solid, there are many other geographical features one can imagine. Features such as marker clustering, static maps, route plotting (without the use of KML), ect, have been on the wishlist practically since the inception of the Maps extension. There is nothing really standing out for me enough to go ahead and implement it in my free time. If any such feature is important to you and you can fund it’s development, definitely contact me. Of course I’ll continue to support the extension and make fixes where needed.

The Semantic MediaWiki 1.6 release will be followed by a new Semantic Bundle, which will include this new version of Maps and Semantic Maps.

Downloads

• Maps 1.0 (archive)
• Maps 1.0 (svn tag)
• Maps and Semantic Maps 1.0 (archive)
• Semantic Maps 1.0 (svn tag)

• Maps 0.7.7 (archive)
• Maps 0.7.7 (svn tag)
• Maps and Semantic Maps 0.7.7 (archive)
• Semantic Maps 0.7.7 (svn tag)

Referata, which runs the documentation wiki for the mapping extensions has upgraded to version 1.0, so you can have a look at and try out the new features yourself on the example/demo pages.

Version 0.7 of both the Maps and Semantic Maps extensions is now available for download. This release is made after 3 beta’s and a release candidate, so should be stable.

The most notable new features in this release are tag extension support for all the Maps parser functions, more consistent error handling via Validator 0.4 and compatibility with the upcoming MediaWiki 1.17. Most changes are internal improvements, but there are also several bug fixes and minor new features.

Whats next?

There only big new feature on the roadmap for 0.7.x is the infamous images-as-layers one. This feature was supported by the now long obsolete Semantic Layers extension (example), and has been requested by dozens of people since the first releases of Maps. Next to fixing the bugs that show up, the focus will mainly be on adding new functionality. Feel free to propose new features, or help out creating them.

Both extensions need some more polishing work before the 0.7 release, some testing needs to be done, and some small new features might still be added. This is a list of changes so far:

Maps

New features

Tag support for these parser hooks (which previously only had parser function support):

• Coordinates
• Distance
• Finddestination
• Geocode
• Geodistance

Bug fixes

• Fixed compatibility with the MW 1.17 resource loader.
• Fixed i18n issue with the overlays control for Google Maps v2 maps.
• Fixed default zoom level for Yahoo! Maps maps.
• Increased the maximum decimals for DMS coordinates from 2 to 20.

Removed features

• #geocodelong and #geocodelat parser functions – you can obtain their functionality using #geocode.

Internal improvements

• Rewrote the geocoding functionality. It’s now an integral part of the extension that can not be just pulled out, while the reverse is true for individual geocoders. Geocoder interaction now uses the same model as mapping service interaction.
• Use of Validator 0.4, allowing for more robust and consistent error reporting.
• Rewrote the parser hooks to use the ParserHook class provided by Validator.
• Restructured the directory structure of the extension to better match it’s architecture.

Semantic Maps

New features

• Added ‘locations’ parameter to the map query printers that allows for displaying static locations in addition to query results in queries. It behaves the same as the locations parameter in display_points.

Semantic Maps displaying the result of a query on an OpenLayers map together with a static point.

Bug fixes

• Fixed compatibility with the MW 1.17 resource loader.

Internal improvements

• Use of Validator 0.4, allowing for more robust and consistent error reporting.
• Restructured the directory structure of the extension to better match it’s architecture.

Notice

Although the big features should work, this release will probably contain multiple issues. Please report any you might find.

For the most current version of this announcement, see the original on the mapping wiki.

A lot of improvements have been made to the documentation as well. Both the Maps examples and Semantic Maps examples are now comprehensive and complete. There now are finally examples of using query templates, of distance queries and of some nice compound queries. Some more work is needed though, a lot of which is explaining basic functionality and fixing minor issues all over the place. I’ll be taking care of the most important things, but I’d be great if people using the extensions could help me out improving the documentation

This release is probably the last one before 0.7, in which I expect to be focusing on new functionality. I’m looking for people that want to fund the development of new features, so please contact me if you are such a person

Downloads:

• Maps 0.6.6 zip archive
• Maps 0.6.6 7z archive
• Maps and Semantic Maps 0.6.6 zip archive
• Maps and Semantic Maps 0.6.6 7z archive

This release is notable for it being the first one in which I’m happy with the code-base as a whole. It took me a year to get here, but now I think the way the mapping extensions work is good and solid. This means you can now extend Maps and not be afraid the code will be incompatible in a few weeks due to changes. This also means that I’ll be focusing more on actual functionality rather then refactoring in future releases. I’ll be progressively building a little guide that explains how the extensions work from a developers perspective and how to extend them.

I might release another minor update in the 0.6.x series if any significant issues are found in 0.6.5. Further plans are finishing up a bunch of changes I’ve started to make in Validator, which I’ll probably release as 0.4 then, and to start working on Maps and Semantic Maps 0.7, which would aim at adding new features and improving existing ones. A likely new feature I’m particularly looking forward to implementing is several tag extensions that do the equivalent of the current parser functions added by Maps. The timetable for all this depends a lot on which other things I get cough up in (I’ll probably continue putting effort into the deployment stuff for my GSoC project) and what kind of funding will be available.

Downloads:

• Maps 0.6.5 [zip - 7z]
• Maps and Semantic Maps 0.6.5 [zip - 7z]

You can also view the release announcement at the documentation wiki.

Lets have a closer look at some of the changes:

• The Google Maps (v2) service now has a KML parameter, which allows you to specify one or more KML files to use. Files are separated with comma’s. The base for this feature was submitted by Andy Chow, who created it for Transit Unlimited wiki. A neat example of a map there using KML is this one. Thanks for the patch Andy!
• There again is an OpenStreetMap service, although this one is different from the one that got removed in 0.6. The implementation is done by embedding (in an iframe) a page from the WMF toolserver, which renders a map with OSM tiles and Wikipedia overlay. Example. It’s basically the same what’s done on the German Wikipedia. Credits here go to Tim Alder and all other people who are making the awesome toolserver stuff work. The reason the creation of the map is not done on the server running the MediaWiki installation itself is that it’s rather difficult to fetch the Wikipedia layer from the toolsever. Hopefully a solution is found for this, as that would be a lot cooler for non WMF usage.
• I re-added service links support for the Geographical Coordinates data-type in Semantic Maps after someone requested this. It got removed in 0.6, as the old implementation was not working anymore, and I was unsure at that point how to create a new one. You can find the updated documentation on this here, although the examples are not working yet (semantic-mediawiki.org is using an alpha of 0.6). I will migrate the examples to the mapping documentation wiki at some later date.
• OpenLayers i18n (translation of the controls) should now be working. A style fix has also been made which caused OpenLayers to render badly in Chrome.
• Multiple small bugfixes have been made in both extensions, and a few in Validator. I guess this is now be the most stable release to date yet, so be sure to upgrade!

For a full list of changes since 0.6.3 see changes to Maps and changes to SM.

Downloads

• Maps 0.6.4: zip, 7z
• Maps and Semantic Maps 0.6.4: zip, 7z

See also

• The release notes on the documentation wiki

Andy Chow

A new release of Semantic Bundle, which will include these versions of the mapping extensions, is likely to soon be released as well

Downloads

• Maps 0.6.3 (7z)
• Maps and Semantic Maps 0.6.3 (7z)

See also

• The release notes on the documentation wiki

This release contains improvements to parameter handling, case insensitivity has been re-added, and using default parameters together with named ones will work more intuitive. In Maps the handling of distances has also been considerably improved: there is a new #distance parser function, additional distance related parameters in #geodistance, and new settings that allow you to customize the default distance behaviour. In Semantic Maps a rather important bugfix has been made which solves a problem with editing articles with forms that contain maps that arose in 0.6.1. (changes to Maps, changes to SM). People running 0.6 and 0.6.1 are advised to upgrade. Especially people using Semantic Maps in conjunction with Semantic Forms, as both 0.6 and 0.6.1 contain undesired behaviour in the forms.

Read this announcement on the documentation wiki

This is a big update, including a lot of new features, bug fixes, security patches, and most of all, internal improvements, making both extensions more modular and extendible (these changes are not covered here, see the relevant change logs for more info). It is also the first release of Semantic Maps that requires you to run the SMW update script, as it requires a new table layout to store coordinates (more info on this).

Let’s have a look at the various new features.

• Maps now supports real coordinate parsing and formatting, which allows you to input coordinates in any of the supported notations at any point in the extension, and can also request any output to be in the notation of your choice. This means you can now choose what format Semantic MediaWiki shows coordinates in, such as in ask queries. The supported notations are DMS, decimal degrees, decimal minutes and floats. All those can be either directional or non directional. A new parser function has been added that allows you to convert between any of these formats: #coordinates.

• New geographical functions: #geodistance and #finddestination. You can use the #geodistance parser function to calculate the geographical distance between two points, from and to any of the supported formats. The #finddestination parser function can be used to find a destination given a starting point, an initial bearing and a distance.

• Related to the new geographical functions is a rewritten distance query in Semantic Maps. It now takes into account performance and is scalable, which the old query was not, by using the new storage structure for coordinates. The notation for distance queries has also changed. Instead of using the like operator and a global distance parameter ( like #ask:[[Property: :~coordinates]]|distance=42 ) you now only have to specify your distance locally in the coordinate criteria itself like #ask:[[Property: :coordinates (42 km)]]. Like you can see you can now also specify a unit, which can be any of the supported ones.

• Support for various width and height notations. Previously Maps only accepted width and height values is px, forcing you to use maps of fixed sizes. Since most people want to have their complete page width visible even on small screens, this resulted in a lot of people using rather small maps, and so wasting screen space. 0.6 allows you to specify the size in px, ex, em, and most importantly, in %. The syntax is what you’d expect: width=”420px”, width=”420em”, width=”42%”. width=”420″ will default to using px, so is backward compatible. When using the % values, maps will even adapt their size when the screen width or the height of the container they are in is changed after the page has loaded

• Not a new feature, but rather one that’s removed: OSM support. The OSM service has been completely removed from Maps and Semantic Maps as it was rather broken and not easy to upgrade to the internal structure of Maps 0.6. I’m planning to add it back later on, rewritten from ground up, in 0.6.1 or 0.6.2 or so. Note that you can still view OSM maps on your wiki using the OpenLayers service, which has build in OSM layers, and also allows you to define your own layers since 0.5.5.

• And many more

The most notable bugfixes are:

• Fixed conflict with prototype library that caused compatibility problems with the Halo extension.
• Added automatic icon image sizing for Google Maps and Yahoo! Maps markers.
• Various security fixes, mostly preventing XSS attacks.

If no serious bugs are found in this release, a minor update can be expected in a month or so.

View announcement on the mapping wiki.

Downloads

• Maps 0.6 [ zip, 7z ]
• Maps and Semantic Maps 0.6 [ zip, 7z ]