Facebook Places and FourSquare

In recent weeks I have tried to use the location-aware services FoursSquare and Facebook Places. They operate quite similar: when logging in, they show a list of nearby places, and one can select the place where one is currently, or can add a new place.

In my opinion, the winner of this informal heuristic comparison between these two services is FourSquare: There appear just many more places to choose from, when I try to check in. This is probably due to the fact that FourSquare has been around a bit longer than FB Places, and this is an advantage, because one does not have do enter new places. Also, since more people appear to have used Foursquare, the quality of the place entries in FourSquare appears to be better than in FB Places: there are sometimes duplicate entries in FB for the same location, and sometimes the coordinates of the place are off. I had to correct one entry on FB Places, whereas in FourSquare I have not yet seen an error.

I have used them both on the iPhone. Here FB Places does have the edge of providing to post photos linked to the location, something that I have not seen in FourSquare. Also, the integration of FB places into the whole FB experience is well done, no need to start another application. But the display of the location from FourSquare on Facebook looks sleeker: the map is shown on the wall, which immediately gives a nice piece of information to friends, whereas FB Places only shows the status update and the pictures that one has posted through the Places interface.

FB Places does not appear to work in Austria yet, whereas FourSquare works fine. I had some problems with either app: at some point FourSquare did not initialise the localisation API properly and got stuck in trying to get the location - I had to remove the app and install it new again, then it worked. The same thing is happening currently to my Facebook Places tab: when I click it, all it says is "locating you"... forever.

I am not going to fix this now (by reinstalling the FB app), because from now on I will anyway use FourSquare only.

New Experiments

Since my last blog entry here a lot of time has passed. In the meantime, Google has modified the way in which the Google Maps API can be accessed, and I have experimented with this new way which makes it easier to run other Google apps simultaneously with Google Maps on the same site.

I am experimenting with the Google Maps API and am writing a few JavaScript functions which should allow an easy Google Maps setup on any new page. This uses extensively callback functions for the various events that can occur when interacting with the map. I will soon put the links to my sites here, once I have some basic functionality working.

Problems in Browsers

Just recently I realised that my routines for using Google Map to display GPX files do not work at all in Google Chrome and Firefox. I had developed the code by testing in MS Explorer 7, hoping that my attempts on being cross-browser compatible would pay off. But no, as I noticed a few days ago, the map is not being updated and does not show the actual track; instead it remains at the default location. I have to explore what the technical issue is. Might be that an error is thrown after which the browser stops executing JavaScript code and does not progress to the point where the map is to be shifted to the new location. Due to the limited debugging capabilities of the browser / editor environment which I am using (Homesite), this will take a while to fix...

Consolidating of Source Code Base: version 0.1

For future development and expandability it was important to reduce the existing code (HTML, JavaScript, PHP) into smaller chunks and make it more managable.

This has now been achieved: the three main display pages (ShowMapHeadingley.php, ShowMapTracks.php, and ShowMapPlaces.php) are using the same functions now, which are consolidated in GoogleMaps.js. This file has the specific functions relating to Google Maps. It also has a basic framework for initialising and showing map content, with the option of having external functions which are executed in the Main files. The automatic callback functions which are executed as <body> event handlers, are common to all three of the main files; this means now that new additional functionality can easily be implemented. It also enables a common interface (through GET with parameters in the URL) so that these files react in the same way.

Here is the current implementation of this common interface (version 0.1):

w	map width in pixels; if not given, then the full browser width or the widht of the encapsulating element (table cell, iframe, ...) is taken as the width of the map.
h	map height in pixels; if not given, then the height of the screen is taken as the map height; this will result in a map that can be scrolled down to see the full extend.
p	point of interest; parameter consists of several parts, separatated by comma: latitude, longitude, text heading, URL for link under the text heading.
tr	GPS track; parameter consists of several parts, separatated by comma: filename, color of track, longitude, text heading for track.

These parameters work fine for ShowMapTracks.php and ShowMapPlaces.php; ShowMapHeadingley.php has currently problems with the full support of these parameters (p, tr) and will eventually be depreciated. A better way will be found to combine live user tracking and static information display. However, all future work will be based on the now consolidated Javascript functions in GoogleMap.js.

Show Tracks on Maps

In principle this is an easy task: to show a track that was recorded by a GPS, onto a Google map. But my search for a suitable applet did not result in anything, so again I did write such a little widget. The term "widget" here might be slightly misleading: the components shown here are not self-contained applications, but pieces of code which anyone could implement in their web site.

The principle is to use an IFRAME, for accessing the script and showing it in a clearly defined region of the web page. The Iframe calls the scripts that I have written - they are hosted on our server.

The widget for showing a track is based on the following:

• a GPX file exists which has the track stored. GPX appears to be a standard XML file, which is used by the OpenStreetMap Community. The Garmin software "MapSource" provides an easy way of exporting recorded tracks into GPS files; and since I use a Garmin GPS, this was the most straight-forward method for me to implement. The GPX file can be accessed with HTTP - this needs then to be included in the parameter URL.


• The GPX file has the track points in the tag . Segments within the track are disregarded - they are simply merged into one track.

The Javascript file that is called by the IFRAME, expects simple the filename of the GPX file (usually given as a URL; tracks can be hosted on OpenStreetMap, and the URL of these tracks can directly be used). This filename is given as a parameter in the URL, together with the optional parameter of track color and track heading.

The script then reads the GPX file. In order to do this, a separate PHP file had to be written which adds the 'text/xml' content-type header before the GPX file is actually loaded. The Javascript file then evaluates the XML file and extracts the points. Start time and end time are recorded too, but no further evaluation takes place. The route is then made into a polygon and is drawn onto the Google Map.

Here is an example how this looks:




This is the code for the above map:

<iframe width="100%" frameborder="0" src="http://creativetech.inn.leedsmet.ac.uk/_Track/ShowMapTracks.php?h=400&tr=tracks/080626_RB.gpx,Red,Bicycle%20Ride" height="400px" >
</iframe>


There is no real reason why these two widget (showing places, showing tracks) need to be in two separate files. In fact, they share a common script file and are basically identical, so either of these files will support all the GET parameters handed over in the URL. The two files may in the future be merged, but for now they will remain separate.

The track display allows to click on the track: a text balloon appears then, indicating start and end time as well as total length of the track. This latter function uses Google Maps function for computing the polygon length.

Map "Widget"

When I tried to include a Google Map into one of my recent blog entries, I did not find a suitable method to just add a placemark and show the map in the blog entry. There was the option to show a map as a static image, provided by Google, but I wanted to keep all the user interaction open (zoom, shift, etc.). So I had no other choice than to write again an HTML page with this functionality.

This page allows to show any set of locations, provided through just the URL. The following is an example how it looks:



This is the code for it:

<iframe width="100%" frameborder="0" src="http://creativetech.inn.leedsmet.ac.uk/_Track/ShowMapPlaces.php?h=400&p=34.8239369,33.6019474,Journalist%20Village,http://www.esk.org.cy/en1.htm&p=34.8210700,33.6035568,Hotel%20Pharos,http://www.faros-village-larnaka.eureka-reservation.com" height="400px" >
</iframe>

Anyone can use this for inclusion in their own blog - no warranty is given here, not for functionality, damage, or sustainability. The above URL may disappear any time, but for now it will remain here - if it would be moved, it will be announced here in this blog.

The method is to embed an IFRAME into any web page, with the usual parameters. The URL is http://creativetech.inn.leedsmet.ac.uk/_Track/ShowMapPlaces.php.

Parameters are:

h= height of the map
w= width of the map; if not given, it will automatically adjust to the width of the IFRAME
p= point
This is given by 4 parameters, separated by commas:
latitude, longitude, headline text, headline URL

Feel free to test it out into your own web site.
Not sure how long the URL can be... but any number of points is ok. In case of 1 point, a zoom factor of 17 is assumed. In case of more points, the bounding box is computed automatically, and the zoom is set so that all points are within the visible map.

Have fun!

Open Day at Leeds Met

The Geo-centric interface has been demonstrated today at the Open Day event. A display monitor at the Innovation North booth showed the web page with the map of the Headingley Campus (Google Map), indicating the icons for individuals' location. Unfortunately it is raining, which makes it not really feasible to walk around outside with the mobile phone/GPS.

A suggestion for future demonstrations would be to include more people being tracked, to have a more lively display. At the demonstration, it was only my lonely icon there, and as Iw as in the tent, I was stationary, and the icon did not move. It worke fine, however, as soon as I walked out. It also worked surprisingly well when I returned: the GPS was tracked even as I walked within the Marquee.