Through work on PhotoGPSEditor and PhotoInfoEditor – geocoding/GPS programs for adding meta-data (latitude/longitude data and descriptions) to photos – I was very familiar with working with geocoded data, Google Maps, and kmz and kml files. Hence I had a start…

Google Maps: Working with Google maps was a breeze. No problems. Time to get the map working, 5 minutes.

Ash cloud data: This is where the ‘fun’ started.

First, I should point out that I have worked on defining international data storage standards so I do know something about how data can, and should, be stored…

So, first problem. Find the data.

All volcanic ash data is produced by the Volcanic Ash Advisory Centres (VAAC) – the one covering Eyjafjallajoekull is the London VAAC. Going to their website gives a link to the raw data, but NO archived data. All that can be found is the last message. The actual the VAAC data looks like this:

614 
FVXX01 EGRR 211126 
VA ADVISORY 
DTG: 20100421/1200Z 
VAAC: LONDON 
VOLCANO: EYJAFJALLAJOKULL 1702-02 
PSN: N6338 W01937 
AREA: ICELAND 
SUMMIT ELEV: 1666M 
ADVISORY NR: 2010/030 
INFO SOURCE: ICELAND MET OFFICE 
AVIATION COLOUR CODE: RED 
ERUPTION DETAILS: ERUPTION CONTINUING TO AROUND FL120 TO FL160. 
OBS VA DTG: 21/1200Z 
OBS VA CLD: SFC/FL200 N6345 W02025 - N6337 W01219 - 
N6447 W01202 - N6432 W00635 - N6234 W00431 - N5835 
W00423 - N5744 W00551 - N5744

There were no xml version, no rss feeds available… in fact, the data was a mess. Plus, it was not even possible to just down load a plain text file. The above data was embedded in a webpage.

OK, let’s have a look at the data (interestingly I couldn’t find a ‘standards’ sheet explaining the data format and so had to guess):

614                                 <-- ??
FVXX01 EGRR 211126                  <-- ??
VA ADVISORY                         <-- OK, so it is an 
                                        advisory
DTG: 20100421/1200Z                 <-- date/time, 
                                        21 Apr 2010, 1200 GMT
VAAC: LONDON                        <-- VAAC London
VOLCANO: EYJAFJALLAJOKULL 1702-02   <-- Volcano name
PSN: N6338 W01937                   <-- Volcano location 
AREA: ICELAND                       <-- Volcano area/country
SUMMIT ELEV: 1666M                  <-- Volcano summit
ADVISORY NR: 2010/030               <-- ??
INFO SOURCE: ICELAND MET OFFICE     <-- Info source
AVIATION COLOUR CODE: RED           <-- Threat level
ERUPTION DETAILS: ERUPTION CONTINUING TO AROUND 
FL120 TO FL160.                     <-- Eruption details 
                                        may spread over 
                                        several lines
OBS VA DTG: 21/1200Z                <-- observation date
OBS VA CLD: SFC/FL200 N6345 W02025 - N6337 W01219 -
N6447 W01202 - N6432 W00635 - N6234 W00431 - N5835 
W00423 - N5744 W00551 - N5744

The section starting OBS VA CLD: is the important bit as this contains the data I want….

SFC/FL200 <-- This is the height range for the observation

SFC = surface = 0 feet (yes, FEET), the FL200 is the flight level. This needs multiplying by 100, so, 20000 feet.

Next come the coordinate pairs:

N6345 W02025 - N6337 W01219

So, here we have two points here, N6345 W02025 and N6337 W01219. But what do they mean?

The N and W are easy, north and west. North and east latitudes are positive, whereas south and west are negative. So we have a north (N), and 6345. The 6345 initially had me stumped. However, it turned out to be 63 degrees and 45 minutes, so DDMM (remember, latitude goes from 0 (equator) to 90, the pole). For Google Maps this needed to be in a DD.DDDD (i.e. decimal) format, so to convert it is DD + (MM/60) as there are 60 minutes in a degree. This means that N6345 = 1 x (63 + (45/60)) = 63.75.

For the longitude W02025 needed converting. As it is W it is minus. There are 180 degrees of longitude, hence three digits are needed for the degrees, so the format must be DDDMM, so 02025 is 020 degrees 25 minutes, therefore, W02025 = -1 x (20 + (25/60)) = -20.417

The position N6345 W02025 is therefore 63.75 -20.417.

A final problem was that the OBS VA CLD: data may contain several areas of ‘ash’ so there may be multiple sections of SFC/FL200, plus there may be FL200/FL300 (flight level 20000 ft – 30000 ft), and a final ‘wrinkle’ was the data is spread over many lines.

Parsing the observation data was, to say the least, painful. And these data were followed by three sets of forecast data (6, 12 and 18 hours) that looked like:

FCST VA CLD +6HR: 21/1800Z SFC/FL200 N6349 W01939 - 
N6317 W01728 - N6253 W01517 - N6310 W01147 - 
N6408 W00707 - N6408 W00346 - N6011

The file structure and format was (is) a mess, and certainly not computer friendly.

Ash cloud data archive: One thing I wanted to show was a ‘historical’ track of the ash cloud. If you look at the site you will see this down the lefthand side. Now, this was the big shock.

I looked at all of the VAACs (London, Toulouse, Anchorage, Washington, Montreal, Darwin, Wellington, Tokyo and Buenos Aires), and the only archive I could find was at the National Oceanic and Atmospheric Administration (NOAA) in the US. In fact you can see the UK archive at http://www.ssd.noaa.gov/VAAC/OTH/UK/messages.html.

What is alarming about this archive is the NOAA archive is not an archive. The data only covers 90 days, and the messages are truncated, they are not complete. I raised this with NOAA and got a very prompted and friendly replay which said: “I spoke with the personnel at the VAAC, and was informed that the information is being truncated due to the length of the VAA on receipt. We have no way at this time to correct the problem.” Yep, the system can’t handle long VAAC messages. I also enquired if there was a publicly available archive and I was told there wasn’t.

The lack of a publicly available data archive is surprising and shocking. Surely this data is of use to researchers and other people?

The new mobile blog for mapped.at can be found at http://mapped.at/iblog, or if you visit the usual blog using an iPhone or iPod Touch you will be redirected to the new mobile site….

mapped.at – mobile blog page

mapped.at has been working on a number of Apps for the iPhone for the past year or so. Nothing so far has really got to a point where we felt happy with releasing it. There were usually some limitation of the iPhone hardware, or the iPhone operating system (OS), that meant we couldn’t get things to work the way we want, or there was something missing, or there were ‘illegal’, from Apple’s point of view, calls being made to the OS.

With the release of the iPhone 3GS this summer (mainly the inclusion of a built-in digital compass and video capability), and now the release of OS 3.1, means we can move things forward.

We now have a couple of prototype applications working on an iPhone 3GS and OS 3.1, and hopefully these will be submitted to the App store within the next month or so….

I have made good progress over the last two weeks since Mac OS 10.6 Snow Leopard came out.

The interface is finished. Image import and processing of previously attached meta-data (description, location, notes etc.) is complete, and the image export system is being completely re-written and is making uses of improvements and advances that are available in Mac OS X 10.5 and Mac OS X 10.6.

New user interface for PhotoInfoEditor

I had hoped to get a beta out for testing by the end of this week, but it doesn’t look like this will happen. With luck, and some good hard coding, I should get things finished in the next few days or so, and then with testing I hope to get a final version out within 14 days, so watch this space….

This release fixed a minor bug which was preventing photos from loading correctly.

With PhotoGPSEditor you can easily, and quickly, add location and summary details to a photo file. Location information consists of latitude and longitude data, as well as town, area/region, and country. This can be added automatically by matching up photos with GPS (gpx or NMEA) file track data, manually (just type it in) or ‘automatically’ by placing a pointer on a map to get the latitude and longitude data. The program can then add town, area/region, and country information. This process can also be described as ‘geocoding’ a picture/photo.

The program is freeware, however, donations can be made to help support future development.

This new version runs under 10.5 and 10.6 only. Unfortunately 10.4 can no longer be supported.

Over at the BBC (read story) there is a cautionary tale of a Swedish couple that wanted to go to Capri, an island of Italy, and accidently typed Carpri (an industrial town in northern Italy) into their car GPS system… The result was they ended up 400 miles off course, and only discovered this when they went to the local tourist office in Carpi and asked for directions to some attractions in Capri. You would have thought not crossing a bridge or taking a ferry to get to an island would have been a give away….?

As you can imagine, mapped.at is rather interested in geolocation and so we have been playing with the feature in Firefox, and we were very impressed (and a little bit spooked) by the accuracy. However, some reports have emerged of a users being ‘located’ many miles (some times hundreds of miles) away from their real physical location.

The article at xconomy follows up on the story, explains how the systems work, and how it can sometimes get it so wrong. An interesting read….

full story

1. Work is still progressing on a couple of iPhone Apps, meanwhile, don’t forget to check-out PhotoGPSEditor and PhotoInfoEditor.

2. A new version of PhotoInfoEditor is currently in the works (as is a minor update of PhotoGPSEditor).

3. mapped.at is delighted to announce they are sponsoring another totally mad ‘drive a Morris to Mongolia’ team this summer. Full details can be found at: Morris to Mongolia. More details to come….

Driving from Adelaide to Melbourne is a long way…

Bits of the drive were very boring… long straight roads across what seemed endless farm land… on and on and on…

The Great Ocean Road was fantastic. A fun and hard drive along winding coast roads with lots of wonderful views and places to visit.

Doing the drive in winter (apart from the truly awful wind and the driving rain…) was great as we had a lot of the places we visited to ourselves. very few tourists about…

The drive also provided a great opportunity to test the mapped.at software. The conclusion is the cell (mobile) phone application is not of ‘production’ quality. I don’t know if it is the phone, the Java, or the software. I suspect it is a combination of all three.

The GPS data analysis software is still a bit buggy, and it does seem to ‘clunk’ when processing 3 days worth of GPS data… plus the resulting kml/kmz files are a bit large (my guess it is a problem of ‘redundant’ points), so this will all need some more work…

Anyway, the software did manage to produce the necessary root files, and I was able to geotag the photos, with ease, using PhotoGPSEditor…

And the route file… it can be found here. This file shows the route we took from Adelaide to Melbourne…

Kmz file: Adelaide to Melbourne