Where On The Map Am I?

When I blogged about using KMLMapLoader to load easily load KML/KMZ files onto a map I quietly side-stepped one problem. The KMLMapLoader requires you to specify the latitude and longitude on which to centre the map and a zoom level, but where do you get these values from?

You could play around with the main Google Maps page and try and figure out appropriate values but this can be a bit hit or miss. The easiest way it to use a new feature in TagME. Simply open your project, choose to configure Google Maps from the tools menu and then specify the size of the map (in pixels) and it will give you the latitude, longitude and zoom values to use. Nice and simple!

Easy Map Embedding

Every since starting the development of TagME I've been thinking about finding an easy way of showing the geotagged photos on my blog. Now it is quite easy to display a KMZ file in Google Maps (and of course Google Earth) using the simple method Google provides. Unfortunately this method doesn't allow you to access all the features of the Google Maps API. So to allow me more flexibility I've written some javascript to allow for easy map embedding. Here is the script in action:

To achieve this you need to have already loaded the Google Maps API and then in the head section of your page load my KMLMapLoader. The when you want to embed a map you create a DIV to contain it. For example, to create the map I showed above you add the following to your page:

<div kml="http://www.dcs.shef.ac.uk/~mark/blog/blog_files/journeys/to_work_updated.kmz"
    zoom="11" latitude="53.4717" longitude="-1.511993"
    maptype="G_PHYSICAL_MAP"
    config="map.addControl(new GLargeMapControl());"
    style="border: 1px solid black; width: 600px; height: 700px;">
</div>

It is reasonable straightforward but here is an explanation of the different attributes you can set:

kml

This should be the URL of the KML or KMZ file you wish to display on the map.

latitude

The latitude of the centre of the map.

longitude

The longitude of the centre of the map.

zoom

The zoom level (level 0 shows the whole earth, each increase in zoom level increase the area seen be a power of 2).

maptype

The map type. The default is the street level map, but you can specify any of the types Google supports. Note that id you specify G_SATELLITE_3D_MAP and the Google Earth plugin isn't installed then rather than an error message the script will revert to using G_SATELLITE_MAP

config

If specified this should be JavaScript that will be executed once the map has been initialised. The map itself is available in the variable map and this can be used to further configure the map (for example adding a large map control rather than the default small control the script uses).

Only the kml attribute is required, but to set the location of the map latitude, longitude and zoom must all be specified.

The script actually does a little more than loading the map, it also provides a fix for a bug in the current version of the Google Maps API. When loading a KMZ file the images etc are accessed through a server side script. Unfortunately the API uses a relative URL to point to this script and so KMZ files display properly if loaded through the main Google Maps website but not when loaded using the API. KMLMapLoader adds code to fix this bug which you can reuse even if you don't want to use the loading facilities.

TagME: Version History

I've decided that instead of a new blog posting every time I release a new version of TagME I'm simply going to update this version history page instead. Of course if there is a major new feature or something worthy of a separate post then I will do one. So without further ado here is the release history to date:

v0.8.1 - 06/02/2010: Open-sourced the code. See here for details.

v0.8.0 - 25/11/2008: Fixed a nasty bug in the map zoom level calculation which might have been causing problems with the time properties display. Added a new feature which calculates the latitude, longitude and zoom level for displaying the KMZ files TagME exports within Google Maps, via the Google Maps API, or with my new KMLMapLoader script.

v0.7.0 - 19/11/2008: Quite a few behind the scene changes to improve performance and stability. Updated the KML output to be more conformant to the spec and introduced the ability to specify author and website.

v0.6.1 - 09/11/2008: I have finally added the ability to embed the GPS coordinates into the photos so that they can be re-used by other programmes.

v0.5.0 - 03/11/2008: The Now with Improved When and Where! release. Added a time zone chooser and a map to the time offset editor. Both of these make TagME a lot easier to use. See this blog post for details.

v0.4.0 - 26/10/2008: Quite a few bug fixes but the major change was the addition of the AppDeath crash reporting tool. See this blog post for details.

v0.3.0 - 16/10/2008: Changed the project file format. Projects saved with earlier versions can no longer be loaded. See this blog post for details.

v0.2.0 - 15/10/2008: Mostly a bug fix release but added the ability of the user to choose the KMZ file name. See this blog post for details.

v0.1.0 - 11/10/2008: The first release of TagME. See this blog post for details.

TagME: Now with Improved When and Where!

I'm releasing another version of TagME today which should along with a number of bug fixes and improvements should fix two of the main problems I had with previous versions; choosing a time zone and setting the camera's time offset from the GPS clock.

To make choosing a time zone easier I've hacked up an as yet rudimentary time zone chooser. Basically you start by choosing a continent or large land mass (not quite sure why they are group as they are) such as Europe, Pacific or Canada and then choose (usually) a capital city to set the time zone. So for example, to choose the UK's time zone you would select Europe and then London. If you can't find your time zone then you can select Etc which then gives you the option of GMT-14 to GMT+12 as well as Zulu and UTC! This still needs work (for example, I don't really think we need the SystemV entries) but should make life a little easier.

The second problem was determining the difference between the GPS clock and the clock in the camera. Getting this right is important otherwise the location of the photos will be wrong. In previous versions the best way of doing this was to view the output in Google Earth and try and work out what how far out the pictures were and then experiment with different offsets. I've improved this by including a little map in the time offset window on which changes are instantly reflected. Currently only the first selected photo (or the first in the list if no photos are selected) is shown, so it may be easier to choose one photo that you know exactly where it was taken and then correct the time offset by applying the changes to all photos.

And in case my descriptions of these new features aren't very good here are some screenshots.

If you want more than a screenshot then as usually you can it directly or if you have the shortcuts installed from trying it before then they are already pointing to the new version.

Let me know what you think.

TRIPOD

No I'm not talking about the three legged object to which you attach a camera (although if you travel a lot then I'd recommend a Gorillapod).

I've recently been volunteered to be the research groups seminar organiser. Every week the Natural Language Processing (NLP) group holds a meeting and we try to ensure that we have a talk as well. Sometimes people from the group speak and other times we invite people from other universities or from industry to come and speak to us.

The head of the research group recently changed and the person who had been organising the seminars left. So now I' have the job of organising the talks. If you happen to work in NLP and would like to come talk to us in Sheffield, please let me know!

Anyway last weeks talk was about the TRIPOD project. The work being done in Sheffield concerns trying to automatically label photos given their geographical location. Given my recent work on TagME I found the talk very interesting. So interesting in fact that TagME might get some automatic photo labelling facilities at some point in the distant future.

If you are interested in the details then both the slides and a research paper are available.

We Regret to Announce....

We regret to announce the death of the application you were using.
The Grim Reaper has called and collected the applications soul,
please do not send flowers.

I've just released version 0.4 of TagME. There aren't really any new features in this version (although there are some bug fixes) what is different is that it now incorporate an error reporting tool that I'm calling AppDeath.

So now if you manage to crash TagME then a nice friendly crash reporting window will appear. If you could fill in the details and press send I'd appreciate it.

At some point I'll release AppDeath for use with other applications and explain how it works, but for now I just hope you never see it.

Software Testing: Part 2

Yesterday I told you how important software testing is. Well, last night I got bitten again! The moral of this new problem is:

It doesn't matter how well you test your own code if you don't fully understand the implications of all the third party libraries you use.

I fixed a bug in TagME last night which unfortunately has meant that any existing saved projects cannot be reloaded -- sorry! Hopefully no one has created any serious projects with the application yet and so it won't actually affect anyone.

I've taken the opportunity to fix a couple of other annoying features of the saved projects that I hadn't changed before because I didn't want to break anything. The upside of all this is that the project files are now much easier to maintain, about a third of the size, and contain versioning information so if I need to make changes in the future I should be able to silently upgrade project files as they are loaded.

Anyway a new build of TagME has been made available for those who want it.

Software Testing

I came across this comment on Slashdot yesterday:

Top flight developers producing quality code don't need large QA departments. They've already written well-designed, bug-resistant code, unit tests, integration tests, and performance tests, all in the course of producing something that works (the first time). If you have to pay a phalanx of QA engineers to find bugs post-facto ("just as important as our development department"), you're doing it wrong. The bugs shouldn't have been there to begin with.

Anyone who has ever done any serious software development knows this is not true so I'm assuming that either the poster was a troll or isn't a software developer -- most likely a troll.

Unfortunately the false nature of this statement was well illustrated this morning in my new TagME project. I do a lot of different things to try and catch bugs as I code but there is no replacement for human testing. When developing the export to KMZ feature I hard coded the output file to be output.kmz in the current directory and forgot to change this and allow the user to choose their own file and directory before I released it last week.

Fortunately, releasing TagME as a Web Start application means that every time anyone starts it up, either from the website or from the shortcuts it installs, it automatically updates itself to the newest version. So I've recompiled everything and placed a new version online so next time anyone launches TagME they will get the bug fix without knowing. They will know something has happened though as the new version also includes some new features. I've restricted a lot of the input fields so they now only take valid values which means it is a lot harder to crash. Also you can now specify the colour, thickness and opacity of the track line, and change the orientation of the photos. I'll update the tutorial later today.

TagME: A Tutorial

While I think TagME is easy to use I'm guessing that for everyone else a simple tutorial introducing the main concepts would be quite useful, so here goes.

Start by downloading and unzipping the sample GPS track and photos and then TagME.

Now follow these five simple steps to geotag and display the photos:

1. First we need to load the GPS track file. Click on to bring up a file open dialog and open the track1.gpx file you downloaded. The track details should then appear in the left hand list.
2. By default the time zone is set to your current location. To properly locate the photos on a map the time zone must be set to the time zone in which the pictures were taken. For the sample images the time zone should be set to "Europe/London". The time zone will default to your local time zone but if this isn't correct then click the button to select the correct time zone.
   
3. Now we need to load in the sample photos. Click on the to bring up a directory chooser and select the directory in which you unzipped the sample photos. Once the photos have loaded they should appear in the left hand list.
4. With the sample images you will notice that the last image in the list is labelled as not appearing within the GPS track. This is because the clock on my camera and the GPS clock are about 2 minutes different to each other. To fix this and shift all the photos to the correct time (and hence position) click on the and then adjust the time to -2 minutes and choose to adjust the time for all the photos then click OK.
5. That is it you have now worked out where each photo was taken. If you just want to add GPS coordinates to the photos then you can do this by clicking on . More likely though, you want to see on a map where the photos were taken. If you are on Windows and have Google Earth installed then you can click on to preview the output in Google Earth. If not then you can click on to export to a KMZ file which you can then load manually.

That is how simple TagME is to use. Of course you can customize the output further. Clicking on either of the buttons will allow you to edit details of the selected track or photo -- giving them names and/or descriptions. You can also save your project so that you can come back and continue editing it at a later date.

TagME

Well it took me a little longer than I originally planed but here is the first version of my new software project, TagME.

TagME is designed to solve all the geotagging problems I was having with the software that came with the GPS recorder I blogged about last month.

The main issue with the software that came with the GPS recorder was that when geotagging photos the output only worked in Google Earth and not with Google Maps. This first version of TagME fixes that problem by exporting to a KMZ file which can be displayed in either Google Earth or Maps (the ME in TagME stands for Maps and Earth -- clever don't you think!). I've also added support for setting the timezone (the GPS times are always in UTC, which is the same as GMT) which while possible in the bundled software was not very straightforward.

I will, however, be the first to admit that TagME is far from perfect. To start with there is as yet very little error checking going on so I expect you could quite easily crash the programme -- this will be my first priority for the next version. The main glaring omission is that there is no visualisation or ability to edit the GPS track data. Currently you can click a button to show the data in Google Earth (if you have it installed and are running Windows) but this takes a while and isn't ideal. Some form of track editor is definitely high on the list of features that need implementing as well as the ability to customize the photo bubbles as the current formatting is very boring.

I still think it is easier to use and produces better results than the bundled software so altogether not too bad for a fortnights work. Given the shocking state of the code at the moment I'm just making the executable version available which you should be able to run simply by clicking the shiny orange launch button.
You can also download a sample GPS track file and some photos to play with (note that I reckon the time offset for the photos should be -2 minutes).