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
Maps 0.4