Alex Little

Fixed quite a few little bugs and other things we needed to get sorted out this week, for example transferring the Moodle MSG block so that it uses the MSG API that we’ve developed. That required a few changes to be made to how the API worked – though only additions rather than changing how it worked originally.

We also released the latest version of the MSGAlert tool (v2.1 – more info) which now includes a link to the MSG presence map. Currently this is only available for the msg.open.ac.uk server (and not msg-openlearn.open.ac.uk, but that’s coming soon). Marc has been demonstrating (amongst other things!) our MSG maps implementation as the EleGI project review meeting this week. This gives a good cohort of users from across Europe to test out the maps and find if there are other remaining bugs or things we could improve.

This morning I also started to look at embedding the maps within the Moodle MSG block, my thinking at the moment is to put a very small Goolge map with in the block (if you are logged in) and the map would centre on your location and put a marker there of you online, but then to view all the other users you would need to click on a link (or on the map) to launch the full MSG presence map. So somthing like…

In fact this is already up and working on my development server. Just not sure that the map isn’t a little too big? Another quesion I’ve got is what to do when users aren’t logged in? I want to show somthing of the map – to try and “entice” people to sign in, rather than just a text link or nothing at all. Maybe it should show a short demo video of how to use the maps – something which I ought to produce anyway? Any other suggestions gratefully received

In case you are wondering, I’m not planning on having all the users contacts displayed on the embedded block map, users will have to go to the actual MSG Presence Map page for this. The reason being that it’s potentially to heavy to have all this javascript going on in the background all the time, especially when there may be other block and content doing JavaScript ‘stuff’ too.

Here’s a screenshot of where I’ve got to with the maps….

You can see the green and grey markers on the map, signifying where users are on or offline. The balloon shows all the users located at one of the markers, and gives a link to chat to those who are online.

Now that I’ve fixed the problem with the rounding and precision of users lat/lng coordinates, I’ve been able to get back to what I was actually trying to do, and that is allow users to select which groups of contacts are shown on the map. By default when you visit the map all your contacts (who we have location data for) will be shown on the map, there is then an option to tick/untick each group of contacts and the map is dynamically updated with these changes.

I feel like we’re getting very close to having the maps deployed onto a a ‘useable’ server – rather than just running on my desktop machine!

Over the last few days we’ve also been running a few presentations and workshops about the LabSpace tools, for the Widening Participation Fair (held at the OU on Tuesday) and hosting a vist from the Sussex Learning Network (SLN) – as we’re heading down to sunny Sussex to do a few workshops for them later this month and again in May. All the feedback we’ve had from the workshops has been very positive and people seem keen to find out more and test out the tools we’ve developed.

I also gave a quick demo yesterday of MSG at the mLearn  (Mobile Learner Support Project)

I’ve spent most of this week virtually rewriting the javascript for MSG on Google maps and also spending time improving the clustering algorithm.

The reason for updating the javascript was to ensure that only markers were loaded as and when they were actually needed for display – my previous version was retrieving all the data for the markers whether or not they were currently visible on the map. I’ve been using chapter 7 of a Google Maps Applications with PHP and Ajax bookto help me get this sorted out and it’s turned out to be very helpful. Having implemented this it REALLY speeds up the application and makes if run far more smoothly – even for a relatively low number (approx 70) markers.

I slightly changed the exact functions in the book so that when the user moved around the map any existing markers were left in place – only the new ones were added in – rather than clearing all and redrawing. The reason for doing this was that if a marker appeared close to the top of the map and then you clicked to open the HTML info window, the map would auotmatically scroll down to be able to fit the info window within the map area – using the functions from the book this would lead to the marker being removed and rewritten (hence also closing the info window), but keeping the marker in place and just adding any new markers seems to get around this. However I’m not sure how my maps would cope if a user spent a long time moving around a single zoom level of the map as the number of markers stored would gradually build up. Fortunately the markers are completely refreshed when the user changes zoom level, so hopefully this build up will not be a big issue.

I’m also in the process of updating the clustering algorithm that I was using for the various zoom levels. The main problem I was envisaging with the algorithm I’d implemented was simply the execution time in updating the clusters – for only 100 points it could take a loooonnnng time to run in PHP. So I started to look at using a grid system instead – in which the earth is divided into grid squares and whichever markers were in a particular square these would be clustered at the squares’ centre. This runs much faster than my original algorithm since it doesn’t need to iterate to calculate distances between points. However, I did find several drawbacks using this grid system, firstly, that when displayed on the map the points looked “too regular” and some appeared in the sea etc, secondly a grid square could cut a ‘natural cluster’ into 2 (or more) markers with half the points being allocated to the marker in the centre of one square and half going to another.

I’ve not been too bothered about this second drawback – as the markers we’re using are only meant to be approximations and I think they are good enough for what we need. But, I really didn’t like markers appearing in the sea and being too regimented on managscreen – so I’ve ed to fake a way around this…. rather than putting the markers at a point in the centre of the square, I’ve just selected (randomly) one of the actual marker points in the grid square and given all other points in this grid square the same coordinates. This has several advantages… 1) the map ‘looks’ better (!), 2) all markers will be at a ‘real’ position – so no-one will appear to be located in the middle of the North Sea, 3) for grid squares which only contain a single point, the marker will always be at exactly the correct position no matter what the zoom level is.

Still got a bit of finishing off to do, but very nearly there

Have progressed well over the last few days (and the few days before Christmas) getting the Google Maps fixed up. I now have a clustering algorithm implemented (admittedly not a very sophisticated one, but it does the job) so we don’t end up with loads of overlapping markers when the user has zoomed out (see below):

Without clustering:

With clustering:

This appears to work quite well with around 100 or so different markers on a map (not yet tested for much higher numbers of markers). The ‘cluster’ that each marker belongs to for a given zoom level is cached in a database, this is to save having to recluster the markers on the fly – which will get really resource intensive for large numbers of markers. We should also be able to use more efficient clustering algorithms without having to change any of the map interface code.

Few more things that I’m working on now…

• Using different marker icons depending on the number of users in a cluster (larger icon = more users)
• Moving the maps so they become part of the MSG client rather than part of Moodle (as they currently are) – this shouldn’t be a massive job, but will involve moving services currently provided by MSG block in Moodle to be from MSG & Wildfire servers
• Looking at how to implement custom maps within Google Maps API

That’s probably enough to be getting on with for now