Jeroens blog

Maps and Semantic Maps 0.6.4 are now available for download. This release contains several new features, amongst which basic KML support for Google Maps, a new OSM service implementation and re-added service links support to the Geographical Coordinates data-type in Semantic Maps. Everyone running 0.6.2 or older is advised to upgrade as soon as possible.

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

I’ve been working on Maps and Semantic Maps 0.6, the next big, awesome, release of both MediaWiki extensions, for over a month now. I also released an early alpha on the 3th of April. All planned new features have been implemented, and known bugs from 0.5.x have been fixed. So you might wonder why 0.6 is still not out.

In response to the possibility of someone doing work on Maps and Semantic Maps during the upcoming Google Summer of Code, I took a critical look at the current structure, holding into account all the things I learned over the last two month while working on Storyboard. I came to the conclusion that a bunch of things ought to be handled in a cleaner fashion, and started to refactor this code. The most difficult part here is changing how the display_map and display_point(s) parser functions handle their mapping service parameter and validate the provided location(s). I’ve been wanting to change this since 0.4, but didn’t since it’s rather tricky to do. I decided to finally get this done now, and have done most of the work. To complete these changes, I’ll have to make some rather complex modifications to Validator, which can take a while to complete. That’s the last thing that needs to be done before the 0.6 release though

I estimate this should be done in approximately 2 weeks, maybe sooner. After that I’m planning to release at least one RC, to ensure stability and complete awesomeness, cause really a lot has been changed. I figure about three quarters of the codebase has been changed in one way or another!

After this release a lot of cool new features can be added, which I might do before the GSoC coding period starts. There are also a few people who wanted to do a mapping project for GSoC at the WMF, but did not get accepted, which are planning to do some effort here after all, which is totally awesome

Yesterday I released Maps and Semantic Maps 0.5.4. This is a minor update which mainly brings additional stability and security to the 0.5.x branch. It contains several bug fixes, a few code improvements and some security fixes. Check out the Maps change log and Semantic Maps change log.

The only new functionality is that you can now define OpenLayers layers in your LocalSettings file, as well as layer groups. This is done by modifying the $egMapsOLAvailableLayers, $egMapsOLLayerGroups and $egMapsOLLayerDependencies arrays, which are defined in Maps_Settings.php.

Another noteworthy point is that Semantic Maps now contains all the geographical coordinate format handling that was part of Semantic MediaWiki earlier on. The code has been removed from SMW itself, and the SMW 1.5 release will be the first one without it. A nice side effect of this is that people still using Semantic Google Maps (one of the extensions Maps and Semantic Maps are based on, which is now obsolete (and really should not be used any more!)) will be forced to switch over to Maps and SM if they want to get the latest SMW.

Both extensions now use Validator 0.2.2, which is a minor update to 0.2.1, which was used in 0.5.3.

Downloads

• Maps 0.5.4 [zip, 7z, svn tag]
• Maps and Semantic Maps 0.5.4 [zip, 7z]
• Semantic Maps [svn tag]
• Validator 0.2.2 [zip, 7z, svn tag]

Today I released Validator version 0.2, on which I’ve been working the last 2 days. It features massive rewriting to make it more flexible, and has some added functionality. Let’s have a look at what changed.

The most important change is, without any doubt, the new list support. Validator 0.1 had a list type, which allowed you to have enumerations of values and do crude validation on them. This version now supports lists of a type, instead of seeing list as a type. So you can now create lists of strings, lists of integers, and even lists of custom types you add. This new approach also allows per-item-validation and per-item-defaulting. This means you can set an in_array criteria, which will then be enforced for every value in your list. Closely related to this new form of list support are the new list criteria, which allow you to validate lists as a whole. At the moment the only 2 build in list criteria are item_count and unique_items, but like for regular criteria, you can hook into Validator and add your own.

Another important change are the output formats. Output formats allow you to specify additional formatting that needs to be done with the parameter value, before it is retrieved from Validator. There are currently 6 build in types, which are array, list, boolean, boolstr, string and unique_items, but again you can hook into this list via Validator. The awesome thing about output formats is that it greatly reduces the mess you otherwise have with converting your parameters from user input to true data structures. You can even specify multiple output formats, which will then do their formatting one by one.

Other things brought by Validator 0.2 include some new criteria (is_boolean, has_length and regex), a new error level, Validator_ERRORS_MINIMAL, new parameter types (boolean, number and char) and support for Validator_ERRORS_WARN in ValidatorManager.

Equally important as the changes made is that the documentation has been completely updated, to give in-depth cover of how Validator works, and how you should use it.

Both Maps and Semantic Maps 0.5.1 use Validator 0.2, allowing them to throw away a lot of repetitive, dumb manipulation, code that has been their since the initial versions of those extensions

Downloads:

• Validator 0.2 (zip)
• Validator 0.2 (7z)
• Validator 0.2 SVN tag

Earlier today, versions 0.5 of Maps and Semantic Maps where released. Some mayor new features where added, and a whole bunch of things have been refactored. I also did some effort to improve the documentation by adding some screencasts and revising the developer docs. Version 0.4.2 proved to be pretty stable, since only 2 bugs have been found and fixed.

Let’s have a look at the new, awesome, functionality:

• Strict parameter validation which allows you to get specific errors or warnings when entering invalid values or parameters. This functionality is obtained by relying on the Validator extension, which saw it’s first release today. This makes Maps dependent on Validator. Every distribution of Maps does include Validator, and Maps will automatically load Validator when it’s not loaded yet, so no extra installation work is required (unless you get the code from SVN).

• Static map support makes you able to display maps as plain images instead of via a JavaScript (or other non-html language, for example flash) mapping API. This is very important since it makes viewing the maps possible for people who are browsing the web with a browser that does not support JavaScript (or this other language), or simply have it disabled for some reason.

• Added a query printer that handles the osm result format.

• Added support for GUI parameter selection of Yaron’s new version of SMW’s Special:Ask page to the query printers.

• Added smart ‘autopanzoom’ like control for Google Maps and Yahoo! Maps.

• Added internationalization to the OSM service, and an extra parameter to define per-map languages.

The list of all things that have been refactored is rather long, so I’ll only cover the most interesting things here:

• Complete rewrite of the parameter handling. To make Maps work with Validator, this was required. The result is that Maps does not have a whole mess of specific validation and defaulting functions any more, since that’s now handled by Validator.

• Moved the geographical coordinate data type handling from Semantic MediaWiki to Semantic Maps. This will make the SMW codebase smaller by moving the geographical coordinate data type out, which is logical, since if you use coordinates, you very likely also want maps.

• Added code to unload any services from the service hook that are not present in the list of allowed services. This ensures they don’t get initialized, and makes any check to see if the service is one of the allowed ones further on unneeded.

As for documentation, I created 2 screencasts, both covering a different aspect of Maps. This way people can learn how to work with Maps in a more interactive way then just reading the documentation.

• Screencast: display_map

• Screencast: display_point

The developer documentation on how you can extend Maps using it’s hooks has been completely rewritten. This was needed since the previous version was created for Maps 0.3.3, since which a lot has been changed to the hook systems of Maps.

For a complete list of changes, see the Maps change log, and Semantic Maps change log.

Downloads:

• Maps 0.5 (includes Validator 0.1) [zip, 7z]
• Semantic Maps 0.5 [zip, 7z]
• Maps and Semantic Maps 0.5 (includes Validator 0.1) [zip, 7z]
• Maps 0.5 SVN tag
• Semantic Maps 0.5 SVN tag

It has been over a week since I posted about any MediaWiki stuff, which can very well be a record since I started my blog. The reason for this is cause I’ve been busy with a lot of projects. You’ll hear about them all later on, but now I just want to provide an overview of the work I’ve been doing on my new MediaWiki extension: Validator.

Validator is an extension that makes parameter validation functionality available to other extensions. This enables other extensions to validate parameters, set them to their defaults, and generate error messages, while only defining the parameters and their criteria. The goal of this extension is to facilitate the handling of parameters in other extension, and generalize the error output. By itself, it does not add any functionality to the user end.

The main functionality is:

• Parameter validation: Parameters that are provided in an array where the keys represent their name, and the values their value, can easily be validated against a set of criteria. During this validation, errors and their types will be stored, and invalid parameters will be separated from valid ones. The only thing an other extension needs to do is define the criteria to validate against. A set of criteria types (which include check to see if something is a number, is within a range, or in an array) is provided by Validator, and can be used without any extra coding. When a criteria type that is not supported is required, you can hook into the Validator criteria types and add your own validation functions.

• Default value handling: Parameters that are invalid, or simply not provided, can be set to their default values. These default values need to be specified by the extension the parameters belong to.

• Error handling: Since the errors and their types are stored during validation, you can create error messages by retrieving this data and parsing it. Validator also provides a manager class that can provide you with a list of internationalized and specific errors. Via a validation level setting Validator provides, you can determine how the errors should be reflected on your wiki page. This can go from completely ignoring any errors to showing a complete list of all errors underneath the regular output, or even hiding the regular output and only showing the errors.

Validator has not yet been released, but will be soon. Although not all documentation is ready yet, most of the information needed to use it can already be found in the implementation section of the documentation. Both the development versions of Maps and Semantic Maps are currently using Validator for their parameter handling. The next release of those extensions, 0.5, will therefore feature strict parameter validation, and be dependent on Validator.

Oh, and I got the 60000th MediaWiki commit with the changes I made to Maps to work with the last alpha of Validator – wooot!

One of the big new features in Maps 0.5 will be strict parameter validation. This means Maps will allow you to get specific errors or warnings when entering invalid values or parameters.

The setting determining the strictness of the validation, which can be changes in your LocalSettings file, currently accepts 4 values:

• Maps_ERRORS_NONE : Maps will not show any errors, and make the best of the imput it got.
• Maps_ERRORS_WARN : Maps will make the best of the imput it got, but will show warnings for omitted coordinates.
• Maps_ERRORS_SHOW : Maps will make the best of the imput it got, but will show a list of all errors.
• Maps_ERRORS_STRICT: Maps will only show a map when there are no errors, if there are, a list of them will be shown.

The underneath example demonstrates an error list that can be generated when the validation level is on Maps_ERRORS_SHOW or Maps_ERRORS_STRICT. In case of the former, it’ll be shown below the map,while in case of the later, it’ll be shown instead of any map. The error messages are of course fully internationalized.

The validation is done via a new class dedicated to parameter validation. To be able to validate anything, you need to feed it two things: an associative array containing the raw parameter names and their values, and a somewhat more complex, nested, array containing the allowed parameter and their meta data, such as aliases and default values. The class also provides a hook for validation types, allowing you to do specific or complex validation that is not build in. The handling of the different strictness levels and generation of the actual error messages is done by another class that uses the first to validate and get the errors. Both classes do not contain any Maps specific code, so can be used to validate the parameter of any parser function. I’m planning to split this code, after it has reached a beta level, into a separate extension, that will probably be named “Validator”. This extension will be bundled with Maps, and will not any additional steps to the installation process.

Together with implementing this new feature, I did a big overhaul of the parameter handling in Maps and Semantic Maps. Instead of the two level system, containing general parameters, and service specific parameters, that was used in Maps, there now is a four level system. The first level are the general parameters, shared by everything. These include things like width, height and zoom. Feature specific parameters make up the second level, while the third one holds service specific parameters. The last level are the parameters specific to a combination of service and feature. Maps goes through these levels, starting with the upper one, and overriding it with the following. This allows more specific behaviour and is required to be able to validate the parameters in some instances.

The changes I made to Maps and Semantic Maps during these rewrites are responsible for what are probably my biggest commits to both extensions yet.

• Changes to Maps (rev 59531)
• Changes to Semantic Maps (rev 59532)

Due to the extend of changes I made, and the lack of thorough tests yet, I expect multiple issues with this code, including several severe ones, so I advice against using the latest SVN code for the moment, except for testing purposes of course. I hope to have the code refined and bug hunted in the coming week, so I can put it in a new extension and release it. During this period I’ll also start working on the other new features planned for 0.5, so you can expect more news on this soon.