BN's blog

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 Maps and Semantic Maps 0.5.3. Both releases mainly include bug-fixes, some of which quite important:

• Fixed JavaScript bug causing all OSM maps to fail. Pretty important yeah
• Fixed issue causing a fatal error when executing a query on Special:Ask with the “map” format.
• Fixed issue causing PHP warnings with the type and types parameters in the Yahoo! Maps form input.
• Fixed OpenLayers form input projection bug, causing the the coordinates to be wrongly interpreted. The amazing thing about this bug is that it has been present since somewhere between 0.3 and 0.3.3, without anyone reporting it. It was caused by an error in coordinate conversion between regular and spherical Mercator projections.
• Fixed marker display for the OpenLayers form inputs.

I also discovered an oversight in the hook system of Maps, which is kind of a dormant bug, that could have caused errors for certain implementations of extensions to Maps. The oversight was that a mapping service does not necessary support a sub feature, like the parser function display_point, of a feature, like the parser functions. A check is now in place, together with a defaulting mechanism that also allows you to set the default per sub feature. I’m planning on changing this to a more recursive algorithm in the future though.

A last change is the adding of initial Google Maps v3 support. It’s only implemented for the display_map parser function, and has a rather limited set of customisation parameters at the moment, not to forget a whole load of issues. My conclusion from trying to implement this is that the GMaps 3 API is definitely not in it’s final state yet, since it’s lacking vital methods needed for basic functionality. The support for GMaps v3 is therefore sort of an alpha release, and won’t be put on the documentation page until it’s more stable and complete.

Downloads

• Maps and Semantic Maps 0.5.3 (zip)
• Maps and Semantic Maps 0.5.3 (7z)
• Maps 0.5.3 SVN tag
• Semantic Maps 0.5.3 SVN tag

As you can see, I changed the location of the releases from my forums to 2 brand new Google Code projects [ Maps, Semantic Maps ].

It’s been quite a while since the last release, but 0.5.2 is finally here! It’s not a big release, but features quite some fixes and improvements in the area of marker and pop-up layout.

You can now specify the icon to be used for all markers for both display_point(s) in Maps and result formats in Semantic Maps. A template= and showtitle= parameter have been added to the result formats as well, allowing you to remove the title from a pop-up, and further specifying what should be shown, in which format, by using templates.

On this map you can see that several markers use different icons. This is now easier then in previous versions due to a bug fix.

This map is created by Semantic Maps by querieng some demo data on my wiki. The title of the location is hidden by setting showtitle=no, and the template parameter is used to have a nice little text with the queried data in it as pop-up, contents.

Downloads

• Maps and Semantic Maps 0.5.2 (zip)
• Maps and Semantic Maps 0.5.2 (7z)
• Maps 0.5.2 SVN tag
• Semantic Maps 0.5.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

Yesterday I released version 0.4.2 of both Maps and Semantic Maps. Apart from the version number, this release includes some interesting changes.

As resided in my previous post, Maps now supports Google Maps overlays. Another change in it’s usage is that Maps now holds into account the coordinate and address naming of the main parameter. Although both these and the default (nameless) parameter are basically the same, and all indicate the locations that should be indicated (or shown) on the map, they get handled differently with respect to the new (since 0.4) smart geocoding feature. Here you have an overview of the different behaviours:

• Default (nameless) parameter: Maps will check every item in the list, and determine whether it’s a coordinate or not. In case it’s a coordinate, it’ll be parsed as a coordinate, and in case it’s not, Maps will attempt to geocode it. When this geocoding fails, you will get an error saying the item could not be geocoded.
• Coordinates parameter. As you probably expect, this parameter expects and only accepts coordinates. It works pretty much the same way as it did before 0.4 in display_point. When an item is not recognized as a coordinate, you’ll get an error saying it’s not a valid coordinate and has been omitted.
• Address(es) parameter. Similar to the coordinates parameter, this one expects and only accepts addresses. It works pretty much the same way as it did before 0.4 in display_address(es). Maps will attempt to geocode every item, and show an error listing all items that could not be geocoded. Important to note here is that Maps does not checks for coordinates, and will attempt to geocode any provided ones, valid notation or not, resulting in an error message.

Version 0.4.2 includes a lot of important bug fixes, and is more a release aimed at stability, then at adding new features. Depending on the amount of issues to be discovered in the coming weeks, a version 0.4.3 might be released before 0.5.

Downloads:

• Maps 0.4.2 (zip, 7z)
• Semantic Maps 0.4.2 (zip, 7z)
• Maps and Semantic Maps 0.4.2 (zip, 7z)
• Maps 0.4.2 SVN tag
• Semantic Maps 0.4.2 SVN tag

I’ve just released Maps and Semantic Maps 0.4.1.

These new versions mainly increase the stability of both extensions and address a few minor, but very annoying bugs. The only new feature is that the centre parameter for the map result formats and map form inputs in Semantic Maps now support the smart geocoding that was added to Maps in 0.4.

Downloads:

• Maps 0.4.1 (zip, 7z)
• Semantic Maps 0.4.1 (zip, 7z)
• Maps and Semantic Maps 0.4.1 (zip, 7z)
• Maps 0.4.1 SVN tag
• Semantic Maps 0.4.1 SVN tag

Last weekend I attended Semantic MediaWiki Camp (SMWC) 2009 in Karlsruhe, Germany. Both days of the event contained very interesting presentations about SMW and various related extensions. The most exciting aspect of the event for me was perhaps getting to know other SMW developers, including Markus Krötzsch and Denny Vrandecic, the two lead SMW developers. And of course, I finally met Yaron Koren, my GSoC 2009 mentor, which was really nice. He also brought my long awaited Google T-shirts – yay!

On Saturday, I gave a presentation about Maps and Semantic Maps, after which I did get quite some nice feedback about the extensions. I also got some interesting proposals for new functionality.

During the two nights I was in Karlsruhe, I stayed at Robert U, a student working at Ontoprise, the company hosting the event, his place, sparing me the rather expensive hotel costs.

This picture is from during one of the first talks. Yaron is explaining Semantic Forms. I’m the guy with red training right in front of the camera.

It’s been almost 2 months since Maps version 0.3.4 was released. Although I did waste a lot of my time at school, I managed to get quite some important work done in that period. Version 0.4 mainly addressed new functionality, and some thorough refactoring for Maps, and only introduced 2 bug fixes for Semantic Maps. So lets have a look at everything that changed

New features

• I added a display_map parser function, that’s obviously meant to display maps. The code handling this parser function is optimized to display maps, and does not hold into account any possible markers, ect. The main reason for adding this function is that it’ll be used for the Wikimedia Foundation implementation of Maps.
• Smart geocoding support. Maps is now able to determine if a value is a set of coordinates, or an address. This enables automatic geocoding of addresses, making the specification of the value type unneeded, and allows you to mix coordinates and addresses in location lists. This functionality is implemented for display_map’s default parameter, the one of display_point(s), and display_point(s) centre property.
• OpenStreetMap service. This service uses OpenLayers to display OpenStreetMap tiles. It’s optimized for OSM, and does not allow you to display other tile sources with it. This is another of the requirements for WF usage that’s now been completed. This service is only implemented in Maps ATM, and will be added to Semantic Maps in version 0.5.
• Support for DM (Decimal Minutes) and DD (Decimal Degrees) coordinate notations. Someone requested these to be added. Several other variants, such as GPS coordinates, might be put into Maps in the future.
• Added a setting specifying the minimum and maximum width and height of maps. When a value falls out of this range, it’ll be changed to the nearest allowed value. This is to prevent post-stamp or wallpaper maps, and is inspired by the similar functionality in the SlippyMap extension.
• Parsing of marker-specific title and label values. I actually marked the lack of this feature a bug a while ago, which I changed at the point where I remembered I simply did not add such a thing yet, and only map-wide title and label value’s got parsed.

Refactoring (“under the hood” changes)

• A new hook system for the parser functions, allowing the adding or removing of additional parser function support. Each mapping service will now have one class for handling on specific parser function. Again, the main reason behind this change is that it’s required for the WF usage of Maps, where at the start, only display_map will be used. Another great advantage is that you can now very easily add new parser functions without having to mess up the core extension code. An example of such a function is display_route, which might be added at some point to maps.
• Change the geocoding functionality into a true feature hook element, so it can be easily removed. This is not easy to do, since the geocoding functionality is currently used at various points by the parser functions. So before I can start making it a feature hook element, the parser function code will have to be restructured.
• Create service hook for the geocoding feature – separate from the mapping services hook. This will allow adding and removing support for a specific geocoding service.
• Since Maps is now able to distinguish coordinates from addresses, the display_address and display_addresses parser functions have been removed. For backward compatibility, calls to them will be routed to display_point(s). This will of course eventually be removed.
• Removed a redundant path variable. One of the messy remains of the initial Maps release, which even caused problems on some installations.

Bug fixes

• Fixed a mayor bug in the initialization method causing hook code to get executed at a probably wrong moment. This bug can be the cause of some weird problems that surfaced since 0.3.3.
• Fixed a rather annoying issue with size of popups in Google Maps. They did not stretch far enough vertically for large contents. I’m happy I got this fixed now, since I’ve been aware of it for quite a while now, but simply could not find a solution. Yaron pointed me to a helpful blog where a certain post set me on the right track. The solution was ridiculously simple, and one line (in the JS code) long.
• Fixed some problems with the display of the mapping result formats on the Special:Ask page of Semantic MediaWiki. I’ve done this by adding an aliasing system for result formats to SMW itself. So to be able to benefit from this, you need to have that version of SMW, or later. Maps has a build in check to see if the aliasing functionality of SMW is present, and if not, uses the old, but a lot less efficient, solution.

For the change log listing, see Maps version history and Semantic Maps version history.

The documentation has been completely updated for both extensions. I only have to change the demo’s on my demo wiki to reflect the new syntaxis of the parser functions. After that I can get to work on the to-do’s for version 0.5, which will include the long awaited static map support

Did I mention Semantic Maps now supports over 50 languages? :p

Downloads

• Maps 0.4 (zip, 7z)
• Semantic Maps 0.4 (zip, 7z)
• Maps and Semantic Maps 0.4 (zip, 7z)
• Maps 0.4 SVN tag
• Semantic Maps 0.4 SVN tag

Today I’ve wrote a small change to Semantic MediaWiki that adds aliasing supports to it’s result formats. I’ve been working (mainly theorizing) on this for quite a while, and came up with some rather complex solutions, that where not feasible since they required PHP 5.3. The implementation I ended up with is ridiculously easy, and works with an $smwgResultAliases array. This array holds result formats as the keys, and the aliases as (array) value. A simple example of adding aliases using this array is:

$smwgResultAliases['googlemaps'] = array(‘googlemap’, ‘gmap’, ‘google’);

Here googlemap, gmap and google will do the same as googlemaps, which is the actual result format. To hold into account these aliases, I only needed to add some simple code to the getResultFormat function in SMWQueryProcessor. This is the code:

This implementation is fully working with Semantic Maps, and has fixed an issue this extension had with the display of it’s result formats on the special:ask page (see screenshot).

Anyway, my first direct contribution to SMW – yay

Since the 0.3.4 release of both Maps and Semantic Maps, I’ve been putting the little free time I have to use by working on the to-do’s for the next release. Originally this would have been 0.3.5, but I’ve added several things to it, that made me decide to make it 0.4 recently, since it involved some relatively big changes for the users. Here are a few of the most noteworthy changes that are planned for 0.4. Some of them are already completed, while still have to start on the others. For a list of changes I’ve made since 0.3.4, view revisions 57704, 57585 and 56614 (newest first).

New Features

• A new display_map parser function. This will enable you to simply display a map without any coordinates indicated on it. Since none of the marker related code will be used, this will be a more efficient and clean way of displaying maps. The main reason I’m implementing this is cause it’s a requirement for getting Maps suitable for Wikimedia Foundation usage.
• An OSM mapping service, which uses OL, but only allows OSM layers and is optimized for OSM. This is an other to-do that got prioritized by the WF usage requirements.
• Parsing of marker-specific title and label values. I actually marked the lack of this feature a bug a while ago, which I changed at the point where I remembered I simply did not add such a thing yet, and only map-wide title and label value’s got parsed.

Refactoring

• A new hook system for the parser functions, allowing the adding or removing of additional parser function support. Each mapping service will now have one class for handling on specific parser function.
• Change the geocoding functionality into a true feature hook element, so it can be easily removed. This is not easy to do, since the geocoding functionality is currently used at various points by the parser functions. So before I can start making it a feature hook element, the parser function code will have to be restructured.
• Create service hook for the geocoding feature – separate from the mapping services hook. This will allow adding and removing support for a specific geocoding service.
• Restructure parser functions: change display_point(s) and display_address(es) to display_point(s), with auto detect to see if the provided value are coordinates or addresses. Retain display_address(es) for backward compatibility, but remove from docs.

Bug Fixes

• Fix a major bug in the initialization method causing hook code to get executed at a probably wrong moment. This bug can be the cause of some weird problems that surfaced since 0.3.3.
• Fix a rather annoying issue with size of popups in Google Maps. They did not stretch far enough vertically for large contents. I’m happy I got this fixed now, since I’ve been aware of it for quite a while now, but simply could not find a solution. Yaron pointed me to a helpful blog where a certain post set me on the right track. The solution was ridiculously simple, and one line (in the JS code) long.

After the actual release, I’ll post a complete list of changes. In any case, these changes will force me to make a heap of changes to the docs, and also to the powerpoint’s of the presentations related to Maps and SM I’m giving.